GA 트래킹 기획서 (PRD)¶

요지¶

각 기능이 제멋대로 트래킹 코드를 짜면 이벤트 이름이 들쭉날쭉해지고 데이터를 믿을 수 없게 된다. GA 트래킹은 그 바닥을 먼저 까는 일이다 — 이벤트 명명·환경 분리·공통 유틸을 한 번 표준으로 정해 두면, 이후 모든 기능이 그 위에 자기 이벤트만 얹으면 된다. MVP-B 마일스톤(MS2) 기능이다.

목표 & 성공 기준 (지표)¶

사용자 행동 데이터를 모아 퍼널과 기능 사용성을 숫자로 판단할 근거를 마련하는 게 목표다. 잘 됐는지는 핵심 화면 이벤트가 제대로 수집되는지, dev와 prod 데이터가 정확히 갈리는지, DebugView 검증을 통과하는지, 그리고 트래킹이 깨져도 사용자 화면에는 영향이 없는지(콘솔 경고 수준)로 본다.

대상 페르소나 (링크)¶

GA4에서 퍼널과 이탈을 분석하는 마케팅·기획, 그리고 공통 래퍼(sendEvent)로 새 이벤트를 일관되게 더하는 개발이 사용자다.

범위 (포함 / 제외)¶

여기서 다루는 건 공통 아키텍처·유틸·명명 규칙, 라우트 변경 시 자동 page_view, DebugView 검증이다. 개별 기능의 이벤트 스키마는 각 기능 FDD가 맡고, 서버사이드 태깅과 상세 리포트는 범위 밖이다.

요구사항 (유저 스토리 · 기능)¶

마케팅·기획은 GA4에서 가입→스터디룸 생성→수업노트 작성으로 이어지는 퍼널과 이탈 지점을 분석하고, 개발은 공통 래퍼(sendEvent) 하나로 새 이벤트를 일관되게 추가한다.

이를 위해 GA4 스크립트를 붙이되 dev/prod 측정 ID를 환경변수로 분리하고(값은 본문에 적지 않는다), 이벤트 이름은 [domain]_[action] 또는 [domain]_[object]_[action] 규칙으로 통일한다. 모든 이벤트에 user_type(teacher/student/guardian/null)을 공통 파라미터로 싣고, 라우트가 바뀌면 page_view를 자동으로 보낸다. 화면별 이벤트 목록은 frd에 정리돼 있다.

근거 (피드백·아이디어·리서치 source)¶

원본 파이프라인 설계(MS2)와 GA4 데이터 수집 기획서에서 도출. 공통 파이프라인을 먼저 세워야 개별 기능 이벤트가 일관되게 쌓이고, 환경 분리로 dev 데이터가 prod 분석을 오염시키지 않는다는 판단.

오픈 이슈¶

LNB/Footer/마이페이지 이벤트 TBD.
서버사이드 태깅(Server-Side Tagging) 도입 여부 미정.