앱 데이터 분석은 출시 전에 이벤트 설계표를 만들어 두는 것에서 시작합니다. 무엇을 알고 싶은지 질문을 먼저 정하고, 그 질문에 답하는 데 필요한 이벤트와 매개변수만 골라 이름 규칙에 맞춰 심는 순서입니다. 이벤트에는 이메일이나 전화번호 같은 개인정보를 넣지 않고, 출시 전에 디버그 화면으로 실제 기록을 확인한 뒤 스토어의 개인정보 신고 내용과 맞춥니다. 아래는 Firebase용 Google Analytics(이하 Firebase Analytics)를 기준으로 저희가 출시 전에 챙기는 순서입니다.

출시 후에 붙이면 왜 늦을까요

분석 이벤트는 앱에 코드로 심는 것이라, 빠뜨린 이벤트를 추가하려면 앱 업데이트를 내야 합니다. 업데이트가 사용자에게 퍼질 때까지 몇 주가 걸리고, 그 사이 데이터는 비어 있습니다. 출시 첫 달은 광고를 몰아서 집행하는 경우가 많고 사용자 반응이 가장 궁금한 시기인데, 정작 그때의 가입 이탈 지점을 볼 수 없는 일이 생깁니다.

출시 후 몇 달 지나서 "가입은 많은데 결제가 왜 적은지" 물어보시는 경우가 많습니다. 이벤트를 열어 보면 회원가입 완료와 결제 완료만 있고 그 사이 단계가 없어서 답을 할 수 없습니다. 출시 전 QA 항목은 앱 출시 전 QA 글에서 다뤘는데, 분석 설정도 그 목록에 함께 넣어 두시길 권합니다.

무엇을 볼지 질문부터 정합니다

이벤트 설계를 화면 목록부터 시작하면 버튼마다 이벤트를 다는 쪽으로 흘러갑니다. 그렇게 쌓인 데이터는 양만 많고 쓸모가 적습니다. 저희는 먼저 출시 후 3개월 안에 답을 얻고 싶은 질문을 서너 개 적어 달라고 요청합니다.

이벤트 설계 순서

1. 질문 적기출시 후 3개월 안에 알고 싶은 것
2. 이벤트 뽑기질문에 답하는 데 필요한 행동만
3. 매개변수 붙이기세부 정보는 이름 대신 매개변수로
4. 이름 통일소문자와 밑줄, 동사와 대상
5. 설계표 정리기획자와 개발자가 같이 보는 표

예를 들면 이런 질문들입니다. 설치한 사람 중 회원가입을 끝내는 비율은 얼마인가, 가입 과정 중 어느 단계에서 가장 많이 나가는가, 첫 결제까지 며칠이 걸리는가, 검색을 쓰는 사람과 안 쓰는 사람의 재방문 차이는 있는가. 질문이 정해지면 필요한 이벤트가 거꾸로 나옵니다. 가입 단계별 이탈을 보려면 단계마다 이벤트가 있어야 하고, 검색 사용 여부를 보려면 검색 이벤트가 있어야 합니다.

이벤트와 매개변수는 어떻게 나누나요

이벤트는 사용자가 한 행동 하나, 매개변수(parameter)는 그 행동에 붙는 세부 정보입니다. 상품을 장바구니에 담았다면 이벤트는 장바구니 담기, 매개변수는 상품 분류와 가격이 됩니다.

흔한 실수는 세부 정보를 이벤트 이름에 넣는 것입니다. 카테고리마다 click_category_food, click_category_fashion처럼 이벤트를 따로 만들면 카테고리가 늘 때마다 이벤트 종류가 늘어납니다. select_category 하나에 category_name 매개변수를 붙이는 편이 보기도 쉽고 한도에도 걸리지 않습니다.

Firebase의 이벤트 기록 문서는 로그인, 회원가입, 구매, 검색처럼 많이 쓰는 행동에 대해 이름과 매개변수가 정해진 추천 이벤트를 먼저 쓰라고 권합니다. login, sign_up, purchase, search 같은 것들입니다. 추천 이벤트를 쓰면 보고서에서 더 자세한 정보를 볼 수 있으니, 추천 이벤트로 표현할 수 없는 것만 직접 만든 이벤트로 기록합니다. 직접 만든 매개변수는 Firebase 콘솔에서 맞춤 정의로 등록해야 보고서에 나타난다는 점도 잊기 쉽습니다.

이름 규칙과 Firebase 수집 한도

