بنر کوکی و تگ‌گذاری سمت سرور: چه چیزی تغییر می‌کند و چه چیزی نه

نام میزبان شخص اول یک مشخصه فنی درخواست است، نه مجوز. اگر دیروز برای گذاشتن کوکی تحلیلی به رضایت نیاز داشتید، امروز هم نیاز دارید، و اینکه کوکی حالا به‌جای google-analytics.com از سوی metrics.yoursite.com گذاشته می‌شود، هیچ ربطی به موضوع ندارد. پرسش نهاد ناظر این است که چه چیزی را و چرا جمع‌آوری می‌کنید، نه اینکه بسته در مسیرش از کدام سرور گذشته است.

آنچه تغییر می‌کند، سرنوشت درخواستی است که پیش‌تر مسدود می‌شد. مسدودکننده‌های تبلیغات و قابلیت‌های حریم خصوصی مرورگر بر اساس نام میزبان و الگوی URL مسدود می‌کنند و googletagmanager.com را مسدود می‌کنند. دامنه خود شما را مسدود نمی‌کنند. بنابراین بازدیدکننده‌ای که رضایت داده و یک فهرست فیلتر بی‌صدا حذفش می‌کرد، حالا شمرده می‌شود. کل فایده همین است، و فقط برای بازدیدکنندگانی که رضایت داده‌اند فایده محسوب می‌شود.

رضایت همچنین نخستین دلیل از چهار دلیلی است که GA4 تبدیل‌های کمتری از فروشگاه شما گزارش می‌کند: چرا GA4 کمتر می‌شمارد و کدام بخش‌ها را می‌توان بازگرداند.

تگ‌های Google یک وضعیت رضایت را می‌خوانند که از چند مجوز نام‌دار تشکیل شده است — analytics_storage، ad_storage، ad_user_data، ad_personalization — و آنچه می‌فرستند را بر اساس آن تنظیم می‌کنند. پیش از اینکه بازدیدکننده تصمیم بگیرد، مدیر رضایت مقدار پیش‌فرض denied را ارسال می‌کند؛ وقتی انتخاب کرد، یک update ارسال می‌کند. در وضعیت denied، تگ Google همچنان اجرا می‌شود اما یک پینگ بدون کوکی می‌فرستد: بدون شناسه کلاینت، بدون کوکی، فقط نشانه‌ای از اینکه صفحه‌ای دیده شده و نه بیشتر. به‌محض اینکه analytics_storage مجاز (granted) شود، هیت کامل را می‌فرستد. کانتینر سرور هر کدام را که ارسال شده باشد دریافت می‌کند و سیگنال‌های رضایت همراه هیت منتقل می‌شوند، پس تگ GA4 سمت سرور هم دقیقاً همین‌طور رفتار می‌کند.

مدیر رضایت باید پیش از تگ Google بارگذاری شود تا وقتی تگ برای اولین بار ارزیابی می‌شود، مقدار پیش‌فرضش سر جایش باشد. بیشتر مدیران رضایت دقیقاً برای همین یک مقدار wait_for_update ارائه می‌دهند — چند صد میلی‌ثانیه که تگ پیش از آنکه denied را فرض کند، منتظر وضعیت رضایت می‌ماند.

موجودیت‌هایی که SignalHost در کانتینر وب شما می‌سازد هیچ شرط رضایتی ندارند. این کار عمدی است. تگ‌های خود Google به Consent Mode پایبندند؛ بررسی رضایتی که دستی روی تگ Google اضافه شده باشد، بدون هیچ بررسی‌ای روی تگ‌های رویداد GA4 زیر آن، اولین اشتباه از دو اشتباهی است که در ادامه می‌آید.

تگ Google همان چیزی است که اندازه‌گیری را از مسیر کانتینر سرور عبور می‌دهد. یک تگ رویداد GA4 — مثلاً تگ purchase — می‌تواند مستقلاً ارسال کند. اگر تگ Google منتظر رضایت بماند و تگ‌های رویداد نه، تگ‌های رویداد پیش از رضایت اجرا می‌شوند و مستقیماً به Google ارسال می‌کنند، آن هم از صفحه‌ای که بنرش هنوز باز است. صفحه کانتینر هیچ مشکلی نشان نمی‌دهد، چون این هیت‌ها هرگز از کانتینر عبور نکرده‌اند.

یا هیچ چیزی را دستی مشروط نکنید و بگذارید Consent Mode این کار را بکند، یا هر تگی را که می‌تواند ارسال کند مشروط کنید. هیچ حد وسط یکدستی وجود ندارد.

