נכתב על ידי דני צ'רניאק, DigiKnowledge. נבדק לאחרונה: 10.11.2026

ב-Consent Mode v2 יש ארבעה פרמטרים של הסכמה. שניים שולטים באחסון: ad_storage קובע אם מותר לקרוא ולכתוב עוגיות פרסום, analytics_storage קובע את אותו דבר לעוגיות אנליטיקס. שניים נוספו בגרסה 2 ושולטים בשימוש בנתונים: ad_user_data קובע אם מותר לשלוח ל-Google נתוני משתמש לצורכי פרסום, ad_personalization קובע אם מותר להשתמש בנתונים לפרסום מותאם אישית כמו רימרקטינג. כל אחד מהם מקבל granted או denied בנפרד, כשלכל denied יש תוצאה אחרת בתגים של Google.

מה הם ארבעת הפרמטרים ומה ההבדל בין שני הזוגות?

ההגדרות בטבלה הן לפי התיעוד של Google. ההבחנה שעוזרת לזכור: הזוג הראשון עונה על השאלה מה מותר לשמור במכשיר של הגולש, בעוד שהזוג השני עונה על השאלה מה מותר ל-Google לעשות עם הנתונים שהגיעו.

הפרמטרמה הוא שולט בומה קורה כשהוא denied
ad_storageאחסון שקשור לפרסום, כמו עוגיות באתר או מזהי מכשיר באפליקציהלא נכתבות עוגיות פרסום חדשות ולא נקראות קיימות
analytics_storageאחסון שקשור לאנליטיקס, למשל לצורך משך ביקורלא נקראות ולא נכתבות עוגיות אנליטיקס של צד ראשון. נשלחים פינגים בלי עוגיות
ad_user_dataשליחת נתוני משתמש ל-Google לצורכי פרסוםמושבת איסוף נתונים אישיים לפרסום, כולל user_id ו-Enhanced Conversions
ad_personalizationפרסום מותאם אישיתתכונות רימרקטינג לא מקבלות נתונים

לצד הארבעה התיעוד מונה שלושה פרמטרים נוספים: functionality_storage, personalization_storage ו-security_storage. הם מתארים אחסון לצורכי פונקציונליות, התאמה אישית ואבטחה. דף העזרה של Google Ads מסווג אותם כפרמטרים של פרטיות ולא כסוגי הסכמה. המדריך הזה עוסק רק בארבעה. את ההחלטה אם להטמיע במצב Basic או Advanced פירטנו בעץ ההחלטה ל-Consent Mode.

מה קורה כש-ad_storage במצב denied?

לפי התיעוד, באתר קורים כמה דברים במקביל. לא נכתבות עוגיות פרסום חדשות ועוגיות פרסום קיימות של צד ראשון לא נקראות. הבקשות נשלחות דרך דומיין אחר, כדי לא לשאת עוגיות צד שלישי שהוגדרו בעבר, בזמן שמוצרי הפרסום מקצצים את כתובת ה-IP כבר באיסוף. גם Google Analytics מושפע: הוא לא קורא ולא כותב עוגיות של Google Ads ו-Google signals לא צובר נתונים על התנועה הזאת.

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

מה קורה כש-analytics_storage במצב denied?

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

ההבחנה שקובעת כאן: הפינגים האלה נשלחים רק בהטמעה שבה התגים נטענים לפני ההסכמה, כלומר במצב Advanced. בהטמעה שחוסמת את התגים עד לבחירת הגולש לא נשלח כלום. איך זה נראה בדוחות הסברנו במדריך מה Consent Mode v2 משנה בדוחות. את המידול עצמו פירטנו במדריך מידול המרות ב-Google Ads וב-GA4.

מה קורה כש-ad_user_data במצב denied?

זה הפרמטר שהכי קל לפספס, כי הוא לא נוגע לעוגיות. לפי התיעוד, כשהוא denied השימוש בנתונים אישיים לפרסום מקוון מושבת. זה כולל תרחישים שנשענים על user_id ועל נתונים שהגולש מסר, כלומר Enhanced Conversions. דף העזרה של Google Ads מגדיר אותו במפורש כפרמטר שנדרש לתרחישי מדידה כמו Enhanced Conversions.

יש לו עוד שתי השפעות שמופיעות בדף העזרה. ייצוא המרות שמבוסס על מזהה קליק מוגבל, למשל אופטימיזציה של בידינג לפי המרות מ-Google Analytics. בנוסף, פינגים של המרות נשלחים בלי עוגיות. המשמעות המעשית: אתר שמעדכן את ad_storage ל-granted ומשאיר את ad_user_data במצב denied משבית בפועל את Enhanced Conversions שהטמיע. את ההטמעה עצמה הסברנו במדריך Enhanced Conversions ל-Google Ads.

