서비스 로그와 행동 로그 분석

https://medium.com/myrealtrip-product/%EB%AA%A8%EB%B0%94%EC%9D%BC-%EC%95%B1-%EB%A1%9C%EA%B7%B8%EB%B6%84%EC%84%9D-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%8B%9C%EC%9E%91%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C-13b8109df196

서비스 로그는 transaction의 결과를 기록하는 로그입니다. 가입하거나 예약하거나 결제 하는 등 하나의 transaction이 완료되었을 때 각각의 서비스 로그가 남게 됩니다. 

행동 로그는 transaction 에 이르기까지 사용자들이 서비스에서 하는 작은 action에 대한 로그를 의미합니다. 특정 상품을 클릭하거나 검색하거나 배너를 스와이프하는 등의 action을 예로 들 수 있습니다. 

서비스 로그는 기본적으로 서비스 운영을 위해서 필수적으로 쌓고 관리해야 하므로 이 데이터를 활용하는 데는 대부분 큰 문제가 없습니다. (모든  변경분을 다 쌓을지, 최종 수정된 내용만 남길지 정도의 고려사항은 있겠지만..) 

반면 행동 로그의 경우 생성되는 데이터 양도 훨씬 많고, 설계하는 과정에서의 자유도도 높아서 수집이나 활용이 상대적으로 까다로운 편입니다. 당장 볼 수 없다고 해서 서비스에 큰 문제가 생기는 것도 아니기 때문에, '일단 되는대로 다 쌓자! 근데 어떻게 봐야할지 모르겠다' 상태로 방치되는 경우가 많습니다. 

 

마이리얼트립 행동로그 설계하기 

행동로그는 어떻게 설계하느냐에 따라서 얻을 수 있는 정보의 수준은 완전히 달라집니다.

행동 로그를 보는 가장 단순한 방식은 발생한 이벤트의 숫자를 count 하는 것입니다. 하지만 단순 이벤트 숫자 집계만으로는 원하는 수준의 인사이트를 얻기 어렵겠죠. 사실 행동 로그 설계의 핵심은 이벤트 속성을 어떤 수준으로 함께 남길 것인가? 를 정의하는 부분입니다. 속성에 대해서 약간 더 부연설명을 하자면, 특정 이벤트가 발생했을 때 함께 남길 수 있는 이벤트(혹은 사용자)에 대한 세부 정보라고 생각하시면 됩니다. 가령 '예약하기' 버튼을 누르는 이벤트가 있다고 하면 아래와 같은 것들이 property가 될 수 있겠네요. 

이벤트의 속성을 남기지 않았다면, 예약하기 버튼을 클릭한 숫자 정도만 확인이 가능합니다. 하지만 이벤트의  property를 함께 기록했다면 어떤 상품을 클릭했는지, 그 상품의 가격이 얼마였는지, 어떤 화면에서 클릭했는지.. 와 같은 훨씬 더 자세한 정보를 얻을 수 있습니다. 만약 사용자가 property까지 함께 기록했다면? 해당 이벤트를 한 사용자가 어떤 특성이 있는지도 확인할 수 있습니다. 즉 하나의 이벤트가 발생했을 때 훨씬 더 입체적으로 정보를 얻을 수 있게 됩니다. 아래 표를 보면 property를 남기는 수준에 따라서 얻을 수 있는 인사이트의 수준이 크게 차이가 나는 것을 확인할 수 있습니다

Big Query에 로그 적재 

마이리얼트립은 Firebase-BigQuery로 이어지는 파이프라인을 이용해서 앱 로그를 남기고 있습니다. BigQuery는 구글이 제공하는 대용량 데이터 베이스인데요. TB단위의 스캔에도 전혀 무리 없는 빠른 속도, 매우 저렴한 저장 비용, 무제한에 가까운 용량, 관리의 편의성, Firebase 프레임웍과 연동.. 등 앱 로그를 쌓는 용도로 사용하기에 아주 좋은 선택입니다. BigQuery에 대한 자세한 소개, 그리고 Firebase를 BigQuery와 연동하기 위한 설정에 대한 디테일한 내용은 아래 링크를 참고하시길 바랍니다. 

https://cloud.google.com/bigquery/docs?hl=ko 

https://github.com/zzsza/bigquery-tutorial

https://brunch.co.kr/@minwoo/15

BigQuery에 쌓인 이벤트 로그는 아래와 같은 포맷의 스키마를 갖습니다. event 에 딸린 key가 있고(위에서 설명한 event property 명칭에 해당됩니다.) 해당 key에 매핑된 value(event property의 구체적인 값에 해당합니다)가 있습니다. 특이한 점은 value가 자료형에 따라 구분되고 있다는 점인데요. string, integer, float, double 각 자료형에 따라서 컬럼이 구분되어 있고, 추후 조회를 할 때도 자료형에 따라 정확한 컬럼을 지정해야 값을 확인할 수 있습니다. 참고로, 아래는 event property를 예로 들었지만, user property도 적재되는 방식은 동일합니다.

또 한가지 주목해야 하는 부분은 하나의 이벤트에 복수 개의 property가 존재하는 경우, row안에 row가 내재한 구조로 쌓인다는 점입니다. (Big Query에서 이런 유형의 컬럼을 Record type으로 분류합니다. 일명 nested구조) 구글은 이걸 장점이라고 홍보하는데, 사실 분석하는 입장에서는 nested구조 때문에 쿼리 작성의 난이도가 굉장히 높습니다. 간단히 설명해 드리면, record type의 데이터를 조회할 때는 항상 unnest 한 다음에 쿼리를 해야 한다는 건데요. 이 부분은 뒤에서 자세히 설명해 드리도록 하겠습니다. 

https://medium.com/firebase-developers/how-to-use-select-from-unnest-to-analyze-multiple-parameters-in-bigquery-for-analytics-5838f7a004c2

위 글 정독 필요...

 

https://medium.com/myrealtrip-product/%EB%A7%88%EC%9D%B4%EB%A6%AC%EC%96%BC%ED%8A%B8%EB%A6%BD-%EC%97%AC%ED%96%89-%ED%9B%84%EA%B8%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B6%84%EC%84%9D-be3f6c557ca2

마이 리얼 트립 하는 방법