[사프일기] 🔥 치이이즈 로그 ...🔥를 드디어 마주하다 (1)

안녕안녕 치이이즈 PM 유정입니다 🧀
오늘은 치이이즈를 사이드프로젝트로 돌린지
벌써 어느덧 한 달이 되는 날입니당

아직 치이이즈..를 모른다구요?
그렇다면 치이이즈 구경하러 가기 ✌🏻

고새 큐시즘 인스타에도 올라왔죠 ㅎㅎ

🧀 근황토크

큐시즘 32기를 마무리하고 ! 마지막 학기도 마무리하고 (유예지만) !
상황이 너무 많이 바뀌면서 개인적으로 마음이 싱숭생숭한 상태로
한동안은 굴러가는 것들만 붙잡고 ... 유지하는 상태로 지냈던 것 같습니다람쥐 ..,

그러다 이제 겨우 정신을 차리고 일들을 쳐내기 시작했는데
마주한 ..! 바로바로

정말 Raw 그대로의 유저 로그 데이터!

경외롭구나 ...

보자마자 뇌가 돌기 시작해서, SQL 쿼리 짜고 스케쥴링 하는 거에 심취해서
오늘 앉은 자리 4시간이 바싹 지나갔던 것 같아요.

서비스 기획 일 자체로도 너무! 가끔은 더욱! 즐겁게 하고 있었지만
애초에 기획을 시작했던 것은 데이터 분석가를 꿈꾸는 사람으로서 실 유저 행동 데이터를 받아보고,
의사결정하는 경험을 얻고 싶기 때문이었거든요.

🧀 유지보수 단계에 온 치이이즈

특히나 우리 팀 기획자랑 디자이너가 '왜 이래야 해?'라는 질문을 많이 하는 사람들이라
이때까지 무수한 '굳이 이렇게 해야 해?', '다른 방법은 없어?' 의 자체 검증을 거쳐왔기 때문에

지금 상태에서 무언가를 바꿔야 한다면 사용자가 이유여야 한다-고 생각했어요.
ㅡ 마치 ... 흑백조커를 이길 수 있는 건 컬러조커밖에 없다...

그래서 12월 말부터 지금 1월 20일까지는
새로운 기능을 완전히 디벨롭하거나, 있던 플로우를 완전히 바꾸기보다도
사용자 데이터를 수집할 수 있는 환경 세팅을 위주로 했어요 ! 😎
다들 고생해 준 덕에 이렇게 환경도 세팅이 된 것 같습니다

큐시즘 밋업을 떠나 사이드 프로젝트를 시작하며 정리한 목표(~2/25) 중 일부

크게 1. 큐시즘 멘토링 이후 받았던 피드백에 대한 수정, 2. 로그 수집 환경세팅, 3. 프로모션 위주의 한 달을 보냈어요.
나중에 JIRA 어떻게 사용하고 있는지도 글 써서 남길게요 ㅎㅎ

🧀 이벤트 로그 추적하기

백엔드 쪽에서는 이미 매일매일 로그가 생성되었고
앨범 생성이나 사진 업로드, 다운로드 같은 주요 액션들이 서버 로그로 남아
S3에 적재된 뒤 BigQuery로 바로 확인할 수 있는 상태입니다.

백엔드에 수집을 요청한 이벤트 로그들 종류

프론트 쪽도 마찬가지로 Google Tag Manager를 통해 이벤트를 보내고 있었고,
GA4를 거쳐 BigQuery로 export 되는 구조는 이미 만들어져 있었어요.

다만 실제로 바로 분석을 하고, 보기에 좋은 상태는 아니었어요
프론트 이벤트는 GA4 특성상 하루 단위로 테이블이 나뉘어 쌓이고 있었고,
백엔드 로그는 또 다른 테이블에 있었기에 테이블을 조인하고 붙이기에 번거로웠어요.

이 상태로 계속 가면 분석을 할 때마다 준비 작업부터 반복하게 될 것 같아서,
분석용으로 바로 볼 수 있는 테이블을 하나 따로 만들어두는 게 낫겠다고 판단했었어요.
원본 데이터는 그대로 두고, 프론트 로그를 정리해서
이벤트 단위로 한 줄씩 볼 수 있는 staging 테이블을 만드는 방식을 참조했어요.

CREATE OR REPLACE TABLE `saycheese-484314.analytics_517953491.staging_events_base` AS
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS event_date,
  TIMESTAMP_MICROS(event_timestamp) AS event_ts,
  event_name,

  user_id,
  user_pseudo_id,
  COALESCE(user_id, user_pseudo_id) AS unified_user_key,

  -- session
  (SELECT value.int_value
   FROM UNNEST(event_params)
   WHERE key = 'ga_session_id') AS ga_session_id,

  (SELECT value.int_value
   FROM UNNEST(event_params)
   WHERE key = 'ga_session_number') AS ga_session_number,

  -- page / custom
  (SELECT value.string_value
   FROM UNNEST(event_params)
   WHERE key = 'page_location') AS page_location,

  (SELECT value.string_value
   FROM UNNEST(event_params)
   WHERE key = 'entry_source') AS entry_source,

  -- device / geo
  device.category AS device_category,
  device.operating_system AS operating_system,
  geo.region AS region

FROM `saycheese-484314.analytics_517953491.events_*`
WHERE event_name IN (
  'view_landing',
  'view_login',
  'click_login',
  'complete_login',
  'complete_album_joined'
);

그럼 이제 테이블명을 바꾸지 않고도 같은 쿼리를 계속해서 써서
분석하기 편한 환경이 되겠죠!

이 과정에서 COALESCE를 썼어요
로그인을 하기 전과 후를 기준으로 로그인 전의 유저들은 pseudo_id를 받고,
로그인을 한 뒤에는 user_id가 생기거든요.
(로그인을 하지 않고 이탈한 유저들은 pseudo_id만 있고, user_id가 null이에요.)

user_id, user_key, user_pseudo_id 같은 값들을 하나의 대표 컬럼으로 묶어줬고,
이벤트 이름도 마찬가지로 하나로 정리했었어요.
이렇게 해두니까 이벤트가 어디서 들어왔는지를 크게 신경 쓰지 않아도 바로 쿼리를 시작할 수 있었어요.

🧀 데이터 분석의 시작은 '무엇을 볼지 정하는 것'

애초에 이벤트 수집을 요청한 게 기획자였기에 깔끔하게 시작할 수 있었지만
데이터 풀이 확정된 상황에서도 가장 먼저 해야하는 질문은 '그래서 무엇을 보고 싶은가?'예요.

1. Metadata로 수집된 피쳐를 확인한다 (너무 발산하지 않도록 Anchoring)
2. 확인하고 싶은 문제에 대한 가설을 만든다
3. 가설을 피쳐를 이용해서 표현한다

의 과정이랄까요. 다다익선이 아니거든요.

GA4 raw 테이블에는 생각보다 컬럼이 정말 많았는데,
지금 단계에서 바로 쓰지 않을 정보들은 staging 테이블에서는 아예 제외했었어요.
어차피 확인하고자 했던 가설은 명확했어서, 골라내는 것도 쉬웠던 것 같습니다
(thx to 민서 ..)

🧀 최종 데이터의 모습!

언제 발생했는지, 누가 어떤 행동을 했는지,
어떤 앨범이나 사진과 관련된 이벤트인지 정도만 남기고 나머지는 과감하게 덜어냈어요.
원본은 그대로 남아 있으니까, 나중에 필요해지면 다시 원본을 참조하면 됩니다.

즉, 이때까지 한 걸 정리하자면

1. 이벤트 테이블을 UNION한다 (아래로 길게 늘여 붙인다)
2. 원하는 피쳐를 선택하고 정제한다
   인거죠.

마지막으로 이 정리 과정을 BigQuery의 Scheduled Query로 설정해서
매일 자동으로 돌아가게 만들어두었어요.

이제는 프론트로부터 새 로그가 자정에 들어오면,
새벽 2시에 같은 테이블로 UPDATE가 그때그때 되기 때문에
테이블을 변경할 필요 없이, 같은 쿼리를 통해 매일의 결과를 낼 수 있답니다 :)

다음 글에서는 이 테이블을 기준으로 실제로 퍼널을 어떻게 짜봤는지,
어떤 질문들을 던질 수 있었는지 정리해보려고 해요.
그럼 빠빠이 ~~