기존 로그분석에서, 로그 1행 = 사용자의 행동 1회 = 사건(Event) 1건 으로 다뤄집니다.
ADMIN 전환관리 대시보드 제작 → 지표 수립과 기록, 시각화 등을 모두 직접 책임지기 GA4를 연결해서 쓴다 ⇒ 업계에서 많이 분석하는 포맷을 일단 적용하고 커스터마이징은 추가 세팅하기
AI-Native 에서는 직접 대시보드 제작하는 것이 더 높은 맞춤 인사이트 수립을 도울 수 있습니다.
사용자 행동 파악: 웹/앱 방문자의 유입 경로, 콘텐츠 반응, 이탈 위치 등을 추적하여 사용자가 브랜드와 상호작용하는 방식을 정확한 수치로 알려줍니다.
가공 및 시각화: 수집된 원시 데이터(Raw Data)는 정해진 기준에 따라 분류·집계되며, 내부 트래픽 제외 등의 필터링을 거쳐 보고서 형태로 시각화됩니다.
설정의 중요성: 한 번 가공되어 데이터베이스에 저장된 데이터는 사후에 수정할 수 없으므로, 비즈니스 목표에 맞춘 초기 분석 환경 설정이 매우 중요합니다. → 일정 시간 지난 후 초기 데이터가 분석된 후 결론만 남아버림.. ⇒ BigQuery 를 일찍 연동하면, BigQuery 에 원본 데이터가 살아있게 됩니다!
Home | Official Google Merch Shop
MVP 관점에서는 여기까지 다룰 수 없습니다. 서비스 활성화가 본격적으로 시작되는 시점에 고려하세요. 아예 별도의 마케팅 분석 관점으로 깊어지는 방향입니다.
/goal-setting을 사용하여 현재 프로젝트의 현황을 기반으로 GA4 에 로그를 전송할 수 있도록 장시간 Hands-Off 작업 가능한 프롬프트를 확보합니다.
SESSION_STARTER_goal-prompt_043_ga4-analytics.md⇒ 작업 결과물을 내가 소화하고 오너십을 확보할 수 있게 해주는 1+3종 산출물이 명시되는 것을 확인하세요!
**/goal-setting**
GA4 연동 파이프라인 작업 목표를 풀버전으로 수립하고자 한다.
기존 로그 감지 체계(각종 사용자 이벤트 발생 및 기록부)와
전환 모니터링 로직(지표 대시보드, 중간집계 & 최종집계 매커니즘)을 **GA4에 실제로 연결**하는 개발 목표를 수립하는 것이 핵심이다.
현재 코드베이스 앵커에 맞춰 작업을 수행한다.
산출물이 가이드/스크립트에 그치지 않고 **앱에 실제 GA4 연동 코드를 구현하는 트랙(T-APP)을 critical path로 포함**하도록 한다.
**1+3종 산출물:**
- **T-APP** — 앱에 실제 GA4 연동 코드 (클라이언트 gtag 마운트 + 서버 측 이벤트 미러링)
- **T1** — 다양한 사용자 활동 패턴의 더미 로그를 GA4로 전송하는 프로세스
- **T2** — GA4 연동·대시보드 설정 교육형 가이드 (개념 + 최신 공식 UI/UX 흐름)
- **T3** — GA4→BigQuery 분석 가이드 + EDA·통계 패턴용 SQL 스크립트
다음의 세 가지 작업 관리 및 트래킹 매커니즘을 적용한다:
(1) aztks-agent 멀티에이전트 병렬 EXECUTE + aztks EVALUATE 평가/보완
(2) AZTKS 보완 카운트를 의사결정 로그 문서에서 명시적 추적
(3) `TURN:` 카운터 줄을 결정 로그에 따로 두어 TURN_CAP 도달을 문서에서 카운트. 재개 시 아래 코드블록의 `/goal` 본문을 그대로 붙여 쓴다.
결정 로그는 직전 루프와 섞이지 않도록 이 루프 전용으로 `docs/loop/ga4-decision-log.md`를 쓴다
goal 프롬프트 확보 → 작업 계획 상세 검토 ⇒
/goal로 작업 수행
**/goal {SESSION_STARTER_goal-prompt_043_ga4-analytics.md} 파일에 명시된 목표를 전부 구현하는 작업을 시작해줘.**