서버 GTM을 사용한 쿠키 없는 GA4 추적

디지털 환경이 지속적으로 발전함에 따라, 사용자 추적 및 데이터 개인 정보 보호에 대한 접근 방식이 크게 변화하고 있습니다. 웹 브라우저에서 서드파티 쿠키를 단계적으로 폐지하고 엄격한 데이터 개인정보 보호법이 도입됨에 따라, 전통적인 사용자 추적 방법은 급속도로 관련성을 잃어가고 있습니다.

이러한 변화에 적응하는 것은 데이터 기반 인사이트에 의존하는 기업과 마케터들에게 필요한 것이 아니라 반드시 가져야 할 것입니다.

최신 추적 도전에 적응하는 방법 중 하나는 쿠키리스 추적으로 전환하는 것입니다. 구글 애널리틱스의 최신 버전에 대한 여러 가지 단점과 불만이 있지만, 여전히 가장 인기 있는 분석 플랫폼입니다. 이에 따라 이 글에서는 서버 Google 태그 관리자를 사용하여 쿠키리스 Google Analytics 4 추적을 설정하는 방법에 대해 설명할 것입니다.

웹사이트가 사용자에 대해 무언가를 기억하고자 할 때(예를 들어, 장바구니에 무엇이 있는지 또는 웹사이트에 도달하기 전에 어떤 광고를 클릭했는지 등), 종종 "쿠키"라는 작은 데이터 조각을 사용합니다.

하지만 이제 많은 웹사이트가 사용자의 활동을 추적하기 위해 이러한 쿠키 사용을 중단하고 있습니다. 대신 사용자의 브라우저에 데이터를 저장하지 않고도 추적할 수 있는 새로운 방법을 사용하고 있습니다. 쿠키 없이 추적을 유지하는 이 새로운 방식을 "쿠키리스 추적"이라고 합니다.

쿠키에 의존하지 않는 추적은 첫 번째 파티 사용자 데이터를 사용합니다. 이 정보를 수집하고 안전하게 처리하는 가장 좋은 방법은 서버 측 추적을 사용하는 것입니다. 이 방법을 통해 추적, 저장, 풍부화, 변환 및 퍼스트 파티 사용자 데이터 흐름을 엄격히 제어할 수 있습니다.

이는 쿠키를 없애고 추적을 더 정확하게 만들 뿐만 아니라, 더욱 준수하며 사용자 데이터에 대한 더 큰 통제력을 가질 수 있게 해줍니다.

쿠키리스 추적은 추적 개인정보 보호 및 제한에 대한 최근 변경에 적응하는 데 도움이 됩니다. 다음은 몇 가지 예입니다.

1. 1.
   규정. 유럽 및 기타 일부 국가의 데이터 보호 규제 기관은 사용자의 동의 없이 쿠키 사용을 제한합니다. 쿠키를 거부하는 사용자의 비율은 국가, 연령 및 쿠키 배너 요구 사항에 따라 다릅니다. 그러나 전반적으로 약 50%의 사람들이 마케팅 및 분석 쿠키를 거부합니다.
2. 2.
   서드파티 쿠키의 가치 하락. 사파리와 파이어폭스는 이미 서드파티 쿠키를 제한하고 있으며, 브레이브는 서드파티 쿠키를 지원하지 않으며, 크롬은 2024년부터 서드파티 쿠키를 단계적으로 폐지할 계획입니다. 광고 네트워크는 서드파티 쿠키를 사용하여 사용자가 웹사이트에 도달하기 전에 클릭한 광고를 구별하고 이후에 전환합니다. 뿐만 아니라 분석 플랫폼은 서드파티 쿠키를 사용하여 이미 웹사이트를 방문한 사용자를 추적하고 사용자의 전체 여정을 보여줍니다. 쿠키 없이는 적절한 전환 속성과 새로운 사용자와 기존 사용자 간의 구분이 매우 어려워집니다.
3. 3.
   완전한 추적 제한. 애플은 추적 제한 측면에서 개인정보 보호를 선도하고 있습니다. 모든 iOS 앱은 사용자의 추적 허가를 요구해야 합니다. 뿐만 아니라, iOS 사용자는 언제든지 앱의 추적 활동 허가를 철회할 수 있습니다. 또 다른 추세는 광고 차단기의 사용 증가입니다. 광고 차단기가 활성화되면 마케팅 및 분석 도구는 사용자에 대한 어떠한 정보도 받지 못합니다.

