앱 마케팅 MMP 이벤트 택소노미 설계 5단계
- 이벤트명은 사용자 행동, 파라미터는 행동의 맥락을 담습니다.
- MMP·분석·CRM 도구가 공유할 공통 데이터 계약을 정의합니다.
- 성공 시점·중복·누락을 테스트한 뒤 광고 최적화에 활용합니다.
앱 마케팅용 MMP 인앱 이벤트 택소노미는 측정할 사용자 행동, 이벤트 발화 시점, 함께 보낼 파라미터를 팀이 같은 규칙으로 정의한 설계서입니다. 먼저 가입·장바구니·결제처럼 판단에 필요한 행동을 고르고, 이름과 조건을 정한 뒤, 앱 코드에 구현하고 테스트하세요. 이름만 정해 전달하면 이벤트가 중복되거나 결제 전 단계에서 구매 이벤트가 잡히는 문제가 생길 수 있습니다.
이벤트 택소노미가 필요한 이유
퍼널의 어디서 이탈하는지 찾습니다
설치 수와 최종 구매 수만 보면 결과는 알 수 있어도 원인을 찾기 어렵습니다. 상품 조회, 가입 완료, 결제 시작, 구매 완료를 각기 정의하면 어느 단계에서 이탈하는지 분석할 수 있습니다. 예를 들어 가입 후 결제 시작이 적다면 광고 유입보다 가입 절차나 상품 탐색 경험을 점검할 근거가 생깁니다.
여러 도구가 같은 행동을 읽게 합니다
MMP(모바일 측정 파트너)는 앱 설치와 광고 기여를 측정하는 도구입니다. 분석 도구와 CRM(고객관계관리) 도구까지 함께 쓸 때는 같은 행동의 의미와 발화 조건이 일치해야 합니다. 솔루션마다 이름 형식이나 전송 방식은 다를 수 있으므로, 공통 이벤트 정의와 각 도구의 매핑을 별도로 관리하세요. AppsFlyer의 SDK 연동 개요도 측정할 인앱 이벤트의 이름과 파라미터를 정해 개발자에게 전달하도록 안내합니다.
설계 전에 합의할 기본 원칙
행동·맥락·사용자 상태를 분리합니다
이벤트명은 사용자가 무엇을 했는지 나타내고, 파라미터는 그 행동의 대상이나 조건을 설명합니다. 사용자 속성은 회원 등급처럼 행동과 별개인 현재 상태입니다. 예를 들어 화면을 봤다면 화면 이름을 이벤트명에 붙여 새 이벤트를 만들기보다, 화면 조회 이벤트에 screen_name을 전달하는 방식이 분석과 유지보수에 유리합니다.
- 이벤트: purchase, sign_up처럼 측정할 행동
- 파라미터: item_id, payment_method, value처럼 행동의 맥락
- 사용자 속성: membership_tier처럼 사용자 상태
네이밍 규칙은 짧고 일관되게 정합니다
소문자와 snake_case 등 한 가지 표기법을 정하고, 동사와 대상의 순서도 통일하세요. 캠페인명, 화면명, 날짜처럼 자주 바뀌는 값을 이벤트 이름에 넣으면 비슷한 행동이 여러 이벤트로 갈라집니다. GA4에 보낼 이벤트는 GA4 추천 이벤트에 해당하는 이름과 지정된 파라미터가 있는지 먼저 확인하세요. 추천 이벤트와 파라미터는 GA4 보고서와 기능에 연결될 수 있습니다.
기억할 기준: 이벤트명은 행동, 파라미터는 행동의 맥락입니다. 이름을 바꾸기 전에 발화 조건과 기존 데이터·매핑의 영향을 함께 확인하세요.
MMP 인앱 이벤트 택소노미 설계 5단계
1단계: 측정할 질문과 핵심 전환을 고릅니다
“광고 유입 사용자가 어디서 구매를 멈추는가?”처럼 답을 얻고 싶은 질문부터 정하세요. 그 질문에 직접 답하는 핵심 전환과, 전환 전 과정을 설명할 보조 행동을 구분합니다. 앱의 모든 화면을 이벤트로 만들 필요는 없습니다.
2단계: 행동과 발화 시점을 문장으로 정의합니다
이벤트마다 “사용자가 무엇을 하면, 어느 시점에, 몇 번 전송되는가”를 적습니다. 가입 완료는 가입 화면을 열거나 버튼을 누른 시점이 아니라 가입 성공 응답이 확인된 시점으로 정의하는 식입니다. 실패·취소·재시도는 별도 분석이 필요할 때만 이벤트나 상태값으로 추가하세요.
3단계: 이벤트명과 필수 파라미터를 정합니다
아래 표는 GA4 전자상거래 추천 이벤트를 참고한 설계 예시입니다. 이벤트명은 모든 MMP에서 그대로 써야 하는 공통 규칙이 아니므로, 사용할 MMP와 분석 도구의 이벤트 구조·매핑 요구사항을 확인하세요. 실제 필드는 앱의 구매 흐름과 각 플랫폼의 요구사항에 맞게 조정하고, 값의 형식·필수 여부·허용값을 문서에 기록하세요.
| 행동 | 이벤트 예시 | 파라미터 예시 | 발화 기준 |
|---|---|---|---|
| 상품 조회 | view_item | item_id, item_category | 상품 상세가 정상 표시됨 |
| 장바구니 추가 | add_to_cart | item_id, quantity | 추가 성공이 확인됨 |
| 결제 시작 | begin_checkout | value, currency | 결제 단계 진입이 확인됨 |
| 구매 완료 | purchase | transaction_id, value, currency | 결제 성공이 확인됨 |
4단계: MMP·분석·광고 도구의 매핑표를 만듭니다
팀 공통 행동 정의, 앱에서 전송할 이벤트, 각 도구의 이벤트명, 광고 파트너로 보낼 전환 여부를 한 표에서 관리하세요. GA4와 MMP가 사전 정의 이름을 다르게 쓰는 경우에도 원래 행동의 뜻과 발화 조건은 같아야 합니다. 매핑이 없는 커스텀 이벤트는 어떤 보고서와 캠페인에 쓰이는지 담당자를 지정해 두세요.
5단계: QA 후 운영 기준을 문서화합니다
개발·마케팅 담당자가 테스트 기기에서 성공·실패·취소 흐름을 확인하고, 대시보드나 원시 데이터에서 이벤트명과 파라미터를 대조합니다. GA4에서는 실시간 및 DebugView 보고서로 이벤트와 매개변수를 확인할 수 있습니다. 이벤트 정의서에는 담당자, 버전, 변경 일자, 테스트 결과와 변경 영향을 남기세요.
- 성공 한 번에 이벤트가 한 번만 기록되는지 확인합니다.
- 필수 파라미터가 빠지거나 문자열·숫자 형식이 뒤섞이지 않는지 확인합니다.
- 테스트 이벤트가 MMP와 연결된 분석·광고 도구에 의도한 대로 도착하는지 확인합니다.
운영 전후에 자주 놓치는 점
결제 성공과 구매 이벤트를 구분합니다
결제 버튼 클릭을 구매로 집계하면 실패한 결제까지 매출 전환처럼 보일 수 있습니다. 구매 이벤트는 실제 성공 기준을 서버나 결제 결과와 맞춰 정의하세요. 결제 재시도나 앱 재실행으로 중복 전송되지 않도록 transaction_id 같은 거래 식별값의 생성·전달 기준도 확인해야 합니다.
수익 데이터와 개인정보를 점검합니다
매출을 보내는 이벤트는 금액의 기준이 결제 총액인지 할인 후 금액인지 팀에서 합의하세요. 통화와 금액 단위도 일관되게 전송해야 합니다. 이벤트 설계에서는 이름, 이메일, 전화번호처럼 개인을 직접 식별할 수 있는 값을 불필요하게 포함하지 말고 목적에 필요한 최소한의 개인정보만 수집하도록 검토하세요. 이는 개인정보 보호법 제16조의 최소 수집 원칙과도 연결됩니다.
- 이벤트 수가 갑자기 늘면 앱 버전별 중복·재전송 여부를 비교합니다.
- 값이 비어 있으면 앱 화면의 값이 아니라 전송 직전 데이터 생성 과정을 확인합니다.
- 이벤트 정의를 변경하면 기존 대시보드·오디언스·광고 최적화 설정에 미치는 영향을 기록합니다.
광고 최적화 전 확인: 핵심 전환 이벤트가 실제 성공 행동에서 발생하고, 테스트 데이터가 운영 리포트와 구분되는지 먼저 검증하세요.
자주 묻는 질문
Q. 이벤트 설계는 마케터와 개발자 중 누가 하나요?
마케팅 목표와 필요한 분석 기준은 마케터가 제안하고, PM·개발자는 앱 동작과 데이터 생성 시점을 검토해 함께 확정하는 방식이 실용적입니다. 설계와 구현을 분리하지 말고 발화 조건까지 공동으로 합의하세요.
Q. MMP와 GA4에서 이벤트명을 똑같이 써야 하나요?
도구별 권장 이름이나 매핑 규칙이 다를 수 있어 이름을 무조건 같게 만들 필요는 없습니다. 다만 이벤트가 뜻하는 행동, 성공 조건, 파라미터 정의는 공통 문서에서 일치시켜야 합니다.
Q. 이벤트를 많이 만들수록 분석이 정확해지나요?
그렇지 않습니다. 중복되거나 사용하지 않는 이벤트가 많으면 구현과 검수가 어려워집니다. 광고 예산·제품 경험·CRM 의사결정에 실제로 쓰일 행동부터 시작하고, 분석 질문이 생길 때 필요한 이벤트를 추가하세요.
Q. 이벤트를 출시한 뒤 이름이나 기준을 바꿔도 되나요?
가능하지만 과거 데이터와 이어서 비교하기 어려워질 수 있습니다. 변경 사유와 적용 앱 버전, 기존 이벤트와의 관계를 기록하고, 보고서·매핑·캠페인 설정까지 함께 점검하세요.
