brunch

라이킷 17 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Beori Apr 25. 2021

Firebase 이벤트로 GA에 데이터를 쌓아보자

사용자가 우리 앱을 어떻게 사용하고 있는지 궁금하다면, 사용자 로그를 통해 확인할 수 있다.

자체 로그를 쌓을 수도 있지만, 여의치가 않은 스타트업에서는 GA만한 것도 없다고 한다.

일단 무료고, 무료인 것 대비 사용 가능한 기능이 많아서가 가장 많은 이유였다 (Firebase는 유료로 쓰고 있다)

GA에 이벤트 로그를 쌓을 때 가장 헷갈렸던 부분은 웹과 앱의 영역이 다르다는 것,

그리고 이벤트를 정리하는 동안 GA4로 변경되던 시기여서 알아봐야 하는 것이 많았다는 점이다.

GA4에 대해 찾아볼 글과 정보도 별로 없었던 상황이라, GA4는 일단 제쳐두고 생각하기로 했었다.

지금은 GA4에 대한 글이 많아졌다:)

GA에서 제대로 통계를 보기 위해 우선 한 일은 1) 화면명 정리, 2) 이벤트 로그를 정의하는 것이었다.

GA에서는 웹의 경우 Page Title, 앱의 경우 Screen Name으로 나오게 되는데, 서비스 내에 웹과 앱 영역이 모두 있어 한번에 볼 수 있도록 정리가 필요했다.

화면명 정리하기

먼저, 화면명은 Screen Class, 국문 화면명, 영문 화면명, 화면코드와 AOS/iOS/WEB의 구분 등으로 나누어 작성했다. 영문 화면명을 쓰기로 하고 화면 하나하나 명칭을 붙였다. 화면명은 네이밍 규칙을 세우고, 쉽게 파악할 수 있도록 영문으로 작성했다.

네이밍 규칙에는 파스칼(pascal case), 카멜(camel case), 언더바(snake case) 3가지 규칙이 있는데, 언더바 방식을 선택했다. 카멜과 언더바가 일반적이나, 가독성 측면 등을 고려해서 선택하게 되었다.

파스칼 방식 : MyName (단어+단어 일 때, 단어 첫 글자를 모두 대문자로 표기)

카멜 방식 : myName (단어+단어 일 때, 두 번째 단어의 첫 글자부터 대문자로 표기)

언더바 방식 : my_name (단어+단어 일 때, 언더바로 구분)

화면코드의 경우 공통적으로 사용할 용어부터 정리했다. 예를 들어, 구매는 purchase, 수정은 modify, 작성은 write, 매장은 shop, 상품은 item, 목록은 list로 정했다. 매장 목록의 경우 shop_list 이런 식으로 확장해서 쓸 수 있도록 정리했다. 이 용어는 화면명뿐만 아니라, 이벤트명에도 활용했다.

그 후, 화면코드가 중복되지 않도록 화면코드 관리 문서도 생성했다. 예를 들어, 메인 홈의 경우 Home이라는 용어를 쓸 것이고, 화면코드는 HM 이런 식이다. 그리고 이 화면코드에 숫자를 붙이는 방식으로 화면별로 화면코드를 생성했다.

GA에서 로그를 보는 목적으로 정리하기 시작했지만, 커뮤니케이션에 활용하고자 각종 팝업까지 모두 정리했다. 프로덕트가 복잡하다 보니 한번 정리하고 관리하면, 모두가 같은 워딩을 쓰게 될 테니 효율적이라고 생각했기 때문이다. 디자인, 개발에서도 해당 용어들을 활용하기로 했다. 물론, 익숙해지기까지 시간은 필요하겠지만 말이다.

추가로, 화면코드는 추후 자체 로그를 쌓게 되는 시점이 왔을 때 활용하고자 했다. 이벤트를 GA에 전송할 때 가급적 짧은 명칭을 쓰는 것이 데이터도 아낄 수 있기 때문이다. 보는 사람은 수고스럽긴 하겠지만, 로그가 많아질수록 부담이 될 터이니 고려해야 할 부분이다.

이벤트 정리하기

화면을 모두 정리하고 난 후, 보고자 하는 이벤트를 정리했다. 앱의 경우 Firebase를 통해서 이벤트 로그를 심게 된다. 이벤트 로그는 이벤트명, 트리거, 파라미터, 파라미터 값을 정리하면 된다.

물론 이벤트를 정리하기 전, 왜 이 이벤트가 필요한지, 이 이벤트를 통해 어떤 유의미한 인사이트를 얻을 수 있을지, 어떤 개선을 할 수 있을지 등에 대한 목적과 활용에 대해 충분히 생각해야 한다. 그래야지만 의미 있는 데이터를 쌓고 이를 통해 실질적 개선을 얻어 낼 수 있을 것이다. 혹은 사용성이나 원하는 결과를 확인하는 근거가 될 수도 있겠다. 이외에도 Firebase 이벤트는 500개의 개수 제한이 있을 뿐만 아니라, 이벤트 로그 자체는 서비스의 퍼포먼스에도 영향을 미치는 부분이기에 개발자를 설득할 근거도 필요하다.

이벤트에 대한 목적이 정리가 되었다면, 이제는 이벤트명, 트리거, 파라미터, 파라미터 값을 정리하면 된다.

이벤트명은 사용자가 어떤 액션을 했을 때 GA에서 확인할 수 있는 명칭이다. 예를 들어, 필터 버튼의 hit 이벤트를 보길 원한다면 'filter_btn_hit'과 같이 적절한 이벤트명을 정하면 된다. 이벤트명은 원하는 대로 넣을 수 있는데, 일관되게 사용하기 위해서 위에서 정리한 용어들을 활용했다.

(**커스텀 이벤트를 넣기 전 자동으로 수집되는 이벤트와 파라미터를 파악하면 수월하다)

트리거란 이벤트를 전송하는 사용자의 특정 Action을 의미하는데, 위에 예시에서는 '사용자가 필터 버튼을 터치했을 때'가 트리거가 된다.

파라미터의 경우, 이벤트가 발생했을 때 추가적으로 보고자 하는 데이터를 함께 GA에 전송하여 확인할 수 있는 매개변수이다. 예를 들어, 결제가 일어났을 때 '상품명, 상품 카테고리, 결제수단, 할인쿠폰 정보' 등 이벤트에서 확인하고 싶은 항목들이 있다면 파라미터로 설정하면 된다.

파라미터 값은 예를 들어, 상품명이 파라미터라면 '나이키 맨투맨', 결제수단을 파라미터로 설정한 경우 '네이버페이'가 파라미터 값이 된다. 즉, 결제가 일어났을 때 네이버페이로 결제한 사용자수라던지, 결제 수 등을 확인할 수 있다.

예시)

Event : payment_done

Trigger : 결제가 완료되었을 때

Parameter : 결제가격

Parameter Value : 100,000원