회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
AWS 이용 중이라면 월 최대 15% 할인받으세요
[프로덕트 지표 설정 프레임워크] ① 프록시(Proxy) 지표
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!
확인
[프로덕트 지표 설정 프레임워크] ① 프록시(Proxy) 지표
요즘IT 독자 여러분 안녕하세요, 김민우입니다. 앞으로 일곱 편에 걸쳐서 여러분께 지표를 이해하는 데 도움이 되는 생각법과 프레임워크를 소개해드리겠습니다. 지표에 대해 공부하다 보면 흔히 접하게 되는 이야기들이 있는데, 거기서 한 단계 더 깊이 들어간 내용을 알려드리고자 기획한 내용입니다.
가장 먼저 소개해 드리고 싶은 개념은, 지표의 스펙트럼입니다.
구체적이고 직접적인 지표에서부터 추상적이고 간접적인 프록시(proxy) 지표까지, 지표는 다양한 스펙트럼 위에 존재합니다. 개념적인 이야기라 ‘무슨 소리지’ 싶으실 텐데요, 예를 들어서 설명해 보겠습니다.
다음 세 가지 지표를 비교해 보겠습니다.
1번, ‘지난 7일 동안 회원 가입한 유저’라는 지표는 굉장히 구체적입니다. 회원 가입이라는 건 명확한 사용자 행동으로 나타나는 거니까 여기에 어떤 가정 같은 게 들어갈 여지가 없죠. 그냥 회원 가입을 완료한 사용자 숫자를 카운트하기만 하면 됩니다.
2번, ‘지난 7일 동안 신규로 활성화(activated)된 유저’라는 지표는 조금 덜 구체적입니다.
이런 지표를 정의할 때는 ‘활성화’란 무엇인가를 정의해야 합니다. 회원 가입을 한 다음에 어디까지 기능을 이용하면 활성화가 된 것인지, 프로덕트 팀 안에서 논의를 해야 합니다.
여기서 활성화의 기준을 정하는 데 단 하나의 정답이 존재하지는 않습니다. 팀이 논의해서 가장 적합하다고 판단하는 기준을 사용해야 합니다.
이처럼 ‘지난 7일 동안 신규로 활성화(activated)된 유저’라는 지표는, ‘지난 7일 동안 회원 가입한 유저’와 비교하면 더 가정이 들어가게 되는, 간접적인 지표입니다. '유저가 이런이런 행동을 하면 활성화된 것이다' 하는 가정이 들어가는 거죠.
3번, ‘지난 7일 동안 프로덕트에 인게이지(engaged)된 유저’라는 지표는 좀 더 간접적인 지표입니다.
활성화 같은 경우에는 그래도 ‘사용자가 특정한 마일스톤에 도달했을 경우 활성화된 것이다’라는 기준을 세울 수 있는데, 인게이지먼트의 경우에는 조금 더 애매합니다.
이 지표는 아까 봤던 활성화된 사용자 지표보다 더 가정이 많이 들어가는, 좀 더 간접적인 지표입니다. ‘인게이지(engaged)된 사용자는 이런 사용자이다’ 하는 가정이 들어가는 거죠.
이렇게 가정이 많이 들어간 간접적인 지표를 프록시(proxy) 지표라고 부릅니다. 우리가 알고 싶은 것은 ‘활성화된 사용자’가 몇 명인지, ‘인게이지된 사용자’가 몇 명인지인데, 그걸 직접 측정하기는 어렵습니다. 그래서 다른 대체물(proxy)을 지표로 설정해서 측정합니다.
위와 같이 ‘OOO하면 활성화된/인게이지된 사용자라고 간주한다’라는 가정을 세워서 지표를 설정하는 거죠.
사실 지표를 설정할 때, 회원가입자 수처럼 구체적이고 직접적인 지표를 설정하는 것은 크게 어렵지 않습니다. 회원가입자 수, 구매 결제 플로우의 전환율, 매출 같은 건 그냥 측정하면 되는 거죠. 설정하기 어려운 것은 간접적인 프록시 지표들, 가정이 들어가는 지표들입니다.
아까 설명드린 것처럼 활성화된 사용자, 인게이지된 사용자 같은 지표를 설정할 때도 가정이 들어가죠.
프로덕트의 인게이지먼트 지표를 볼 때, 어떤 팀들은 ‘파워 유저, 코어 유저, 캐주얼 유저’ 같은 식으로 유저를 세그멘테이션하고 싶어 합니다. 이런 유저 세그멘테이션에도 역시나 정답이 없습니다. 파워 유저를 정의한다고 할 때, 1주일 중 7일 내내 이용해야 파워 유저인지, 아니면 특정 기능을 여러 번 이용해야 파워 유저인지, 아니면 오랜 시간을 이용해야 파워 유저인지 같은 논의를 팀 안에서 해야 하죠. 여기에도 정답은 없습니다. 팀의 가정을 통해 정의해야 하는 거죠.
그러면 이렇게 정답이 없는 프록시 지표를 설정할 때, 우리는 어떤 마음가짐으로 접근해야 좋을까요?
아까 말씀드린 것처럼 우리는 뭔가를 측정하고 싶은데, 그걸 직접 측정하기가 어렵습니다. 그래서 측정하고 싶은 대상의 대체물로서 지표를 발명해 냅니다. 이 글에서는 우리가 측정하고 싶은 대상을 ‘the thing’이라고 부르고, 그 대상의 대체물을 ‘프록시’라고 부르겠습니다.
조금 다른 얘기지만, 건강검진의 예를 들어 볼게요. 신체검사를 해서 내 체중이 적정 수준인지, 내가 어느 정도 비만한지 알고 싶습니다. 여기서 ‘내가 비만한 정도’가 우리가 측정하고 싶은 the thing이라고 해 보겠습니다. 그런데, 비만한 정도라는 게 측정하기가 참 어렵습니다. 눈으로 봐서 체격이 호리호리해 보이면 비만하지 않은 거고, 눈으로 봐서 체격이 조금 펑퍼짐해 보이면 비만한 거라고 할 수 있을까요? 어느 정도 체격이면 비만이고, 어느 정도 체격이면 비만이 아닌 걸까요? 눈으로 보이는 체격, 눈짐작은 너무 주관적이기 때문에 사람들은 몇 가지 방법을 발명해 냅니다.
체질량지수는 몸무게(kg)를 키(m)의 제곱으로 나눈 겁니다. 키가 180cm이고 몸무게가 70kg인 사람 A의 체질량지수는 70/(1.8)^2 = 21.6입니다. 키가 170cm이고 몸무게가 70kg인 사람 B의 체질량지수는 70/(1.7)^2 = 24.2입니다. A와 B는 키도 다르고 체형도 다르겠지만, 이 수치에 따르면 B가 A에 비해 비만도가 어느 정도 높은지 비교할 수 있습니다. 체질량지수라는 프록시를 통해서 the thing, 이 사람이 얼마만큼 비만한지 파악할 수 있습니다.
그런데, 체질량지수에는 문제가 있습니다. 스켈레톤 국가대표로 유명한 윤성빈 선수는 프로필에 따르면 키 178cm에 몸무게 90kg인데, 이러면 체질량지수는 28.4로 비만으로 나옵니다. 근육량이 많으면 몸무게가 많이 나올 수밖에 없기 때문입니다.
비만도를 측정하기 위한 또 다른 프록시로는 WHR, 허리-엉덩이 둘레 비율이라는 게 있습니다. 허리둘레를 엉덩이둘레로 나눈 값인데요. 높으면 비만인 겁니다.
그런데 이 지표에도 몇 가지 한계가 있습니다.
일단 측정 오차가 생길 수 있습니다. 이를 측정하려면 허리둘레도 재고, 엉덩이둘레도 재야 하는데요. 하나를 잴 때도 오차가 발생할 수 있는데, 두 개를 재서 비율을 계산해야 하니까 오차가 많이 발생하게 되죠. 그리고 해석하기 어렵다는 문제도 있습니다. WHR이 높은 이유가 복부지방이 많아서일 수도 있고, 엉덩이 근육이 부족해서일 수도 있기 때문입니다. 어쨌든 이것도 the thing, 비만한 정도를 직접 측정할 수 없으니 사용하는 프록시 중 하나입니다.
비만도를 측정하기 위한 또 다른 프록시로는, 일명 인바디라고 부르는 생체 전기 저항 분석이 있습니다. 인바디는 우리 몸에 약한 전류를 흘려보내서 체성분을 분석해 내는 전자기기인데, 지방과 근육의 저항값이 다르기 때문에 몸의 몇 퍼센트가 지방이고 몇 퍼센트가 근육인지 추산해 낼 수 있다고 합니다. 인바디를 통해서 우리는 몸의 몇 퍼센트가 지방인지 추산할 수 있고, 이를 통해 비만한 정도를 알아낼 수 있습니다. 하지만 인바디도 완벽한 방법은 아닙니다. 인체의 수분은 질병, 탈수, 체중감량 등으로 인해 줄어들 수 있기 때문에, 이런 경우에 정확도가 감소한다는 문제가 있습니다. 이렇듯, BMI과 WHR, 인바디 등의 프록시에는 모두 나름의 부정확성, 나름의 한계가 있습니다.
하지만 모두 유용한 지표입니다. 비만한 정도, 체지방과 근육량 등을 완벽히히 측정할 수 없다고 한탄하며 아무 것도 안 하는 사람과, BMI나 WHR, 인바디 지표를 측정하고 개선하려고 노력하는 사람 중 누가 더 건강해질 가능성이 높을까요? 아무래도 지표를 측정하고 개선하려고 노력하는 사람일 것입니다.
그래서 이 이야기의 교훈은, 우리가 원하는 것을 완벽하게 측정할 수 없다고 하더라도, 가능한 프록시 지표를 측정하는 것부터 시작하는 게 좋다는 것입니다.
프로덕트에서 지표를 설정할 때도 마찬가지로 생각해 볼 수 있습니다. 프로덕트에서도 우리는 뭔가를 직접 측정할 수 없을 때 프록시를 이용합니다.
예를 들어, 이메일 뉴스레터를 발송하는 SaaS의 프로덕트 매니저가 이런 고민을 하고 있다고 해 보겠습니다. “우리 서비스에 회원가입한 사용자들 중 어떤 사람들은 프로덕트를 제대로 이용해 보고 우리가 제공하는 핵심 가치가 무엇인지 느낄 테고, (이걸 아하 모먼트aha moment를 경험한다고 하죠) 반대로 어떤 사람들은 핵심 가치를 느끼지 못하고 이탈해 버릴 텐데… 회원가입한 사용자 중 몇 퍼센트가 우리 프로덕트의 핵심 가치를 느끼는지 알고 싶다.”
그런데, 사용자들이 프로덕트의 핵심 가치를 느끼는 것, 사용자들이 아하 모먼트’를 경험하는 것은 직접 측정하기가 어렵습니다. 한 사람 한 사람에게 ‘우리 프로덕트의 핵심 가치를 느끼셨나요?’, ‘아하 모먼트를 경험하셨나요?’ 하고 물어볼 수도 없는 노릇이구요. 이럴 때 프로덕트 매니저는 the thing, 사용자들이 아하 모먼트를 경험했는지 직접 측정할 수 없기 때문에 프록시로서 지표를 만들어 냅니다. 이런 식으로 말이죠.
그런데, 이 지표는 the thing을 측정하는 완벽한 지표라고 할 수는 없습니다. 왜냐면 이메일 편집기 페이지에 진입했다고 해서 반드시 아하 모먼트를 경험했다고 할 수는 없기 때문입니다. 어떤 사용자는 그냥 이것저것 눌러 보다가 이메일 편집기에 진입하고, 이메일 편집기에서 별다른 행동을 하지 않을 수도 있습니다. 이런 사용자는 아하 모먼트를 경험했다고 할 수 없죠. 또 어떤 사용자는 이메일 편집기에 진입해서 이래저래 편집을 해 봤는데, 프로덕트 매니저의 바람과는 달리 이메일 편집기에 만족하지 못할 수도 있습니다. 좀 더 프로페셔널한 기능을 가진 편집기를 기대했는데, 초보자들이 쓰기 쉬운 심플한 편집기라서 오히려 불만족할 수도 있죠. 이런 사용자 역시 아하 모먼트를 경험했다고 할 수 없습니다.
하지만 이렇게 완벽하지 못한 프록시라고 하더라도 충분히 가치가 있습니다. 프로덕트 팀이 1-week activation rate 지표에 집중하고, 이 지표를 개선하기 위해 전력질주해 본다고 해 볼게요. 더 많은 사용자들이 이메일 편집기를 이용하게 하기 위해 여러 가지 방법을 쓰면서 30%였던 지표가 40%를 지나 60%, 70%까지 도달했다고 해 보겠습니다. 모르긴 몰라도, 이전에는 이메일 편집기를 이용해 보지도 않고 이탈했을 사용자들 중 많은 사람들이 이메일 편집기를 경험해 보게 되고, 이 서비스가 괜찮구나 하고 생각하게 되고, 이로 인해 다른 지표들도 개선될 겁니다.
이와 비슷한 사례가 그 유명한 페이스북의 아하 모먼트 지표입니다. 페이스북은 초창기에 여러 가지 그로스 실험을 했는데, 그중에서도 특히 유명한 것이 ‘신규 사용자 중 가입 후 10일 내로 7명 이상의 친구를 맺는 사용자’ 지표를 활용한 실험입니다. 신규 사용자들 중 10일 이내로 7명 이상의 친구를 맺는 사람들은 그렇지 않은 사람들에 비해 훨씬 리텐션율이 높았다는 데서 비롯된 것인데요. 페이스북 그로스 팀은 다른 것들은 제쳐두고 이 지표를 높이기 위해 전력질주했고, 이로 인해 굉장히 리텐션율을 개선할 수 있었다고 합니다.
그런데, 사실 ‘10일 이내로 7명의 친구를 맺는다’ 라는 지표는 기술적으로 또는 통계적으로 완벽한 지표는 아니었고, 어느 정도 자의적으로 정한 프록시였다고 합니다. 어쩌면 10일에 7명이 아니라 11일에 8.5명이 더 통계적으로 완성도 높은 프록시였을지도 모릅니다. 하지만 여기서 중요한 건 통계적으로 완벽한 프록시를 만드는 게 아닙니다. 여기서 중요한 건 통계적으로 혹은 기술적으로 완벽하지는 않을 수 있어도, 우리가 측정하고 싶은 the thing을 어느 정도 반영할 수 있는 프록시 지표를 만들고, 그 프록시 지표를 중심으로 팀이 한 점에 집중해서 프로덕트를 개선하는 노력을 했다는 점입니다.
그러니 여러분도 지표를 정할 때, 너무 어렵게 생각하지 않고 일단 우리가 할 수 있는 수준에서 시작한다는 마음가짐을 갖고 시작하시면 됩니다. 일단 지금 현재 수준에서 최선을 다해서 고민을 해서 프록시 지표를 정하시는 겁니다. 그리고 그 지표를 개선하기 위해서 팀이 전력질주하는 것. 그거면 시작하는 데는 충분하고도 남습니다. 이후에 점점 더 우리 제품, 우리 데이터에 대한 이해도를 높여 가면서 더 나은 프록시를 만들어 내면 됩니다.
지표 설정은 100% 과학의 영역이 아닙니다. 아트(art)의 영역이기도 합니다. 사업에서 지표를 설정하는 것은 100% 확실한 진리를 탐구하는 것이 아닙니다. 지표를 설정하는 것은 성과를 내기 위해서입니다. 지표가 어느 정도 엄밀함이 떨어지더라도, 사업 성과에 도움이 될 수 있다면 그 지표는 유용합니다. 반대로 지표가 아무리 기술적으로 엄밀하게 설정되더라도, 사업 성과를 개선하는 데 도움이 되지 않는다면 그 지표는 무용합니다.
지표를 엄밀하게 설정하는 기술도 중요하지만, 그보다 훨씬 더 중요한 것은 팀을 한 군데에 집중하도록 만드는 것입니다. 이걸 위해서는 팀 구성원들이 납득할 수 있게 만드는 스토리텔링, 그리고 팀 구성원들이 모두 이 지표에 집중해서 실행하게 만드는 영향력, 그리고 리더십 등의 역량이 필요합니다. 과학보다는 아트의 영역이죠. 데이터에 대해 고민하는 분들이 이 점을 잊지 않으셨으면 합니다.
다음 글에서는 5가지 지표 설정 프레임워크를 소개하고, 그중에서도 첫 번째로 ‘획득(Acquisition)’ 지표를 알아보도록 하겠습니다.
요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.