Google 애널리틱스 UI와 BigQuery 내보내기 간의 격차 줄이기

민하즈 카지, Google 애널리틱스 Developer Advocate, 2023년 4월

"그런데 수치가 UI와 일치하지 않는 이유는 무엇인가요?"

GA4 속성에 필요한 BigQuery 이벤트 내보내기 데이터로 작업해 봤다면 이런 질문을 한 경험이 있을 것입니다. 오히려 다른 사람에게 이런 질문을 받았던 난감했던 순간도 있었을 것이고요. 질문에 대답하려고 애쓰고 있는데 더욱 두려운 후속 질문이 이어졌을 겁니다.

"그리고 어디에 그런 내용이 표시되나요?"

이 도움말에서는 위 두 가지 질문에 대해 알아봅니다.

수치가 왜 다른지 자세히 들여다 보기 전에 BigQuery 이벤트 내보내기 데이터의 목적을 이해하는 것이 중요합니다. Google 애널리틱스 사용자는 수집 방법(Google 태그, Google 태그 관리자, 측정 프로토콜, SDK, 데이터 가져오기) 중 하나를 통해 수집된 데이터를 GA로 전송합니다. Google 애널리틱스는 GA 속성의 설정을 기반으로, 수집된 데이터가 표준 보고서, 탐색 분석, Data API 등의 표준 보고 도구에 도달하기 전에 유의미한 가치를 부여합니다. Google 신호 데이터 포함, 모델링, 트래픽 기여 분석, 예측 등이 이러한 가치 부여 과정에 포함될 수 있습니다.

표준 보고 도구는 가장 낮은 마찰로 가장 높은 값을 GA 사용자에게 제공하는 것을 목표로 합니다. 그러나 사용자를 넓은 범위로 보자면 Google 애널리틱스에서 가치 부여를 보완해 주기를 원하거나 심지어 완전히 맞춤설정된 결과물을 제공해 주기를 원하는 사용자가 있을 수 있습니다. BigQuery 이벤트 내보내기는 바로 이런 사용자가 출발점으로 삼을 수 있도록 설계된 기능입니다. BigQuery 이벤트 내보내기에는 클라이언트 또는 앱에서 Google 애널리틱스로 전송되는 수집된 데이터가 포함되어 있습니다. 위에서 언급한 대부분의 가치 부여에 관한 상세 데이터는 포함되지 않습니다.

따라서 많은 사용 사례의 경우 표준 보고 도구와 BigQuery 내보내기 데이터는 이러한 가치 부여 부분과 관련하여 조정이 불가능할 것으로 예상됩니다. 그렇더라도 내부적으로 둘 사이에 일관성이 있고 수집 중인 데이터와 일치한다면 계속 작업을 진행해도 괜찮습니다.

이제 차이가 발생하는 구체적인 이유를 살펴보고 가능한 경우 이를 줄이는 방법을 알아보겠습니다. 이 문서에서는 스트리밍 내보내기가 아닌 BigQuery 일별 이벤트 내보내기만 다룹니다.

샘플링

BigQuery 내보내기 데이터를 표준 보고서, Data API 보고서 또는 탐색 분석 보고서와 정확하게 비교하려면 이러한 보고서가 샘플링된 데이터를 기반으로 생성된 보고서가 아니어야 합니다. 여기에 관한 자세한 정보와 샘플링을 처리하는 방법은 GA4의 데이터 샘플링을 참고하세요.

활성 사용자

GA4 속성에서 이벤트를 하나 이상 로깅한 모든 사용자를 집계하는 경우 총 사용자 측정항목이 표시됩니다. GA4 UI의 탐색 분석에서도 총 사용자 측정항목을 사용할 수 있기는 하지만 GA4의 보고에 사용되는 기본 사용자 측정항목은 활성 사용자입니다. GA4 UI 및 보고서에서 사용자라고만 언급된 경우에는 일반적으로 활성 사용자를 가리킵니다. 따라서 BigQuery 데이터에서 사용자 수를 계산할 때는 숫자를 GA UI와 비교할 수 있도록 활성 사용자만 필터링해서 유지해야 합니다. 계산 방법은 선택한 보고 ID에 따라 달라집니다.

기술적 구현

BigQuery 이벤트 내보내기 데이터에서 고유한 User-ID 수를 집계하면 총 사용자 수가 나옵니다. 다음은 user_pseudo_id를 기반으로 총 사용자 수와 신규 사용자 수를 보여주는 샘플 쿼리입니다.

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

활성 사용자만 선택하려면 is_active_user가 true인 이벤트로 쿼리를 제한하세요.

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

HyperLogLog++

