메타 이벤트 8개 제한: 폐지 후에도 우선순위가 필요한 이유
메타 이벤트 8개 제한은 단순한 설정 개수 제한이 아니었습니다. iOS 사용자의 추적 거부 이후 메타가 어떤 전환을 우선 측정할지 정하려고 만든 장치였습니다.
지금은 이벤트 관리자에서 8개를 고르고 순서를 매기는 절차가 사라진 계정이 대부분입니다. 그래도 실무에서 중요한 건 달라지지 않았습니다. "몇 개까지 넣을 수 있나"보다 "어떤 이벤트 하나에 최적화를 맡길 것인가"를 먼저 정해야 합니다. 메타의 측정은 여전히 신호가 적은 환경에서 이 판단을 기준으로 움직이기 때문입니다.
아래에서 8개 제한이 어떻게 작동했는지, 폐지된 뒤 무엇이 남았는지, 이벤트 구성을 점검하는 기준을 차례로 설명합니다.
1. 메타 이벤트 8개 제한이란: 생긴 이유와 작동 방식
출발점은 iOS 14.5의 추적 동의 정책
2021년 애플은 iOS 14.5부터 앱 추적 투명성(ATT) 정책을 적용했습니다.
앱이 사용자를 다른 앱·웹사이트에서 추적하려면 별도 동의를 받아야 하는 구조입니다.
동의하지 않은 사용자가 광고를 누르고 웹사이트에서 구매하면
메타는 그 사람의 행동을 예전처럼 하나하나 연결할 수 없게 됐습니다.
이때 메타가 도입한 방식이 집계된 이벤트 측정(Aggregated Event Measurement, AEM) 입니다.
개별 사용자 대신 집계된 형태로 전환을 측정하는 프로토콜입니다.
도메인당 8개, 그리고 '우선순위'
AEM의 핵심 규칙은 두 가지였습니다.
도메인 하나에서 광고 최적화에 쓸 수 있는 웹 전환 이벤트는 최대 8개
8개에는 1위부터 8위까지 순위를 매겨야 함
순위가 필요했던 이유가 중요합니다.
추적을 거부한 iOS 사용자가 한 번의 방문에서 장바구니 담기, 결제 시작, 구매를 모두 했더라도
메타는 그중 가장 순위가 높은 이벤트 하나만 보고했습니다.
그러니까 구매를 1위, 장바구니를 3위로 뒀다면 이 사용자는 '구매 1건'으로만 잡히고
장바구니 담기는 기록에 남지 않았습니다.
당시 운영자가 겪던 제약
8개 제한 체제에서 실무자들이 자주 부딪힌 제약은 이렇습니다.
항목 | 8개 제한 체제에서의 규칙 | 실무 영향 |
|---|---|---|
이벤트 수 | 도메인당 최대 8개 | 맞춤 이벤트를 많이 쓰는 계정은 정리가 필요했음 |
우선순위 | 1~8위 지정 | iOS 옵트아웃 사용자는 최상위 이벤트 1개만 집계 |
순위 변경 | 변경 시 약 72시간 동안 관련 광고 게재 제한 | 캠페인 운영 중에는 순위를 함부로 바꿀 수 없었음 |
도메인 인증 | 이벤트 구성 전에 도메인 인증 필요 | 인증을 안 하면 이벤트를 구성할 수 없었음 |
전환 보고 | 옵트아웃 사용자 전환은 최대 3일 지연 | 당일 성과만 보고 판단하면 과소평가됨 |
-> 핵심: 8개 제한은 '개수' 문제가 아니라, 신호가 부족할 때 무엇을 먼저 셀지 정하는 '우선순위' 문제였습니다.
2. 메타 이벤트 8개 제한 폐지 이후 달라진 것과 남은 것
달라진 것: 수동 구성 절차가 사라짐
2025년을 지나면서 메타는 AEM 운영 방식을 단순화했습니다.
이벤트 관리자에서 8개 이벤트를 직접 고르고 순위를 매기는 설정이 대부분의 계정에서 사라졌고,
AEM 적용을 위해 도메인 인증을 반드시 먼저 해야 하는 조건도 완화됐습니다.
그래서 요즘 광고 계정을 처음 세팅하는 분들은
"8개 우선순위 설정 메뉴가 어디 있냐"고 찾다가 메뉴 자체가 없다는 걸 발견하는 경우가 많습니다.
다만 적용 시점과 화면 구성은 계정마다 다를 수 있으므로
과거 가이드를 참고할 때는 내 이벤트 관리자에 해당 메뉴가 남아 있는지부터 확인하는 편이 안전합니다.
남은 것: iOS 옵트아웃 사용자의 측정 한계
규칙이 바뀌었다고 해서 ATT가 사라진 건 아닙니다.
추적을 거부한 사용자의 전환은 여전히 제한된 신호로 측정되고, 일부는 모델링으로 추정됩니다.
실무에서 체감되는 차이는 이렇습니다.
광고 관리자 구매 수와 자사몰 실제 주문 수 사이의 격차는 여전히 존재함
전환이 뒤늦게 반영되는 현상도 여전히 있음 (당일 새벽에 본 수치가 며칠 뒤 올라가는 경우)
픽셀만 설치한 계정은 CAPI까지 연결한 계정보다 이 격차가 크게 벌어지는 경향이 있음
남은 것: 최적화 이벤트는 여전히 하나
더 본질적인 부분도 있습니다.
광고 세트 하나는 전환 위치와 최적화 이벤트를 하나만 고릅니다.
이벤트를 20개 보내든 8개 보내든, 알고리즘이 학습하는 대상은 세트에서 선택한 그 하나입니다.
즉, 8개 제한이 풀리면서 늘어난 건 "보낼 수 있는 이벤트 수"이지
"최적화에 쓸 수 있는 신호의 양"이 아닙니다.
-> 핵심: 개수 제한은 사라졌지만, 신호가 적은 환경에서 어떤 이벤트를 기준으로 삼을지 정하는 판단은 여전히 운영자 몫입니다.
메타 도메인 인증: 방식별 선택 기준과 실패 원인 정리
3. 메타 이벤트 우선순위 정하는 4가지 기준
메뉴가 사라졌어도, 8개 체제에서 쓰던 우선순위 사고방식은 이벤트 설계 기준으로 그대로 쓸 수 있습니다.
실무에서 쓰는 기준을 네 가지로 정리했습니다.
기준 ① 퍼널을 거꾸로 올라가며 정한다
가장 먼저 둘 이벤트는 매출과 직접 연결되는 최종 전환입니다.
커머스라면 Purchase, 리드 수집형이라면 Lead나 상담 신청 완료 이벤트입니다.
그다음부터는 퍼널을 한 단계씩 거꾸로 올라갑니다.
순서 | 커머스 | 리드 수집형 | 앱 설치 유도형 웹 |
|---|---|---|---|
1 | Purchase | Lead(신청 완료) | CompleteRegistration |
2 | InitiateCheckout | 신청 폼 제출 시작 | 사전 예약 |
3 | AddToCart | 상담 페이지 조회 | 기능 소개 페이지 조회 |
4 | ViewContent | ViewContent | ViewContent |
이 순서를 정해두면 어떤 이벤트가 '최적화용'이고
어떤 이벤트가 '진단용'인지 팀 안에서 헷갈리지 않습니다.
기준 ② 주당 50건을 채울 수 있는 이벤트인가
메타 알고리즘이 학습 단계를 벗어나려면
일반적으로 광고 세트당 7일 내 최적화 이벤트 약 50건이 필요합니다.
예를 들어 일 예산 5만 원, 구매 CPA가 3만 원인 계정이라면
주당 구매 전환은 11~12건 수준입니다. 50건에 한참 못 미칩니다.
이런 계정에서는 최종 전환인 Purchase에 바로 최적화하기보다
한 단계 위 이벤트(InitiateCheckout, AddToCart)로 학습을 먼저 시키는 선택을 검토합니다.
대신 이 경우 결제 시작은 많은데 구매로 넘어가지 않는 트래픽이 섞일 수 있으니
최소 2주간 구매 전환율을 같이 봐야 합니다.
기준 ③ 표준 이벤트로 먼저 해결한다
8개 체제에서 가장 흔한 실수는 맞춤 이벤트를 과하게 만드는 것이었습니다.
'버튼A 클릭', '팝업 닫기', '스크롤 50%' 같은 이벤트를 전부 전환처럼 보내는 경우입니다.
지금도 원칙은 같습니다.
메타가 이미 정의한 표준 이벤트(Purchase, Lead, AddToCart 등)로 먼저 매핑
표준 이벤트로 표현이 안 될 때만 맞춤 이벤트 또는 맞춤 전환 사용
맞춤 전환은 URL 규칙 기반이라 페이지 주소가 바뀌면 조용히 끊길 수 있으므로, 리뉴얼 일정이 있으면 사전 점검
표준 이벤트는 메타가 학습에 활용하는 방식이 명확하고,
다른 광고주 데이터와도 같은 기준으로 비교되기 때문에 최적화 안정성이 높습니다.
기준 ④ 값(value)이 필요한 이벤트는 따로 챙긴다
ROAS 최적화나 가치 기반 최적화를 쓰려면
Purchase 이벤트에 금액(value)과 통화(currency) 가 정확히 실려야 합니다.
실무에서 자주 보는 오류는 이렇습니다.
금액에 배송비·할인 전 금액이 들어가 ROAS가 부풀려짐
통화 값이 누락되거나 USD로 잘못 들어감
쿠폰 전액 결제 주문이 0원으로 들어가 가치 최적화 학습을 흐림
-> 핵심: 우선순위의 1순위는 '가장 중요한 이벤트'이고, 동시에 '충분히 자주 발생하며 값이 정확한 이벤트'여야 합니다.
4. 메타 이벤트 구성 실패 사례와 점검 체크리스트
사례 1: 이벤트가 많을수록 좋다고 생각한 경우
한 패션 브랜드의 경우 페이지별 버튼 클릭까지 합쳐 맞춤 이벤트가 20개 넘게 설정돼 있었습니다.
정작 광고 세트는 대부분 AddToCart에 최적화돼 있었고,
Purchase 이벤트는 결제 완료 페이지가 아닌 주문서 페이지에서 발생하도록 잘못 걸려 있었습니다.
결과적으로 광고 관리자에 찍힌 구매 수가 실제 주문보다 훨씬 많았습니다.
이벤트를 정리하고 Purchase 발생 위치를 결제 완료 페이지로 옮기자
보고되는 구매 수는 줄었지만, 광고 관리자와 실제 매출의 방향이 맞기 시작했습니다.
이런 케이스에서는 숫자가 줄어든 게 개선입니다.
틀린 신호로 학습하던 알고리즘이 맞는 신호로 다시 학습하게 되기 때문입니다.
사례 2: 픽셀과 CAPI가 같은 구매를 두 번 보낸 경우
8개 제한이 있던 시기에도, 폐지된 지금도 꾸준히 나오는 문제가 중복 전환입니다.
브라우저 픽셀과 서버 CAPI가 같은 구매를 각각 보냈는데
event_id가 일치하지 않아 메타가 중복을 걸러내지 못하는 경우입니다.
이벤트 관리자에서 Purchase 이벤트의 '중복 제거' 상태를 확인하고,
픽셀과 서버 양쪽에서 동일한 event_id가 전달되는지 확인하는 게 우선입니다.
메타 event id 설정 기준: 픽셀·CAPI 중복 제거 4단계 점검
사례 3: 리드 수집형인데 이벤트 이름을 섞어 쓴 경우
상담 신청을 받는 브랜드에서 어떤 페이지는 Lead, 어떤 페이지는 CompleteRegistration,
또 다른 페이지는 SubmitApplication으로 같은 행동을 기록하는 경우가 있습니다.
같은 행동이 세 이벤트로 흩어지면 각 이벤트 건수가 모두 50건에 못 미쳐
어느 이벤트로 최적화해도 학습이 불안정해집니다.
같은 행동은 하나의 표준 이벤트로 통일하는 게 원칙입니다.
지금 바로 해볼 이벤트 점검 체크리스트
이벤트 관리자를 열고 아래 항목을 확인해 보세요.
[] 최적화에 실제로 쓰는 이벤트가 무엇인지 한 줄로 말할 수 있는가?
[] 그 이벤트가 광고 세트 기준 주당 50건 안팎으로 발생하고 있는가?
[] Purchase(또는 Lead)가 '완료 페이지'에서만 발생하는가?
[] 픽셀과 CAPI 양쪽에서 같은 event_id가 들어오고 중복 제거가 되고 있는가?
[] Purchase의 금액·통화 값이 실제 결제 금액과 맞는가?
[] 같은 행동을 서로 다른 이벤트 이름으로 보내고 있지 않은가?
[] 과거 8개 제한 가이드를 참고했다면, 지금 내 계정 화면에 해당 설정이 실제로 남아 있는가?
세 개 이상 '아니오'가 나온다면 소재나 타겟을 손보기 전에
이벤트 구조부터 정리하는 편이 성과 개선에 더 빠릅니다.
메타 광고 전환 안잡힘: 발생·수신·귀속 3구간 진단 순서
자주 묻는 질문
Q. 메타 이벤트 8개 제한은 지금도 적용되나요?
2025년 이후 대부분의 계정에서 8개 이벤트를 직접 선택하고 순위를 매기는 설정이 사라졌습니다. 다만 계정별로 적용 시점과 화면이 다를 수 있으니 이벤트 관리자에서 해당 메뉴가 있는지 직접 확인하는 것이 정확합니다. 제한이 풀렸더라도 iOS 추적 거부 사용자의 측정 한계는 그대로 남아 있습니다.
Q. 메타 이벤트 우선순위 설정 메뉴가 안 보이는 이유는?
메타가 집계된 이벤트 측정(AEM)의 수동 구성 절차를 단순화했기 때문입니다. 메뉴가 없다고 설정이 잘못된 것은 아니며, 추가로 할 조치도 없습니다. 대신 광고 세트에서 고르는 최적화 이벤트를 신중히 정하는 것이 사실상 우선순위 설정 역할을 합니다.
Q. 메타 픽셀 이벤트는 몇 개까지 보내도 되나요?
보내는 것 자체에는 실무상 큰 제약이 없습니다. 하지만 이벤트가 많아질수록 같은 행동이 여러 이름으로 흩어지거나 잘못된 위치에서 발생할 위험이 커집니다. 최적화용 이벤트 1~2개와 진단용 표준 이벤트 몇 개로 구성하는 편이 관리하기 좋습니다.
Q. 구매 전환이 적으면 어떤 이벤트로 최적화해야 하나요?
광고 세트 기준 주당 구매가 50건에 크게 못 미친다면 InitiateCheckout이나 AddToCart처럼 한 단계 위 이벤트를 검토합니다. 다만 상위 이벤트로 최적화하면 구매로 이어지지 않는 트래픽이 섞일 수 있으니, 최소 2주간 구매 전환율과 CPA를 함께 확인해야 합니다.
마무리
메타 이벤트 8개 제한은 사라졌지만, 이 제한이 던졌던 질문은 그대로 남아 있습니다.
"신호가 부족할 때, 무엇을 가장 먼저 셀 것인가."
최종 전환을 1순위로 두고, 그 이벤트가 충분히 자주 발생하는지 확인하고,
표준 이벤트로 통일하고, 금액 값을 정확히 싣는 것.
이 네 가지만 지켜도 이벤트 구조 때문에 새는 성과는 상당 부분 막을 수 있습니다.
이벤트를 더 많이 보내는 것보다, 맞는 이벤트 하나를 정확하게 보내는 쪽이 알고리즘에게 훨씬 좋은 신호입니다.