들어가며
Meta의 AEM(Aggregated Event Measurement)은 ATT 비동의 유저용 측정 프로토콜인데, 한 도메인에서 측정할 이벤트를 9개까지만 우선순위 리스트로 등록할 수 있습니다. 풀퍼널 측정에서 보통 20~30개 이벤트를 보내던 것을 9개로 압축해야 하고, 어느 이벤트를 1번 슬롯에 두느냐가 캠페인 ROAS 보고를 직접 결정합니다. 이 글은 9개 슬롯 우선순위를 디자인하는 룰과 캠페인 목표별 매핑 패턴을 마케터 시선에서 정리합니다.

20개 이벤트를 9개로 줄이는 작은 게임 — 우선순위가 보고서를 결정한다
AEM의 동작 원리
같은 유저의 여러 이벤트가 발생하면
같은 ATT 비동의 유저가 한 광고 노출 후 24시간 안에 여러 이벤트(ViewContent, AddToCart, InitiateCheckout, Purchase)를 일으켰다고 합시다. AEM은 그 중 우선순위가 가장 높은 이벤트 하나만 어트리뷰션에 사용합니다.
📌 이 글의 전제
Meta 광고를 운영하고 픽셀·CAPI라는 단어를 일상에서 쓴다고 가정합니다(ios-att-skadnetwork-aem 참고). AEM이 ATT 비동의 유저의 측정 도구라는 건 받아들이면 충분합니다.
우선순위 1번이 보고에 노출
AEM 보고서에 잡히는 건 우선순위 1번 이벤트의 카운트입니다. AddToCart가 우선순위 1번이고 Purchase가 5번이라면, Purchase한 유저도 보고서에는 AddToCart로 잡힙니다. 풀퍼널 캠페인의 ROAS를 단순 합산하면 안 되는 이유.
슬롯 디자인의 표준 패턴
패턴 1 — 풀-퍼널 컨버전 캠페인
ROAS 목표 광고를 운영하는 이커머스:
| 슬롯 | 이벤트 | 비고 |
|---|---|---|
| 1 | Purchase | 가장 비싼 행동, ROAS 핵심 |
| 2 | InitiateCheckout | 결제 시작, 미들 퍼널 |
| 3 | AddToCart | 장바구니 |
| 4 | ViewContent | 상위 퍼널 |
| 5 | Subscribe | 구독 (해당 시) |
| 6~9 | 부수 이벤트 | Search·Wishlist·Lead 등 |
이 매핑이 ROAS 측정에 가장 정확합니다.
패턴 2 — 신규 사용자 획득 (UA)
신규 가입 KPI 캠페인:
| 슬롯 | 이벤트 |
|---|---|
| 1 | CompleteRegistration |
| 2 | Lead |
| 3 | StartTrial |
| 4 | Subscribe |
| 5 | Purchase |
UA 캠페인에서는 가입이 1번 슬롯이지만, 같은 도메인에서 ROAS 캠페인도 운영하면 충돌합니다 — AEM이 도메인 단위라서 풀퍼널과 UA를 분리하는 게 어렵습니다.
패턴 3 — 콘텐츠·앱 (광고 매출형)
소셜·콘텐츠·게임 앱:
| 슬롯 | 이벤트 |
|---|---|
| 1 | Subscribe (프리미엄) |
| 2 | Purchase (in-app) |
| 3 | TutorialComplete |
| 4 | LevelComplete (게임) |
| 5 | ViewContent |
엔게이지먼트 단계별 우선순위를 줍니다.
도메인 단위의 함정
한 도메인 = 9 슬롯 공유
example.com에서 ROAS 캠페인과 UA 캠페인을 동시에 운영하면 9개 슬롯을 공유합니다. UA의 1번 슬롯은 가입, ROAS의 1번 슬롯은 구매여야 하는데 둘 다 1번에 놓을 수 없습니다.
서브도메인으로 분리
해결책 중 하나는 캠페인 종류별로 서브도메인을 분리하는 것입니다.
-
shop.example.com→ ROAS 캠페인용 (Purchase 1번) -
signup.example.com→ UA 캠페인용 (Registration 1번)
서브도메인마다 독립적인 9개 슬롯을 갖습니다. 다만 운영 복잡도가 늘어나고, SEO·UX에 영향을 미칠 수 있습니다.
💡 서브도메인 분리 결정 룰
ROAS와 UA 두 캠페인 동시 운영 + 둘 다 비중 30% 이상 → 서브도메인 분리 검토
ROAS만 90% 이상 → 단일 도메인으로 충분
UA가 일시적·계절적 → 단일 도메인 + 시즌마다 우선순위 조정
우선순위 변경의 비용
Pixel-AEM 동기화
AEM 우선순위는 Meta 비즈니스 매니저에서 변경하지만, 변경 즉시 측정에 적용되지 않습니다. 픽셀·CAPI에서 보내는 이벤트 이름이 일치해야 하고, 변경 후 24~48시간 propagation 시간이 걸립니다.
캠페인 학습 영향
ROAS 목표 캠페인은 Meta의 ML이 우선순위 1번 이벤트를 학습 신호로 씁니다. 1번 슬롯을 바꾸면 ML이 다시 학습 단계로 돌아가고, 1~2주간 캠페인 성과가 흔들립니다.
⚠️ 우선순위 변경 빈도
분기에 한 번 이하가 안전합니다. 자주 바꾸면 ML 학습 안정화 시간을 매번 다시 거치게 되어 캠페인 효율이 떨어집니다.
CAPI 매칭률 — AEM의 정확도 절반
EMQ 점수의 의미
AEM은 픽셀(클라이언트) + CAPI(서버) 신호를 합쳐 매칭합니다. CAPI에서 보내는 사용자 신호의 매칭 품질을 EMQ(Event Match Quality)로 0~10점 매기고, 7점 이상이어야 광고 최적화에 신호가 잘 들어갑니다.
| EMQ 점수 | 매칭 키 |
|---|---|
| 1~3 | IP·user agent만 |
| 4~6 | + 이메일 또는 전화 1개 |
| 7~9 | + 이메일·전화·이름 |
| 10 | 모든 매칭 키 + 정규화 완벽 |
매칭 키 우선순위
EMQ를 끌어올리려면 다음 매칭 키를 보내야 합니다(우선순위 순):
- 이메일 (해싱 SHA-256, 소문자)
- 전화번호 (E.164 형식, 해싱)
- 이름·성 (소문자, 해싱)
- 외부 ID (회원 ID 등)
- IP 주소·User Agent
이 다섯 개를 모두 보내면 EMQ 9~10이 일반적입니다. 정규화 단계 누락이 EMQ 떨어뜨리는 가장 흔한 원인.
광고 보고 해석의 함정
같은 유저가 여러 채널 광고에 잡힘
ATT 동의 유저는 결정론적, 비동의 유저는 AEM 집계 — 두 경로의 데이터가 보고서에 합쳐지면서 해석이 복잡해집니다. 같은 매출이 두 경로에서 모두 카운트되는 dedup 처리가 필요합니다.
상위 슬롯 이벤트의 카운트 부풀림
AddToCart가 1번 슬롯이고 Purchase가 그 아래라면, Purchase 유저의 카운트가 AddToCart에 흡수됩니다. AddToCart 카운트가 실제 장바구니 행동보다 부풀어 보이는 신호.
모니터링 alert
- 일별 EMQ 점수 < 7 알림
- 우선순위 1번 이벤트 카운트의 30% 이상 변동 알림
- 픽셀-CAPI 카운트 차이 50% 이상 알림 (서버 측 신호 누락)
분기 점검 체크리스트
우선순위 적정성
- [ ] 9개 슬롯의 이벤트 목록과 분기 캠페인 목표 일치
- [ ] 1번 슬롯이 가장 가치 있는 행동인가
- [ ] 풀퍼널 단계가 우선순위 순으로 잘 배치됐는가
기술 인프라
- [ ] CAPI EMQ 7점 이상
- [ ] 픽셀-CAPI dedup ID(event_id) 일치
- [ ] 매칭 키 정규화 (이메일 소문자·전화 E.164)
보고 해석
- [ ] 1번 슬롯 카운트의 부풀림 가능성 인지
- [ ] 우선순위 변경 시 시계열 단절 문서화
- [ ] AEM 보고와 다른 측정(MMP·MMM·Lift) 비교
💡 실무 운영 워크플로
마케팅·앱·분석 3팀이 분기 시작에 한 시간 워크숍 — 9개 슬롯 우선순위 결정·CAPI 매칭 키 점검·예외 도메인 분리 결정. 분기 중에는 손대지 않습니다. {/* TODO_HUNY: 우리 회사 9개 슬롯 우선순위와 마지막 변경 시점 한 단락 */}
함정 모음
- UA·ROAS 동일 도메인 충돌 — 1번 슬롯 결정 갈등
- EMQ 7점 미만 방치 — 측정 데이터 사실상 안 들어감
- 잦은 우선순위 변경 — ML cold start 반복
- 이벤트 이름 불일치 — 픽셀과 CAPI에서 다른 이름으로 보내면 dedup 실패
- 1번 슬롯 부풀림 무시 — 1번 이벤트 카운트를 그대로 신뢰
마치며
AEM 9슬롯은 마케터가 iOS·웹의 ATT 비동의 유저를 측정하는 거의 유일한 프로토콜이고, 9개 슬롯의 우선순위가 캠페인 보고서의 절반을 결정합니다. 캠페인 목표별 표준 패턴, 도메인 분리 룰, 우선순위 변경 빈도 통제, EMQ 7점 유지 — 이 네 가지가 분기 운영에 박혀 있으면 AEM은 안정적인 측정 도구가 됩니다.
다음 분기에 한 번만 시도해 볼 만한 것은 9개 슬롯의 우선순위와 캠페인 ML 학습 신호를 같이 보는 모니터링 대시보드입니다. 우선순위 변경 후 ML 안정화 시간이 얼마나 걸리는지 정량화하면 다음 변경 결정에 자료가 됩니다.
{/* TODO_HUNY: 우리가 9개 슬롯 우선순위를 마지막으로 바꿨을 때의 학습 안정화 기간과 결과 한 단락 */}
참고
- Meta, "Aggregated Event Measurement": https://www.facebook.com/business/help/721422165168355
- Meta, "Conversion API documentation": https://developers.facebook.com/docs/marketing-api/conversions-api/
- Meta, "Event Match Quality": https://www.facebook.com/business/help/765081237991954
- "AEM best practices" (Singular): https://www.singular.net/blog/aem/
- Meta, "Domain verification": https://www.facebook.com/business/help/286768115176155
Top comments (0)