Google 애널리틱스는 HyperLogLog++(HLL++) 알고리즘을 사용하여 활성 사용자와 세션을 포함한 일반적인 측정항목의 카디널리티를 예측합니다. 즉, UI 또는 API를 통해 이러한 측정항목의 고유한 수치가 표시된다면 이는 특정 정밀도로 산출한 근사치입니다. BigQuery에서는 상세 데이터에 액세스할 수 있기 때문에 이러한 측정항목의 정확한 카디널리티를 계산할 수 있습니다. 따라서 둘 사이의 측정항목이 근소한 차이로 다를 수 있습니다. 95% 신뢰 구간에서 세션수의 정밀도는 ±1.63%일 수 있습니다. 정밀도 수준은 측정항목에 따라 다르며 신뢰 구간에 따라 변경됩니다. HLL++의 정밀도 매개변수에 따른 다양한 신뢰 구간의 정밀도 수준은 HLL++ 스케치를 참고하세요.

기술적 구현

Google 애널리틱스에서 HLL++를 구현하는 방법과 BigQuery 쿼리를 사용하여 이 기능을 복제하는 방법은 Google 애널리틱스의 순 집계 근사치를 참고하세요.

데이터 수집 지연

GA에서 당일의 모든 이벤트가 수집되면 일일 내보내기 테이블이 생성됩니다. 일일 테이블은 테이블 생성 날짜 이후 최대 72시간까지 테이블 생성일 타임스탬프가 찍힌 이벤트를 포함할 수 있습니다. 이와 관련한 세부정보 및 예를 참고하세요. 데이터 수집 지연은 Firebase SDK 또는 측정 프로토콜 구현이 오프라인 이벤트 또는 지연된 이벤트를 전송하는 경우의 문제에 더 가깝습니다. 표준 보고 도구와 BigQuery가 앞서 언급한 72시간 동안에 업데이트되는 시점에 따라 차이가 발생할 수 있습니다. 이러한 구현의 경우 72시간 이전의 데이터를 비교해야 합니다.

카디널리티가 높은 보고서

표준 보고서 또는 Data API를 통해 보고서를 조회한다고 가정하겠습니다. 이 보고서는 다량의 데이터를 표시하고 카디널리티가 높은 측정기준을 사용합니다. 측정기준의 카디널리티가 높은 경우 보고서가 기본 테이블의 카디널리티 한도를 초과할 수 있습니다. 이 경우 Google 애널리틱스에서는 빈도가 낮은 값을 그룹화하여 (기타)라는 라벨을 지정합니다.

데이터 양이 적은 단순화된 예를 보자면, 기본 테이블의 카디널리티 한도가 10행인 경우 다음과 같이 표시될 수 있습니다.

실측 정보 데이터와 기타 행이 있는 총괄 표를 단순화하여 보여주는 예

보다시피 총 이벤트 수는 변경되지 않습니다. 하지만 빈도가 낮은 값은 함께 그룹화되므로 측정기준을 기반으로 표를 다시 집계할 수 없습니다(예: 총괄 표를 토대로 정밀도가 높은 특정 도시에 대한 총 이벤트 수를 산출할 수 없음). 측정기준을 기반으로 합산 데이터를 필터링하면 위 예시가 더 복잡해집니다.

이 (기타) 행 그룹은 보고 모듈과 Data API에서 보고서가 카디널리티 한도를 초과할 때만 표시됩니다. BigQuery에서 계산하면 항상 실측 값 데이터, 즉 가장 상세한 데이터가 포함된 행이 생성됩니다. (기타) 행 및 이를 피하는 방법에 관한 권장사항을 자세히 알아보세요.

Google 신호 데이터

GA4 속성에서 Google 신호 데이터를 활성화하면 여러 플랫폼과 기기에서 중복 사용자가 삭제되는 등의 이점이 있습니다. User-ID와 Google 신호 데이터가 구현되지 않았다고 가정할 때, 사용자가 세 가지 웹브라우저에서 웹사이트를 보는 경우 Google 애널리틱스는 이 사용자를 세 명의 다른 사용자로 집계하고 BigQuery 내보내기에는 세 개의 user_pseudo_id가 포함됩니다. 하지만 Google 신호 데이터가 활성화된 상태에서 이 사용자가 세 가지 브라우저에서 단일 Google 계정으로 로그인하면 Google 애널리틱스는 이를 중복 사용자로 간주하여 표준 보고 도구에 중복 삭제된 수를 표시합니다. 하지만 BigQuery에는 여전히 세 개의 user_pseudo_id가 표시됩니다. BigQuery 내보내기에서는 Google 신호 데이터 정보를 사용할 수 없습니다. 따라서 Google 신호 데이터가 반영된 보고서는 BigQuery 내보내기에 비해 사용자 수가 더 적을 가능성이 큽니다.

