אינטגרציה של 1C-Bitrix עם שירותי אנליטיקה מקצה לקצה

אינטגרציה של 1C-Bitrix עם אנליטיקה מקצה-לקצה: היכן נשבר התיעוד החשבונאי

אתר על 1C-Bitrix ומערכת הנהלת החשבונות מחליפים ביניהם נתונים, אך השרשרת «פנייה → עסקה → תשלום → דוח» נשברת בכמה מקומות צפויים. הפנייה מגיעה פעמיים — במייל וברשומה באינטגרציה, ומכאן כפילויות של הזמנות ופניות שמאחדים ידנית. תגית המקור אובדת במעבר בין דומיינים או בביקור חוזר: העסקה בדוח קיימת, אך הערוץ אינו מזוהה.

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

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

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

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

מה משתנה לאחר החיבור: אפקט בגדלים מדידים

החיבור בין אתר על 1C-Bitrix, פורטל Bitrix24 וקונטור הנהלת החשבונות של 1С מסיר את העברת הנתונים הידנית בין המערכות. להלן מה בדיוק משתנה בגדלים מדידים לאחר שההחלפה מכוילת ופועלת לפי לוח זמנים.

זמן הכנת הדיווח

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

שלמות הנתונים לפי ערוצים

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

שיעור הפניות ללא תיוג

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

השבתת התיעוד ותמונה אחודה של המכירות

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

כיצד להעביר נתונים לדיווח: השוואת גישות

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

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

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

סדר העבודות: מביקורת המקורות ועד מסירה לתמיכה

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

1. ביקורת מקורות הנתונים. אוספים רשימה של מערכות שמייצרות נקודות מגע: האתר, ה-CRM, הטלפוניה, חשבונות הפרסום, המסנג'רים, נקודות אופליין. עבור כל מקור מתעדים מזהה ראשוני של הפנייה — מספר הפנייה, הלקוח, השיחה או הביקור — ומה קורה לו בעת החלפת ערוץ.
2. סכמת התאמת הישויות. מתארים כללי קישור בין הפנייה לביקור, למודעה ולעסקה. בנפרד מפרטים את ההתנהגות במקרים שנויים במחלוקת: פנייה חוזרת מאותו לקוח, פנייה ללא מזהה ביקור, כמה עסקאות לפנייה אחת.
3. הגדרת ההחלפה והתיוג. מחברים את העברת הנתונים בין האתר, ה-CRM ושירותי האנליטיקה, מכווננים את הטפסים, היעדים והחלפת המספר. כל פרמטר תיוג נבדק במעבר אמיתי, ולא בעמדת בדיקה.
4. בדיקה על פניות אמיתיות. מריצים את המסלול המקצה-לקצה על פניות ממשיות, כולל לא שגרתיות: שיחה ללא ביקור באתר, פנייה ממסנג'ר, ביטול ופתיחה חוזרת של עסקה.
5. בדיקת עומס של ההחלפה. מזרימים שיא של אירועים ובודקים אם ההחלפה אינה מפגרת, אם הרשומות אינן מתרבות ואם השגיאות אינן אובדות. חובה לבדוק שליחה חוזרת לאחר תקלת תקשורת.
6. קבלה ומסירה לתמיכה. מתאימים את הדוחות לנתוני המקורות עד להתאמה מלאה, מתארים תקנון להפעלה מחדש של ההחלפה, מגדירים התראות על ניתוק התקשורת ומעבירים תיעוד לצוות שלכם או לנו לליווי.

מארז של סכמות, הגדרות ותקנונים לאחר ההרצה

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

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

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

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

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

מה היה לפני החיבור

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

מה שינינו

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

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

במה נבדל תיעוד מקצה-לקצה ממארז של דוחות נפרדים?

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

חלק מהתיעוד חי בטבלאות ידניות — האם זה יפריע?

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

כיצד לתחום את הגישה לפי תפקידים?

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

מה יקרה אם שירות האנליטיקה לא יהיה זמין?

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

האם אפשר לבצע שיפורים בלי לעצור את האתר?

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

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

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

• הצגת המשימה לחיבור: אילו אירועים מ-1C-Bitrix ו-Bitrix24 נחשבים ליעדיים (פנייה שהוגשה, חשבונית, תשלום, רכישה חוזרת), היכן נגמר המשפך ומה נחשב להצלחה.
• רשימת מקורות הנתונים: האתר, ה-CRM, הטלפוניה, המסנג'רים, הקופות המקוונות, פלטפורמות הפרסום, הייצוא מ-1С — עם ציון אילו מזהי לקוח קיימים בהם כעת (טלפון, מייל, מספר הזמנה).
• דרישות לדיווח: אילו חתכים נדרשים בסופו של דבר — לפי ערוצים, קמפיינים, מנהלים, אגפים — ובאיזו תדירות עדכון; בנפרד נציין היכן הנתונים יגיעו באיחור ומדוע.
• סדר הגישה למערכות: מי מצד הלקוח מנפיק הרשאות ל-CRM, לחשבונות הפרסום, למערכת הנהלת החשבונות, והאם יש מגבלות על ייצוא נתונים אישיים.
• מגבלות וכללים: תקופות שמירת נתונים, דרישות לאנונימיזציה, עבודה עם כמה ישויות משפטיות או סניפים בדיווח אחד.
• אחראים ונקודות אישור: מי מאשר את לוגיקת קישור האירועים ומי מקבל את התוצאה בשלב הבדיקה.
• תוכנית עבודות והערכה: לאחר בחינת נתוני הפתיחה נחזור עם שלבים, סדר ההטמעה ומה שאפשר להריץ במחזור הראשון.

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