מה Consent Mode v2 עושה בפועל?
Consent Mode הוא מנגנון טכני של תגי Google שמתאים את התנהגות התגים לבחירת המשתמש בבאנר ההסכמה. הוא לא באנר, לא מדיניות ולא ייעוץ משפטי. הוא מקבל ארבעה סיגנלים ומחליט לפיהם מה כל תג רשאי לעשות. גרסה 2, שפורסמה בנובמבר 2023, הוסיפה שני סיגנלים לשניים שהיו קודם.
ad_storage שולט באחסון לצורכי פרסום, כלומר קוקיז של Google Ads. analytics_storage שולט באחסון לצורכי אנליטיקה, כלומר הקוקי של GA4 שמזהה משתמש וסשן. ad_user_data קובע אם מותר לשלוח ל-Google נתוני משתמש לצורכי פרסום. לפי התיעוד הוא נדרש למקרי מדידה כמו Enhanced Conversions ומעקב המרות מבוסס תג. ad_personalization קובע אם מותר להשתמש בנתונים לפרסום מותאם אישית. בלעדיו רשימות רימרקטינג ב-Google Ads לא מקבלות נתונים. שני הסיגנלים האחרונים צריכים להיות מאושרים יחד כדי שפרסום מותאם אישית יעבוד.
מה ההבדל בין Basic לבין Advanced?
ביישום Basic תגי Google חסומים לחלוטין עד שהמשתמש מאשר. מי שדחה לא שולח כלום, לא קוקיז ולא פינגים. ב-GA4 אין על המשתמש הזה שום מידע. ב-Google Ads מודלינג ההמרות מתבסס לפי התיעוד על מודל כללי שמשתמש במשתנים גסים כמו סוג דפדפן, סוג פעולת ההמרה ושעה ביום.
ביישום Advanced התגים נטענים לפני הבאנר עם מצב ברירת מחדל "denied". כשהמשתמש דוחה, התגים שולחים פינגים ללא קוקיז. לפי התיעוד של Google הפינגים האלה כוללים חותמת זמן, user agent, referrer, ערך בוליאני של מצב ההסכמה, אינדיקציה אם היה מזהה קליק פרסומי (GCLID או DCLID) בכתובת, מספר אקראי שנוצר בכל טעינת עמוד ומידע על פלטפורמת ההסכמה. ל-GA4 נשלחים גם רזולוציית מסך וכתובת IP, שלפי Google אינה נשמרת. הפינגים האלה הם חומר הגלם למודלינג. זה ההבדל המעשי העיקרי: רק Advanced מאפשר מודלינג התנהגותי ב-GA4 ומודל ספציפי למפרסם ב-Google Ads.
עץ החלטה: מה קורה לפינג כשהמשתמש דוחה
עץ החלטה
מה קורה לפינג כשהמשתמש דוחה, לפי Basic או Advanced
GA4: אין נתונים ואין מודלינג התנהגותי.
Google Ads: מודל כללי בלבד
analytics_storage אין קוקי _ga. הפינג נשלח ל-GA4. משתמשים וסשנים ממודלים אם יש נפחad_storageאין קוקיז פרסום. פינג דרך דומיין ללא קוקיז צד שלישי. GCLID נשמר בכתובתad_user_data אין נתוני משתמש ל-Google Ads. Enhanced Conversions ו-user_id מושבתיםad_personalization אין פרסום מותאם. רשימות רימרקטינג לא מקבלות נתונים. המדידה ממשיכהמה נשלח, מה נמדד ומה ממודל בכל תרחיש?
בפרויקטים שלנו אנחנו בודקים את ההתנהגות הזו עם שני דפדפנים במקביל, אחד שמאשר ואחד שדוחה. אנחנו משווים את הפינגים ברשת (Network) ואת מה שמופיע בדוח Realtime. הטבלה הבאה מסכמת מה ראינו ומה התיעוד של Google קובע, לפי שלושה משתנים: סוג היישום, האם האתר עומד בתנאי הסף למודלינג ומה המשתמש בחר. "נפח מספיק" בטבלה מתייחס לתנאי הסף של Google ולא להערכה שלנו.
| תרחיש | מה נשלח מהדפדפן | מה נמדד ישירות | מה ממודל |
|---|---|---|---|
| Basic, המשתמש אישר | אירועים מלאים עם קוקיז של GA4 ו-Google Ads | הכל: משתמשים, סשנים, אירועים, המרות, ייחוס | אין צורך במודלינג |
| Basic, המשתמש דחה | כלום. התגים לא נטענים | כלום. המשתמש לא קיים ב-GA4 | GA4: אין. Google Ads: מודל כללי בלבד, אם החשבון עומד בסף של 700 קליקים בשבעה ימים לקבוצת מדינה ודומיין |
| Advanced, המשתמש אישר | אירועים מלאים עם קוקיז, זהה ל-Basic כשמאשרים | הכל, כמו בשורה הראשונה | אין צורך במודלינג |
| Advanced, המשתמש דחה, נפח מספיק למודלינג | פינגים ללא קוקיז: חותמת זמן, user agent, referrer, מצב הסכמה, אינדיקציה ל-GCLID, מספר אקראי לכל עמוד | ספירות אירועים (page_view, session_start, אירועי המרה) מופיעות בדוחות ללא זיהוי משתמש | GA4 בזהות דיווח Blended: משתמשים, משתמשים חדשים, סשנים ו-key events. Google Ads: מודל ספציפי למפרסם, ההמרות הממודלות נכנסות לעמודת Conversions |
| Advanced, המשתמש דחה, נפח לא מספיק | אותם פינגים ללא קוקיז | הפינגים נאספים אך הנתונים הממודלים אינם זמינים בדוחות עד שהפרופרטי נהיה זכאי | GA4: אין מודלינג התנהגותי. key events שאין להם מספיק נתונים לא מדווחים כממודלים ומיוחסים ל-Direct. Google Ads: מתחת ל-700 קליקים אין מודלינג מבוסס Consent Mode |
תנאי הסף של GA4 למודלינג התנהגותי, לפי התיעוד הרשמי: לפחות 1,000 אירועים ביום עם analytics_storage במצב denied במשך שבעה ימים לפחות, לפחות 1,000 משתמשים ביום ששולחים אירועים עם analytics_storage במצב granted בשבעה ימים לפחות מתוך 28 הימים האחרונים, Consent Mode מוטמע בכל עמודי האתר, התגים נטענים לפני הבאנר וזהות הדיווח מוגדרת ל-Blended. Google מציינת שגם עמידה בכל התנאים לא מבטיחה זכאות, כי המודל בוחן גם יחס משתמשים חדשים לחוזרים ויחס משתמשים לסשנים. אם הפרופרטי מפסיק לעמוד בתנאים, הנתונים הממודלים מפסיקים להיות זמינים.
חשוב לדייק מה ממודל ומה לא. ב-GA4 המודלינג ההתנהגותי משלים משתמשים, סשנים ומשתמשים חדשים. ספירות אירועים כמו page_view אינן ממודלות, אלא פשוט נהיות ניתנות לדיווח. הנתונים הממודלים אינם זמינים בקהלים, ב-User Explorer, בדוחות Retention, ב-Cohort Exploration ובייצוא ל-BigQuery. מי שעובד מול BigQuery רואה רק נתונים נצפים. לכן המספרים שם נמוכים מהממשק כשהמודלינג פעיל.
איך מבדילים בין ירידה טכנית לירידה עסקית?
ירידה טכנית נראית בדוחות כמו ירידה עסקית: פחות משתמשים, פחות סשנים, פחות המרות. ההבדל הוא במבנה שלה. ירידה טכנית מתחילה ביום מדויק, זה היום שבו הבאנר עלה לאוויר או שהוגדר "denied" כברירת מחדל. ירידה עסקית בדרך כלל מתפתחת לאורך זמן ומתואמת עם שינוי במדיה, בעונתיות או במחיר.
הבדיקה הראשונה היא מקור אמת שאינו תלוי בהסכמה. מספר הלידים ב-CRM, מספר ההזמנות במערכת הניהול של האתר או כמות הקליקים בחשבון Google Ads אינם דורשים קוקי בדפדפן. אם GA4 מראה ירידה של 30 אחוז במשתמשים (דוגמה) ומערכת ההזמנות מראה כמות הזמנות יציבה, הירידה טכנית. אם שני המקורות יורדים יחד, הירידה עסקית או שיש בעיה בטראפיק עצמו.
הבדיקה השנייה היא היחסים הפנימיים בדוח. כשחלק מהמשתמשים מפסיק להיות מזוהה, שיעור המשתמשים החדשים עולה, ממוצע הסשנים למשתמש משתנה, נתח Direct ו-(not set) גדל ונתח ההמרות המיוחס לפייד יורד בעוד שהקליקים ב-Google Ads לא השתנו. שינוי ביחסים האלה ללא שינוי בטראפיק הנכנס מצביע על מדידה, לא על שוק.
הבדיקה השלישית היא סימני המודלינג בממשק. ב-GA4 אייקון איכות הנתונים בראש הדוח מציג אחד משלושה מצבים: "Including estimated user data", "Excluding estimated user data" או "Estimated user data unavailable" עם הסיבה. אם המודלינג נכנס לפעולה בתאריך מסוים, הדוחות יראו קפיצה למעלה בתאריך הזה, שאינה אמיתית גם היא. ב-Google Ads ההמרות הממודלות נכנסות לעמודת Conversions בלי סימון נפרד. לפי התיעוד נתוני הייחוס מתעדכנים עד 12 ימים אחורה. לכן השוואה של השבוע האחרון תמיד נראית חלשה מהמציאות.
שלבי בדיקה מסודרים
- לאתר את התאריך המדויק שבו עלה הבאנר או שונה מצב ברירת המחדל. לסמן אותו כ-Annotation ב-GA4 ובדוחות הלקוח.
- לפתוח GA4 בשני מצבי זהות דיווח, Blended ו-Observed. להשוות את מספר המשתמשים לאותה תקופה. הפער ביניהם הוא נתח המודלינג.
- להשוות המרות ב-GA4 ו-Google Ads מול מספר הלידים או ההזמנות במערכת הפנימית, לפני ואחרי התאריך.
- לבדוק ב-Google Ads את יחס ההמרות לקליקים לפני ואחרי. קליקים יציבים עם המרות יורדות הם סימן טכני.
- לבדוק את שיעור ההסכמה בפלטפורמת הבאנר. שיעור דחייה גבוה יותר מהצפוי מסביר חלק גדול מהירידה.
איפה נגמרת הטכנולוגיה ומתחיל החוק?
Consent Mode לא קובע אם צריך לשאול את המשתמש, מה לשאול ואיך לנסח. הוא רק מתרגם תשובה שכבר ניתנה להתנהגות של תגים. ההחלטה מה דורש הסכמה, האם ברירת המחדל יכולה להיות "granted" ואיזה מידע נחשב מידע אישי, היא החלטה משפטית של בעל האתר עם הייעוץ המשפטי שלו.
בישראל המסגרת היא חוק הגנת הפרטיות. תיקון 13 לחוק, שנכנס לתוקף באוגוסט 2025, הרחיב את חובות השקיפות, הגדיר מחדש מהו מידע אישי והעמיד לרשות להגנת הפרטיות כלי אכיפה רחבים יותר. אנחנו לא עורכי דין ולא נותנים ייעוץ משפטי. מה שאנחנו כן אומרים ללקוחות: הגדרת ברירת המחדל בתג (denied או granted) צריכה להגיע מהייעוץ המשפטי. אנחנו מיישמים אותה טכנית. ההשלכות של ההחלטה הזו על הדוחות הן בדיוק מה שתואר למעלה. לכן כדאי שהיועץ המשפטי והאנליסט ישבו באותו חדר לפני ההעלאה לאוויר. במיוחד חשוב להבין שדרישות Google לגבי EEA ובריטניה (אכיפת מדיניות ההסכמה של האיחוד האירופי) הן דרישות של ספק, לא של החוק הישראלי. הן חלות על אתרים ישראליים שמגיעים אליהם משתמשים מאירופה.
טעויות נפוצות
הטעות הראשונה היא יישום Basic בלי להבין את המחיר. באתר ישראלי בינוני עם שיעור דחייה של 30 אחוז (דוגמה), Basic מוחק 30 אחוז מהמשתמשים מהדוחות לצמיתות ומשאיר ל-Google Ads רק מודל כללי. בחירה ב-Basic יכולה להיות החלטה משפטית לגיטימית, אבל היא צריכה להיות מודעת.
הטעות השנייה היא Advanced בלי זהות דיווח Blended. בלי Blended הנתונים הממודלים לא מופיעים גם כשהפרופרטי זכאי. בדיקה של דקה בהגדרות הפרופרטי חוסכת שבועות של תהייה. הטעות השלישית היא השוואה בין ממשק GA4 לבין BigQuery או Looker Studio שמחובר ל-BigQuery, בלי להבין שהייצוא לא כולל נתונים ממודלים.
הטעות הרביעית היא הזנחה של ad_user_data. אתרים רבים שולטים רק ב-ad_storage וב-analytics_storage ומשאירים את שני סיגנלי v2 ללא הגדרה. התוצאה היא Enhanced Conversions שלא עובדים ורשימות רימרקטינג שלא מתמלאות, בלי שום שגיאה גלויה. הטעות החמישית היא תג שנטען אחרי הבאנר ביישום שאמור להיות Advanced. אם התג לא נטען לפני הבאנר, אין פינגים ללא קוקיז. בפועל זה Basic גם אם הכוונה הייתה אחרת.
איך בודקים שזה עובד?
הבדיקה הטכנית מתחילה ב-Tag Assistant. פותחים את האתר בדפדפן נקי, מסתכלים על ההיטים הראשונים לפני אינטראקציה עם הבאנר ומוודאים שמצב ההסכמה בכל ארבעת הסיגנלים הוא denied כברירת מחדל. אחרי לחיצה על דחייה בודקים שהתגים ממשיכים לשלוח היטים ושהפרמטר gcs בכתובת הפינג מראה מצב דחייה (G100 מציין ad_storage ו-analytics_storage במצב denied). בודקים גם שהפרמטר gcd מכיל את מצב ארבעת הסיגנלים. אחרי לחיצה על אישור בודקים שנשלח פינג update ושההיטים הבאים כוללים קוקי _ga.
בכרטיסייה Network מסננים לפי collect ובודקים שהפינגים ללא קוקיז יוצאים ללא פרמטר cid קבוע וללא קוקיז בכותרות הבקשה. ב-Google Ads בודקים בעמוד Consent Mode תחת Goals שסטטוס היישום הוא Active ולא Partial. בודקים שיש זרימת נתונים משני המצבים.
הבדיקה העסקית נמשכת ארבעה שבועות אחרי העלייה לאוויר. בוחנים את אייקון איכות הנתונים ב-GA4 פעם בשבוע, מתעדים את התאריך שבו הופיע "Including estimated user data". משווים את יחס ההמרות ללידים במערכת הפנימית לפני ואחרי. אם אחרי ארבעה שבועות אין מודלינג והפרופרטי קרוב לסף של 1,000 אירועים דחויים ביום, זה כנראה סימן שהאתר פשוט קטן מדי למודלינג, לא שיש תקלה.
הטמעת Consent Mode v2, בחירה מושכלת בין Basic לבין Advanced והגדרת זהות הדיווח הן חלק משירות המדידה המתקדמת שלנו. אם אתם רואים ירידה בדוחות ולא בטוחים אם היא טכנית או עסקית, אפשר לקרוא על שירות המדידה המתקדמת או לפנות דרך טופס הקשר.
מדריכים קשורים
מקורות
Google: Set up consent mode on websites (ארבעת הסיגנלים ויישום), Google: Consent mode on websites and mobile apps (Basic מול Advanced, תוכן הפינגים), Google Analytics: Behavioral modeling for consent mode (תנאי הסף למודלינג), Google Ads: Consent mode modelling (סף 700 קליקים ועמודת Conversions), Google Ads: Consent mode reference (ad_user_data ו-ad_personalization)
