안녕하세요 킴스캐슬입니다:)
오늘은 회사에서 mixpanel이라는 데이터 수집 및 분석 툴을 적용하면서 알게된 내용을 정리해볼까합니다!
mixpanel SDK자체의 사용법은 공식문서가 잘 되어있을테니 그 내용은 아니고요
제가 생각했을때 mixpanel의 강력한 기능중 하나인 distinct_id의 동작원리를 정리해보려합니다
믹스패널에서 특정 이벤트들을 이 이벤트들은 한명의 유저로 부터 비롯된 이벤트들이다 라고 식별하는 값을 “distinct_id”라고 합니다
이게 왜 필요하냐고 생각하실수있는데요
예를들어서 로그인이 있는 앱이 있다고 해봅시다
어떤 유저가 로그인전에 A, B, C라는 이벤트를 수행했고 로그인 후에 D, E이벤트를 수행했다면 유저 데이터를 분석하는데 있어서 A,B,C,D,E를 특정 유저가 수행한 이벤트로 묶이는건 매우 중요합니다. 유저의 flow를 확인할수있고 어떤 이유로 유저가 로그인이나 회원가입이라는 큰 방지턱을 넘었는지를 분석할수있으니까요
자 그러면 시작해보겠습니다
distinct_id란?
distinct_id는 식별값이지만 unique한 값이 아니고 특정상황에 따라 변하는 가변적인 값입니다. 기본적으로 mixpanel은 아래 두가지 속성을 통해 이벤트를 클러스터링합니다
클러스터링이란?
비슷한 특징을 가진 데이터 포인트들을 그룹화하여 분류하는 비지도 머신러닝 기법이라는 뜻이지만 여기서는 특정 이벤트들을 하나의 유저가 보낸 이벤트로 묶는다는 의미로 이해해주시면 될 것 같습니다
첫번째 $device_id
두번째 $user_id
$가 붙은 건 무슨 의미인가요?
$가 붙지 않은 파라미터는 순전히 mixpanel을 사용하는 사용자가 데이터를 확인하고 필터링하기 위한 값이고 $가 붙은 값은 mixpanel내부에서 내부로직에 의해 무언가를 식별하는데 쓰이는 값입니다
결론부터 말씀드리면 $user_id ,$device_id 두 값중 하나가 “distinct_id”가 됩니다
첫 번째 상황
첫번째 상황은 유저가 앱에 진입했을때 로그인이 안된상황입니다
이때는 서버에서 user_id(유저 식별값)를 받아오지 않은 상태이기때문에 $user_id는 없는 상황이고 mixpanel내부에서 $device_id를 임의로(1a2b3c-4d5e)만들어서 세팅해둔 상태입니다
이 상황에서 a이벤트와 b이벤트를 mixpanel에 보내게되면 mixpanel에서는 두 이벤트 모두 $user_id가 없지만(우선순위 높음), $device_id가 같기때문에 같은 유저가 보낸 이벤트라고 판단해 클러스터링을 생성합니다
두 번째 상황
두번째상황은 첫번째 상황을 거쳐 로그인을 하고 c이벤트와 d이벤트를 전송한 상황입니다
mixpanel에 identify라는 함수를 호출하면 $user_id를 유저가 원하는 값으로 설정하고 $device_id는 이미 1a2b3c-4d5e라는 값으로 설정되어있기때문에 새로운 값을 할당하지 않습니다
mixpanel내부적으로는 a,b이벤트와 c,d이벤트의 $user_id는 다르지만 $device_id가 같기때문에 하나의 유저로 판단합니다
이 순간 아래와같은 클러스터가 생성됩니다
{
$user_id: 212988,
$device_id: 1a2b3c-4d5e
}세 번째 상황
세번째 상황은 이미 abcd가 하나의 유저의 이벤트로 클러스터링 된 후 로그아웃을 하고 ef이벤트를 발생시킨 경우입니다
로그아웃을하면 reset을 호출하게되고 mixpanel내부에서 $user_id와, $device_id를 초기화 시킨후 최소한의 distinct_id를 설정하기위해 $device_id를 새로생성합니다
이미 아래와 같은 클러스터가 형성되어있는 상황에서
{
$user_id: 212988,
$device_id: 1a2b3c-4d5e
}mixpanel은 ef이벤트를 위 클러스터에 merge(하나의 유저이벤트로 묶는 로직)할 근거를 찾지 못합니다. 왜냐면 ef이벤트들은 $user_id도 클러스터와 다르고 $device_id도 다르기때문입니다. 이 시점에서 abcd는 한명의 유저의 이벤트로 ef는 다른 유저의 이벤트로 클러스터링됩니다
네 번째 상황
이번상황은 로그아웃후 다시 이전 아이디(같은 계정으로)로그인을 한 상황입니다. 같은 계정이라면 kihno서버에서 같은 user_id를 내려주고 세팅하기때문에 $user_id가 212988로 세팅되며 $device_id가 이미 있기때문에 이 값을 변경하진 않고그대로 둡니다
이 상황에서 gh이벤트를 보내게되면
{
$user_id: 212988,
$device_id: 1a2b3c-4d5e
}이미 위와같은 클러스터가 형성되어있는 시점에서 $user_id가 같기때문에 $device_id에 6f7g8h-9i10j가 추가되게됩니다
{
$user_id: 212988,
$device_id: 1a2b3c-4d5e, 6f7g8h-9i10j
}abcd,gh가 위 클러스터로 묶이고 난뒤 6f7g8h-9i10j라는 $device_id로 보냈던 이벤트인 ef도 해당 클러스터에 merge되어서 abcdefgh이벤트가 한명의 유저로 클러스터링됩니다
다섯 번째 상황
네번째 상황은 로그아웃후 같은 계정으로 로그인한 경우라면 다섯번째 상황은 로그아웃후 새로운 계정으로 로그인한 경우입니다. 이때는 서버에서 다른계정이므로 다른 user_id를 받게되고 $user_id에 세팅되며 $device_id는 있던 값이 유지됩니다
{
$user_id: 212988,
$device_id: 1a2b3c-4d5e
}위와 같은 클러스터가 유지되지만 434211이라는 새로운 $user_id를 기준으로 새로운 클러스터가 생성됩니다
{
$user_id: 424111,
$device_id: 6f7g8h-9i10j
}따라서 로그아웃후 이벤트인 ef가 6f7g8h-9i10j라는 $device_id를 가지고 있으므로 같은 클러스터에 묶이게 됩니다. 이렇게되면 abcd가 A라는 유저(212988)의 이벤트로 클러스터링되고 efij가 B라는유저(434211)의 이벤트로 클러스터링됩니다
웹 ↔ 앱간의 데이터 클러스터링
특정 서비스의 경우에 앱 내부에서 웹뷰를 사용하는 경우가 많고 웹뷰 내부의 이벤트는 웹뷰 자체에서 mixpanel이벤트를 전송하기에 이 두 플랫폼사이의 유저를 식별해서 같은 유저인지를 판단해야합니다
이를 위해 쿠키에 $deivce_id를 담아 보내주고 웹뷰에서는 이 쿠키에있는 값을 그대로 $device_id로 세팅해줍니다
왜 쿠키에 $device_id를 담아줘야하나요?
로그인을 한 경우라면 cookie에 $deivce_Id를 담아주지 않더라도 $user_id는 같고 $device_id가 새로생성된 값(예를들면 5l6k7j-8j9h)이기 때문에
{ $user_id: 212988, $device_id: 1a2b3c-4d5e, 5l6k7j-8j9h }이렇게될테니 abcdef가 같은 유저의 이벤트로 묶입니다
다만 이렇게했을때는 로그아웃후 문제가 발생합니다
로그아웃을 한 유저가 앱이벤트인 ab를 전송하고 그상태로 웹뷰진입해서 ef이벤트를 전송했을때 흐름상으로는 같은유저지만 $user_id가 없고 $device_id가 다르기때문에 같은 유저로 식별할 수 없습니다
ab는 가상의 A유저의 이벤트 ef는 가상의 B유저로 인식하게됩니다
하지만 쿠키에 $device_id를 담아준다면
로그아웃한 시점에서의 이벤트들이 $device_id로 묶이게되고 로그아웃전 가상유저가 abef라는 이벤트를 발생하게 클러스터링됩니다
로그인 후에는 웹뷰에 진입시 웹뷰내부에서도 로그인한 유저라면 kihno서버에서 userID를 받아오므로 같은 $user_id가 세팅됩니다 이때의 ef이벤트들은 이미 생성된 아래의 클러스터에 merge되므로
{
$user_id: 212988,
$device_id: 1a2b3c-4d5e
}abcdef가 플랫폼이 다르더라도 같은 유저로 인식됩니다
기존에는 회사에서 ga를 사용했었고 그때는 이벤트들을 한명의 유저로 묶는것이 중요하지 않았는데(이벤트의 빈도수가 더 중요했기때문에) mixpanel을 도입하게되면서 유저의 flow를 분석해서 유저가 어떻게 서비스를 사용하는지를 분석하는게 중요해졌습니다
이로인해 sdk를 도입하는과정에서 어떻게 식별전 유저와 식별후 유저, 식별전 앱이벤트와 웹이벤트를 한명의 유저로 묶을수있을지를 공부하면서 결과(실제 mixpanel데이터를 보면서 잘 묶이는지)를 통해 내린 결론이기에 틀린 부분이 있을수있을것같습니다
그런부분이있다면 피드백주시면 다시한번 확인해보겠습니다:)
