앱 계층 분석: 지표, SQL, 실용적인 워크플로

일일 25.3%의 모바일 앱 사용자가 돌아오지만, 평균 유지율은 __CAPGO_KEEP_0____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%일치하는 반면 안드로이드 평균은 1일차 23.01%와 30일차 2.59%. 카테고리 성능도 크게 다르며, 2026년 벤치마크 세트의 경우 뉴스 카테고리에서 11.3%의 30일 유지율에서 교육 카테고리에서 2.1%까지 다양하다. . 따라서 전 세계 평균은 강한 카테고리를 약한 것으로 만들거나 약한 채널을 합리화할 수 있다.앱 코호트 분석이 집계 지표에 숨겨진 사용자 유지율 패턴을 드러내는 방법을 설명하는 인포그래픽이다.

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

앱 코호트 분석

그 distinction은 질문을 "유지율이 낮은 이유는 무엇인가?"에서 "획득 품질:"로 바꾸는 것

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

팀이 전체적으로 유지율이 평평한 반면 최근 주간 계층이 개선되고 더 오래된 계층이 자연스럽게 노화하는 것을 볼 수 있다. 계층 경계가 없으면 개선이 평균화된다. 반대로, 강한 집계 숫자는 유기적 트래픽이 충분히 커서 이를 보상할 수 있는 경우에만 악화되는 유료 채널을 숨길 수 있다.

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

The 앱 사용자 유지율 프레임워크 생태계 분석을 더 광범위한 생애주기 관점으로 확장하는 진단을 변환하는 데 유용합니다. 운영 포인트는 간단합니다: 생태계 분석은 곡선이 끊기는 곳을 알려주며, 세그멘테이션은 끊기는 이유가 되는 제어 가능한 입력을 식별하는 데 도움이 됩니다.

생태계 유형과 사용하는 시기

정확한 생태계는 질문에 답하려고 하는 시점에서 시작됩니다. 설치 생태계, 이벤트 생태계 및 수익 생태계는 모두 동일한 사용자를 설명할 수 있지만, 분석을 다른 시점에 고정하고 다른 결정을 지원하기 위해 다릅니다.

설치 기반 생태계 첫 번째 설치 또는 첫 번째 앱 열기 날짜에 따라 사용자를 그룹화합니다. 온보딩 및 수집 분석에 기본으로 사용되는 것은 사용자가 동일한 시작 이벤트를 통해 모두 입장하기 때문입니다. 성장 팀은 캠페인 품질, 초기 유지율 및 첫 번째 실행 경험에 대한 변경 사항을 비교하기 위해 사용합니다.

이벤트 기반 생태계 의미 있는 행동, 예를 들어 온보딩을 완료한 경우, 프로젝트를 생성한 경우, 워크아웃을 완료한 경우, 첫 번째 메시지를 보낸 경우와 같은 시작점에서 시작합니다. 설치와 활성화 사이의 잡음 일부를 제거합니다. 사용자가 첫 번째 워크아웃을 완료한 경우 활성화 기간이 사용자가 단순히 설치한 경우보다 더 길다면, 온보딩 문제가 제품 전체 유지율 실패를 반영하는 것이 아니라 가치 발견을 방해하는 문제일 가능성이 높습니다.

수익 기반 생태계 __CAPGO_KEEP_0__ 사용자들을 첫 번째 거래, 구독 시작, 플랜 티어 또는 다른 수익 이벤트에 고정시킵니다. 이러한 계층은 LTV 분석, 수익 반환 결정 및 비즈니스 모델 간 비교를 지원합니다. 구독 사용자와 광고 지원 사용자는 동일한 유지율 기대치를 가지고 있지 않아야 합니다. 왜냐하면 그들의 경제적 가치와 참여 동기부여가 다르기 때문입니다. 최근 모바일 유지율 커버리지 보고서들에 14% Day 30 유지율이 구독 앱에 비해 약 5.4%가 광고 지원 앱에 해당한다는 점을 그것은 비즈니스 모델 정규화가 필수적이라는 것을

실용적인 선택 지침

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

사용 유저 세그멘테이션 공정성을 보장하는 차원들을 보존하기 위해.

코호트 정의는 anchor 이벤트, 시간대, 채널, 국가, 플랫폼, 플랜, 앱 버전을 기록해야 합니다. 그렇지 않으면 동일한 레이블을 가진 두 행은 물리적으로 다른 집단을 나타낼 수 있습니다.

코호트 결정을 이끄는 핵심 지표

유지율, churn, LTV는 서로 다른 질문을 답합니다. 팀이 하나를 다른 것의 대용품으로 다루면 문제가 생깁니다. 유지율

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

원래 코호트의 정의된 반환 행동을 수행한 비율을 측정합니다.

