GA4 ב-1С-Битрикс: הגדרת יעדים ואירועים

1С-Битрикс Google Analytics: היכן נשבר תיוג המטרות

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

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

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

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

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

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

אפקט מדיד מאנליטיקה נכונה באתר

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

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

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

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

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

שיטות איסוף נתונים: השוואת גישות ומצבים

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

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

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

הטמעת תיוג ב-1С-Битрикс: שלבי העבודה

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

1. ביקורת תיוג. אוספים מונים ותגים בכל התבניות, בודקים מה כבר נשלח אל Google Analytics, היכן יש כפילויות ופערים. בפלט — טבלה «מוגדר / עובד / מעוות סטטיסטיקה».

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

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

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

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

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

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

ערכת מסירה: קונפיגורציות, סכימות ונהלים

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

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

הערכה נשארת אצלכם ללא תלות בשאלה אם נמשיך לעבוד או לא.

מקרה בוחן: איך הפסיקו ללכת לאיבוד מטרות ואירועים

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

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

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

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

לאחר ההטמעה שיעור הפניות שנספרו עלה מכ-שני שליש ל-97%, והפער מול יומן הפניות נכנס לתחום שגיאת המדגם. כפילויות האירועים ירדו מ-18% לאפס, והדוחות הפסיקו לנפח את ההמרה.

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

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

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

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

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

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

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

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

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

באתר יש כמה מונים — איך לא לכפול המרות?

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

הזמנות טלפוניות נכנסות לסטטיסטיקה?

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

מה כוללת הבדיקה לפני ההפעלה?

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

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

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

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

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