איך שלוש השכבות עובדות יחד?
הסדר קבוע. קודם תג ההסכמה, בדרך כלל תבנית של פלטפורמת ניהול ההסכמה (CMP), קובע ברירת מחדל לכל סוג הסכמה. כשהמשתמש בוחר בבאנר, אותו תג מעדכן את המצב. רק אחר כך מגיע תורם של שאר התגים. כל אחד מהם בודק את המצב לפי ההגדרות שלו: הבדיקות המובנות שהגיעו עם התבנית והדרישות הנוספות שהוספתם.
המדריך הזה עוסק במנגנון שבתוך הקונטיינר. את השאלה איזה מצב הסכמה לבחור פירטנו בעץ ההחלטה ל-Consent Mode. את המשמעות של כל אחד מהפרמטרים תמצאו במדריך לארבעת הפרמטרים של Consent Mode v2.
סדר הפעולות של ההסכמה
מה קורה מטעינת העמוד ועד שתג נורה
מה עושה הטריגר Consent Initialization?
לפי התיעוד של Google הטריגר הזה נועד לוודא שהגדרות ההסכמה מכובדות לפני שטריגרים אחרים נורים. הוא נורה לפני כל התגים האחרים, כולל אלה שעל טריגר Initialization. כל קונטיינר Web מגיע עם טריגר מוכן בשם Consent Initialization - All Pages.
התיעוד מגביל את השימוש בו: רק תגים שקובעים או מעדכנים מצב הסכמה, כמו תג של CMP או תג שקובע ברירות מחדל. תג שרק צריך לרוץ מוקדם שייך לטריגר Initialization. הסיבה פשוטה: אם תג מדידה נורה באותו שלב שבו ההסכמה נקבעת, אין ערובה שברירת המחדל כבר קיימת כשהוא רץ. לפי התיעוד, ברירת המחדל חייבת להיקבע לפני שתג כלשהו קורא או מעדכן הסכמה. אם היא נקבעת מאוחר מדי, תגי Google מתנהגים כאילו Consent Mode לא מופעל בכלל.
למה לא מגדירים הסכמה בתג Custom HTML?
בגלל סדר העיבוד. לפי התיעוד למפתחים, פקודות שנשלחות דרך gtag נכנסות לתור אחרי ההודעות שכבר ממתינות. ייתכן לכן שהן לא יעובדו לפני שהאירוע הבא מתחיל. המשמעות המעשית: תג Custom HTML שקורא ל-gtag consent על טריגר Consent Initialization לא מבטיח שההסכמה תיקבע לפני שהתגים הבאים נורים.
הפתרון של Google הוא ה-Consent APIs של Tag Manager, שזמינים בתוך תבניות: setDefaultConsentState לברירת המחדל ו-updateConsentState לעדכון. התיעוד מציין שהם מוודאים שעדכוני ההסכמה מעובדים לפני הפריטים שממתינים בתור. כך כל התגים שנורים מאותו אירוע רואים אותו מצב הסכמה. בפועל זה אומר להשתמש בתבנית ההסכמה של ה-CMP מתוך Community Template Gallery ולא להדביק קוד. על היתרון של תבניות על פני קוד מודבק כתבנו גם בפיקסלים ב-GTM בתבנית ולא ב-Custom HTML.
מה זה Built-In Consent Checks?
אלה הבדיקות שהתג מבצע בעצמו, בלי שהגדרתם דבר. רואים אותן בכל תג Web תחת Advanced Settings ואחר כך Consent Settings. לפי התיעוד, תגים עם בדיקות מובנות משנים את ההתנהגות שלהם לפי מצב ההסכמה. בתגי Google, כלומר Google Analytics, Google Ads, Floodlight ו-Conversion Linker, אמורים להופיע שם ad_storage ו-analytics_storage. הרשימה הזאת מגיעה עם התג ולא נקבעת על ידכם.
אלה סוגי ההסכמה ש-Tag Manager תומך בהם לפי התיעוד:
| סוג ההסכמה | על מה הוא חל |
|---|---|
| ad_storage | אחסון שקשור לפרסום, למשל עוגיות |
| ad_user_data | שליחת נתוני משתמש ל-Google לצורכי פרסום |
| ad_personalization | פרסום מותאם אישית |
| analytics_storage | אחסון שקשור לאנליטיקה, למשל משך ביקור |
| functionality_storage | אחסון שתומך בתפקוד האתר, למשל הגדרת שפה |
| personalization_storage | אחסון שקשור להתאמה אישית, למשל המלצות וידאו |
| security_storage | אחסון שקשור לאבטחה, למשל אימות ומניעת הונאות |
ארבעת הראשונים הם הפרמטרים של Consent Mode. שלושת האחרונים מוגדרים בתיעוד כפרמטרים של פרטיות שאינם חלק מ-Consent Mode. אפשר גם להוסיף סוגי הסכמה מותאמים אם ה-CMP שלכם תומך בהם.
מה ההבדל בין שלוש האפשרויות של Additional Consent Checks?
זאת ההגדרה היחידה שאתם קובעים בעצמכם לכל תג. היא נמצאת באותו מקום, תחת Consent Settings.
| האפשרות | מה היא עושה | מתי בוחרים בה |
|---|---|---|
| Not set | ברירת המחדל. התג לא מבצע בדיקות הסכמה נוספות | מצב זמני לתג שעוד לא נבדק |
| No additional consent required | מציינת שהתג לא צריך הסכמה נוספת כדי לירות | תג שנבדק ולא דורש הסכמה מעבר לבדיקות המובנות שלו |
| Require additional consent for tag to fire | התג נורה רק אם כל סוגי ההסכמה שצוינו במצב granted ברגע הטריגר | תג בלי בדיקות מובנות שתלוי בהסכמת המשתמש |
מבחינת התנהגות התג, שתי האפשרויות הראשונות זהות: אף אחת מהן לא מוסיפה בדיקה. ההבדל הוא תיעודי. לפי התיעוד, No additional consent required מאפשרת להבדיל בין תגים שכבר עברו בדיקה לבין תגים שעוד לא. באפשרות השלישית מופיע הכפתור Add required consent, שבו מוסיפים סוג הסכמה אחד או יותר.
איזו הגדרה מתאימה לאיזה תג?
לתגי Google התשובה של התיעוד חד משמעית: יש להם בדיקות מובנות והם לא צריכים בדיקות נוספות. שימוש בשתיהן יחד עלול למנוע מהתגים לעבוד כמו שצריך. לכן בתגי Google בוחרים Not set או No additional consent required. התיעוד גם ממליץ להסיר מתגי Google חריגים (Exceptions) ישנים שחוסמים אותם לפי הסכמה, כי תג שנחסם לגמרי פוגע בדיוק של מידול ההמרות. זאת ההמלצה של Google. אם בחרתם לחסום תגים עד לקבלת הסכמה, השיקולים מתוארים בעץ ההחלטה שקישרנו אליו למעלה.
לתגים שאינם של Google המצב הפוך. התיעוד מציין שתגים כאלה לא משנים התנהגות לפי Consent Mode. אם לתבנית של הפיקסל אין בדיקות מובנות, הדרך לכבד את בחירת המשתמש היא Require additional consent for tag to fire עם סוג ההסכמה המתאים, למשל ad_storage לפיקסל פרסומי.
כאן נמצאת מלכודת נפוצה. הבדיקה נעשית ברגע שהטריגר מפעיל את התג. התיעוד של Google אומר זאת במפורש: גם אם ההסכמה ניתנת מאוחר יותר, התג לא יירה אם היא לא הייתה במצב granted ברגע שהופעל לראשונה. כשברירת המחדל היא denied, תג על טריגר Page View נבדק לפני שהמשתמש לחץ על הבאנר ולכן לא יירה באותו רגע. אם פלטפורמת ההסכמה שלכם דוחפת אירוע ל-Data Layer אחרי בחירת המשתמש, מוסיפים לתג טריגר Custom Event על האירוע הזה. כדאי לבדוק את התרחיש ב-Preview עם באנר שעוד לא אושר.
איך מגדירים הסכמה לכל התגים דרך Consent Overview?
- מפעילים את המסך. נכנסים ל-Admin ואחר כך ל-Container Settings. תחת Additional Settings מסמנים Enable consent overview.
- פותחים את Consent Overview. לוחצים על Tags בתפריט הצד ואחר כך על הסמל של Consent Overview.
- עוברים על הקבוצה Consent Not Configured. אלה התגים שנשארו במצב Not set, כלומר שאף אחד לא קיבל לגביהם החלטה.
- מסמנים תגים מאותו סוג. כשמסמנים תג אחד או יותר מופיע הסמל Edit Consent Settings.
- קובעים את Additional Consent Checks. לתגי Google בוחרים No additional consent required. לפיקסלים בלי בדיקות מובנות בוחרים Require additional consent ומוסיפים את סוג ההסכמה.
- שומרים ומפרסמים. השינוי נכנס לתוקף רק אחרי פרסום הקונטיינר. היעד: קבוצת Consent Not Configured ריקה.
איך בודקים שההגדרות עובדות?
ב-Tag Assistant, בשלושה מבטים. הראשון: בוחרים את אירוע ה-Consent המוקדם ביותר ובודקים בחלק API Call שארבעת הפרמטרים נקבעו. אפשר לראות אותם גם בלשונית Consent בעמודה On-page Default. השני: אחרי לחיצה על הבאנר בודקים את אירוע ה-Consent האחרון ואת העמודה On-page Update. אם לשונית Consent ריקה, לפי התיעוד Consent Mode לא מוטמע בעמוד.
המבט השלישי הוא על התגים עצמם. בלשונית Tags לוחצים על תג שלא נורה. אם מופיע בו חלק בשם Required Additional Consent עם שורות בטבלה, התג נחסם בגלל דרישת ההסכמה שהוספתם. כדאי לבצע את הבדיקה פעמיים: פעם עם אישור הבאנר ופעם עם סירוב. את סדר הבדיקה המלא תיארנו במדריך Preview ו-Tag Assistant.
שאלות נפוצות
מה ההבדל בין Consent Initialization ל-Initialization ב-GTM?
Consent Initialization נורה לפני כל הטריגרים האחרים, כולל Initialization. לפי התיעוד של Google הוא מיועד רק לתגים שקובעים או מעדכנים מצב הסכמה, כמו תג של פלטפורמת ניהול הסכמה. תגים אחרים שצריכים לרוץ מוקדם משתמשים ב-Initialization. כך מצב ההסכמה כבר קיים כשהם נורים.
מה זה Built-In Consent Checks?
אלה בדיקות ההסכמה שתג מבצע בעצמו כחלק מהתבנית שלו. רואים אותן בכל תג Web תחת Advanced Settings ואחר כך Consent Settings. תגי Google כמו Google Analytics, Google Ads ו-Floodlight משנים את ההתנהגות שלהם לפי מצב ההסכמה. לפי התיעוד אמורים להופיע אצלם ad_storage ו-analytics_storage. הרשימה מגיעה עם התג ולא נקבעת על ידכם.
מה ההבדל בין Not set ל-No additional consent required?
מבחינת התנהגות התג אין הבדל: בשני המצבים התג לא מבצע בדיקת הסכמה נוספת. Not set היא ברירת המחדל של תג שאף אחד לא נגע בו. No additional consent required מסמנת שהתג נבדק והוחלט שאינו דורש הסכמה נוספת. במסך Consent Overview תגים במצב Not set מופיעים תחת Consent Not Configured.
האם צריך להוסיף Additional Consent Checks לתג GA4 או לתג Google Ads?
לפי התיעוד של Google לא. לתגי Google יש בדיקות הסכמה מובנות והם לא צריכים בדיקות נוספות. שימוש בשתיהן יחד עלול למנוע מהתגים לעבוד כמו שצריך. ההמלצה היא לבחור ב-Additional Consent Checks את Not set או את No additional consent required. מי שחוסם תגים עד להסכמה פועל בתרחיש אחר.
מתי תג עם Require additional consent נורה?
התג נורה רק אם כל סוגי ההסכמה שהוגדרו בו נמצאים במצב granted ברגע שהטריגר מפעיל אותו. לפי התיעוד של Google, גם אם ההסכמה ניתנת מאוחר יותר התג לא יירה בדיעבד. לכן כשברירת המחדל היא denied, תג על טריגר Page View שנבדק לפני שהמשתמש אישר את הבאנר לא יירה. כדי שיירה אחרי האישור צריך טריגר נוסף שפועל אחרי עדכון ההסכמה.
איך מפעילים את Consent Overview ב-GTM?
נכנסים ל-Admin, בוחרים Container Settings ומסמנים Enable consent overview תחת Additional Settings. אחר כך לוחצים על Tags ועל הסמל של Consent Overview. המסך מחלק את התגים לשתי קבוצות: Consent Not Configured ו-Consent Configured. אפשר לסמן כמה תגים ולערוך את Additional Consent Checks לכולם יחד. השינוי נכנס לתוקף אחרי פרסום.
מה השורה התחתונה?
הגדרת הסכמה נכונה ב-GTM היא ארבע החלטות קצרות. תג ההסכמה יושב על Consent Initialization ומגיע מתבנית, לא מ-Custom HTML. תגי Google נשארים עם הבדיקות המובנות שלהם בלי תוספות. פיקסלים בלי בדיקות מובנות מקבלים Require additional consent וטריגר שפועל גם אחרי אישור הבאנר. שום תג לא נשאר במצב Not set. כל השאר הוא בדיקה ב-Tag Assistant בשני התרחישים, אישור וסירוב. איך ההגדרות האלה משפיעות על המספרים הסברנו במה Consent Mode v2 משנה בדוחות. את שאר יסודות הקונטיינר ריכזנו במדריך המלא ל-Google Tag Manager. הקמה ובדיקה של שכבת ההסכמה הן חלק משירות הטמעת Google Tag Manager שלנו. אם אתם לא בטוחים שהתגים שלכם מכבדים את הבאנר, כתבו לנו.
מקורות
Tag Manager Help: Tag Manager consent mode support, Tag Manager Help: Page view triggers, Tag Manager Help: Unblock Google tags when using consent mode, Google for Developers: Create a consent mode template, Google for Developers: Troubleshoot consent mode with Tag Assistant, Google for Developers: The data layer
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי