티스토리 뷰

코멘토에서 라이브 PT - 'Firebase와 GA4로 사용자 데이터 수집하고 제품 개선하기' 수업을 들었다.
이에 대해 내용 복습 및 학습 일지 챌린지 참가를 위해 작성한다.

데이터 분석을 위한 지표 설정 방법은 절대 답이 없다!
- 가장 유의미한 결과 및 활용 할 수 있는 자료가 나올 수 있도록 잘 설정하면 되는 것이다.


몇 가지 질문에 대한 답 정리
Q. GTM을 잘 다루려면 Front End 지식이 어느정도 있어야 하는가?
A. 필요하다. GTM(구글태그매니저)을 잘 하려면 스크립드의 동작 순서(윈도우가 로깅되고, 자바스크립트가 실행될 수 있는 것이 실행되고 등) 를 잘 알고 있어야 이벤트가 왜 발생 되었는지, 왜 발생이 안되었는지 알 수 있다.

Q. 유저가 스크롤을 얼마나 했는지 데이터 추적이 가능한지? 기술적으로?
A. 가능하다. 하지만 개발에 투입되는 리소스가 엄청 많이 든다. 개발자와 충분히 이야기 많이 해보고

1. Firebase에 대한 간략한 Overview


Firebase는 구글이 인수 후 앱 개발 시 필수적인 도구가 되었다. 특히 그 이유는 푸쉬 알림에 필요한 클라우드 메시징 때문이다.
푸쉬 알림을 날리려면 파이어베이스 SDK에서 클라우드 메세징을 이용하기 때문이다.
또한 현재는 GA4=Firebase라고 생각해도 될 정도이기 때문에, firebase용의 데이터 로깅 플랜 = GA4용의 데이터 로깅 플랜과 같다.


2. 웹/앱에 따른 데이터 수집 비교

(1) 공통점
=> 사실 큰 차이는 없고, 언어만 다르지 그 큰 틀은 대체로 같다.
*동일 운영체제에서도 개발 언어, 프레임워크의 변화가 존재한다.

*동일 디자인/기능/언어/프레임워크인 경우에도 차이가 있다.
- 로그 기능의 실행 조건과 타이밍
ex) 버튼 클릭의 경우 : 우리의 입장에서는 버튼 클릭일때 이벤트 발생하도록 요청하지만, 실제 버튼은 눌럿다가 떼는 두가지 동작의 합침이다. 그렇기에 누를때 이벤트 발동시킬지, 뗄 때 발동시킬지하는 것도 알려주면 좋다.
- 로그 기능 객체의 호출, 생성, 실행 과정
- 로그 기능 메서드의 인자 입력 인터페이스
- 로그 기능 입력시의 값의 타임
이렇듯 개발자의 취향, 요청자의 설정에 따라서 다른 결과를 만들어 낼 수 있다.

(2)데이터 수집에서 웹과 앱의 차이점
App
- 모든 페이지 정보와 템플릿이 로컬에 저장된 상태로 시작
- 페이지의 템플릿이 업데이트 될 때 화면 조회 이벤트 발생

Web
- 요청한 하나의 페이지를 받아와 시작
- 페이지의 로드가 끝날 때 화면 조회 이벤트 발생

로그를 심어달라고 요청하는 사람의 입장에서는 언어는 신경 안써도 되고, 그저 앱인지 웹인지 모든 페이지 정보와 템플릿이 로컬에 저장된 상태로 시작되는지 / 페이지의 로드가 끝날 때 화면 조회 이벤트가 발생하는지 정도 파악해주면 좋다.

*추가로, 웹에서도 SPA(Single-page application)이라는 것을 통해 웹에서도 앱처럼 페이지 정보와 템플릿이 로컬에 저장된 상태로 시작되는 트렌드가 생기고 있다.


3. Tracking plan
*개발자나 분석가에게 효과적으로 이해 될 수 있도록 공유 할 수 있는 문서면 되는 것이다! 너무 무겁게 생각하지 말자. 정답이 없다!
(1) 공통 가이드 라인

(2) Web 가이드 라인

웹은 페이지 뷰 만으로도 구매 전환 퍼널 설계가 가능하다.
url 이 변경되었다 = 화면이 변경되었다.
*팝업창의 경우 url이 바뀌는게 아니므로(예외적인 경우임) 개발자와 잘 이야기 해서 page view 이벤트를 부가적으로 설치해 관리한다.

버튼 클릭 데이터 수집 관련 : 요청하는 버튼의 이름이 실제 코드에 a등으로 지칭되어 적혀있을 것이다. 그러므로 개발자랑 이야기 할때 그 코드 내 버튼의 찐이름을 지칭하면서 ‘a버튼에 심어주세요’ 라는 식으로 말하면 상호 소통하기 편할것이다.

(3) 앱 가이드라인

앱은 웹처럼 url이 없다. 개발자들이 이용하는 viewcontroller나 activity가 있는데
하지만, 그렇다고 viewcontroller나 activity가 우리가 목표로한 그 화면이냐를 확실히 알려주냐? 라고 햇을때 yes가 아니다.
그러므로 screen view이벤트가 우리가 원하는 그 부분에딱 맞아 잘 활용 할 수 있는지 개발자와 충분히 검토해봐야한다.

**소카 화면을 예시로 데이터 수집을 위한 tracking plan 짜기


화면 구성

<화면 1, 2>, 참고로 화면 1 지도 위 S마크를 누르면 화면 2 처럼 차량 목록이 나오는데 화면 자체가 바뀌는게 아니라 팝업처럼 나오는 것이다.

<화면 3, 4>




Tracking plan

*map 화면은 첫 번째 화면, zone 화면은 두 번째 화면, reservation 화면은 세 번째 화면, purchase화면은 마지막 화면이다.
각각에 화면에 알맞는 특징을 잡아 Context 열에 스스로 정의 한 것이다.

*각각의 화면이 ‘노출'되었을 때 이벤트가 발생되어 로그를 남겼으면 좋겠다 라고 해서 trigger에 ‘노출'이라고 적은 것이다. 클릭 될 때 이벤트가 발생되길 원하면 클릭으로 적는 것이다.

*J열에서 zone_name 이벤트 파라미터를 추가 한 이유 : 주차장이 노출 될 때 주차장의 이름을 추적 할 수 있도록 하면 좋을 것 같아 zone name을 추가 한 것이다.(그 이유는 어떤 주차장이 인기가 많은지 알 수 있기 때문!)
-> J열에서 {{ zone_name }}을 통해 테이블을 링크 한 이유는 데이터 베이스에서 끌고 오라고 하기 위함이다. zone name을 '오토샵 주차장' 이라고 일일히 특정해도 되지만, 실제로는 전체 주차장들에 대해서 트래킹을 하는 것이기 때문에 아래에서처럼, 특정 데이터 베이스 테이블에서 가지고 오는 것이라고 일러주는 것이다. 그렇게 해서 다른 주차장들이 있는 곳에서도 {{ zone_name }} 링크만 달아놓음으로써 개발자가 주차장 데이터 베이스에서 끌고 오는 것이라고 알 수 있다.


*3,4번째 화면에서는 차종과 쿠폰 정보가 새로 나오게 된다.
그래서 고객들이 어떤 차에 관심이 많은지 알고싶기에 car_name 파라미터를 넣은 것이다.
또 쿠폰의 경우에도 쿠폰을 골랐으면 결제를 할 때 쿠폰을 얼마나 쓰는지, 어떤걸 쓰는지 찾아보고 싶기에 여기에서 coupon 파라미터를 추가한 것이다. 이렇듯 추적을 원하는 지표가 하나씩 더 있을 때마다 이벤트 파라미터를 하나씩 더 추가하면 된다.

