데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA (2)

 

 

 

데이터 로그와 퍼널 분석에 대한 공부를 하다가 소중한 게시물을 찾아서 똑같이 필사하며 공부했다.

데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것 · 어쩐지 오늘은 (zzsza.github.io)

데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것

 

 

 

데이터 로깅 프로세스

● 단계별 설명

   ○ 0) 현 회사에서 데이터 로깅 관련 문서 또는 아키텍쳐가 있는지 확인하기

   ○ 1) 해당 프로젝트에서 메인으로 가져갈 지표 생각해보기

   ○ 2) 어떤 식으로 저장하면 좋을지 작성해보기

         - 데이터가 어떤 형태로 저장되는지 확인해보고, 이 데이터를 어떻게 바라볼 수 있는지 생각해보기

   ○ 3) 개발자 또는 데이터 분석가와 커뮤니케이션(이 데이터를 볼 수 있는지 등)

   ○ 4) 확정된 로깅 가이드 문서를 개발자에게 전달

   ○ 5) 로깅 개발 완료 후, 실제로 데이터가 잘 들어갔는지 테스트

   ○ 로깅 가이드 문서는 스프레드시트 등을 통해 관리하면 좋음

        - 이벤트 이름은 무엇인지

        - 어느 상황에 로깅되는지

        - 언제부터 적용되는지(= 언제 배포되었는지)

        - 이벤트의 세부 파라미터의 이름은 무엇인지(Firebase에선 Key라고 표현함), 어떤 Parameter가 들어가는지(예를 들어 주문 완료 이벤트의 파라미터로 Key:product_id, Value:1 등으로 저장될 수 있음. 이는 product_id가 1번인 주문을 완료했다는 뜻)

 

● 데이터 로깅 프로세스는 크게 데이터 로깅 설계와 데이터 로깅 작업, 데이터 QA로 나눌 수 있음

● 데이터 로깅 설계

  ○  어느 시점에 어떤 데이터를 어떤 파라미터와 기록할 것인지, 유저의 프로퍼티를 저장할 것인지를 담은 데이터 로깅 추적 계획을 세우는 과정

  ○  데이터 로깅 설계 전에 어떤 지표를 메인으로 볼 것인지? 를 구체화하는 것이 꼭! 필요함

      - 어떤 지표를 볼 것인지에 따라 로깅 계획이 달라지므로 어떤 지표를 왜 보려고 하는지 고민하는 것이 중요함

      - 생각했던 지표가 꼭 웹/앱이 아니라 Database의 데이터로 볼 수 있다면 굳이 로깅하지 않아도 괜찮음

      - 퍼널 단계를 볼 때 이런 데이터가 꼭 필요함

  ○ 데이터 로깅에서 모든 것을 남길 수는 없기 때문에, 이런 지표에 대한 사전 고민이 있어야 필요한 것만 남길 수 있음. 필요하지 않는 것은 굳이 남길 필요가 없음(= 데이터가 로깅되면 어떻게 분석할지 미리 생각해보기)

 

● 데이터 로깅 작업

데이터 로깅 작업은 개발이 어느정도 끝난 후, QA에 들어가는 시점 쯤에(거의 출시 직전) 작업함

  ○  개발 중에 기획이 바뀌면, 로깅하는 부분도 바뀌어야 하고 로깅을 놓칠 수 있으므로 보통 모든 개발이 완료된 후, 또는 로직이 진짜 확정된 경우 로깅을 시작함

  ○  데이터 로깅 작업(개발자가 데이터 로깅 설계를 보고 코드에 작성하는 경우)

 

● 데이터 QA

  ○  데이터 로깅 작업에서 로깅한 데이터가 맞는지 확인하는 과정

  ○  개발자가 직접 하는 경우도 존재하고, 기획자, PM, 데이터 분석가, QA 등 회사마다 어떤 사람이 할 지 다름

  ○  위의 데이터 로깅 설계에서 정의한 내용이 잘 들어가있는지 확인함

  ○  데이터 QA가 잘 되지 않으면 이상한 데이터를 볼 수 있으므로(데이터 유실 등) 꼭 확인해야 함

 

