앱 계층 분석: 지표, SQL, 실무 워크플로우

모바일 앱 사용자 중 25.3%만 1일 후에 돌아옵니다. , 평균 유지율은__CAPGO_KEEP_0__ 30일째 5.7% 31개의 모바일 앱 카테고리에서 전 세계적으로 Business of Apps의 모바일 앱 유지율 지표에 따르면 그 그래프가 문제가 있는지, 가입 과정에서 혼란이 생기는지, 제품의 가치가 약한지 알려주지 않는다.앱 계층 분석은 그것을 말해준다. 평균은 다른 캠페인, 국가, 기기, 앱 버전, 수익화 모델을 통해 도달한 사용자를 합친다. 계층 분석 도구는 그 그룹을 분리하고 각 그룹을 동일한 생애주기를 통해 추적하며, 제품, 마케팅, 엔지니어링 팀이 무엇을 고쳐야 하는지에 대한 근거를 제공한다.

목차

페이지/영역: Capgo 마케팅 웹사이트. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 위치: blog/[slug].astro 페이지. 메시지 키 `table_of_contents` (목차).

• 앱 계층 분석이 집계 지표가 숨기는 것을 드러내는 이유
  • 계층 분석 행의 진단적 가치
• 계층 유형과 사용하는 시기
  • 실용적인 선택 가이드
• 계층 분석을 위한 핵심 지표
  • 지표를 함께 읽기
• SQL 및 분석 도구를 사용하여 계층을 계산하세요
  • 계산 층을 선택하세요
• 계층 데이터를 잘못 읽는 팀의 일반적인 오류와 해결책
  • 처음 실패를 숨기는 생존 편향
  • 혼합 채널이 평균을 왜곡하는
• 계층 통찰력을 출시 및 업데이트 전략과 연결하세요
  • rollout 비교를 위해 고정된 경계를 사용하세요
• 설치 유지율과 이벤트 및 수익 계층을 넘어서세요
  • 반환 행동과 함께 진행률을 보고하세요

앱 계층 분석이 집계 지표를 숨기는 이유를 밝혀내세요

전체 유지율은 건강 검사를 위한 유용한 수치지만, 이는 진단 도구가 될 수 없습니다. 유료 소셜, 유기적 검색, 추천, 파트너 캠페인이 하나의 블렌드 داش보드에 공급되는 경우, 결과는 사용자들의 혼합보다 제품을 설명하는 것이 아닙니다. iOS 및 Android 사용자, 새로운 및 반복 사용자, 또는 다른 온보딩 경험을 공유하는 곡선에서 동일한 문제가 나타납니다.

이 상위 벤치마크는 첫 번째 달에 주의를 기울어야 하는 이유를 보여주고 있습니다. 동일한 앱의 비즈니스 유지율 분석 iOS의 평균은 1일차 25.65%와 30일차 4.13%일치하는 반면 Android의 평균은 1일차 23.01%와 30일차 2.59%입니다. 카테고리 성능도 크게 다르며, 2026년 벤치마크 세트는 뉴스에서 11.3%의 30일 유지율에서 교육에서 2.1%까지 다양합니다. 따라서 전 세계 평균은 강한 카테고리를 약한 것으로 만들거나 약한 채널을 합리화할 수 있습니다.앱 코호트 분석이 집계 지표에 숨겨진 사용자 유지율 패턴을 드러내는 방법을 설명하는 인포그래픽입니다.

코호트 행은 사용자가 앱을 처음 열었을 때 그룹화하고, 이후 일정한 연령(1일, 7일, 30일)에서 돌아오기 위한 행동을 측정합니다. 한 행을 읽으면 단일 그룹이 어떻게 연령을 달성하는지 알 수 있고, 열을 읽으면 동일한 시점에 다른 그룹을 비교할 수 있습니다.

The diagnostic value of a cohort row

그 distinction은 질문을 “유지율이 낮은 이유는 무엇인가?”에서 “유지율이 낮은 이유는 무엇인가?”로 바꾸는 것에서 차이가 있습니다.

• 유입 품질: 유저가 제품을 사용하지 않으려는 의도를 가지고 있는 캠페인에 유저가 끌려갔는가?
• 온보딩 저항: 유저가 설치했지만 첫 번째 의미 있는 단계를 완료하지 못했는가?
• 가치 제공: 활성화된 유저가 초기 경험 후에도 사라지는가?
• 릴리즈 영향: 새로운 버전이 유저에게 전달된 경우 곡선이 변하는가?

