제품 사용 데이터를 기능 채택 보고서로 변환하는 방법 (2026)

사용량 내보내기 데이터는 사용자 ID, 이벤트 이름, 타임스탬프, 그리고 한두 개의 속성으로 구성된 긴 이벤트 목록입니다. 반면 기능 채택 보고서는 단 하나의 백분율로 표시됩니다. 이 둘 사이의 간극을 메우는 것은 공식이 아니라 세 가지 결정입니다.

분모에 어떤 사용자를 포함할 것인가. 기능을 사용한 것으로 인정하는 기준은 무엇인가. 그리고 어떤 기간을 기준으로 측정할 것인가.

이 중 하나만 바꾸어도 수치가 수십 퍼센트포인트씩 달라집니다. 그럼에도 보고서는 여전히 그럴듯해 보인다는 것이 바로 문제입니다.

이 가이드에서는 가장 먼저 결정해야 할 사항, 세 가지 수동 측정 경로, 그리고 각 방식이 한계를 드러내는 지점을 다룹니다.

시작하기 전에 필요한 것

미리 집계된 요약 데이터가 아니라, 이벤트 수준의 행 데이터가 필요합니다. 사용자 식별자와 타임스탬프가 포함된 이벤트당 하나의 행이어야 합니다.

실제로 해당 기능을 나타내는 이벤트 이름이 필요합니다. 대부분의 기능은 여러 이벤트를 발생시키기 때문에 이는 말처럼 간단하지 않습니다. 기능 채택 수치의 정확성은 이 매핑이 얼마나 잘 되어 있느냐에 달려 있습니다.

또한 누가 그 기능을 사용할 수 있었는지 알아야 합니다. 특정 계정 그룹에만 기능 플래그를 통해 배포되었다면, 나머지 사용자는 분모에 포함되어서는 안 됩니다.

간단한 정합성 검사를 거치면 나중에 시간을 크게 아낄 수 있습니다. 내보낸 데이터에서 고유 사용자 수를 세어 기존에 알고 있는 활성 사용자 수와 비교해 보세요. 차이가 크다면, 인지하지 못한 필터가 내보내기 데이터에 적용되어 있을 수 있습니다.

수치를 변화시키는 세 가지 결정

분모. 전체 가입 사용자, 월간 활성 사용자, 또는 해당 기능을 사용할 자격이 있는 사용자만 포함할 것인가. 동일한 이벤트 데이터라도 이에 따라 세 가지 다른 백분율이 도출됩니다. 모든 기능 채택 수치는 분수이므로, 계산을 시작하기 전에 분자와 분모를 명확히 정의해야 합니다.

새로 출시된 기능의 경우, 보통 자격이 있는 사용자를 분모로 삼는 것이 가장 정직한 선택입니다. 전체 가입 사용자를 분모로 삼으면 수치가 가장 낮게 나오지만, 보수적인 기준이라고 방어하기는 가장 쉽습니다.

"사용"의 정의. 이벤트를 한 번 발생시킨 것, 두 번 발생시킨 것, 또는 서로 다른 두 세션에서 발생시킨 것 중 무엇을 기준으로 할 것인가. 온보딩 튜토리얼 중 단 한 번 클릭한 것은 채택이라고 볼 수 없으며, 대부분의 팀은 시행착오를 겪은 후에야 이를 깨닫습니다.

기준을 정하고 이를 보고서에 명시하세요. 서로 다른 이틀 동안 각각 한 번씩, 총 2회 사용하는 것을 기준으로 삼는 것이 일반적이고 합리적인 규칙입니다.

기간. 채택은 특정 시점의 데이터가 아닙니다. 특정 기간 내에 해당 행동을 수행한 대상 사용자의 비율이므로, 기간 자체가 정의의 일부가 됩니다.

분석 도구의 방법론을 그대로 복사하기 전에 알아두어야 할 미묘한 차이점이 있습니다. Amplitude's retention documentation에서는 계산 방식을 다음과 같이 설명합니다. "시작 이벤트의 날짜와 지정한 복귀 이벤트의 날짜를 비교하여 리텐션 데이터를 계산합니다."

날짜 범위는 첫 번째 이벤트에만 적용됩니다. Amplitude는 "사용자가 분석에 포함되기 위해 해당 기간 내에 복귀 이벤트를 트리거할 필요는 없다"고 명확히 밝히고 있습니다.

이는 합리적인 방식이지만 많은 이들을 놀라게 합니다. 두 이벤트 모두 동일한 기간으로 필터링하는 스프레드시트는 이 도구와 결과가 다르게 나오겠지만, 둘 중 어느 쪽도 틀린 것은 아닙니다.

수동으로 계산하는 방법

옵션 1: 고유 사용자 수를 세고 나누기

단순 이벤트 발생 횟수는 채택자 수가 아니므로 중복 제거부터 시작해야 합니다. UNIQUE 함수를 사용하여 고유 사용자 목록을 추출하세요.

그런 다음 이벤트 이름과 날짜 범위를 조건으로 COUNTIFS 함수를 사용하여 해당 기능 이벤트를 발생시킨 사용자가 몇 명인지 세어보세요. 이 값을 대상 사용자 수로 나눕니다.

두 개의 카운트 값을 하나의 수식에 중첩하지 말고 눈에 보이는 별도의 셀에 유지하세요. 누군가 분모가 무엇이었는지 물어볼 때 바로 가리킬 수 있어야 하기 때문입니다.

이 방식의 한계는 구체적인 맥락 없이 단 하나의 숫자만 제공한다는 점입니다. 18%가 채택했다는 사실만 알 뿐, 그들이 누구인지에 대해서는 아무것도 알 수 없습니다.

옵션 2: 사용자 수준의 플래그 테이블 구축하기

대상 사용자당 하나의 행을 만들고, 질문당 하나의 열을 만듭니다. 이벤트를 발생시켰는지, 몇 번 발생시켰는지, 그리고 며칠 동안 발생시켰는지 등을 기록합니다.

이제 데이터를 세분화할 수 있습니다. 요금제별, 가입 코호트별, 계정 규모별, 온보딩 완료 여부별로 채택률을 분석해 보세요.

이 단계에 이르러야 기능 채택 데이터가 단순한 보고용을 넘어 행동을 유도하는 지표가 됩니다. 전체 평균 18%라는 수치는 신규 사용자의 채택률은 40%이고 작년 가입 사용자의 채택률은 4%라는 중요한 사실을 가려버립니다.

바로 그 격차가 우리가 찾아내야 할 인사이트입니다. cohort analysis 가이드에서는 사용자의 행동이 변하지 않더라도 가입자 수의 변화에 따라 왜 전체 평균 수치가 흔들리는지 설명합니다.

이 방식의 한계는 데이터의 양과 조인 작업입니다. 100만 행이 넘는 내보내기 데이터에 계정 테이블까지 결합하면 수식만으로는 감당하기 어려운 수준이 됩니다.

옵션 3: 숫자 옆에 정의 탭 유지하기

이벤트 이름, 기준, 기간, 분모, 그리고 대상 사용자가 누구였는지를 기록해 두세요.

이렇게 해야 다음 달에도 일관된 기준으로 보고서를 비교할 수 있습니다. 하지만 누군가 10분 안에 수치를 요구할 때 가장 먼저 무시되기 쉬운 탭이기도 합니다.

한계는 정의를 문서화한다고 해서 그것이 자동으로 적용되지는 않는다는 점입니다. 결국 누군가는 매주기마다 동일한 5개의 필터를 다시 설정하고 있을 것입니다.

공통적인 한계. 세 가지 방법 모두 이벤트 이름이 깔끔하게 정리되어 있다는 것을 전제로 합니다. 리팩터링 후 동일한 작업이 세 가지 다른 이름으로 실행된다면, 계산을 시작하기 전에 이 이름들을 일치시키는 작업이 진짜 골칫거리가 됩니다.

수동 방식이 정체되는 지점

