GA4의 세션수가 맞지 않는 이유
이제 '세션'을 다르게 이해해야 합니다
GA4와 GA3(UA)의 세션은 다르게 집계됩니다
기존부터 구글 애널리틱스를 이용하던 분들이라면 세션(Session) 단위의 분석에 익숙할 것입니다. 세션은 ‘방문’과 비슷한 의미로 사용되는 구글 애널리틱스의 주된 측정항목입니다. 기본 트래픽 보고부터 ‘유입(A)-행동(B)-전환(C)’으로 이루어지는 퍼널 분석에서도 ‘세션’은 기본 단위로 활용되어 왔습니다.
세션은 특히 ‘소스-매체-캠페인-콘텐츠’ 등 유입경로를 상세하게 볼 수 있는 ‘UTM 파라미터’와 같이 묶어서 볼 때 더 유용하게 사용할 수 있습니다. 어떤 외부 채널에서 우리 사이트로 방문했는지, 어떤 광고가 더 성과가 좋은지 파악하는 것만으로도 개선할 수 있는 부분들이 많았죠.
세션은 우리가 분석을 하는 과정에서 그 의미를 쉽게 파악할 수 있는 가장 직관적인 단위이자, 구글 애널리틱스 분석 관점의 토대라고 볼 수 있었습니다. 그러나 신규 버전인 GA4부터는 세션의 집계 방식이 바뀌었고, 보고서에 기본적으로 적용되는 데이터 처리방식도 달라지게 되었습니다. 바뀐 개념에 대해 파악하는 것과 더불어 새 방식에 맞는 분석 관점의 변화도 필요해진 시점입니다.
그로스해킹스쿨 → https://bit.ly/49Qt5pP
- 더 많은 그로스 해킹 전략과 사례를 확인할 수 있습니다
- 데이터 분석과 활용에 대한 고민이 있다면 문의를 남겨 주세요.
요약
GA4에서 ‘방문’을 뜻하는 ‘세션수’는 추산치로 제공됩니다. 각 서비스의 환경에 따라 오차범위가 커질 수 있으니 사전에 확인하는 작업이 필요합니다.
GA4의 ‘세션수’에는 우리가 확인할 수 없는 환경에서 사용자가 방문한 데이터도 포함이 되어 있습니다. 비록 ‘추산치’일지라도 구글에서 보정을 해주기 때문에 오히려 정확한 방문 수를 파악할 때는 더 유용하게 사용할 수 있을 것입니다. 방대한 빅데이터와 머신러닝으로 데이터 보정이 가능한 구글 애널리틱스만의 장점입니다.
오차범위를 확인하고 수정하기 위한 접근 방법으로는 ‘session_start’ 이벤트 발생 수와 비교, 원시 데이터인 BigQuery 데이터와의 비교가 있습니다.
앞으로 ‘세션’ 단위의 분석 보다는 ‘사용자’ 단위의 분석이 더 중요해질 것 같습니다.
GA4 세션 이슈 체크
이론적으로 바뀐 개념을 살펴보기 전에 실무에서 자주 겪는 이슈를 먼저 확인해보겠습니다. GA4 보고서에서 데이터를 조회하면 아래 사진과 같이 유입 채널별로 세션수가 표기 되는 것을 확인할 수 있습니다.
각 채널별 세션수와 더불어 총계는 13,587회인 것을 확인할 수 있습니다. 여기까지는 기존 버전인 GA3(UA)버전과 다를 것이 없습니다. 그러나 각 행을 더한 총합은 표기되는 총계와 일치하지 않는 것을 확인할 수 있습니다. 각 행을 합산했을 때는 ‘총 세션수’가 13,678회이지만 보고서에 표기되는 총계는 13,587회로 약 91회의 차이가 발생합니다.
HyperLogLog++ 알고리즘과 데이터 기준점 적용
결론부터 이야기하자면 GA4에서는 데이터 조회 속도를 향상 시키고 데이터 처리 리소스를 절약하기 위해서 ‘HyperLogLog++’라는 특정한 계산 알고리즘을 적용하고 있습니다. 100% 정확한 데이터를 제공하는 대신에, 오차범위 이내에서 추산치를 빠르게 제공하는 관점을 택한 것이죠. 위 자료를 기준으로 보면 총계로 제시하는 값과 각 행을 더한 값은 약 0.665%의 오차를 보이고 있습니다. 금융, 의료분야와 비교했을 때 마케팅 분야가 허용할 수 있는 오차범위가 더 크고, 이 정도 수준의 오차범위는 결정에 큰 영향을 미치지 않을 것이라는 것을 고려한다면 이해하고 넘어갈 수 있는 수치입니다.
그런데 여기에 또 하나 데이터가 일치하지 않도록 하는 요인이 있습니다. 데이터 기준점(Data Thresholds, ‘임계점’이라고도 부름)의 적용 여부입니다. GA4는 세계적인 개인정보 보호 흐름의 추세에서 출시된 만큼, 개별 사용자를 추론할 가능성이 있는 데이터를 보여주지 않습니다. 조회 기간 내 데이터가 적은 경우나 특정 검색어 정보가 포함이 될 경우 해당 행이 보고서에 표기되지 않을 수 있습니다.
원시 데이터(Raw Data) 활용을 위한 BigQuery
GA4의 표준 보고서에서는 여러 설정에 따라 처리된 결과를 제공합니다. 추산치/기준점이 적용되지 않은 데이터를 확인하기 위해서는 원시 데이터를 저장하여 처리할 수 있는 BigQuery 연동이 필요합니다.
여기까지의 내용만으로도 구글애널리틱스를 이용하는 우리에게는 2가지 관점 변화가 요구됩니다.
마케팅 데이터는 100% 정확한 데이터보다 빠르게 인사이트를 얻어 활용하는 것이 더 중요하다. 작은 오차범위에 익숙해져라.
서비스 특성상 높은 정확성이 요구된다면 원시데이터(Raw Data)를 활용할 수 있는 구글의 클라우드 제품인 BigQuery와 GA4를 연결해서 직접 데이터를 조회해라
GA4의 사용 목적과 비즈니스 특성에 맞춰 준비해야 할 사항이 하나 더 생겨났습니다. 앞으로 GA4를 사용하는 과정에서는 BigQuery 적용 여부와 더불어 원시 데이터를 기반으로 데이터를 조회-가공-시각화를 할 수 있는 역량이 요구됩니다.
GA4에서 보이는 ‘오차’는 사용자의 데이터를 광고/마케팅 분석에 직접 사용할 수 있게 하면서, 개인 사용자 추론을 어렵도록 고안한 것이라 볼 수 있습니다.
GA4 세션의 의미
오차범위를 보다 정확하게 파악하려면 GA4의 세션에 대한 개념과 ‘이벤트 기반 지표’에 대한 이해가 필요합니다. 이미 GA4를 사용하는 분들이라면 GA4의 데이터가 ‘이벤트 기반’으로 바뀌었다는 말을 들어보셨을 것입니다. 각각의 상호작용이 ‘이벤트’로 보고 된다고 하는데, 보다 정확한 의미는 무엇일까요?
기존 버전(GA3, UA)에서는 세션 내에서 어떤 이벤트가 몇 번 발생했는지를 기준으로 분석했습니다. 이벤트는 세션에 종속된 개념이었죠. GA4에서는 모든 사용자의 행동을 병렬적인 ‘이벤트’로 기록합니다. GA4의 ‘세션’ 또한 이 이벤트를 기반으로 계산하여 처리된 지표입니다.
GA4에서 세션을 집계하는 방식
세션이 시작되면 ‘session_start’라는 이름의 이벤트가 발생하고, 해당 이벤트의 매개변수인 ‘ga_session_id’의 고유 값이 생성됩니다. 얼핏 생각하면 ‘session_start 이벤트 발생 수’가 곧 ‘세션수’가 되는 것 같이 느껴지지만, 실제 세션 집계 방식은 이벤트 발생 수가 아닌, ‘ga_session_id’의 고유한 값을 ‘추정’한 값이 사용됩니다. 고유한 세션 ID를 모두 계산하는 것이 리소스 낭비가 되기 때문에, 앞서 설명한 HyperLogLog++ 알고리즘을 적용하여 추산한 값을 제공해 주는 것이죠.
조회의 편의를 위해 ‘세션’이라는 별도의 지표로 표현을 해주기는 하지만, 결국은 ‘이벤트’를 기준으로 처리된 지표라는 것이 중요합니다. ‘세션’이라는 지표 자체가 추정 값이기 때문에 데이터 수집 과정에서 ‘세션 100% 일치’를 기대할 수가 없게 되었습니다.
보다 정확한 지표를 활용하려면 좀 더 원론적인 의미로 접근이 필요하겠죠. 데이터 정합성을 확인하기 위해 우리는 어떤 과정을 거쳐야 할까요?
이 또한 2가지 방식이 있습니다.
고유한 ‘ga_session_id’의 수를 구하기
session_start 이벤트 발생 수를 기준 지표로 활용하기
원론적인 의미를 고려한다면 ‘고유한 session_id 값’을 구하여 비교하는 것이 맞습니다. BigQuery에서도 추정 값인 ‘세션수’ 외에 정확한 값을 구하는 별도의 옵션을 제공하고 있습니다. 하지만 모든 값을 확인하여 고유 수를 확인한다는 것은 상당한 리소스를 필요로 합니다. 특정한 목적이 있지 않는 한, 상시적으로 적용하기는 어려운 방법이죠. (원시 데이터에는 Google Signal 등을 통해 보정된 데이터가 포함 되어 있지 않다는 점도 고려해야 합니다.)
리소스를 고려한다면 우리가 데이터를 일상적으로 이용하기 위해서는 결국 1가지의 선택지만 남게 됩니다.
‘session_start’ 이벤트 발생 수 파악하기.
‘ga_session_id’의 값이 ‘session_start’로 인해 생성되는 것이기 때문에, 개념적으로는 ‘session_start’ 이벤트 발생 수를 ‘세션수’와 비슷한 의미로 활용할 수 있을 것입니다. 그러나.. 여기서 끝나면 정말 좋겠지만 또 다른 문제가 발생합니다. 데이터를 조회해 보면 ‘session_start’ 이벤트 발생 수와 ‘세션수’가 오차범위를 초과하여 보고 되는 문제가 생깁니다.
과연 무시할 수 있는 오차 범위일까?
채널별로 오차가 더 커지는 환경이 있습니다. 어떤 경우에 오차가 더 커지는지, 그 비율이 어떤지 알아야 기준점을 잡아 활용할 수 있을 것입니다. 검증을 위해 아래와 같이 데이터를 조회해 보도록 하겠습니다.
세션 시작 이벤트가 없는 세션
GA4의 세션에 세그먼트를 적용하여 비교
'session_start' 이벤트가 발생한 세션
'session_start' 이벤트가 발생하지 않은 세션
놀랍게도 ‘session_start 이벤트가 발생하지 않은 세션’이 예상한 오차범위를 초과한 비율(약 3.26%)로 표기되고 있습니다. 채널별로 나눠서 보면 전체 세션에서 ‘session_start 이벤트가 발생하지 않은 세션’의 비율은 Unassigned 채널 약 19.43%(�), Organic Search 채널 약 0.93%, Direct 채널은 약 2.67%의 오차율을 보이고 있습니다.
Organic Search 채널에서 보이는 오차율(0.93%)은 넘어갈 수 있는 수준이기는 합니다. 원인을 살펴보기 위해 다른 측정 기준을 적용했더니 발생하는 오차의 약 90%에 해당하는 비율은 네이버에서 운영하고 있는 ‘Whale Browser’를 통한 유입인 것을 확인할 수 있었습니다.
가장 많은 오차를 보이고 있는 Unassigned 채널도 살펴보겠습니다. 일단 Unassigned 채널은 구글 애널리틱스에서 분류한 ‘사전 채널 기준에 해당하지 않는 경우’를 뜻합니다. 유입경로가 유실 되었거나, 표준 채널 분류 규칙에 해당하지 않는 UTM을 사용했을 때 Unassigned 채널로 분류됩니다.
Unassigned 채널에서도 특히 유입경로가 유실된 케이스라고 볼 수 있는, 소스/매체가 (not set)인 경우는 전부 session_start 이벤트가 발생하지 않았습니다.
그래서 어떻게 해야할까? – ‘추산치’이지만 더 정확한 지표인 ‘세션수’
데이터를 나눠볼수록 오차가 발생하는 원인을 찾기 더 어렵습니다. GA4 의무 사용 초창기이기 때문에 오차가 발생하는 모든 케이스를 정리하기는 아직 어려울 것 같습니다. 현재까지 찾은 규칙과 생각해볼 수 있는 가설은 아래와 같습니다.
1.’세션수’에는 추적을 할 수 없는 환경의 데이터도 포함이 되어 있다. (확인)
GA4에는 쿠키 활용에 동의하지 않은 사용자의 데이터를 모델링하는 여러 머신러닝 기능이 적용되어 있습니다. 쿠키를 거부하는 사용자의 행동을 추정하여 데이터를 보정해줍니다.
애드블락(Adblock) 혹은 네트워크 환경과 같은 기술적 이유로 session_start 이벤트가 정상적으로 발생하지 않아도 세션수를 집계할 수 있습니다. (사례에서는 Whale Browser 사용자들이 애드블락을 사용하고 있을 것으로 예상)
또한 구글 애널리틱스의 세션은 고유한 ‘세션 ID의 수’라는 것도 인지를 해야 합니다. 기술적인 이유로 session_start 이벤트가 발생하지 않아도, 다른 이벤트에서 ‘고유한 세션 ID’를 확인할 수 있다면 세션수로 보고를 할 수 있습니다.
2.보정이 더 용이한 환경에서는 더 낮은 오차율을 보인다. (가설)
‘Organic Search’ 채널은 별도의 UTM을 사용하지 않아도, 주요 검색 엔진을 통한 유입이면 알아서 분류를 해주고 있습니다. 이 경우 이전 사이트의 도메인과 HTTP 리퍼러 정보만 있어도 해당 채널을 통한 유입을 확인할 수 있을 것입니다.
Google Signal 기능을 통해 크롬 브라우저 사용자 등(구글 계정에 사이트 방문 기록이 저장됨) 추후 보정할 수 있는 데이터가 세션 수에 같이 집계 되는 것 같습니다. (데이터 보정이 더 용이한 환경)
자료로 보여드린 데이터에서 Unassigned 채널로 분류된 유입에는 UTM을 표준 규칙에 따라 사용하지 않은 경우의 데이터가 다수 포함 되어 있습니다. 잘못된 UTM 활용 및 교차 도메인 설정은 세션 수에 영향을 줄 수 있습니다.
(*자료를 제공해주신 고객사와는 잘못된 데이터 수집 환경을 바로 잡는 작업을 진행하고 있습니다. 해당 환경을 바로 잡은 뒤 오차율이 줄어드는지도 확인해볼 사항입니다.)
어떤 지표를 기준점으로 잡아야 할까?
‘세션수’에는 우리가 확인할 수 없는 환경에서 사용자가 방문한 데이터도 포함이 되어 있습니다. 비록 ‘추산치’일지라도 구글에서 보정을 해주기 때문에 오히려 정확한 방문 수를 파악할 때는 더 유용하게 사용할 수 있을 것입니다. 방대한 빅데이터와 머신러닝으로 데이터 보정이 가능한 구글 애널리틱스만의 장점이라고도 볼 수 있을 것입니다.
그러나 관점을 바꿔보자면, 우리가 분석의 목적으로 둔 ‘비즈니스 성장’을 위해서라면 정확하게 파악하고 제어할 수 있는 환경이 중요합니다. 사이트의 전체 성과를 더 잘 알 수 있는 것과는 무관하게, 각각의 유입경로별로 어떤 변화를 꾀해야 하는지를 파악하려면 보다 직관적인 지표를 활용해야 합니다. 성과로 잡히기는 하지만 어디에서 발생한 성과인지 정확히 알 수 없다면 활용하기 어려워질테니 말이죠.
제안
현재 단계에서는 ‘세션수’와 ‘session_start 이벤트 발생 수’를 같이 고려해야 한다.
전체 성과를 파악할 때는 ‘세션수’를 활용한다.
채널별, 광고 매체별 등 나눠서 성과를 확인하고 관련 의사 결정을 할 때는 ‘session_start’ 이벤트 발생 수와 비교하여 오차범위를 확인 후에 활용한다.
어떤 경우에 오차율이 더 크게 발생하는지 확인하고 얼마나 신뢰할 수 있는지, 수정 가능한 환경인지 전반적으로 검토하는 과정도 필요합니다.
‘Google Demo 계정의 데이터’는 Unassigned 채널로 분류가 되면서 소스/매체가 (not set)인 경우에만 session_start 이벤트가 발생하지 않았습니다. 그 외 채널에서는 아주 낮은 오차율(추산치의 적용)만을 보이고 있습니다.
사례로 보여드린 고객사의 경우 사용자들이 ‘Whale Browser’를 사용하는 경우와, ‘표준 규칙을 위반한 UTM을 사용하는 경우’에 오차가 더 커졌습니다.
위 고객사와 비슷한 패턴을 가지고 있다면 어떻게 대응해야 할까요?
‘페이지 리퍼러’ 지표와 조합하여 어떤 경로에서 오차가 발생하는지 확인하고 수정 가능한 환경인지 확인한다. (현상 파악) 페이지 이동 과정에서 잘못된 리다이렉트 사용 등 기술적인 문제로 인해 누락 되는 경우가 없는지 확인한다.
예 )우리 서비스에 방문하는 사용자들 중 ‘Whale Browser’를 사용하는 비율이 높아서 데이터 추적이 잘 되지 않는다. Whale Browser의 ‘Adblock’을 사용하는 경우에도 데이터를 추적할 수 있는 환경으로 만든다. 애드 블록을 사용 여부를 체크하여 별도로 기록한다. (보다 정확한 현상 파악) ‘Whale Browser’에서 ‘Adblock’ 기능을 사용하는 경우에도 데이터를 추적할 수 있는 환경으로 만든다. → 서버 측에서 데이터를 수집하도록 GA4 데이터 수집 방식을 변경한다. (적극적 조치) 광고 집행 과정에서 추적이 용이하지 않은 환경을 제외 조건으로 설정한다. (광고 효과 관리를 위한 배제적 조치) Whale Browser 사용자를 별도의 세그먼트로 만들고, 해당 데이터를 분석할 때 유의한다. (유의 – 소극적 조치)
‘페이지 리퍼러’와 조합하면 방문 이전 사이트의 주소를 확인할 수 있습니다.
결론
상시적인 분석에서는 추적할 수 없는 환경까지 고려하여 데이터를 보정해주는 ‘세션수’를 기준점으로 삼는다.
중요한 의사 결정 과정에서는 상세 조회 및 Bigquery 등의 활용을 통해 의사결정에 반영할 데이터만을 분리하는 작업을 거쳐야 한다.
조직마다 오차가 크게 발생하는 케이스는 다를 수 있다. 위 예시와 같이 어떤 경우에 오차가 크게 발생하는지를 살펴보고, 오차를 줄일 수 있는 환경을 찾아 수정 작업을 진행한다.
‘어느 정도의 오차 범위’에 익숙해지는 것과 동시에, 개인정보 보호 추세에 맞게 ‘파악할 수 있는 환경’과 ‘파악하기 어려운 환경’을 나눠서 생각할 필요가 있다.
세션 단위의 분석을 넘어 보다 큰 관점으로 적용할 수 있는, ‘사용자-이벤트’ 단위의 분석 전략을 마련해야 한다. (추후 안내)
사용자 단위의 분석 강화
서비스를 이용할 때 필수로 로그인을 해야 하는 서비스라면 분석의 정확도가 더 높아질 수 있습니다. 정확도와 더불어 분석의 관점도 ‘세션 단위’가 아닌 ‘사용자 단위’로 바뀔 필요가 있겠죠. GA4에서도 이와 같은 분석을 위해 해당 사용자가 어떤 채널로부터 처음 방문하게 되었는지, 재방문(전환) 과정에서 어떤 채널들이 기여했는지를 평가하는 모델을 활용할 수 있습니다.
‘session_start 이벤트가 발생하지 않은 세션’의 원인과 다른 웹사이트에도 공통적으로 발견되는 현상들을 계속 정리해 보려고 합니다. 특정한 설정과 제어 방식을 통해 오차율이 줄어 드는 것을 확인할 수 있다면, 약간의 노력으로 더 정확하고 많은 것들을 볼 수 있을테니까요.
이후 사례가 궁금한 분들은 아래 채널을 추가해 주시기 바랍니다.
그로스해킹스쿨 → https://bit.ly/49Qt5pP
- 더 많은 그로스 해킹 전략과 사례를 확인할 수 있습니다
- 데이터 분석과 활용에 대한 고민이 있다면 문의를 남겨 주세요.