팀이 전체적으로 유지율이 평평한 것을 볼 수 있지만 최근 주간 코호트가 개선되고 더 오래된 코호트가 자연스럽게 나이를 먹는 것을 볼 수 있다. 코호트 경계가 없으면 개선이 평균화된다. 반대로, 강한 집계 숫자는 유입 채널이 악화되고 있지만 유기적 트래픽이 이를 보상할 만큼 충분히 증가했다면 숨겨질 수 있다.

실용적인 규칙: 유지율 관련 제품 변경을 승인할 때 집계 대시보드만으로는 절대 하지 말라. 결과를 첫 번째로 구입 소스, 국가, 플랫폼, 온보딩 경로, 앱 버전으로 분리하라.

The 앱 사용자 유지율 프레임워크 은 진단을 더 광범위한 라이프 사이클 뷰로 변환하는 데 유용합니다. 운영 포인트는 간단합니다: 계층 분석은 곡선이 끊기는 곳을 알려주고, 세그멘테이션은 끊기는 이유를 식별하는 데 도움이 됩니다.

계층 분석의 유형과 사용하는 시기

정확한 계층은 질문에 따라 달라집니다. 설치 계층, 이벤트 계층, 수익 계층은 모두 동일한 사용자를 설명할 수 있지만, 분석을 시작하는 시점과 지원하는 결정이 다릅니다.

설치 기반 계층 사용자를 첫 번째 설치 또는 첫 번째 앱 열기 날짜에 따라 그룹화합니다. 온보딩 및 수익 분석에 기본으로 사용되며, 모든 사용자가 같은 시작 이벤트를 통해 입장하기 때문입니다. 성장 팀은 캠페인 품질, 초기 유지율, 첫 번째 런 경험의 변경을 비교하기 위해 사용합니다.

이벤트 기반 계층 의미 있는 행동으로 시작합니다. 온보딩을 완료하거나 프로젝트를 만들거나 워크아웃을 마치거나 첫 번째 메시지를 보는 등. 설치와 활성화 사이의 잡음 일부를 제거합니다. 워크아웃을 완료한 사용자가 활성화 기간이 더 길다면, 온보딩 문제가 제품 전체 유지율 실패를 나타내는 것이 아니라 가치 발견을 방해하는 문제일 가능성이 높습니다.

수익 기반 계층 첫 번째 거래, 구독 시작, 플랜 티어 또는 다른 수익 이벤트에 고정되는 사용자들을 위한 계층입니다. 이 계층은 LTV 분석, 지불 결정 및 비즈니스 모델 간 비교를 지원합니다. 구독 사용자와 광고 지원 사용자는 동일한 유지율 기대치를 가지고 있지 않아야 합니다. 왜냐하면 그들의 경제적 가치와 참여 동기부여가 다르기 때문입니다. 최근 모바일 유지율 커버리지 계층에 대한 구독 앱의 30일 유지율이 14% 인 반면 광고 지원 앱의 경우 약 5.4%로 이는 비즈니스 모델 정규화가 필수적임을 나타냅니다.실용적인 선택 지침

계층 유형

운동 앱은 첫 번째 운동을 완료하는 사용자가 첫 번째 일 내에 완료하는 사용자보다 더 잘 유지하는 것을 발견할 수 있습니다. 이 발견은 운동이 유지에 영향을 미친다는 것을 증명하지는 않지만 제품 팀에게 테스트 가능한 활성화 가설을 제공합니다. 다음 단계는 첫 번째 운동까지의 경로를 줄이기고 그다음에 제대로 통제된 계층을 비교하는 것입니다.

사용 유저 세그멘테이션 공정성을 보장하기 위해 영향을 받는 차원들을 보존하는 것이 중요합니다. 계층 정의는 anchor 이벤트, 시간대, 채널, 국가, 플랫폼, 플랜, 앱 버전을 기록해야 합니다. 그렇지 않으면 동일한 레이블을 가진 두 행은 물리적으로 다른 집단을 나타낼 수 있습니다.

코어 메트릭

