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

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

גוגל מתייחסת לפרוסה גדולה ולא מדודה כרגיל: מידול התנהגותי עבור מצב הסכמה אינו מופעל עד שנכס מתועד לפחות 1,000 אירועים ביום עם analytics_storage='denied' למשך 7 יום לפחותמתחת לכך, נתונים חסרים נשארים חסרים.

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

מה באמת מודד התאמת רכישה

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

שלב 1: משיכת שתי טבלאות שניתן לחבר לפי מזהה הזמנה

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

• backend: מזהה הזמנה, חותמת זמן שנוצרה באזור הזמן של הדיווח של הנכס, ערך הזמנה על אותו בסיס מס ומשלוח שהגדרת ב-GA4, אמצעי תשלום, מכשיר, מדינה, סטטוס.
• GA4: ייצוא BigQuery, לא ממשק המשתמש. שאילתה purchase אירועים עם ecommerce.transaction_id, event_timestamp, ecommerce.purchase_revenue, קטגוריית מכשיר ומקור תנועה.

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

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

שלב 2: בטא את הפער בשלוש דרכים, לא אחת

אחוז חודשי יחיד מסתיר הכל. חשב את שלושתם:

1. פער בין מספר הזמנות: (הזמנות backend פחות רכישות GA4 תואמות) / הזמנות backend. זה מבודד אובדן מעקב.
2. פער בהכנסות: אותו חישוב על הערך. אם פער הספירה הוא 3% ופער ההכנסות הוא 11%, אין לך בעיית מעקב, יש לך בעיה בהגדרת הערך (מס, משלוח, הנחות, מטבע, כרטיסי מתנה).
3. שונות פער יומית: שרטטו את הפער היומי בין הזמנות לספירה. קו ישר פירושו סיבה מבנית כגון הסכמה או חסימות. קפיצות משמעותן פריסות, פרצי קמפיינים או תקרית אצל ספק התשלומים.

שלב 3: פירוק הפער לסיבות בעלות שם

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

שניים ראויים לטיפול נוסף. transaction_id ביטול כפילויות עובד רק על זרמי אינטרנט, לא על זרמי אפליקציות, וגוגל מזהירה ששליחת מחרוזת ריקה גורמת ל-Analytics לבצע ביטול כפילויות כל רכישת נשיאת אירוע transaction_id=''באג אחד כזה יכול למחוק את רוב היום. בנפרד, רשימת ההפניות הלא רצויות מוגבלת ל-50 דומיינים לכל זרם נתונים, דבר שפוגע אם משתמשים במספר סוכנויות רכישה, ארנקים ודפי בנק.

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

שלב 4: קבעו סובלנות שתוכלו להגן עליה

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

אלו הם ספי הפעולה שלנו, לא תקן בתעשייה. הנקודה היא הקובעת: 3% בלתי מוסברים גרועים יותר מ-8% מוסברים.

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

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

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

שתי עובדות אזוריות מזיזות את המספרים.

גם בטורקיה ניתן להסכים, אך ללא רשת הביטחון של גוגל. רשות הגנת המידע הטורקית קנסה מפעיל אתר אינטרנט בסכום של 300,000 לירות שטרלינג בהחלטה 2022/1358 (23 בדצמבר 2022) בגין הפעלת קובצי Cookie של פרסום ושיווק ללא בסיס חוקי, ודרשה הצטרפות פעילה לקובצי Cookie שאינם חיוניים. אתרים טורקיים רבים ענו עם באנר שחוסם לחלוטין את תגית גוגל במקום באנר ששולח אותות הסכמה. הבחנה זו יקרה: מידול זקוק ל... analytics_storage='denied' אירועים קיימים. באנר שלא מפעיל דבר לא נותן לגוגל שום אפשרות לדגם, כך שהנתונים נעלמים במקום להיות מוערכים.

משלוחי 3DS טורקיים מחזירים את המוצר לקונה בדואר. עם iyzico, הסוחר מציג דף 3DS מפוענח, ולאחר אישור OTP, iyzico מפנה אל חשבון הסוחר. callbackUrl עם status, paymentId ו mdStatusהחזרה מונעת POST היא בדיוק מה שגוגל מכנה כמפרקת מדידה חוצת דומיינים, מכיוון שהפניות יכולות להסיר _gl לפני שהיעד נטען. אם הפער שלך נמצא בתשלומי כרטיס אשראי וכמעט אפס בתשלום במזומן במשלוח, זו הסיבה.

שתי טענות שחזרו על עצמן רבות ולא הצלחנו לאמת

"ספארי מגבילה עוגיות של צד ראשון ל-7 ימים." לא מדויק. התיעוד של WebKit אומר ש-ITP מוחק קובצי Cookie של JavaScript ואחסון אחר הניתן לכתיבה באמצעות סקריפטים לאחר 7 ימים של... אין אינטראקציה עם המשתמש, ומגביל בנפרד עוגיות JavaScript ל-24 שעות כאשר דף הנחיתה הגיע באמצעות קישוט קישור מדומיין מסווג. הבדיקות של סימו אהבה מצאו שהשעון פועל לפי ימי שימוש בדפדפן, ולא לפי ימים בלוח השנה, כך שלקוח חוזר יכול להחזיק מזהה הרבה מעבר לשבוע.

פער של 5% מקובל. לא מצאנו מקור בגוגל לנתון הזה. הוא מופץ בבלוגים של ספקים ובתשובות בפורומים. השתמשו בו כפולקלור, לא כסף.

היכן שיטה זו מתקלקלת

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

שאלות נפוצות

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

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

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

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

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

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

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

האם נוכל להריץ מבחני A/B כל עוד הפער מעל 10%? הפעילו אותם על מדדים יחסיים שנמדדו בתוך כלי הבדיקה, אך אל תדווחו על השפעה מוחלטת על ההכנסות מ-GA4 עד שהפער יפורק.

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

מקורות

• [GA4] מידול התנהגותי עבור מצב הסכמה, עזרה של Google Analytics
• [GA4] מזעור אירועים מרכזיים כפולים באמצעות מזהי עסקאות, עזרה של Google Analytics
• [GA4] הפניות לא רצויות, עזרה ב-Google Analytics
• [GA4] מדידה בין-דומיינים, עזרה ב-Google Analytics
• שליחת אירועי Measurement Protocol ל-Google Analytics ול-Google for Developers
• פרמטרים של מצב הסכמה, תיעוד פלטפורמת התגים של גוגל
• מניעת מעקב ב-WebKit
• הוסרה מגבלת תפוגה מעוגיות JavaScript בדפדפני WebKit, סימו אהבה
• KVKK Kurul karari 2022/1358, 23 בדצמבר 2022
• יישום 3DS, תיעוד למפתחים של iyzico