Налаштування пікселя Facebook на 1С-Bitrix
Піксель Facebook не працює «із коробки» на Bitrix — це не складність коду, а те, що стандартний механізм підключення скриптів конфліктує з кешуванням та моделлю подій. Базовий код пікселя вставляють у шапку через header.php або через настройки сайту, але без передачі подій це просто лічильник відвідувань, не більше.
Де живе базовий код та чому там проблеми
Шаблон сайту у Bitrix зберігає 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 — проблемніше. Додавання в кошик у Bitrix іде через AJAX-запит до sale.basket.basket або безпосередньо через CSaleBasket::Add(). Подія пікселя потрібна у колбеку JS після успішної відповіді. У ядрі Bitrix за додавання в кошик відповідає подія 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 з токеном доступу.
У Bitrix це реалізується через CURLFile або стандартний \Bitrix\Main\Web\HttpClient. Вішаєте обробник на подію OnSaleOrderSaved та відправляєте Purchase з хешованим email (sha256) та event_id для дедублікації з браузерною подією.
Модуль bitrix.main версії 22+ включає \Bitrix\Main\Web\HttpClient — використовуйте його, а не file_get_contents, щоб не залежати від конфігурації allow_url_fopen.
Перевірка роботоспроможності
Після налаштування перевіряйте через Facebook Pixel Helper (розширення Chrome) та через Events Manager у кабінету Facebook — вкладка «Тестування подій». У тестовому режимі Conversions API видно реальний розбір payload з помилками валідації.
Типова проблема: подія дублюється двічі — браузерна та серверна приходять без event_id. Без дедублікації Facebook вважає їх двома різними конверсіями. event_id повинен бути одинаковим у JS-виклику fbq('track', 'Purchase', data, {eventID: 'order_123'}) та у серверному запиті.