brunch

You can make anything
by writing

C.S.Lewis

by Jongwony Jul 14. 2022

제품에 이벤트 올바르게 심기

Amplitude 관점에서

이 내용은 개발자, 마케터, 프로덕트 오너, 데이터 부서가 있거나 스타트업에 계신 분들을 대상 독자로 합니다

여기서 말하는 "이벤트" 란 유저가 발생한 사건을 의미하며 유저 행동을 기록하는 로깅의 의미도 포함합니다.


제품에 이벤트를 심는다는 것은 그 유저의 행동을 다양한 관점으로 보고 제품에 더 나은 의사결정을 위한 데이터를 제공한다는 것이다.


스타트업에서 바쁜 일정 속에 이벤트를 심기는 생각보다 훨씬 까다롭다

그리고 데이터적인 관점과 - 제품적인 관점이 충돌할 때는 더욱 그러하다

 안에서 올바르게 이벤트를 심는다는건 어떤 것일까


첫 번째 예시

(PO) 저번 스프린트에 만들어주신 화면에서 이 버튼이 유저에게 얼마나 영향을 미쳤는지 성과를 측정하고 싶어요
(데이터) 이전에 여기에 심는 버튼 이벤트 이야기 나왔던것 같은데 그거 있으면 될 것 같아요
(개발자) 아 이거 저번에 당장 필요없다고 하셔서 저번 스프린트에서 빠졌어요
(데이터) 그럼 이제 심어야 할 것 같은데요
(PO) 이 데이터는 이번 스프린트에서 배포 나가고 유저 데이터 좀 들어와야 되네요


이렇게 기능 만들어 두고 한 달을 기다리게 된다

데이터 관점에서는 이벤트를 가능한 한 다 심는게 좋다

그럼 그냥 그렇게 하면 되지 않을까?


이번엔 제품 관점을 보자.


두 번째 예시

(개발자) 이번에 요청 주신 이 버튼 이벤트요, 유저의 상태 값이 이 화면에 왜 필요한가요?
(PO) 이 버튼이 주요 지표에 영향이 어떻게 미치는지 측정하고 싶어요
(개발자) 이거 지금 화면에서는 얻을 수 있는 값이 아니에요 이거 꼭 필요한가요?
(데이터) 네 이 지표가 KPI 니까요 이걸로 성과 측정을 해야 할거에요
(개발자) 그럼 서버에 추가로 API 에 작업을 먼저 요청 해야 할것 같아요
KPI 란 Key Performance Indicator 의 약자로제품 또는 기업의 정량적인 핵심 성과 지표를 나타낸다
API 란 application programming interface 의 약자로 서버에서 받은 데이터를 사용자에게 보여주는 과정에서의 개발자들의 규약이다

하지만 제품 관점에서는 이벤트를 가능한 한 최소화 하는것이 좋다

제품 관점에서 화면과 전혀 관련이 없는 불필요한 서버 API가 더 필요할까?


사실 이런 고민은 제품과 PO사이, 데이터 플랫폼에서 애초에 고민을 많이 했을 것이다

이 고민은 어떻게 했을까


위에서 극단적인 두 사례를 제시했지만, 첫 번째 예시에서는 데이터를 다 심는게 올바른 방향이고

두 번째 예시에서는 불필요한 데이터는 빼는게 올바른 방향으로 보인다.


Amplitude 에서는 데이터를 두 가지 관점으로 나누었다.

하나는 이벤트를 로깅하는 관점이고, 하나는 유저의 상태를 로깅하는 관점이다

이를 위해서는 Event Property, User Property 개념을 알면 좋다.

Event Property  이벤트를 특정시점에 기록하는 스냅샷에 전달하는 데이터다.
User Property 란 유저에 대한 상태를 기록하는 누적 데이터다.


아래 그림과 같이 찍힌 이벤트를 보자.


이 시점에서 User Property 가 버튼을 처음 클릭할 때 로그인 했다라는 걸 기록한다고 가정해보자

유저가 마지막 로그인한 시간은 뒤에 이벤트를 기록할 때도 유저의 상태가 이렇다는게 계속 남는다.

누적값이니까.

하지만 유저가 로그인 버튼을 클릭했다라는 액션자체는 뒤에 계속 남을 필요가 없다.


그럼 다시 첫 번째 예시를 보면,

버튼 이벤트 자체는 화면에 있는 내용이고
이는 유저가 액션할 수 있는 모든걸 기록하는게 좋다

두 번째 예시를 보면

버튼 이벤트에 유저 상태를 이벤트로 기록하는게 아니라
이미 유저의 상태는 유저가 상태가 바뀌는 그 때에 기록하는게 좋고
버튼 이벤트를 발생했을 때 누적된 User Property 값을 가지고 분석하면 된다.


이 처럼 User Property 는 개발자가 빠뜨리기 쉽고 데이터를 놓치기 쉬운 대표적인 개념이다.

이 User Property 데이터는 성과를 보려는 데이터에 기록을 하는게 아니라, 실제 로그인할 때나 구매를 했거나 하는 상태가 바뀌는 그 때에 기록을 해야 하기 때문이다.


마무리하며

사실 이벤트를 올바르게 심는 다는 것은 정답이 있다고 생각하지 않는다.

하지만 Amplitude 에서 이 내용에 대한 고민을 많이 했고 GA4 에서도 웹과 앱이 통합되면서 세션 위주의 이벤트 개념으로부터 유저 위주의 이벤트 개념으로 전환한 듯 하다.

하지만 이렇게 특정 솔루션 위주로 얘기를 해도 자체 데이터 개발을 한다면 결국 이 개념을 차용하면 되고

쓴다고 하더라도 기능을 활용하지 못한다면 데이터에 구멍만 많아지고 정합성이 떨어져 신뢰할 수 없을 것이다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari