by
Sep 09. 2020
기획자의 개발 문서 읽기
데이터 분석 솔루션 ‘Amplitude’ 개발 문서 함께 읽어보기
기획자는 개발을 얼마나 알아야 할까요? 사람마다 의견은 다르겠지만 저는 product가 어떻게 구성되어 있는지 이해하고, 맡고 있는 product가 client – server 간 어떻게 통신하고 있는지 정도는 이해하고 있어야 한다고 생각합니다.
즉, product의 ERD 내 데이터 structure가 어떻게 구성되어 있는지 이해하고, client에서 어떤 API를 호출하여 서버와 통신하고 있는지 정도는 이해해야 한다고 생각합니다. 물론 보다 상위 레벨인 정책 수준에서 서비스를 이해하는 것도 중요하지만 그보다 조금 더 낮은 (low level)인 DB와 API레벨에서 서비스 흐름을 이해할 수 있으면 좀 더 개발자와 소통이 원활해지고 product에 대한 이해도 증진시킬 수 있다고 생각합니다. 물론, DB, API를 넘어서 코드 레벨 및 인프라 수준까지 이해하면 좋겠지만 이는 어찌 보면 욕심이라고 할 수도 있을 것 같습니다. 이렇게까지 세세하게 스펙을 내려서 이해하려고 하면 기획자의 업무 범위가 너무 방대해지고, 또 정작 집중해야 될 다른 요소를 소홀히 하게 될 수 있으니까요.
기획자는 사업을 정의하고 문제점을 발견 및 해결안을 제시하는 등 보다 상위 레벨에서 움직여야 할 경우가 많습니다. 근데 비전문 영역인 코드 레벨과 인프라까지 이해하려고 하면 이는 오히려 생산성 측면에서 마이너스가 될 수 있습니다. 기획자의 product 이해는 적당한 수준에서 이해하는 정도로 멈추고, 그 이하 low level은 개발자에게 맡기는 게 좋다고 생각합니다. 물론, 어디까지나 호기심 해결의 차원에서 코드와 인프라를 공부해보는 것은 좋다고 생각합니다. 무어든 공부해서 익히고 알아 나가는 것은 즐거운 일이니까요.
어찌 됐든 위에서 상술한 바와 같이 DB와 API 수준에서 서비스를 이해하는 정도는 꼭 필요하다고 생각합니다. 단순 정책만 갖고 서비스를 다룰 때에는 개발자와 커뮤니케이션 이슈가 발생하는 경우가 종종 생깁니다. 실제로 어떤 데이터를 어떤 형식으로 저장하고 있고, API 통신을 통해서 데이터를 어떻게 적재하고 있는지 이해하고 있다면 개발자와 커뮤니케이션하기 좀 더 수월할 것입니다.
3rd 파티 솔루션을 연동할 때도 마찬가지입니다. 단순 정책 문서 레벨에서 좀 더 나아가 개발자를 위해 제공하는 API 문서 등을 읽고 이해할 수 있다면 자사 product와 어떻게 연동을 해야 될지 좀 더 명확한 그림을 그려볼 수 있을 것입니다. 구글/카카오/네이버/공공데이터포털에서 제공해주는 오픈 API 문서를 읽고 어떤 데이터를 어떤 방식으로 받아올 수 있는지 확인 후 개발자와 소통한다면 커뮤니케이션이 상당히 원활해질 것입니다.
오늘은 GA와 유사한(?) 데이터 분석 툴인 Amplitude의 개발 문서를 함께 읽어보며 기획자인 제가 개발 문서를 어떻게 이해하고 활용하고 있는지 설명드리도록 하겠습니다. (먼저 말씀드리자면 저는 전문 개발자가 아니고 개발에 대한 이해도가 높지 않기 때문에 아래 상술한 내용 중 잘못된 내용이 있을 수 있습니다. 혹여 잘못된 부분이 있다면 댓글로 남겨주시면 확인 후 수정하도록 하겠습니다. :) )
문서는 다음을 참조하였습니다. 스샷을 첨부하고 제가 해석하고 이해한 내용을 공유하는 방식으로 진행하겠습니다.
그럼 시작해보도록 하겠습니다.
데이터 전송 흐름Amplitude는 이벤트 기반(이벤트 예: 음악 재생하기 버튼 클릭 등) 데이터 분석 솔루션입니다. 이 솔루션을 활용하기 위해 Amplitude 서버로 유저 데이터를 전송해주어야 합니다. 위 내용을 보니 client에서 직접 데이터를 전송할 수도 있고 server to server로 http API통신을 통해 데이터를 전송할 수도 있어 보입니다. 혹은 3rd party 솔루션을 통해서 Amplitude에 데이터를 전송하는 것도 가능해 보입니다.
Client SideClient에서 데이터를 전송할 때는 Amplitude에서 제공하는 SDK를 활용하면 된다고 합니다. 웹/모바일 OS용 SDK를 제공하고 있고 Amplitude 깃헙에서 소스를 다운받을 수 있다고 합니다.
Server SideHTTP API 통신을 통해서 server to server로 Amplitude에 데이터를 직접 전송할 수도 있습니다. 위 방식을 통한 데이터 적재를 원할 경우 Amplitude에서 제공해주는 end point로 호출을 해주면 되겠군요.
SchemaAmplitude 스키마는 이벤트, 이벤트 상세 정보, 유저 상세 정보, 그룹 타입으로 구성되어 있네요. 즉, ‘어떤 segment’(group)의 ‘어떤 유저’(user)가 ‘어떤 행동’(event)를 했는지 추적할 수 있는 것 같습니다.
Event Type & Event Property이벤트는 product 안에서 행해지는 특정 유저의 ‘행동’으로 정의됩니다. Server to server로 데이터를 전송하는 경우에는 product 외부의 이벤트도 수집이 가능한 것으로 보입니다. (예: 이메일 열람 확인 등) 이벤트 로깅 시 이벤트 네이밍을 할 때 대소문자 구별도 확실히 해주어야 할 것 같습니다. ‘Play song’(앞 대문자)과 ‘play song’(앞 소문자)은 다른 이벤트로 인식됩니다.
이벤트 상세 정보 (event property)는 특정 이벤트 타입의 속성(attribute) 값으로 정의되네요. 예를 들어 ‘play song’ 이벤트 발생 시 ‘song name’이 무엇이었는지 함께 전송이 가능합니다.
About User Property유저 상세정보 (user property)는 각 유저에 tag along 되어 있는 정보입니다. 예를 들어 사용자 타입, 총 결제 금액, 계정 타입 등이 될 수 있겠네요. Client를 통해 데이터를 전송하면 이러한 유저 상세정보를 자동으로 적재해준다고 합니다.
유저 상세정보를 로깅하기 위해서는 반드시 특정 이벤트가 trigger 될 필요가 있어 보입니다. 예를 들어 홍길동 유저의 ‘좋아하는 음악 장르’(유저 상세정보)를 수집하고 싶다면, ‘create profile’ 이벤트가 발생하여 좋아하는 음악 장르가 수집된 후에 tracking이 가능해집니다. (적재 이후 시점에 장르를 통한 segmentation도 가능하겠네요.) 이벤트 발생 전 해당 상세 정보 값은 정의되지 않은 '없는 값'(null)이 되겠네요.
How to operate SDKSDK를 활용하여 유저 상세정보 값을 아래와 같이 설정할 수 있습니다.
- set: 최초 유저 상세정보를 설정하거나 기존 값 덮어쓰기
- setOnce: 최초 유저 상세정보 설정, 값 덮어쓰기는 불가
- unset: 설정된 값을 null로 초기화
- add: 특정 유저 상세정보 값을 증가시킴, 예를 들어 총 결제 금액 등은 계속해서 증가해야 하므로 이때 add operation을 실행하면 되겠네요.
- append: user property가 배열(array) 형태로 구성되어 있을 때 값을 추가해주는 옵션인 것 같습니다. 예를 들어 관심 음악 카테고리가 원래 [발라드] 하나였는데 append 옵션을 사용하여 [발라드, 락] 이런 식으로 추가할 수 있을 것 같습니다.
또한 server to server 데이터 전송을 사용할 경우 별도의 event triggering이 아닌 Identity API를 호출하여 user property를 직접 추가할 수도 있네요.
Group Types기업 회원은 Group Type을 활용할 수 있는 것 같습니다. 아마도 group type으로 segmentation 된 별도의 보고서를 볼 수 있는 것 같습니다.
User IdentificationAmplitude는 사용자 식별을 위해 User ID, Device ID, Amplitude ID를 활용하고 있네요. 이 중에서 기본이 되는 값은 아마도 Device ID 일 것 같습니다.
User IDUser ID는 optional 한 값이고 (일반적으로) 변동될 수 없는 고유 식별자네요. 가이드에서는 익명 유저가 아닌 계정을 생성하고 로그인한 유저에게 적용하는 것을 추천하고 있습니다. 즉, 실제 서비스 ID와 매핑되는 값으로 보는 게 좋을 것 같습니다. 중간에 user ID를 변경하게 되면 Amplitude는 서로 다른 사용자로 인식을 한다고 합니다.
Device IDDevice ID는 필수 값입니다. SDK를 사용할 경우 자동으로 device ID를 생성해준다고 합니다. Server to server로 전송 시 device ID를 전송하지 않을 경우 user ID를 hashing 처리해 device ID 값으로 저장한다고 합니다.
(그런데 device ID를 전송하지 않고 user ID만 전송하는 경우가 있을까요? 한편 user ID, device ID를 모두 전송하지 않으면 API 400대 (잘못된 요청) error가 return 될 것 같습니다. hash값은 단방향 해시 값으로 저장하게 되겠네요.)
(server to server로 device ID 전송 시 각 모바일 OS에서 제공해주는 앱별 개별 uuid를 활용하여 device ID를 전송하면 될 것 같습니다. 참조: 안드로이드의 경우는 앱 삭제 후 재설치시 새로운 uuid가 할당됩니다. IOS의 경우는 동일 디바이스에서 앱 삭제 후 재설치 시 OS에서 같은 uuid를 할당합니다.)
Amplitude IDAmplitude ID는 user ID와 device ID를 기준으로 매핑된 고유 값으로 보입니다. Device ID와 user ID가 사용자 측에서 생성한 ID라면 Amplitude ID는 amplitude 사에서 사용하고 있는 고유 매핑 ID로 보입니다. 분석 시 이 ID를 어떻게 활용할 수 있을지는 좀 더 고민이 필요할 것 같습니다. Amplitude ID 하나만 갖고도 전체적인 데이터 분석이 가능할 것처럼 보이기도 합니다.
Merging Users유저 병합이 가능합니다. 예를 들어 Bob이라는 유저가 새로운 기기를 구매 후 앱 설치 및 로그인을 하였을 경우 Amplitude ID를 이전 ID와 동일하게 사용할 수 있습니다. Multi channel 및 multi device 환경에서 하나의 Amplitude ID를 활용할 수 있어 보입니다. 일반적으로 GA의 경우는 브라우저 및 기기가 다를 경우 서로 다른 user로 인식을 하는데, Amplitude의 경우는 통합 관리가 가능해 추적 및 분석이 용이해 보입니다. (물론 GA도 user ID를 사용하면 통합하여 관리가 가능한 것으로 알고 있습니다.)
(생각: 한 디바이스 내에서 로그인한 아이디를 로그아웃 후 다른 아이디로 로그인하게 되면 어떻게 될까요? user ID가 Amplitude 서버 내 존재한다면 해당 Amplitude ID로 매핑되고, 만약에 신규 user ID라면 새로운 Amplitude ID가 생성될 것 같습니다.)
Tracking Sessions세션은 특정 유저가 product 내에서 연속적으로 활동한 '특정 기간’을 의미합니다. 모든 이벤트에는 기본적으로 session ID가 생성되고 epoch를 활용하여 milliseconds 단위로 session ID가 자동 생성되는 것 같습니다. 같은 세션에 속하는 이벤트는 같은 session ID를 공유합니다. (GA를 다루어 보신 분이라면 이 세션 개념이 이미 익숙하실 것입니다.) 푸시 발송이나 이메일 열람 등 세션과 관련 없는 이벤트는 세션 트래킹에서 제외할 수 있다고 합니다. 한편 Server to server 방식으로 데이터를 전송할 때는 session ID를 수동으로 설정해주어야 한다고 하네요.
SDK Configuration Options자주 사용하는 SDK 구성 옵션입니다.
- minTimeBetweenSessions, sessionTimeout: 모바일 및 웹 환경에서 세션의 최소 시간을 설정합니다. GA의 경우에는 세션 시간이 30분으로 디폴트 설정되어 있습니다.
- optOut: 현재 유저를 트래킹에서 제외합니다.
- Offline: 이벤트 전송을 중지합니다.
- saveEvents: 미발송 이벤트를 사용자 디바이스에 저장합니다.
- savedManCount: 디바이스에 저장 가능한 최대 미발송 이벤트 수입니다. 디폴트 값은 1,000이라고 합니다.
Data BackfillingAmplitude 도입 전 과거 데이터를 Amplitude에 전송하여 분석하거나, 이미 기존 유저가 있을 경우 사용하는 옵션으로 보입니다. GA에서는 Backfilling이라는 용어를 유입 경로 시각화 보고서에서 중간 funnel data를 자동으로 채울 때 사용하는데 Amplitude에서는 이전 데이터 마이그레이션 개념으로 사용하고 있는 것 같습니다.
Best PraticesBest Practice를 위한 팁입니다. Dev/stage 환경과 production 환경을 구분하여 프로젝트를 생성하는 것이 좋다고 합니다. Dev 환경에서 프로젝트를 구축한 후 충분한 테스트를 거쳐 데이터가 제대로 적재되고 있을 때 production 환경을 구축하면 좋을 것 같습니다. 한번 적재된 데이터는 수정이 어렵다고 합니다. (GA도 마찬가지 입니다.) 또한 HTTP API server to server 통신 시에는 반드시 session ID를 보내달라고 하네요.
APIs