راهنمای جامع کانسنت مود بیسیک

اگه میخوای موارد نظری رو نخونی و برسی به اصل مطلب به این تایتل برو: وصل کردن دستی CMP با تمپلیت کاستوم. اگه نه, از اول پست شروع کن.

کانسنت مود گوگل یه روشه که با اون می‌تونی کنترل کنی تگ‌ها چطور به رضایت کاربر به استفاده از دیتاش برای تبلیغات و تحلیل واکنش نشون بدن. این سیستم مخصوصاً برای تگ‌های گوگل طراحی شده، ولی با گوگل تگ منیجر می‌تونی از ویژگی‌ها و APIهای کانسنت مود استفاده کنی و تگ‌های دیگه رو هم کنترل کنی.
کانسنت مود دو "نوع" داره:
کانسنت مود پیشرفته مخصوص محصولات گوگل طراحی شده. تگ‌های GA4، Ads و Floodlight به انتخاب‌های کانسنت کاربر حساسن و رفتارشون رو بر اساس اون تنظیم می‌کنن. پیاده‌سازی این مود خیلی راحته چون عملاً نیازی به تغییر تریگر لینک شده به تگ‌ها نداره.
کانسنت مود بیسیک یعنی تگ‌ها منتظر بمونن تا کانسنت داده بشه. یعنی باید دستی جلوی اجرا شدن تگها رو بگیری تا کاربر نشون بده که رضایت داره تگ های مربوط به تحلیل/تبلیغات اجرا بشن. این نوع کانسنت مود خیلی سخت ست میشه چون ستاپ تریگرش به سختی انجام می‌شن.

تو این راهنما، من می‌خوام سراغ دومی برم. کانسنت مود بیسیک یه دردسر کاملئه، چون برخلاف کانسنت مود پیشرفته، هیچ‌جوره خودکار نیست. این نوع کانسنت مود به این معناست که تگ‌ها فقط وقتی اجرا بشن که کاربر کانسنت مربوطه رو داده باشه. اگه کانسنت داده نشده یا مشخص نباشه که کانسنت داده شده یا نه، تگ‌ها نباید اجرا بشن.
بخش اول این پست درباره چطور پیاده‌سازی خود کانسنت مود هست چه به کمک یه پلتفرم مدیریت کانسنت (CMP)، چه به صورت دستی با یه تمپلیت کاستوم، یا ترکیبی از این دو تا. بخش دوم این بلاگ پست درباره ست کردن تگ‌ها هست تا فقط وقتی فایر بشن که  کانسنت مناسب داده شده باشه.

این مقاله اول روی پیاده‌سازی گوگل تگ منیجر تمرکز داره. اگه فقط از گوگل تگ استفاده می‌کنی، این پست رو تا انتها بخون چون خیلی برات کاربردیه. ولی بهتره راهنمای رسمی گوگل رو هم چک کنی.

 کانسنت مود بیسیک: اصول اولیه
کانسنت مود بیسیک (BCM) واقعاً یه ویژگی نیست و فقط یه روش پیاده‌سازیه که مشخص می‌کنه تگ‌هایی که به کانسنت نیاز دارن اجرا نشدن تا وقتی کانسنت موردنیاز داده نشده باشه.
این یه روند عادیه. احتمالاً به همین روش تگ‌هات رو ست کردی چه به خاطر قوانین مثل GDPR و چه قواعد حریم خصوصی مجازی که مبانی قانونی پردازش دیتای کاربر رو دیکته می‌کنن.
ولی در زمان اجرای کانسنت مود بیسیک باید تگ‌هات رو به بسته به شیوه فعال شدن کانسنت مود تو صفحه ست کنی. این یعنی پلتفرم مدیریت کانسنت (CMP) باید با کانسنت مود ادغام بشه. اگه این‌طور نیست، خودت باید هماهنگی بین CMP و کانسنت مود رو مهندسی کنی.

