אינטגרציה של Bitrix24 עם Google Analytics: העברת המרות לא מקוונות

המרות אופליין לא מגיעות לאנליטיקה: היכן נשברת השרשרת

לרוב השרשרת נשברת לא בשלב ההגדרה, אלא בשלב ההתאמה: ב-CRM יש עסקה, באנליטיקה — ביקור, וביניהם אין מזהה משותף. הלקוח הגיע ממודעה, השאיר פנייה, המנהל פתח עסקה ידנית כעבור יום — וזהו, השרשרת נקטעה. Google Analytics רואה רק סשן ללא תוצאה, ו-Битрикс24 — תוצאה ללא מקור. בדוחות לפי ערוצים עסקאות כאלה שוקעות ב"כניסות ישירות" או לא נספרות כלל.

הקרע השני — זמני. המרת אופליין מטבעה מפגרת אחרי הביקור: שיחה מטופלת כעבור שעה, עסקה נסגרת כעבור שבוע, תשלום — כעבור חודש. עד שהאירוע מגיע לאנליטיקה, חלון הייחוס כבר סגור, והמערכת רושמת את ההמרה לערוץ הלא נכון. הדבר בולט במיוחד בעסקאות ארוכות ב-B2B, שבהן בין המגע הראשון לתשלום חולפים חודשים ומספר מגעים.

המקור השלישי לעיוותים — סטטוסים ידניים. אם המשפך ב-Битрикс24 לא מקושר באופן נוקשה לשלבים "מוסמך, מאושר, שולם", והמנהלים מזיזים כרטיסים לפי שיקול דעתם, לאנליטיקה מגיעה לא עובדת המכירה אלא הערכה סובייקטיבית.

אנליטיקה מקצה-לקצה מתחילה לספור כהמרה משהו שאינו כזה, והערוצים מקבלים ייחוס שגוי — התקציב הולך למקום שבו יש הרבה פניות אבל אין כסף.

השכבה הרביעית — טכנית: מזהה הקליק (gclid, client_id) לא נשמר בעסקה, ובלעדיו Google Analytics לא יכול לתפור אירוע אופליין לביקור ספציפי.

האינטגרציה Битрикс24 Google Analytics בנקודה הזו דורשת לא תוסף, אלא משמעת של העברת מזהים מהטופס ל-CRM ושליחה חוזרת של סטטוסים דרך Measurement Protocol. בואו נפרק איך זה נסגר.

מה נותן החיבור: השפעות מדידות למחלקת המכירות

כאשר עסקה מה-CRM נכנסת לניתוח כהמרה לא מקוונת, מחלקת המכירות מפסיקה לעבוד באופן עיוור. בעבר מסלול הלקוח נקטע בפנייה: הטופס נשלח, אך מה קרה איתו בהמשך — האם העסקה נסגרה או לא — הניתוח לא ידע.

כעת כל עסקה סגורה חוזרת לדיווח עם שיוך למקור, לקמפיין ולשאילתת המפתח, וההחלטות מתקבלות לפי כסף בפועל, ולא לפי מספר הקליקים.

ייחוס עסקאות משנה את תמונת הערוצים. ערוץ שסיפק הרבה פניות זולות, אך כמעט לא הביא תשלומים, סוף סוף נראה בדוח לצד ערוץ שהביא פחות לידים, אך עם שיעור סגירות גבוה. הדבר מאפשר לחלק מחדש את המאמצים והתקציב למקום שבו הפניות הופכות להכנסה, ולא רק לשורה ב-CRM.

איכות הלידים הופכת למדידה, ולא להערכה. ניתן לראות מאיזה קמפיין מגיעים לקוחות שמגיעים עד לתשלום, ומאיזה — פניות שמחלקת המכירות סוגרת בסירוב בשיחה הראשונה. עלות הגיוס מחושבת לפי עסקאות, ולא לפי פניות, ולכן היא משקפת את הכלכלה האמיתית של המכירות, ולא מדד ביניים.

הדיווח לפי ערוצים מפסיק להיות שונה בין השיווק למכירות: שני הצדדים מסתכלים על אותם נתונים, שבהם עסקאות לא מקוונות מאוחדות עם מקורות מקוונים. הוויכוח "השיווק מביא זבל" או "המכירות לא יודעות לסגור" מוחלף בניתוח של ערוצים ושלבים ספציפיים במשפך.

