Не работает пиксель Facebook: почему нет событий и что делать

Если пиксель Facebook не показывает события, проверьте по порядку три вещи: загружается ли пиксель на странице (расширение Meta Ads Data Advisor, бывший Pixel Helper), доходят ли события до Meta (вкладка «Тестовые события» в Events Manager) и что пишет вкладка «Диагностика». Чаще всего виноваты блокировщик или запрет cookie у посетителя, чужой ID пикселя в коде, событие не на той странице, новый домен вне списка разрешённых и данные, которые Meta режет по своим правилам.

Если события есть, но их больше или меньше, чем лидов в трекере, дело обычно в дублях и потерях: Lead срабатывает при обновлении страницы «спасибо», на странице стоят два пикселя, а пиксель и Conversions API шлют одно событие без общего ID. Ниже порядок проверки, таблица причин и код, который мы прогнали в браузере перед публикацией.

Обновлено 1 октября 2026. В первой версии статьи (2024 год) была схема с двойной отправкой пикселя. В ней нашлись ошибки, разбор в конце статьи.

Как проверить пиксель за 10 минут

1. Data Advisor в Chrome. Расширение Meta Pixel Helper теперь называется Meta Ads Data Advisor и обновляется само. Отключите свой блокировщик рекламы на проверяемом сайте, откройте страницу и нажмите на значок расширения. Видно, какие пиксели найдены и какие события ушли. Статусы пикселя: Active (работает), Warning (настроен с ошибкой), Inactive (не отправляет события). У события есть ещё статус Error: например, заблокированные параметры или дубли. Для проверки входить в Facebook не нужно.
2. Тестовые события. Events Manager → «Источники данных» → ваш пиксель → вкладка «Тестовые события». Откройте сайт, пройдите путь до заявки и смотрите, какие события приходят. Если событие не появилось в течение минуты, Meta советует проверить интернет, отключить блокировщики, обновить страницу и попробовать другой браузер: поддерживаются не все.
3. Диагностика. На этой вкладке Meta показывает проблемы за последние 24 часа: красные критичные и жёлтые предупреждения. Если три дня ничего с проблемой не делать, она уходит в «Ранее обнаруженные», и инструкция по исправлению пропадает. Расшифровка сообщений есть в справке по ошибкам пикселя.

Только что поставленный пиксель показывает первый PageView не сразу. В документации Meta советует подождать несколько минут и обновить Events Manager, а базовый код ставить внутрь <head> на каждой странице: так браузеру и чужим скриптам сложнее его заблокировать, и он успевает сработать до ухода посетителя.

Почему пиксель не отправляет события

Последняя строка частая у нутры и финансовых офферов. В базовой настройке Meta не принимает пользовательские параметры и обрезает адрес до домена: https://site.com/diabet/?item=10 превращается в https://site.com/. Включить её может сама Meta, если отнесла источник к ограниченной категории или несколько раз находила в событиях запрещённые данные. С 2 сентября 2025 Meta ещё и не даёт запускать кампании на пользовательских конверсиях, которые указывают на болезнь или финансовое положение (в примерах Meta это «arthritis» и «high income»).

Со списком разрешённых доменов есть подвох. Meta сама советует его включать: ID пикселя виден в коде страницы, и кто угодно может поставить ваш пиксель к себе на сайт. Но каждый новый лендинг тогда нужно добавлять в список до запуска трафика, иначе его события просто не дойдут.

Пиксель передали в другой бизнес-портфель, а он не появился

Передача пикселя другой компании не срабатывает сразу. По справке Meta отправитель указывает тип отношений с получателем и заново принимает условия Business Tools, а получатель должен согласиться на запрос. Пока он этого не сделал, пиксель висит в ожидании. Статус видно в Meta Business Suite: «Настройки» → «Источники данных» → «Наборы данных и пиксели» → «Партнёры».

Что ещё проверить, если пиксель «не принялся»:

• Передаёт тот, у кого полный доступ к бизнес-портфелю, которому принадлежит пиксель. Партнёр даже с полным доступом не может передать пиксель дальше, это делает только владелец.
• Нужен ID бизнес-портфеля получателя, а не ID рекламного аккаунта. Для набора данных путь такой: «Настройки» → «Источники данных» → «Наборы данных» → «Назначить партнёров».
• У нового бизнес-портфеля или аккаунта часть функций может быть ещё закрыта. Что доступно, Meta показывает в Business Support Home.

Почему лидов в Facebook больше или меньше, чем в трекере

Сначала убедитесь, что сравниваете одно и то же. Events Manager показывает почти все полученные события, а Ads Manager только те, что Meta приписала рекламе. Поэтому в кабинете событий обычно меньше, чем в Events Manager, и это не поломка.

В Facebook больше лидов: ищем дубли

• Lead при каждом открытии страницы «спасибо». Человек обновил страницу или вернулся на неё, событие ушло ещё раз. Лечится защитой на один клик, она есть в коде ниже. Как сделать саму страницу, мы разбирали в статье про мультиязычную страницу «Спасибо за заказ».
• Два пикселя на странице. Вызов fbq('track') отправляет событие во все пиксели, которые инициализированы на странице. Meta показывает это на примере, где событие для второго пикселя попадает и в первый. Для одного пикселя есть fbq('trackSingle', 'ID', 'Lead').
• Событие и в коде, и в автособытиях. «Диагностика» тогда пишет Duplicate events detected. С 3 августа 2026 у пикселей, которые добавляют в бизнес-портфель, автособытия включены по умолчанию: ИИ Meta сам находит на сайте лиды и покупки и добавляет их как стандартные события. Где это выключить, мы писали в статье про ИИ-пиксель Meta.
• Несколько событий на одно действие. Код события стоит в общем шаблоне сайта, и Lead уходит с каждой страницы. Meta называет это ошибкой Multiple events on an action: в шаблоне должен быть только базовый код с PageView.
• Пиксель и Conversions API без общего ID. Meta склеивает браузерное и серверное событие, если у них совпадают название и ID: eventID у пикселя и event_id у Conversions API. Дубль, пришедший позже, отбрасывается, если он пришёл в течение 48 часов. Без ID каждый лид считается дважды.

В Facebook меньше лидов: ищем потери

• Браузер не дал пикселю сработать. Блокировщик, запрет cookie, вкладку закрыли до загрузки страницы «спасибо». Пиксель это не исправит. Для этого Meta советует отправлять те же события и через Conversions API: сервер передаёт события, которые пиксель теряет из-за сети и ошибок загрузки.
• До страницы с Lead не доходят. Форма отправляется без перехода, а событие висит на странице, которую человек не открывает. Тогда Lead нужно вызвать после успешной отправки формы.
• Meta отсекла данные. Заблокированные параметры, базовая настройка, домен вне списка разрешённых: всё это видно в «Диагностике».
• Ошибка в коде. Пример ниже, в разборе старой схемы.

Пиксель и Conversions API: рабочая схема 2026 года

Meta рекомендует отправлять одни и те же события двумя путями: пикселем из браузера и через Conversions API с сервера, и склеивать их по ID события. У пикселя ID передаётся четвёртым аргументом: fbq('track', 'Lead', {}, {eventID: 'ID'}). У картинки-пикселя без JavaScript это параметр eid в адресе. Для лидов удобно брать subid клика из трекера: он есть и на лендинге, и в постбэке партнёрской сети.

Этот пример не содержит механизма управления согласием посетителя. Свяжите загрузку и отправку событий с уже настроенной логикой согласий сайта; серверная отправка не должна игнорировать выбранные пользователем ограничения. Код ниже ставится в <head> всех страниц лендинга. ID пикселя и subid он берёт из адреса (в Keitaro это макросы, например ?pxl=123456789012345&subid={subid}) и запоминает до конца сессии во вкладке. Если пиксель у лендинга один, вместо keep('pxl', …) можно вписать ID строкой.

<!-- Meta Pixel: на всех страницах лендинга, внутри <head> -->
<script>
!function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};if(!f._fbq)f._fbq=n;
n.push=n;n.loaded=!0;n.version='2.0';n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)}(window,
document,'script','https://connect.facebook.net/en_US/fbevents.js');