برخی مدیران رضایت با مسدود کردن اسکریپت‌ها تا زمان دادن رضایت کار می‌کنند — تگ‌های script را بر اساس URL رهگیری می‌کنند و نگه می‌دارند. فهرست‌هایشان googletagmanager.com را می‌شناسند. اما exxz2gdaz1jz.yoursite.com را نمی‌شناسند، چون فهرست هیچ‌کس نمی‌تواند آن را بشناسد: نام میزبان و نام فایل بارگذار مختص کانتینر شماست. بنابراین در حالت مسدودسازی ممکن است بارگذار بی‌قیدوشرط اجازه عبور بگیرد، و اگر به مسدودسازی تکیه کرده‌اید نه به Consent Mode، این یعنی تگی که پیش از رضایت اجرا می‌شود.

دو راه وجود دارد. URL بارگذار را دستی به قواعد مسدودسازی مدیر رضایت اضافه کنید، در همان دسته‌ای که ابزارهای تحلیلی شما به آن تعلق دارند. یا — که بهتر است، چون پینگ بدون کوکی را هم درست مدیریت می‌کند — برای تگ‌های Google به Consent Mode تکیه کنید و مسدودسازی را فقط برای اسکریپت‌هایی به کار ببرید که از آن پشتیبانی نمی‌کنند. سایت خود ما یک مدیر رضایت را در حالت مسدودسازی خودکار و همراه با Consent Mode اجرا می‌کند؛ تگ Google بعد از اسکریپت مدیر رضایت قرار گرفته و اگر کسی ترتیبشان را عوض کند، یک تست در مخزن کد شکست می‌خورد.

وضعیت رضایت درون هر هیت به کانتینر سرور می‌رسد و تگ GA4 سمت سرور آن را همان‌طور می‌خواند که تگ سمت مرورگر می‌خواند. هیچ چیز در سمت ما رضایتی اعطا نمی‌کند یا آن را ارتقا نمی‌دهد؛ پینگ بدون کوکی، پینگ بدون کوکی باقی می‌ماند.

اگر یک پلتفرم تبلیغاتی وصل کنید — Meta، TikTok، Reddit، Pinterest، Snapchat یا LinkedIn — همین هیت‌ها به آن هم می‌رسند، اما فقط از بازدیدکنندگانی که ad_storage را مجاز کرده‌اند. سرور وضعیت رضایتی را که هر هیت همراه دارد می‌خواند و برای هر کسی که تبلیغات را رد کرده یا هنوز پاسخی نداده، هیچ چیزی به آن پلتفرم‌ها نمی‌رود: نه رویدادی و نه کوکی‌ای. تبدیل‌های Google Ads همانند تگ‌های خود Google از Consent Mode پیروی می‌کنند، یعنی به‌صورت سیگنالی بدون کوکی که هرگز به یک کلیک گره نمی‌خورد، و بازاریابی مجدد منتظر رضایت می‌ماند. همه این‌ها به این بستگی دارد که بنر، Consent Mode را تنظیم کند: صفحه‌ای که آن را ندارد هیچ وضعیت رضایتی نمی‌فرستد و هر هیت، مجاز (granted) به حساب می‌آید. این را همان‌طور بررسی کنید که هر چیز دیگری را در اینجا بررسی می‌کنید: سایت را بدون پاسخ دادن به بنر باز کنید، زبانه Network را زیر نظر بگیرید و ببینید چه چیزی خارج می‌شود.

«تطبیق تبدیل‌های بیشتر»، اگر روشنش کنید، باعث می‌شود تگ Google نشانی ایمیلی را که بازدیدکننده در یک فرم وارد می‌کند بردارد، تا پلتفرم‌های تبلیغاتی بتوانند تبدیل را با آن شخص تطبیق دهند. مرورگر آن را صرف‌نظر از انتخاب بازدیدکننده ارسال می‌کند. SignalHost آن را در لبه (edge) از هر هیتی که رضایت تبلیغاتی‌اش رد شده حذف می‌کند، پیش از اینکه هیت جلوتر برود، و پلتفرم‌ها همیشه فقط نسخه هش‌شده آن را دریافت می‌کنند.

• اسکریپت مدیر رضایت در صفحه بالاتر از تگ Google قرار دارد.
• پیش از بارگذاری تگ، وضعیت رضایت پیش‌فرض denied همراه با یک wait_for_update ارسال می‌شود.
• هیچ تگی در کانتینر شرط رضایتی ندارد که دستی اضافه شده باشد — یا هر تگی که می‌تواند ارسال کند چنین شرطی دارد.
• وقتی به بنر پاسخ نداده‌اید، زبانه Network یک پینگ بدون کوکی (gcs=G100 در درخواست) نشان می‌دهد و هیچ هیت کاملی در کار نیست.
• پس از پذیرفتن، همان صفحه یک هیت کامل نشان می‌دهد و صفحه کانتینر آن را می‌شمارد.
• اگر مدیر رضایت بر اساس URL مسدود می‌کند، URL بارگذار در قواعد آن آمده است.