דרכי העברת נתונים: השוואת אפשרויות

העברת המרות אופליין מ-Bitrix24 אל Google Analytics מבוססת על עיקרון אחד: אירוע ב-CRM מותאם לסשן באתר באמצעות מזהה הלקוח, וההתאמה הזו עוברת אל האנליטיקה. מה ששונה הוא דרכי המסירה — מהעברה כמעט מיידית דרך וובהוקים ועד ייצוא נתונים קבוע במנות. הבחירה קובעת כמה מהר ההמרה תופיע בדוחות וכמה עבודה ידנית תישאר בצד הצוות.

למה לשים לב בעת הבחירה

הסיכון המרכזי — אי-סנכרון של מזהה הלקוח: אם ב-CRM הוא נשמר בצורה אחת ובאתר נאסף בצורה אחרת, ההתאמה מייצרת חיובי שווא או החמצות. לכן בכל אפשרות קודם מקבעים את כלל הנרמול ורק אחר כך בוחרים את דרך המסירה.

הגורם השני — אידמפוטנטיות. שליחה חוזרת של אותו אירוע לא אמורה להכפיל את ההמרה, אחרת הדיווח מאבד משמעות. וובהוקים וייצוא מוגדרים כך שלכל אירוע יהיה סימן ייחודי ושליחה חוזרת לא תיצור כפילות.

מה זה נותן בפועל

בהעברת המרות אופליין דרך וובהוקים הנתונים בדוחות מפגרים בדקות, בייצוא מתוכנן — בשעות. ההבדל קריטי אם ניהול הפרסום נשען על האנליטיקה: נתונים טריים מאפשרים לחלק מחדש ערוצים מהר יותר, ואילו השהיה יומית משאירה החלטות על תמונה מיושנת.

אנחנו בדרך כלל משלבים דרכים: וובהוקים לעסקאות שוטפות וייצוא מתוכנן כרשת ביטחון שמשלים את מה שהוחמץ. תארו את המשפך שלכם ואת נפח העסקאות — נחזור עם הערכה ותוכנית לכל דרך.

איך אנחנו מטמיעים את החיבור: שלבי העבודה

אנחנו מתחילים את העבודה עם ביקורת: בודקים אילו מטרות כבר מוגדרות ב-Google Analytics, איך מסומנות הטפסים והכפתורים באתר, ואילו עסקאות ב-Bitrix24 נסגרות ידנית ולכן לא נכנסות לניתוח. בשלב הזה אנחנו מזהים את הפער בין נתוני השיווק לבין המכירות בפועל — דווקא הוא מעוות את הערכת הערוצים.

שלבי ההטמעה

1. ביקורת של האינטגרציה הנוכחית. משווים את רשימת המטרות מול משפך העסקאות, בודקים את תקינות המזהים (Client ID, User ID) בטפסים באתר ובפניות ממסרים, ומוצאים את המקורות שבהם הקשר הולך לאיבוד.
2. תכנון סכמת ההעברה. קובעים אילו שלבי עסקה נחשבים להמרה לא מקוונת, איך להתאים את האירוע לסשן, ואילו שדות CRM עוברים לדוח. מתאמים את הכללים עם צוות המכירות שלכם, כדי ש"ליד מוסמך" יסומן באותה צורה אצל כולם.
3. הגדרת העברת הנתונים. מגדירים ייצוא מ-Bitrix24 אל הניתוח: מקשרים עסקאות סגורות לביקור המקורי, מגדירים תזמון ושליחות חוזרות במקרה של תקלות, כדי שאף המרה לא תלך לאיבוד.
4. בדיקות. מריצים עסקאות בקרה דרך כל המשפך — מהפנייה ועד לתשלום — ובודקים שהאירוע הגיע עם המקור והסכום הנכונים. בנפרד בודקים את החזרה לאחור: אם ההעברה נכשלה, הנתונים צריכים להיטען מחדש ולא להיכפל.
5. התאמה מול ה-CRM. משווים את מספר ההמרות בדוח למספר העסקאות ב-Bitrix24 באותה תקופה. אם הפער גדול מהמותר — מחפשים את הסיבה עד שהמספרים יתאמו.
6. תיעוד. מוסרים את סכמת זרימת הנתונים, רשימת המטרות והשלבים, נוהל הבדיקה והוראות למשווק: איך להוסיף מטרה חדשה או לשנות כלל בלי מפתח.