첫 번째 보고서를 작성하는 데는 반나절이 걸립니다. 하지만 네 번째 보고서를 작성할 때는 더 오랜 시간이 걸리는데, 그사이 정의가 미세하게 변했기 때문입니다.

제품이 변경되면 이벤트 이름도 바뀝니다. 코드베이스에서 이름이 변경되면 차트의 그래프가 급격히 꺾이게 되는데, 이는 마치 사용자들이 해당 기능을 이탈한 것처럼 보입니다. 결국 기능 채택 차트가 고객의 결정이 아닌 코드 변경 사항을 보고하게 되는 셈입니다.

배포 범위의 변경은 분모를 망가뜨립니다. 기능이 100%의 계정에 배포되면 대상 사용자 수가 3배로 늘어나기 때문에, 겉보기에는 채택률이 떨어진 것처럼 보입니다.

또한 가장 오랫동안 살아남는 계산 오류가 있습니다. 고유 사용자가 아닌 이벤트 발생 횟수를 합산하면, 소수의 파워 유저가 기능을 집중적으로 사용할 때마다 채택률이 비정상적으로 부풀려집니다.

마감 직전에야 드러나는 비용이 하나 더 있습니다. 누군가 "이 수치가 좋은 건가요?"라고 물었을 때, 단 하나의 백분율만으로는 답할 수 없으며, 비교 대상을 만드는 것은 또 다른 프로젝트가 됩니다.

Powerdrill Bloom으로 보고서 작성하기

1단계: 사용량 내보내기 데이터 업로드

이벤트 내보내기 파일 또는 이벤트와 계정 파일을 함께 업로드합니다. Powerdrill Bloom은 업로드 즉시 열을 분석하므로, 백분율을 계산하기 전에 일관되지 않은 이벤트 이름이나 누락된 사용자 ID를 먼저 찾아냅니다.

2단계: 자연어로 정의 설명하기

규칙을 직접 구축하는 대신 말로 설명하세요. 이벤트 이름, 기준, 기간, 그리고 대상 사용자를 지정합니다.

그런 다음 함정을 피할 수 있는 질문을 던져보세요. 중복에 가까운 이벤트 이름이 있는지 물어보거나, 발생한 이벤트 수 대비 고유 사용자 수는 얼마나 되는지, 그리고 가입 월별로 기능 채택률이 어떻게 다른지 질문해 보세요.

3단계: 차트, 보고서 또는 프레젠테이션 덱 내보내기

채택 트렌드 차트, 세그먼트별 테이블, 또는 수치와 정의가 함께 담긴 슬라이드를 내보내세요.

매주기마다 보고서를 다시 만드는 것보다 나은 이유

	수동 방식	Powerdrill Bloom
이벤트에서 사용자 중복 제거	파일별 보조 열 생성	고유 사용자 수 요청
코호트 또는 요금제별 세분화	테이블 조인 및 재구축	세부 분석 요청
릴리스 후 변경된 이벤트 이름	나중에 차트에서 발견	업로드 시 즉시 감지
대상 사용자 범위 변경	분모 재계산	새로운 규칙 지정

세 번째 행이 바로 정확성이 결정되는 지점입니다. 꺾은선형 차트에서는 변경된 이벤트 이름과 실제 채택률 하락이 똑같이 보이지만, 제품 차원의 대응이 필요한 것은 후자뿐입니다.

흔히 하는 실수들

사용자가 아닌 이벤트를 세는 것. 200명이 발생시킨 10,000건의 이벤트는 채택이 아닙니다. 항상 중복 제거부터 하세요.

특정 그룹에만 배포된 기능의 분모로 전체 가입 사용자를 사용하는 것. 계정의 3분의 1만 해당 기능을 볼 수 있다면, 나머지 3분의 2는 미채택자가 아니라 대상 사용자가 아닙니다.

단 한 번의 클릭을 채택으로 간주하는 것. 온보딩 중 발생한 단일 이벤트는 단순 노출에 불과합니다. 수치가 의미를 가지려면 서로 다른 날에 걸친 반복 사용을 기준으로 삼아야 합니다.