설치 코호트의 경우 반환 행동은 앱을 열 수 있습니다. 이벤트 코호트의 경우 반환 행동은 완료된 워크아웃 또는 생성된 문서일 수 있습니다. 결과를 확인하기 전에 그 행동을 정의하세요. 반환 이벤트가 보고서 간에 변경된다면 곡선이 더 이상 신뢰할 수 있는 비교를 제공하지 않습니다. 회손율

Churn Rate = 1 - Retention Rate

같은 기간 동안 잃어버린 사용자를 설명합니다.

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

LTV = Total Cohort Revenue / Cohort Size

어떤 팀은 모델 형태를 사용하여, 예를 들어 평균 사용자당 수입을 평균 생애 기간으로 곱한 형태를 사용하지만, 계층별 계산은 감사하기 더 쉬운 방법입니다. 또한, 초기 전환자로부터 수입을 받는 것을 전체적인 수집 소스의 이익임으로 간주하는 일반적인 오류를 방지합니다.

지표를 함께 읽어보세요.

작은 규모의 고가치 계층은 예외적으로 보이면서도 확장하지 못하는 경우가 있습니다. 각 계층을 자신의 시작 인구에 맞춰 정규화하고, 수입과 유지율을 함께 비교하여 수집 비용, 채널, 국가, 플랫폼, 비즈니스 모델과 같은 요소와 함께 비교하세요. LTV나 초기 유지율에서 가장 높은 계층만으로 계층을 순위하지 마세요.

기준 범위는 통과 또는 실패의 등급이 아닌 맥락을 제공합니다. 일반적으로 강력한 앱은 30-40%의 일일 유지율, 10-15%의 일일 7일 유지율, 5-8%의 일일 30일 유지율을 보고합니다. 30–40% Day 1 유지율, 10–15% Day 7 유지율, 5–8% Day 30 유지율을 보고하는 강력한 앱은 일반적으로 25%, 8%, 4% 일일 1일, 일일 7일, 일일 30일 유지율을 보고하는 중간 앱은 Setgreet의 모바일 유지율 기준 요약 에 따르면 있습니다. 올바른 카테고리와 비즈니스 모델과 함께 앱을 비교하여 UX에 대한 격차를 부여하지 마세요.. Compare your app with the right category and business model before attributing a gap to UX.

The 사용자 churn 분석 가이드 유형별 분석을 제공하여 유형별 분석을 보완합니다. 유형별 분석은 attrition이 발생하는 시기를 보여줍니다. churn 분석은 사용자 행동, 인수 소스 또는 제품 조건이 이전에 발생한지 여부를 확인해야 합니다.

SQL 및 분석 도구를 사용하여 유형별 계산

신뢰할 수 있는 SQL 워크플로는 사용자당 한 행으로 시작합니다. 유형별 anchor를 계산하지 마십시오. 나중에 발생하는 이벤트는 사용자를 잘못된 시작 기간으로 옮길 수 있습니다.

Assume an events table with user_id, event_name, and event_at fields. 다음 패턴은 주간 설치 유형별 계산을 생성하고 각 사용자가 선택한 라이프 사이클 연령에 해당하는 활동 이벤트를 생성했는지 여부를 측정합니다:

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;

SQL 구문은 저장소에 따라 달라지며, 특히 날짜 차이 함수에 따라 달라집니다. 중요한 구조는 동일합니다: 첫 번째 이벤트를establish, 나중에 활동을 anchor에 연결하고, 연령을 계산하고, 원래 유형별 인구에 따라 distinct 반환 사용자를 나눕니다.

활성화 유형별 계산을 위해 anchor 이벤트를 대신하여 대체하십시오.

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;

계산 layer를 선택하는

Amplitude, Mixpanel 및 Firebase는 일반적으로 첫 번째 패스에 잘 작동합니다. anchor 이벤트를 선택하고 return 이벤트를 선택하고 시간 granulariti를 정의하고 채널 또는 버전에 대한 필터를 추가하고 차트를 해석하기 전에 계열 크기를 확인하세요. Warehouse SQL은 광고 비용, 환불, 구독 상태 및 개인 정보 보호를 보장하는 귀속을 하나의 계산에서 조인할 때 더 가치가 있습니다.

이 기초를 구축하는 팀은 또한 데이터 주도 문화를 구축해야 합니다.이유는 계열 대시보드는 제품, 마케팅, 금융 및 엔지니어링 팀이 정의에 신뢰를 할 때만 결정에 영향을 미치기 때문입니다. 사용자 정의 라이프 사이클 이벤트에 대해 Capgo의 이벤트 추적 플러그인 이 분석 도구가 이미 앱에 있는 분석 도구와 함께 고려될 수 있습니다.

일반적인 실수 및 팀이 계열 데이터를 잘못 읽는 방법

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

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

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

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

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

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

혼합 채널은 오류를 숨깁니다.

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