이벤트 이름은 대소문자를 구분합니다. Firebase 문서에도 대소문자만 다른 두 이벤트는 서로 다른 이벤트로 기록된다고 적혀 있습니다. iOS 개발자는 signUpComplete, 안드로이드 개발자는 sign_up_complete로 심으면 같은 행동이 둘로 쪼개집니다. 저희는 영문 소문자와 밑줄만 쓰고, 동사와 대상을 합친 형태(예: view_item, start_checkout)로 통일합니다. 화면 이름이나 버튼 위치처럼 나중에 바뀔 수 있는 말은 이벤트 이름에 넣지 않습니다.

수치 한도는 Google Analytics 이벤트 수집 한도 안내에 정리되어 있습니다. 앱 데이터 기준으로 주요 항목은 이렇습니다.

500개면 넉넉해 보이지만, 위에서 말한 것처럼 세부 정보를 이벤트 이름에 넣기 시작하면 금방 찹니다. 매개변수 값 100자 제한 때문에 검색어나 긴 문구가 잘려 기록되는 일도 있습니다.

사용자 속성과 전환 이벤트 정하기

사용자 속성(user property)은 사람에게 붙는 정보입니다. 이벤트가 "무엇을 했는가"라면 사용자 속성은 "어떤 사람인가"입니다. 회원 등급, 구독 여부, 선호 언어처럼 자주 바뀌지 않는 값을 넣고, 이 값으로 사용자를 나눠 비교합니다. 개수 한도가 25개이고 값은 36자까지라 정말 나눠 볼 기준만 고릅니다.

이벤트와 사용자 속성

이벤트

• 사용자가 한 행동
• 예: 장바구니 담기
• 세부 정보는 매개변수로

사용자 속성

• 어떤 사람인지
• 예: 회원 등급, 구독 여부
• 25개, 값은 36자까지

주요 이벤트

• 사업상 가장 중요한 행동
• 예: 가입 완료, 첫 구매
• 서너 개면 충분

전환 이벤트는 사업적으로 가장 중요한 행동입니다. Google Analytics에서는 이런 이벤트를 주요 이벤트(key event)로 표시해 따로 집계하고 광고 성과를 잴 때 기준으로 씁니다. 회원가입 완료, 첫 구매, 예약 완료처럼 서너 개면 충분합니다. 무엇이든 주요 이벤트로 표시하면 정작 중요한 숫자가 묻힙니다.

여기까지 정한 내용은 이벤트 설계표 한 장으로 정리합니다. 저희는 이벤트 이름, 발생 시점, 매개변수와 예시 값, 플랫폼(iOS, Android, 웹), 주요 이벤트 여부, 답하려는 질문을 열로 두고 기획자와 개발자가 같이 봅니다. 나중에 이벤트를 추가하거나 고칠 때도 이 표부터 바꿉니다.

이벤트에 개인정보를 넣지 않는 법과 동의 처리

Google Analytics의 개인 식별 정보 정책 안내는 Google이 개인을 알아볼 수 있는 정보를 보내지 말라고 분명히 적고 있습니다. 예로 이메일 주소, 휴대폰 번호 등을 들고, URL과 화면 제목에 개인정보가 섞여 들어가는 경우가 많다고 경고합니다. 회원 식별이 필요하면 이메일 대신 서버에서 만든 의미 없는 회원 번호를 씁니다. 웹뷰 앱이라면 주소 뒤에 붙은 이메일이나 이름이 화면 조회 기록에 그대로 들어가지 않는지 확인합니다. 자유 입력 칸의 내용을 매개변수로 보내는 것도 피합니다. 사용자가 무엇을 적을지 모르기 때문입니다.

동의는 iOS와 국내 법 기준을 따로 봐야 합니다. 애플의 App Tracking Transparency 문서에 따르면 다른 회사의 앱이나 웹사이트에 걸쳐 사용자를 추적하기 위해 데이터를 공유한다면 이 프레임워크로 허락을 받아야 합니다. 앱 안의 행동 분석만 하고 광고 추적에 쓰지 않는다면 대상이 아닐 수 있지만, 광고 SDK나 광고 계정 연동이 들어가면 달라지니 앱에 들어간 SDK 목록과 함께 판단합니다. Firebase는 iOS에서 광고 식별자(IDFA)를 가져오지 않는 구성도 문서로 안내하고 있습니다.

