Communitygithub.com

전환 감사

깔때기 전체를 감사하여 수정할 가치가 있는 단 하나의 누수와 이를 증명하는 테스트를 찾아냅니다. 단계별 전환율을 실제 벤치마크와 비교하여 측정하고, 사용자가 실제로 이탈하는 지점을 파악하며, 트래픽 품질 문제와 제품 문제를 분리하고, 사전에 합의된 성공 지표가 있는 실험을 설계합니다.

전환 감사란 무엇인가요?

이 스킬은 전체 깔때기(퍼널)를 감사하여 단 하나의 가장 큰 누수를 식별하고, 이를 해결하기 위한 실험을 설계하는 데 초점을 맞춥니다. 단순히 숫자를 보고하는 것이 아니라, '무엇을 고칠지'에 대한 결정을 내리는 것이 목표입니다. 이 스킬은 Claude Code, Cursor, Codex 등과 같은 AI 에이전트 플랫폼에서 사용할 수 있으며, 주어진 SKILL.md 문서를 기반으로 작동합니다. 깔때기 단계를 이벤트 단위로 작성하고, 단계 간 전환율을 측정하여 절대 사용자 손실 순으로 순위를 매긴 뒤, 가장 심각한 단계에 대해 동기 부족, 마찰, 적합성 문제라는 세 가지 진단 질문을 던집니다. 이후 허영 지표를 제거하고 북극성 지표를 선택한 후, 사전에 합의된 성공 기준과 기간이 포함된 단일 변경 실험을 설계합니다. 최종 산출물은 누수, 진단, 변경, 수치의 네 줄로 구성됩니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/oinoa/skills/tree/HEAD/skills/conversion-audit

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

전환 감사은(는) 무엇을 하나요?

당신의 임무는 숫자를 보고하는 것이 아닙니다. 모든 감사는 결정으로 끝나야 합니다: 가장 많은 비용을 초래하는 하나의 누수, 출시할 하나의 변경 사항, 그리고 그 변경 사항이 달성해야 하는 수치. 아무도 다음에 무엇을 해야 할지 바꾸지 않는 차트는 모두의 오후를 낭비한 것입니다.

모든 것을 지배하는 하나의 규칙

가장 쉬운 누수를 고치지 말고, 가장 큰 누수를 고치십시오. 전환은 곱셈적입니다. 100 → 40 → 36 → 34로 이어지는 깔때기는 하나의 치명적인 단계와 세 개의 괜찮은 단계를 가지고 있습니다. 36 → 34 단계(94% 단계)의 전환율을 두 배로 높이는 것은 거의 의미가 없습니다. 100 → 40 단계를 55로 개선하면 전체 깔때기가 약 38% 상승합니다. 항상 절대 사용자 손실을 기준으로 단계의 순위를 매기십시오. 백분율이나 단계가 얼마나 성가셔 보이는지 기준으로 하지 마십시오. 가장 못생긴 페이지가 가장 비용이 많이 드는 경우는 드뭅니다.

1단계: 데이터를 보기 전에 깔때기를 그리십시오

사용자가 실제로 거치는 단계를 페이지가 아닌 이벤트로서 순서대로 작성하십시오. "랜딩 → 가격 확인 → 가입 시작 → 이메일 인증 → 설정 완료 → 핵심 작업 수행 → 7일차 재방문." 단계 이름을 지을 수 없으면 측정할 수 없으며, 두 개의 다른 여정이 하나의 단계로 합쳐지면 모든 하위 숫자는 거짓말이 됩니다.

모든 깔때기 감사를 조용히 망가뜨리는 두 가지:

  • 혼합된 모집단. 유료 트래픽, 오가닉, 초대 플로우의 전환율은 크게 다릅니다. 이들을 평균내면 좋은 것과 망가진 것을 모두 숨깁니다. 어떤 결론을 내리기 전에 소스별로 세분화하십시오.
  • 분모가 움직였습니다. "떨어진" 전환율은 일반적으로 제품 회귀가 아닌 트래픽 구성 변경입니다. 제품 버그를 찾으러 가기 전에 상위 단계의 개수 모양이 변경되었는지 확인하십시오.

2단계: 단계별로 측정한 다음 사용자 손실 기준으로 순위를 매기십시오

각 단계에 대해: 진입, 완료, %, 절대적 감소. 절대적 감소 기준으로 정렬하십시오. 정렬된 목록이 감사입니다. 나머지는 모두 설명입니다.