(function () {
  // трекер передаёт в адресе лендинга ?pxl=ID_ПИКСЕЛЯ&subid=ID_КЛИКА
  var q = new URLSearchParams(location.search);
  function keep(name, re) {
    var v = q.get(name);
    if (v && !re.test(v)) v = null;            // мусор и подставные значения отбрасываем
    try {
      if (v) sessionStorage.setItem('fb_' + name, v);
      return v || sessionStorage.getItem('fb_' + name);
    } catch (e) {
      return v;
    }
  }
  var pixel = keep('pxl', /^\d{5,20}$/);
  var subid = keep('subid', /^[\w.-]{1,64}$/);
  if (!pixel) return;
  fbq('init', pixel);
  fbq('track', 'PageView');

  // Lead один раз на клик: обновление страницы «спасибо» не даст второе событие
  window.fbLead = function () {
    if (!subid) return;
    var key = 'fb_lead_' + subid;
    try {
      if (localStorage.getItem(key)) return;
      localStorage.setItem(key, '1');
    } catch (e) {}
    fbq('track', 'Lead', {}, { eventID: subid });
  };
})();
</script>

На странице «спасибо» перед закрывающим </body> добавляется одна строка:

<!-- страница «спасибо», перед </body> -->
<script>window.fbLead && fbLead();</script>

Перед публикацией мы открыли обе страницы в Chromium с настоящим fbevents.js и перехватили запросы к facebook.com/tr. Ушли PageView на лендинге, PageView и Lead с eid=subid на странице «спасибо». После обновления страницы второго Lead не было. С подставным значением в pxl пиксель не запускается вовсе.

Серверная половина схемы, постбэк из Keitaro в Conversions API с тем же subid в event_id, разобрана в статье про Keitaro и Facebook Conversions API. Там же скрипт и проверка через тестовые события. Учтите одно: события с test_event_code Meta не отбрасывает, они попадают в статистику как обычные. После проверки тестовый код нужно убрать.

Что было не так в схеме из первой версии статьи

Статья появилась в 2024 году, когда пиксель у нас начал вести себя странно: при 10 лидах в Кейтаро Facebook показывал то 15, то 4-5, и байеры теряли автоправила. Тогда мы предложили отправлять Lead дважды: с сервера из api.php и картинкой на странице success.php, а в октябре 2024 добавили вариант на sessionStorage. Если что-то из этого у вас стоит, вот что в нём не так.

• Запрос к facebook.com/tr с сервера. Это адрес браузерного пикселя. Запрос через curl уходил с IP и User-Agent сервера и без cookie посетителя, то есть Meta получала событие не от того человека. Для отправки с сервера у Meta есть Conversions API.
• Параметр event_id в адресе картинки. По документации ID события у картинки-пикселя передаётся в eid. Параметр event_id в адресе Meta не описывает, поэтому склейки двух отправок ждать не стоило: один лид мог посчитаться дважды.
• Уязвимость в success.php. Страница выводила pxl и event_id из адреса без экранирования. Мы проверили: со ссылкой вида success.php?pxl="><script>… страница вставляет в себя чужой скрипт.
• Вариант на sessionStorage падал с ошибкой. Код стоял в <head> и вызывал document.body.appendChild, а body в этот момент ещё нет. В Chromium запрос всё равно уходит, потому что картинка начинает грузиться сразу, но скрипт падает с ошибкой «Cannot read properties of null». Картинка при этом не попадает на страницу, а Meta предупреждает, что такой пиксель без дополнительного кода не доходит в сценарии для iOS 14.5 и новее. К тому же событие уходило без ID и повторялось при каждом обновлении страницы.

Код из раздела выше эти проблемы закрывает. Старые файлы api.php и success.php с отправкой пикселя лучше убрать с сервера целиком.

Отдельно сверяйте анонс Meta о конверсиях на устройстве с 12 ноября. Он не означает, что функция уже доступна каждому аккаунту, и не отменяет проверку событий и дедупликации.

Частые вопросы