מה קורה כש-ad_personalization במצב denied?

לפי התיעוד פרסום מותאם אישית מושבת, כלומר רימרקטינג ב-Google Ads, ב-Display & Video 360 וב-Search Ads 360 לא מקבל נתונים. המדידה של הגולש לא תלויה בפרמטר הזה, אבל הוא לא ייכנס לרשימות הרימרקטינג.

שני פרטים מהתיעוד שכדאי להכיר. הראשון: כדי לאפשר פרסום מותאם אישית צריך שגם ad_user_data וגם ad_personalization יהיו granted, כך שאחד מהם לבד לא מספיק. השני: ההגדרה הוותיקה allow_ad_personalization_signals משיגה את אותה תוצאה כשמכבים אותה. אם שתי ההגדרות קיימות עם ערכים סותרים, ההתאמה האישית מושבתת. Google ממליצה להשתמש ב-ad_personalization כדי לכבד את בחירת הגולש. על בניית קהלים וייצוא שלהם אפשר לקרוא במדריך קהלים ב-GA4.

איך מגדירים ברירת מחדל ועדכון לכל פרמטר?

לפי התיעוד, כברירת מחדל שום ערך של Consent Mode לא מוגדר. את המצב ההתחלתי קובעים בפקודת default ואת הבחירה של הגולש בפקודת update. Consent Mode לא שומר את הבחירה בעצמו: הבאנר או פלטפורמת ניהול ההסכמות שומרים אותה ומחילים אותה מחדש בעמודים הבאים.

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});
  1. קובעים ברירת מחדל לכל ארבעת הפרמטרים. בכל עמוד, לפני כל פקודת config או event. התיעוד מזהיר שקוד הסכמה שרץ בסדר שגוי גורם לכך שברירות המחדל לא יעבדו.
  2. נותנים לבאנר זמן לעדכן. כשפלטפורמת ההסכמות נטענת באופן אסינכרוני מוסיפים wait_for_update באלפיות שנייה. בדוגמה של התיעוד הערך 500 נותן לכלי ההסכמות חצי שנייה לקרוא ל-update לפני שהתגים נורים.
  3. מגבילים לאזורים כשצריך. הפרמטר region מקבל מערך של קודים לפי ISO 3166-2. ברירת מחדל בלי region חלה על כל מי שלא מכוסה בהגדרה אזורית. כששתי הגדרות חלות, האזור הספציפי יותר גובר.
  4. שולחים update כשהגולש בוחר. מיד כשהוא מאשר את ההעדפות, גם כשהבחירה היא denied. כל שינוי מאוחר יותר נשלח באותה פקודה.
  5. מוודאים שכל ארבעת הפרמטרים מתעדכנים. באנר ישן שנבנה לפני גרסה 2 מעדכן רק את שני פרמטרי האחסון.

ב-Google Tag Manager הפקודות האלה מגיעות בדרך כלל מתבנית של פלטפורמת ההסכמות. לפי התיעוד, תבניות משתמשות ב-API הייעודי setDefaultConsentState ו-updateConsentState במקום בפקודת gtag. לפי דף העזרה של Tag Manager, פלטפורמות הסכמה שאושרו על ידי Google מתעדכנות לגרסה העדכנית של Consent Mode בעצמן. עדיין כדאי לוודא מול הספק שאתם על הגרסה הזאת. את ההגדרות ברמת התג הבודד פירטנו במדריך הגדרות הסכמה בתגים של GTM.

מה עושות ההגדרות url_passthrough ו-ads_data_redaction?

אלה שתי הגדרות משלימות: הן לא סוגי הסכמה, אבל הן משנות את מה שקורה כשפרמטר אחסון הוא denied.

ההגדרהמה היא עושהמתי היא משפיעה
url_passthroughמעבירה מידע על קליק על מודעה ועל הסשן בין עמודים בפרמטרים של הכתובת במקום בעוגיותכש-ad_storage או analytics_storage במצב denied, בקישורים לאותו דומיין
ads_data_redactionמסירה מזהי קליק מבקשות הרשת של Google Ads ושל Floodlight ומנתבת אותן דרך דומיין בלי עוגיות צד שלישירק כש-ad_storage במצב denied

לפי התיעוד, הפרמטרים ש-url_passthrough עשויה להוסיף לקישורים הם gclid, dclid, gclsrc, _gl ו-wbraid. מפעילים אותה בפקודת set לפני כל פקודת config. ל-ads_data_redaction אין השפעה כש-ad_storage במצב granted או כשלא משתמשים בפקודת consent בכלל.