그런 다음 최악의 단계에 대해서만 세 가지 진단 질문을 하십시오:

  • 동기 부여 문제입니까? 사용자가 다음 단계를 이해하지 못하거나 원하지 않습니다. 증상: 상호작용 없이 이탈합니다. 해결 방법은 카피, 증거, 가격 명확성에 있습니다.
  • 마찰 문제입니까? 사용자가 원하지만 플로우가 방해합니다. 증상: 단계를 시작하고 중간에 포기합니다(제출 없는 양식 시작, 재시도, 오류). 해결 방법은 더 적은 필드, 더 적은 결정, 더 나은 기본값, 오류 처리에 있습니다.
  • 적합성 문제입니까? 도착하는 사용자가 전환할 의사가 전혀 없었습니다. 증상: 한 소스에서는 단계 전환이 잘되고 다른 소스에서는 형편없습니다. 해결 방법은 페이지가 아닌 상위 타겟팅에 있습니다.

이 분류를 잘못하는 것은 감사가 몇 달 간의 쓸모없는 작업을 생산하는 가장 일반적인 방법입니다. 적합성 문제에서 A/B 테스트로 빠져나올 수 없습니다.

3단계: 허영 지표의 이름을 큰 소리로 말하십시오

비즈니스가 옆으로 가는 동안에도 지표가 상승할 수 있다면 그 지표는 허영입니다. 페이지뷰, 활성화가 없는 가입, "참여도", 원시 팔로워 수, 누적 합계(오를 수만 있음). 각각을 분모와 시간 제한이 있는 버전으로 대체하십시오: "1만 가입"이 아닌 "코호트별 7일 이내 가입 → 활성화."

정확히 하나의 북극성을 선택하십시오: 사용자가 실제 가치를 얻을 때만 움직이는 지표, 팀이 실제로 영향을 미칠 수 있는 지표, 그리고 수익을 선행하는 지표(후행하지 않음). 다른 모든 것은 보조 지표 또는 가드레일입니다. 단계가 망가졌다고 선언하기 전에 기준이 되는 벤치마크 범위에 대한 참조를 확인하십시오.

4단계: 이를 증명하는 테스트를 설계하십시오

모든 권장 사항에는 실험과 사전에 약속된 수치가 함께 제공됩니다:

  • 테스트당 하나의 변경. 세 가지 변경 사항을 묶으면 승리는 어떤 것이 효과가 있었는지에 대해 아무것도 가르쳐주지 않으며, 패배는 더 적게 가르쳐줍니다.
  • 시작 전에 목표와 기간을 설정하십시오. "2단계가 40%에서 48%로, 2주 동안 측정." 데이터를 본 후 기준을 결정하는 것은 팀이 패자를 출시하는 방법입니다.
  • 전체 주를 실행하십시오. 주중/주말 트래픽은 다릅니다. 4일 테스트는 기분입니다.
  • 검정력이 부족한 테스트는 테스트를 안 하는 것보다 더 나쁩니다. 단계의 주간 사용자가 수백 명에 불과하다면 작은 상승은 측정 불가능합니다. 나타날 만큼 큰 것을 테스트하거나, 명백히 더 나은 버전을 그냥 출시하고 넘어가십시오. 가짜 통계를 통해 추측을 세탁하지 마십시오.
  • 예정대로 죽은 것으로 간주하십시오. 종료일까지 기준에 도달하지 못한 테스트는 패배한 것입니다. 승리할 때까지 연장하는 것은 테스트가 아니라 노이즈를 찾는 것입니다.

산출물

매번 다음 순서로 네 줄:

  1. 누수 — 어떤 단계, 절대 사용자 손실, 전체 손실 대비 %.
  2. 진단 — 동기 부여 / 마찰 / 적합성, 이를 뒷받침하는 증거.
  3. 변경 — 출시할 한 가지.
  4. 수치 — 달성해야 하는 기준, 기한, 또는 되돌려야 합니다.

4번 줄을 채울 수 없다면 아직 권장 사항이 있는 것이 아니라 의견만 있는 것입니다.

단계별 벤치마크 범위, 표본 크기 경험 법칙, 허영 지표를 실제 지표로 교체하는 표, 감사 및 실험 템플릿은 references/funnel-benchmarks-and-test-design.md를 참조하십시오.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

관련 스킬