کال‌های کانسنت مود 
کانسنت مود دو نوع کال مختلف داره:
- دیفالت: این نوع کال خیلی زود فراخونی می‌شه. باید از تریگر Consent Initialization - All Pages برای این کار استفاده کنی. بهتره همه حالت‌های کانسنت رو به‌صورت دیفالت روی "denied" بذاری.
- آپدیت: این نوع کال وقتی فراخونی می‌شه که کاربر انتخابش رو بکنه یا انتخابش به هر نحو دیگه معلوم بشه. در حالی که دیفالت باید فقط یه بار تو هر بار لود صفحه اجرا بشه، آپدیت می‌تونه چند بار فراخونی بشه—هر وقت کاربر انتخاب جدیدی بکنه.

هر دو نوع کال  شامل سیگنال‌های کانسنت و حالت‌هاشون میشن. اگه رضایت برای یه سیگنال خاص مثلا ad-storage رد بشه، مقدارش باید "denied" باشه. اگه رضایت داده شد، مقدارش باید "granted" بشه. یه مثال از حالتی که کانسنت به‌صورت دیفالت رد شده:

ما همه سیگنال‌های کانسنت کاستوم (مثل funcionality_storage، security_storage و غیره) رو نادیده می‌گیریم چون رسماً بخشی از کانسنت مود نیستن.
و وقتی مثلاً رضایت برای تحلیل داده داده بشه، کال آپدیت به این صورت فرستاده می‌شه:

روش ایده‌آل ستاپ کانسنت: این چیزیه که من روش ایده‌آل می‌دونم. تو مراحل بعدی راهنما بیشتر توضیحش می‌دم. مهمه که بدونی این روش به یه CMP نیاز داره. اگه پلتفرم مدیریت کانسنت ادغام درستی با کانسنت مود نداشته باشه ممکنه مجبور شی خودت با تمپلیت مناسب کال‌های کانسنت مود رو کنترل کنی.
کال دیفالت باید همیشه تو تریگر Consent Initialization - All Pages اتفاق بیفته و همه سیگنال‌های رضایت رو روی "denied" بذاره.

شاید از خودت بپرسی چرا سیگنال‌های رضایت رو توی کال دیفالت معادل "granted" نذاریم، اگه این اطلاعات تو کوکی‌ها (یا استوریج مرورگر) که CMP ایجادش کرده موجود باشه. به نظر من ست کردن دیفالت به "denied" شیک‌ترین و منسجم ترین روشه.
اگه وضعیت کانسنت موقع لود کانتینر GTM معلوم باشه، کال آپدیت باید بلافاصله بعد از کال دیفالت، هم تو تریگر Consent Initialization، اتفاق بیفته. این کال آپدیت باید بعد از یه دیتالیر.پوش دارای یه ایونت کاستوم (مثلاً gtm_consent_update) و جزئیات حالت‌های کانسنت اتفاق بیفته. این ایونت برای تریگر تگ‌هایی که به رضایت نیاز دارن استفاده می‌شه.

در صورت اجرای کال‌های دیفالت و آپدیت به صورتی که کال آپدیت فوراً بعد از کال دیفالت بیاد، مطمئن می‌شی که همه تگ‌های GTM می‌تونن از به‌روزترین حالت‌های کانسنت استفاده کنن.

اگه رضایت بعدتر توسط کاربر تنظیم یا تغییر کنه، یا حالت کانسنت فقط وقتی معلوم بشه که CMP لود شده، کال آپدیت باید بلافاصله بعد از معلوم شدن وضعیت سیگنال‌های کانسنت اجرا بشه. باز هم، بعد از این کال آپدیت باید یه دیتالیر.پوش طبق توضیح بالا اتفاق بیفته.


