이벤트 로그 설계, Tracking plan만 짜면 되는 것 아니었나요? +Ampli Cli

글의 목적

네.. 저는 Tracking plan만 잘 짜면 로그 개발은 쉽게 슉슉 되는 건 줄 알았습니다. 하지만.. (후술)

데이터 분석가가 하는 일 대부분이 그렇지만, 직접 일해보거나 누가 알려주지 않으면 정말 알기 힘든 것이

"이벤트 로그 설계 잘하는 법 & 원하는 지표를 그래서 볼 수 있는 상황을 만드는 것" 이라고 생각합니다. 

Tracking plan을 처음 짤 때는 이벤트를 잘 짜는 것 자체도 물론 어렵지만.. (여러 개발 지식 들을 알아야하기에) 

그 뒤단의 , 앞단의 일도 매우 중요했습니다. 

 

따라서 과거의 저를 생각하면서 & 미래의 내가 잊지 말았으면 하는 바람을 담아 & 지금 고군분투하고 계실 분들에게 조금이라도 도움이 될까 하여 저의 고군분투 로그 설계 기록을 담아보았습니다. 

예상 독자

- 로그 설계는 했는데 데이터 로깅의 우선 순위가 계속 밀려 정작 데이터 분석하기는 힘든 상황인 주니어 데이터 분석가 or PM/PO 

- 어떻게 로깅을 좀 더 쉽고 간단하게 할 수 있을지 고민인 분 / 더 좋은 로그 설계를 위해 고민하시는 분 

- 우리는 왜 핵심 로그를 안심고 기능을 배포하는지 답답한 분 

 

문제 상황 

데이터 분석가가 

사용자 행동 트래킹을 위해 로그를 설계하고 적용하다 보면 부딪치는 가장 큰 문제가 있습니다. 

 

당연히 우리 DA들 입장에선 되도록 많은 데이터를 알고 싶기 때문에 한가득 tracking plan을 작성하여 전달합니다. 

 

• 그럴 때 벌어지는 흔한 사례 

1. DA : 이번에 들어갈 기능들 로그 설계 tracking plan에 정리했어요! 
2. 개발자분들 : 어..음..지금 개발 리소스가 없는데 배포 먼저 하고 나중에 심으면 안 될까요? 
3. DA : 네.. ㅜㅜ 어쩔 수 없죠 
4. Others : 이 데이터 알고 싶어요..! 
5. DA : 아..그게 리소스가 부족해서 로깅이 안되었어요..! 

- 무.한.반.복 - 

데이터 분석가 입장에서는 이 로그를 개발하는 데에 얼마나 많은 시간이 소요되는지 모르다 보니 안 쓸지도 모르지만 필요할지도 모르는 여러 데이터를 다 요청하고, 서로 힘들어지는 상황이 반복될 수 있습니다. 

여기서 문제는... 나는 데이터를 "분석"하는 사람인데 데이터가 없으면.. 할 수 있는 게 많이 없다는 것! 

 

* 로그 설계 참고 자료 :  데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것 

1. 프로덕트 기능을 런칭했을 때가 아닌,  지표가 올랐을 때 박수를 쳐야한다고 의사결정자를 설득한다. 

- 진지하게 고민해 볼 지점 

• 출처: 마켓핏랩 정성영님 멘토링 내용

✨ 왜 출시와 함께 로그가 안 심겨져 나갈까? 

 

Q : 출시를 기한에 맞춰하기 바쁜 상황에서, 

     가설에 기반한 실험으로 프로덕트를 개선하는 환경을 어떻게 조성할 수 있을까요?

 

A : 왜 우리는 태깅을 안하는가?  - 데이터 / 지표가 중요하다고 생각하는 사람이 의사결정자가 아니라서

 

의사 결정자는 프로덕트를 기능을 런칭했을때 박수 치는가?
지표가 올랐을 때 박수 치는가? 에 따라 나뉜다.  - 정성영님
         

