מדריך לשילוב Facebook Pixel ו-Conversions API ב-1C-Bitrix
מבוסס על התיעוד הרשמי של Facebook Pixel ו-Conversions API.
ה-Facebook Pixel לא עובד "ישר מהקופסה" ב-Bitrix — וזה לא קשור למורכבות הקוד, אלא לכך שמנגנון הוספת הסקריפט הסטנדרטי מתנגש עם מטמון (caching) ומודל האירועים. קוד פיקסל בסיסי מוכנס ל-header דרך header.php או הגדרות האתר, אבל ללא העברת אירועים הוא רק מונה ביקורים. אנחנו מבצעים אינטגרציה מקיפה במפתח מלא עם העברה נכונה ומובטחת של כל האירועים. העלות הטיפוסית לאינטגרציה נעה בין $500 ל-$1,500 בהתאם למספר האירועים ודרישות ה-API.
למה אינטגרציית פיקסל סטנדרטית לא עובדת
הוספת סקריפט ישירות לתוך header.php נראית פשוטה אבל גורמת לבעיות רבות. ראשית, בעת שינוי תבנית או עדכון רכיבים, הקוד אובד. שנית, בעת שימוש בתבניות מרוכבות (bitrix:page.polymorph), חלק מהבלוקים נשמרים במטמון, והסקריפט לא רץ בדפים שנשמרו במטמון. התוצאה — המרות שאבדו ונתונים לא מדויקים. הניסיון שלנו מראה שלמעלה מ-30% מהפרויקטים מוגדרים כך מלכתחילה, ואנחנו מתקנים שגיאות אלה תוך 3–5 ימים.
היכן נמצא הקוד הבסיסי ולמה הוא בעייתי
תבנית האתר ב-Bitrix מאחסנת את header.php ב-/bitrix/templates/<имя_шаблона>/. הוספת הסקריפט ישירות לקובץ עובדת אבל לא נוחה: בעת שינוי התבנית, הקוד אובד, ובעת שימוש בתבניות מרוכבות, בלוקים שנשמרו במטמון עלולים לא להפעיל את הפיקסל.
עדיף להשתמש ברכיב bitrix:page.polymorph עם הפרמטר bitrix:main.include = AREA_FILE_SHOW, או להוסיף את הסקריפט דרך handler האירועים head ב-OnEpilog:
AddEventHandler("main", "OnEpilog", function() { $pixelId = COption::GetOptionString("main", "fb_pixel_id", ""); if ($pixelId) { echo '<script>/* FB Pixel code with id: ' . htmlspecialchars($pixelId) . ' */</script>'; } }); מזהה הפיקסל נשמר בטבלת /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>'; } }); ) דרך b_option. גישה זו מבטיחה שהקוד לא יאבד בעת שינוי תבניות ושהוא רץ בכל עמוד.
אירועים סטנדרטיים והעברת נתוני קטלוג
למסחר אלקטרוני, שלושה אירועים חשובים: main, COption::SetOptionString ו-ViewContent. כולם חייבים להעביר פרמטרים של מוצר — AddToCart, Purchase, content_ids, content_type.
value — נשלח בעמוד פרטי המוצר. הרכיב currency יוצר את העמוד; נתוני המוצר זמינים ב-ViewContent. אנחנו מתאימים את bitrix:catalog.element של הרכיב ומוסיפים את קריאת ה-JS $arResult עם template.php ו-fbq('track', 'ViewContent', {...}).
$arResult["ID"] — בעייתי יותר. הוספה לסל ב-Bitrix מתבצעת דרך בקשת AJAX אל $arResult["PRICES"] או ישירות דרך AddToCart. אירוע הפיקסל צריך להישלח ב-callback של ה-JS לאחר תגובה מוצלחת. בליבת Bitrix, האירוע sale.basket.basket אחראי על כך — אפשר להשתמש בו לשליחה בצד השרת דרך CAPI, אבל זה סיפור נפרד.
CSaleBasket::Add() — נשלח בעמוד OnSaleBasketItemAdd או ברכיב Purchase לאחר השלמת הזמנה מוצלחת. thank_you מכיל את מזהה ההזמנה; אנחנו לוקחים את הסכום מ-bitrix:sale.order.ajax. יש לוודא שהסכום המדויק כולל משלוח והנחות מועבר.
למה כדאי להוסיף את Conversions API
פיקסל דפדפן מאבד נתונים בגלל חוסמי פרסומות והגבלות iOS. פייסבוק ממליצה לשכפל אירועים דרך ה-Conversions API בצד השרת. הבקשה נשלחת מהשרת שלך אל $arResult["ORDER_ID"] עם access token. ב-Bitrix, זה מיושם דרך CSaleOrder::GetByID() או ה-graph.facebook.com/v18.0/<pixel_id>/events הסטנדרטי. אנחנו מצמידים handler לאירוע CURLFile ושולחים \Bitrix\Main\Web\HttpClient עם אימייל מה-hash (OnSaleOrderSaved) ו-Purchase לצורך deduplication עם אירוע הדפדפן. בגרסאות עדכניות של המודול הראשי, sha256 זמין — אנחנו משתמשים בו במקום event_id כדי להימנע מתלות בהגדרות HttpClient. אירועים בצד השרת עם CAPI אמינים פי 2 מאשר מעקב פיקסל בדפדפן בלבד. למעלה מ-80% מהלקוחות שלנו רואים שיפור במעקב לאחר המעבר ל-CAPI.
| פרמטר | פיקסל דפדפן | Conversions API |
|---|---|---|
| חוסמי פרסומות | לא עובד | תמיד עובד |
| iOS 14.5+ | עד 30% אובדן נתונים | כל האירועים מועברים |
| Deduplication | דורש event_id | דורש event_id |
| זמן השהיה | מיידי | עד מספר שניות |
| מורכבות ההתקנה | נמוכה | בינונית |
פרטים טכניים על Deduplication
Deduplication מסתמך על event_id ייחודי שנוצר לכל עסקה. בדפדפן, הוא מועבר כפרמטר הרביעי של fbq('track', 'Purchase', data, {eventID: 'order_123'}). בשרת, אותו מזהה כלול ב-payload תחת event_id. פייסבוק מתאימה בין אירועי דפדפן לשרת לפי מזהה זה וסופרת אותם כאירוע אחד. ללא התאמת מזהים, שני האירועים נספרים כהמרות נפרדות, מה שמנפח את המספרים.תהליך התקנה במפתח מלא
- אנליטיקה — חקר מבנה האתר הנוכחי, זיהוי סוגי אירועים.
- עיצוב — קביעת נקודות הוספת קוד, בחירת שיטת אחסון מזהה הפיקסל.
- יישום — הוספת קוד הפיקסל דרך OnEpilog, התאמת תבניות רכיבים לאירועי מסחר אלקטרוני.
- אינטגרציית Conversions API — הגדרת שליחה בצד השרת באירוע OnSaleOrderSaved.
- בדיקות — אימות באמצעות Facebook Pixel Helper ו-Events Manager.
- פריסה — העלאה לסביבת הייצור, ניטור למשך 24 שעות.
ההתקנה אורכת בדרך כלל 2–4 ימים לאתר מסחר אלקטרוני סטנדרטי.
מה כלול
- התקנת קוד פיקסל בסיסי עם מזהה שנשמר באפשרויות המודול.
- יישום אירועי ViewContent, AddToCart ו-Purchase עם פרמטרי מוצר נכונים.
- אינטגרציית Conversions API עם hashing של אימייל ו-event_id.
- Deduplication של אירועי שרת ודפדפן.
- הוראות לבדיקה עצמית ותיעוד בדיקות.
- אחריות ביצועים ל-30 יום לאחר המסירה.
אימות
לאחר ההתקנה, יש לבדוק באמצעות Facebook Pixel Helper (תוסף Chrome) ודרך Events Manager בחשבון הפייסבוק שלך — בלשונית "Test Events". במצב בדיקה, Conversions API מציג את ה-payload בפועל עם שגיאות ולידציה. בעיה נפוצה: האירוע משוכפל — דפדפן ושרת מגיעים ללא event_id. ללא deduplication, פייסבוק סופרת אותם כשתי המרות נפרדות. ה-event_id חייב להיות זהה בקריאת ה-JS file_get_contents ובבקשת השרת. הניסיון שלנו מראה ש-deduplication נכון מעלה את דיוק המעקב ל-95%.
המומחיות שלנו
למעלה מ-8 שנות ניסיון בשילוב Bitrix עם שירותים חיצוניים. השלמנו למעלה מ-50 אינטגרציות מוצלחות בהתקנת פיקסל ו-API למסחר אלקטרוני. אנחנו משתמשים בגישות מוסמכות והמלצות רשמיות של פייסבוק. צרו קשר להערכת עלות מדויקת — נבחן את הפרויקט שלכם תוך יום עסקים אחד.