تو اسکرین‌شات بالا، کال آپدیت کانسنت بخاطر یه تمپلیت کاستوم GTM (که پایین آوردمش) اجرا میشه و اون تمپلیت میاد و ایونت consent_banner_click رو پوش میکنه.
همونطور که می‌بینی، آپدیت کانسنت دقیقا زمان لاگ شدن ایونت consent_banner_click اتفاق می‌افته. این به خاطر اون هست که GTM جوری طراحی شده که تغییرات حالت‌های کانسنت رو فوراً اعمال کنه اگه تمپلیت کاستوم از APIهای اختصاصی (setDefaultConsentState و updateConsentState) استفاده کنه.
تو این روش ایده‌آل از  تمپلیت‌های GTM برای مهندسی کانسنت استفاده میشه. تکیه صرف بر اسکریپت گوگل آنالیتیکس( یعنی صرفا gtag) ممکنه ولی توصیه نمیشه. توی ستاپ ایدئال مون از ترکیب GA4+GTM استفاده میکنیم.

 پلتفرم مدیریت کانسنت
نمی‌تونم CMP خاصی رو پیشنهاد بدم. همیشه ترجیح دادم تعامل با کانسنت مود رو دستی با تمپلیت کاستوم (که در ادامه اومده) مدیریت کنم، ولی خیلی CMPها تمپلیت‌های کاستوم خودشون رو دارن که کار رو راه میندازن، البته تا حدودی.
به‌طور کلی، پیشنهاد می‌کنم CMP رو خارج از GTM، و قبل از اجرای گوگل تگ منیجر، لود کنی چون که تو بعضی موارد GTM توسط بلاکرهای تبلیغی و محتوایی متوقف می‌شه، که یعنی CMP اصلاً لود نمی‌شه. این ریسک زیادی داره اگه جمع‌آوری دیتایی که به کانسنت کاربر بستگی داره خارج از GTM اتفاق بیفته.

در هر صورت، موقع کار با CMP، باید مراقب باشی چقدر از ستاپ کانسنت مود رو به کتابخونه CMP واگذار می‌کنی، چون اغلب CMP به‌صورت ناهمزمان لود می‌شه. لودینگ ناهمزمان یعنی مرورگر لود رو شروع می‌کنه ولی بعد به اجرای بقیه کارها تو صف ادامه می‌ده. به بیان دیگه، تضمینی نیست که CMP کی لود بشه و آماده پیاده‌سازی کانسنت مود باشه.
سوای روش کارکردن CMP، روشی که پیشنهاد می‌کنم برای مهندسی کانسنت مود مناسبه:
1-از یه تمپلیت کاستوم GTM برای ست کردن دیفالت روی "denied" برای همه سیگنال ها استفاده کن و بذار رو تریگر Consent Initialization - All Pages اجرا بشه. اولویت اجرای این تگ رو  10 بذار.
2- از یه تمپلیت کاستوم GTM برای فراخونی کال آپدیت رو تریگر Consent Initialization - All Pages استفاده کن اگه کاربر قبلاً رضایتش رو داده و داده کانسنت اون کاربر تو کوکی‌های مرورگر یا لوکال استوریج موجود باشه. حالت‌ها رو از "denied" به "granted" برای همه سیگنال‌هایی که رضایتشون داده شده تغییر بده (ممکنه نیاز باشه از وریبل‌ها برای برداشتن داده کانسنت از کوکی‌ها، لوکال استوریج یا آبجکت گلوبال window استفاده کنی).
3- از یه تمپلیت کاستوم GTM برای فراخونی کال آپدیت استفاده کن که زمانی که کاربر انتخاب‌های کانسنتش رو مشخص کرد اجرا بشه.

