רמת קושי 3

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

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

אסף טרפיקנט | 05 אוגוסט, 2020
הורדת ספר

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

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

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

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

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

  1. נכנסים לגוגל אנליטיקס
  2. פותחים את הדוח Transaction Performance תחת ה E-commerce.
  3. הדוח הזה מציג את רשימת העסקאות.
  4. בוחרים בטווח תאריכים למעלה, תאריך של יום אחד ספציפי. איזה שבא לכם, רצוי מהתקופה האחרונה.
  5. מיון ברירת המחדל של הדוח הזה הוא לפי שווי העסקה. זה לא מעניין. אז הקליקו על הכותרת של Transaction ID על מנת לראות את העסקאות ממוינות לפי מספר העסקה.
  6. מתחת לטבלה, יש הגדרה של כמה שורות אתם רוצים לראות. פתחו את זה למקסימום האפשרי שמתאים לכם.
  7. אתם אמורים לקבל משהו כזה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בגליון האקסל שיצאתם נתונים מה 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. המשתמש חוסם את גוגל אנליטיקס – או שהוא חוסם קוקיז. כל הטרנזקציות שלו נרשמות כמובן ב Back-end אבל לא בגוגל. ישנן כמה שיטות למדוד האם למשתמש יש או אין חוסם קוקיז/פרסומות וכיו"ב.
  2. אספתם יותר מדי מידע על כל משתמש וזה חרג מכמות המידע שניתן לאסוף על משתמש בסשן אחד (500 היטים). זה קורה שאתם משתמשים בגוגל אנליטיקס לאיסוף של מידע זבל על המשתמש כמו תנועות עכבר, מעקב אחרי גלילה וכו'. יש כלים אחרים בשביל זה.
  3. אתם שולחים את המידע על הטרנזקציה תוך כדי Redirect לדף התודה. וייתכנו מקרים שזה פשוט "נופל" בדרך. זה רחוק מלהיות מומלץ, ואני מעדיף כי את כל הפרטים תשלחו לגוגל בדף התודה עצמו ולא בדרך אליו.
  4. בעיות ביצועים בדף התודה – יותר מדי סקריפטים רצים בדף התודה, וגוגל אנליטיקס איכשהו מתועדף נמוך, כך שהמשתמש מספיק לצאת מדף התודה לפני שהסקריפט רץ. זה אומר שאתם צריכים לנקות את הדף התודה מזבל, לנתח את הביצועים ובעזרת Google Tag Manager לסדר את הסקריפטים לפי עדיפות. 
  5. האתר שלכם מבקש מהמשתמש לאשר או לא לאשר שמירת קוקיז. המשתמש מחליט להתעלם מההודעה או לדחות קוקיז – שום דבר לא יעבוד.

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

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

תגובות

Please Post Your Comments & Reviews

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

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

אסף טרפיקנט
רוצה לקרוא אחר כך?

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

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

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

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

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

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

  1. נכנסים לגוגל אנליטיקס
  2. פותחים את הדוח Transaction Performance תחת ה E-commerce.
  3. הדוח הזה מציג את רשימת העסקאות.
  4. בוחרים בטווח תאריכים למעלה, תאריך של יום אחד ספציפי. איזה שבא לכם, רצוי מהתקופה האחרונה.
  5. מיון ברירת המחדל של הדוח הזה הוא לפי שווי העסקה. זה לא מעניין. אז הקליקו על הכותרת של Transaction ID על מנת לראות את העסקאות ממוינות לפי מספר העסקה.
  6. מתחת לטבלה, יש הגדרה של כמה שורות אתם רוצים לראות. פתחו את זה למקסימום האפשרי שמתאים לכם.
  7. אתם אמורים לקבל משהו כזה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בגליון האקסל שיצאתם נתונים מה 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. המשתמש חוסם את גוגל אנליטיקס – או שהוא חוסם קוקיז. כל הטרנזקציות שלו נרשמות כמובן ב Back-end אבל לא בגוגל. ישנן כמה שיטות למדוד האם למשתמש יש או אין חוסם קוקיז/פרסומות וכיו"ב.
  2. אספתם יותר מדי מידע על כל משתמש וזה חרג מכמות המידע שניתן לאסוף על משתמש בסשן אחד (500 היטים). זה קורה שאתם משתמשים בגוגל אנליטיקס לאיסוף של מידע זבל על המשתמש כמו תנועות עכבר, מעקב אחרי גלילה וכו'. יש כלים אחרים בשביל זה.
  3. אתם שולחים את המידע על הטרנזקציה תוך כדי Redirect לדף התודה. וייתכנו מקרים שזה פשוט "נופל" בדרך. זה רחוק מלהיות מומלץ, ואני מעדיף כי את כל הפרטים תשלחו לגוגל בדף התודה עצמו ולא בדרך אליו.
  4. בעיות ביצועים בדף התודה – יותר מדי סקריפטים רצים בדף התודה, וגוגל אנליטיקס איכשהו מתועדף נמוך, כך שהמשתמש מספיק לצאת מדף התודה לפני שהסקריפט רץ. זה אומר שאתם צריכים לנקות את הדף התודה מזבל, לנתח את הביצועים ובעזרת Google Tag Manager לסדר את הסקריפטים לפי עדיפות. 
  5. האתר שלכם מבקש מהמשתמש לאשר או לא לאשר שמירת קוקיז. המשתמש מחליט להתעלם מההודעה או לדחות קוקיז – שום דבר לא יעבוד.

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

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

תגובות

Please Post Your Comments & Reviews

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

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