설치 이벤트만으로는 광고 효율을 판단할 수 없다

MMP가 잡아내는 첫 신호는 앱 설치입니다. 하지만 설치는 광고비 투자의 결과물 중 가장 초기 단계일 뿐, 그 사용자가 실제로 서비스를 계속 쓰고 결제까지 이어졌는지는 설치 데이터만으로 알 수 없습니다. 설치당 비용(CPI)이 낮은 캠페인이 반드시 좋은 캠페인은 아닌 이유가 여기 있습니다. 설치는 쌌지만 그 사용자들이 가입도, 결제도 하지 않는다면 결국 광고비 대비 매출(ROAS)은 오히려 나쁠 수 있습니다.

이 문제를 풀기 위해 MMP는 설치 이후 사용자의 행동을 추적하는 인앱 이벤트(In-App Events) 기능을 제공합니다. 인앱 이벤트는 사용자가 앱 안에서 특정 행동(회원가입 완료, 장바구니 담기, 결제 완료 등)을 할 때마다 그 사실을 MMP 서버로 실시간 전송하는 로그입니다.

표준 이벤트명은 왜 임의로 짓지 않고 정해진 것을 쓰는가

AppsFlyer SDK는 af_app_open(앱 실행), af_complete_registration(회원가입 완료), af_purchase(구매) 같은 사전 정의된 표준 이벤트 이름을 제공합니다. 개발자가 이 이벤트가 발생하는 화면·시점에 맞춰 표준 이벤트명으로 SDK 코드를 심으면, 그 데이터가 MMP 대시보드뿐 아니라 연동된 광고 매체(메타, 구글 등)로도 전달됩니다.

표준 이벤트명을 쓰는 것이 중요한 이유는, 매체의 자동 입찰·최적화 알고리즘이 이 표준 이벤트를 인식해 "구매 확률이 높은 사용자"에게 광고를 더 많이 보여주는 식으로 캠페인 자체를 최적화하는 데 활용하기 때문입니다. 개발자가 임의로 이벤트명을 지어(예: af_purchase 대신 "buy_done") SDK를 심으면, 매체 쪽에서 이 이벤트를 표준 구매 신호로 인식하지 못해 최적화 알고리즘의 학습 대상에서 빠지는 문제가 생길 수 있습니다. 정확한 이벤트명·파라미터 스펙은 SDK 버전에 따라 갱신되므로, 실제 연동 전에는 AppsFlyer 개발자 문서(dev.appsflyer.com)의 최신 SDK 레퍼런스를 반드시 재확인해야 합니다(구체적인 세부 파라미터 스펙 변경 이력은 이번 조사에서 확인하지 못한 부분이 있어, 실제 세팅 시점의 최신 문서 대조가 필요합니다).

이벤트에는 어떤 부가 정보를 함께 실어야 하나

이벤트 이름 자체만 전송해서는 분석에 한계가 있습니다. af_purchase 이벤트라면 결제 금액, 통화, 상품 ID, 수량 같은 부가 파라미터를 함께 실어 보내야, "이번 달 매체별 총 매출"이나 "상품 카테고리별 구매 전환율" 같은 실질적인 분석이 가능해집니다. af_complete_registration 이벤트에도 가입 경로(이메일, 소셜 로그인 등)를 파라미터로 함께 담아두면, 어떤 가입 방식이 이후 결제로 더 잘 이어지는지까지 확인할 수 있습니다.

이 부가 파라미터를 어떻게 설계할지는 마케팅 목표에 따라 달라지므로, 마케터가 "이 이벤트에서 어떤 데이터를 함께 보고 싶은지"를 먼저 정리해 개발팀에 전달하는 과정이 필요합니다. 개발이 끝난 뒤에 파라미터를 추가하려면 다시 코드를 수정하고 배포해야 하므로, 처음 설계 단계에서 필요한 파라미터를 최대한 빠짐없이 정의해두는 편이 이후 재작업을 줄이는 길입니다.

앱 실행(af_app_open) 이벤트는 왜 따로 관리하나

af_app_open은 설치 이후 사용자가 앱을 다시 열 때마다 발생하는 이벤트로, 리텐션(재방문율) 분석의 기초 데이터가 됩니다. 설치 후 하루가 지나서도 이 이벤트가 발생하지 않는 사용자는 사실상 앱을 쓰지 않고 있다고 볼 수 있어, 이 이벤트의 발생 빈도가 11강에서 다룰 코호트·리텐션 분석의 핵심 지표로 쓰입니다.

이벤트 매핑 명세서는 어떻게 작성해야 하나

실무에서 인앱 이벤트 세팅은 마케터가 원하는 이벤트 목록과 각 이벤트에 필요한 파라미터를 표로 정리한 "이벤트 매핑 명세서"를 만들어 개발팀에 전달하는 방식으로 진행하는 경우가 많습니다. 명세서에는 이벤트명(표준 이벤트명 우선 사용), 발생 시점(어느 화면, 어느 버튼 클릭 시), 필수 파라미터와 그 값의 형식(숫자, 문자열 등)을 구체적으로 적어야 개발팀이 모호함 없이 구현할 수 있습니다.

이벤트를 다 심었다고 끝이 아니라, 배포 전 QA 단계에서 실제 기기로 각 행동을 재현해 MMP 대시보드의 실시간 이벤트 로그(디버그 모드)에 정확히 찍히는지 확인하는 절차가 반드시 필요합니다. 이 검증을 생략하면 캠페인이 이미 집행되는 시점에서야 이벤트가 누락된 사실을 발견하게 되어, 그 기간의 데이터는 되돌릴 수 없이 손실됩니다.