حالا ایده‌آل اینه که تمپلیت کاستوم  CMP بیاد و همه این سناریوهای بالا رو مدیریت کنه. ولی اغلب CMPها تمپلیت متناسب با GTM رو ندارن یا ترجیح می‌دن از gtag به‌جای APIهای اختصاصی تمپلیت استفاده کنن. تو این حالت، شاید بهتر باشه کانسنت مود رو دستی مدیریت کنی.
بعنوان م4ال, تمپلیت Cookiebanners.nl این کار رو خیلی خوب انجام می‌ده. باید تگی که با این تمپلیت ساخته شده رو روی تریگر Consent Initialization - All Pages تنظیم کنی. تگ وقتی اولین بار اجرا بشه، کال دیفالت رو به‌صورت خودکار اجرا می‌کنه و اگه حالت‌های رضایت Cookiebanners.nl تو کوکی مرورگر موجود باشه، کال آپدیت رو دنبالش میفرسته. بعد، اگه کاربر انتخاب‌های مربوط به کانسنت رو تغییر بده، کتابخونه جاوااسکریپت Cookiebanners.nl با کال gtag('consent', 'update', ...) حالت‌های کانسنتش رو آپدیت می‌کنه و بعد یه دیتالیر.پوش با ایونتی که برای تریگر تگ‌ها قابل استفاده‌ باشه می‌فرسته.

راهنمای پیاده سازی کانسنت مود برای طراحای CMP
اگه روی یه CMP کار می‌کنی یا دنبال CMPی می‌گردی که با کانسنت مود کاملاً یکپارچه باشه، باید بدونی که CMP این ویژگی‌ها رو باید داشته باشه:
- نیاز به یه تمپلیت کاستوم GTM داره که از APIهای کانسنت تمپلیت کاستوم استفاده کنه یعنی این دو تا: setDefaultConsentState و updateConsentState. 

API اول باید فوراً کال بشه وقتی تگی که با تمپلیت ساخته شده اجرا شد (البته فقط یه بار تو هر بار لود صفحه!) و API دومی باید بلافاصله بعد از این، وضعیت کانسنت معلوم شد، فراخونی بشه. اگه کاربر تنظیمات کانسنت خودش رو بعدا تغییر بده، updateConsentState باید دوباره فراخونی بشه. این APIها خاص هستن چون مودهای کانسنت رو تو گوگل تگ منیجر فوراً تغییر می‌دن به‌جای اینکه منتظر پردازش کال gtag() توسط کانتینر بمونن.
- تمپلیت کاستوم باید یه ایونت دیتالیر رو فوراً بعد از هر کال آپدیت پوش بکنه چون که خود کال آپدیت کانسنت نمی‌تونه به‌عنوان تریگر GTM استفاده بشه! اگه می‌خوای تگ‌ها رو وقتی انتخاب‌های کانسنت کاربر معلومه یا تغییر می‌کنه تریگر کنی، CMP باید یه ایونت به دیتالیر بفرسته تا بعدش به‌عنوان ایونت کاستوم توی یه تریگر استفاده بشه. کال دیتالیر.پوش می‌تونه مثلاً این‌جوری باشه:
- CMP باید گزینه‌ای داشته باشه که کال‌های اولیه دیفالت و آپدیت رو بلوکه کنه اگه مدیر سایت بخواد با تمپلیت کاستوم خودش کنترل کامل این اتفاقات حیاتی رو به دست بگیره.- شیوه ساختن تمپلیت Cookiebanners.nl رو توی این لینک آوردم.

وصل کردن دستی CMP با تمپلیت کاستوم 
اگه می‌خوای حداقل ستاپ اولیه کانسنت مود رو داشته باشی ، می‌تونی از تمپلیت کانسنت مود (تگ‌های گوگل + مایکروسافت) سیمو آهاوا که توث GTM از این مسیرقابل دسترسی هست  استفاده کنی.

اگه این کار رو بکنی، مهمه که CMP خودش با کانسنت مود تعامل نکنه، وگرنه ممکنه چند کال آپدیت یا دیفالت، اغلب ضد و نقیض، اتفاق بیفته. کار CMP اینه که انتخاب‌های رضایت کاربر رو تو استوریج مرورگر (مثل کوکی‌ها یا لوکال استوریج) بنویسه و بعد یه ایونت به دیتالیر بفرسته که بشه ازش برای تریگر کردن تگ تمپلیت کاستوم استفاده کرد.

