מה נשבר באנליטיקה של חנות אינטרנט על 1С-Битрикс
לרוב חנות על 1С-Битрикс מאבדת נתונים לא ברגע ביצוע ההזמנה, אלא במפגש בין הפרונטאנד, הבקאנד ומערכות החשבונאות. האירוע purchase יוצא מהדפדפן לאחר ההפניה מחדש לעמוד ה"תודה", ואם הלקוח רענן אותו או חזר דרך ההיסטוריה — העסקה נשלחת שוב. כך מופיעים כפילויות של עסקאות: בדוחות שני הזמנות במקום אחת, ההכנסה מנופחת, וההמרה האמיתית מיטשטשת.
התקלה הטיפוסית השנייה — פריטי סל שאבדו. הרכב ההזמנה נאסף מתוך סימון ה-DOM, ודי לשנות תבנית של רכיב או לחבר מודול חיצוני לביצוע הזמנה, וכבר ב-items עובר id שגוי של המוצר, אובדת הקטגוריה או הכמות.
Enhanced Ecommerce בצורה כזו מגיע למערכת האנליטיקה באופן חלקי: סכום ההזמנה מתאים, אך הפילוח לפי מוצרים וקטגוריות — לא, ודוחות הרווחיות הופכים לבדיה.
המקור השלישי לאי-התאמות — אסינכרוניות. ההזמנה נרשמת ב-1С, הסטטוס משתנה מאוחר יותר, חלק מהתשלומים מגיעים משער התשלומים באיחור.
אם האירוע נשלח רק בצד הלקוח, הזמנות שבוטלו והוחזרו נשארות בסטטיסטיקה כמוצלחות, ונתוני האנליטיקה של חנות האינטרנט חלוקים עם הנהלת החשבונות בשיעור ההחזרות והסלים שלא שולמו.
בנפרד יש להתחשב בחוסמים ובאובדן סשן: חלק מהאירועים לא מגיעים כלל, ובדוחות נוצר תעבורה "אפורה" ללא ייחוס. כל הכשלים הללו באיסוף הנתונים נראים כאי-התאמות קטנות לכל הזמנה, אך לאורך זמן מעוותים החלטות בנוגע למלאי, לפרסום ולרכש. אנו מפרקים כיצד זה נסגר בצד השרת וברמת התבניות.
מה נותנת העברה נכונה של נתוני הזמנות
התאמה עם מערכת הנה"ח
העברה נכונה של אירועים משמעה שהסכומים וההרכב של ההזמנות באנליטיקה תואמים את מה שמציגה מערכת הנה"ח. פער נוצר בדרך כלל לא בגלל שגיאות רישום, אלא בגלל אובדן אירועים בצד האתר: הסקריפט לא נטען במלואו, הקונה סגר את החלון לפני האישור, חסימת tracker הופעלה.
כאשר זרימת האירועים בנויה ומוכפלת בצד השרת, שיעור ההזמנות שהנתונים שלהן מגיעים לדוחות מתקרב לשלם, והפער מול מערכת הנה"ח מצטמצם למקרים בודדים שנראים לעין וניתנים לבדיקה.
שלמות משפך המכירות
כאשר כל שלב — צפייה בכרטיס, הוספה לסל, התחלת תשלום, תשלום — מועבר כאירוע נפרד עם מזהים זהים, המשפך מפסיק "להיקרע". רואים באיזה שלב בדיוק הולך לאיבוד שיעור הקונים וכמה הזמנות לא מגיעות לתשלום.
זה משנה את סדרי העדיפויות: במקום השערות ש"הסל לא נוח", מופיע שלב קונקרטי עם הנשירה הגדולה ביותר, והעבודה מתמקדת בו, ולא בכל העמוד בבת אחת.
ויתור על התאמות ידניות
התאמה ידנית של דוחות עם מערכת הנה"ח — עומס קבוע על האנליסט או המשווק ומקור לשגיאות. כאשר הנתונים מתאמים אוטומטית, העבודה הזו נעלמת: הדיווח נבנה על מקור אחד, והפערים צפים מיד, ולא בסוף החודש.
איכות הנתונים הופכת לצפויה: הגדרות זהות של אירועים בכל העמודים ובערוצים שונים נותנות נתונים בני השוואה שאפשר להישען עליהם בהחלטות לגבי תקציב ומגוון.
מה זה נותן בניהול
במקום אוסף של נתונים מפוזרים מופיעה תמונה קוהרנטית: כמה עולה גיוס לפי ערוצים, אילו מוצרים ומדורים באמת מניבים הכנסה, היכן הולכת לאיבוד ההמרה. החלטות לגבי קידום ומגוון נשענות על נתונים מתאמים, ולא על הערכות. מפרקים כיצד זה נסגר בפרויקט קונקרטי.
דרכים ליישום Enhanced Ecommerce: השוואה
שיטת היישום קובעת איזה נתונים על מוצרים והזמנות בכלל יגיעו לניתוח. אם בוחרים בגישה "לפי העין", חלק מהאירועים הולכים לאיבוד בעגלת הקניות ובתהליך השלמת ההזמנה — והדוחות מתחילים לסטות מהמכירות בפועל.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודול מוכן מהמרקטפלייס | התחלה מהירה, עגלת קניות טיפוסית, כרטיסי מוצר סטנדרטיים | אינה מכסה שלבי השלמת הזמנה מותאמים אישית ושדות לא סטנדרטיים; בעת עדכון התבנית יש להגדיר מחדש את האירועים |
| סימון דרך תבנית הרכיב | קטלוג סטנדרטי על רכיבים מקוריים, נדרש שליטה מלאה על האירועים | דורש שינויים בתבניות; בעת שינוי עיצוב יש להעביר את הסימון ידנית |
| אירועים דרך הצד השרת | הזמנות, תשלום, סטטוסים, נתונים מ-1С — במקומות שבהם חשובה�יוק | קשה יותר לנפות, נדרש גישה ללוגיקה בצד השרת ותיאום עם מערכת החשבונאות |
| העברה מקצה לקצה מ-1С | נדרשים מכירות, החזרות והתאמה עם החשבונאות בתמונה אחת | תלוי באיכות הייצוא; אי-התאמות במדריכים שוברות את התאמת המוצרים |
בפועל, לרוב משלבים: את חלון הראווה מסמנים בצד התבנית, ואת ההזמנות והתשלום מעבירים מהשרת. כך אירועי עגלת הקניות והכרטיסים נאספים מיד עם הצפייה, ועובדת הרכישה מאושרת בנתונים ממערכת החשבונאות — בלי ספירה כפולה והזמנות "רפאים".
מגבלה שכדאי לזכור בכל אפשרות: התאמת המוצר מתבצעת לפי מזהה, ואם הוא משתנה בעת עדכון הקטלוג או ייצוא מ-1С, ההיסטוריה של הפריט נשברת. לכן מקבעים את המזהים לפני תחילת הסימון.
איך מתבצע היישום: שלבי העבודה
היישום אינו מתחיל בקוד, אלא במיפוי של מה שכבר נאסף. בשלב זה חשוב להבין אילו אירועים באמת נשלחים לניתוח נתונים, ואילו משוכפלים או הולכים לאיבוד בצד הסל ומערכת השלמת ההזמנה. בלי תמונה כזו, כל הגדרה הופכת לניחוש.
- ביקורת הניתוח הנוכחי. משווים את רשימת האירועים מול המשפך: צפייה ברשימה, כרטיס מוצר, הוספה לסל, תחילת השלמת הזמנה, רכישה. מתעדים פערים בין נתוני החנות המקוונת לדוחות — בדרך כלל דווקא שם מסתתרות הזמנות שאבדו.
- תכנון סכמת האירועים. מתאמים מילון פרמטרים: מזהה מוצר, קטגוריה, מותג, כמות, עלות פריט. אותו מוצר חייב להיקרא באותו שם בכל האירועים, אחרת הדוחות לא יתאימו.
- הגדרת איסוף הנתונים. מחברים העברת אירועים בצד השרת, כדי שהנתונים לא יהיו תלויים בחוסמים ובהגדרות הדפדפן. מגדירים חיבור ל-1С, כדי שהרכב ההזמנה והסכומים שלה יתאימו לנתונים בפועל.
- הרכבת הדוחות. מכנסים את האירועים למשפכים ולדוחות לפי מוצרים וקטגוריות. בודקים שכל שלב נראה בנפרד ושהסכומים תואמים לנתונים החשבונאיים.
- בדיקה והצלבה. מריצים הזמנות בדיקה ומשווים את נתוני הניתוח למכירות בפועל. פער בכמות ובסכום — אות עצירה, וחוזרים לסכמת האירועים.
- מסירת נהלים. מוסרים תיעוד של האירועים, הוראות להוספת מוצרים חדשים וצ'ק-ליסט לבדיקה לאחר עדכוני האתר.
לאחר המסירה הליווי לא מסתיים: בעת שינוי בקטלוג, בסל או בהשלמת ההזמנה יש לתחזק את סכמת האירועים במצב מעודכן. אנו מתארים כיצד לעשות זאת בכוחות עצמכם, ונשארים בקשר להמשך עבודה.
מה הלקוח מקבל לידיו
פיתוח אינטגרציה הוא לא רק קוד עובד בתבנית. הלקוח מקבל ערכה שלמה שלפיה צוות השיווק והפיתוח יוכל לעבוד באופן עצמאי: לבדוק את נכונות הנתונים, לחזור על ההגדרה באתר חדש ולהעביר את המשימה לספק חדש בלי חפירות ארכיאולוגיות בקוד של מישהו אחר.
- מפת אירועים — טבלת התאמה: איזה רכיב ממשק (כרטיס מוצר, כפתור "הוספה לסל", שלב השלמת הזמנה) שולח איזה אירוע ועם אילו פרמטרים. איתה איש השיווק רואה מה בדיוק נכנס לדוחות, והמפתח — היכן לחפש את נקודת התיקון.
- הגדרות מעקב — תצורת המונה וזרמי הנתונים, רשימת מטרות ואירועים מרכזיים, חיבור לקטגוריות הקטלוג ולמשפך השלמת ההזמנה. הכול מתועד בצורה שניתן להשוות למצב הנוכחי של המערכת.
- נוהל בדיקת נתונים — סדר ההשוואה: כיצד להשוות את מספר ההזמנות בפאנל הניהול למספר הרכישות בדוח, אילו פערים נחשבים לתקינים (החזרות, ביטולים, תשלום לאחר משלוח), ואילו מאותתים על תקלה.
- מדריך לצוות — תיאור שלב אחר שלב של פעולות שגרתיות: כיצד להוסיף פרמטר חדש לאירוע, כיצד לבדוק אותו במצב דיבאג, כיצד להחזיר שינוי לאחור אם הדוח השתבש.
- תיעוד האינטגרציה — נקודות החיבור בתבניות, המודולים שבשימוש, תלויות בשירותי צד שלישי. מפתח חדש נכנס להקשר בתוך שעות, ולא בשבועות של פענוח.
- צ'ק-ליסט קבלה — רשימת תרחישים שנבדקים לפני העלייה לאוויר: צפייה בכרטיס מוצר, הוספה לסל, מחיקה, השלמת הזמנה, תשלום. לפיו מתקבלת העבודה ונבדקת שוב לאחר עדכוני הפלטפורמה.
- תוכנית ליווי — מה בודקים לאחר עדכון הפלטפורמה, מי אחראי לתגובה לפערים, ובאילו לוחות זמנים מטופלות תקלות בהעברת הנתונים.
ערכה כזו מסירה את הסיכון המרכזי של האינטגרציה: הנתונים בדוחות מפסיקים להיות "קופסה שחורה" שאף אחד לא יכול לבדוק. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: כיצד שוחזרה התאמת הנתונים של החנות
הלקוח — חנות מקוונת על 1С-Битрикс עם כמה אלפי SKU וביצוע הזמנה בשלב אחד. פנו בתלונה קונקרטית: הסיכומים ב-Google Analytics 4 אינם תואמים לדוחות ממערכת הנה"ח.
דוח ההכנסות לחודש סטה מההזמנות בפועל ב-18–22%, והמרת משפך ההזמנה נראתה מנופחת — חלק מהרכישות נספרו פעמיים, וחלק לא נספרו כלל.
מה מצאנו
אירוע purchase נשלח בעמוד "תודה" בכל רענון, ולא פעם אחת לכל עסקה — מכאן הכפילויות וההכנסה המנופחת. פריטי הסל הועברו ללא פירוט לפי וריאנטים של המוצר, ולכן הצעות המסחר קופלו לשורה אחת ועיוותו את מבנה ההזמנות. חלק מההוספות לסל מהקטלוג לא הגיעו בגלל שהאירוע הופעל לפני טעינת נתוני המוצר.
מה שינינו
קישרנו את transaction_id למספר ההזמנה במערכת הנה"ח והפעלנו הסרת כפילויות בצד אוסף הנתונים — שליחות חוזרות של אותו אירוע נזרקות. הפרדנו מוצרים והצעות מסחר לפי מזהים, והוספנו העברת מותג וקטגוריה בכל רמות המשפך.
אירועי הקטלוג הועברו לשליחה לאחר אישור טעינת כרטיס המוצר, ושלבי ההזמנה סומנו לפי מצבי הטופס בפועל, ולא לפי כתובות העמודים.
תוצאה
הפער בין ההכנסות למערכת הנה"ח הצטמצם מ-18–22% ל-2–3% — היתרה מוסברת בהחזרות וביטולים, אשר בדוח נספרים בנפרד. רכישות כפולות נעלמו לחלוטין: סוג השגיאה שגרם להכנסה מנופחת טופל ברמת מזהה העסקה. משפך ההזמנה מציג כעת את השלבים האמיתיים, וממנו ניתן לראות באיזה שלב בדיוק הולכים לאיבוד הקונים.
בנפרד הגדרנו התאמה: פעם ביום דוח ההזמנות מותאם לדוח ממערכת הנה"ח, ופער מעל הסף מודגש. זה נתן את מה שלשמו נעשה הכל — לנתונים בדוחות אפשר שוב לתת אמון בתכנון רכש והערכת ערוצים.
במה שונה Enhanced Ecommerce מניתוח בסיסי?
ניתוח בסיסי סופר ביקורים, צפיות ומעברים — הוא עונה על השאלה "כמה אנשים הגיעו". Enhanced Ecommerce עונה על שאלה אחרת: "מה בדיוק הם עשו עם המוצר ובאיזה שלב עזבו". ההבדל אינו בהיקף הדוחות, אלא במודל הנתונים: אירועים נקושרים לישויות של הקטלוג, ולא לעמודים.
צפייה בכרטיס מוצר, הוספה לסל, התחלת תהליך רכישה, קנייה — כל פעולה נושאת מזהה מוצר, קטגוריה, וריאנט, כמות וסכום. מהצירוף הזה נבנה משפך עבור פריט מסוים, ולא "טמפרטורה ממוצעת" של האתר.
האפקט המעשי ניכר במקומות שבהם הניתוח הבסיסי שותק. הוא יראה ש-70% מהאורחים נטשו את הסל, אך לא יגיד שמחצית מהנטישות מתרחשות במידות של מותג אחד לאחר בחירת מידה. Enhanced Ecommerce מראה באיזה שלב של תהליך הרכישה אובד חלק מההזמנות ואילו מוצרים נצפים לרוב אך לא נרכשים. מכאן נולדים פתרונות: להעביר את בלוק המשלוח, להסיר שלב מיותר, לשפר תיאור או תמונה בפריט בעייתי.
האירועים נבנים לפי סכימה: רשימת מוצרים בעמוד הקטלוג, צפייה בכרטיס מוצר, הוספה והסרה מהסל, שלבי תהליך הרכישה, קנייה והחזרה. לכל שלב מוקצה מספר סידורי, ולכן המשפך נבנה במלואו, ולא לפי מדדים עקיפים.
בנפרד מועבר מידע על מבצעים ומעברים פנימיים — ניתן לראות איזה באנר באמת מביא הזמנות ואיזה רק אוסף קליקים.
אם איסוף הנתונים הבסיסי כבר פרוס, אין חובה לעבור מאפס. ניתן לשמור על המונים והסימון הקיימים בעמודים, ולהוסיף מעליהם העברת אירועים של הקטלוג והסל. עיקר העבודה אינו בחיבור, אלא בהצלחה: מזהי מוצרים, קטגוריות וסכומים חייבים להתאים לנתוני הקטלוג, אחרת הדוחות יהיו שונים מההזמנות בפועל.
לאחר ההגדרה בודקים את המשפך על הזמנות בדיקה ומצליבים סכומים עם מערכת החשבונאות, כדי שהמספרים בדוחות יתאימו למכירות בפועל.
ספקות טכניים נפוצים
תאימות עם מערכת הנה"ח — הדבר הראשון שנתקלים בו: Enhanced Ecommerce דורש ש-items[] באירוע purchase יכיל את אותם מזהים שנשלחים להזמנה. אם הקטלוג ב-1С מנוהל לפי קודים פנימיים, ובאתר המוצר קיים לפי קוד תווי או ID של אינפובלוק, הסימון יגיע לדוח עם פריטים ריקים. אנו בונים התאמה בשלב האינטגרציה ובודקים אותה על הזמנות אמיתיות, ולא על סל קניות לבדיקה.
מהירות האתר — הספק השני, והוא מוצדק: בניית dataLayer בכל כרטיס מוצר ובסל הקניות מוסיפה עבודה לדפדפן. בפועל האירועים נשלחים באופן אסינכרוני, וחישובים כבדים (חישוב מחדש של הסל, משיכת מלאי) מבוצעים בצד השרת ומוחזרים כ-JSON מוכן.
תוספת זמן התגובה נשארת בטווח טעות המדידה, ובהגדרה נכונה של מטמון עמוד הקטלוג אינו נבנה מחדש עבור כל אורח.
תמיכה לאחר ההשקה — לא "התקנו והלכנו": מבנה הקטלוג משתנה, כללי הסל משתנים, תרחישי ביצוע ההזמנה משתנים, ויש לתקן את הסימון בסנכרון, אחרת הדוחות יתחילו לסטות מהמכירות בפועל.
מה קורה אם חלק מההזמנות מבוצעות ב-1С ידנית או דרך מנהל?
הזמנות כאלה אינן עוברות דרך האתר, ולכן לא ייכנסו ל-Enhanced Ecommerce. אנו או מסמנים אותן במקור נפרד בעת הייצוא, או מאחדים את הנתונים בצד מערכת הנה"ח — חשוב להסכים מראש איזה דוח נחשב למחייב, כדי שהמספרים לא יסטו.
האם יש לעצור את האתר בזמן ההגדרה?
לא. הסימון מותקן ונבדק על האתר החי: האירועים נאספים במקביל לאנליטיקה הנוכחית, והמעבר לדוחות החדשים נעשה לאחר השוואה על הזמנות אמיתיות. החזרה לאחור היא הסרת שכבת הסימון, והיא אינה נוגעת בקטלוג, בסל הקניות ובביצוע ההזמנה.
מי אחראי לנכונות הנתונים לאחר המסירה?
אנו מתעדים את סכמת האירועים ואת כללי התאמת המוצרים בתיעוד, כדי שהמפתח שלכם יוכל לבצע תיקונים. אם מבנה הקטלוג או תרחיש ההזמנה משתנה, עדכון הסימון הוא משימה נפרדת, ומוטב לתכנן אותה יחד עם שדרוג האתר, ולא בדיעבד.
בואו נדון במשימת האנליטיקה שלכם
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים להתיישר לפי נתוני הפתיחה. שלחו גישה לפאנל האנליטיקה ולממשק הניהול של האתר — משם אנחנו בעצמנו ניקח את המצב הנוכחי, נבדוק אילו אירועים כבר נשלחים ואילו הולכים לאיבוד בדרך.
מה מבררים בהתחלה:
- אילו מטרות אתם מחשיבים כמרכזיות: הזמנה שהושלמה, הוספה לסל, צפייה בכרטיס, שלב בתהליך ההזמנה;
- איך בנוי הקטלוג: הצעות מסחריות, וריאציות, כמה מחסנים או מחירים — מזה תלוי איך להעביר נתונים על המוצר;
- אילו ערוצי מכירה צריך להפריד זה מזה: קמעונאות, סיטונאות, מרקטפלייסים, איסוף עצמי;
- האם כבר קיימת סימון אירועים והאם הוא משוכפל לאחר עדכונים;
- אילו דוחות אתם צופים בהם כעת ומה חסר בהם כדי לקבל החלטות;
- מי בצד שלכם מקבל את התוצאה ובאיזו צורה נוח לו לקבל אותה.
מכאן עובדים כך: מקבעים את רשימת האירועים והפרמטרים, מצליבים אותה עם הסימון הנוכחי, מראים היכן הנתונים אינם תואמים, ורק לאחר מכן מחשבים את ההיקף. אתם מקבלים הערכה לפי שלבים ותוכנית עם סדר העבודות — מה עושים ראשון, ומה אפשר לדחות בלי לאבד את התוצאה.
תארו את המשימה בשתיים-שלוש פסקאות: מהו האתר, על מה הוא עובד, מה כבר ניסיתם ומה לא התאים באנליטיקה הנוכחית. נחזור עם הערכה ותוכנית.