● 정리

  ○ 특정 기능 개발을 위한 작업을 시작할 때 지표에 대해 생각한 후, 개발 착수함

  ○ 그 후에 지표 기반으로 어떤 데이터 로깅을 할 것인지 설계

  ○ 설계한 내용을 개발자분들과 공유해서 어떻게 남길지 논의. 이 과정에서 개발이 어떻게 되었느냐에 따라 앱/웹에서 남길지 서버에서 남길지가 결정되기에 관련 개발을 하는 개발자분들과 모두 회의하는 것을 추천

  ○ 로깅을 모두 개발한 후, 데이터 QA를 통해 데이터가 잘 저장되었는지 확인

  ○ 간혹 데이터 로깅 없이 출시하자는 경우도 있는데, 이런 경우 유저가 어떤 부분을 사용하고 있는지 알 수 없어 그 이후 방향성을 잡을때 힘들어짐

 

 

 

이벤트 로그 설계 템플릿(Tracking Plan)

● 이벤트 로그 설계시, 스프레드시트 또는 노션에 이벤트 로그 설계한 내용을 잘 기록해두는 것이 제일! 중요함

  ○ 이 로그 설계가 잘 관리되어야 추후 데이터 분석시 어떤 이벤트를 봐야하는지 알 수 있음

  ○ 이 로그 설계가 잘 관리되어야 추후 데이터 누락이나 이상한 상황을 확인할 수 있음 (특정 이벤트가 이상하다 => 데이터 로그 설계 확인 => 이슈 확인 등)

  ○ 스프레드시트, 노션, 자체 개발한 시스템 등 어디에 저장할지는 조직의 상황에 따라 다름. 다만 처음 시작할 땐 개발 공수가 들지 않는 곳에서 시작하고 점점 개발하는 것을 추천

  ○ 관련 내용이 궁금할 경우 데이터 거버넌스(Data governance)를 검색하면 데이터 관리에 대한 내용이 나옴

 

● 이벤트 로그 설계는 Tracking Plan이란 단어로 검색하면 템플릿이 꽤 나옴

●  Tracking Plan을 작성하는 시점

  ○ 새로운 기능이 출시되는 경우

  ○ 새로운 이벤트, 새로운 이벤트의 파라미터를 수집해야 하는 경우

  ○ 데이터 타입을 수정하는 경우

  ○ 데이터 수집을 중지하는 경우

 

● Tracking Plan의 장점

  ○ 이벤트, 이벤트의 파라미터 등이 어떤 방식으로 기록되어 있는지 한 번에 볼 수 있음

  ○ 데이터 중복을 피할 수 있음. 동일한 데이터를 여러 번 수집하지 않음

  ○ 데이터의 부정확성을 피할 수 있음 : 일관된 방식으로 데이터를 로깅

  ○ 모든 사람들이 사용할 때, 동일한 규칙으로 로깅함

  ○ 처음 개발하는 사람들도 다른 사람이 이미 만든 이벤트 로그 설계를 참고할 수 있음

 

● Tracking Plan에 포함되는 정보

  ○ 이벤트의 이름

  ○ 이벤트의 설명

  ○ 이벤트의 카테고리가 무엇인지(추상화 또는 도메인)

  ○ 어느 시점에 실행되는지

  ○ 이벤트에 어떤 파라미터(또는 프로퍼티)를 가지는지

      - 파라미터의 타입

      - 파라미터의 설명

      - 파라미터의 필수 여부(Required)

  ○ 어느 플랫폼에서 남기는지

  ○ 언제부터 남기기 시작했는지

  ○ 언제 수집을 중지했는지

  ○ 설계 완료 유무, 개발 완료 유무, QA 개발 유무, 배포 유무 등

 