이 차이를 줄이는 가장 좋은 방법은 GA4 속성에서 User-ID를 구현할 때 Google 신호 데이터도 함께 활성화하는 것입니다. 이렇게 하면 먼저 user_id에 따라 중복이 삭제됩니다. 로그인한 사용자의 경우 user_id 필드가 BigQuery에 입력되며 계산 목적으로 사용할 수 있습니다. 하지만 로그인하지 않은 사용자(예: user_id가 없는 세션)의 경우에도 Google 신호 데이터가 중복 삭제에 사용됩니다.

또한 표준 보고 도구의 특정 보고서에 기준점이 적용되어 특정 데이터가 반환되지 않을 수 있습니다. 일반적으로 임곗값이 적용될 수 있는 대부분의 정보는 BigQuery 내보내기에 사용할 수 없습니다.

동의 모드 및 모델링된 데이터

웹사이트 및 모바일 앱의 동의 모드를 사용하면 사용자의 쿠키 또는 앱 식별자 동의 상태를 Google에 알릴 수 있습니다. 방문자가 동의를 거부하면 GA4는 전환 모델링 및 행동 모델링으로 데이터 수집 공백을 채웁니다. 모델링된 데이터는 BigQuery 이벤트 내보내기에서 사용할 수 없습니다. 동의 모드가 구현되면 BigQuery 데이터 세트에 GA에서 수집한 쿠키 없는 핑이 포함되며 세션에는 각기 다른 user_pseudo_id가 포함됩니다. 모델링으로 인해 표준 보고 도구의 데이터와 BigQuery의 상세 데이터에는 차이가 있습니다. 예를 들어 행동 모델링은 동의하지 않은 개별 사용자의 여러 세션을 예측하려고 할 수 있기 때문에 BigQuery 내보내기에 비해 활성 사용자 수가 적을 수 있습니다.

앞서 언급했듯이 이러한 차이를 줄이려면 GA4 속성에서 User-ID를 구현해야 합니다. user_id 및 맞춤 측정기준은 사용자의 동의 여부와 관계없이 BigQuery로 내보내집니다.

트래픽 기여 분석 데이터

BigQuery에서 트래픽 기여 분석 데이터는 사용자(첫 방문) 및 이벤트 수준에서 사용할 수 있습니다. 이는 수집된 데이터입니다. 하지만 Google 애널리틱스는 세션 수준에서 자체 기여 분석 모델을 구현하므로 이 정보는 BigQuery 내보내기에 직접 사용할 수 없고 제공된 데이터를 가지고 정확하게 계산할 수도 없습니다. 사용 사례에 따라 BigQuery 데이터 세트를 관련 퍼스트 파티 데이터와 결합하고 자체 기여 분석 모델을 빌드할 수도 있습니다. 앞으로는 트래픽 기여 분석을 위해 수집된 추가 데이터가 BigQuery 이벤트 내보내기를 통해 제공될 수 있습니다.

일반적인 계산 오류

계산 방법: BigQuery에서 여러 가지 측정항목을 계산할 때는 올바른 방법을 사용해야 합니다. 예를 들면 다음과 같습니다.
- Google 애널리틱스 4 속성의 세션을 집계하는 표준 방법은 기간에 관계없이 user_pseudo_id/user_id 및 ga_session_id의 고유한 조합을 집계하는 것입니다. 유니버설 애널리틱스에서는 자정에 세션이 재설정되지만, UA 모델에 따라 각 날짜의 세션을 계산하고 합산하여 총 세션수를 얻는 경우 여러 날에 걸쳐 있는 세션이 중복으로 집계됩니다.
- 선택한 보고 ID에 따라 사용자 수 계산 방법을 업데이트해야 합니다.
측정기준 및 측정항목 범위: 계산할 때 올바른 사용자, 세션, 항목 또는 이벤트 수준 범위를 사용해야 합니다.
시간대: BigQuery 내보내기에서 event_date는 보고 시간대이고 event_timestamp는 마이크로초 단위의 UTC 타임스탬프입니다. 따라서 쿼리에서 event_timestamp를 사용하는 경우 UI 번호와 비교할 때 올바른 보고 시간대로 조정해야 합니다.
데이터 필터링 및 내보내기 한도: BigQuery 이벤트 내보내기에 데이터 필터링을 설정했거나 일별 이벤트 내보내기 볼륨이 한도를 초과한 경우 BigQuery 이벤트 내보내기 데이터는 표준 보고 도구와 일치하지 않습니다.

지금까지 Google 애널리틱스 UI와 BigQuery 내보내기 데이터가 일치하지 않는 이유에 대해 살펴보았습니다. 이 가이드라인을 토대로 진행 중인 프로젝트에 적합한 솔루션을 찾을 수 있기를 바랍니다. 궁금한 점이 있으면 GA Discord 서버를 방문하여 문의해 주세요. 질문은 언제나 환영입니다.