metrics-report

name	metrics-report
description	GA·Amplitude·사내툴의 지표를 뽑아 정기 보고서를 쓴다. 숫자 나열이 아니라 목표 대비·변화 드라이버·시사점 중심. "지표 보고서 / 주간 지표 / 지표 정리해서 보고서 / GA 리포트" 요청 시. (metrics-watch=이상알림, 이건 리포트 작성)

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

지표 보고서 작성

숫자를 '읽는' 것과 '보고하는' 것은 다르다. 목표 대비 어디에 있고, 왜 그렇게 됐고, 그래서 뭘 할지를 쓴다.

1. 지표 가져오기 (안정 순서대로)

1. API·커넥터 우선: GA4 Data API / Amplitude / Mixpanel 등이 claude.ai 커넥터로 연결돼 있으면 그걸로 읽는다(정확·자동화 가능·예약에서도 동작).
2. 사내툴 폴백(Claude-in-Chrome): API가 없는 내부 대시보드는 로그인된 브라우저로 열어 숫자를 읽는다. ⚠️ 화면이 바뀌면 깨질 수 있고 본인 로그인 세션이 필요하며 무인 예약엔 불안정 — 그 한계를 보고서에 밝힌다.
3. 미연결/못 읽음: 지어내지 말고 사용자에게 숫자를 붙여달라 하거나 "확인 필요"로 남긴다. 지표 환각은 잘못된 의사결정으로 직결되므로 절대 금지.

2. 데이터 경계

회사 내부 지표는 민감하다. 승인된 소스로만 읽고, 웹 검색어 등 외부로 흘리지 않는다. 보고서는 설정된 개인/팀 채널로만 전달(팀 공유 여부는 사용자 확인).

3. 보고서 구조 (각 항목에 근거·날짜·세그먼트)

1. 한 줄 요약 — 이번 기간 핵심 1문장.
2. KPI 스코어카드 — 지표 / 이번값 / 전기간 / 목표 / 상태(✅⚠️). 노스스타·가드레일 포함.
3. 변화 드라이버 — 오른/내린 이유. 근거 있는 것만, 추정은 "추정"으로. 상관≠인과.
4. 시사점 → 액션 — 그래서 무엇을 할지 1~2개.
5. 확인 필요 — 못 읽었거나 이상한 숫자.

4. 전달 & 주기

• 온디맨드로 보여주거나, 주간/월간 루틴으로 자동화(→ schedule_brief 방식).
• 전달: 연결된 Slack 커넥터로 설정 채널에 게시(우선). 폴백 post_slack.py, 항상 미리보기 먼저.

무작정 하지 않기 (중요)

사내툴 브라우저 스크래핑처럼 복잡하거나 애매한 경로는 바로 실행하지 않는다. 먼저 "이건 이렇게 뽑을 수 있어요 — 어떤 지표/기간으로 할까요?" 로 가능함을 알리고 범위를 확인한 뒤 진행한다. 신입이 필요할 때 도와주되, 대신 다 해치우고 결론만 던지지 않는다.

원칙 (신입 코칭)

• 숫자마다 "이게 왜 중요한지" 한 줄(신입이 지표를 이해하게).
• 없는 값 지어내지 않기 · 출처/날짜 표기 · 결론은 사람이 검토. [metrics-watch]·[experiment]와 연결.

기획으로 연결 (지표만 보고 끝내지 않는다)

시사점을 [[prioritize]] → [[write-spec]]/[[project]]로 기획·태스크화한다. 이상·기회는 [[voc]]와 교차해 원인을 본다.