유지율, churn, LTV는 서로 다른 질문을 답합니다. 팀이 하나를 다른 것과 대체로 간주할 때 문제가 발생합니다.

유지율 원래 코어트 그룹의 정의된 리턴 액션을 수행한 비율을 측정합니다.

Retention Rate = Active Users in Cohort in Period / Total Users in Cohort × 100

설치 코어트 그룹의 경우 리턴 액션은 앱을 열 수 있습니다. 이벤트 코어트 그룹의 경우 리턴 액션은 완료된 워크아웃 또는 생성된 문서일 수 있습니다. 결과를 확인하기 전에 액션을 정의하세요. 리포트 간에 리턴 이벤트가 변경되면 곡선이 더 이상 신뢰할 수 있는 비교를 제공하지 않습니다.

churn 유저가 동일한 기간 동안 잃어버린 비율을 설명합니다.

Churn Rate = 1 - Retention Rate

이 역은 특히 구독 제품에서 유용합니다. 잃어버린 고객은 반복적인 수입에 영향을 미칩니다. Day 1 결과가 높고 Day 30 결과가 급격히 감소하는 곡선은 첫 경험보다 장기적인 가치 제안이 더 잘 작동하는 것을 나타냅니다. 곡선이 안정화되면 핵심 그룹이 반복 가능한 이유를 찾은 것을 나타냅니다.

LTV 코어트 그룹의 누적 수입을 코어트 그룹 크기로 나눈 것을 측정합니다.

LTV = Total Cohort Revenue / Cohort Size

일부 팀은 모델 형태를 사용하여, 예를 들어 평균 사용자당 수입을 평균 수명으로 곱하는 방식으로 계산하지만, 계층별 계산은 감사하기 더 쉬운 방법입니다. 또한, 초기 변환자로부터 수입을 받은 것으로 보아 전체적으로 수익이 발생하는지 여부를 판단하는 일반적인 오류를 방지합니다.

지표를 함께 읽어보세요.

작은 규모의 고가치 계층은 예외적으로 보이지만 확장하기 어렵습니다. 각 계층을 시작하는 인구수에 맞춰 정규화하고, 수입과 유지율을 함께 비교하여, 채널, 국가, 플랫폼, 비즈니스 모델과 함께 인수 비용과 비교하세요. 단지 LTV가 가장 높은지, 초기 유지율이 가장 높은지에만 의존하지 마세요.

기준 범위는 통과 또는 실패의 등급이 아닌 맥락을 제공합니다. 일반적으로 강력한 앱은 30-40%의 일일 유지율, 10-15%의 일주일 유지율, 5-8%의 30일 유지율을 보고합니다. 30–40% Day 1 retention, 10–15% Day 7 retention, and 5–8% Day 30 retention그것은 25%, 8%, and 4% Setgreet의 모바일 유지율 기준 요약에 따르면. 적절한 카테고리와 비즈니스 모델과 비교하여 앱을 비교하세요. UX에 대한 격차를 atributing하기 전에.The

The __CAPGO_KEEP_0__ 유저 churn 분석 가이드

코호트 테이블과 유용한 보완 자료를 제공합니다. 코호트는 attrition 발생 시점을 보여줍니다. churn 분석은 그 이전에 발생한 유저 행동, acquisition source, 또는 product condition을 식별해야 합니다.

SQL 및 분석 도구를 사용한 코호트 계산

신뢰할 수 있는 SQL 워크플로우는 하나의 행에 유저를 포함하는 코호트 anchor로 시작합니다. 모든 활동 행에서 anchor를 계산하지 마십시오. 나중에 발생하는 이벤트로 인해 유저가 잘못된 시작 기간으로 이동할 수 있기 때문입니다. events table user_id, event_nameAssume an event_at table