یه مثال از ستاپ ایده‌آل:
- یه تگ دیفالت جدید با تمپلیت من بساز.
- تریگرش رو Consent Initialization - All Pages بذار.
- همه سیگنال‌های کانطنت رو "denied" ست کن.
- اولویت تگ رو 10 بذار.

- بعد، یه تگ آپدیت جدید هم با همون تمپلیت بساز.
- تنظیمش کن که رو تریگر Consent Initialization - All Pages اجرا بشه.
- این تگ رو بلاک کن که اگه انتخاب کانسنت کاربر هنوز معلوم نیست اجرا نشه.
- سیگنال‌های کانسنت رو با وریبل‌ها به‌صورت پویا روی "denied" یا "granted" ست کن. معمولاً این اطلاعات تو کوکی مرورگر یا لوکال استوریج ذخیره می‌شه (مستندات CMP رو بخون تا مطمئن شی).
- گزینه Push dataLayer event رو روشن کن، تا تگ یه ایونت بسازد که بتونی ازش برای تریگر شدن تگ‌های مارکتینگی استفاده کنی.



با این دو تگ، لود اولیه و تنظیمات حیاتی کانسنت مود رو آماده می‌کنی.
وقتی کاربر بعد با بنر کانسنت تعامل می‌کنه، CMP باید یه ایونت به دیتالیر بفرسته که تغییر تو حالت‌های ذخیره‌شده کانسنت رو نشون بده. این دیتالیر پوش باید بعد از این اتفاق بیفته که مطمئن باشیم انتخاب‌های کانسنتی ذخیره‌شده به‌روز شدن.
بعد می‌تونی تگ آپدیت که قبلاً ساختی رو تنظیم کنی که با این ایونت دیتالیر هم اجرا بشه. کال آپدیت دوباره اتفاق می‌افته و کانسنت مود با حالت‌های جدید به‌روز می‌شه.

یه ستاپ مثل این تقریباً بدون نقصه چون قطعا سریع کار میکنه و کنترل کامل داری که کانسنت مود تو سایتت چطور پیاده‌سازی بشه.

 تنظیم تگ‌ها برای کار با بیسیک کانسنت مود(BCM)
حالا که از یه CMP استفاده می‌کنی که با کانسنت مود خوب کار می‌کنه، یا با تمپلیت کاستوم که همه سناریوها رو مدیریت می‌کنه، قسمت سخت کار مونده.
زمان کار با BCM، باید تگ‌ها رو بلاک کنی که تا وقتی رضایت داده نشده اجرا نشن. این تو ظاهر ساده به نظر میاد، ولی اینطور نیست. متأسفانه گوگل پیاده‌سازی BCM رو خیلی سخت کرده البته نسبت به راحتی کار با کانسنت مود پیشرفته.
قبل از اینکه بریم سراغ تنظیمات خاص تگ‌ها، مهمه که یه باگ بحرانی که ممکنه رو پیاده‌سازیت اثر بذاره رو بدونی.

باگ  "چک‌های اضافی کانسنت"
یه باگ خیلی کلافه‌کننده توی چک‌های اضافی کانسنت هست که باعث می‌شه برای تگ‌هایی که تنظیم Once per page روشون روشنه، قابل استفاده نباشه:

بخاطر این باگ، اگه تگ شما اول سعی کنه وقتی رضایت داده نشده (مثلاً تو تریگر Initialization - All Pages بالا) اجرا بشه، به درستی توسط چک‌های اضافی کانسنت بلاک میشه چون که وجود  کانسنت analytics_storage رو تشخیص نداده.
ولی وقتی تگ بعد از cmp_consent_banner_click و دریافت کانسنت باید اجرا بشه، اجرا نمی‌شه.
باگ اینه که چک‌های اضافی کانسنت تنظیم "Once per page" رو استفاده می‌کنه. از نظر GTM، تگ تو اون صفحه "اجرا شده"، حتی اگه تگ توسط چک‌های اضافی کانسنت بلاک شده باشه.
این خیلی بده و  برای تگ‌های Once per page باید از منطق تریگر برای کنترل اجرای این تگ ها استفاده کنی.