מה מקבלים בסוף

לאחר ההטמעה הדוחות מציגים לא פניות אלא כסף: רואים איזה ערוץ מביא עסקאות שמגיעות עד לתשלום, ואיזה — רק קליקים. בהמשך אפשר להרחיב את החיבור — להוסיף מקורות ושלבים חדשים בלי לבנות הכול מחדש.

מה נשאר לכם לאחר ההטמעה

לאחר ההטמעה נשארת לכם לא "קבוצת הגדרות בחשבון של מישהו אחר", אלא תיעוד עבודה שלפיו כל מהנדס או משווק שלכם יוכל לתחזק את האינטגרציה של Bitrix24 עם Google Analytics. אנחנו מעבירים הכול בסביבה שלכם: מאגר, הרשאות, תיאורים — שום דבר לא נשאר בצד שלנו.

• תרשים האינטגרציה — זרימת הנתונים מהעסקה ב-CRM ועד להעלאת המרה לא-מקוונת ל-Google Analytics: אילו אירועים ובאילו שלבי משפך נשלחים, כיצד מותאמים מזהי הלקוח, והיכן בדיוק הולכים לאיבוד אי-ההתאמות.
• תצורת ההעברה — הגדרות עבודה של הייצוא: רשימת שלבים ושדות של העסקה, כללי המיפוי למטרות, לוח הזמנים ותנאי השליחה החוזרת במקרה של כשל.
• נוהל התחזוקה — מי עושה מה בעת שינוי במשפך, הוספת שלב חדש או שינוי בכללי הייחוס: שלב אחר שלב, עם אחראים ונקודות בדיקה.
• הוראות אבחון — כיצד בתוך 10-15 דקות להבין מדוע ההמרה לא הגיעה: היכן לבדוק את יומן השליחות, כיצד להשוות עסקה ב-CRM עם אירוע באנליטיקה, ואילו שגיאות הן אופייניות.
• מפת התאמת נתונים — טבלת התאמה בין שדות ה-CRM לפרמטרים של אירועים, כדי שבעת שיפורים לא תצטרכו לנחש מה ממופה לאן.
• רשימת תיוג לקבלה — מערכת בדיקות שלפיהן אתם מקבלים את העבודה: עסקת בדיקה עוברת את כל המסלול, הדוח מציג את ההמרה, והחזרה לאחור מחזירה את ההתנהגות הקודמת.
• הרשאות ותפקידים — מה ולמי הוענק, אילו מפתחות וטוקנים משמשים, היכן הם נשמרים וכיצד מחליפים אותם ללא השבתה.

כל זה מתואר כך שכעבור חצי שנה, כשהמשפך ישתנה, לא תצטרכו להבין מחדש כיצד בנויה ההעברה. תארו את המשימה — נחזור עם הערכה ותוכנית, כולל הרכב הארטיפקטים המועברים.

מקרה בוחן: כיצד המרות אופליין שינו את הדיווח

הלקוח — רשת של מספר שואורומים עם פניות מקוונות ומכירות באולם. עסקאות ב-Битрикс24 נסגרו על ידי מנהלים באופן ידני, ובדוחות של מערכות ניתוח האינטרנט נלקחו בחשבון רק פניות מהאתר. בגלל זה, הערוץ שהביא פניות עם מחזור קבלת החלטה ארוך נראה מפסיד, וצמצמו בו את הפעילות.

פירקנו את מסע הלקוח: פנייה מהאתר → שיחה → ביקור בשואורום → עסקה. קישרנו בין ה-CRM לניתוח האינטרנט לפי מזהה הקליק: בעת מעבר לאתר הוקצה למבקר מזהה, ואותו מזהה נשמר גם בכרטיס העסקה. כאשר המנהל העביר את העסקה לסטטוס מוצלח, המערכת שלחה לניתוח המרת אופליין עם המזהה הזה וסכום העסקה. בנפרד הוגדרה העברת החזרים וביטולים — כדי שהדיווח לא ינפח את התוצאה.

מה השתנה בדיווח