릴리스 또는 온보딩 변경을 평가하기 전에 수집 원천에 대한 제어가 필요하다. 캠페인, 국가, 플랫폼, 앱 버전, 및 수익화 모델이 dimension으로 유지되어야 한다. 비즈니스 모델도 중요하다. 구독과 광고 지원 앱 간의 유실률 격차가 보고된 이전 벤치마크 소스 이전 벤치마크 소스 심슨의 역전은 실제 위험이다. 유료와 유기적 사용자들이 하나의 행을 공유할 때, 채널 혼합이 강한 원천 쪽으로 이동할 때, 심슨의 역전은 채널 내에서 유실률이 감소하는 동안 블렌드 커브가 상승할 수 있다.

코호트는 유입 조건이 유사할 때만 비교할 수 있다.

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

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

버전 및 업데이트 전략과 함께 코호트 인사이트를 연결하는 방법

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

이것은 유지율을 릴리스 신호로 만들고, 후속 보고서가 아닌 것입니다. 새로운 버전의 첫날 갑자기 발생하는 유지율 하락은 충돌, 인증 실패, 마이그레이션 오류, 온보딩 회귀와 같은 문제를 나타낼 수 있습니다. 코호트 곡선은 자체적으로 원인에 대한 정보를 제공하지는 않지만, 새로운 사용자 집단이 다른 행동을 보이고 즉시 조사할 가치가 있는지 알려줄 수 있습니다.

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

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

• 노출 정의: 앱 버전, 롤아웃 채널, 기기 플랫폼, 국가, 노출 시간을 기록하십시오.
• 매치된 코호트 생성: 새로운 버전을 받은 사용자를 이전 기준선의 사용자와 같은 캘린더 및 인수 조건 하에서 비교하십시오.
• 곡선 검토: 첫날, 일주일, 30일 유지율, 충돌, 실패한 이벤트, 핵심 활성화 검토하십시오.
• 선택한 액션: 합쳐진 증거에 따라 확장, 일시 중단, 반복, 또는 롤백을 선택할 수 있습니다.

새로운 온보딩 플로우를 작은 청중에게 출시하면 초기 유지율이 더 좋을 수 있습니다. 이는 청중이 다른 캠페인에서 왔기 때문입니다. 이 결과는 확장된 롤아웃을 위해 충분하지 않습니다. 유지율을 높이기 위해 수집한 데이터와 계층구조를 유지하거나 랜덤 할당을 사용하여 버전 효과가 마케팅 효과를 상속하지 않도록 합니다.

핫픽스 분석도 같은 discipline이 필요합니다. 버그를 처음 만난 사용자, 버그를 수정받은 사용자, 이전 버전을 유지한 사용자를 태그합니다. 수정된 버전의 계층구조가 활성화 경로를 회복하고 이전 버전의 계층구조가 계속해서 떨어지면, 버그가 원래의 감소에 대한 증거를 제공합니다. 두 그룹이 동일하게 행동하면 버그가 원래의 감소에 대한 원인일 수 없습니다.

모바일 릴리스를 관리하는 팀은 모바일 앱 업데이트 전략 을 사용하여 배포 선택과 측정 사이의 연결을 만들 수 있습니다. 버전 기반 계층구조는 릴리스 채널, 수용 이벤트, 실패 상태가 동일한 이벤트 모델에 포함될 때 더 유용합니다.

설치 유지율, 이벤트 계층구조, 수익 계층구조를 넘어서는 것

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

이벤트 계층을 통해 진행 상황을 보이게 합니다. 활성화 이벤트를 정의하여 실제 가치가 아닌 프록시(화면 열기 등)가 아닌 실제 가치가 되는 이벤트를 정의합니다. 피트니스 앱의 경우 첫 번째 운동을 완료하는 것이 될 수 있고, 금융 앱의 경우 허용된 코어 거래를 완료하는 것이 될 수 있고, 협업 앱의 경우 프로젝트를 생성하고 공유하는 것이 될 수 있습니다.

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

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

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

셀은 측정된 값이 아닌 일반적인 목표를 포함해야 합니다. 벤치마크는 카테고리와 모델에 따라 다르며 UXCam의 유지율 벤치마크 토론 일일, 일주일, 30일 창구를 요약하는 데 중점을 둔 일반적으로 사용되는 일일, 일주일, 30일 창구를 요약합니다.

개인 정보 제한으로 인해 이 더 광범위한 정의가 점점 더 중요해지고 있습니다. Attribution이 불완전할 때, 팀은 첫 번째 파티 이벤트, 라이프 사이클 마일스톤, 수입 기록에 더 많이 의존해야 합니다. 설치 출처가 행동의 완전한 설명이 아닌 것으로 간주하는 대신.

라이프 사이클 분석에서 월 첫 달과 월 세 번째의 분출이 역할을 하는 것을 강조합니다. 가장 유용한 계층 정의는 제품 가치가 개선되는 것을 목표로 하는 제품 가치와 가장 가깝습니다.

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