Настройка пикселя Facebook и Conversions API на 1С-Битрикс
Пиксель Facebook не работает «из коробки» на Битриксе — и дело не в сложности кода, а в том, что стандартный механизм подключения скриптов конфликтует с кешированием и событийной моделью. Базовый код пикселя вставляют в шапку через header.php или через настройки сайта, но без передачи событий это просто счётчик посещений, не более. Мы выполняем комплексную интеграцию под ключ с гарантией корректной передачи всех событий.
Почему стандартное подключение пикселя не работает?
Прямая вставка скрипта в header.php кажется простым решением, но рождает массу проблем. Во-первых, при смене шаблона или обновлении компонентов код теряется. Во-вторых, при использовании составных шаблонов (bitrix:page.polymorph) часть блоков кешируется, и скрипт не выполняется на закешированных страницах. В результате — пропущенные конверсии и неверные данные. Наш опыт показывает, что более 30% проектов первично настроены именно так, и мы исправляем эти ошибки за 3-5 дней.
Где живёт базовый код и почему там проблемы
Шаблон сайта в Битриксе хранит header.php в /bitrix/templates/<имя_шаблона>/. Вставка скрипта напрямую в файл — рабочий вариант, но неудобный: при смене шаблона код теряется, а при использовании составных шаблонов (bitrix:page.polymorph) часть блоков кешируется и пиксель может не срабатывать на закешированных страницах.
Правильнее использовать компонент bitrix:main.include с установленным параметром AREA_FILE_SHOW = head, или подключать скрипт через обработчик события OnEpilog в файле /bitrix/php_interface/init.php:
AddEventHandler("main", "OnEpilog", function() {
$pixelId = COption::GetOptionString("main", "fb_pixel_id", "");
if ($pixelId) {
echo '<script>/* FB Pixel code with id: ' . htmlspecialchars($pixelId) . ' */</script>';
}
});
ID пикселя при этом хранится в таблице b_option (модуль main), через COption::SetOptionString. Такой подход гарантирует, что код не потеряется при смене шаблона и выполняется на каждой странице.
Стандартные события и передача данных каталога
Для e-commerce важны три события: ViewContent, AddToCart, Purchase. Все они должны передавать параметры товара — content_ids, content_type, value, currency.
ViewContent — вызывается на странице детального просмотра товара. Компонент bitrix:catalog.element генерирует страницу, данные товара доступны в $arResult. Кастомизируете template.php компонента и добавляете JS-вызов fbq('track', 'ViewContent', {...}) с подстановкой $arResult["ID"] и $arResult["PRICES"].
AddToCart — проблемнее. Добавление в корзину в Битриксе идёт через AJAX-запрос к sale.basket.basket или напрямую через CSaleBasket::Add(). Событие пикселя нужно стрелять в колбэке JS после успешного ответа. В ядре Битрикса за добавление в корзину отвечает событие OnSaleBasketItemAdd — его можно использовать для серверной передачи через Conversions API, но это отдельная история.
Purchase — срабатывает на странице thank_you или в компоненте bitrix:sale.order.ajax после успешного оформления. В $arResult["ORDER_ID"] есть ID заказа, сумму берёте из CSaleOrder::GetByID(). Убедитесь, что передаётся точная сумма с учётом доставки и скидок.
Почему стоит подключить Conversions API?
Браузерный пиксель теряет данные из-за блокировщиков рекламы и iOS-ограничений. Facebook рекомендует дублировать события через серверный Conversions API. Запрос уходит с вашего сервера на graph.facebook.com/v18.0/<pixel_id>/events с токеном доступа. На Битриксе это реализуется через CURLFile или стандартный \Bitrix\Main\Web\HttpClient. Вешаете обработчик на событие OnSaleOrderSaved и отправляете Purchase с хешированным email (sha256) и event_id для дедупликации с браузерным событием. В актуальных версиях модуля main доступен HttpClient — используйте его, а не file_get_contents, чтобы не зависеть от конфигурации allow_url_fopen.
| Параметр | Браузерный пиксель | Conversions API |
|---|---|---|
| Блокировщики рекламы | Не работает | Работает всегда |
| iOS 14.5+ | Потеря данных до 30% | Все события передаются |
| Дедупликация | Требует event_id | Требует event_id |
| Задержка | Мгновенно | До нескольких секунд |
| Сложность настройки | Низкая | Средняя |
Процесс настройки под ключ
- Аналитика — изучение текущей структуры сайта, выявление типов событий.
- Проектирование — определение мест вставки кода, выбор способа хранения ID пикселя.
- Реализация — добавление кода пикселя через OnEpilog, кастомизация шаблонов компонентов для e-commerce событий.
- Интеграция Conversions API — настройка серверной отправки на событие OnSaleOrderSaved.
- Тестирование — проверка через Facebook Pixel Helper и Events Manager.
- Деплой — выкатка на боевой сервер, мониторинг в течение 24 часов.
Что входит в работу
- Настройка базового кода пикселя с хранением ID в опциях модуля.
- Внедрение событий ViewContent, AddToCart, Purchase с корректными параметрами товара.
- Интеграция Conversions API с хешированием email и event_id.
- Дедупликация серверных и браузерных событий.
- Инструкция по самостоятельной проверке и тестовая документация.
- Гарантия работоспособности в течение 30 дней после сдачи.
Проверка работоспособности
После настройки проверяйте через Facebook Pixel Helper (расширение Chrome) и через Events Manager в кабинете Facebook — вкладка «Тестирование событий». В тестовом режиме Conversions API видно реальный разбор payload с ошибками валидации. Типичная проблема: событие дублируется дважды — браузерное и серверное приходят без event_id. Без дедупликации Facebook считает их двумя разными конверсиями. event_id должен быть одинаковым в JS-вызове fbq('track', 'Purchase', data, {eventID: 'order_123'}) и в серверном запросе. Наш опыт показывает, что грамотная дедупликация повышает точность отслеживания до 95%.
Наши компетенции
Более 8 лет опыта интеграции Битрикс с внешними сервисами. Свыше 50 проектов по настройке пикселя и API для e-commerce. Используем сертифицированные подходы и официальные рекомендации Facebook. Свяжитесь с нами для расчёта точной стоимости — оценим ваш проект за один рабочий день.