● Avo의 Analytics Tracking Plan Template

  ○ 특정 KPI, Metric에서 사용할 수 있는 이벤트를 모아두는 형태

 

● Segment의 Tracking Plan(Basic)

 

 

● Amplitude의 Basic Event Taxonomy Template

  ○ Amplitude는 event taxonomy라는 단어를 사용함

  ○ E Commerce용 Event Taxonomy, Game용 Event Taxonomy, Music App Event Taxonomy 등 다양한 Use case에 대한 템플릿 제공

  ○ 해당 템플릿은 회사에서 가질 수 있는 질문에 대한 답변을 하면서 이벤트를 정의함

 

● Practico Analytics의 Analytics Tracking Plan

  ○ Event Lifecycles를 구분하고 Priority를 작성한 부분이 특이함. 이 중요성을 관리할 주체가 필요함

 

● Mixpanel

  ○ Retail & ECommerce용 Tracking Plan, Saas용 Tracking Plan, Media & Entertainment용 Tracking Plan

 

● Data-led의 Tracking Plan

  ○ Activation, Adoption, Revenue, Page View 관점으로 데이터 로그 설계

 

● 위의 링크로 연결된 Tracking Plan을 모두 확인해보고 => 회사에 맞는 Tracking Plan을 만드는 것을 추천!

● 공통적으로 파라미터의 이름을 이렇게 사용하자! 정의하는 것도 중요하고, 화면의 이름도 개발-디자인-기획에서 통일되면 데이터 로깅 설계시 그대로 활용하면 좋음. 개발과 기획에서 부르는 이름을 통일하면 로깅 설계도 편함

 

 

 

개인적인 이벤트 로깅 팁(★★★)

● 로그는 최대한 자세할수록 좋지만, 우선순위를 정할 필요가 있음

  ○ 자주 봐야하는 지표라면 꼭 심는 것이 좋음

  ○ 모든 것을 다 로깅하면 좋지만, 그러기 힘든 이유는 로깅을 위해 추가적인 개발이 필요하거나 저장하는데 부하나 비용이 들 수 있음. 우선순위를 항상 작성하면 좋음

  ○ "모든 데이터를 저장하는 것이 중요한 것이 아니고, 필요한 데이터를 적재적소에 남기는 것이 중요함. 보고 싶은 데이터라고 하면 끝이 없기에 먼저 지표에 대해 생각하고 그 기반으로 로깅 설계하기!"

  ○ "사용되지 않을 데이터를 저장하기 위해 시간을 쓰는 것은 아깝다. 데이터가 남으면 어떤 분석이 가능할지 고민해보기"

● 클라이언트 vs 서버

  ○ 보통 서버 로그로 모두 해결될 수 있지만, 앱의 사용 관점이 궁금한 경우 클라이언트 로그를 심는 것이 좋을 수 있음

  ○ 서버 로그의 경우 어떤 페이지에서 입력했는지를 알 수 있어야 하는데, 이렇게 개발이 안되었다면 특정 API가 3 화면에서 불릴경우 어떤 화면에서 불렸는건지 확인할 수 없음

  ○ 클라이언트와 서버 로그는 보완재로 사용하면 좋음

● 보통 로그 파일로 저장하면, AWS S3에 저장하는데, 이 파일을 지우지 않고 보관하는게 좋고, 비용상의 이슈가 있다면 AWS의 콜드라인으로 저장해 비용을 절감할 수 있음

● 내가 아는 것 != 개발자가 아는 것

  ○ 개발자의 언어로 이해해야 함

  ○ API 호출이라면 Request하는 시점을 기록할 것인지, Response를 기록할 것인지(성공/실패 유무나 실패의 원인 등이 궁금한 경우) 정확히 명시해줘야 커뮤니케이션이 좋음

