מחפשים מומחה גוגל אנליטיקס כי הקמפיין מדווח על המרות, אבל לא ברור מה העסק קיבל? אני דן גיל, מומחה Google Ads ו־PPC מאז 2012. אני בודק את שרשרת המדידה בין האתר, GA4 ו־Google Ads כדי להפריד בין פעולה אמיתית, אירוע שנשלח והמרה שמשמשת להחלטות פרסום. תכולת הבדיקה והיישום נקבעת מראש לפי הבעיה והגישה למערכות.
תוכן עניינים — מעבר לנושא שמעניין אתכם
מתי כדאי לבדוק את GA4 עם מומחה?
הבדיקה מתאימה כשיש החלטה עסקית שתלויה במדידה שאינכם בטוחים בה. למשל, לפני הגדלת תקציב, אחרי החלפת אתר או כאשר פניות בפועל אינן מתיישבות עם הדוחות. המטרה היא לדעת אילו מסקנות אפשר להסיק ומה צריך לאמת, ולא להוסיף אירועים רק כדי למלא את המסך בנתונים.
- טופס מגיע לעסק אבל לא נראה באירועים הרלוונטיים.
- נרשמות כמה פעולות על פנייה אחת.
- לחיצה על WhatsApp או טלפון מוצגת כאילו הייתה שיחה או ליד מאושר.
- דף תודה נספר גם ברענון או בביקור חוזר.
- קיים חיבור ל־Google Ads, אך לא ברור איזו פעולה משמשת לבידינג.
- אתר, טופס או מנגנון הסכמה השתנו, ולא בוצעה בדיקה מסודרת מחדש.
אם עדיין לא מכירים את המונחים, מדריך GA4 למדידת אתר וקמפיינים מסביר את הבסיס. כאן המיקוד הוא בבדיקה המקצועית, בתוצרים שלה ובאופן שבו מגדירים את העבודה.
מה בודקים בפועל?
מתחילים בפעולה שהעסק רוצה לקבל, ורק אחר כך בודקים את התגים והדוחות. אירוע בשם generate_lead אינו מוכיח שנוצר ליד; צריך להבין מה גרם לו להישלח. כאשר יש גישה מתאימה, מצליבים את הפעולה באתר, אות המדידה ורישום הפנייה או ההזמנה במערכת העסקית.
| שכבה | השאלה בבדיקה | תוצר שימושי |
|---|---|---|
| הגדרה עסקית | מה נחשב פנייה, רכישה או שלב ביניים? | רשימת פעולות והגדרות מוסכמות |
| האתר | מה קורה בהצלחה, בשגיאה ובניסיון חוזר? | מסלולי בדיקה ותיעוד התנהגות |
| הטמעה | מה מפעיל את האירוע והאם הוא מוכפל? | מיפוי תגים, טריגרים ומקור האירוע |
| GA4 | אילו אירועים נקלטים ובאיזה הקשר? | ממצאים עם ראיות ומגבלות |
| Google Ads | מה מיובא ומה משמש להחלטות הקמפיין? | מפת יעדים והבחנה בין שלבים |
| העסק | האם נוצרה פנייה ומה איכותה? | צורך בהצלבה או במדידת המשך |
הבדיקה אינה מבטיחה שכל הפערים ייעלמו. היא אמורה להבהיר מה ידוע, מה אינו ידוע ומהי הפעולה הבאה. אם לא ניתנה גישה למערכת שמקבלת את הפנייה, לא מסמנים את קבלת הפנייה כמאומתת.
אירוע, אירוע מרכזי והמרה: שלושה דברים שצריך לחבר
ב־GA4 אירוע מתעד פעולה. אירוע מרכזי, Key Event, מסמן פעולה שחשובה לעסק. אפשר ליצור המרה ב־Google Ads על בסיס אירוע מרכזי מתאים. ההבחנה מתוארת בתיעוד Google על אירועים מרכזיים והמרות. השמות אינם תחליף להחלטה מהו השלב העסקי הנמדד.
לכן לפני שינוי יעד בקמפיין מבררים אם הוא מייצג התחלת מילוי, פנייה שהתקבלה או שלב מתקדם יותר. אירועי עזר יכולים לעזור להבין את המסלול, בלי להפוך כל אחד מהם ליעד אופטימיזציה. שינוי ההגדרה מתועד כדי שיהיה אפשר לפרש נכון את הדוחות שאחריו.
תהליך עבודה: מהשאלה ועד בדיקת קבלה
העבודה מתחילה בהיקף שאפשר לבדוק. “כל המדידה לא טובה” היא נקודת פתיחה לשיחה, אבל אינה משימה מוגדרת. מנסחים שאלה, בוחרים מסלול ומוודאים שיש דרך לראות את התוצאה בכל שלב. לאחר מכן אפשר להרחיב למסלולים נוספים לפי הממצאים.
- מגדירים את הבעיה: מה העסק רואה, באיזה דוח ובאיזו תקופה.
- ממפים נכסים והרשאות: אתר, נכס GA4, חשבון Ads, GTM ומערכת עסקית לפי הצורך.
- בוחרים תרחישי בדיקה: הצלחה, שגיאה, ניסיון חוזר ומצבי שימוש רלוונטיים.
- אוספים ראיות: מה קרה באתר, מה נשלח ומה התקבל.
- מסווגים ממצאים: תקלה מאומתת, החלטת הגדרה, מגבלת נתונים או שאלה להמשך.
- מגדירים יישום: מי אחראי, מה מותר לשנות ומהו תנאי הקבלה.
- בודקים לאחר שינוי שסוכם: מוודאים שהבעיה טופלה ושמסלול הפנייה נשאר תקין.
DebugView של Google עוזר לצפות באירועים בזמן בדיקה כשמצב ניפוי מופעל. היעדר אירוע מחייב לבדוק גם את סביבת הבדיקה וההסכמה; הוא אינו מוכיח לבדו שהתג חסר. אין לעקוף בחירה של משתמש כדי לייצר אות מדידה.
מטריצת קבלה לדוגמה: טופס פנייה
הטבלה היא תבנית מקצועית, לא תוצאה של בדיקה בחשבון לקוח. לפני השימוש מתאימים אותה למערכת ולמשמעות המדויקת של “פנייה התקבלה”. המטרה היא לקבוע מראש מה נחשב תקין, במקום להחליט לפי הנתון שנראה לאחר ההרצה.
| תרחיש | מה צריך לבדוק? | מתי משאירים את הממצא פתוח? |
|---|---|---|
| שדות חסרים או שגויים | אין סימון של פנייה מוצלחת | לא נבדק מנגנון השליחה בפועל |
| שליחה מוצלחת | המסירה ואירוע ההצלחה תואמים להגדרה | אין גישה למקום שבו הפנייה מתקבלת |
| לחיצה חוזרת | אין ספירת הצלחה נוספת ללא פעולה חדשה | לא ברור כיצד האתר מונע כפילות |
| חזרה לדף תודה | לא מסיקים שנוצר ליד נוסף רק מהצפייה | הטריגר מבוסס כתובת בלבד ללא בדיקה |
| קליק ל־WhatsApp | האירוע מתאר פתיחת קשר | אין נתון על שיחה או פנייה שהתקבלה |
| בחירת הסכמה שונה | ההתנהגות תואמת את המימוש המוסכם | לא תועדו המצבים שנבדקו |
ממצא שימושי יכלול: תאריך, מסלול, פעולה צפויה, תוצאה שנצפתה, ראיה, השפעה אפשרית, אחראי לטיפול ותנאי לבדיקה חוזרת. “הכול תקין” בלי פירוט אינו מאפשר להמשיך לעבוד בביטחון.
מה כלול באבחון ומה צריך להגדיר בנפרד?
אני ממקד את הבדיקה במדידה שמשמשת לפרסום ולקבלת החלטות. היקף ההטמעה או התיקון נקבע בנפרד לפי המערכת והגישה. שינוי בקוד האתר, רכיב מסחר, CRM, מדידה בצד שרת או פרויקט נתונים רחב אינם נחשבים כלולים רק מפני שהם משפיעים על GA4.
| עבודה | מה מגדירים לפני התחלה? |
|---|---|
| אבחון מדידה | נכסים, מסלולים, ראיות ותוצר מסכם |
| שינוי ב־GA4 או ב־GTM | הרשאה, תכולת השינוי ובדיקת קבלה |
| פיתוח באתר או במערכת חיצונית | בעל אחריות, תלות וסביבת בדיקה |
| בדיקת רכישות | שלבי הזמנה, מקור אמת וכיסוי תרחישים |
| מעקב לאחר תיקון | תקופה, דוחות ומי מקבל החלטה |
לבדיקת מערכת הפרסום כולה מתאים אודיט Google Ads. ליישום המרות בקמפיין ראו מעקב המרות בגוגל אדס, ולתשתית התגים ראו מדריך Google Tag Manager.
מידע אישי והרשאות: חלק מתכנון המדידה
אין לשלוח שמות, כתובות אימייל, מספרי טלפון אישיים או תוכן הודעות ל־GA4. גם כתובת עמוד ופרמטרים עלולים להכיל מידע מזהה. הנחיות Google למניעת העברת מידע אישי מבהירות מדוע בודקים את תוכן השדות שנשלחים ולא רק את שם האירוע.
לבקשת גישה מגדירים מה נדרש לכל מערכת ולמי יש בעלות. אין צורך להעביר חשבון אישי לספק. מידע עסקי לבדיקה צריך להיות מצומצם למה שנחוץ; דוגמה עם פרטים מוסתרים עדיפה על שליחת רשימת לקוחות בשיחה ראשונית.
מה להכין לפני שפונים?
שלחו כתובת אתר, תיאור קצר של הבעיה, המערכת שבה רואים אותה והפעולה שחשוב למדוד. ציינו אם בוצע לאחרונה שינוי באתר, בטופס או בקמפיין. אם יש צילום מסך, הסתירו מידע אישי ופרטי לקוחות. אין צורך להכין מפרט טכני מלא כדי להתחיל.
העבודה היא ישירות מולי, במסגרת ההתמחות שלי בפרסום ובמדידה עבור Google Ads. אפשר לקרוא על הניסיון של דן גיל או לפנות לתיאום בדיקת התאמה. לאחר הבנת המצב אפשר להגדיר תכולה מציאותית, תוצרים ואחריות לפני תחילת העבודה.