WITH first_open AS (
  SELECT
    user_id,
    MIN(event_at) AS cohort_at
  FROM events
  WHERE event_name = 'app_open'
  GROUP BY user_id
),
activity AS (
  SELECT DISTINCT
    f.user_id,
    DATE_TRUNC('week', f.cohort_at) AS cohort_week,
    DATE_DIFF('day', CAST(f.cohort_at AS DATE), CAST(e.event_at AS DATE)) AS age_day
  FROM first_open f
  JOIN events e
    ON e.user_id = f.user_id
   AND e.event_name = 'app_open'
   AND e.event_at >= f.cohort_at
)
SELECT
  cohort_week,
  COUNT(DISTINCT CASE WHEN age_day = 1 THEN user_id END) * 1.0
    / COUNT(DISTINCT user_id) AS day_1_retention,
  COUNT(DISTINCT CASE WHEN age_day = 7 THEN user_id END) * 1.0
    / COUNT(DISTINCT user_id) AS day_7_retention,
  COUNT(DISTINCT CASE WHEN age_day = 30 THEN user_id END) * 1.0
    / COUNT(DISTINCT user_id) AS day_30_retention
FROM activity
GROUP BY cohort_week
ORDER BY cohort_week;

, and

fields. 주간 설치 코호트를 생성하고, 각 유저가 선택한 라이프 사이클 연령에 해당하는 활동 이벤트를 발생시켰는지 여부를 측정하는 패턴입니다.

WITH onboarding_complete AS (
  SELECT
    user_id,
    MIN(event_at) AS cohort_at
  FROM events
  WHERE event_name = 'onboarding_complete'
  GROUP BY user_id
)
SELECT
  DATE_TRUNC('week', cohort_at) AS cohort_week,
  COUNT(DISTINCT CASE
    WHEN e.event_name = 'app_open'
     AND DATE_DIFF('day', CAST(o.cohort_at AS DATE), CAST(e.event_at AS DATE)) = 7
    THEN o.user_id END) * 1.0 / COUNT(DISTINCT o.user_id) AS day_7_retention
FROM onboarding_complete o
LEFT JOIN events e
  ON e.user_id = o.user_id
 AND e.event_at >= o.cohort_at
GROUP BY cohort_week;

SQL 구문은 warehouse에 따라 date-difference 함수에 따라 다릅니다. 중요한 구조는 동일합니다: 첫 번째 이벤트를establish, 나중에 활동을 anchor에 연결, 연령을 계산, 그리고 원래 코호트 인구에 대한 distinct 반환 유저를 나눕니다.

Amplitude, Mixpanel 및 Firebase는 일반적으로 첫 번째 패스에 잘 작동합니다. anchor 이벤트를 선택하고 return 이벤트를 선택하고 시간 단위의 정밀도를 정의하고 채널 또는 버전에 대한 필터를 추가하고 계정 크기를 확인하기 전에 차트를 해석하기 전에.

warehouse SQL은 ad spend, 환불, 구독 상태 및 개인 정보 보호를 보장하는 귀속을 하나의 계산에서 조인할 때 더 가치가 있습니다. 이 기초를 구축하는 팀은 또한데이터 주도 문화를 구축해야 합니다. Capgo’s event tracking plugin __CAPGO_KEEP_0__의 이벤트 추적 플러그인

앱에 이미 있는 분석 도구와 함께 고려될 수 있습니다.

팀은 기술적으로 정확한 계층 표를 만들 수 있지만 여전히 잘못된 결론에 도달할 수 있습니다. 가장 유해한 실수는 해석 이전에 발생합니다. 분석가들은 비교할 수 없는 집단을 결합하거나 동시적인 변화에 대한 원인적 신뢰를 부여합니다.

생존자 편향은 첫 번째 실패를 숨깁니다.

late-stage 유지율이 특정 기능에 도달한 사용자에게 개선된다고 가정해 보십시오. 팀은 축하하지만, early retention은 새로운 온보딩 스크린으로 인해 기능에 도달하지 못하는 사용자가 더 많아졌기 때문에 하락했습니다. 생존자만 보는 것은 제품이 건강해 보이게 하지만 상위 펀들이 악화되는 것을 숨깁니다.

전체 시퀀스를 추적하십시오, 단지 남아 있는 사용자만 추적하지 마십시오:

1. 설치 또는 첫 번째 열기.
2. 계정 생성 또는 권한 완료.
3. 핵심 활성화 이벤트.
4. 반복적 가치 이벤트.
5. 수익 또는 구독 행동.

late-stage 계층은 조건적입니다. 활성화된 사용자가 어떻게 행동하는지에 대한 답을 합니다, 활성화된 사용자를 효율적으로 생성하는 제품의 효율성에 대한 답은 아닙니다.

mixed 채널은 오류를 유발하는 평균을 생성합니다.