✨ 어떻게 하면 의사 결정자를 잘 설득할 수 있을까? (개인적인 생각)

• 데이터를 활용해 작은 성공 경험을 선사해 필요성을 어필&신뢰 자본을 쌓는다.(데이터 이렇게 돈이 되잖아요..! 심어야겠죠..?)
• 권력 편향을 이용한다. (결정권자가 신뢰하는 / 자주 언급하는 회사나 사람이 있다 --> 멘토링을 받거나 블로그 등을 뒤져 인용하여 사용한다.  ex) 이 분이 이렇게 말씀하시더라고요..!) 
• 데이터를 수집하지 않으면 나타나게 될 /된 문제점들을 현 상황에 대입해 직시하게 한다.

로그를 안 심으면 나타나는 문제점

본인 작성

2. 개발해야 할 로그 양은 줄이고 설득력은 높인다. 

 1) 이벤트에 우선순위를 매긴다. 

 

NEW THING : 신규 기능과 관련된 것으로, 가장 우선순위 높음

MUST HAVE : 핵심 지표에 필요한 데이터로, 반드시 개발되어야 함

SHOULD HAVE : 핵심 지표까지는 아니지만, 의사 결정에 필요함

COULD HAVE : 있으면 좋지만, 없어도 아직 큰 문제는 없음

ex)  바쁘시면 빨간색까지만이라도 부탁드려요..!!

 

 2) 데이터 수집의 목적(Purpose of Collection) 칼럼을 Tracking Plan에 추가해 작성한다. 

 

효과 

 

"쓸데없는 데이터 쌓는다는 거.. 내 이야기 아닌 줄 알았는데... 어랏...?" 순간을 방지할 수 있다. 이 로그 개발을 통해서 구하고자 하는 지표를 칸 옆에 명시하고, 이를 통한 미래 Action Item을 명시하면 몇 달 뒤 해당 데이터를 분석할 때 맥락을 쉽고 빠르게 파악할 수 있을 뿐 아니라, 개발자 분들에게도 데이터 수집의 목적과 필요성을 효과적으로 설득시킬 수 있다. 

 

 

*여기서 데이터 수집의 목적을 정하지 못한 채 Tracking Plan을 작성하는 가장 큰 요인은 해당 기능을 기획하는 기획자/PM/디자이너 분들과의 적극적인 소통의 부재라고 생각합니다. 더 깊이 들어가면 기획하는 분들도 이거 왜 만드는지 모르고 -> 그러니 알고 싶은 데이터가 없고 -> 알려줄 수 없는 상황이 될 수 있죠. 따라서 로그를 설계하기 전에 반드시 화면 설계서 등을 보면서
1. 어떤 데이터를 보고 싶으시고 2. 그 목적은 무엇인지 (for What) 두 가지를 충분히 논의하는 것이 필요하다고 생각합니다.  

 

3) 페이지 진입시점을 기준으로 이벤트를 설계해 로깅 양을 줄인다. 

 

이건 당연히 일을 해봐야 아는 내용으로... 사수 없이 던져진 1인 데이터 분석가들에겐 서툴 수밖에 없다.

 

되도록이면 페이지 진입 시로 로그를 설계하면 좋은 이유

• 개발자 분들에게 이벤트 trigger가 클릭 시 인 것보다 페이지 진입 시 인 것이 코드 작성에 있어서 훨씬 리소스가 적게 든다고 하신다. --> 개발 시간 줄일 수 있음
• 클릭이 꼭 필요한 이벤트 들은 어쩔 수 없지만, 화면이 다양한 앱 프로덕트 등의 경우에 지속적인 UI 변경이 이루어짐으로 화면 단위로 로그를 설계하면 신규 기능이 생길 때마다, 버튼이 새로 생길 때 마다 등등 새로 이벤트를 설계할 필요 없이 A 화면 진입 후 B 화면 진입 등으로 전환율 등 다양한 지표를 알 수 있다. 때문에 이렇게 하면 설계할 로그의 양이 크게는 3분의 1로 준다는 사실..! 

