Taxomony, 유저 행동 로그 이름 정하기
유저 행동데이터 분석을 위해 꼭 필요한 유저 행동 로그 데이터 기획
유저 행동 로그(이하 이벤트)들은 보통 화면의 UI가 변경되는 시점에 어떤 분석을 할 지 계획하면서 정하게 됩니다.
개인적으로 이벤트를 계획할 때 중요한 건 최적화된 메모리 관리와 분류 체계를 정하는 일이라고 생각하는데요.
유저 볼륨이 늘어날 수록 이벤트 데이터는 선형적으로 증가하기 때문에 꼭 필요한 이벤트만 심어서 불필요한 메모리가 쓰이지 않게 관리해야합니다. 그리고 이벤트명에 대한 규칙을 정해서 분석 할 때 찾아 헤메는 일이 없어야하죠.
사실 이벤트 데이터는 프로젝트가 진행될 때 그리 원활히 기획되지 않을 수 있습니다. 왜냐하면 기능을 개발하다보면 기능 그 자체에만 집중하고 추후 성과분석은 어떻게 할 계획인지 함께 고려되기 힘든 상황이 벌어지기 때문이예요.
그래서 저는 이벤트 로그를 심을 때에 필요한 프로세스 문서를 만들고, 기획할 때 필요한 항목들을 가이드 시트에 넣어서 원활히 이벤트 기획이 이루어 질 수 있도록 구성원에게 공유하여 상황별 규칙을 업데이트 해 나가는 일을 담당하고있습니다.
이번 글에서 공유드릴 부분은 분류 체계에 대한 일입니다. 이를 영어로는 Taxonomy라고 부르고 해외에서는 Taxonomist, Taxonomy Specialist가 있을 정도로 세분화 되어있는데요. 바로 이벤트명을 짓는겁니다.
원티드에는 원티드 채용 서비스 외에도 여러 서비스가 있어요. 그리고 각각 개발된 환경도 다르고 분석하는 환경도 다르죠.
그래서 우선 전체적으로 Taxonomy에 대한 규칙을 정하고, 각각의 서비스마다 달라야만 하는(주로 페이지 구성에 따라 정해짐) 규칙을 별도로 업데이트하고있습니다.
이제, 이벤트와 프로퍼티를 기획 할 때 사용하고있는 규칙을 소개해 볼게요. (이벤트-프로퍼티 구조는 이해하고있다고 가정)
Events
이벤트명 정하기
- 언더바 2개
__로 depth 표현
– 도입배경: ‘하위’를 의미하는 코딩 규칙 차용
– 구성:{prefix}__{상세정보}__click - prefix로 페이지정보와 서비스 구분하기
– 페이지정보(화면에 노출된 tab 또는 gnb 명)
ex. 커리어:career__/ 채용:jobs__/ 이벤트:event__/ 이력서:resume__/ 포지션:position__등
– 서비스
ex. 원티드 긱스:gigs__/ 취업지원시스템:eas__등
이벤트 타입(발생시점) 정하기
- 클릭 시점
–__click/__start로 끝남 (생략 가능)
– 유저가 버튼/배너/아이콘 등을 클릭한 시점 - 처리완료 시점
–__complete/__done으로 끝남
– 페이지/화면 상에서 유저가 클릭 또는 설정을 완료하여 데이터(DB)가 변경되는 시점
– 웹: 주로 서버 이벤트(not 프론트)로 처리
– 앱: 서버상 데이터 변경 시점으로 맞춤 - 페이지/화면이 로딩 완료되는 시점
–__view로 끝남
– 페이지/화면의 뷰이벤트
Properties
이벤트 프로퍼티 정하기
- 이벤트 발생 위치를 나타내는 pagePath(웹)와 screen(앱) 값은 기본 이벤트 프로퍼티로 셋팅하기
- 자주 사용하는 프로퍼티명은 통일하기(이벤트명이 상이하더라도 프로퍼티명은 같게)
- AB테스트를 진행할 때
– 프로퍼티명:abTest/ a, b 값으로 구분
– 특정 영역나 페이지에서 진행되는 테스트 일 경우,abTest_페이지정보로 설정 - True/False의 데이터가 필요할 때
– 프로퍼티명:is...(camelCase) 소문자 true, false 값으로 구분
단, gigs 유저프로퍼티의 경우gigsIs... - Array형 데이터를 넣을 때
–[ ]," "와 같은 특수문자는 제외하고 값을,로 셋팅
이벤트 프로퍼티 발생시점 정하기
- 클릭/처리완료 시점 이후 변경이 완료된 값으로 적재
- 변경 이전값을 넣고자 하는 경우 별도의 프로퍼티 생성
– 프로퍼티명 예시:beforeUrl
유저 프로퍼티 정하기
- 이벤트를 기준으로 insert/update 할 것인지, 별도 업데이트 주기를 설정할 것인지 시점과 정합성을 관리합니다.
함께 이름 지어보기(Hands-on)
- 상황: 포지션 클릭 후 지원 전환율을 확인하고싶다!
- 필요한 이벤트 나열하기
– 포지션 클릭 → 포지션 뷰 → 지원하기 클릭 → 지원서 뷰 → 지원 완료 - 동일 화면 별 이벤트 나누기 (prefix 정의를 위해)
– 포지션 클릭, 포지션 뷰 →position__– 지원하기 클릭, 지원서 뷰, 지원 완료 →apply__ - 각각의 이벤트 이름 정하기
– 포지션 클릭 →position__click– 포지션 뷰 →position__view– 지원하기 클릭 →apply__start– 지원서 뷰 →apply__view– 지원 완료 →apply__done - 앰플리튜드는 Chrome 확장 프로그램으로 실시간 액션에 대한 이벤트 확인 할 수 있습니다.
— — — — —
하나의 이벤트를 심는 데에는 이렇게 다양한 케이스들을 마주하게됩니다. 따라서 원티드랩에서는 위의 규칙를 따라 이벤트에 이름을 짓고 있습니다.
신규 서비스와 페이지가 우후죽순 생겨날 수록 데이터는 방대해지고 찾기 힘들어지기 때문에 네이밍 분류 가이드 체계를 갖추고 구성원에게 전파하는 것이 저의 역할입니다. 그 결과 원티드는 데이터가 흐르는 환경이 되었고, 구성원들이 데이터를 찾는 과정에 많은 힘을 들이지 않게 하는 데에 기여하고 있지요.
이 글을 통해 이벤트 체계를 더 잘 구성하려는 분들께 도움되시길 바라며 공유합니다.
감사합니다 :)
