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

[Other skills]

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

indongspace 2024. 9. 2. 22:26

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

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

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

이벤트 데이터 로그 설계, 데이터 로그 설계, 데이터 로깅, 데이터 QA에 대해 작성한 글입니다 키워드: 데이터 로깅, 데이터 로깅이란, 데이터 로깅 시스템, Firebase event logging, 이벤트 로그 설계,

zzsza.github.io

데이터 로깅 프로세스

● 단계별 설명

○ 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일 동안 데이터가 들어오지 않았는가?