איך בודקים מה נשלח בפועל?

הכלי הוא Tag Assistant. לפי התיעוד בוחרים ב-Summary את אירוע ה-Consent המוקדם ביותר ובודקים בסעיף API Call שארבעת הפרמטרים הוגדרו. אחר כך בוחרים את אירוע ה-Consent האחרון ובודקים שהם התעדכנו אחרי הבחירה בבאנר. בלשונית Consent של כל תג יש עמודה On-page Default ועמודה On-page Update שמציגות את אותו מידע לכל פרמטר. לשונית Consent ריקה אומרת ש-Consent Mode לא מוטמע בעמוד.

בבקשות הרשת עצמן יש שני פרמטרים שנושאים את המצב. לפי התיעוד, gcs מעביר את המצב של ad_storage ושל analytics_storage. הפרמטר gcd, שנשלח תמיד לשירותי Google גם כש-Consent Mode לא מופעל, מקודד מידע מפורט על הבחירה של הגולש בכל סוגי ההסכמה.

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

שאלות נפוצות

מה הם ארבעת הפרמטרים של Consent Mode v2?

ad_storage שולט באחסון שקשור לפרסום, כמו עוגיות. analytics_storage שולט באחסון שקשור לאנליטיקס. ad_user_data קובע אם מותר לשלוח נתוני משתמש ל-Google לצורכי פרסום. ad_personalization קובע אם מותר פרסום מותאם אישית. לפי התיעוד של Google שני האחרונים נוספו בגרסה 2 של Consent Mode. כל פרמטר מקבל granted או denied בנפרד.

מה קורה כש-ad_storage במצב denied?

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

מה ההבדל בין ad_user_data ל-ad_personalization?

ad_user_data שולט בשליחת נתוני משתמש ל-Google לצורכי פרסום. כשהוא denied מושבת השימוש בנתונים אישיים לפרסום, כולל user_id ו-Enhanced Conversions. ad_personalization שולט בפרסום מותאם אישית. כשהוא denied תכונות רימרקטינג לא מקבלות נתונים. לפי התיעוד של Google, כדי לאפשר פרסום מותאם אישית שניהם צריכים להיות granted.

האם Enhanced Conversions עובד כש-ad_user_data במצב denied?

לא. לפי התיעוד של Google, כש-ad_user_data במצב denied איסוף נתונים אישיים לצורכי פרסום מושבת, כולל Enhanced Conversions שמבוססות על נתוני צד ראשון מגובבים. דף העזרה של Google Ads מגדיר את ad_user_data כפרמטר שנדרש לתרחישי מדידה כמו Enhanced Conversions. לכן באנר שמעדכן רק את ad_storage משאיר את התכונה כבויה.

מה זה wait_for_update ב-Consent Mode?

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

איך בודקים שארבעת הפרמטרים של Consent Mode מוגדרים נכון?

ב-Tag Assistant. לפי התיעוד של Google בוחרים את אירוע ה-Consent המוקדם ביותר ובודקים בסעיף API Call שהוגדרו ad_storage, ad_user_data, ad_personalization ו-analytics_storage. אחר כך בוחרים את אירוע ה-Consent האחרון ובודקים שהערכים התעדכנו אחרי הבחירה בבאנר. בלשונית Consent של כל תג מופיעות העמודות On-page Default ו-On-page Update.

מה השורה התחתונה?

ארבעת הפרמטרים הם לא מתג אחד של עוגיות. שניים קובעים מה נשמר בדפדפן ושניים קובעים מה Google רשאית לעשות עם הנתונים. הטמעה שמטפלת רק ב-ad_storage וב-analytics_storage נראית תקינה בבדיקה מהירה, אבל משאירה את Enhanced Conversions ואת הרימרקטינג כבויים. לפי דף העזרה של Tag Manager, מי שמקבל תנועה מהאזור הכלכלי האירופי חייב לאסוף הסכמה ולהעביר את האותות ל-Google כדי להמשיך להשתמש במדידה, בהתאמה אישית וברימרקטינג. הבדיקה לוקחת דקות: Tag Assistant, אירוע ה-Consent הראשון והאחרון, ארבע שורות בכל אחד. אנחנו מטמיעים ובודקים Consent Mode כחלק משירות מדידה מתקדמת, כולל ההתאמה מול פלטפורמת ההסכמות והתגים בצד שרת. אם אתם לא בטוחים אילו מהפרמטרים מתעדכנים אצלכם, כתבו לנו.

מקורות

דני צ'רניאק
דני צ'רניאק
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי

כתיבת תגובה

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