*또한, 화면 1에서 보면 여러개의 플로팅 버튼(Floating_button)이 존재한다.(⬇️아래와 같이 저렇게 화면 위에 떠 있는 모든 버튼들을 플로팅 버튼이라고 한다.)

3개의 플로팅 버튼들

이 중에 특정 플로팅 버튼을 누를 경우 데이터 수집을 하고 싶을 경우 M열처럼 component name을 통해 Floating_action_button 이라고 지칭해주고, N열을 통해 3개의 플로팅 버튼 중 어떤 버튼인지 알려주는 것이다. (N열에서 링크라고 적혀 있는데, 링크 대신 GPS 아이콘 등 텍스트로 적어도 된다. 그냥 세개 중 어떤 버튼인지 식별 할 수 있기만 하면 된다.)

또한, 첫 번째 화면에서 소카 존 컴포넌트를 누를 때 그 주차장의 목록이 무엇인지 수집 할 수 있도록도 할 수 있다


*User properties 시트
User property: 사용자 속성이 새로 만들어주거나 갱신될때 기록하는 것
사용자 속성은 그냥 그 이벤트가 발생 햇을 때 직후에 바로 집어넣으면 끝이다.(로그인 할 때 바로 기록하면 끝)


디버깅 방법

IOS의 경우, Xcode라는 툴에서 디버그 콘솔을 이용하는 것이므로, 상대적으로 좀 복잡하고 난이도가 있다.


모바일어트리뷰션

모바일에서 광고를 보고 도착하는 장소가 웹인지, 앱인지가 중요하다!


- 링크 이동 시 광고 식별자를 url에 남겨 전달하여 매치(URL에 식별자를 남겨서 그 곳에서 유입된 사용자 라는 것을 알 수 있게 함)
- 링크 리다이렉트를 통해 식별자를 기록해두고 다음 링크로 이동한 뒤 수집한 식별자 매치
- 웹의 경우에는 광고를 본 시점과 결제 시점이 며칠 차이가 나거나, 혹은 완전히 새로 접속하게 될 경우, (앱에비하면 어렵지만) 어덯게든 광고 보고 들어왔던 식별자를 잘 저장해놨다가 추후 세션 아이디와 매치시켜 추적하면 될 수도 있다.(물론 어렵다)



- ADID/IDFA/IDFV 등의 광고 식별자 수집하여 매치
- 링크 리다이렉트를 통해 식별자를 기록해두고 다음 링크로 이동한 뒤 수집한 식별자 매치
- 안드로이드의 경우 플레이스토어 유입 시의 utm 태그를 수집/보관하여 GA/FB에 전달하여 매치
- 어트리뷰션툴이 식별자를 따로 부여해준다. 그 후 앱으로 들어갈때 그 식별자를 다시 주는 것이다. 그래서 그 식별자를 통해 아 그 광고였구나를 알 수 있게 해준다.
- 앱의 경우, 그 광고를 보고 바로 구매로 전환안되더라도, 어트리뷰션 툴에 의해 그 식별자가 남겨지게 되므로, 앱에 다시 접속해서 결제로 이어지게 될 경우에는 그 식별자를 다시 불러오기 때문에 텀이 있어도 추적이 가능하다!


데이터 실험이 필요한 이유

A/B 테스트 방식

유저가 들어왔을때 랜덤으로 발생되는 장치를 발생시켜 a가 발생되면 ‘a’광고 페이지를 보여주고 b가 발생되면 ‘b’광고 페이지를 보여주는 것이다.
파이어베이스의 경우에는 a/b테스트 시 아래와 같다.

데이터 분석에서의 R&R



Output Metric, Input Metric, Long term Metric, Short term Metric, Proxy Metric


OEC






라이브 PT 강의에 관심 있으시면 아래 링크로 접속하시면 됩니다.
https://bit.ly/3D9XCOz

*본 영상은 라이브 PT 강의를 수강 후 환급을 위한 학습 일지 챌린지 참가 및 내용 복습을 하기 위해 작성한 글입니다.

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
글 보관함