Firebase Analytics 시작하기
아무 생각 없이 편하게 시작하는 이벤트 수집
# 글의 목적
이 글은 모바일 앱의 사용자 로그를 수집하기 위해
Firebase Analytics와 Bigquery를 처음으로 사용하는 분들을 위해 작성되었습니다.
# 공식 가이드에 대해
- 공식 가이드는 매우 유용합니다.
- 다만, Firebase는 구글의 인수 이후 쉴 새 없이 수많은 기능이 추가되었고 정책 또한 변화가 있었습니다.
- 그래서인지 안타깝게도 한글로 번역된 가이드에서는 변경된 일부 정책이나 신규 기능에 대해 설명되지 않은 문서가 종종 있었습니다.
- 영문으로 된 문서를 사용하시기를 강력히 추천합니다.
# 설정과 설치
https://console.firebase.google.com위 페이지에서 시작합니다. 위 경로로 접근하기 위해서는 구글 계정이 필요합니다.
이후 가장 먼저 만들 것은 프로젝트입니다. "Firebase를 사용하는 프로젝트" 라는 단어는 살짝 애매한데,
정확히 표현하자면 "Firebase 서비스를 사용하는 Google Cloud Platform Project" 입니다.
위 페이지에서 생성하는 것은 GCP 프로젝트이므로 Firebase Project 삭제는 곧 GCP 프로젝트를 삭제하는 것과 같습니다..
# iOS & aOS
Firebase Analytics는 두 OS만 지원하는 것으로 시작되었습니다.
헌데, 웹 페이지를 위한 도구가 제공되고 있지 않습니다. (최근 C++과 Unity가 추가되었지만.. )
따라서 서비스가 웹과 앱 모두 가져가는 것이 일반적인 트렌드임을 감안할 때 데이터가 나뉘어 저장되는 불편함이 필연적으로 발생하게 됩니다.
물론 Google Analytics 360을 사용한다면 별 불편함이 없을 것이지만.. Google Analytics 360 가격이 만만치 않습니다.
그리하여 여하튼, 이 글은 모두 iOS/aOS만을 위한 글입니다.
# 수집할 정보
Firebase Analytics는 정보를 "사용자 속성"과 "이벤트" 두 가지 종류로 구분합니다.
예를 들어, "홍길동 씨가 오늘 회원가입을 했다."...라는 일이 일어났을 때 구분해보자면,
"홍길동" 은 사용자 속성에, "회원가입" 은 이벤트로 적습니다.
사용자 속성과 이벤트 모두 정보를 넣을 때에는 "key"와 "value" 쌍으로 적어 넣게 되며, "key"는 정보의 이름 혹은 종류로 "value"는 적어 넣을 실제 값을 의미힙니다.
# 이벤트
- Custom Event : 일반적으로 우리가 원하는 이벤트 입력을 얘기합니다.
- 자동 수집되는 이벤트 : 별도로 추가 설정하지 않아도 자동으로 수집되는 이벤트들입니다. 앱 제거나 업데이트, 스크린 뷰 등의 이벤트가 포함되어 있습니다. 자세한 내용은 도움말을 참고하시되.. 참고로 app_remove 이벤트는 iOS에서 수집되지 않습니다.
# 사용자 속성
- 사용자 고유의 속성을 붙일 수 있습니다. 회원 구분, 연령대 등의 각 회원 고유의 정보를 붙여주면 됩니다.
- 이벤트와 달리 지속적으로 정보가 유지되고 어느 이벤트에나 붙여 읽을 수 있습니다.
# 제한
무엇을 어떻게 가져올지를 생각해보기 이전에 현실적인 어려움들에 대해 먼저 알아볼 필요가 있습니다.
Firebase Analytics가 제공하는 기능은 쉽고 강력하지만, 그에 상응하는 한계와 제한사항이 있습니다.
## 이벤트 개수
- 전송 가능한 이벤트 개수는 "무제한"으로 안내되고 있습니다.
- 실제로 문서화되어 있지 않은 제한이 있습니다. 하나의 디바이스에서 일반적으로는 발생할 수 없는 만큼의 이벤트를 발생시키면 해당 디바이스에 한해 더 이상 이벤트가 저장되지 않는 상황이 발생합니다. 이 제한에 대해 문의해보았으나 정책에 대해 안내받지 못하였습니다. 물론 "일반적인" 상황에서는 발생하지 않습니다.
## 이벤트
- 500개까지의 이벤트 종류만 저장됩니다. 501개부터 저장되지 않습니다. 이 제한은 50개에서 늘어났기 때문에 추후 충분히 늘어날 것으로 예상되지만 상태를 이벤트 이름으로 담아 보내는 등의 설계는 포기하는 것이 좋겠습니다.
- 대소문자를 구분합니다... "page_view"와 "PAGE_VIEW"는 다른 이벤트로 취급됩니다.
- 알파벳으로 시작해야 하는 제한이 있습니다. "firebase_", "google_", "ga_"로 시작하는 이벤트 이름도 사용할 수 없습니다.
## 이벤트 파라미터
- 하나의 이벤트에 25개 파라미터를 붙여보넬 수 있습니다.
- 파라미터의 키와 값 각각 40글자, 100글자 제한이 있습니다.
## 사용자 속성 개수
- 50개의 사용자 속성을 사용할 수 있습니다.
- 이벤트에 비해 충분하지 않은 숫자입니다. 굉장히 잘 설계되어야 할 필요가 있습니다.
## 이벤트가 누락되는 경우
- 네트워크 장애와 관련해서는 일정 기간을 두고 재시도하는 등으로 안정적인 기록 보관을 위한 별도 장치가 마련되어 있습니다.
- aOS의 경우 앱이 삭제된 이후에도 Play Store 앱을 통해 전달됩니다.
- iOS의 경우 앱이 오류로 종류 된 이후에 재시작 없이 앱이 삭제되면 누락됩니다.
# 개발
- 상세한 내용은 iOS와 aOS 각각 문서를 참고하세요.
### 이벤트 입력
- 위의 예시에서 보듯 저장할 값의 type을 지정하지 않습니다.
- 입력 값의 type은 최종적으로 string, int, float, double 중 하나의 타입으로 저장됩니다.
- 입력 값의 형태에 따라 dynamically... 지정됩니다. 테이블 전체에 걸쳐 일관되게 type을 유지해 주지 않기 때문에 앱에서 주의하여 type을 유지하지 않을 경우... ifnull(ifnull(ifnull... 하는 지옥 같은 경우가 생깁니다.
### 디버그
- 입력한 이벤트는 즉시 Android Studio 혹은 Xcode의 디버그 창에 노출됩니다.
- 실제로 Firebase에 이벤트가 전달된 것을 확인하기 위해서는 Debug View를 사용합니다. Stream View와 달리 특정 디바이스의 시간순 이벤트와 입력된 파라미터를 한 번에 확인할 수 있어 용이합니다.
- 디버그 뷰는 개발할 때 외에도 사용할 수 있기 때문에 개발자가 아닌 기획자, 분석가 입장에서도 현황을 파악하는 데에 매우 유용합니다.
# 대시보드
서비스 초기에서 많은 변화가 있던 영역이 이 대시보드입니다.
사실 서비스 시작 시에는 입력한 파라미터의 조회도 일부 이벤트에 제한되는 등,
대시보드에서 볼 수 있던 정보가 거의 없었으므로 Bigquery export가 필수적이었습니다.
최근 많은 발전이 있었으나 아직 Bigquery + BI Tool (Data Studio, Tableau 등)을 대체하기에는 부족합니다.
## 잠재고객
- 사용자 속성 또는 이벤트 발생 기록을 조건으로 사용자를 분류할 수 있습니다.
- 잠재고객은 Growth 기능들과 다양한 방식으로 연계가 가능하며 활용 가치가 높습니다.
## Funnels
- 이벤트를 순서대로 나열해 설정하면 각 이벤트 사이의 전환율을 보기 좋게 정리해줍니다.
- 이벤트 이름만으로 단계 설정이 가능하기 때문에 범용적인 이름을 가진 이벤트의 경우 사용하기 애매한 단점이 있습니다.
# 데이터
- 2018년 6월부터 bigquery export에 큰 변화가 있었습니다. 2개월이 지난 현재까지도 한글 문서는 업데이트되어 있지 않으므로, 꼭 영문 안내 문서를 보셔야 합니다.
## 설정
- Bigquery 연동을 위해서는 Firebase 요금제 변경이 필요합니다. Blaze (종량제)로 요금제를 변경해주세요.
- 이후 설정 페이지 > 통합 > Bigquery > 관리 메뉴를 통해 Bigquery와 연동할 수 있습니다.
## 저장 장소
- GCP 프로젝트에 Firebase App 들을 위한 하나의 데이터 셋이 생성됩니다.
- "analytics_" 뒤의 숫자는 Firebase 속성 아이디입니다.
- 테이블 생성은 이벤트 발생 이후에 진행됩니다. 이벤트 발송 이후로부터 몇 시간 정도를 기다려야 합니다.
## 데이터 세트와 테이블 생성 규칙
- Firebase로부터 이벤트를 전달받으면 매일마다 하나씩 테이블을 생성해 추가합니다.
- 생성된 테이블은 "events_" preffix와 "yyyymmdd" 형식의 날짜를 붙여 이름 짓습니다.
- 빅쿼리의 특성상 "yyyymmdd" suffix를 붙인 테이블은 하나의 테이블처럼 묶어 보여주므로 날마다 만든다고 테이블 리스트가 길어지진 않습니다.
- 주의해야 할 것은 intraday, 오늘의 데이터입니다. 이 테이블은 streaming insert로 데이터가 삽입되며 하루간만 유지되다 삭제됩니다. 다음날은 다음날의 날짜를 붙인 새로운 intraday가 생성됩니다.
- 신규 intraday 테이블이 생성되면 어제자 intraday를 "events_yyyymmdd"로 이름 지어 사본으로 저장하고서 삭제하게 되는데, 이 과정에서 intraday 테이블이 두 개일 경우가 생깁니다.
- 가끔 intraday 테이블이 삭제되지 않는.. 경우도 있습니다... 만 흔치 않습니다.
## 스키마
- BigQuery Export 스키마 문서를 참고해주세요.
- 크게 5개 컬럼 - [앱 정보, 사용자 속성, 이벤트, 유입 경로, 위치] 정보로 구분되어 저장됩니다.
# Analytics와 연계해 꼭 써야 할 기능
## Remote Config
- 앱에 원격으로 "기본 설정값"을 심어줄 수 있습니다. Key와 Value 쌍으로 적절한 이름과 값을 입력해 넣을 수 있으며 앱 시동 시 값을 호출해 사용하는 방식입니다.
- 값을 호출한 이후부터는 계속 서버에서 값을 받아오지 않고 cache로 보관해 사용하게 됩니다. cache는 12간 이후 만료되지만 fetch time을 지정해 이 시간을 변경할 수 있습니다. (코드 레벨의 설정입니다.)
- Analytics를 위해 넣어두었던 사용자 속성과 이벤트를 조건으로 설정값의 분기를 태울 수 있습니다.
- 혹은 임의의 비율을 지정해 A 혹은 B를 설정해 넣을 수 있습니다.
- 물론 지정해 넣은 값에 따라 뷰를 구성하거나 로직을 구현하는 것은 우리의 몫입니다.
## ML Kit
- Vision API를 사용하고 있었다면? 비용을 0으로 만들 수 있습니다.
# 고민해볼 점들
## 페이지뷰에 대해서
- 이제까지 컴포넌트의 transition 혹은 transform을 페이지뷰로 볼 생각은 하지 않았겠지만.
- 한 개 버튼으로 화면에 배치되었던 컴포넌트가 화면을 덮는 크기로 변하면 그건 페이지뷰일까요 버튼 클릭일까요 "transform"으로 기록해야 할까요?
- 최선이 무엇인지에 대해서는 많은 고민이 필요하겠지만 확실한 것은 이전의 페이지뷰 단위 이동의 UX에서 Context 이동으로의 UX 변화가 기록 방식에도 같은 변화와 고민을 주고 있다는 것입니다.
## 제한들
- 25개를 넘는 파라미터를 가지는 이벤트를 생각해내기는 생각보다 쉽습니다.
- 100글자를 넘는 정보가 충분하지 않은 경우도 의외로 많습니다.
## 실험에 대해서
- 버튼의 색으로 A/B 테스트를 진행한다고 할 때 실험 번호 "A" 혹은 "B"를 이벤트에 넣어야 할까요, 사용자 속성에 넣어야 할까요?
- 버튼 클릭 이벤트에 실험 번호를 넣을 경우 버튼의 색이 이후 사용자 행동에 어떤 영향을 주었는지 알기 힘듭니다. 어떤 실험 번호였는지를 조회하기 위해 모든 이벤트를 뒤져 사용자 단위로 파티셔닝해 사용자와 매치하는 과정이 필요합니다. 이 과정에서 불필요한 bigquery 조회 과금도 발생할 것입니다.
- 사용자 속성에 실험 번호를 넣는 경우 50개 자리 중 하나를 사용해야 하지만 동시에 진행되는 실험이 다수가 될 경우를 생각해보면 실험의 개수를 제한하거나 사용자 속성 정보를 복잡하게 기록하고 복잡하게 파싱 해 사용하는 어려운 과정을 거쳐야 합니다.
# 마치며
- GCM이 FCM으로 옮겨오면서 Firebase는 앱 개발에 가장 필수적인 요소 중의 하나가 되었습니다. 따라서 Analytics 나 다른 기능을 전혀 사용하지 않는다 해도 강제적으로 설치되어야 하는 SDK 중의 하나입니다.
- 온갖 기능이 다 붙어 있어 혼란스럽지만 하나하나가 굉장히 유용하고 쉽고 싸게 쓸 수 있기 때문에 활용하기에 따라 큰 성과를 볼 수 있습니다.
- 무엇보다 가장 큰 장점은 Bigquery와의 연계에 있습니다. 굉장히 편리하고 유용하게 사용할 수 있습니다. 꼭 쓰세요. 두 번 쓰세요.
