Product Analytics 201
1장 Data in action: A model of a Dinner Party (2)
이전 글과 이어집니다.
리뷰
Social Process 는
- 풀어야하는 문제보다는 이해해야 하는 과정으로 보는게 더 적합합니다.
- Open system (개방계)으로써 영향을 줄 수 있는 외부 요인이 매우 많습니다.
- 정확하게 정의된 Outcomes 가 없습니다.
- 불완전하고, 때때로는 일방적인 정보의 문제가 있습니다.
- 어떤 것이 왜 일어났는가 (인과관계)를 추측하는 것은 거의 불가능합니다.
파티로 알아보는 Social Process의 특징
1. A Party is a Process
저녁파티는 AI / ML을 적용 할 수 있는 분류의 문제로 보긴 어렵습니다. 가령 주어진 사진이 사람인지 개인지 를 구분한다면 털이 있는 지, 코의 모양은 어떠한지 등의 정해진 특징 (벡터화 되었더라도) 을 통해 알 수 있지만. 파티에 만족했다 안했다는 사람마다의 기준도 애매하고 여러 상호작용과 단계별 이벤트로 구성되어 있어 어렵습니다.
어떤 질문이 좋은 질문 일까요?
만약 파티 전문가 라면 , 조금 더 좋은 파티를 정의하는 컨텍스트가 있을 수 있지만, 여전히 전체의 긴 이벤트를 잘 묘사하는 모델을 만드는 것은 어렵습니다. 웹 / 앱 프로덕트 또한 유사하게 유입 부터 가입, 구매 등. 여러 (퍼널) 단계로 구성되어 있고 컨텐츠와의 상호작용과 어쩌면 커뮤니티와 규칙, 문화, 환경 등의 요소가 있어 더 복잡하기도 합니다. (그렇기에 문제를 매우 좁게 정의하는 것도 한가지 방법입니다 !)
2. A Party Is an Open System
(Open system은 열린계 라고 번역 되기도 하는데 이 링크를 참고하면 좋습니다)
우리가 처음에 고려했던 파티의 요인들 외에도 날씨와 같은 “우리가 통제 할 수 없는 그리고 실제로 영향을 주기도 하는” 외부의 요인들이 있습니다. 너무 당연하지만 우리가 이러한 요인들을 전부 고려하는 것은 어렵겠죠. 그들의 상호작용이나 조합 까지 고려하는 것은 물론 예측 하는 것조차도 아예 새로운 문제 이기 때문에 “모델”에 이를 포함시키기는 어렵습니다.
3. A “Great Party Is Hard to Define”
앞서 했던 이야기 입니다. 파티의 좋음은 정량적으로 표현하기가 어렵습니다. 결과가 아닌 과정인지 고민 하는 것 또한 어렵구요. 그렇지만 다행인 점은 웹 / 앱 프로덕트와 마찬가지로 고객의 목적을 이해하고, 이를 이루기 위한 그들의 여러 행동을 이해 한다면 “목적” 혹은 Pain point 를 잘 해결 했는가? 라는 관점에서 접근 해볼 수 있다는 것입니다.
4. Party Guests’ Motives and Opinions Are Often Unknown
우리가 주최한 파티는 수집되는 정보가 부족합니다. 많은 분석가나 DS, 실무진들은 이 정도 데이터라면 시스템을 잘 모델링 할 수 있겠지? 와 같은 생각을 하지만 그렇지 않다는 것을 알면 아쉬울 겁니다. 파티라면 그래도 (번거롭겠지만) 만족했는지 물어볼 수 있지 않나요? 라는 생각을 할 수 있습니다. 그러나 입장을 살짝 바꿔서 친구의 지인이 주최한 파티에 참여한 목적이 무엇인지, 파티에는 만족했는지 물어본다면 솔직한 대답을 할 수 있는 사람은 많지 않을 것이라고 생각합니다. (좋은게 좋은거겠죠…?) 하물며, 오프라인이 아닌 온라인에서 로그로 만나는 고객의 생각이라면, 알파고 할아버지가 와도 알기 어려울 것입니다.
5. A Party Presents a Variable Search Problem
Social Process의 또 다른 특징은, 과정을 표현 할 수 있는 변수가 정말 정말 정말 많다는 것입니다. 게스트가 누구인지, 이 사람은 언제 왔는지, 누구와 만났고, 어떤 대화를 했는지, 어떤 음식을 먹었고, 어떤 행동들을 순서대로 했는지, 술은 얼마나 마셨는지 등. 파티의 만족도와 관련되어 어떤 변수는 다른 변수에 비해 조금 더 그럴싸하다고 생각되지만, 결국 어떤 것이 가장 중요한지는 알 수 없습니다.
다시 한번, 유사합니다. 웹 / 앱 프로덕트도 많은 것을 측정 할 수 있습니다. (표현을 살짝 빌리자면 비용이 들고 설계가 귀찮을 뿐, 정말 많은 것을 수집 할 수 있습니다.) 그러나 측정의 쉽고 어려움과는 별개로 그 데이터가 중요한가요? 라는 질문은 별도의 이야기 입니다. 프로덕트에 대해서 그리고 사용자에 대해서 많은 고민을 했다면, 좋은 이론 혹은 모델을 가지고 있다면 프로세스를 더 잘 이해하기 위해 문제를 더욱 좁히고, 변수를 구성. 수집 할 수 있습니다.
6. The Real Secret to a Great Party Is Elusive
(주의. 이 부분은 살짝 이해 잘못한 것 같기도 해요.)
우여곡절 끝에, 우리가 파티를 좋게 만드는 요인들을 다 찾았다고 해도, 이 효과를 검증하기 위한 증거 혹은 반증을 수집하는 것은 또 다른 이야기 입니다. 예를 들어. 좋은 파티는 결국 맛있는 음료가 있으면 된다. 라는 결론이 났다고 해볼까요? 우리가 닥터스트레인지였다면, 완전히 동일한 상황에서 (참가자, 날짜, 시간 등) 음료만 바꾸어 실험 후 결과를 확인 할 수 있겠지만. You Only Live Once, 인생은 한번 뿐이기 때문에 결국은 조금씩 조금씩 다른 요인들이 적용 될 수 밖에 없습니다.
다행이라면, 웹 / 앱 프로덕트는 Social Process 보다 실험을 설계 하고 변수를 통제하는게 조금은 낫다는 것입니다. (그리고 어떤 변수를 통제 할 수 있는지 어떤 것은 불가능 한지 를 고민하는 것에 정말 많은 시간을 보내게 될 겁니다)
신약 개발과 같은 메디컬 프로세스들은 이러한 Split test (Test / Control) 라 불리는 접근 방법을 많이 적용 하고 있었고, 이는 웹/앱 프로덕트에서는 A/B 테스트라고 불립니다.
번외) A/B 테스트를 실제에 적용하는 것에는 정말 생각치도 못한. 가령 사업의 방향상 실행 불가능하거나, 다른 그룹에 영향을 주는 등 여러 어려움 들이 있습니다.
웹 / 앱 프로덕트와 Social Process 혹은 Human Behavior의 가장 큰 차이는 Physical Location을 실제로 필요로 하는가, 즉 관찰자가 (실험 설계자) 이벤트를 직접 관찰 할 수 있는지의 여부로 이에 대한 이야기는 나중에 기회가 되면 또 다뤄보도록 하겠습니다.
사용자 (사람) 데이터의 특징
한편, 웹 / 앱 프로덕트에 비해 Human behavior 데이터는 5가지 다른 점도 있습니다.
1. Human Behavior Is a Process, Not a Problem
Social Process는 개인 / 그룹 간의 특정한 목표 달성이나 규칙 하에 이뤄지는 상호작용입니다. 가령 Linkedin 이라는 프로덕트를 예시로 들어 보겠습니다. 다른 사람과 “친구” 가 되는 방법은 2가지가 있습니다. 1촌 신청을 보내고, 그 사람이 승인하는 과정 과 그냥 팔로우만 하는 방법이 있습니다. 두 사람이 연결된다는 관점에서는 크게 다르지 않은데, 어떤 이유로 프로덕트의 설계자가 1촌 신청에서 상호작용을 2단계로 쪼개두었을까요? 어떤 사용자는 1촌 거절 혹은 읽씹을 선호하지 않아, 1촌신청을 팔로우로 할 수도 있기 때문입니다. (라고 쓰여 있긴 한데 정확하게 어떤 의미인지 저는 이해 하지 못했습니다.)
이러한 규칙은 실제 사회에도 유사하게 있으며, 당연히 구성원의 행동에도 영향을 미치게 됩니다. 다만 우리가 만든 프로덕트라면 우리만의 새로운 규칙을 만들어낼 수 있습니다 (그리고 새로운 상호작용을 만들어 낼 수도 있죠!)
그럼 프로덕트는 무조건 좋은걸까요? 글쎄, 사회에서는 행동을 통해 학습하고 이를 바꿀 수 있지만, 프로덕트에서는 이를 고려하면 굉장히 어려워질 것 같긴 하네요.
많은 행동들은 정답이라는 결과를 찾기보단, 이뤄가는 과정을 더 중요하게 생각해야 할때도 있습니다. 이는 주어진 문제를 푸는 프레임워크 / 방법론들이 사회 행동을 예측하는 것에 힘을 못쓰는 이유이기도 합니다.
SNS에서 프로필 사진을 기본 아이콘이 아닌 걸로 변경한 사람들이 더 리텐션이 올라갔다고 합시다. 이제 PM은 신규 유저가 프로필을 업로드 하게 온보딩 하는 기능을 추가 하자 ! 라고 합니다. 그 결과는 어떨까요? 아마 아주 살짝만 오르거나, 어쩌면 떨어 질 수도 있습니다. 프로필은 리텐션의 원인이 되었다기보단, 그저 둘이 연관되어 있기 때문입니다. (자주 나오는 상관과 인과는 다르다는 이야기입니다)
SNS 이야기를 조금 더 해볼까요? SNS의 고객들은 컨텐츠를 만들기보다 소비 하는 사람이 더 많습니다. 소수가 플랫폼을 “지배” 하며 많은 커넥션을 만들고, 기능을 완전히 활용합니다. 어쩌면 프로덕트 디자이너보다 더 잘 알 수도 있죠. 그럼 이제 우리는 이러한 질문을 할 수 도 있습니다. 우리 프로덕트는 이 소수의 헤비유저와 다수의 라이트유저 중 어디를 우선으로 고려해야할까?
2. No Clear and Defined Outcomes
우편물의 숫자 인식! 과 같은 문제는 맞고 틀리다가 있지만, 파티 참가자가 만족했다? 는 맞고 틀림이 없습니다. 쿠친이 배송을 위해 어떤 경로로 가야할지 는 풀 수 있는 문제이지만, 파티의 순서는 어떻게 해야할까 는 도무지 풀기 어려운 문제이죠. 이러한 애매함 (혹은 Fuzzy) 은 사람 데이터의 또 다른 특징 중 하나입니다. (Fuzzy의 경우 튜링테스트를 보면 더 잘 이해 된다고 하는데, 저는 명확하지 않았습니다.)
분석을 하는 과정에서 때때로 만나는 문제는, 중요 요인들이 서로 얽혀 있는 경우입니다. 즉, A 와 B 둘 다 올라야 좋은 지표이지만, A가 오르면 B는 내려가는 구조를 가지고 있는 경우 인거죠. 이럴 때는 최적의 포인트를 위한 의사결정 또한 고려해야할 요소입니다.
또 하나, 의사결정권자들은 이러한 분석의 디테일을 파악하기엔 시간이 모자란 경우가 많습니다. 그래서 이들과 잘 커뮤니케이션 하는 것 또한 정말 중요합니다.
마지막, 데이터를 분석하는 과정에서 시작은 아마 DB를 들여다 보는 것일겁니다. 그렇지만 변수가 어떤 의미를 갖는지 혹은 어떤 테이블이 있는지 조차도 문서화되어 있지 않은 경우가 많습니다. 큰 회사나 작은 회사나 관계 없이 자주 발생하는 문제로 중요하지만, 동시에 많은 사람들이 어려움을 겪고 있는 문제이기도 합니다.
3. Social Systems Have Rampant Problems of Incomplete Information
불완전 정보는, 양쪽 방향의 정보가 비대칭 혹은 정보가 있지만 이를 해석 할 수 없을때 를 의미합니다. 많은 웹 / 앱 프로덕트에서 발생하며 이는 고객마다 프로덕트에 다른 정보를 가지고 있고, 이로 인해 다른 행동을 만들어내기 때문입니다.
잘 하기 어렵지만, 유저 리서치는 고객이 어떠한 이유를 가지고 이러한 행동을 했는지 를 이해 할 수 있는 좋은 방법 중 하나입니다. 그렇지만 동시에 편견이나 오해로 인해 “오염” 되기도 합니다.
만보기 서비스를 담당하는 DA라고 생각해보겠습니다. 각 사용자의 걸음수는 매일, 꽤 다를 수 있습니다. 이유가 뭘까요? (물론 알 수 없지만)
사용자가 만보기를 매일 작동하지 않을 수도 있다 라는 가설이 생깁니다. 이를 위해 리소스를 들여 조사를 합니다. 꽤나 효과적인 정성적인 데이터와 프로덕트의 데이터와도 합칠 수 있는 정량적인 데이터를 얻을 수 있지만 여전히 모든 질문에 답변 할 수는 없습니다. (심지어 프로덕트 데이터와 반대 될 수도 있죠)
사용자의 스케쥴 (휴가를 가거나, 마라톤을 했거나) 에 따라 다를 수도 있습니다. 그럼 이제 또 다른 가정을 합니다. 만보기는 매일 작동했고, 스케쥴은 큰 차이가 없다 라는 가설이죠. 다른 팀원이 다시 묻습니다. 이 가정은 어떻게 증명할 수 있나요?
모든 고객의 전부를 파악 할 수 없기 때문에 우리는 반드시 가정을 만들어야 하는데 이 퀄리티가 이후 프로덕트 개선 프로세스에 엄청난 영향을 미치게 됩니다.
4. Social Systems Consists of Millions of Potential Behaviors
비슷한 이야기 입니다. 정말 정말 많은 변수들이 포함되어 있습니다. 그렇기 때문에 (어쩌면 영향이 없을) 변수까지 전부 활용해서 모델링을 하는 것보다는 더 본질에 집중하는 메트릭 혹은 기능, 더 원론 적으로 질문을 만드는 것이 중요합니다. 우리의 목적이 Search problem 의 관점에서 100만개 중 1개 유용한 feature를 찾는 문제라면 어떻게 접근 할 수 있을까요?
도메인 / 사용자 전문가라면 기가막힌 휴리스틱을 만들어 내고, 정답에 가까운 솔루션을 찾을 수 있습니다. (물론 가능하다면 이도 실험과 검증을 할 수 있으면 좋습니다.)
잠재적인 요인들을 유형에 따라 컨셉화 하고 구조화 하는 것은 연습하는 것도 어렵지만 정말 중요한 관점입니다. 이를 위한 방법은 위의 도메인 전문가, 랜덤성, 실험 (try and error), 아카데믹 논문 참고 등이 있습니다.
5. Inferrring Causation Is Almost Impossible
요인들의 인과관계를 알 수 있다면 액셔너블한 인사이트와 고객의 행동을 바꿀 수 있습니다. 더 많은 구매를 이끌어 내는 거죠.
우리의 추측이나 인과를 증명하는 방법은 여러개가 있지만 2가지를 다뤄보겠습니다.
- 비교 실험
페니실린의 효과를 검증하기 위해 2개의 페트리디쉬에 거의 동일한 환경과 박테리아, 그리고 한쪽에만 페니실린을 처리하여 이후 결과를 관측합니다. 효과가 있다면 한쪽에서만 자라겠죠?
아쉽게도 모든 상황에서 이런 잘 통제된 실험을 하긴 어렵습니다.
- 랜덤성을 활용한 추측
(우리는 지진을 연구하는 사람이라고 합니다)
저기 태평양 어딘가에 무인도가 있습니다. 그리고 지진이 2년정도 마다 발생한다고 합시다. 무인도 이기 때문에 실제로 지진이 어느때 발생 했는지는 알 수 없습니다. 그때를 위해 무인도에 상시로 대기 할 수는 없기 때문이죠.
대신 해조류의 성장을 통해 지진을 알 수 있습니다. 지진이 있고 난 이후에는 해조류가 한달 동안 100년만에 한번 나올까 말까 하는 정도로 크게 성장하는 것을 관찰했다고 합시다. 만약 우리가 지진을 직접 관측하진 않았지만 해조류가 크게 성장해 있다면, 최근 1달안에 지진이 발생했다고 가정 할 수 있지 않을까요?
물론 극단적인 예시이긴 합니다. 그리고 실제로는 베이지안을 활용하기도 하지만 여전히 지진이 100% 발생했다고는 절대 알 수 없습니다. 다만 엄청 있었던 것 같다 정도로 말할 수는 있죠. (대부분은 실제로 그렇습니다, 이번 글에서 베이지안에 대한 설명은 다루지 않습니다.)
인과관계가 중요한 이유
취직연계프로그램이 실제로 취업에 도움이 될까? 레드 와인을 마시는 것이 장수에 영향을 줄까? 와 같은 질문에 답을 하는 것으로 정부의 효과적인 운영, 더 오래사는 것, (그리고 프로덕트의 개선에도) 활용 할 수 있습니다.
그리고 magnitude of the effect 는 아직은 깊게 생각해볼 주제는 아니지만 연달아서 고려해야하는 중요한 요인입니다.
레드와인이 주 3일 정도 마실때 1년을 더 살 수 있다 라고 할때, 1일을 마시고 1/6년을 더 사는 것부터 그리고 주 6일을 마시고 2년을 더사는 것까지의 여러 선택지중 가장 효과적인 방법을 고려하는 것이죠.
Social Product를 다뤄본 사람들의 증언에 따르면 이러한 인과관계가 있는 변수들은 아주 작은 영향을 나타내는 경우가 많습니다. A/B 테스트와 통계 매칭, 자연실험 등의 키워드는 나중에 다뤄보기로 합시다.
비용, 프로세스의 진행 중, 설득의 이유 등, A/B 테스트를 실행할 수 없는 상황은 정말 많습니다. 그렇지만 여전히 인과관계를 알고 싶을 때 대안으로 접근 할 수 있는 방법이 없진 않습니다. 그중 하나는 엄밀히는 변수가 통제 되지 않은 다른 그룹이지만 그룹의 분포가 유사할때 A/B로 간주하여 이 그룹들에 실험을 진행하는 것입니다. 비록 정확하게 설계된 실험에 비하면 덜 완벽하겠지만 충분히 의미있는 임팩트를 만들어내거나 이후에 진행될 A/B 테스트에 힘을 실어줄 수 있습니다.
요약
- 웹/앱 프로덕트는 Social Universe의 소은하입니다.
- 웹/앱 프로덕트의 Social Process와 최신 Data Science 솔루션에는 어느정도 차이가 있습니다.
- 웹/앱 프로덕트는 수많은 인간 행동 변수를 포함하는 Open System이다. 불완전한 정보로 가득하고, 정의된 결과가 없으며 인과관계를 찾는 것은 더욱 어렵습니다.
- 인과를 확인하기 위해서 반증을 찾아야하는데요, 많은 경우 예측, 상관관계를 활용해 부정확한 인과 관계를 추측하곤 합니다.
