עסקאות איקומרס חסרות או שגויות בגוגל אנליטיקס - המדריך המלא [עודכן 2023]

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

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

לפני שמתחילים:

1. זה לא משנה עם איזו מערכת איקומרס אתם עובדים, מג'נטו, Shopify, Woocommerce או מערכת שפיתחתם בעצמכם. לשם פשטות הכתיבה אני פשוט אכתוב back-end. 
2. המצב תמיד לרעת גוגל אנליטיקס. כלומר, לא ייתכן שעסקה תירשם בגוגל אנליטיקס אבל לא תופיע לכם ב back-end. אם זה המצב, אז המפתח על סמים.
3. "אני עובד עם (פלאגין מוכן/שופיפיי/מערכת סגורה כלשהי) אין צורך לבדוק" – אחלה. בכל זאת, עשו את הבדיקה ויפה שעה אחת קודם.

שלב א' – בדיקת עסקאות קיימות

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

נכנסים לגוגל אנליטיקס 4 ל Explore ובונים דוח לפי האפיון הבא:

1. ברשימת הדיימנשנס, לבחור את Transaction ID
2. ברשימת המטריקות לבחור tax amount, shipping amount, purchase revenue, ecommerce quantity 
3. מוסיפים פילטר של transaction id לא שווה ל not set. 
4. מוודאים שבחרתם שיוצגו 50-100 שורות או כמה עסקאות שאשתם מצפים שיופיעו בדוח בטווח תאריכים מסויים.
5. בצד ימין הדוח יציג את רשימת העסקאות עם פירוט ההכנסות לכל עסקה.
6. בוחרים בטווח התאריכים תאריך של יום אחד ספציפי. איזה שבא לכם, רצוי מהתקופה האחרונה.
7. הקליקו על הכותרת של Transaction ID על מנת לראות את העסקאות ממוינות לפי מספר העסקה.

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

מה השגנו עד עכשיו? הבנה של כמה עסקאות "נפלו" לנו.

עכשיו מסתכלים על כמה עסקאות אקראיות מתוך הדוח הזה ומשווים את הנתונים המספריים שמוצגים לנו עם המספרים שיש לכם ב Backend, ובעיקר להשוות את ה Revenue (שווי העסקה), Shipping ו Quantity המייצג את מספר המוצרים בעסקה. במידה ויש חוסר התאמה עם המספרים ב Back-end, סביר להניח שהיא תהיה גורפת לכל העסקאות ולא רק לאחת.  ובמידה ויש בעיה כזו, הגורם הוא בדר"כ הטמעה לא טובה של ה E-commerce ויש לפנות למפתח. אבל לפני שאנחנו פונים אל המפתח, כדאי להיות קצת יותר מבושלים עם הבעיה.

מה השגנו עד עכשיו? בדיקת תקינות נתונים ברמת העסקה.

צוללים פנימה לעסקה ספציפית

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

1. בחרו את הדיימנשנס transaction id, item id, item name
2. בחרו את המטריקות item revenue, item quantity
3. הוסיפו פילטר של transaction id=12345 או כל מספר אחר של עסקה שאתם רוצים לתחקר.
4. הדוח יציג לכם את כל רשימת המוצרים בתוך עסקה מסויימת.

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

1. מוצרים מסויימים נשלחים עם מחיר אפס
2. לא משנה מה הלקוח קנה וכמה, תמיד הכמות של כל מוצר היא 1.
3. כל המחירים של המוצרים זהים.
4. לא משנה כמה מוצרים המשתמש קנה, בפועל תמיד מופיעים עד X מוצרים ולא יותר.
5. המשלוח מופיע כ"מוצר" עם עלות מה שמנפח לכם את מספר המוצרים בכל עסקה. אם היו 100 עסקאות היום, זה נראה בדוחות כאילו נמכרו מאה נמורצים יותר מהמציאות. זה "לא בסדר" או "כן בסדר". פשוט תצטרכו להחליט אם זה מתאים לכם או לא.

כך או כך, ממליץ גם לבדוק את ה SKU של המוצרים והשמות שלהם ולוודא שיש התאמה ל Backend.

מה השגנו עד עכשיו? בדיקת נתוני מוצרים בתוך עסקה ספציפית, ובדיקה ששם המוצר וה SKU תקינים.

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

שלב ב' – בדיקת שעון

זה החלק הכי נחמד שנסתר מעיני הרבה אנשים.

1. בחרו יום ספציפי ב Backend ויצאו את רשימת העסקאות לאקסל.
2. לכו לגוגל אנליטיקס, לאותו היום ולאותו הדוח שהוצאנו בשלב א' והסתכלו ברשימת העסקאות.
3. כל עסקה שמופיעה ב Back-end ולא מופיעה באנליטיקס, צבעו אותה באקסל.
4. חזרו לאנליטיקס, אבל הפעם שנו את טווח התאריכים ל 5 ימים כאשר היום הבעייתי ממוקם באמצע. כלומר, אם החלטנו לתחקר את ה 10 ליולי, הדוח באנליטיקס צריך להתייחס לתאריכים 8-12 ליולי.
5. חפשו שוב את העסקאות ה"חסרות".

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

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

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

