🌈 데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것 🎁 이 자료를 추천하는 이유 - 데이터 분석이 아닌, 데이터 로그 설계, 데이터 로깅 관련된 자료입니다 - 생각

🌈 데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것 🎁 이 자료를 추천하는 이유 - 데이터 분석이 아닌, 데이터 로그 설계, 데이터 로깅 관련된 자료입니다 - 생각보다 이런 자료가 많이 파편화되어 있고, 없길래 제가 정리해봤습니다 - 4-5년간 데이터 로깅 설계를 하며 느낀 점도 간단히 작성했습니다 👍 읽으면 좋은 분 - 데이터 로그 설계를 해야하는 기획자, PM, 데이터 분석가 - 데이터 로그 설계에 대해 궁금하신 분 📋 내용 - 데이터 로그란 : “특정 상황을 이벤트로 정의하고, 이벤트의 파라미터가 어떤 것으로 저장해야 하는지” 등의 내용을 정의(설계)하는 행동을 데이터 로깅, 이벤트 로그 설계등으로 부름 - 데이터 로깅을 해야 하는 이유 - 데이터를 정확히 보기 위해, 데이터를 올바르게 기록해야 함 - 데이터를 잘 심지 않으면, 이상한 데이터를 볼 수 있음 - 혹은 과거에 출시된 기능에 대한 데이터 로깅을 하지 않았다면 그 데이터는 추가로 로깅하지 않는 이상 볼 수 없음 - 데이터 관련 책, 강의에서 나오는 예제 데이터 이미 누군가 데이터 로깅을 진행한 결과를 집계한 데이터 - 회사에서 겪을 수 있는 상황 - 로깅을 신경쓰지 않고 진행 ⇒ 특정 기능 배포 ⇒ 성과를 확인하려고 하니, 데이터에 누락이 있음을 발견(혹은 잘못된 로깅) ⇒ 다시 로깅을 한 후, 배포 ⇒ 과거 성과는 알 수 없음 - 이런 경우를 방지하기 위해 데이터 로깅도 항상 진행쓰고 + 데이터 QA도 진행해야 함 - 데이터 로그 설계를 위한 기본 상식 - 1) 데이터가 어디에서 발생하는지 확인해야 함(Source) - 2) 웹뷰(WebView) - 3) 딥링크(Deeplink) - 4) 구글 애널리틱스(Google Analytics) - 5) 구글 파이어베이스(Google Firebase) - 6) 구글 태그 매니저(GTM) - 7) 배포의 용이성 이벤트 파라미터, 유저 프로퍼티 이벤트 - 예를 들어 회원 가입 버튼(Component)을 클릭한 경우 - event : Click - 이벤트의 파라미터로 “어떤 버튼”을 클릭했는지 기록. 예: component_name: sign_up - 이벤트의 구체적인 상태, 세부 정보를 파라미터(또는 프로퍼티)에 저장함 - Firebase에선 이벤트의 파라미터를 Key라고 부르고, 파라미터에 저장된 데이터를 Value라고 부름 유저 - 유저가 특정 이벤트를 할 당시의 정보를 유저 프로퍼티로 저장함 - 예를 들어 이커머스 앱에 접속한 이벤트에 그 유저가 여태까지 제품을 구매한 횟수와 총 누적 구매 금액 등이 유저 프로퍼티로 저장되어 있으면 구매 금액별 분석을 할 수 있음 - 이런 데이터는 Database에 저장될 수도 있는데, 특정 시점의 테이블에 저장된 데이터를 추출한 후, Join해서 사용할 수도 있음. 그러나 분석의 용이성을 위해서 유저 프로퍼티로 저장할 수도 있음 - 단, 유저의 DB에서 확인할 수 있는 정보 중 정말 의미가 있다고 판단되는 것만 유저 프로퍼티로 넣는 것이 좋음. 혹은 사용자에 따라 수시로 변할 수 있는 옵션이거나 서버에선 모르는 경우 로깅 - AB Test 같은 실험할 때, 실험군과 대조군이 유저별로 계속 고정되어야 하기에 이런 정보를 유저 프로퍼티로 넣음 이벤트 로그 설계하는 방법 - 이벤트 로그의 3가지 Element - 1) 발생한 이벤트가 무엇인지(Event) - 2) 어느 시점에 실행되는지(Trigger) - 3) 어떤 상태(State)를 가지는지 데이터 로깅 프로세스 - 데이터 로깅 설계 - 데이터 로깅 작업 - 데이터 QA 이벤트 로그 설계 템플릿(Tracking Plan) - 이벤트 로그 설계시, 스프레드시트 또는 노션에 이벤트 로그 설계한 내용을 잘 기록해두는 것이 제일!!! 중요함 - 다양한 회사의 템플릿 개인적인 이벤트 로깅 팁(★★★) - “모든 데이터를 저장하는 것이 중요한 것이 아니고, 필요한 데이터를 적재 적소에 남기는 것이 중요함. 보고 싶은 데이터라고 하면 끝이 없기에 먼저 지표에 대해 생각하고 그 기반으로 로깅 설계하기!” - “사용되지 않을 데이터를 저장하기 위해 시간을 쓰는 것은 아깝다. 데이터가 남으면 어떤 분석이 가능할지 고민해보기” - 어떻게 개발되었느냐에 따라 어디에 로깅을 남길지가 다르기 때문에 협업!! 기획자, PM, 개발자(프론트, 앱, 서버), 데이터 분석가, 데이터 엔지니어와 적극적으로 이야기하기 데이터 QA - 회사에서 겪을 수 있는 케이스 - 오타! - string으로 넣어야 하는데 integer로 넣은 경우! - 안드로이드와 IOS가 다른 경우! - 갑자기 특정 버전부터 값이 남지 않는 경우!