ניפוי שגיאות ב-Google Consent Mode עם DevTools של הדפדפן: קריאת הפרמטר gcs
למה כדאי לאמת בדפדפן
באנר הסכמה שנראה תקין אינו הוכחה שהתגים שלכם מתנהגים נכון. בעיות ב-Consent Mode הן שקטות: דפים נטענים, מודעות מוצגות ודוחות מתמלאים, ובכל זאת האותות שנשלחים ל-Google עשויים להיות שגויים. כלי המפתחים של הדפדפן מאפשרים לבדוק מה באמת קורה, תוך דקות ובלי תוכנה נוספת.
שלב 1: פתחו את לשונית Network בצורה נקייה
- פתחו את הדף בחלון פרטי כדי שלא תישמר בחירה קודמת.
- פתחו את DevTools ועברו ללשונית Network.
- סמנו Preserve log כדי שהבקשות ישרדו ניווט.
- טענו את הדף מחדש ואל תיגעו עדיין בבאנר.
שלב 2: מצאו את מצב ההסכמה בבקשות
תגי Google מוסיפים פרמטר gcs לבקשות שלהם. אפשר לסנן את רשימת הרשת לפי collect או google ולפתוח כל פגיעה כדי לקרוא את מחרוזת השאילתה שלה. הערך נראה כמו G100 או G111.
- G100 — גם אחסון פרסום וגם אחסון אנליטיקה נדחו.
- G111 — שניהם אושרו.
- G101 ו-G110 — אחד אושר ואחד נדחה.
קראו את התווים משמאל לימין אחרי G1: הספרה הראשונה היא מצב אחסון הפרסום והשנייה היא מצב אחסון האנליטיקה, כאשר 1 פירושו אושר ו-0 פירושו נדחה. מימושים חדשים יותר שולחים גם פרמטר gcd עם מצב מקודד ארוך יותר הכולל את אותות Consent Mode v2 הנוספים.
שלב 3: מה אתם אמורים לראות לפני כל בחירה
באזור שבו נדרשת הסכמה, הבקשות הראשונות, שנשלחות לפני שהמבקר מקיים אינטראקציה, צריכות להציג מצב נדחה. אם אתם רואים G111 עוד לפני שהמבקר לחץ על משהו, ברירת המחדל שלכם שגויה, או שהתג הופעל לפני שברירת המחדל הוגדרה.
שלב 4: מה אתם אמורים לראות אחרי אישור
לחצו על אישור ואז עקבו אחרי הבקשות החדשות. המצב אמור להשתנות לאושר והתגים אמורים להמשיך. אם הבאנר אומר שאושר אך הבקשות עדיין נושאות את המצב נדחה, קריאת העדכון אינה מגיעה לתגי Google, או שהיא רצה מאוחר מדי.
שלב 5: בדקו את שכבת הנתונים
ב-Console הקלידו dataLayer והרחיבו את הרשומות. אתם מחפשים שני דברים לפי הסדר:
- רשומת consent עם הפקודה default, המפרטת כל אות כנדחה באזורים שדורשים הסכמה.
- רשומת consent מאוחרת יותר עם הפקודה update, אחרי שהמשתמש בוחר.
אותות Consent Mode v2 הם ad_storage, analytics_storage, ad_user_data ו-ad_personalization. אם שני האחרונים חסרים, יש לכם הגדרה בסגנון v1.
הטעויות הנפוצות ביותר
- ברירת מחדל שהוגדרה מאוחר מדי. פקודת default חייבת לרוץ לפני שתג Google או מכולת Tag Manager נטענים.
- העדכון לא נשלח אף פעם. הבאנר שומר בחירה אך אינו קורא לפקודת update.
- רק שני אותות. אותות v2 עבור נתוני משתמש והתאמה אישית חסרים.
- לוגיקת אזורים שגויה. מבקרים מאזור שדורש הסכמה מטופלים כמאשרים כברירת מחדל.
- חסימה על ידי תוסף. תוסף פרטיות בדפדפן שלכם מסתיר בקשות; בדקו כשהתוספים כבויים.
- בחירה שמורה במטמון. בדקתם בחלון רגיל ששמר כבר בחירה קודמת.
שלב 6: בדקו את מצב Preview של Tag Manager
אם אתם משתמשים ב-Google Tag Manager, מצב Preview מציג את מצב ההסכמה לכל אירוע בדף, ואילו תגים הופעלו או נחסמו. השוו אותו למה שראיתם בלשונית הרשת: שתי התצוגות צריכות להתאים.
הפכו את זה לשגרה
הריצו את הבדיקה של חמש הדקות אחרי כל שינוי בבאנר, פרסום מכולה או גרסת אתר. רשמו את ערך gcs הצפוי בארבעה מקרים: ביקור ראשון, אחרי אישור, אחרי דחייה ואחרי שינוי הבחירה מאוחר יותר. כל דבר שלא תואם הוא באג שיש לתקן לפני שהדוחות שלכם יספרו על כך.
היכן FlexyConsent נכנסת לתמונה
FlexyConsent היא CMP מוסמכת של Google (CMP ID 317) התומכת ב-Google Consent Mode v2 ושולחת בשבילכם את אותות default ו-update. עדיין כדאי להריץ את בדיקת הדפדפן הזו בדפים שלכם, כי סדר התגים והגדרות המכולה ספציפיים לאתר שלכם.
נקודות מפתח
- בדקו בחלון פרטי כשיומן הרשת נשמר.
- קראו את ערך gcs: G100 הוא נדחה, G111 הוא אושר.
- ברירת המחדל הנדחית חייבת להיראות לפני שהמבקר בוחר.
- העדכון חייב לשנות את המצב מיד אחרי הבחירה.
- ודאו שכל ארבעת אותות Consent Mode v2 מופיעים בשכבת הנתונים.