여러 달에 걸쳐 평균 비율을 비교하는 것. 신규 사용자와 기존 사용자의 채택률은 다르기 때문에, 사용자 구성 비율의 변화만으로도 수치가 달라질 수 있습니다. 결론을 내리기 전에 코호트별로 데이터를 나누어 보세요.

변경된 이벤트 이름을 무시하는 것. 리팩터링은 이탈처럼 보이는 급격한 하락을 만들어냅니다. 사용자 행동을 조사하기 전에 이벤트 사전을 먼저 확인하세요.

도구의 측정 기간 방식을 이해하지 않고 그대로 복사하는 것. 문서화된 리텐션 기간은 첫 번째 이벤트에만 필터가 적용되는 경우가 많기 때문에, 두 이벤트 모두 필터링하는 스프레드시트와 결과가 다를 수 있습니다.

정의를 첨부하지 않고 백분율만 보고하는 것. 분모와 기준이 없다면 수치는 아무런 의미가 없습니다. 잘 만들어진 KPI dashboard가 지표에 라벨을 붙이는 것처럼, 차트에 두 가지를 모두 표시하세요.

결론

대상 사용자를 결정하고, 사용 기준을 설정하고, 기간을 고정하고, 나누기 전에 사용자를 중복 제거하세요. 이 네 가지 단계를 거쳐야 기능 채택 백분율이 제품 팀이 실제로 활용할 수 있는 지표가 됩니다.

이 작업에 많은 리소스가 드는 이유는 제품이 변경되더라도 정의의 일관성을 유지해야 하기 때문입니다. 이벤트 이름 변경과 배포 범위 확대는 보고서를 직접 수정하지 않더라도 수치를 변화시킵니다.

보고서 작성 주기가 이 단계에서 정체되어 있다면, 사용량 내보내기 데이터에 try Powerdrill Bloom을 사용해 보세요. 또한 building a cohort retention chart 가이드, best AI tools for product analytics 모음, 그리고 CSV AI assistant 페이지도 참고해 보시기 바랍니다.

자주 묻는 질문

기능 채택(feature adoption)이란 무엇인가요?

정의된 기간 내에 기능을 사용한 대상 사용자의 비율을 의미하며, 이벤트 수가 아닌 고유 사용자 수로 측정됩니다. 이 정의는 분모와 사용 기준이 명확히 명시되어야만 유효합니다.

이벤트 내보내기 데이터에서 어떻게 계산하나요?

지정한 기간 내에 기능 이벤트를 발생시킨 고유 사용자 수를 세고, 이를 대상 사용자 수로 나눕니다. 한 명의 사용자가 수백 개의 이벤트를 발생시킬 수 있으므로 반드시 먼저 중복을 제거해야 합니다.

분모는 전체 사용자여야 하나요, 아니면 활성 사용자여야 하나요?

실제로 해당 기능에 접근할 수 있었던 대상 사용자 범위를 사용하세요. 전체 가입 사용자를 기준으로 삼으면 수치가 보수적으로 나오며, 배포 플래그 뒤에 숨겨진 실제 채택률을 과소평가하게 됩니다.

측정 기간은 어느 정도로 설정해야 하나요?

일반적인 사용 주기에 맞추어 충분한 기간을 설정해야 합니다. 매일 사용하는 제품의 경우 주간 단위로, 주기적으로 사용하는 제품의 경우 월간 단위로 설정하는 것이 좋습니다. 기간을 변경하면 수치도 달라지므로 보고서 전반에 걸쳐 이를 고정해 두세요.

분석 도구와 제 수치가 다른 이유는 무엇인가요?

보통 측정 기간이나 중복 제거 규칙의 차이 때문입니다. 문서화된 리텐션 계산 방식은 날짜 필터를 첫 번째 이벤트에만 적용하는 경우가 많으므로, 두 이벤트 모두에 필터를 적용하는 스프레드시트에서는 동일한 결과를 얻을 수 없습니다.