심슨의 역전은 유료 사용자와 유기 사용자가 하나의 행을 공유할 때 실제 위험이다. 채널 혼합이 강한 원천 쪽으로 이동할 때, 채널 내에서 유지율이 감소하는 동안 블렌드 커브가 상승할 수 있다. 대시보드는 구성 변경을 기록하지만 제품 개선이 아니다.

릴리스 또는 온보딩 변경을 평가하기 전에 수집 소스에 대한 제어가 필요하다. 캠페인, 국가, 플랫폼, 앱 버전 및 수익화 모델이 dimension으로 유지되도록 하라. 비즈니스 모델도 중요하다. 구독 및 광고 지원 앱 간의 유지율 격차가 보고된 이전 벤치마크 소스 의 의미는 제품의 수익화 혼합이 변경될 때 블렌드 커브가 제품을 처벌한다는 것이다.

코호트는 비교할 수 있는 경우에만 비교할 수 있다. 입장 조건이 비교할 수 있는 경우에만.

타임스탬프 오류는 quieter한 형태의 부패를 유발한다. 이벤트 타임스탬프를 일관되게 저장하고, Day 0을 명확하게 정의하고, 분석이 사용자의 로컬 날짜 또는 표준화 보고 시간대 사용하는지 결정하라. 글로벌 앱은 그렇지 않으면 늦은 밤에 설치한 사용자와 다음날 아침에 열린 사용자를 같은 라이프 사이클 일자로 간주할 수 있다.

설치 기반 유지율은 한 가지 더 제한이 있다. 설치 또는 첫 번째 열기 인구에서 시작하지만, 앱의 핵심 경험에 도달하지 못한 사용자가 유기적인 기대에 취약하게 취득된 경우를 설명하지 않는다. 캠페인이 즉시 제공하지 않는 특징을 약속한 경우, 채널 수준의 코호트 데이터가 조사에 앞서야 한다. 엔지니어링이 제품을 다시 작성하기 전에.

버전 및 업데이트 전략과 함께 코호트 통찰력을 연결하는 방법

릴리즈 관리는 자연스러운 코호트를 생성합니다. 버전 A, 버전 B, 스테이지 롤아웃 또는 핫픽스를 받은 사용자들은 별도로 추적할 수 있습니다. 단, 앱은 노출 시점에 버전과 관련된 릴리즈 채널을 기록해야 합니다.

이것이 유지율을 릴리즈 신호로 만드는 것입니다. 새로운 버전의 첫날 갑자기 발생하는 유지율 하락은 시스템 충돌, 인증 실패, 마이그레이션 오류 또는 온보딩 회귀와 같은 문제를 나타낼 수 있습니다. 코호트 곡선은 문제의 근본 원인을 스스로 식별하지는 않지만 새로운 사용자 집단이 다른 행동을 보이고 즉시 조사할 가치가 있는지 알려줄 수 있습니다.

롤아웃 비교를 위해 고정된 경계를 사용하십시오

유용한 롤아웃 워크플로는 다음과 같습니다.

• 노출 정의: 앱 버전, 롤아웃 채널, 기기 플랫폼, 국가, 노출 시간을 기록하십시오.
• 매치된 코호트 생성: 새로운 버전으로 노출된 사용자와 이전 기준선의 사용자를 비교하십시오. 동일한 캘린더와 수집 조건 하에서.
• 곡선 검토: 첫날, 일주일, 30일 유지율, 시스템 충돌, 실패한 이벤트, 핵심 활성화 검토하십시오.
• 선택할 액션을 선택하세요: 증거를 결합하여 프로모션, 일시 중단, 반복, 또는 롤백을 선택하세요.

새로운 온보딩 플로우를 작은 청중에게 출시하면 초기 유지율이 더 좋을 수 있습니다. 이는 청중이 다른 캠페인에서 왔기 때문입니다. 이 결과는 롤아웃을 확장하는 데 충분하지 않습니다. 수집 소스 및 코호트 경계를 일정하게 유지하거나 랜덤 ASSIGNMENT을 사용하여 버전 효과가 마케팅 효과를 상속하지 않도록 하세요.

