התקנת מונים: איך לבדוק אותה בחמש דקות
איך לבדוק התקנת מונים בחמש דקות: מה לבדוק בקוד, איך להשוות מול מקור אמת, למה המספרים לא מסתדרים ומה עושים כשהמונה לא עובד.
צוות העריכה של ADS Beastפורסם 6 דקות קריאה
התקנת מונים נבדקת בחמישה צעדים: קוד בכל העמודים, אירוע נשלח פעם אחת, מזהה עקבי, השוואה מול מקור אמת משלכם, ובדיקת הגדרות ההמרה. חמש דקות מספיקות כדי לדעת אם יש בעיה. לא מספיקות כדי לדעת אם הנתונים בדוחות כבר הופיעו.
בקצרה
- הבדיקה עצמה קצרה. הופעת נתונים בדוחות תלויה בפלטפורמה ובסוג האירוע.
- קודם משווים מול מקור אמת משלכם, רק אחר כך נוגעים בקמפיינים.
- מזהה עקבי (transaction או order ID) הוא תנאי להשוואה, לא תוספת.
- המרה ראשית ומשנית נספרות אחרת, וזה יוצר פערים מדומים.
מה בודקים בחמש דקות אחרי התקנת מונים
בודקים שלושה דברים בסיסיים: שהקוד נטען בכל העמודים הרלוונטיים, שכל אירוע נשלח פעם אחת, ושהמזהה שנשלח זהה למזהה שיש לכם במקור האמת. אם שלושתם תקינים, ההתקנה עובדת. אם אחד מהם שבור, שום דוח לא יעזור.
הבדיקה הזאת לא דורשת גישה לכלים מיוחדים. היא דורשת רשימה קצרה של מה לפתוח ומה להשוות, וסדר עבודה שלא מדלג על שלבים.
חמשת הצעדים בסדר
- פותחים את דף הבית, דף מוצר או שירות, דף תודה או סיום רכישה, ועמוד נחיתה מקמפיין. מוודאים שהקוד נמצא בכולם ולא רק בבית.
- מבצעים פעולה אחת ידנית (הזמנה, שליחת טופס) ורושמים את המזהה שקיבלתם.
- בודקים שהאירוע נשלח פעם אחת ולא פעמיים, ושהוא נושא את אותו מזהה.
- משווים בין המספר שרואה המערכת לבין מקור האמת: מספר ההזמנות בקופה או מספר הלידים בטופס.
- פותחים את הגדרות ההמרה במערכת ובודקים סוג המרה וחלון המרות לפני שמסיקים משהו.
אם הפער גדול, חוזרים להגדרות ולמזהים. לא נוגעים בקמפיין.
איך מזהים שהמונה ספר את אותה המרה פעמיים
משווים בין מספר ההמרות במערכת לבין מספר הפעולות הייחודיות אצלכם, לפי מספר הזמנות או מזהי עסקה. אם המערכת מראה יותר פעולות ממה שיש לכם בפועל, יש חשד לספירה כפולה. זה חשד, לא הוכחה.
בגוגל אדס, המרה חוזרת עם אותו transaction או order ID מקבלת דה-דופליקציה. מזהה זהה לא מאחד בין פעולות המרה שונות. גם בדפדפן וגם בהעלאה מהשרת צריך לשלוח מזהה עקבי. בלי מזהה עקבי אין בכלל מה להשוות.
מה באמת מוכיח דה-דופליקציה
ירידה במספר ההמרות אחרי שינוי היא לא הוכחה. זו השערה עד שבודקים את האירועים, המזהים, המקורות והאירועים. הסדר הזה חשוב: קודם מאתרים את מקור הפער, אחר כך משנים, ורק אז מודדים שוב.
למה מספר ההמרות במערכת שונה ממספר ההזמנות בפועל
הפער יכול לנבוע מאירועים כפולים, מאירועים שלא נרשמו, מחלון המרות שונה, או מההבחנה בין המרה ראשית למשנית. כל אחד מהגורמים האלה נראה כמו "המונה לא עובד", אבל כל אחד דורש תיקון אחר.
בגוגל אדס רק המרות ראשיות נכנסות לעמודת ההמרות ולמכרז. המשניות מופיעות בנפרד. השוואה של העמודה הלא נכונה מול מספר ההזמנות יוצרת פער מדומה, גם כשההתקנה מושלמת.
מאיזה מקור מגיע כל פער
| סימן בשטח | גורם סביר | מה בודקים קודם |
|---|---|---|
| יותר המרות מאשר הזמנות | אירוע כפול או מזהה לא עקבי | שהאירוע נשלח פעם אחת ושה-ID זהה |
| פחות המרות מאשר הזמנות | אירוע שלא נרשם או המרה משנית | שהאירוע נשלח ושהוא מוגדר כראשי |
| פער שגדל עם הזמן | חלון המרות שונה בין המערכות | חלון ההמרות בשני הצדדים |
| פער קטן וקבוע | הגדרת המרה ראשית מול משנית | איזו עמודה משווים |
הטבלה הזאת כלי אבחון, לא פסק דין. כל שורה דורשת אימות מול הנתונים שלכם.
כמה זמן לוקח עד שההמרות נקלטות
בדיקת הקוד עצמה היא עניין של דקות. הופעת נתונים בדוחות תלויה בפלטפורמה ובאירוע. לכן "חמש דקות" מתייחסות לבדיקת ההתקנה, לא לבדיקת הדוחות.
בגוגל אדס חלון ההמרות נקבע כברירת מחדל ל-30 יום לפי קליק, וניתן לכוונון בין 1 ל-90 יום. השוואה עם מקור חיצוני חייבת להתחשב באותו חלון. אחרת אתם משווים שתי תקופות שונות ומסיקים מסקנות משגעות.
אם אין נתונים בכלל, בודקים שני דברים: שהאירוע נשלח, ושהוא מוגדר כהמרה ראשית ולא משנית. אחת מהשתיים כמעט תמיד מסבירה את ההיעלמות.
איך משווים נכון בין המערכת למקור אמת
מקור אמת הוא המספר שאתם סומכים עליו מבחינה עסקית: הזמנות בקופה, לידים בטופס, חשבוניות. ההשוואה צריכה להיות על אותה תקופה, אותו חלון המרות ואותו סוג המרה. בלי שלושת התנאים האלה אין השוואה.
בפועל, רוב הפערים שמדווחים כבאג הם פערי הגדרה. לכן מתחילים מהגדרות, מזהים ומקורות, ורק בסוף בודקים את הקמפיין. אם עוברים על הסדר הזה, רוב הבעיות נפתרות בלי לגעת בתקציב.
מי שרוצה לראות את כל שרשרת הנתונים במקום אחד, כולל השוואה בין מקורות, יכול לעבוד עם דוחות מעקב ותשלומים במקום אחד. שם רואים את התמונה המלאה לפני שמחליטים מה לתקן.
מה עושים כשהבדיקה מראה שהמונה לא עובד
מתחילים מהדברים הפשוטים: האם הקוד נמצא בכל העמודים, האם האירוע נשלח בזמן הנכון, והאם המזהה קבוע. אחר כך בודקים את הגדרות ההמרה במערכת, כולל סוג ההמרה וחלון ההמרות, ומשווים שוב מול מקור אמת.
אם משנים משהו, מחכים לראות שהנתונים מתעדכנים לפני שמסיקים שהבעיה נפתרה. שינוי בהגדרה לא משנה את הנתונים שכבר נאספו, ולכן ההשוואה צריכה להיות על תקופה שאחרי השינוי.
מה לא לעשות
לא מכבים קמפיין בגלל פער שלא הוסבר. לא משנים תקציב לפני שיודעים אם הבעיה בקוד, במזהה או בהגדרה. לא מסיקים מסקנות על ביצועים מנתונים שלא עברו בדיקת התאמה.
איפה עוד נוצרים פערים בין המערכות
פערים בין מערכות הם לא תמיד תקלה בהתקנה. חלקם נובעים מהבדל בהגדרות בין הפלטפורמות, חלקם מהבדל באופן שבו כל מערכת מייחסת פעולה. כשמבינים את המקור, קל יותר להחליט אם בכלל צריך לתקן.
אם הפער הוא בין GA4 לבין ממשק הפרסום, יש סיבות מובנות לכך, והן מתוארות בפער בין GA4 לממשק הפרסום ואיך מאתרים אותו. אם מדובר בהמרות שנשלחות מהשרת, המרות API: מה זה נותן ומה זה לא מחליף מסביר מה השיטה פותרת ומה נשאר באחריותכם.
כשמדובר בשיחות טלפון, מעקב שיחות: איך לקשר שיחה לקמפיין מראה איך שיחה הופכת לאירוע שאפשר להשוות מולו. ואם הפער הוא בין חשבון הפרסום ל-CRM, מספרי חשבון הפרסום לא תואמים ל-CRM: איך מאתרים ומתקנים מפרק את המקורות לפער.
למי שבונה את המערכת מאפס, אנליטיקה מקצה לקצה בלי קבלן חיצוני: הסט המינימלי מציג את הרכיבים ההכרחיים, כולל תיוג קישורים, כדי שההשוואה תהיה אפשרית מלכתחילה.
למה בדיקת מונים צריכה להיות שגרה
התקנה חד-פעמית נשברת בשקט. עדכון תבנית, שינוי טופס, הוספת עמוד נחיתה, מעבר בין ספקי תשלום: כל אחד מהם יכול לנתק אירוע בלי שאף אחד ישים לב. הבדיקה הקצרה אחרי כל שינוי כזה זולה יותר מתיקון קמפיין שהתבסס על נתונים שגויים.
חמש דקות פעם בתקופה, עם אותה רשימת צעדים, נותנות ביטחון שהמספרים שאתם מחליטים לפיהם הם המספרים הנכונים.
הצעד הבא
בחרו פעולה אחת שאתם סומכים עליה (הזמנה או ליד), בצעו אותה ידנית, ורשמו את המזהה שלה. אחר כך השוו אותה מול מה שהמערכת ראתה, ותעדו את הפער אם יש כזה. את כל שרשרת הבדיקה, מהאירוע ועד ההשוואה בין המקורות, אפשר לנהל במקום אחד: בדיקת מעקב והשוואת מקורות.