לפני ההטמעה בדוחות נראו 38% מהמכירות בפועל — השאר "אבד" בין הפנייה לסגירת העסקה ב-CRM. לאחר הגדרת העברת המרות אופליין הכיסוי עלה ל-94%: בדוחות החלו להילקח בחשבון גם עסקאות שנסגרו שבועות לאחר הפנייה הראשונה.

הערוצים התכנסו לתמונה אחרת. חלקם של הפניות עם מחזור ארוך גדל בדוחות כמעט פי שניים, ואחד הערוצים שנחשב לחלש התברג בראש לפי מספר העסקאות שנסגרו. החלטות על חלוקת הפעילות החלו להתקבל לפי מכירות בפועל, ולא לפי מספר הפניות.

מה נתנה החיבור עם התחשבות בהחזרים

ביטולים והחזרים כעת מפחיתים את תוצאת הערוץ, ולא נשארים מחוץ לתמונה. הפער בין דוחות הניתוח לנתוני ה-CRM הצטמצם מ-40% ל-6% — המספרים בדוח להנהלה וב-CRM הפכו להשווים.

מכירות חוזרות ללקוחות קיימים גם הן קושרו לערוץ המקורי. זה הראה שחלק מההכנסות מביאות לקוחות שהגיעו דרך ערוצים שנחשבו בעבר ללא אפקטיביים — והתרומה שלהם הפכה לגלויה בדיווח.

הפרויקט הוטמע על Битрикс24 עם העברת נתונים למערכות ניתוח האינטרנט.

במה שונה העברת המרות אופליין מניתוח מקצה לקצה?

ניתוח מקצה לקצה עונה על השאלה "איזה ערוץ הביא את הלקוח", המרות אופליין — על השאלה "מה קרה ללקוח הזה לאחר שעזב את האתר". אלה שני רבדים שונים של נתונים, וערבוב ביניהם פירושו בניית דיווח על תמונה חלקית.

ניתוח מקצה לקצה מקשר את מקור התנועה לפעולה באתר: קליק פרסומי, מעבר מחיפוש, ביקור בקישור מתוך מייל. המרת אופליין מתעדת אירוע שהתרחש מחוץ לדפדפן: תשלום לפי חשבונית, חתימה על חוזה, שיחה למחלקת מכירות, רכישה חוזרת דרך מנהל.

ההבדל מתגלה ברגע שבו העסקה נסגרת לא באתר. הלקוח השאיר בקשה, המנהל הוביל אותו במשך שבוע, התשלום הגיע לחשבון — עבור מערכת ניתוח האינטרנט המסלול הזה נקטע בטופס. ניתוח מקצה לקצה יראה את מקור הבקשה, אך לא יראה שהעסקה התקיימה וכמה היא הניבה. המרת אופליין סוגרת את הפער הזה: האירוע ממערכת החשבונאות חוזר לניתוח ומקושר למקור התנועה המקורי.

מבחינה טכנית זה בנוי כך: ב-Bitrix24 מתועד שלב העסקה, במעבר לשלב היעד המערכת יוצרת מזהה לקוח ומעבירה את האירוע לניתוח. המזהה מקשר את העסקה הסגורה לאותו קליק פרסומי או ביקור שהוליד אותה.

בלי הקישור הזה ערוצי הפרסום מוערכים לפי בקשות, ולא לפי הכנסות — וההחלטה על חלוקה מחדש של התקציב מתקבלת על נתונים שגויים.

מתי נדרש איזו גישה. ניתוח מקצה לקצה — אם מחזור העסקה קצר ונסגר באתר: חנות אינטרנטית, תשלום מקוון, רכישה מהירה. המרות אופליין — אם בין הבקשה לתשלום יש עבודת מנהל, חשבונית, חוזה, משא ומתן ממושך.

בפועל שני הרבדים פועלים יחד: ניתוח מקצה לקצה נותן את החלק העליון של המשפך, המרות אופליין — את הסיום הכספי שלו. האינטגרציה של Bitrix24 עם Google Analytics בדיוק מגדירה את העברת האירועים הללו, כדי שהדיווח יתבסס על עסקאות שנסגרו בפועל, ולא על מספר הטפסים שהושארו.

שאלות טכניות נפוצות

