들어가며
iOS 14.5 이후 모바일 광고 측정은 완전히 다른 세계가 됐습니다. IDFA를 못 보는 환경에서 Meta·Google·TikTok이 보고하는 iOS 전환 수치는 모두 추정·집계·지연된 데이터로, 안드로이드 시절의 즉시·정확·유저 단위 데이터와는 다른 문법을 가집니다. 이 글은 마케터가 iOS 캠페인을 운영하면서 매일 보는 세 약자 — ATT, SKAdNetwork(SKAN), AEM(Aggregated Event Measurement) — 가 실제로 어떤 데이터를 만들고, 그 한계가 의사결정에 어떻게 영향을 주는지 정리합니다.
ATT 동의에서 SKAN postback까지 — 데이터가 흐르는 길이 짧지 않다
왜 이게 문제가 됐나 — IDFA 이전과 이후
IDFA(Identifier for Advertisers)는 애플이 광고용으로 제공하던 디바이스별 고유 ID입니다. 안드로이드의 GAID와 같은 역할로, 광고를 본 디바이스와 앱을 설치·구매한 디바이스를 매칭해 어트리뷰션을 결정론적으로(deterministic) 했습니다.
📌 이 글의 전제
독자가 모바일 앱 광고(UA, retargeting)를 운영하거나, 모바일 캠페인 보고서를 정기적으로 본다고 가정합니다. 광고 기술 디테일은 모르더라도 어트리뷰션·전환·CAC 같은 단어는 일상적으로 쓴다고 가정합니다.
iOS 14.5(2021년 4월)부터 ATT 프레임워크가 강제되면서, IDFA 접근에는 명시적 동의가 필요해졌습니다. 동의율은 카테고리·앱마다 다르지만 시장 평균 25~40% 수준이 흔하고, 이는 "iOS 유저의 60~75%는 IDFA 추적 불가"라는 의미입니다. Meta·Google처럼 자기 플랫폼에서 광고를 보여주는 회사도, MMP(Mobile Measurement Partner)도 이 영역에서는 결정론적 매칭을 못 합니다.
대안으로 등장한 것이 SKAN(애플 제공 익명·집계 어트리뷰션)과 AEM(Meta 제공 8개 이벤트 슬롯 기반 집계 데이터)입니다.
SKAdNetwork — 애플이 직접 처리하는 어트리뷰션
SKAN은 광고를 본 디바이스의 ID를 광고주·광고 네트워크에 노출하지 않고, 애플이 OS 레벨에서 어트리뷰션을 처리한 뒤 집계된 postback만 전달하는 구조입니다.
Postback 구조 — 무엇이 들어오나
| 필드 | 의미 | 한계 |
|---|---|---|
| campaign-id | 캠페인 식별자 (0~99) | 100개 이하만 동시 운영 가능 |
| source-app-id | 광고를 보여준 앱 | 비활성 시 NULL |
| conversion-value | 전환 가치 (0~63, 6bit) | 직접 정의 필요 |
| postback-sequence-index | 0/1/2 (3 윈도우) | 첫 24~48h, 4일, 7일 |
| crowd-anonymity | NULL 가능성 알림 | 노이즈 추가됨 |
핵심 한계는 세 가지입니다. 첫째, postback이 광고 노출 직후가 아니라 며칠 뒤 도착합니다. 둘째, 캠페인 단위가 100개로 한정되어 광고그룹·크리에이티브 세부 분석이 안 됩니다. 셋째, conversion value가 6비트(64개 값)뿐이라 풍부한 이벤트를 표현하기 어렵습니다.
Conversion Value 6bit 설계가 핵심
64개 슬롯에 무엇을 매핑할지가 SKAN 운영의 절반입니다. 흔한 설계는 다음을 한 정수에 인코딩합니다.
- 첫 24시간 내 핵심 이벤트 발생 여부 (회원가입·구매·튜토리얼 완료)
- 매출 구간(0원·1~5천·5천~3만·3만 이상…)
- 유저 프로파일 시그널(첫날 세션 수, 지역)
이 인코딩이 한 번 잘못 잡히면 며칠~몇 주의 데이터가 무용해집니다. 인코딩을 바꿀 때마다 시계열이 끊긴다는 점이 함정입니다.
⚠️ CV 변경의 비용
Conversion value 매핑을 바꾸면 그 시점 이전·이후의 데이터가 직접 비교 불가능해집니다. 분기 시작 시 한 번만 결정하고 가급적 바꾸지 않는 게 운영 안정성에 좋습니다.
AEM — Meta의 8슬롯 우선순위 게임
AEM(Aggregated Event Measurement)은 Meta가 ATT 비동의 유저를 위해 만든 도메인 단위 측정 프로토콜입니다. 한 도메인에서 측정할 이벤트를 최대 8개(또는 모바일 앱은 최근까지 9개 → 변경)까지 우선순위 리스트로 등록하고, 우선순위 1번 이벤트만 어트리뷰션에 사용됩니다.
슬롯 우선순위 설계
마케터가 운영 단계별로 가장 중요한 이벤트를 1번 슬롯에 두고, 보조 이벤트를 아래로 둡니다.
| 슬롯 | 흔한 매핑 | 사용 사례 |
|---|---|---|
| 1 | Purchase | 풀퍼널 ROAS 캠페인 |
| 2 | InitiateCheckout | 결제 시작 비율 모니터링 |
| 3 | AddToCart | 장바구니 단계 |
| 4 | ViewContent | 상위 퍼널 |
| 5~8 | 부수 이벤트 | 옵션 |
핵심 함정: 같은 유저가 1번과 2번 이벤트를 모두 일으켰을 때 1번만 카운트됩니다. 풀퍼널 측정을 그대로 합산하면 안 됩니다.
Domain Verification·CAPI 연동
AEM의 정확도는 도메인 검증과 Conversion API(서버측 이벤트 전송)로 올라갑니다. 픽셀 기반 클라이언트 측 데이터만으로는 ATT 비동의 유저의 신호가 거의 다 빠지므로, 서버에서 해싱된 이메일·전화번호로 매칭률을 끌어올리는 작업이 필수입니다.
마케터 수치의 한계 — 무엇을 더 못 보는가
ATT 비동의 환경에서 마케터가 잃는 것을 정리하면:
- 유저 단위 여정 — 어떤 광고를 본 사람이 어떤 광고를 본 뒤 전환했는지 추적 불가
- 실시간성 — SKAN postback이 며칠 지연. AEM도 일배치 가까움
- 광고그룹·크리에이티브 단위 — SKAN 100개 제한, AEM은 광고 단위까지 본다지만 신뢰가 떨어짐
- 리타게팅 정확도 — IDFA 없는 디바이스는 retargeting 풀에 못 들어감
- LTV 계산 — 첫 며칠 데이터만 잡혀 30·60·90일 LTV 추정이 어려움
마케터가 이 환경에서 살아남으려면 정확도 대신 방향성으로 의사결정 기준을 옮겨야 합니다. "Meta iOS ROAS가 정확히 1.4"는 못 알지만, "최근 2주가 그 전 4주보다 나아졌나 나빠졌나"는 여전히 답할 수 있습니다.
💡 iOS 측정의 황금 룰
iOS 캠페인 의사결정은 주 단위 트렌드와 안드로이드 동향과의 차이를 함께 봅니다. iOS만의 절대값에 의존하면 1주 단위로 의사결정이 흔들리고, 안드로이드와의 비교가 들어가면 외부 변수(시즌·경쟁) 영향을 자연스럽게 통제할 수 있습니다.
운영 가이드 — 분기 단위 점검 리스트
iOS 캠페인을 굴리면서 분기당 한 번 점검할 만한 항목들:
측정 인프라 점검
- [ ] AEM 8개 슬롯 우선순위가 현재 캠페인 목적과 일치하는가
- [ ] CAPI 서버 측 매칭률(EMQ, Event Match Quality)이 7점 이상인가
- [ ] SKAN conversion value 인코딩이 분기 핵심 KPI를 담고 있는가
- [ ] MMP의 SKAN 보고와 광고 플랫폼 보고의 차이가 30% 이내인가
의사결정 인프라 점검
- [ ] iOS 캠페인 ROAS는 일이 아니라 주 단위로 보는가
- [ ] 안드로이드 vs iOS 비율 변화에 alert가 걸려 있는가
- [ ] iOS는 Lift 실험·MMM에서 별도 채널로 분리되어 있는가
CAPI·서버 측 신호 강화
ATT 동의율을 끌어올리는 게 한계라면 CAPI(서버측 전송)로 이벤트 매칭률을 끌어올리는 게 우선입니다. EMQ 점수는 매칭 키(이메일·전화번호·이름) 개수와 해싱 정확도에 따라 0~10으로 매겨지고, 7점 이하라면 그 캠페인의 측정이 거의 잡히지 않는다고 봐도 무방합니다.
⚠️ EMQ 흔한 함정
CRM에서 빼낸 이메일이 평문·소문자 처리 안 됨·잘못된 SHA-256 등 처리 누락이 흔합니다. EMQ가 갑자기 떨어졌다면 데이터 파이프라인의 해싱 단계를 먼저 의심합니다.
마치며
iOS 광고 측정은 IDFA 시절 만큼의 정밀도로 돌아갈 일은 없습니다. SKAN·AEM·CAPI는 정밀도를 일부 포기하고 프라이버시 호환성을 얻은 새 표준이고, 마케터는 이 새 표준에 맞는 새 운영 룰을 받아들여야 합니다. 핵심은 절대값에서 트렌드로, 일 단위에서 주 단위로, 광고그룹 단위에서 캠페인 단위로 의사결정 단위를 한 단계 위로 끌어올리는 일입니다.
다음 분기에 한 번 시도해 볼 만한 것은 자체 LTV 모델을 SKAN conversion value 6bit에 맞춰 재인코딩하고, 첫 24시간 시그널만으로 30일 LTV를 추정하는 작은 모델을 붙이는 것입니다. iOS의 짧은 측정 윈도우를 보완하는 가장 실용적인 방법입니다.
{/* TODO_HUNY: 우리 앱·서비스에서 ATT 동의율과 EMQ 점수가 얼마인지, iOS와 안드로이드 ROAS 차이를 어떻게 해석하고 있는지 한 단락 */}
참고
- Apple, "SKAdNetwork": https://developer.apple.com/documentation/storekit/skadnetwork
- Meta, "Aggregated Event Measurement": https://www.facebook.com/business/help/721422165168355
- Apple, "App Tracking Transparency": https://developer.apple.com/documentation/apptrackingtransparency
- Adjust, "SKAN 4.0 guide": https://www.adjust.com/skan/
- AppsFlyer, "Conversion value modeling": https://www.appsflyer.com/glossary/conversion-value/
Top comments (0)