앰플리튜드
Amplitude로 "데이터 사용" 쉽게 하기
Team MAXONOMY ・ 2022.03.18
Amplitude(앰플리튜드)는 디지털 최적화 시스템입니다. Amplitude(앰플리튜드)는 팀이 어디에 투자를 해야하는지 결정할 수 있도록 돕습니다. 그런 다음 고객이 이러한 투자 관련 중요한 사항(예: 고객 충성도)에 미치는 영향을 파악할 수 있도록 도와줍니다. 측정, 전문 데이터베이스, 분석, 실험 및 추천을 하나로 모아 놓았습니다.
우리는 "데이터 사용"에 대한 의견을 나누어 보려고 합니다. Amplitude(앰플리튜드)는 데이터 사용에 도움이 되며, 데이터에 관심을 갖지 않는 고객들도 비슷한 문제에 직면하게 됩니다.
반드시 쉬워야 합니다.
쉽지 않다면 사람들은 떠나게 됩니다. “평소와 같은 (혹은, 어렵지 않은) 비즈니스”의 힘은 그만큼 강력합니다. 우리 모두는 영향력이 중요하다고 말합니다. 하지만 데이터를 잘 활용하고 있다고 스스로 자랑스럽게 내세우는 기업 조차도 기능 공장(Feature Factory)*이 되는 것을 경계하고 있을 정도로 더 중요한 것이 있습니다.
*기능 공장(Feature Factory): 고객의 문제를 해결하는 것보다 기능을 구축하는 데 중점을 둔 비즈니스를 일컫는 말로, 제품 관리 용어에서 ‘기능 공장’은 일반적으로 부정적인 의미로 사용됩니다. 제품이 고객의 공감을 얻지 못하여 개발 시간과 예산을 낭비하는 것은 물론, 경쟁사에 비해 입지를 잃고 비즈니스가 위험해질 수도 있습니다. (출처: ProductPlan, Feature Factory)
데이터를 쉽게 활용하기 위한 변화에는 오랜 시간이 걸려서는 안됩니다. 누군가를 방해하는 방향이 되어서도 안됩니다. 다른 팀에서 사용자의 기능을 측정하거나 데이터를 변환하는 것을 기다리기만 해서도 안됩니다. 이 분야의 전문가 혹은 특정 툴이 여러분에게 도움이 될 수도 있습니다.
중앙 집중식 게이트나 리뷰 게시판에 의존해서는 안됩니다. 협업이 쉬워야 합니다. 숙련된 분석가로부터 피드백을 받는 것이 쉬워야 합니다. 새로운 질문을 탐색하는 것도 쉬워야 합니다. 적합한 이벤트를 찾는 것도 쉬워야 합니다. 측정이 쉬워야 합니다. 형식의 안전성과 테스트도 쉽게 할 수 있어야 합니다. 투박한 트래킹 스프레드시트는 지양합니다. 일관된 네이밍으로 쉬워야 합니다. 실험 실행이 쉬워야 합니다. 의미 있는 데이터를 얻기 쉬워야 합니다.
쉽고, 또 쉬워야 합니다.
호기심부터 인사이트를 행동에 옮기기까지 가능한 한 문제 요소가 없어야 합니다. 이전에 Amplitude(앰플리튜드)와 Shreyas Doshi가 함께한 작업에서, Shereyas는 많은 대시보드가 있지만 대부분 사용되지 않는다고 말했습니다.
“우리는 이 대시보드를 만들기 위해 많은 노력을 했습니다. 하지만 이것을 보는 사람은 거의 없습니다.”
그는 데이터를 주시하기 위해 스스로 양식을 만들었습니다.
“그 중 하나가 메인 지표 대시보드입니다. 새 탭을 열거나 URL을 입력할 필요 없이 바로 확인할 수 있습니다. 또 하나 깨달은 점은, 사람들이 이메일 지표를 좋아한다는 사실입니다. 왜일까요? 마찰을 없애기 때문입니다.”
기술적인 작업에 많은 시간이 소요되어 "어렵다"는 생각을 하고 있지만, 이는 큰 오해입니다. "개발자를 괴롭히지 않기 위해" 컨텍스트와 속성을 제외한 모든 것을 포함하는 것은 해결책이 아닙니다. 이벤트를 트래킹하기 위해 코드를 추가하는 것은 간단합니다. 그것이 어렵다는 것은 잘못된 인식입니다. 측정을 보통의 작업 방식의 일부로 통합하면, 이는 또 다른 보통의 방식이 됩니다.
일부는 자신의 회사에서 특정 툴의 “전문가”만 측정을 계획할 수 있다고 말하기도 합니다. 하지만 이는 절대 사실이 아닙니다.
또 다른 큰 오해는 팀이 사전에 모든 질문에 동의해야 한다는 것입니다. 이 역시 잘못된 것입니다. 여러분이 명사, 동사, 형용사, 부사를 사용하여 만든 질문은 여러분과 계속 함께 갑니다. 소수의 몇몇 이벤트가 인사이트를 계속해서 제공하게 됩니다.
이 모든 것들은 실제 방해 요소에 비하면 별거 아닙니다.
- SQL을 알아야 하는 경우
- 일정이 너무 많은 경우
- 진행 상황 및 페어링에 대해 논의할 시간이 없는 경우
- 기본적인 인사이트를 다시 확인해야 하는 경우
- 대시보드가 불확실한 경우
- 데이터를 신뢰할 수 없고 자신이 없는 경우
- 비동기식 협업이 어려운 경우
- 이메일과 알림을 사용하지 않는 경우
- (외부의 도움을 받는, 혹은 스스로 하는) 온보딩이 없는 경우
- 문서가 없는 경우
- 구축할 수 있는 대표적인 작업이 없는 경우
- 재방문할 의사가 없는 경우
- 깊게 생각하고 고려할 시간이 없는 경우
그렇다면 무엇을 해야할까요? 다음의 과정부터 시작해보세요
모든 것을 쉽게 만드는 방법
- 매주 협업 세션을 진행합니다. 정기화하세요.
- 원격 측정 기능을 모든 영역에 포함하세요. 완벽한 질문을 만들어야 한다는 것에 대해 너무 걱정하지 마세요. 상황을 제대로 인식하기 위해 노력하면 됩니다.
- 이메일 등을 활용하여 리마인더와 알림을 만드세요.
- 가능한 모든 “데이터”를 통합하세요.
- 정기적인 데이터 관리 세션을 마련하여 데이터 관리를 쉽게 하세요.
다시 한 번 말하지만, 데이터를 사용하는 방법은 무조건 쉬워야 합니다.
팀맥소노미
YOUR DIGITAL MARKETING HERO
비즈니스 성장을 위한 최적의 솔루션과 무료 데모 시연, 활용 시나리오를 제안 받아보세요
24시간 프리미엄 열람권 받기
관련 글 보기
GA4 vs Amplitude 비교하기
데이터 분석 시대, GA4만으로 충분할까?이제 거의 모든 비즈니스에서 디지털 역량은 필수 요소로 자리잡았습니다. 전통적인 제조업부터, 리테일, 물류, 심지어 외식업까지 디지털 서비스가 배제되는 산업이 없는데요. 이제 소비자는 앱이나 웹을 통해 식당을 예약하고, 내 물건이 어디까지 배송되었는지 확인하고, 마트에 방문하기 전에 원하는 물건이 있는지 확인합니다.이런 환경 속, 고객 경험 이해는 기업 경쟁력의 핵심이 되었습니다. 고객이 우리 서비스 안에서 무엇을 하고 어떤 점을 좋아하고 어떤 점에 불만을 느끼는지 명확히 알 수 있다면, 최적화 전략을 쉽게 도출할 수 있기 때문입니다.고객 경험 이해를 위한 대표적인 도구로 GA4(Google Analytics 4)와 Amplitude가 있는데요. 그중 GA4는 현재 가장 많은 시장 점유율을 가진 분석 솔루션입니다. 아무래도 무료로 제공되던 구글의 UA(Universal Analytics)로 분석을 시작하는 기업이 많았고, UA 지원이 종료되며, 자연스럽게 GA4를 사용하게 된 것이 아닐까 추측됩니다.하지만 GA4에는 여러 아쉬운 점들을 찾아볼 수 있습니다. 예를 들어, 개인화된 데이터 추적이나 고객 라이프사이클 추적 영역에서는 기능이 다소 제한적입니다. 다른 3rd party 데이터와의 통합과 유연성 측면들에도 아쉬움이 많습니다.제품 분석 솔루션 역사 이해하기GA4가 왜 이런 영역에서 유독 약한 모습을 보이는지 이해하기 위해서는 분석 솔루션의 역사를 살펴볼 필요가 있습니다.사실 GA4의 근간이 되었던, UA는 디지털 광고, UTM과 같이 신규고객 유입(User Acquisition) 중심의 퍼포먼스 마케팅 솔루션입니다. 때문에 세션 기반의 로그 데이터를 수집하는 형태로 작동하였죠. 당시 마케팅은 유저를 최대한 많이 유입시키는 것에 초점이 맞추어져있었고, UA는 이에 최적화된 솔루션으로 인기가 많았습니다.하지만 Amplitude가 시장에 출시되고, 기존의 세션 기반이 아닌, 이벤트 기반의 데이터 분석 방식을 처음 제안하였습니다. 이벤트 기반의 데이터 분석은 특히 모바일 앱 환경에서 사용자의 면밀한 행동 분석을 가능하게 하였고, 모바일 시장의 성장과 함께 Amplitude도 폭발적으로 성장할 수 있었습니다. 이때부터 마케팅의 영역이 유저 유입을 넘어, 유저 활성화, 리텐션, 수익화 등 훨씬 넓은 영역으로 확장되었습니다.이런 변화에 맞추어 구글은 기존 UA를 종료하고, 이벤트 기반의 GA4를 새롭게 출시하였습니다. Amplitude에 비하면, 여전히 퍼포먼스 분석 위주의 기능을 제공하며, 유저 라이프 사이클을 추적하는 데 있어서 다소 아쉬운 모습을 보이고 있습니다.Amplitude는 단순 분석 도구가 아니다Amplitude는 단순히 데이터를 수집하고 시각화하는 도구가 아닙니다. 고객의 획득 > 참여 > 전환 > 유지 > 성장에 이르는 고객 여정 전체를 설계하고, 이 여정에서 획득한 데이터를 제품 기획자, 마케터, 개발자 등 누구라도 쉽게 다룰 수 있는 통합 디지털 경험 플랫폼입니다.실시간 개인화 및 실시간 데이터 분석 대시보드를 통해 A/B 테스트와 같은 실험을 설정하고, 그 데이터들을 곧바로 분석80개 이상의 마케팅 플랫폼들과 네이티브 연동을 지원하며, 채널별 획득 데이터들의 리텐션 효과 분석 가능고객 전체 여정의 분석에 최적화되어, 첫 방문부터 재구매까지 사용자 ID 기반으로 고객의 라이프사이클 분석 가능 현재 Amplitude의 대표적 고객인 버거킹은 과거에는 GA4를 이용했지만, Amplitude로 전환하고 통합된 데이터를 기반으로 실험과 지속적인 개인화를 실행하며 전환율과 재구매율을 끌어올리고 있습니다." 우리는 버거 회사입니다. 버거가 바로 우리의 제품입니다. 웹사이트가 아닙니다. 하지만 경쟁력을 유지하려면 단순히 와퍼를 판매하는 것 이상의 노력을 기울여야 합니다. 오늘날 우리는 그 어느 때보다 사람들이 버거킹 브랜드를 통해 어떤 경험을 할지, 그리고 그 경험이 의미 있고 감정적인 유대감을 형성할 수 있을지 고민하고 있습니다. " - 엘리 자비스, Restaurant Brands International(버거킹) 기술 제품 관리 부사장이미지 출처: Amplitude | 개인화된 할인을 제공하는 버거킹버거킹의 고객 여정 개선은 크게 다음의 프로세스들로 이루어졌습니다.오퍼(주문) CTA 클릭을 유도하는 A/B 테스트장바구니 금액 기준, 고객별 개인화된 할인 제공Amplitude 코호트 기능을 통해 이탈 및 특정 행동 고객에게 푸시 알림 발송마치며글로벌 대표 컨설팅펌 브레인 앤 컴퍼니(Bain & Company)의 연구 결과에 따르면, 80% 이상의 기업이 고객들에게 훌륭한 경험을 제공한다고 스스로 평가했지만, 실제 훌륭한 경험을 제공받았다 생각하는 고객은 단 8%에 불과했습니다.고객 유입 마케팅의 한계를 엿볼 수 있는 부분이자, 고객 경험 관리의 중요성을 대변해주는 자료입니다. 여전히 많은 마케터분들이 캠페인 성과 측정과 유입 분석을 위해 GA4를 이용 중일 것입니다. 하지만 유입 데이터만으로는, 구체적인 액션으로 연결하지 못하고, 고객을 제대로 이해하지 못합니다.바로 지금이 진정한 고객 경험을 이해하기 위한 최적의 시기입니다. Amplitude에 대해 궁금하신 게 있다면, Team MAXONOMY에 문의하세요. 성실히 안내 도와드리겠습니다. 문의하기콘텐츠 더 읽어보기[FAQ] GA에서 Amplitude로 전환하기UA 서비스 중단 대처 가이드북[FAQ] 구글 UA종료 & GA4 전환에 대해 궁금한 모든 것분석 솔루션, 여러 개 써도 되나요?
모바일 게임 리텐션(Retention) 바로알기 🎮
모바일 게임의 성과를 측정할 때 가장 중요한 지표는 아마 리텐션일 것입니다. 리텐션을 측정하는 기본적인 방식은 어느 서비스나 동일하지만, 서비스나 산업에 따라 그 특성에 맞는 상세한 리텐션 설정 기준과 측정 방법이 존재합니다. 모바일 게임 서비스도 마찬가지로 게임이라는 특성에 맞는 적합한 리텐션율 측정법이 있습니다.리텐션율은 크게 'N-day 리텐션율', 'Unbounded 리텐션율', 'Bracketed 리텐션율' 3가지로 나뉩니다. 이중 모바일 게임에 가장 많이 적용하는 지표는 N-day 리텐션율입니다. 이유가 무엇일까요? 이번 포스트에서는 모바일 게임에 적합한 리텐션 설정 방법과 그 이유에 대해서 알아보겠습니다.N-day 리텐션 vs Unbounded 리텐션N-day 리텐션은 사용자가 처음 앱을 사용한 이후, 지정된 날에 앱으로 돌아오는 비율을 말합니다. 예를 들어, 2일차 N-day 리텐션율이 50%라면, 새로운 유저의 50%가 2일차에도 앱을 실행했다는 것을 의미합니다. 반면, Unbounded 리텐션은 특정한 날짜에 앱으로 돌아오는 사용자의 비율이나 이후의 임의의 날짜를 측정합니다. 만약 2일차 Unbounded 리텐션율이 50%라면, 새로운 사용자의 50%가 2일차를 포함한 그 이후에 한번이라도 앱을 사용했다는 것을 뜻합니다.아래는 동일한 모바일 애플리케이션에 대한 N-day 리텐션과 Unbounded 리텐션(Rolling Retention)을 비교한 그래프입니다.그래프를 보시면 알겠지만, 두 지표 간의 차이는 상당히 큽니다. 이 사실을 모른채로 아무 리텐션 지표를 모니터링한다면, 중요한 비즈니스 의사결정에 큰 오류가 생길 수 있겠죠.Day 1을 기준으로 보면 N-day 리텐션은 43%로, 신규 유저 중 43%가 앱을 처음 사용한 후 첫 번째 날에 앱을 실행했다는 것을 의미합니다. 반면, Unbouded 리텐션은 59%로, 이는 새로운 사용자 중 59%가 Day1을 포함하여 그 이후의 어느 날이든 한번 이상 앱을 실행했다는 것을 의미합니다.N-day 리텐션을 사용하면, 앱을 가장 처음 실행한 이후 N일이 지난 시점까지 앱으로 얼마나 많은 사용자가 돌아오는지 정확한 비율을 알 수 있습니다. 따라서 모바일 게임같이 유저가 매일 플레이하는 것이 목표인 애플리케이션은 N-day 리텐션이 적합하다고 할 수 있죠.물론 N-day 리텐션이 항상 정답은 아닙니다. 어떤 케이스에서는 매일은 아니더라도 조금 긴 텀을 가지고 사용자가 돌아오는 것이 유의미할 수 있습니다. 대표적으로 모바일 임대료 결제 앱이라면, 사용자가 매월 한 번씩만 앱을 사용하여 결제를 하는 것이 앱 성공의 기준이 될 수 있겠죠. 이 경우에는 N-day 리텐션보다는 Unbouded 리텐션을 측정하는 것이 유용할 것입니다. 흔한 케이스는 아니겠지만, 특정 게임도 Unbouded 리텐션을 사용하는 것이 적합할 수 있습니다. 예를 들어 '텐텐 오락실'이라는 앱은 술자리나 많은 사람들이 모인 자리에서 다 함께 플레이하는 모바일 게임입니다. 이런 류의 게임의 경우, 유저가 매일 습관적으로 접속하길 기대하지 않겠죠.시간 기준 리텐션 VS 날짜 기준 리텐션N-day 리텐션과 Unbounded 리텐션 차이 외에도, 시간 기준과 날짜 기준으로 리텐션 계산 방법을 나눌 수도 있습습니다. 시간 기준으로 계산한다면, 각 사용자별 접속 시간을 기준으로 날짜를 구별합니다. 즉, Day 0는 사용자가 앱을 최초로 실행시킨 시간부터 24시간이 지난 시간인 0 ~ 24시간 사이를 의미하고, Day 1은 24시간부터 48시간 사이를 의미합니다. Day 1 리텐션율이 10%라고 가정해본다면, 1,000명의 사용자 중에서 100명이 각각의 처음으로 앱을 실행한 이후 24시간에서 48시간 사이에 앱을 한번 이상 더 실행했다는 것을 뜻합니다. 만약 사용자 X가 화요일 오후 4시에 처음으로 앱을 실행했다면, 수요일 오후 4시와 목요일 오후 4시 사이에 앱을 다시 열었다는 뜻입니다.반면, 날짜를 기준으로 계산할 때, 리텐션 차트는 그저 달력상의 날짜를 기준으로 측정됩니다. 만약 어떤 사용자가 10월 1일 오후 11시에 처음으로 앱을 실행했다면, 이 사람의 Day 0는 10월1일, Day 1는 10월 2일이 될 것입니다.아래 그래프는 앞서 살펴본 동일한 앱에 대한 시간 기준 리텐션과 날짜 기준 리텐션 수치입니다.처음 며칠 동안에 가장 뚜렷한 차이가 나타난다는 것을 알 수 있습니다. 날짜 기준 Day 1 리텐션은 43%인 반면, 시간 기준 Day 1 리텐션은 32%에 불과합니다. 하지만 시간이 흐름에 따라, 두 그래프 간의 차이는 줄어들고 이 둘을 구별하는 의미는 많이 사라진다고 볼 수 있습니다.시간 기준과 날짜 기준을 구별하는 이유시간이 흐름에 따라 구별 의미가 줄어들면 굳이 이 두 지표를 나누는 이유가 있나 궁금해질 겁니다. 하지만 우리가 리텐션 지표를 평가할 때는 보통 앱 출시 초기에 다른 앱의 리텐션 지표와 비교하는 식으로 많이 진행합니다. 이 때, 다른 기준의 리텐션 지표를 비교하면 분명 큰 오류가 생기겠죠. 빠르게 시장 반응을 살피고 대응해야하는 앱 출시 초기에는 이 오류가 치명적으로 작동할 수 있습니다.예를 들어, 모바일 게임 초기 버전을 런칭한 후 Day 1 리텐션율이 32%라고 가정해봅시다. 이것만으로는 리텐션이 잘 이루어지고 있는지 판달할 수 없겠죠. 최대한 유사한 게임과 리텐션율을 비교해보아야합니다. 만약 이 때, 시간 기준과 날짜 기준 리테션 지표를 잘못 비교한다면, 제대로된 벤치마크가 되지 않겠죠.결국 어떤 지표로 모바일 게임을 측정해야하나요?리텐션 지표에 정해진 정답은 없습니다. 그렇지만 일반적인 경우에는 날짜 기준 리텐션보다는 시간 기준 리텐션이 더 정확한 현황을 보여준다고 할 수 있습니다. 하지만 시간 기준 리텐션은 정확한 데이터를 얻는데 하루 더 걸린다는 단점이 있습니다. 앱 출시 초기라면 하루 일찍 대응하는 것의 차이가 큰 결과 차이를 만들 수 있죠.정리하자면, "일반적인 모바일 게임이라면 N-day 리텐션을 측정하는 것이 좋지만, 간혹 매일 들어오는 것을 원하지 않는 게임일 경우 Unbounded 리텐션 지표를 사용하는 것이 좋을 수 있으며, 또 기본적으로 시간 기준 리텐션을 측정하는 것이 정확하나, 데이터를 더 빨리 얻어야 할 때는 날짜 기준 리텐션을 먼저 살펴보는 것이 좋다." 정도가 될 것 같습니다.다시 한번 말하지만 리텐션에 정해진 정답은 없으며, 각 지표가 정확히 무엇을 측정하는 것인지 알고 있다면, 어떤 상황에서든 데이터 기반의 유의미한 인사이트를 도출할 수 있을 것입니다.콘텐츠 더 읽어보기고객 리텐션 마스터 가이드북리텐션(Retention) 의미와 측정 방법🔍리텐션 캠페인 효과를 최대화하는 8가지 방법
북극성 지표(North Star Metric) 설정하기
북극성 지표(North Star Metric)를 이해하고 제대로 설정하는 활용 방법 AtoZ
Amplitude Feature Experiment: 데이터 기반 실험의 시작
실험이 중요한 이유디지털 서비스를 운영하다 보면 다음과 같은 질문과 마주하게 됩니다. “이 버튼을 바꾸면 클릭률이 더 높아질까?” “새로운 기능을 모든 사용자에게 바로 공개해도 될까?” “프리미엄 사용자에게만 실험적으로 먼저 공개해보고 싶은데, 어떻게 관리하지?”대부분 경우 직감이나 내부 회의로 결정을 내리지만, 그 결과가 실제로 사용자 경험과 KPI에 긍정적인 영향을 주는지 알기 어렵습니다. 이로 인해 향후에 추가적인 실험 테스트를 수행하기 어려운 환경이 조성되어 버리기도 합니다.또한, 서비스를 운영하다보면, 서비스의 성장을 위해 여러 고민과 의사결정이 필요한 순간이 옵니다.✅ 새로운 기능을 모든 사용자에게 배포하기엔 위험할 때✅ 디자인이나 UI를 바꾸고 그 효과를 정확히 측정하고 싶을 때✅ 특정 사용자 그룹에게만 실험적으로 기능을 보여주고 싶을 때✅ 실험 결과를 클릭률, 전환율, 리텐션율 등의 지표로 분석하고 싶을 때따라서, 개발단의 리소스를 최소화하면서, 실제 사용자 데이터 기반의 결과 분석이 가능한 실험 체계를 도입할 필요가 있습니다. Amplitude Experiment는 고객에게 제공하는 기능 on/off 토글링부터 A/B 테스트, 점진적 릴리즈, 결과 분석까지 하나의 워크플로우 안에서 지원함으로써 "기능 실험 → 결과 측정 → 의사결정"을 오차없이 빠르게 수행할 수 있도록 도와줍니다.Amplitude Experiment에서는 다음 두 가지 방식으로 실험을 구성할 수 있습니다.Feature ExperimentWeb Experiment이름만 보아서는 비슷해 보이지만, 실제 사용 목적과 운영 방식에는 뚜렷한 차이가 있습니다. 이번 포스팅에서는 이중 Feature Experiment에 대해 집중적으로 알아보겠습니다.Feature Experiment: 기능 중심 실험Feature Experiment는 코드 기반으로 운영되는 실험 방식입니다. 개발자가 직접 고객에게 보여줄 화면을 만들거나 신규 기능을 구현한 후에 이것을 일부 고객들에게만 노출하고 원하는 효과를 보았는지 확인하고자 할 때 활용합니다.개발단에서는 변경된 화면이나 기능을 적용하고 예외 처리를 추가하여 특정 사용자에게만 노출될 수 있도록 구현하고, 실무자는 원하는 고객군과 모수 비율을 Amplitude 콘솔에서 언제든 수정하여 테스트를 수행 해 볼 수 있습니다.개발단 기능- 화면 구성- 조건 처리실무단 기능- 모수집단 선정, 비율 선택- 전환 목표 지정, 분석 방식 선정- 테스트 시작, 종료, 기간 선정- 실험 분석 결과 확인- Analytics로 추가 심화 분석 수행예시로 이해하는 Feature Experiment 활용1) 신규 기능 가설 세우기어느 날, 개발자가 추천 알고리즘 로직 개선 작업을 완료 하였습니다. 이 알고리즘을 서비스에 적용하면 굉장한 효과를 보여줄 것이라 기대하고 있지만, 바로 운영계에 적용하기에는 어떤 사이드 이펙트가 있을지 예상할 수 없었습니다. 가령 잘못된 상품 추천으로 고객에게 안 좋은 경험을 제공하면 이탈로 이어질 수 있죠.따라서, 전체 고객이 아닌, VIP 고객 중 10%에게만 새 알고리즘을 적용하고 클릭률, 구매율을 측정하기로 하였습니다. 결과 데이터가 나머지 고객들에 비해 5%이상 증가한다면 전체 사용자에게 확대 배포하는 거죠.2) 개발단 작업처음 실험을 진행하는 것이라면 Amplitude Experiment SDK를 적용하는 작업이 필요합니다. 신규 추천 알고리즘은 이미 개발 완료된 상황이고 SDK 적용은 큰 시간이 소모되지 않기 때문에 거의 바로 실험 진행이 가능합니다.(Amplitude Experiment SDK 라이브러리 탑재 및 초기화 후 고객마다 서로 다르게 제공하고자 하는 위치에서 조건문(if)을 구성)Android 적용법1. 라이브러리 추가 (build.gradle에 dependencies 추가)2. 초기화 (Application단에서 초기화)3. 현재 사용자의 experiment 관련 정보 수신4. 고객이 보유한 flag 값에 따라 제공 여부 결정( 새로운 추천 알고리즘이 제공될 10%의 VIP 고객은 "on"으로, 그 외 고객들은 모두 "off"로 적용)3) Amplitude 설정(Experiment UI 구성)3-1) Deployment 생성하기운영하는 서비스는 여러 환경으로 구분되어 있습니다.개발계(development) / 내부 QA 테스트 수행 환경(staging) / 운영 환경(production)Android, iOS, Web 등 제공 플랫폼 환경실험을 진행하고자 할 때, 특정한 환경에서만 진행하실 수도 있고, 여러 환경에서 동시에 진행해 보실 수도 있을 겁니다. 이 때, 어떤 환경에 실험을 배포할 것인지를 정의할 수 있도록 "Deployment"라는 작업이 필요합니다.하나의 프로젝트 내에서 배포할 환경마다 각각의 Deployment를 생성해주시면, 실험을 진행할 때, 이 실험을 어떤 환경에만 배포할지 지정할 수 있습니다.Experiment > Deployments 화면에서 제공하는 “Create Deployment”를 클릭하고 배포할 환경의 이름과 프로젝트를 선택하면 바로 Deployment 생성이 가능합니다.3-2) Experiment 생성하기이제 기본적인 세팅은 모두 완료 되었으니 실험을 만들어 볼 수 있습니다!Experiment > Experiments 메뉴에서 새로운 실험명과 사용할 키 값을 정하신 후 생성(Create)합니다.4) 실험 설계4-1) 목표 설정하기실험을 만들 때 가장 먼저 생각해야 할 부분은 "목표" 설정 입니다. 실험을 한다는 것은 결국, 무언가를 더 좋게 만들기 위해서이기 때문에, 반드시 “이 실험을 통해 무엇이 좋아지기를 기대하는가?”에 대한 기준이 필요하며, 그것이 바로 목표 설정입니다. 우리가 설정한 목표를 달성했는지 여부를 가지고 이번 실험의 성공 여부를 파악해 보실 수 있겠지요.목표는 기존에 만들어 두었던 지표를 선택하실 수도 있고, 원하는 목표를 새롭게 생성하실 수도 있습니다.Unique, Event Total, Conversion 등 분석에서 활용해 보셨던 다양한 지표 옵션을 기반으로 목표 설정이 가능한데, 이번 실험에서는 클릭율이 5% 이상 증가하는 것을 목표로 잡았기 때문에, "화면 진입 > 버튼 클릭"으로의 전환율이 5% 이상 상승하는 것을 목표로 설정했습니다.4-2) 대안(Variant) 등록하기비교 테스트를 진행할 때, 대안은 하나일 수 있지만 여러 개가 있을 수도 있습니다. "내가 테스트하고 싶은 기능의 버전은 몇 가지이며, 각각 어떤 차이가 있을까?" 테스트 하고자 하는 대안의 수 만큼 Add a Variant 옵션으로 추가하여 정의할 수 있습니다. (단, 너무 많은 Variant는 분석을 어렵게 하므로 2~4개 이내를 권장합니다.)각 Variant의 Value 값은 SDK에서 분기 처리에 사용(e.g. variant.value)되므로 개발단에서 미리 지정하신 값이 있을 경우, 해당 값으로 기입되어야 하며, 미리 정의되어 있지 않았다면 여기에서 정의하시는 값으로 개발단의 코드 작업이 수행되어야 합니다.※Value 값이 수정될 경우, 앱의 재배포가 필요하므로 처음 생성 시 Amplitude에서 허용하는 명명규칙(숫자, 영문, 언더스코어, 하이픈만 허용)을 참고하시어 향후 변경하지 않을 값으로 지정이 필요합니다.4-3) 고객 그룹(Targeting) 정의하기[Audience]실험에 활용할 대안을 등록했다면, 누구를 대상으로 실험을 진행할 것인지 모수 집단을 선택하실 수 있습니다. All Users를 선택하여 전체 고객을 모수 집단으로 선정할 수 있으며, Target Users를 선택하여 특정 모수집단을 Segment로 정의할 수 있습니다.[Distribution]선정한 모수 집단을 각 대안에 어느 정도 비율로 할당 할것인지 지정할 수 있습니다. 기본 옵션인 evenly distribute로 동일한 비율로 지정하는 것을 권장 드리며, 원하실 경우 Customize 옵션으로 수동 설정이 가능합니다.(control로 할당되는 고객들은 실험에 참여는 하지만 실제로는 변경된 대안 UI가 노출되지 않는 그룹으로써, 대조군의 역할을 수행합니다.)[Rollout]지정하신 모수 집단 전체를 대상으로 실험을 수행하실 수도 있으나 그 중 일부를 대상으로만 진행하는 것도 가능합니다. Rollout 설정을 통해 전체 모수 집단 중 몇 %에 해당하는 고객들을 대상으로 실험을 진행할 것인지 범위를 지정할 수 있습니다.(Control vs. Rollout: control에 포함된 고객은 실험에 포함되어 향후 결과 분석 시 대조군 역할을 하지만, Rollout에서 제외된 고객은 실험 자체에 포함되지 않으므로 결과 또한 추적되지 않습니다.)5) 전달 구성5-1) Flag & Evaluation 정의Flag는 실험을 식별하는 고유 식별자로써, 실험을 생성하시는 시점에 key 항목으로 기입한 정보를 확인하실 수 있으며, 실험 시작 전까지는 변경이 가능합니다. 이 값은 SDK에서 실험 정보 요청에 사용(e.g.FLAG_KEY) 되므로 개발단에서 미리 정하신 값이 있다면 그 값으로, 없다면 여기에서 정의된 값으로 개발단의 코드 작업이 수행되어야 합니다.Evaluation Mode는 고객이 어떤 대안에 해당 되는지를 어디에서 계산할 것인지 선택하는 항목입니다. 일반적으로는 Amplitude에 수집된 정보를 실시간으로 확인하여 결정되나, 실시간 검토 방식은 통신 상의 약간의 딜레이(0.1~1초)가 발생하므로, 고객에게 즉각적으로 노출되어야 하는 UI에 대해서는 로컬에서 계산하는 방식을 선택하실 수도 있습니다.5-2) 배포 환경(Deployment) 선택지금까지 작성한 실험을 어떤 환경에 배포 할 것인지를 선택합니다. 특정 플랫폼이나 개발환경에만 적용하고자 하실 경우, 해당하는 deployment만 선택하여 배포가 가능합니다.6) 실험 시작모든 세팅을 완료했다면, 우측 상단 버튼을 이용하여 각 플랫폼 별로 적용할 수 있는 샘플 코드를 확인할 수 있습니다. 개발 담당자에게 해당 정보를 전달하여 적용을 요청할 수 있습니다.실험을 고객들에게 배포하기 전, 미리 등록해 둔 테스터만을 대상으로 선행적으로 배포가 가능하며, 예약 실행이나 feature flag만 활성화하고 실험 분석은 수행하지 않는 등 여러 옵션을 정의해 보실 수 있습니다.모든 사항의 확인이 완료되었다면, 최종적으로 Start Experiment를 클릭하여 실험 시작이 가능합니다. 실험을 종료할 때에는 초기 버전으로 롤백을 할 것인지, 아니면 특정 대안( Variant )으로 적용할 것인지 선정하여 실험을 마칠 수 있습니다.실험이 진행되는 동안 발생한 실험 참여(Assigentment), 실험 노출(Expouse) 및 목표로 잡은 정보들은 모두 고객별 프로필에 저장되므로 이를 기반으로 심층 분석(Analytics)을 바로 수행해 볼 수 있습니다. 또한, 처음 목표로 잡았던 것 이외에도 각 그룹별로 어떠한 변화가 있었는지 수집된 데이터를 기반으로 분석이 가능합니다.실험과 분석을 하나의 플랫폼 안에서실험과 데이터 분석은 이제 더 이상 따로 작업할 필요가 없습니다. 기존 A/B 테스트 도구들이 단순히 실험을 “실행”하는 데 집중했다면, Amplitude Feature Experiment는 실험 설계부터 분석, 최종 반영까지 추가적인 개발단 작업없이 한 번에 처리할 수 있는 실험 플랫폼 체계를 제공합니다.CUPED, Sequential Testing, Bonferroni 등 실험의 정확도를 높이는 기능이 기본으로 탑재되어 있어, 적은 트래픽으로도 빠르게 유의미한 결론을 얻을 수 있으며, Amplitude Analytics와 완벽히 연결되어 언제든 전환율,리텐션, 코호트 분석 등 심층적인 결과 분석을 바로 이어나갈 수 있습니다.또한 클라이언트 배포 없이, 서버-사이드 실험 연동을 지원하므로 고객들에게 끊김없는 실험 환경 제공이 가능합니다. 제품의 성과를 빠르게 검증하고, 그 결과를 정확히 해석해 다음 의사결정으로 이어가고 싶다면, Amplitude Feature Experiment는 더없이 강력한 선택이 될 것입니다.Feature Experiment 활용에 도움이 필요하나요?팀 맥소노미 Amplitude 도입문의 바로가기 콘텐츠 더 읽어보기A/B테스트 개념과 데이터 분석 방법🔍Amplitude 실험 전략 가이드북A/B테스트 마케팅 실전 가이드북