אינטגרציה של Битрикс24 עם Google Analytics נתקלת לרוב לא בחילופי הנתונים עצמם, אלא בהעברה נכונה של המרות אופליין — אירועים שמתרחשים מחוץ לאתר: תשלום לפי חשבונית, אישור עסקה על ידי מנהל, רכישה חוזרת. בלעדיהם האנליטיקה רואה רק קליקים ופניות, ואינה מציגה את ההכנסה האמיתית לפי ערוצים.

להלן תשובות לספקות טכניים שעולים לפני תחילת ההגדרה.

מה יקרה אם החיבור מוגדר לא נכון?

כפילויות של המרות מעוותות את הדיווח חזק יותר מהיעדרן: עסקה אחת עשויה להיספר פעמיים בעת שינוי סטטוס. אנחנו מגדירים העברה לפי סטטוס סופי מסוים והגנה מפני שליחה חוזרת — בדוח נשארת רשומה אחת לכל עסקה.

כיצד מוגדרת ההעברה מ-Битрикс24?

באמצעות תהליכים עסקיים ו-webhooks: כאשר העסקה עוברת לסטטוס היעד, המערכת שולחת אירוע ל-Measurement Protocol. ההגדרה אורכת מספר ימים, כולל הרצת בדיקה על עסקאות אמיתיות והצלבת נתונים עם ה-CRM.

האם ניתן לבטל שינויים אם משהו ישתבש?

כן. הלוגיקה מוצאת לתהליך עסקי נפרד, שמנותק בהגדרה אחת ללא שינוי הליבה. לפני ההפעלה אנחנו עושים גיבוי של התצורה — החזרה למצב הקודם אורכת דקות.

האם צריך לגעת באתר עצמו וב-1С?

בדרך כלל לא: מזהה הקליק והסטטוסים כבר קיימים ב-CRM. באתר אנחנו מבצעים התאמות רק אם הוא אינו מעביר את התג בעת יצירת הליד. עם 1С החיבור עובד דרך חילופי סטטוסי תשלום — אינטגרציה נפרדת אינה נדרשת.

נדון במשימה שלכם

אנחנו אוספים נתוני פתיחה על המערך שלכם: אילו יישויות ב-Bitrix24 נחשבות ליעד (עסקה, תשלום, רכישה חוזרת), אילו מקורות מסומנים ב-Google Analytics, והיכן כיום אובד הקשר בין הליד לעסקה סגורה. זה מספיק כדי לחזור עם הערכה ותוכנית — בלי "ראיון טכני של שלוש שעות" מקדים.

• מנתחים את הסכימה הנוכחית: איך לידים נכנסים ל-CRM, אילו שדות מתעדים את המקור ואת מזהה הקליק, והיכן נשברת השרשרת עד להמרה אופליין.
• מאמתים את ספרי העזר: סטטוסים של עסקאות, סיבות סירוב, קטגוריות של מוצרים ושירותים — מביאים אותם לצורה שמתאימה להעברה לאנליטיקה בלי תיקונים ידניים.
• מתכננים את העברת ההמרות האופליין: התאמה בין עסקה לביקור, כללים לשליחה בעת שינוי סטטוס, טיפול בעסקאות חוזרות ומבוטלות.
• מגדירים את הייצוא ובודקים אותו על עסקאות בדיקה: סכומי בקרה, כפילויות, השהיות בין סגירת העסקה להופעת הנתונים בדוחות.
• מאחדים את הדיווח: חיבור בין מקורות, קמפיינים והכנסה בפועל לפי עסקאות סגורות, ולא לפי טפסים שנשלחו.
• קובעים נוהל: מי ומתי משנה סטטוסים, מה קורה כאשר לקוח מסרב, ואיך מתבצעת חזרה של העברה שגויה.
• מוסרים תיעוד ומכשירים את הצוות שלכם — כדי שעדכונים בספרי העזר לא ישברו את העברת הנתונים.

כדי לחזור עם תוכנית, אנחנו צריכים מכם מעט: גישה ל-CRM עם הרשאות קריאה לספרי העזר, רשימת סטטוסי עסקאות יעד, והבנה אילו דוחות אתם צופים בהם היום. תארו את המשימה בשתיים-שלוש פסקאות — מה כבר מוגדר, מה לא מסתדר במספרים, ואיזו תוצאה נדרשת. לאחר מכן נציע סכימה, לוחות זמנים וסדר עבודה.