국내 개인정보 처리 동의, 유럽 사용자 대상의 동의 관리는 앱 성격마다 달라서 법무 검토와 함께 정합니다. 기술적으로는 동의를 받기 전에는 수집을 꺼 두었다가 동의 후에 켜는 설정이 가능하니, 동의 화면과 분석 시작 시점을 설계표에 같이 적어 둡니다.

출시 전 DebugView로 확인하고 스토어 신고와 맞추기

평소 Firebase Analytics는 이벤트를 모아 두었다가 한 번에 보내기 때문에 콘솔에 바로 나오지 않습니다. Firebase DebugView 문서에 따르면 디버그 모드를 켜면 지연을 최소로 해서 보내고, DebugView 화면에서 기기를 골라 최근 이벤트와 매개변수, 사용자 속성을 거의 실시간으로 볼 수 있습니다. 안드로이드는 adb shell setprop debug.firebase.analytics.app 패키지명 명령으로, iOS는 Xcode 실행 설정에 -FIRDebugEnabled를 넣어 켭니다. 안드로이드는 끄는 명령을 실행하기 전까지 켜진 상태가 유지됩니다.

출시 전 분석 설정 점검

• 디버그 모드로 실제 기록 확인
• 이벤트 이름 철자와 대소문자
• 매개변수 값이 비어 있지 않은지
• iOS와 안드로이드 이름 일치
• 개발자 트래픽 필터 설정
• 스토어 개인정보 신고 반영

확인은 설계표를 옆에 두고 한 줄씩 합니다. 이벤트 이름 철자, 매개변수 값이 비어 있지 않은지, iOS와 안드로이드에서 같은 이름으로 들어오는지, 결제 금액이 숫자로 들어오는지를 봅니다. 문서에 따르면 디버그 이벤트도 BigQuery 내보내기에 기본으로 포함되니, 개발자 트래픽을 걸러 내는 필터를 설정해 두는 편이 좋습니다.

마지막으로 스토어 신고와 맞춥니다. 애플의 App Privacy 안내는 분석 도구와 SDK 같은 외부 파트너가 수집하는 데이터까지 신고하라고 하고, 구글 플레이의 Data safety도 SDK가 기기 밖으로 보내는 데이터를 포함하라고 합니다. 분석을 넣으면 보통 앱 이용 기록(제품 상호작용, 앱 상호작용)과 기기 식별자 항목이 해당됩니다. 회원 번호를 사용자 ID로 연결했다면 사용자와 연결된 데이터로 신고해야 합니다. 설계표를 만들어 두면 이 항목을 고르는 데도 그대로 쓸 수 있습니다. AI 도구로 만든 앱이라면 AI로 만든 앱의 출시 전 점검 글도 함께 보시면 좋습니다.

자주 묻는 질문

이벤트는 몇 개 정도로 시작하는 게 좋나요?

정해진 숫자는 없습니다. 앞에서 정한 질문 하나에 이벤트 몇 개가 붙는다고 보고, 질문에 답하는 데 필요한 것만으로 시작하는 편이 낫습니다. 쓰지 않는 이벤트가 쌓이면 오히려 보고서를 읽기 어려워집니다.

이미 출시한 앱인데 이벤트가 엉망이면 어떻게 하나요?

지금 들어오는 이벤트 목록을 뽑아 설계표로 옮기고, 이름이 중복되거나 쓰지 않는 것을 표시하는 것부터 합니다. 새 이름으로 바꾸면 이전 데이터와 이어지지 않으니, 바꾸는 날짜를 기록해 두고 한 번의 업데이트에 몰아서 정리합니다.

웹뷰 앱도 Firebase Analytics를 쓸 수 있나요?

쓸 수 있습니다. 웹 쪽에서 일어나는 행동을 네이티브로 넘겨 기록하거나 웹용 Google Analytics를 따로 두는 방법이 있습니다. 어느 쪽이든 같은 행동이 두 번 기록되지 않게 기록 위치를 한 곳으로 정해야 합니다.

분석 도구를 Firebase 말고 다른 것으로 써도 되나요?

됩니다. 다른 분석 도구를 써도 질문 정하기, 설계표, 개인정보 제외, 출시 전 확인이라는 순서는 같습니다. 도구마다 이름 길이나 개수 한도가 다르니 해당 도구의 공식 문서로 확인하면 됩니다.

출시를 앞두고 어떤 이벤트를 심어야 할지 정리가 안 되셨다면 앱 화면 구성과 알고 싶은 질문을 적어 상담으로 보내 주세요. 저희가 앱 개발부터 출시 후 유지보수까지 맡는 방식은 서비스 소개 페이지에서 보실 수 있습니다.