* GA는 페이지 진입 단위이지만 Amplitude의 경우 이벤트 기반

3.  DA가 로깅의 Funnel 스텝을 줄이기 

1) 개발진의 String ID 혹은 디자이너 분들의 컴포넌트 용어 따르기 

 

이벤트 수가 많아질수록 이벤트 로그 이름 다르고, 앱 개발 string ID 다르고 하면 혼란이 올 수 있습니다. 따라서 UX writing 등에서 String ID가 정해졌다면 최대한 이에 맞춰서 비슷하게 용어를 통일하면 불필요한 의사소통 비용을 줄일 수 있습니다. 

 

2) Amplitude를 쓴다면, Ampli CLI 도입 고려해 보기

 

보통 Tracking plan 템플릿 툴로 Google Sheet를 많이 사용하는데요. 

현재 가장 좋은 툴이긴 하지만, 개발자 분들의 입장에선 여러 불편함이 있을 수 있다고 합니다. 

 

여러 문제점들 

• Amplitude 이벤트를 쏠 때 하드 코딩된 문자열을 발송하면서 여러 문제점들이 발생함.
  • 문자열 잘못 작성해서 실수하거나 계속 최신화해야 하는 문제 등 
  • 자동 완성이 안되기 때문에 일일이 구글 시트를 보면서 복붙 해야 함, 좋은 개발자 경험이 아님. 
• tracking plan의 Developer Notes에 히스토리 기록을 위해 지라 티켓 번호를 남기시는데, 트랙킹이 다소 어려움, 이벤트 로그 설계가 필요할 때 티켓이 생성되고 그 안에 개발에 필요한 정보들이 다 들어있으면 좋겠음
• 개발/배포 등을 체크하는 과정에서 버전 관리가 어렵고 실수할 가능성이 농후함 
• 변경된 사항, 신규 요청 사항 등을 Google Sheet의 댓글 기능으로 기록을 하고 멘션 하다 보니 트래킹이 어렵고 일일이 다 보기가 어려움

해결 방법 

개발자 분들 영역 : Ampli CLI를 설치하고 적용합니다. * GA는 GTM이 있음 

효과 : 이전처럼 복붙할 필요 없이 점 (.)을 찍으면  이벤트/프로퍼티/Enum값들이 자동 완성됩니다. 매우 편해졌다고 합니다. 

 

데이터 분석가 영역 

• 사실 데이터 분석가가 할 일은 늘어납니다 ^^ 하지만 데이터만 수집할 수 있다면..✨

프로세스 

1. 기획단과 협의하여 필요한 지표 / 데이터를 정의한다.
2. Google Sheet에 로그를 설계한다.
3. Amplitude tracking plan에 각 신규 기능별로 branch를 만든다.
4. 각 이벤트 프로퍼티 등을 기입한다
5. 지라 티켓을 생성한다.
6. 이벤트 예약어/중복 이슈 등을 개발자 분들에게 전달받아 수정한다.
7. 개발자 분들이 OS별로 로깅하신다.
8. 보드 이슈를 보며 개발 / 배포 등을 Google Sheet에 기입한다.
   1. In review : 개발 / Done : 배포
9. QA 한다.
10. 데이터를 분석한다. / Action Item 도출한다 / 데이터 토론회에서 공유한다.

 

--> 결국 Tracking plan 시트는 분석가만 보고, 진행 상황을 체크하고 매니징 & 설계하여 실수의 가능성을 줄이고 서로 win - win (?) 할 수 있습니다. 

 

처음 접하면 가장 어렵고도 중요한 이벤트 로깅... 더 열심히 배워가겠습니다.

 

감사합니다. 

References

• 데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것       
• PM을 위한 데이터 리터러시(프로덕트 데이터 분석)   
• 그로스해킹 - 양승화