שלב ג'- איתור עסקאות חסרות

עכשיו הגענו ל Money Time ולשאלה הכי חשובה – למה לעזאזל יש עסקאות שלא מופיעות בגוגל אנליטיקס?

האם הפיקסלים אשמים או האתר אשם?

הבדיקה הראשונה שהייתי עושה, זה לבדוק מה הכתובת של דף התודה. היא יכולה להיות נניח domain.com/transactionSuccess. הולך לדוח של Pages and screen ומסתכל כמה צפיות יש ב URL של דף התודה. נניח שיש 1000 View, זה אומר בגדול שיש כ 1000 עסקאות. אבל אם בדוחות האיקומרס יש לנו 700 עסקאות זה אומר שייתכן ומשהו מתפקשש בקוד ששולח את נתוני האיקומרס ואז אפשר להמשיך במאמר לשאר הפתרונות, ולדלג על הפסקה הבאה.

אבל(!), יצא כבר שגיליתי שדף התודה בעצמו מופיע מעט פעמים ביחס לכמות הטרנזקציות. כלומר, הדף נטען 500 פעמים בגלל בעיות ביצועים או השד יודע למה, ויש לי בבקאנד 600 עסקאות שנספרו. זה אומר ש 100 עסקאות פוספסו, לא כי הקוד לא תקין, אלא כי הדף לא נטען בכלל כמו שצריך! אז אם חסרים לי Pageviews ברור שגם כל מה שנגזר מזה יתפספס – כל המידע של העסקאות לא ישלח וכמובן כל הפיקסלים למיניהם של רשתות הפרסום. אז מה בודקים? קודם כל זמני טעינה של הדף, עומס של קוד, צמצום הקונטיינר של GTM וכו'. כך או כך, זו שיחה שאתם צריכים לנהל מול המפתח.
טיפ קטן: קחו בחשבון שייתכן שהבקאנד סופר עסקאות שבוצעו באופן אחר (נניח באמצעות הטלפון, או דרך דפים אחרים, שותפים וכו'), אז וודאו שאתם משווים עגבניות לעגבניות.

ממשיכים…

אז בהנחה וכמות ה Pageviews זהה לכמות העסקאות ב Backend, ועדיין חסרות עסקאות בדוחות האיקומרס, נחזור לאקסל.

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

1. כל העסקאות החסרות הן של PayPal או סולק ספציפי אחר, או כרטיס אשראי ספציפי.
2. לכל העסקאות יש הטבה שהופעלה,  כגון קוד קופון.
3. בכל העסקאות שנפלו יש משלוח בתשלום/בחינם.
4. כל העסקאות כוללות את אותו מוצר ספציפי (כמו מתנה שמתווספת בקופה), או סוג מוצר (נניח באנדלים, שזה אומר קבוצה של מוצרים שנמכרים כיחידה אחת כמו חבילת שי)
5. כל העסקאות שנפלו התרחשו באותן שעות (נניח בלילה, או בין 8-9 בבוקר או וואטאבר)
6. כל העסקאות שנפלו כוללות מעל X מוצרים (בעיה מאד מוכרת)
7. כל העסקאות שנפלו בעלות הכנסות מעל סכום X.

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

עסקאות הכוללת מעל X מוצרים

לגוגל אנליטיקס יש מגבלה של נפח המידע שנשלח  ב event אחד. הבעייה מחמירה באתרי סופרמרקט למיניהם ששם עסקה יכולה להכיל עשרות אם לא מאות מוצרים, ועל כל מוצר יש כל מיני Custom dimensions שהוספתם. איך יודעים? כל המידע שנשלח לגוגל אנליטיקס בקריאה אחת לא יכול לעבור משקל של 8kb שזה בערך 8200 תווים. זה אמור להספיק לכמה עשרות מוצרים ברמה בסיסית. במידה וזה המקרה וחרגתם מהמקסימום, אתם תראו בלשונית של ה Console ב DevTools בדפדפן, את ההודעה "Payload Size is too large" וגם יצויין המשקל הנוכחי של הקריאה ותדעו כמה צריך לצמצם. יש כמה דרכים לצמצם את הקריאה אבל זה רחוק מלהיות טריוויאלי או שאוכל לכסות את זה כאן. אחד הפתרונות אגב, זה לפצל את הטרנזציה לכמה טרנקזציות קטנות יותר או כל מיני תכמונים ותרגילים אחרים.

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

תרחישים נוספים ללא מידע

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

יש לכם שתי אופציות לחקור  את זה:

1. לעשות טסטים עם VPN, או ממכשירים שונים  או דפדפנים שונים שוב ושוב ושוב ולנסות לזהות מכנה משותף בין כל העסקאות שנפלו אם בכלל.
2. לשכלל את מערכת ה Backend שלכם כך שתאסוף עבור כל טרנזציה גם מידע טכני כמו דפדפן, כתובת IP, סוג Device, רזולוציית מסך וכו'. מסובך, מגעיל, לא פתרון אסתטי – אבל זה מה שיש.

ועוד קצת..

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

1. לקוח סיפר שכמות המוצרים שאנליטיקס דיווח גדולה מכמות המוצרים שנמכרה בפועל. מה שגיליתי זה שהמשלוח נשלח כמוצר נפרד. כלומר, עסקה שכללה מוצר אחד, נשלחה כעסקה עם שני מוצרים (מוצר+משלוח) שזה כמובן שגוי. משלוח אינו מוצר.
2. המשתמש חוסם את גוגל אנליטיקס – או שהוא חוסם קוקיז. כל הטרנזקציות שלו נרשמות כמובן ב Back-end אבל לא בגוגל. ישנן כמה שיטות למדוד האם למשתמש יש או אין חוסם קוקיז/פרסומות וכיו"ב. אפשר גם להעביר את המדידה לServer side במקום client-side.
3. אספתם יותר מדי מידע על כל משתמש וזה חרג מכמות המידע שניתן לאסוף על משתמש בסשן אחד (500 היטים). זה קורה שאתם משתמשים בגוגל אנליטיקס לאיסוף של מידע זבל על המשתמש כמו תנועות עכבר, מעקב אחרי גלילה וכו'. יש כלים אחרים בשביל זה.
4. אתם שולחים את המידע על הטרנזקציה תוך כדי Redirect לדף התודה. וייתכנו מקרים שזה פשוט "נופל" בדרך. זה רחוק מלהיות מומלץ, ואני מעדיף כי את כל הפרטים תשלחו לגוגל בדף התודה עצמו ולא בדרך אליו.
5. בעיות ביצועים בדף התודה – יותר מדי סקריפטים רצים בדף התודה, וגוגל אנליטיקס איכשהו מתועדף נמוך, כך שהמשתמש מספיק לצאת מדף התודה לפני שהסקריפט רץ. זה אומר שאתם צריכים לנקות את הדף התודה מזבל, לנתח את הביצועים ובעזרת Google Tag Manager לסדר את הסקריפטים לפי עדיפות. 
6. האתר שלכם מבקש מהמשתמש לאשר או לא לאשר שמירת קוקיז. המשתמש מחליט להתעלם מההודעה או לדחות קוקיז – שום דבר לא יעבוד.

פתרון נפוץ לבעיות שצוינו לעיל, הוא לא לשלוח את העסקה מהדף תודה, אלא מהשרת באמצעות Measurement Protocol או בכלל מעבר ל Server -side tagging. אמנם תקבלו מידע מדוייק אבל יש לזה יותר חסרונות מיתרונות ולכן אני מתייחס לזה כאל פתרון בעדיפות הכי נמוכה.

עסקאות כפולות

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

1. בדוח העסקות, כל עסקה מופיעה פעמיים או יותר. זה אומר שבדוח של ה Transaction, תראו 100 שורות במקום נניח 50. אז בהנחה וכל עסקה מדוייקת כשלעצמה, הבעיה היא ככל הנראה טריגרים שלא מוגדרים נכון ב GTM. בנוסף, יש מקרים בהם היוזר יכול לחזור לדף התודה ואז כל הפיקסלים והמידע ייטען שוב. זו תקלה והיא לא אמורה לקרות. ברגע שיוזר עוזב או סוגר את דף התודה, אסור לאפשר טעינה שלו מחדש, ואם זה קורה זו תקלת פיתוח חמורה שצריך לטפל בה. לדפי תודה בעסקאות איקומרס, חייב להיות זמן "תוקף" שבדר"כ נקבע סביב כמה שניות.
2. רשימת העסקאות תקינה, אבל בתוך כל עסקה, כל מוצר מופיע פעמיים – זו תקלה בקוד שאתם שולחים לגוגל אנליטיקס או ב GTM. קל לתקן יחסית.
3. רשימת העסקאות תקינה, בתוך כל עסקה מספר מוצרים תקין, אבל הסכומים כפולים – במקום שפריט יעלה 10 שח, כתוב שהוא עולה 20 שח. גם כאן, תקלה בקוד שאפשר לתקן יחסית בקלות.

תוספים ומערכות איקומרס סגורות

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

אם Pixel Your Site מפספס הרבה עסקאות באתר ה WooCommerce שלכם, סביר להניח שזו לא בעיית קונפיגורציה אלא שהתוסף פשוט לא מתאים לאתר שלכם. זה קורה כי עשיתם שינויים רבים בטמפלטים ושינויים בקוד. ברמה האישית, אני חושב ש Pixel Your Site הוא מוצר בינוני לגמרי שלא יכול להתמודד עם כל השינויים ב WP וב WOO ולא מתוחזק ברמה הראויה. אני ממליץ לא להשתמש בו ולפנות לאיש פיתוח שיעשה לכם את זה.

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

ו..אני חושב שזהו. עכשיו שימו את המאמר הזה ב Bookmarks ושלפו אותו כשיגיע הצורך.