● 서비스마다 다름

  ○ 게임이여도 일반 RPG, 방치형 RPG 모두 비슷하지만 어떤 것을 로깅할지에 대한 생각이 다름

● 로그 네이밍 룰이 있으면 좋음(영어 동사로 시작한다, 명사로 시작한다 등)

● 어떻게 개발되었느냐에 따라 어디에 로깅을 남길지가 다르기 때문에 협업! 기획자, PM, 개발자(프론트,앱,서버), 데이터분석가, 데이터엔지니어와 적극적으로 이야기하기

● 로깅할 때, 개발이 많이 변경되야 하는 경우가 존재함. 이런 경우 이 데이터를 통해 어떤 지표를 볼 것이고, 이 지표가 어떻게 변하면 우리가 이런 행동을 할 수 있다고 적극적인 데이터 활용 사례를 이야기하며 개발자분들을 설득하기

  ○ 데이터 로깅이 불필요한 일이 아니라는 것을 지속적으로 알려주며, 이 데이터를 통해 이런 분석이 나왔다고 감사함 표현하기!

  ○ 왜 이 데이터 로깅이 중요하고, 어떤 문제를 해결할지에 대한 목적을 알려주는 것이 중요함

● 데이터 로깅 설계에 집중한 후, 데이터를 잘 확인할 수 있는 공간에 대한 이야기를 하는 것도 중요함(데이터를 잘 봐야 의미가 있으니!)

● 이벤트 이름을 파라미터까지 포함해서 저장하는 경우 vs 이벤트만 추상화하는 경우

  ○ 전자  event_name : click_signup

  ○ 후자  event_name : click으로 남고 파라미터인 component_name : signup으로 저장하는 경우

  ○ 어떤 플랫폼을 사용하느냐에 따라 다른데, Firebase나 Google Analytics라면 이벤트 이름의 갯수 제한이 있음(500개). 따라서 이런 경우에 이벤트 이름은 추상화하고, 파라미터로 관리하는 것이 좋음

     - 전자의 경우도 빅쿼리에서 쿼리하는 비용 차원에서 파라미터를 포함하지 않아서 쿼리 비용이 감소함(파라미터까지 쿼리할 경우 빅쿼리에서 비용이 증가되기 때문)

  ○ 장기적으로 잘 관리하기 위해선 이벤트 속성을 추상화하는 것이 좋음

 

 

 

데이터 QA

● 데이터가 제대로 들어가는지 확인하는 과정

● 회사에서 겪을 수 있는 케이스

  ○ 오타!

  ○ string으로 넣어야 하는데 integer로 넣은 경우!

  ○ 안드로이드와 IOS가 다른 경우!

  ○ 갑자기 특정 버전부터 값이 남지 않는 경우!

● 데이터 QA를 위한 자동화 시스템을 만드는 것도 좋음

● Firebase, Google Analytics의 경우 DebugView 사용하고, 서버 로그의 경우 자체적으로 구축한 시스템을 사용함

● 데이터 QA 자동화할 요소

  ○ 해당 이벤트에 값이 들어갔는가?

  ○ 파라미터가 잘 설정되어 있고, 값이 저장되는가?

  ○ 값이 여러가지인가?

  ○ 기존에 정의된 타입과 동일하게 데이터가 저장되는가?

  ○ 갑자기 n일 동안 데이터가 들어오지 않았는가?

● 앱/웹에서 개발 버전에선 토스트 팝업으로 저장되고 있는 로깅을 보여주면 DebugView를 보지 않아도 돼서 편함

 

 

 

정리

● 제일 중요한 건 전사적으로 이런 데이터를 잘 관리해야 데이터를 확인할 수 있음(Tracking Plan)

 

● 데이터 분석 전에 중요한 것은 데이터 로깅 설계! 데이터 QA!

 

● 앱,웹 사이드에서 저장되는 데이터는 유저의 인터랙션 데이터, 서버 사이드에서 저장되는 데이터와 보완재로 사용할 수 있음