Google Analytics 4는 분석 쿠키에 동의하지 않은 사용자의 행동을 모델링하기 위해 머신 러닝을 사용합니다. 그들은 분석 쿠키에 동의한 비슷한 사용자의 행동을 사용하여 분석 쿠키에 동의하지 않은 사용자의 행동을 모델링합니다.

머신 러닝에 적합하려면 GA4 속성이 특정 조건을 충족해야 합니다:

• 모든 페이지에서 동의 모드가 활성화되어 있어야 함.
• 동의 대화 상자가 나타나기 전에 태그가 트리거되어야 함.
• Google 태그는 사용자가 동의하는 경우뿐만 아니라 모든 경우에 로드되어야 함.
• 최소 7일 동안 하루에 1,000개 이벤트가 analytics_storage='denied'로 설정되어야 함.
• 이전 28일 중 최소 7일 동안 하루에 1,000명의 사용자가 analytics_storage='granted'로 이벤트를 보내야 함.

GA4 속성이 머신 러닝 자격을 갖추지 못하거나 머신 러닝이 정확한 결과를 제공하지 않는 것으로 판단되면, 분석 쿠키를 거부하는 사용자에 대한 퍼스트 파티 데이터에 의존하고 쿠키리스 GA4 추적을 구현할 수 있는 옵션이 있습니다.

GA4가 제대로 작동하고 돌아오는 사용자를 인식하려면 GA4에 다음 정보를 제공해야 합니다:

• 클라이언트 ID (cid)
• 세션 ID (sid)
• 세션 수 (sct)
• 첫 방문 (_fv)
• 사용자 참여 (seg)

사용자가 동의하지 않았을 때 쿠키리스 GA4 추적을 설정하기 위해 다음 도구를 사용할 것입니다:

1. 1.
   서버 Google 태그 관리자
2. 2.
   서버 GA4
3. 3.
   GA4 gsc 매개변수를 사용하여 사용자 동의 구분
4. 4.
   Stape에 Google 서비스 계정 연결
5. 5.
   Firestore에 데이터 쓰기
6. 6.
   Firestore에서 데이터 읽기
7. 7.
   Stape 사용자 ID 파워업

동의가 부여되었는지 여부를 결정하기 위해, 우리는 gcs 매개변수를 사용합니다. 기본 GA4 동의 구성은 sGTM으로 요청을 보내지만, 요청에는 일부 정보가 누락되어 있습니다. 모든 GA4 요청은 Firestore에 기록됩니다.

동의 없이 GA4에서 사용자의 활성 세션을 확인하려면 이전 방문의 타임스탬프와 현재 방문의 타임스탬프 차이를 사용합니다. 차이가 30분 이상이면 Firestore에서 세션 매개변수를 업데이트합니다.

Firestore는 UserID를 문서 이름으로 사용하고 이 문서 내에 사용자 세션에 대한 세부 정보를 저장합니다. 이것은 Firestore를 구성하는 간단한 방법이지만 Firebase에서 전체 사용자 경험에 대한 데이터를 유지하는 다양한 다른 접근 방식이 있습니다.

1.1 기본 GA4 서버 측 설정을 사용하세요. 

1.2 필요한 경우 Firestore에 데이터를 기록하세요. 이 목적을 위해 Firestore Writer 태그를 사용합니다. Firestore Writer 태그 사용 방법에 대한 자세한 안내는 이 가이드를 확인하세요. 우리는 UserID 컬렉션을 사용합니다. 각 사용자 ID에 대해 cid를 문서 이름으로 사용하는 새 문서를 생성합니다.

1.3 GA4 서버 측 태그는 표준 구성을 가지고 있으며 GA4 클라이언트가 요청될 때마다 트리거되고 사용자가 분석 쿠키에 동의합니다.

2.1.1 분석 쿠키에 동의하지 않은 경우, 우리는 Stape User ID 파워업을 사용하여 sGTM 요청 헤더에 사용자 ID를 추가했습니다.

2.1.2 Firestore Writer 태그를 사용하여 Firestore에 데이터를 기록하고 Stape User ID를 문서 이름으로 사용합니다.

2.1.3 세션이 활성화되었는지 확인하기 위해 Firestore Reader 변수를 사용하여 Firebase에서 이 사용자의 마지막 방문과 관련된 타임스탬프를 추출합니다. 그런 다음 사용자의 이전 세션 타임스탬프와 현재 타임스탬프 간의 차이를 확인합니다. 타임스탬프가 30분 미만이면 사용자는 기존 세션을 가지고 있습니다.

2.1.4 매개변수는 다음과 같이 업데이트됩니다:

• cid 및 client_id는 Stape UserID의 값입니다.
• ga_session_number - Firestore의 ga_session_number 값
• ga_session_id - Firestore의 ga_session_id 값
• x-ga-mp2-seg (참여 세션)는 1로 설정됩니다.
• x-ga-system_properties.fv (첫 방문), x-ga-system_properties.ss (세션 시작), x-ga-system_properties.nsi (새 세션 ID)는 제거됩니다.

2.1.5 GA4에 수정된 데이터를 보냅니다. GA4에 데이터를 보내기 전에 업데이트하기 위해 변환을 사용합니다.

2.2.1 분석 쿠키에 동의하지 않은 경우, 우리는 Stape User ID 파워업을 사용하여 sGTM 요청 헤더에 사용자 ID를 추가했습니다.

2.2.2 Firestore Writer 태그를 사용하여 Firestore에 다시 사용자 데이터를 기록하세요.

2.2.3 세션이 활성화되었는지 확인하기 위해, Firebase에서 이 사용자와 관련된 타임스탬프를 추출하기 위해 Firestore Reader 변수를 사용합니다. 그런 다음, 사용자의 마지막 세션 타임스탬프와 현재 타임스탬프 간의 차이를 확인합니다. 타임스탬프가 30분 이상이면 새 세션이 시작된 것입니다. 세션이 활성화되었는지 확인하기 위해, Firebase에서 이 사용자와 관련된 타임스탬프를 추출하기 위해 Firestore Reader 변수를 사용합니다. 그런 다음, 사용자의 마지막 세션 타임스탬프와 현재 타임스탬프 간의 차이를 확인합니다. 타임스탬프가 30분 이상이면 새 세션이 시작된 것입니다.

2.2.4 매개변수는 다음과 같이 업데이트됩니다:

• cid 및 client_id는 Stape UserID의 값입니다.
• ga_session_id는 Firestore에서의 ga_session_id 값으로, 이전에 초 단위로 타임스탬프로 설정되었습니다.
• ga_session_number는 Firestore에서의 ga_session_number에 1을 더한 값입니다.
• x-ga-system_properties.ss (세션 시작)는 1로 설정됩니다.
• X-ga-mp2-seg (참여 세션)는 1로 설정됩니다.
• x-ga-system_properties.fv는 제거됩니다.

2.2.5 GA4에 수정된 데이터를 보내세요. GA4로 데이터를 보내기 전에 업데이트하기 위해 변환을 사용합니다. 태그는 GA4 클라이언트가 요청될 때, 동의가 부여되지 않았고, 세션 간 시간 차이가 30분 이상일 때 트리거됩니다.

2.3.1. 분석 쿠키가 허용되지 않을 때, Stape의 User ID 파워업을 사용하여 사용자 ID를 생성합니다.

2.3.2. Firestore에 동일한 UserID를 가진 사용자가 이미 있는지 확인하세요. 동일한 사용자 ID를 가진 사용자가 없으면 Firestore Writer 태그를 사용하여 데이터베이스에 세션 세부 정보가 있는 사용자를 생성하세요.

2.3.3 매개변수는 다음과 같이 업데이트됩니다:

• cid 및 client_id는 Stape UserID의 값입니다.
• ga_session_id는 Firebase에서의 ga_session_id입니다.
• ga_session_number는 Firestore에서의 ga_session_number입니다.
• x-ga-system_properties.ss (세션 시작)는 1로 설정됩니다.
• x-ga-mp2-seg (참여 세션)는 1로 설정됩니다.
• x-ga-system_properties.fv (첫 방문)는 1로 설정됩니다.

2.3.4 GA4에 수정된 데이터를 보내세요.

서버 Google Tag Manager를 통한 쿠키 없는 Google Analytics 4 추적을 구현하는 것은 온라인 데이터 개인정보 보호 및 사용자 선호도의 변화에 적응하는 중요한 진전을 나타냅니다. 디지털 세계가 발전함에 따라 쿠키에 의존하지 않고 중요한 인사이트를 얻는 것이 필수적이 됩니다.

서버 측 추적과 Google Tag Manager의 능력을 활용함으로써 기업들은 데이터 개인정보 보호에 대한 그들의 약속을 유지하면서도 GA4가 제공하는 중요한 데이터 기반 인사이트를 활용할 수 있습니다. 이 접근 방식은 신흥 규제에 대한 준수를 보장할 뿐만 아니라 온라인 개인정보에 대해 우려하는 사용자들과의 신뢰를 구축하는 데에도 도움이 됩니다. 쿠키 없는 미래를 탐색하면서 서버 측 추적과 GA4와 같은 혁신적인 솔루션을 채택함으로써 기업들은 디지털 경쟁력과 관련성을 유지할 수 있습니다.