با یکی از آپدیت های جدید گوگل، فاصله میان Google Tag Manager و Google Tag کمتر شده و این دو تکنولوژی حالا بیش از گذشته به یکدیگر نزدیک شده اند.
تا پیش از این، هر گوگل تگ عملا مانند یک لایه یا Wrapper روی یک کانتینر Google Tag Manager عمل می کرد، اما نکته عجیب این بود که کانتینرهای GTM به تمام قابلیت های Google Tag دسترسی نداشتند و از طرف دیگر، Google Tag نیز نمی توانست دقیقا همان امکانات Google Tag Manager را ارائه دهد.
اما یکی از مهم ترین تغییرات این است که حالا Google Tag هایی که به آنها دسترسی دارید می توانند مستقیما به عنوان Destination به کانتینر Google Tag Manager متصل شوند. در نتیجه، مدیریت تنظیمات تگ ها ساده تر می شود و می توان مجموعه ای از تنظیمات Google Tag را از طریق همان رابط کاربری GTM کنترل کرد.
این تغییر می تواند نقش مهمی در بهینه سازی کانتینر گوگل تگ منیجر داشته باشد، زیرا مدیریت Destination ها، تنظیمات تگ ها و ارتباط میان سرویس های مختلف گوگل از یک محیط متمرکز انجام می شود.
شاید در نگاه اول این سوال پیش بیاید که این تغییر چه اهمیتی دارد؟ Google Tag تا امروز همیشه بخشی نسبتا مبهم از اکوسیستم ابزارهای گوگل بوده و در بسیاری از موارد نتوانسته تمام وعده های اولیه خود را عملی کند.
اما حالا از نظر عملکرد سمت کاربر یا Client-side Performance، شرایط کاملا متفاوت شده است.
در ساختار جدید، Destination ها دیگر به صورت منابع جداگانه gtag.js بارگذاری نمی شوند. در عوض، فایل اصلی Google Tag Manager شامل تمام دستورها و تنظیماتی است که باید برای Destination های متصل اعمال شوند.
این تغییر می تواند به کاهش درخواست های اضافی و مدیریت بهینه تر منابع در سمت مرورگر کمک کند و از این جهت، یکی از نکات مهم در بهینه سازی کانتینر گوگل تگ منیجر محسوب می شود.
از طرف دیگر، گوگل با این ساختار جدید کاربران را به سمت یکپارچه کردن مدیریت دسترسی ها میان Google Tag Manager و Google Tag های متصل سوق می دهد. زمانی که Google Tag ها به شکل مستقیم به کانتینر متصل باشند، امکان استفاده از Permission های مشترک میان آنها فراهم می شود.
البته همچنان می توان Destination های مورد نیاز را به صورت موردی و از طریق نوع جدیدی از تگ ها با نام Destination Tag به کانتینر اضافه کرد. در ادامه مقاله بیشتر درباره این نوع تگ توضیح خواهیم داد. با این حال، اگر اتصال میان Google Tag Manager و Google Tag ها به شکل صحیح انجام نشده باشد، امکان استفاده از دسترسی های مشترک را از دست خواهید داد.
در ادامه این مقاله، ساختار جدید Tagging در Google Tag Manager و تغییراتی که در نحوه مدیریت تگ ها، Destination ها و تنظیمات ایجاد کرده است را با جزئیات بیشتری بررسی می کنیم.
تجربه جدید Tagging در Google Tag Manager به زبان ساده
مهم ترین تغییری که در ساختار جدید اتفاق افتاده این است که حالا خود کانتینر Google Tag Manager نیز به عنوان یک Google Tag شناخته می شود.
به این ترتیب، سرویس های مختلف گوگل مثل GA4، Google Ads و Floodlight می توانند به عنوان Destination به کانتینر Google Tag Manager متصل شوند. در نتیجه، همه این سرویس ها می توانند از یک مجموعه تنظیمات و دسترسی های مشترک استفاده کنند که به صورت متمرکز در خود کانتینر GTM مدیریت می شوند.
این ساختار، مدیریت تگ ها را ساده تر می کند و می تواند یکی از مهم ترین تغییرات در بهینه سازی کانتینر گوگل تگ منیجر باشد، چون دیگر لازم نیست تنظیمات مشابه برای هر سرویس به شکل جداگانه مدیریت شوند.
همزمان با این تغییر، نوع جدیدی از تگ ها با عنوان Destination Tag نیز به Google Tag Manager اضافه شده است. این تگ ها جایگزین نوع قدیمی Google Tag می شوند و وظیفه آنها شروع جمع آوری داده برای Destination مربوطه است.
یکی از مهم ترین مزیت های Destination Tag این است که برای فعال کردن هر Destination، فایل جداگانه ای از gtag.js بارگذاری نمی شود. در عوض، این تگ ها از همان تنظیمات مشترکی استفاده می کنند که در کانتینر Google Tag Manager تعریف شده است.
البته این موضوع به این معنا نیست که کنترل روی تنظیمات هر سرویس از بین می رود. Destination Tag ها همچنان تمام قابلیت های Loader های قبلی را در اختیار شما قرار می دهند. برای مثال، در صورت نیاز می توانید بعضی از فیلدهای تنظیمات را برای یک Destination خاص تغییر دهید یا مقدار متفاوتی برای آنها تعریف کنید.
این تگ ها همچنین با Consent Mode و تنظیمات مربوط به رضایت کاربران سازگار هستند و هنگام جمع آوری داده، وضعیت Consent را در نظر می گیرند.
در کنار این تغییرات، بخش هایی از رابط کاربری Google Tag Manager، تنظیمات کانتینر و Preview Mode نیز تغییر کرده اند که در ادامه مقاله آنها را بررسی خواهیم کرد.
پیش از آن، بهتر است با اصطلاحات و مفاهیم جدیدی که در این ساختار استفاده می شوند آشنا شویم.
Tagging Destination چیست؟
Google Tag مشخص می کند که محصولات مختلف گوگل تحت چه تنظیماتی فعالیت کنند. برای مثال، این تگ تعیین می کند چه Event هایی به صورت خودکار شناسایی شوند، جمع آوری First-party Data چگونه انجام شود و حتی در بعضی موارد می تواند تنظیمات پیش فرض Consent را تغییر دهد.
محصولات مختلف گوگل، مثل GA4 Data Stream، کانورژن های Google Ads یا تگ های فروش Floodlight، می توانند به عنوان Destination به یک Google Tag اضافه شوند.
وقتی یک محصول به عنوان Destination اضافه می شود، به صورت خودکار از تنظیماتی که در Google Tag تعریف شده استفاده می کند.
برای مثال، فرض کنید در Google Tag جمع آوری User-provided Data غیرفعال شده باشد. در این شرایط، یک Google Ads Conversion Tag که به این Google Tag متصل است نمی تواند این قابلیت را از طریق تنظیمات خودش فعال کند.
اما اگر جمع آوری User-provided Data در Google Tag فعال باشد، می توانید آن را از طریق تنظیمات Google Ads Tag غیرفعال کنید.
این ساختار باعث می شود تنظیمات مرکزی به عنوان حد پایه در نظر گرفته شوند و هر Destination فقط بتواند محدودیت بیشتری ایجاد کند، نه اینکه قوانین مرکزی را دور بزند.
Destination ها در ساختار جدید Google Tag Manager
وقتی محصولات مختلف را به عنوان Destination به Google Tag Manager متصل می کنید، تمام آنها تنظیماتی را که در بخش جدید Settings کانتینر تعریف شده است به ارث می برند.
در عین حال، اگر برای یک Destination خاص به تنظیمات سخت گیرانه تری نیاز داشته باشید، می توانید همان تنظیم را مستقیما در Destination Tag تغییر دهید.
این مدل یکی از بخش های مهم بهینه سازی کانتینر گوگل تگ منیجر است، چون به جای تعریف و نگهداری تنظیمات مشابه در چند تگ مختلف، می توانید بخش زیادی از تنظیمات را به صورت متمرکز در سطح کانتینر مدیریت کنید.
برای انتقال کانتینرهای قبلی به این ساختار، گوگل ابزاری با عنوان Optimization Wizard در اختیار کاربران قرار داده است.
Optimization Wizard در Google Tag Manager
اگر کانتینر Google Tag Manager شما قبل از ارائه این قابلیت ساخته شده باشد، احتمالا در رابط کاربری GTM یک بنر مشاهده می کنید که امکان شروع فرایند Optimization را در اختیارتان قرار می دهد.
این ابزار بخش زیادی از فرایند انتقال Google Tag های قبلی به ساختار جدید را به صورت خودکار انجام می دهد.
شروع فرایند Optimization
بعد از انتخاب گزینه شروع Optimization، پنجره جدیدی نمایش داده می شود که تمام Google Tag هایی را که به آنها دسترسی دارید و در کانتینر استفاده شده اند نشان می دهد.
در این مرحله می توانید مشخص کنید کدام Google Tag ها به صورت خودکار به عنوان Destination به کانتینر متصل شوند.
اگر تگی را از این فهرست خارج کنید، آن تگ همچنان به شکل قدیمی یا Legacy Google Tag در کانتینر باقی می ماند و از مزایای ساختار جدید استفاده نخواهد کرد.
برای هر تگ همچنین می توانید تعیین کنید افرادی که قبلا به Google Tag دسترسی داشته اند، Read Access به کانتینر Google Tag Manager نیز دریافت کنند یا خیر.
اعطای Read Access در بسیاری از موارد تصمیم منطقی تری است. دسترسی داشتن به یک Google Tag بدون امکان مشاهده مکانیزمی که آن را Deploy می کند، یعنی Google Tag Manager، می تواند مدیریت و عیب یابی تگ ها را دشوار کند.
البته این Permission ها بعدا نیز از طریق تنظیمات کانتینر قابل تغییر هستند.
همچنین می توانید از گزینه View settings استفاده کنید تا تنظیمات هر Google Tag را قبل از ادغام بررسی کنید. این کار به خصوص زمانی اهمیت دارد که چند Google Tag دارای تنظیمات متفاوت باشند.
انتخاب تنظیمات کانتینر
در مرحله بعد باید مشخص کنید کدام تنظیمات Google Tag به عنوان تنظیمات اصلی کانتینر Google Tag Manager استفاده شوند.
اگر تمام Destination ها تنظیمات یکسانی داشته باشند، تصمیم خاصی لازم نیست بگیرید و همان تنظیمات مشترک به کانتینر منتقل می شوند.
اما اگر Google Tag های مختلف تنظیمات متفاوتی داشته باشند، می توانید یکی از آنها را به عنوان مبنا یا Blueprint برای تنظیمات مشترک کانتینر انتخاب کنید.
حتی می توانید هیچ کدام از تنظیمات قبلی را Import نکنید و Shared Settings کانتینر را از ابتدا تنظیم کنید.
یکی از مهم ترین مزایای ساختار جدید Google Tag Manager همین مفهوم Shared Settings است.
تمام Destination هایی که به کانتینر متصل می شوند، می توانند از یک مجموعه تنظیمات مشترک استفاده کنند. در نتیجه دیگر نیازی نیست تنظیمات یکسان را در چند محصول مختلف گوگل به صورت جداگانه نگهداری و هماهنگ کنید.
این موضوع علاوه بر ساده تر شدن مدیریت تگ ها، احتمال ایجاد اختلاف میان تنظیمات GA4، Google Ads یا Floodlight را نیز کاهش می دهد.
البته همچنان می توانید بعضی تنظیمات را در سطح هر Destination Tag به صورت جداگانه Override کنید.
بررسی تغییرات قبل از اجرای Optimization
پیش از انتخاب گزینه Add to workspace بهتر است روی Show details کلیک کنید.
این بخش به شما نشان می دهد که Optimization Wizard دقیقا چه تغییراتی در کانتینر ایجاد خواهد کرد.
یکی از تغییرات مهم این است که Google Tag Settings به عنوان نوع جدیدی از Setting به کانتینر اضافه می شود. این تنظیمات از طریق منوی جدید Settings در Google Tag Manager قابل مدیریت خواهند بود.
Google Tag هایی که به کانتینر متصل شده اند نیز با وضعیت Modified نمایش داده می شوند.
دلیل آن این است که این تگ ها دیگر به عنوان Google Tag قدیمی فعالیت نخواهند کرد و به Destination Tag های جدید تبدیل می شوند.
اگر در مراحل قبلی تصمیم گرفته باشید به کاربران Destination ها Read Access به کانتینر بدهید، این تغییر نیز در همین بخش به شما نمایش داده می شود.
مشاهده وضعیت قبل و بعد از Optimization
ابزار Optimization یک نمای تصویری نیز در اختیار شما قرار می دهد تا بتوانید وضعیت تگ ها را قبل و بعد از مهاجرت مقایسه کنید.
فرض کنید این ابزار سه Google Tag را در کانتینر پیدا کرده باشد:
یک Floodlight Tag با شناسه ای مثل DC-12345 که به آن دسترسی ندارید و دو Google Tag مربوط به دو Measurement ID مختلف در GA4 که به هر دو دسترسی دارید.
در چنین شرایطی، ابزار Optimization مشخص می کند که دو Google Tag مربوط به GA4 امکان انتقال مستقیم به ساختار جدید را دارند.
در نمای Before هر سه تگ به صورت Google Tag های جداگانه دیده می شوند.
اما در نمای After، تگ Floodlight که به آن دسترسی ندارید همچنان به عنوان Google Tag جداگانه باقی می ماند، در حالی که دو Google Tag مربوط به GA4 به صورت Destination مستقیما به کانتینر Google Tag Manager متصل می شوند.
اضافه کردن تغییرات به Workspace
برای تکمیل فرایند Optimization باید گزینه Add to workspace را انتخاب کنید.
نکته مهم این است که این فرایند تغییرات را فقط به Workspace اضافه می کند و آنها را به صورت خودکار منتشر نمی کند.
بنابراین بعد از انجام بهینه سازی کانتینر گوگل تگ منیجر، همچنان باید مانند سایر تغییرات GTM ابتدا تنظیمات را با Preview Mode تست کنید و بعد از اطمینان از عملکرد صحیح، نسخه جدید کانتینر را Publish کنید.
یکی دیگر از مزیت های این روش این است که امکان Rollback نیز وجود دارد. اگر بعد از انتشار متوجه مشکلی شوید، می توانید کانتینر را به یکی از نسخه های قبلی برگردانید.
Destination Tag های جدید در Google Tag Manager
همزمان با این تغییرات، انواع جدیدی از Tag نیز به Google Tag Manager اضافه شده اند.
در این ساختار دیگر توصیه نمی شود از Google Tag قدیمی استفاده کنید، چون استفاده از آن باعث بارگذاری جداگانه فایل gtag.js می شود.
برای مثال، در بخش Google Analytics اکنون Destination Tag جدیدی وجود دارد که وظیفه Load کردن GA4 Data Stream مرتبط با کانتینر را بر عهده دارد.
مزیت اصلی این روش در مقایسه با Legacy Google Tag این است که هنگام فعال شدن Tag نیازی به بارگذاری Resource جداگانه وجود ندارد و اطلاعات مورد نیاز از همان GTM Library تامین می شوند.
به محض اینکه Destination Tag در کانتینر اجرا شود، از Shared Settings تعریف شده در سطح کانتینر نیز استفاده می کند. این تنظیمات می توانند موارد مختلفی، از جمله تشخیص خودکار Event ها را شامل شوند.
Destination Tag های جدید شامل این موارد هستند:
- Google Analytics
- Google Ads
- Google Floodlight
Google Tag قدیمی اکنون به عنوان Legacy شناخته می شود و بهتر است دیگر برای پیاده سازی های جدید از آن استفاده نشود.
Conversion Linker نیز در این ساختار به عنوان یک Legacy Tag در نظر گرفته می شود، چون عملکرد آن توسط Destination Tag های جدید پوشش داده شده است.
آیا همچنان می توان تنظیمات هر Destination را تغییر داد؟
بله. استفاده از Shared Settings به این معنا نیست که دیگر امکان شخصی سازی هر Destination وجود ندارد.
همچنان می توانید فیلدهای مختلف را در تنظیمات Destination Tag تغییر دهید.
برای مثال، می توانید ارسال خودکار Event مربوط به page_view را غیرفعال کنید یا تنظیمات مربوط به Server-side Tagging را برای همان Destination مشخص کنید.
Destination Tag های جدید همچنین Consent-aware هستند و مانند سایر تگ های جدید گوگل، تنظیمات مربوط به Consent کاربران را هنگام جمع آوری و ارسال داده در نظر می گیرند.
چرا باید Google Tag های قدیمی را به Destination Tag منتقل کنیم؟
ساده ترین راه برای درک این تغییر این است که Destination Tag را نسخه تکامل یافته Google Tag قدیمی در نظر بگیرید.
در حالت ایده آل، Google Tag های فعلی باید به Destination Tag های جدید منتقل شوند. برای تگ هایی که به آنها دسترسی دارید، Optimization Wizard بخش زیادی از این فرایند را به صورت خودکار انجام می دهد.
اما ممکن است این سوال مطرح شود که چرا گوگل تمام Legacy Google Tag ها را به صورت خودکار به Destination Tag تبدیل نمی کند؟
دلیل اصلی این است که Destination Tag های جدید به صورت خودکار از Shared Settings کانتینر استفاده می کنند.
اگر این مهاجرت بدون بررسی انجام شود، ممکن است تنظیمات مشترک کانتینر با تنظیمات قبلی یک Tag متفاوت باشند. چنین اختلافی می تواند روی کیفیت داده ها یا حتی Compliance و نحوه رعایت الزامات مربوط به حریم خصوصی تاثیر بگذارد.
به همین دلیل، هنگام انتقال یک Legacy Google Tag به Destination Tag باید حتما Shared Settings کانتینر را بررسی کنید و مطمئن شوید تنظیمات اختصاصی آن Destination با تنظیمات مرکزی تضاد ناخواسته ای ندارند.
در ادامه، نحوه پیاده سازی و مدیریت Shared Settings در Google Tag Manager را بررسی می کنیم.
تنظیمات Tag در کانتینر Google Tag Manager
در تجربه جدید Google Tag Manager، تنظیمات مربوط به Google Tag مستقیما داخل خود کانتینر قرار گرفته اند و دیگر لازم نیست برای مدیریت این تنظیمات به بخش های جداگانه مراجعه کنید.
با کلیک روی گزینه Settings در منوی Google Tag Manager، می توانید تنظیمات مشترکی را ببینید که روی تمام Destination Tag های اضافه شده به کانتینر اعمال می شوند.
در بالای این صفحه نیز گزینه Add destination قرار دارد. با انتخاب این گزینه، فهرستی از Google Tag Destination هایی نمایش داده می شود که روی آنها دسترسی Admin دارید و می توانید آنها را به راحتی به عنوان Destination به کانتینر GTM اضافه کنید.
این تنظیمات همان Shared Settings هستند که پیش تر درباره آنها صحبت کردیم.
یکی از مزیت های مهم ساختار جدید این است که هر کدام از این تنظیمات به عنوان یک Resource داخل Google Tag Manager در نظر گرفته می شوند.
در نتیجه، تغییراتی که روی تنظیمات انجام می دهید دارای Version History خواهند بود و می توانید مانند سایر تغییرات کانتینر، سابقه آنها را نیز بررسی کنید.
زمانی که یکی از این تنظیمات را تغییر می دهید، تغییر مورد نظر ابتدا به عنوان Workspace Change ثبت می شود.
این یعنی می توانید قبل از انتشار، آن را در Preview Mode بررسی و تست کنید. تنظیم جدید تنها زمانی روی سایت اعمال می شود که نسخه جدید کانتینر را Publish کنید.
این موضوع از نظر مدیریت تغییرات اهمیت زیادی دارد، چون تنظیمات اصلی Google Tag دیگر به صورت مستقل و خارج از چرخه تست و انتشار GTM تغییر نمی کنند.
در نتیجه، در فرایند بهینه سازی کانتینر گوگل تگ منیجر می توانید تغییرات مربوط به Tag Settings را نیز مانند سایر تغییرات کانتینر کنترل، تست و نسخه بندی کنید.
وضعیت Legacy Google Tag ها در بخش Destination
اگر همچنان Google Tag های قدیمی یا Legacy در کانتینر داشته باشید، آنها نیز در فهرست Destination ها نمایش داده می شوند.
با این حال، این تگ ها با وضعیت Not optimized مشخص خواهند شد و External Account Link نیز برای آنها وجود نخواهد داشت.
External Account Link اهمیت زیادی در سطح دسترسی کاربران دارد.
اگر یک Destination به عنوان External Account Link به کانتینر متصل نشده باشد، افرادی که به آن Destination دسترسی دارند الزاما نمی توانند خود کانتینر Google Tag Manager را مشاهده کنند.
به عبارت دیگر، دسترسی به یک محصول یا Destination به صورت خودکار به معنای دسترسی به GTM نیست.
مشکل احتمالی: تداخل میان تنظیمات کانتینر و Destination
یکی از قابلیت هایی که هنوز در این ساختار وجود ندارد اما می تواند مدیریت Tag ها را بسیار شفاف تر کند، نمایش Conflict میان Shared Settings کانتینر و تنظیمات اختصاصی هر Destination است.
برای مثال، فرض کنید در تنظیمات یک Destination قابلیت User-provided Data غیرفعال شده باشد، اما تنظیمات مرکزی Google Tag Manager اجازه استفاده از این قابلیت را بدهند.
چنین اختلافی می تواند باعث ابهام در رفتار نهایی Tag شود و حتی در بعضی شرایط مشکلاتی در زمینه Compliance یا نحوه جمع آوری داده ایجاد کند.
Shared Read Permission تا حدی به شفاف شدن این وضعیت کمک می کند، اما همچنان بهتر است خود Google Tag Manager بتواند وجود چنین اختلافی را به ادمین کانتینر هشدار دهد.
البته پیاده سازی چنین قابلیتی یک چالش مهم دارد.
ادمین های Google Tag Manager لزوما به تنظیمات داخلی Google Tag متصل شده دسترسی ندارند. بنابراین GTM نباید اطلاعاتی را نمایش دهد که کاربر مجوز مشاهده آنها را ندارد.
یک راه حل منطقی می تواند صرفا نمایش یک هشدار درباره وجود Conflict باشد، بدون اینکه جزئیات تنظیمات Destination نمایش داده شود.
در این صورت ادمین کانتینر متوجه می شود که میان Shared Settings و تنظیمات Destination اختلافی وجود دارد و می تواند موضوع را با فردی که دسترسی لازم به آن Destination دارد بررسی کند.
قابلیت جدید Manage data transmission settings
یکی دیگر از قابلیت های نسبتا جدید در Google Tag Manager گزینه Manage data transmission settings است.
این تنظیم را می توان نوعی کنترل برای Basic Consent Mode در کنار Advanced Consent Mode در نظر گرفت.
با استفاده از این قابلیت می توانید مشخص کنید زمانی که Consent لازم از کاربر دریافت نشده است، Google Tag Manager ارسال Hit های مرتبط را به صورت خودکار متوقف کند یا خیر.
اگر کاربر بعدا Consent لازم را ارائه کند، GTM می تواند Hit هایی را که به دلیل نبود Consent ارسال نشده بودند، دوباره اجرا کند.
این قابلیت به خصوص برای پیاده سازی Basic Consent Mode اهمیت زیادی دارد.
یکی از پیچیده ترین بخش های Basic Consent Mode مدیریت Event هایی است که به دلیل نبود Consent مسدود می شوند و باید بعد از دریافت رضایت کاربر دوباره اجرا شوند.
Manage data transmission settings بخش زیادی از این فرایند را به صورت خودکار مدیریت می کند.
کنترل ارسال داده برای Analytics و Advertising
این تنظیم به شما اجازه می دهد جریان داده را برای Tag های Analytics و Advertising کنترل کنید.
در مورد Advertising Tag ها، سطح کنترل دقیق تر است.
برای مثال، می توانید مشخص کنید در صورت نبود Consent فقط مجموعه محدودی از داده ها ارسال شود که مشابه رویکرد معمول در Advanced Consent Mode است.
یا می توانید ارسال درخواست های تبلیغاتی را به طور کامل متوقف کنید تا زمانی که Consent مربوط به ad_storage دریافت شود.
این قابلیت می تواند پیاده سازی Basic Consent Mode را به شکل قابل توجهی ساده تر کند و در بعضی سناریوها حتی نیاز به تعریف Consent Settings جداگانه برای هر Tag را کاهش دهد.
محدودیت Manage data transmission settings
با وجود مزایای این قابلیت، یک محدودیت مهم وجود دارد.
Manage data transmission settings فقط روی Tag های خود گوگل تاثیر دارد.
بنابراین اگر در Google Tag Manager از Tag های مربوط به Vendor های دیگر استفاده می کنید، این تنظیم نمی تواند ارسال داده آنها را مدیریت یا متوقف کند.
در چنین شرایطی همچنان باید Consent Management را برای Tag های شخص ثالث به صورت جداگانه پیاده سازی کنید.
حالا که نحوه عملکرد Shared Settings و مدیریت ارسال داده را بررسی کردیم، در بخش بعدی می توانیم ببینیم Permission ها چگونه میان Google Tag Manager و Google Tag های متصل شده توزیع می شوند.
مدیریت Permission ها در Google Tag Manager
به صورت پیش فرض، کاربرانی که قبلا به یک Google Tag دسترسی داشته اند، در صورتی که آن Google Tag به عنوان Destination به کانتینر Google Tag Manager اضافه شود، به صورت خودکار Read Access به کانتینر دریافت می کنند.
البته این دسترسی ها قابل تغییر هستند. برای مدیریت آنها می توانید وارد بخش Admin شوید و از Container Settings گزینه External account links را انتخاب کنید.
نکته مهم این است که این ارتباط دسترسی فقط در یک جهت عمل می کند.
یعنی کاربرانی که به کانتینر Google Tag Manager دسترسی دارند، به صورت خودکار به Google Tag های متصل شده دسترسی پیدا نمی کنند.
هدف از این مدل دسترسی، افزایش شفافیت و کاهش ابهام هایی است که ممکن است به دلیل تفاوت میان تنظیمات کانتینر و تنظیمات Google Tag ایجاد شوند.
همان طور که در بخش های قبل توضیح دادیم، زمانی که یک محصول به عنوان Destination به کانتینر GTM اضافه می شود، تمام Google Tag Settings تعریف شده در کانتینر را به ارث می برد.
اگر کاربری که Google Tag را مدیریت می کند به کانتینر GTM دسترسی نداشته باشد، ممکن است متوجه نشود چرا بعضی از تنظیماتی که در Google Tag تعریف کرده است هنگام اجرای تگ اعمال نمی شوند. دلیل این اتفاق می تواند وجود تنظیمات متفاوت در کانتینر Google Tag Manager باشد.
به همین دلیل، دادن Read Access به کانتینر می تواند تصمیم مناسبی باشد.
با این حال، قبل از فعال کردن این دسترسی بهتر است کاربران Google Tag را بررسی کنید. در غیر این صورت ممکن است ناخواسته فردی به محتوای کانتینر GTM دسترسی پیدا کند که نیازی به مشاهده آن ندارد.
ممکن است در آینده مدل Permission دقیق تر شود و به جای دسترسی خواندن به کل کانتینر، کاربران خارجی فقط به بخش هایی مثل Tag Settings دسترسی داشته باشند.
تغییرات صفحه Overview کانتینر
در ساختار جدید، صفحه Overview در Google Tag Manager دید بهتری از ارتباط میان محصولات مختلف گوگل ارائه می دهد.
در این صفحه یک نمودار نمایش داده می شود که نشان می دهد چه محصولات و Destination هایی به کانتینر اضافه شده اند و داده چگونه میان آنها جریان پیدا می کند.
برای Legacy Google Tag ها، یک مرحله اضافی بین کانتینر و Destination نمایش داده می شود.
برای مثال، ممکن است دو Destination مربوط به GA4 مستقیما به کانتینر متصل باشند، اما Google Ads و Floodlight همچنان به صورت Legacy Google Tag در کانتینر حضور داشته باشند و به شکل مستقیم به کانتینر لینک نشده باشند.
عددی که در کنار هر Destination نمایش داده می شود نیز نشان می دهد چند Tag به آن Destination ارجاع می دهند. این تعداد می تواند شامل Google Tag یا Destination Tag باشد.
اگر روی یک Destination کلیک کنید، پنجره Destination details باز می شود.
در این بخش می توانید تمام Tag هایی را ببینید که به آن Destination متصل هستند.
این قابلیت دید مناسبی از ساختار کانتینر ایجاد می کند و در فرایند بهینه سازی کانتینر گوگل تگ منیجر کمک می کند سریع تر متوجه شوید داده از چه مسیرهایی به محصولات مختلف گوگل ارسال می شود.
تغییرات Preview Mode در Google Tag Manager
Preview Mode نیز در تجربه جدید GTM تغییراتی داشته است که برای تست Tag ها و Consent اهمیت زیادی دارند.
یکی از این تغییرات نمایش وضعیت Deferred Hit است.
Deferred Hit چیست؟
اگر از تنظیم Manage data transmission استفاده کرده باشید و مشخص کرده باشید که داده های Analytics یا Advertising تا قبل از دریافت Consent مناسب ارسال نشوند، Tag ها همچنان ممکن است اجرا شوند، اما Hit مربوط به آنها بلافاصله ارسال نمی شود.
در این شرایط، Hit در وضعیت Deferred قرار می گیرد.
به محض اینکه Consent Update مناسب دریافت شود، GTM می تواند Hit هایی را که منتظر دریافت Consent بوده اند ارسال کند.
Preview Mode این وضعیت را به صورت بصری نمایش می دهد و به شما کمک می کند بررسی کنید که Tag ها واقعا مطابق ساختار Basic Consent Mode رفتار می کنند یا خیر.
این قابلیت حتی زمانی کاربرد دارد که Trigger یک Tag بدون توجه به Consent اجرا شود، چون می توانید ببینید که خود Tag اجرا شده اما ارسال داده تا دریافت Consent متوقف مانده است.
نمایش Hits sent در Preview Mode
از آنجا که در ساختار جدید خود Google Tag Manager نیز به عنوان یک Google Tag در نظر گرفته می شود، حالا تب Hits sent مستقیما در Preview Mode کانتینر GTM نمایش داده می شود.
در این بخش می توانید Hit هایی را که در نتیجه اجرای یک Trigger Event ارسال شده اند بررسی کنید.
گاهی ممکن است در این قسمت هشداری درباره تاخیر در ارسال Hit مشاهده کنید.
این هشدار لزوما به معنی وجود مشکل نیست. ممکن است GTM ابتدا Trigger Event را پردازش کرده باشد و Destination کمی بعد در کانتینر Load شده باشد. در نتیجه ارسال Hit با تاخیر کوتاهی انجام شده است.
اگر در نتیجه یک Trigger Event، یک Destination Tag اجرا شود، Preview Mode همچنین تنظیماتی را که در آن لحظه در کانتینر فعال بوده اند نمایش می دهد.
در بخش Settings می توانید ببینید کدام Shared Settings روی آن Destination اعمال شده اند.
با کلیک روی هر Setting نیز امکان مشاهده مقدار و تنظیمات مربوط به آن وجود دارد.
این قابلیت برای عیب یابی بسیار کاربردی است، چون می توانید در همان Preview Mode بررسی کنید که یک Destination دقیقا تحت تاثیر چه تنظیماتی قرار گرفته است.
البته در کانتینرهایی که تعداد زیادی Destination دارند، ممکن است این نمای یکپارچه به مرور شلوغ شود. با این حال، در شرایط فعلی اطلاعات بیشتری درباره جریان داده، Consent و تنظیمات موثر بر هر Destination در اختیار کاربر قرار می دهد.
