- Партнерки
- B2B
- Статьи
- Блоги
- Работа
- Сервисы
- Агентские кабы
- Объявления
- Ещё
- ТОП итог за 5 мин
В партнерке 50 подтвержденных лидов, в трекере те же 50, а в кабинете Facebook* — только 20. Куда делись 30 и что в итоге сломалось? При этом в 2026 году Meta* еще и обновила отчетность, поэтому с расхождениями сейчас еще больше путаницы.
Разберем, из чего на самом деле складывается сегодняшний коллапс атрибуции в Meta*, где теряются конверсии и как вернуть статистике вменяемый вид.
Collapse Attribution API — это разрыв связи между показом рекламы и целевым действием. Допустим, человек зацепился за крео, подумал пару дней и депнул, но за это время браузер снес куки или метка срезалась на редиректе. Для Meta* это выглядит так, будто он сам нашел сайт. В итоге деньги упали реклу, лид есть в партнерке, а в кабинете и API конверсия потерялась. По одному отчету пока видно только, что Meta* не показала эту конверсию среди результатов рекламы. Чтобы понять, потерялся ли сигнал для оптимизации, нужно проверить, получила ли Meta* само событие.
В начале 2026 года Meta* выкатила обновление Ads Insights API и убрала оттуда два окна атрибуции по показам — на 7 и 28 дней. Если ваши выгрузки или дашборды тянули стату по этим окнам, из привычных отчетов разом пропала часть конверсий после показа. Ну а что? Задач у байера ведь немного, почему бы не потратить еще полдня на ручную сверку выгрузок с партнеркой.
Вообще об этих правках в Meta* предупреждали еще в октябре 2025 года, но мало кто читал блог для разработчиков, пока все и так прекрасно работало. До обновы через Ads Insights API можно было посчитать конверсии за 7 или 28 дней после показа крео, даже если юзер по рекламе не кликнул. При этом конверсии по просмотрам не исчезли совсем — суточное окно 1d_view (и кликовые 1d_click / 7d_click) осталось доступным. Но если ваш дашборд подтягивал именно длинные хвосты, после обновления можно было знатно поседеть, глядя на просадку конверсий.
Январское обновление особенно задело команды, которые тянут стату из кабинета своими скриптами в таблицы или дашборды. По данным блога Meta* for Developers, при запросе параметра action_attribution_windows устаревшие окна 7d_view и 28d_view просто исключаются из выдачи. API не падает с ошибкой, а отдает статус 200 OK, но без данных по этим окнам, из-за чего самописные парсеры молча подтягивали нули.
Все это дело сильно ударило по вертикалям, где клиент долго решается на покупку или первый деп, в том числе по крипте, финансам, e-commerce, дорогой нутре и гемблингу с пуш-дожимом. В этих нишах вы часто греете человека несколько дней, и раньше API привязывал эти покупки к показу рекламы еще целую неделю или месяц, а теперь — всего сутки.
При этом реальные деньги в этот момент продолжают капать по назначению. У рекла есть оплаты, в партнерке капают апрувы, но ваш скрипт тянет стату через API и доброй части конверсий просто не видит.
А дальше в дело вступают автоправила… Допустим, вы настроили стоп на адсеты, если за трое суток просел ROI в дашборде, который тянет данные из Ads Insights API, а ваша аудитория привыкла дозревать до заявки на четвертый день после просмотра ролика без клика. Скрипт считает, что связка сливает в минус, и гасит ее среди ночи.
Так что доверять судьбу связки одним цифрам из API сейчас уж точно не стоит, а перед стопом кампании всегда сверяйте спенд и профит в своем трекере, партнерке или внутренней аналитике. К тому же конверсии после кликов у вас и так бьются с трафиком по subid. Сложнее с теми, кто посмотрел креатив без перехода и купил пару дней спустя.
В марте 2026 года Meta* поменяла правила атрибуции для конверсий на сайте и в офлайн-магазинах. В click-through теперь учитываются только конверсии после клика по ссылке в объявлении. Если человек, например, сохранил объявление, по ссылке не кликнул, а позже купил, Meta* может отнести покупку к engage-through — атрибуции по взаимодействию. Поэтому при сравнении отчетов до и после обновления в колонке click-through может стать меньше конверсий, даже если число покупок осталось прежним.
Впрочем, урезанные отчеты и реальное обучение кампаний в Meta* живут отдельно друг от друга. Движок Meta* Andromeda вместе с Advantage+ смотрит на поток событий, которые приходят напрямую в Events Manager. Пока вы исправно шлете в Meta* покупки и заявки, у алгоритма есть на чем учиться. Он видит, кто откликается на оффер, и ищет людей, которые тоже могут сконвертиться. А если постбэк по пути отвалился, живой лид для системы превращается в обычный пустой переход, и алгоритм попросту недополучает нужный сигнал для качественной оптимизации.
Даже если постбэк доехал, покупка может не появиться в результатах адсета. Тут важно, какое окно атрибуции стоит в настройках группы объявлений: оно влияет и на учет конверсий, и на оптимизацию показов. 1d_click — это сутки после клика по ссылке, 7d_click — семь дней, а 1d_view — сутки после показа, даже если человек не кликнул. Например, в адсете можно выбрать 7d_click вместе с 1d_view. Допустим, в адсете стоит только 1d_click. Человек кликнул по крео, ушел советоваться с женой и купил на третий день. Meta* могла получить событие, но в результаты адсета по этому окну покупка уже не попадет.
В партнерке 50 апрувов, в трекере те же 50, а в Events Manager — двадцать. Куда делись остальные? Может, трекер вообще не отправил часть апрувов. А может, отправил, но Meta* их не приняла. По цифрам в кабинете этого не понять.
Постбэк может дойти до Meta*, но CAPI отклонит событие, если у него слишком старый event_time. В этом поле передается время самого события (когда юзер реально совершил покупку или оставил заявку). В Meta* принимают конверсии максимум за семь суток от этого момента. Если вы решили задним числом дослать их со старым временем заявки, API ответит ошибкой валидации. Для системы такой лид уже просрочен, как бы сильно вам ни хотелось скормить его в обучение.
Пример ошибки
Даже если событие укладывается в эти семь суток, задержка всё равно имеет значение. Допустим, вы льете с оптимизацией на апрувы. В обед партнерка подтвердила десять лидов, а постбэки доехали до Meta* только к восьми вечера. Вот за этот разрыв между апрувом и получением события в Meta* и отвечает Data Freshness («Свежесть данных»). Все это время адсет продолжал тратить бюджет, а Meta* еще не получила данные о десяти аппрувах. Если слать постбэки сразу, Meta* раньше получит сигнал для оптимизации адсета.
Апрув уже есть в трекере, а события в Meta* все еще нет? По логам видно, ушел ли постбэк и когда. Запрос не ушел, тогда Meta* не получит событие через CAPI. Если Meta* приняла событие, а в Ads Manager конверсии все равно нет, чекайте, доживает ли fbclid до вашего ленда. При клике по объявлению соцсеть сама дописывает этот ID к ссылке. Но стоит прогнать трафик через бесплатный шортнер, кривой редирект с HTTP на HTTPS, кеш Cloudflare или отдельную прокладку без проброса параметров, как метка обрезается по пути.
Если fbclid срезало по дороге и вы не успели его сохранить, событие всё равно можно отправить через CAPI. Meta* может получить заявку или покупку, но в запросе не будет fbc с ID этого клика. Для сопоставления Meta* может использовать другие данные, если вы их передаете, например fbp, external_id или хешированный email.
Поэтому лучше сразу сохранять fbclid в куки или сессию, как только он попал к вам. А если льете через редиректы и проклы, настройте сквозной проброс параметров ссылки, чтобы метку не срезало по дороге.
Ошибиться с форматом fbc могут те, кто настраивает отправку в Conversions API руками или своими скриптами. Если просто вытащить fbclid из URL и сунуть его в поле fbc как есть, нормальной склейки с кликом не выйдет. Для сервера идентификатор нужно обернуть в формат fb.1.{timestamp_в_миллисекундах}.{fbclid}, не трогая заглавные и строчные буквы самой метки. Если пропустите этот префикс или собьете регистр, пришедший лид в кабинете просто не свяжется с объявлением.
Пример правильно собранного fbc — префикс fb.1, время в миллисекундах и идентификатор клика
Важная деталь — единицы времени. Корневое поле event_time в JSON-пакете CAPI передается в секундах Unix-времени, а временная метка внутри fbc — в миллисекундах. Два разных формата времени в одном запросе легко перепутать по невнимательности. А поскольку кривой таймстамп в fbc сервер может проглотить без ошибки, то зеленый статус в логах еще ничего хорошего не значит. Откройте отправленный запрос и проверьте обе метки времени — в event_time должны быть секунды, внутри fbc — миллисекунды.
Связать событие с рекламой могут помешать настройки приватности браузера. В Safari и во встроенных браузерах на движке Apple за это отвечает Intelligent Tracking Prevention — защита от отслеживания между сайтами. Если юзер семь дней пользовался браузером и за это время никак не взаимодействовал с вашим сайтом, браузер может снести куки, которые поставил скрипт на ленде.
А иногда Safari режет срок жизни куки вообще до суток. Допустим, юзер пришел с домена, который Safari пометил как трекер, а в ссылке на ленд осталась метка вроде fbclid (ID клика по рекламе Meta*). Вот тогда под жесткий лимит попадают куки, которые поставил скрипт на ленде.
С серверными куки отдельная история. Если за вашим поддоменом на самом деле стоит сторонний трекер и браузер это распознал, куки из ответа этого сервера проживут максимум семь дней.
На реальном заливе это выглядит так: человек кликнул с айфона по вашей похудалке во вторник вечером, оставил вкладку открытой и оформил заявку только в четверг утром. Сутки давно вышли, и Safari мог уже стереть рекламную куку. Тогда у браузерного пикселя не будет сохраненного ID клика для этого лида.
А вот если Safari уже снес куку с ID клика и вы нигде его не сохранили, CAPI сам этот ID не вернет. Заявка может доехать до Meta*, но привязать ее к объяве будет сложнее.
Бывает, что постбэк до Meta* доехал, а про клиента в нем почти ничего не написано. С таким набором данных оценка Event Match Quality (EMQ) может заметно просесть.
При этом многие передают в Meta* только сам факт конверсии и метку fbc в надежде, что остальное алгоритм подтянет сам. Но если кликовая метка срезается на редиректах, лид будет безымянным. Выручить могла бы браузерная кука _fbp формата fb.1.{timestamp}.{random}, однако ее часто забывают забрать с лендинга и пробросить в трекер для поля fbp.
Еще одна ошибка — подмена данных пользователя. Вместо сохраненных в момент клика client_ip_address и client_user_agent живого покупателя скрипт берет IP прилетевшего от партнерки постбэка. В итоге для алгоритма все ваши покупатели выходят в сеть с одного серверного хостинга. Если к тому же телефон и почта из формы заказа не хешируются по SHA-256 и не отправляются в CAPI вместе с external_id, у Meta* будет меньше данных, чтобы сопоставить лид с профилем.
Данные клиента в запросе CAPI — идентификатор браузера fbp, IP-адрес и User-Agent
Представим, что вы оставляете браузерный пиксель на странице «Спасибо» и параллельно шлете тот же лид серверным постбэком из трекера. Если не настроить между ними дедупликацию, кабинет засчитает одного клиента дважды, обучится на дублях и быстро сольет бюджет.
Для дедупликации в Meta* вообще не нужно идеальное совпадение двух запросов. По правилам склейки пикселя и CAPI кабинет в течение 48 часов смотрит только на пару полей. У каждого события свой event_id. Если отправляете одно и то же событие через пиксель и CAPI, в обеих отправках должны совпадать ID и название события. Правда, сбить настройку может даже одна строчная буква. Пришлете из браузера Purchase, а с сервера purchase, и кабинет раздвоит вам конверсию.
На ленде оставляете пиксель. Как только человек отправит заявку, пиксель пошлет ее в Meta* из браузера, а трекер — с сервера через CAPI. Если она не доехала из браузера, то все равно может прийти с сервера. Прилетели обе копии? Meta* сама удалит дубль по правилам выше.
Пример с Reddit: в Shopify за день было 6 покупок, а в Ads Manager — 10. По словам автора, поддержка Meta* подтвердила сбой дедупликации. События Purchase из пикселя и CAPI приходили с разными event_id, поэтому Meta* не могла склеить их как одну покупку. По словам автора, в отчете также были смоделированные конверсии.
Meta* может засчитать конверсию после показа рекламы. Если человек не кликал по объявлению, у трекера не будет рекламного перехода, с которым можно связать эту конверсию. Поэтому с трекером сначала сверяйте конверсии по кликам. В Ads Manager смотрите 1-day click и 7-day click отдельно. Складывать их не надо, поскольку одна и та же заявка может попасть в обе колонки. Конверсии за сутки после показа (1-day view) чекайте отдельно от сверки с трекером. В эту колонку может попасть заявка от человека, который увидел рекламу, не кликнул по ней, но в течение суток сам зашел на сайт и оставил заявку.
Сверяете цифры по дням? Тогда чекайте, на какую дату каждый отчет ставит конверсию. Клик мог быть 5-го числа, а постбэк прийти 7-го. В трекере по дате клика покажет эту конверсию за 5-е, а отчет по дате получения постбэка покажет ее за 7-е. Перед сверкой проверьте, к какой дате относит конверсию выбранный отчет Meta*: дата самой покупки и дата получения постбэка могут различаться.
Перед масштабированием связки обязательно пробегитесь по кабинету Meta* и сверьте данные с логами трекера. Лучше уж заранее найти, где теряются события, потому что при большом бюджете ваше расследование обойдется гораздо дороже.
В первую очередь открываем логи трекера. Там смотрим, ушли ли постбэки и что на них ответил CAPI.
Прогоните живой тест через вкладку Test Events. Перед запуском трафика возьмите в блоке Confirm your server's events are set up correctly проверочный код test_event_code и временно вставьте его в настройки CAPI внутри трекера или своего скрипта.
Потом откройте свою рекламную ссылку с параметром fbclid, оставьте тестовую заявку и посмотрите, что прилетит в кабинет. Если конверсию шлют и пиксель, и сервер, первое событие пройдет со статусом Processed, а дубль получит плашку Deduplicated. Если же лиды вы передаете только по CAPI из трекера, от браузера отобразится один PageView, а сам Lead придет с пометкой Server и списком распознанных параметров. Чекнули, что серверные события прилетают в Test Events? Убирайте test_event_code из рабочих запросов CAPI. Meta* рекомендует передавать этот код только во время проверки.
Чекайте Event Match Quality (EMQ) и то, какие параметры доходят вместе с событиями. Откройте Events Manager → Data Sources, выберите нужный пиксель (Dataset). Во вкладке Overview разверните целевое событие — Lead, CompleteRegistration или Purchase — и нажмите View Details.
Во вкладке Event Match Quality посмотрите оценку от 0 до 10 и процент заполнения параметров. Проверьте, передаются ли Click ID (fbc) для переходов с соответствующей меткой и Browser ID (fbp), а также Client IP Address и User Agent. В последних двух должны быть реальные данные юзеров. Если у всех покупателей один IP вашего VPS, поздравляем — по вашим данным весь оффер выкупил сервер.
Сверьте баланс Browser / Server и ключи дедупликации. Нажмите View Details, откройте вкладку Event Overview и посмотрите, сколько событий приходит из браузера, а сколько с сервера. Если у вас включены оба источника, небольшая разбежка в цифрах погоды не делает, но резкое падение одного из графиков лучше сразу разобрать. А если со стороны сервера вообще тишина, постбэки до кабинета просто не долетают и пора открывать логи отправки CAPI.
Затем перейдите во вкладку Event Deduplication и найдите в блоке Deduplication Keys строку Event ID. По ней сразу разберетесь, передают ли ключ пиксель с CAPI и сколько событий реально склеивается в столбце Overlap. В хорошем раскладе оба источника должны присылать на одну конверсию одинаковое название события и общий ID. Иначе одна покупка превратится в две, что выглядит красиво ровно до первой сверки с партнеркой.
Сравнивайте статистику трекера и Ads Manager в одинаковых окнах. В таблице кампаний откройте меню Columns, выберите Compare attribution settings и отметьте столбцы 1-day click, 7-day click и 1-day view, а заодно чекните, какое окно выставлено внутри самого адсета.
Откройте в трекере и Ads Manager одну и ту же кампанию за одни и те же даты (часовой пояс тоже должен совпадать). Если событие уходит в Meta* сразу после заявки, берите для сверки число заявок в трекере. Если отправляете событие после подтверждения в партнерке — число апрувов.
* — принадлежит компании Meta, признанной экстремистской и запрещенной на территории РФ.
Написать в Telegram 
сайт 
0 
Удалось как то налить им, 900~ фтд где-то вышло. До сих пор даже капает. Может чуть позже еще вернусь снова по ревшаре полить, а то в кейсах у коллег уж больно сладкие RD, надо проверить.
Ребята аффы написали вчера говорят вернуться траф дать)) ну отзыв попросили оставить, мне в целом не сложно, но вот как есть)