Aggregated Event Measurement в Facebook: что работает в 2026 году
Aggregated Event Measurement (AEM) - протокол Meta для измерения веб- и апп-событий пользователей на устройствах iOS 14 и новее с защитными мерами: удалением идентификаторов, дифференциальной приватностью и агрегацией по пользователям. Он появился после того, как App Tracking Transparency сделала отказавшихся от трекинга пользователей iOS 14.5+ невидимыми для IDFA. Если вы искали старый гайд по настройке - верификация домена, приоритизация 8 событий, вкладка AEM в Events Manager - такого воркфлоу больше не существует. В статье разобрано, что изменилось, что протокол делает сейчас и как под него обрабатываются серверные события.
Теперь вам не нужно предпринимать никаких шагов, чтобы ваши события обрабатывались через Aggregated Event Measurement.
Что такое Aggregated Event Measurement?
До iOS 14.5 Meta Pixel фиксировал конверсионные события без лимитов на уровне событий, а атрибуция была детерминированной. После внедрения ATT (обязательной с iOS 14.5) пользователи, отказавшиеся от трекинга, перестали определяться по IDFA, и Meta построила Aggregated Event Measurement, чтобы вернуть ограниченное измерение этих конверсий. Протокол обрабатывает события с защитными мерами - удалением идентификаторов, добавлением дифференциальной приватности и агрегацией данных по пользователям - до персонализации и измерения рекламы.
AEM покрывает две поверхности:
- События сайта: восстановление измерения для веб-кампаний с трафиком iOS 14.5+.
- Апп-события: кампании с целями sales, lead и engagement (продажи, лиды, вовлечение) с мобильным приложением в качестве назначения, позже расширенные на цель app promotion.
Что изменилось: Meta убрала настройку AEM
Meta выпустила обновления кампаний с веб-конверсиями, которые убрали процесс настройки полностью. По данным официального справочника:
- Приоритизировать 8 конверсионных событий на домен для веб-оптимизации конверсий больше не нужно, а value sets не требуются для value optimization.
- Вкладка Aggregated Event Measurement в Meta Events Manager удалена, потому что веб-события больше не требуют настройки.
- Верификация домена не требуется для задач, связанных с конфигурацией событий (для других функций она может понадобиться).
- Выбирать conversion domain при создании кампании в Ads Manager не нужно.
Практический вывод: любой гайд, который проводит вас по ранжированию 8 событий на подтверждённом домене, описывает удалённый интерфейс. Если в вашем Events Manager нет вкладки AEM - это ожидаемое состояние, а не ошибка настройки.
Что AEM делает сегодня
Удаление настройки не отменило сам протокол. AEM по-прежнему обрабатывает веб- и апп-события с устройств iOS 14+ с теми же защитными мерами, и Meta продолжает его развивать. Для медиабаеров важны два текущих поведения:
- Отчётность в MMP: с 9 октября 2024 Meta отправляет AEM-отчётность мобильным измерительным партнёрам (MMP), чтобы дать более полную картину эффективности привлечения пользователей в отчётах MMP.
- Отчётность и доставка апп-кампаний: кампании iOS 14+, использующие AEM как метод атрибуции, получают кликовые окна отчётности в 1 и 7 дней для app event optimization и value optimization, а также преимущества доставки вроде более длинного 7-дневного кликового окна атрибуции и доставки в Audience Network.
Для веб-кампаний нет ни ранжирования событий на домен, ни порядка приоритетов, который мог бы подавлять события воронки в агрегированных отчётах.
Совмещение AEM с Conversions API (CAPI)
Серверные события через CAPI обходят ограничения браузера - блокировщики рекламы и ITP - и остаются надёжным способом доставки конверсий с собственной инфраструктуры. Для ожиданий важна одна официальная оговорка: события, отправляемые в Meta через Conversions API, также могут обрабатываться в соответствии с лимитами, заданными Aggregated Event Measurement. CAPI - не отказ от протокола, а более надёжный канал доставки в него.
Что по-прежнему под вашим контролем - дедупликация. Meta дедуплицирует события, пришедшие и из Pixel, и из CAPI в окне 48 часов, при совпадающих event_id; приоритет у браузерного события.
- Pixel продолжает отправлять стандартные события в браузере.
- Те же события дублируются серверно через CAPI с совпадающими
event_id. - Дедупликация схлопывает двойное срабатывание в одну засчитанную конверсию.
Пошаговая интеграция CAPI с трекером - в гайде Facebook CAPI в Keitaro. Если упираетесь в 7-дневный лимит обработки, смотрите Facebook CAPI Error 2804003. Механика общих идентификаторов разобрана в статье event_id и дедупликация.
Браузерный Pixel ---> event_id: abc123 ---> Meta получает оба,
CAPI (сервер) ---> event_id: abc123 считает один раз (дедупликация)Для автоматической маршрутизации конверсий без ручной настройки постбэков используйте MOST - платформу маршрутизации и отчётности по рекламным сетям. Для быстрой ручной активации пикселя без трекера подойдёт Pixel Activator - отправка тестовых событий напрямую.
Решение проблем с веб-отчётностью конверсий
| Симптом | Вероятная причина | Решение |
|---|---|---|
| Нет вкладки AEM или ранжирования событий в Events Manager | Настройка удалена Meta | Ожидаемое состояние; восстанавливать нечего |
| События CAPI отсутствуют в отчётах | Несовпадение event_id между Pixel и CAPI | Синхронизируйте генерацию event_id на обоих каналах |
| Подозрительный разрыв между цифрами трекера и Ads Manager | Браузерная доставка теряет события из-за блокировщиков и ITP | Добавьте серверную доставку; сравнение архитектур - в гайде Серверный трекинг против браузерного пикселя |
После любых изменений доставки событий используйте инструмент Test Events, чтобы убедиться, что события доходят корректно, прежде чем судить об агрегированной отчётности. Воркфлоу валидации разобран в гайде Meta Test Events Tool.