핫픽스 분석도 같은 discipline이 필요합니다. 버그를 처음 만난 사용자, 버그를 수정받은 사용자, 이전 버전을 유지한 사용자를 태그하세요. 후속 수정 코호트가 활성화 경로를 회복하면서 비수정 코호트가 계속해서 떨어지면, 버그가 원래의 감소에 대한 설명이 될 수 있습니다. 만약 두 그룹이 동일하게 행동한다면, 버그는 원래의 감소에 대한 설명이 될 수 없습니다.

팀이 모바일 릴리스를 관리하는 경우 모바일 앱 업데이트 전략 릴리스 채널, 수용 이벤트 및 실패 상태를 동일한 이벤트 모델에 포함하여 배포 선택과 측정 사이를 연결할 수 있습니다. 버전 기반 코호트는 릴리스 채널, 수용 이벤트 및 실패 상태가 동일한 이벤트 모델에 포함될 때 더 유용합니다.

설치 유지율, 이벤트 코호트 및 수익 코호트를 넘어서

설치 유지율은 좁은 질문에 답합니다: 사용자가 설치한 후 다시 돌아 왔습니까? 사용자가 완료한 액션을 통해 가치가 생성되었는지, 사용자가 확장된 사용을 사용했는지, 사용자가 수익을 발생시켰는지 여부를 알려주지 않습니다. 제품은 설치 커브가 존중할 수 있으면서도 제품의 핵심 워크플로를 사용자에게 전달하지 못할 수 있습니다.

이벤트 계층을 통해 진행 상황을 보이게 합니다. 활성화 이벤트를 정의하여 실제 가치를 대표하는 이벤트를 선택하세요. 화면을 열기만 하는 것은 proxy입니다. 피트니스 앱의 경우 첫 번째 운동을 완료하는 것이 될 수 있고, 금융 앱의 경우 허용된 코어 거래를 완료하는 것이 될 수 있고, 협업 앱의 경우 프로젝트를 생성하고 공유하는 것이 될 수 있습니다.

수익 계층은 경제层을 추가합니다. 사용자를 첫 구매, 구독 시작, 플랜 티어, 또는 청구 이벤트에 따라 그룹화하고, 이후 수익과 사용량을 추적합니다. 구독 티어와 인앱 구매 패키지의 비교를 정규화하여, 높은 수익 계층이 universally 좋은 제품 경험으로 오인되지 않도록 합니다.

회귀 행동과 함께 진행 상황을 보고합니다.

유용한 스프린트 리뷰 테이블에서 계층 정의를 보이도록 해야 합니다.

셀은 측정된 값이 아닌 일반적인 목표를 포함해야 합니다. 카테고리 및 모델에 따라 벤치마크가 다르며 UXCam의 유지율 벤치마크 토론 일일, 일주일, 30일 창을 포함하여 월 1, 월 3 차단을 생애주기 분석에서 역할을 강조하는 일반적으로 사용되는 창을 요약합니다.

개인 정보 제한으로 인해 이 더 광범위한 정의는 점점 더 중요해집니다. Attribution이 불완전할 때, 팀은 첫 번째 파티 이벤트, 생애주기 마일스톤, 수입 기록에 의존하는 것이 더 중요합니다. 설치 출처가 행동의 완전한 설명이 아닌 것으로 간주되는 경우.

설치 유지율, 활성화 유지율, 수입 유지율을 함께 보고합니다. 설치 유지율이 평평하지만 활성화된 사용자가 개선된 경우, 온보딩이 주된 조절 장치일 수 있습니다. 활성화가 강하지만 수입 유지율이 약화된 경우, 가격, 결제墙 타이밍, 플랜 적합성, 청구 경험에 주목해야 합니다. 그 분리는 인수, 제품 및 수익성 팀이 생애주기에서 영향을 미칠 수 있는 부분에 책임을 지게 합니다.

Capgo는 CapacitorJS 및 Electron 앱에 대한 실시간 업데이트를 제공하여 팀이 대상화된 JavaScript, CSS, 구성, 자산 변경을 배포하고 수용, 실패, 롤백 신호, 버전 확산을 추적할 수 있습니다. 사용자들이 롤아웃 신호를 사용하여 더 깨끗한 버전 및 채널 계층을 만들고, 그 다음에 방문하세요. Capgo 배포 워크플로우가 릴리스 측정 프로세스에 맞는지 평가하기 위해 방문하세요.