[GA4] bigquery에 연결한 GA4 데이터는 어떤 모습일까

삽질에 삽질을 거듭하고 있는 모습.. 사실 그냥 계속 쿼리를 두들기는게 맞다고 본다

빅쿼리 기반의 GA4, 낯설지만 재밌다

구글 애널리틱스는 2023년 UA 버전을 떠나게 되면서 GA4라는 새로운 모습으로 거듭나게 된다. 어떻게보면 강제로 일어나는 이벤트인데, 현재까지도 수많은 마케터/기획자/퍼블리셔 등 그동안 세션 중심의 UA가 익숙한 유저들은 GA4의 모습이 상당히 낯설지 않을까 싶다. 아마 이 변화를 받아들이기 위해서는 빅쿼리를 선 연결해서 미친듯이 쿼리 에러를 일으켜야 한다고 생각한다. 왜냐하면 빅쿼리 안에 쌓이는 데이터가 곧 GA4 대시보드의 기반이 되는 데이터이며, 쿼리는 그 데이터를 다루는 가장 강력한 언어이기 때문이라 본다. 

events_와 events_intraday_는 빈도의 설정에 의해 만들어진다

GA4 계정에서 빅쿼리로 연결하는 절차는 지극히 간단하며, 설명이 자세한 곳이 굉장히 많다. (구글이 불친절상냥하게 도움말까지 준다. 꾺끌이쪠꺠딸을떄또됐짜나또움말싺따빠꿔쪼요 love you google. ^^)
GCP 내부에서 특정 프로젝트를 생성해서 그 안에 데이터 세트로 제공이 될 수 있도록 진행하면 되며, 이 안에는 두가지 타입의 테이블이 형성될 수 있다. 바로, events_ 형태와 events_intraday_ 형태. 

설정 - 빅쿼리 연결 - 빈도 부분에서 매일과 스트리밍 두가지를 체크했다면, 연결된 데이터 세트 아래에 두가지 테이블이 생성된다.

events_에는 매일 데이터가 내보내기 되고, intraday에는 구글 said '최선의 노력으로 실행된 작업' 이며 하루종일 계속 이벤트가 쌓인다고 한다. 
모든 timezone 에서 동일한지는 모르겠으나 한국 기준 현재 일자가 11/19 일때 11/17까지 데일리 데이터가 샤딩 테이블 형태로 적재되며, intraday에는 18~19일 데이터가 쌓여있게 된다. 만약에 스트리밍은 체크 없이 '매일'만 체크한다면 11/17까지의 데이터를 빅쿼리에서 볼 수 있을 것이다. 따라서, 이벤트 발생량을 감당할 수 있다면 스트리밍도 같이 체크해주는 것이 베스트일 것이다. 나같은 경우 회사 내에 고객 이벤트를 담는 DB가 없어 부서의 의사결정 용도로 전일자 데이터 이벤트를 조회하거나 순매출 계산식을 짰었다보니 더 필요했기도 하다.

 

쿼리 작성 이전에 스키마 부터, 스키마 이전에 데이터부터

위와 같이 테이블을 봤다면 웹 콘솔에서 테이블 세부 정보에 스키마를 보게 되는데, 이 스키마에 대한 정의는 외국 사이트인 measurelab에서 매우 fancy한 형태로 제공해주고 있다. 심지어 UA 버전도 있다. 초반에 정말 많은 도움이 되었다. 최고 최고!! 

지금 펼쳐놓은 event_params가 내가 가장 많이 관여하게 될 컬럼이라 볼 수 있을 것이다. 사실상 이벤트 관련 세부 정보가 여기 들어가 있기 때문인데, 세 가지를 알아야 한다. unnest, key, value. 일단 데이터 자체는 key와 value 로 나눠져서 어떤 이벤트명을 찾을때에는 반드시 key에 대한 고민을 하고, value에 뭐가 와야 하는지를 보아야 한다. 예를 들어 이런 식이다. 

 select user_pseudo_id
 , FORMAT_TIMESTAMP('%Y-%m-%d',TIMESTAMP_ADD(TIMESTAMP_MICROS(event_timestamp), INTERVAL 9 hour)) as date
 , (select value.string_value from unnest(event_params) where event_name = 'purchase' and key = 'transaction_id') as order_id
 , (select value.int_value from unnest(event_params) where event_name = 'purchase' and key = 'value') as revenue
  from `{내 테이블}`, date_range
  where stream_id = '{내 데이터 스트림}'
  and event_name = 'purchase'
  and _table_suffix between current_day and current_day

 

event_params는 nested 구조로 되어있고 이로 인해 key를 검색하는 방식 또한 다소 복잡하다. (이건 나중에 시간이 나면 포스팅을 하는 방향으로..) 위 쿼리가 정답이라곤 할 수 없겠지만 적어도 내가 원하는 이벤트의 특정 값을 export 하는데에는 문제가 없다.

 

다만 위에서 말하는 event_name이 뭐가 되어야 하는지, value가 어떤 값으로 오는지는 전부 쿼리를 쓰는 내가 먼저 알아두어야 한다. 만약 내가 찾는 값이 int가 아니라 string으로 지정되어서 수집이 설계되어 있다면 쿼리는 분명히 달라져야 할 것이다. 이게 아니더라도 이벤트명이 헷갈리는게 굉장히 많고, 컬럼명 또한 user_id 와 user_pseudo_id 의 차이를 분명하게 알고 집계를 시작해야 할 것이다(이건 이후 글에서 작성). 따라서 스키마를 보면서 특정 유저의 데이터를 계속 보고, value들을 음미하면서 마치 광산에 들어가서 보석캐는 사람처럼 호시탐탐 노려야(?) 하지 않을까 싶다. 

복병은 테이블 조회가 아니라 테이블 만료

(이 직업에서 가장 무서운건 아마... 데이터 유실이 아닐까? 물론 나도 알고싶지 않았다..)

기본 빅쿼리 세팅에 의하면 GA4와의 연결은 매우 편리하게 되어있지만, 기본 세팅은 '테이블은 60일 지나면 삭제'이다. 이건 사실 빅쿼리 샌드박스의 정책이며, 신경쓰지 않을 경우 위에서 본 테이블이 계속 events(60)으로 멈추게 되는 현상을 볼 수 있을 것이다.

이 부분은 지혜의 도시 다차타에서 능력자분의 댓글 코멘트를 참고하면 테이블 만기일을 해제할 수 있고, 이건 선택이 아닌 필수 사항이다. 미리미리 확인해서 테이블이 사라지는 공포를 겪지 않도록 하자.