تگ‌های initialization که باید فقط یه بار تو هر لود صفحه اجرا بشن
این تگ‌ها مثل پیکسل Meta یا گوگل تگ هستن که باید زودتر از همه اجرا بشن و به اطلاعاتی که ممکنه تو GTM با تأخیر موجود بشن نیازی ندارن.
اگه کانسنت مود رو ست نکردی، این تگ‌ها رو با تریگر Initialization - All Pages باید فایر می‌کردی.
بعد از ستاپ BCM، اولین لحظه ای که مطمئنی رضایت داده شده، پوش شدن یه ایونت دیتالیر هست که توسط CMP یا تمپلیت کاستوم فوراً بعد از به‌روز شدن رضایت با حالت "granted" ارسال می‌شه.
مثلاً اگه از تمپلیت کاستوم سیموآهاوا استفاده کنی، تریگر مربوط به تگ‌هایی که به analytics_storage نیاز دارن این‌جوری می‌شه:
 
نکته: {{DLV - analytics_storage}} یه دیتالیر وریبل هست که به اسم analytics_storage اشاره می‌کنه، چون تمپلیت کاستوم از اون برای ارجاع به حالت‌های کانسنت کاربر استفاده می‌کنه.
اگه این تریگر رو به تگ‌های Once per page اضافه کنی، فقط وقتی کانسنت برای analytics_storage داده شده اجرا می‌شن. برای تگ‌هایی که به ad_storage نیاز دارن، یه تریگر جدید بساز و از اون استفاده کن.
نیازی به اضافه کردن چک‌های اضافی کانسنت مود یا تریگر بلاک به این تگ‌ها نیست. فقط وقتی کانسنت مرتبط داده شد این تگ ها اجرا می‌شن—تریگرت این مورد رو مدیریت می‌کنه.

 تگ‌های initialization که نیازه چند بار اجرا بشن
این مورد هم نسبتاً ساده‌ست. فرض کن یه تگ اولیه داری که باید وقتی کانسنت داده شده  تو پیج ویوهای مجازی یا وقتی کاربر لاگین می‌کنه اجرا بشه.
تو این حالت، تنظیم فایر شدن تگ باید روی Once per event باشه.
تریگر باید همون تریگر ستاپ بالا باشه که در اونها  کانسنت مود کاربر به "granted" آپدیت می‌شه.
علاوه بر این، تگ باید همه تریگرهای دیگه‌ای که می‌خوای بهش اضافه کنی رو داشته باشه.
نهایتاً، تنظیم چک‌های اضافی کانسنت رو به حالتی که تگ نیاز داره انجام بده —analytics_storage اگه مثال بالا رو دنبال کنی.

تو این حالت، تگ هر وقت کانسنت  analytics_storage داده شده باشه اجرا می‌شه. تگ همچنین برای همه ایونت‌های virtual_pageview اجرا می‌شه البته اگر کانسنت analytics_storage داده شده باشه.

تگ‌هایی که باید وقتی کانسنت داده شده و فقط تو شرایط خاصی اجرا بشن
اگه از چک‌های اضافی کانسنت استفاده کنی، تگ‌ها بلاک میشن اگه کانسنت داده نشده باشه. ولی وقتی کانسنت بعداً داده بشه، تگ ها خودکار دوباره اجرا نمی‌شن. باید خودت  لاجیک اونها رو مهندسی کنی.
بعضی تگ‌ها باید منتظر شرایط خاصی بمونن تا اجرا بشن. یه مثال رایج تگ ایکامرسی خرید هست که باید فوراً بعد از پوش ایونت خرید به دیتالیر اجرا بشه.
برای تگ‌هایی که فقط یه بار باید اجرا بشن، ساده‌ترین روش استفاده از تریگر گروپ هست.
یه تریگر گروپ می‌تونه یکی یا چند تا تریگر بگیره و فقط وقتی همه تریگرهایی که به گروپ اضافه شده اجرا بشن فعال می‌شه.
پس اگه یه تگ GA4 Purchase داری، تریگر گروپ این‌جوری می‌شه:

تگی با این تریگر فقط وقتی اجرا می‌شه که کانسنت برای analytics_storage معادل granted باشه و ایونت خرید به دیتالیر پوش شده باشه.
تگی مثل این نیازی به چک‌های اضافی کانسنت یا تریگرهای بلاک کننده نداره، چون یکی از شرایط اجرای اون وجود analytics_storage معادل "granted" هست.

تگ‌هایی که ممکنه چند بار اجرا بشن
تگ‌های ایونتی معمول مثل Add to cart، Scroll، Login و Timer ممکنه چند بار تو صفحه اجرا بشن.
ساده‌ترین روش اینه که از چک‌های اضافی کانسنت استفاده کنی تا این تگ‌ها بلاک بشن اگه رضایت مناسب داده نشده .

این ستاپ یعنی اگه رضایت داده نشده، تگ بلاک می‌شه. وقتی رضایت داده بشه، تگ خودکار دوباره اجرا نمی‌شه. تریگر گروپ‌ها اینجا کار نمی‌کنن چون فقط می‌تونن تو هر لود صفحه یه بار فعال بشن.

اگه می‌خوای این تگ‌ها- اگه کانسنت بعد از فایر شدن تریگر داده شده بود- خودکار اجرا بشن، باید یه سیستم نوبت دستی پیاده‌سازی کنی، که اینجا بهش نمی پردازیم. به نظرم هم ارزش زحمتش رو نداره—بعضی وقت‌ها یه کم از دست رفتن دیتا برای ساده نگه داشتن ستاپ کار خوبه.

 فلوچارت
اینجا یه فلوچارت از قواعد بخش های قبلی اومده.


 موارد نادر
خیلی موارد نادر برای این ستاپ هست.
بعضی وقتا ایونت gtm_consent_update نمی‌تونه تو زمان Consent Initialization پوش بشه چون دیتای انتخاب‌های کانسنتی کاربر موجود نیست. این ناشی از طراحی ضعیف CMP هست، ولی اتفاق می‌افته.
بعضی وقتا ایونت virtual_pageview تو لود اولیه صفحه اتفاق می‌افته، که ممانعت از پیج ویوهای تکراری رو سخت می‌کنه (یکی برای ایونت gtm_consent_update و یکی برای virtual_pageview).
بعضی وقتا CMP همکاری نمی‌کنه و کال دیفالت یا آپدیت معیوب می‌فرسته و همه‌چیز رو به‌هم می‌ریزه.

خلاصه مطالب
پیاده‌سازی کانسنت مود بیسیک به اندازه خوندن این راهنما از اول تا آخر سخته.
بزرگ‌ترین مشکل مدیریت تگها هست، جایی که تگ‌ها باید منتظر کانسنت بمونن تا بعدا براساس مکانیسم‌های تریگرشون فایر بشن.
خیلی CMPها به‌صورت ناهمزمان لود می‌شن و از کال‌های gtag() به‌جای تمپلیت‌های کاستوم گوگل تگ منیجر برای هماهنگی تعاملات کاربر با کانسنت مود استفاده می‌کنن. این باعث تأخیرهای غیرضروری می‌شه، جایی که تگ می‌تونست خیلی وقت پیش اجرا بشه ولی حالا باید منتظر یه CMP کند بمونه تا با به‌روزترین وضعیت کانسنت مود راهنمایی‌ش کنه.