Metrics report
GA·Amplitude·사내툴의 지표를 뽑아 정기 보고서를 쓴다. 숫자 나열이 아니라 목표 대비·변화 드라이버·시사점 중심. "지표 보고서 / 주간 지표 / 지표 정리해서 보고서 / GA 리포트" 요청 시. (metrics-watch=이상알림, 이건 리포트 작성)From its SKILL.md
npx -y skills add sminju98/pm-copilot --skill metrics-reportAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.3 KB, as published. Nobody here has run it
작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].
지표 보고서 작성
숫자를 '읽는' 것과 '보고하는' 것은 다르다. 목표 대비 어디에 있고, 왜 그렇게 됐고, 그래서 뭘 할지를 쓴다.
1. 지표 가져오기 (안정 순서대로)
- API·커넥터 우선: GA4 Data API / Amplitude / Mixpanel 등이 claude.ai 커넥터로 연결돼 있으면 그걸로 읽는다(정확·자동화 가능·예약에서도 동작).
- 사내툴 폴백(Claude-in-Chrome): API가 없는 내부 대시보드는 로그인된 브라우저로 열어 숫자를 읽는다. ⚠️ 화면이 바뀌면 깨질 수 있고 본인 로그인 세션이 필요하며 무인 예약엔 불안정 — 그 한계를 보고서에 밝힌다.
- 미연결/못 읽음: 지어내지 말고 사용자에게 숫자를 붙여달라 하거나 "확인 필요"로 남긴다. 지표 환각은 잘못된 의사결정으로 직결되므로 절대 금지.
2. 데이터 경계
회사 내부 지표는 민감하다. 승인된 소스로만 읽고, 웹 검색어 등 외부로 흘리지 않는다. 보고서는 설정된 개인/팀 채널로만 전달(팀 공유 여부는 사용자 확인).
3. 보고서 구조 (각 항목에 근거·날짜·세그먼트)
- 한 줄 요약 — 이번 기간 핵심 1문장.
- KPI 스코어카드 — 지표 / 이번값 / 전기간 / 목표 / 상태(✅⚠️). 노스스타·가드레일 포함.
- 변화 드라이버 — 오른/내린 이유. 근거 있는 것만, 추정은 "추정"으로. 상관≠인과.
- 시사점 → 액션 — 그래서 무엇을 할지 1~2개.
- 확인 필요 — 못 읽었거나 이상한 숫자.
4. 전달 & 주기
- 온디맨드로 보여주거나, 주간/월간 루틴으로 자동화(→
schedule_brief방식). - 전달: 연결된 Slack 커넥터로 설정 채널에 게시(우선). 폴백
post_slack.py, 항상 미리보기 먼저.
무작정 하지 않기 (중요)
사내툴 브라우저 스크래핑처럼 복잡하거나 애매한 경로는 바로 실행하지 않는다. 먼저 "이건 이렇게 뽑을 수 있어요 — 어떤 지표/기간으로 할까요?" 로 가능함을 알리고 범위를 확인한 뒤 진행한다. 신입이 필요할 때 도와주되, 대신 다 해치우고 결론만 던지지 않는다.
원칙 (신입 코칭)
- 숫자마다 "이게 왜 중요한지" 한 줄(신입이 지표를 이해하게).
- 없는 값 지어내지 않기 · 출처/날짜 표기 · 결론은 사람이 검토. [metrics-watch]·[experiment]와 연결.
기획으로 연결 (지표만 보고 끝내지 않는다)
시사점을 [[prioritize]] → [[write-spec]]/[[project]]로 기획·태스크화한다. 이상·기회는 [[voc]]와 교차해 원인을 본다.