پیاده‌سازی سمت سرور (Server-Side Tagging) انتقال بار پردازش و ردیابی داده‌ها از مرورگر کاربر به یک سرور ابری است. در این مقاله جامع، ابتدا معماری‌های پیش‌فرض استقرار شامل محیط‌های گوگل کلود (Cloud Run و App Engine) و همچنین روش استقرار با داکر را از منظر فنی، الزامات زیرساختی و برآورد هزینه‌های عملیاتی بررسی می‌کنیم. در ادامه این مقاله از بخش آموزش سرور در بلاگ پارس‌پک، استقرار کانتینر GTM در PaaS پارس‌پک را به عنوان یک زیرساخت مدیریت‌شده پیاده‌سازی کرده و در نهایت، فرایند کامل اتصال دامنه اختصاصی برای عبور از محدودیت‌های رهگیری مرورگرها و پیکربندی نهایی تگ‌ها را مرحله به مرحله آموزش می‌دهیم.
انتخاب و راه‌اندازی زیرساخت سرور GTM
برای پیاده‌سازی سرورساید تگینگ، پیش از انجام هرگونه تنظیمات در پنل تگ منیجر، نیازمند یک محیط ابری هستید تا بار پردازشی را از مرورگر کاربر تحویل گرفته و مدیریت کند. در این بخش، چهار معماری و مسیر متفاوت برای استقرار این زیرساخت را با تمام جزئیات، هزینه‌های پنهان و محدودیت‌های عملیاتی بررسی می‌کنیم.
شما می‌توانید بر اساس بودجه، نیاز سازمان و توانمندی تیم فنی خود، یکی از این چهار روش را انتخاب و اجرا کنید. پس از روشن شدن سرور و اتصال دامنه در روش انتخابی خود، برای تکمیل فرایند مستقیما به «بخش دوم» (پیکربندی نهایی در پنل GTM) مراجعه کنید.
روش اول: استقرار روی گوگل کلود (Cloud Run)
استقرار روی زیرساخت Google Cloud Platform (GCP) روش پیش‌فرض گوگل برای اجرای سرورساید است. این فرایند می‌تواند به صورت خودکار از داخل پنل تگ منیجر یا به صورت دستی در محیط Cloud Run انجام شود. مراحل، پیش‌نیازها و چالش‌های فنی این روش طبق مستندات رسمی گوگل به شرح زیر است:
۱. پیش‌نیازهای زیرساختی
برای شروع، شما قطعا به یک حساب کاربری GCP و یک حساب پرداخت (Billing Account) متصل به کارت اعتباری بین‌المللی نیاز دارید. کاربر اجراکننده باید نقش‌های Project Creator و Billing Account User را در سیستم مدیریت دسترسی گوگل داشته باشد.
۲. استقرار خودکار (Automatic Provisioning)
سریع‌ترین راه گوگل برای ساخت سرور، استفاده از دکمه استقرار خودکار است. پس از ساخت کانتینر در پنل GTM، با کلیک روی گزینه Automatically provision tagging server و انتخاب حساب پرداخت دلاری، گوگل یک سرور تستی روی Cloud Run می‌سازد. نتیجه این کار اختصاص یک آدرس پیش‌فرض به شکل https://[PROJECT_ID]-uc.a.run.app است. شما فقط یک بار می‌توانید این فرایند خودکار را اجرا کنید.
هشدار استراتژیک این روش: استفاده از این دکمه ظاهرا راحت، دو مشکل زیرساختی برای تیم مارکتینگ شما به همراه دارد:
قفل شدن موقعیت مکانی (Region Lock): در فرایند استقرار خودکار، سرور شما بدون حق انتخاب، منحصرا در دیتاسنترهای مرکزی آمریکا (us-central1) راه‌اندازی می‌شود. این یعنی تمام ترافیک بازدیدکنندگان ایرانی شما باید مسیر رفت و برگشت تا امریکا را طی کند که منجر به افزایش شدید پینگ (Latency) و تاخیر در لود اسکریپت‌ها می‌شود.
دامنه مسدودشده: دامنه پیش‌فرضی که گوگل به سرور می‌دهد (run.app)، در لیست سیاه اکثر ادبلاکرها و مرورگرهای سخت‌گیر قرار دارد و به عنوان ردیاب شخص ثالث مسدود می‌شود.
برای فرار از این محدودیت‌ها، شما چاره‌ای جز استقرار دستی (Manual Provisioning) برای انتخاب ریجن نزدیک‌تر به ایران و تحمل پیچیدگی‌های فنی آن ندارید.
۳. مدیریت منابع و برآورد دقیق هزینه‌ها
در معماری Cloud Run، هر سرور (شامل ۱ هسته پردازشی vCPU و ۰.۵ گیگابایت رم) ماهانه حدود ۴۵ دلار هزینه دارد. گوگل اکیدا توصیه می‌کند برای جلوگیری از از دست رفتن داده‌ها در زمان قطعی سرور، حداقل ۲ نمونه (Instance) فعال داشته باشید. این یعنی نقطه شروع شما ماهانه ۹۰ دلار هزینه ثابت ارزی است. (گوگل برای برآورد دقیق‌تر بر اساس ترافیک، استفاده از ماشین حساب قیمت‌گذاری Cloud Run را پیشنهاد می‌دهد، اما خروجی نهایی برای حداقل منابع عملیاتی همان ۹۰ دلار است). مکانیزم مقیاس‌پذیری خودکار (Autoscaling) به این شکل عمل می‌کند: شبکه‌ای متشکل از ۲ الی ۱۰ سرور می‌تواند بین ۳۵ تا ۳۵۰ درخواست در ثانیه را پردازش کند اما با افزایش ترافیک، زیرساخت گوگل برای حفظ پایداری به طور خودکار سرورهای بیشتری را درگیر می‌کند و به همان نسبت، صورت‌حساب پرداختی شما را هم به صورت تصاعدی بالا می‌برد.
۴. پیکربندی استقرار چندمنطقه‌ای (Multi-region Deployment)
اگر سایت شما ترافیک بین‌المللی دارد یا می‌خواهید افزونگی (Redundancy) در سرویس ایجاد کنید، باید سرورها را در چند ریجن مختلف دیپلوی کنید. پیش از اجرای اسکریپت، باید یک لودبالانسر ایجاد کرده و نام آن (BACKEND_NAME) را یادداشت کنید. سپس در اسکریپت زیر، مقادیر زیر را با اطلاعات سرور خود جایگزین کرده و کد را در خط فرمان گوگل کلود اجرا کنید:
REGION: ریجنی که سرور پیش‌نمایش در آن مستقر است.
CONTAINER_CONFIG: رشته کانفیگ کانتینر شما که از پنل GTM دریافت کرده‌اید.
NEW_REGION: ریجن جدیدی که می‌خواهید سرورهای تگ‌گذاری در آن مستقر شوند.
BACKEND_NAME: نامی که در زمان ساخت لودبالانسر انتخاب کرده‌اید.
۵. غیرفعال کردن لاگ‌ها (برای جلوگیری از هزینه‌های پنهان)
به صورت پیش‌فرض، گوگل کلود تمام جزئیات مربوط به درخواست‌ها و حتی پیام‌های متنی داخل کنسول را ثبت می‌کند. اگر سرور شما بیش از ۱ میلیون درخواست در ماه مدیریت می‌کند، این لاگ‌ها هزینه‌های سرسام‌آوری (Logging charges) روی دست شما می‌گذارند. برای مدیریت این بحران، تیم فنی شما باید دو نوع لاگ را به صورت دستی فیلتر کند:
الف) فیلتر لاگ درخواست‌ها (Request logging): برای متوقف کردن ثبت درخواست‌ها باید این مسیر دستی را در GCP طی کنید:
۱. در پلتفرم گوگل کلود، وارد بخش Logs Router شوید. در همان ابتدا مطمئن شوید که پروژه انتخاب‌شده دقیقا با Container ID شما در تگ منیجر تطابق دارد:
۲. در ردیف مربوط به Type: Cloud Logging bucket و Name: _Default، روی منوی گزینه‌ها (overflow menu) کلیک کرده و گزینه Edit Sink را انتخاب کنید.
۳. در بخش Sink destination، بررسی کنید که logs bucket روی _Default تنظیم شده باشد.
۴. در بخش Choose logs to include in sink، یک خط جدید ایجاد کنید و فیلتر زیر را برای حذف لاگ‌های درخواست کانتینر اعمال کنید:
۵. برای جلوگیری از هزینه‌های جانبی لودبالانسر، یک خط دیگر اضافه کرده و فیلتر زیر را نیز وارد کنید:
۶. روی گزینه Update Sink کلیک کنید تا تغییرات اعمال شود. پس از آن باید به Logs Explorer بروید تا مطمئن شوید هیچ درخواست جدیدی ثبت نمی‌شود.
۶. اتصال دامنه اختصاصی (Custom Domain) و ثبت در تگ منیجر
برای اینکه سرور شما بتواند محدودیت‌های مرورگرها و ادبلاکرها را دور بزند، باید از دامنه پیش‌فرض گوگل (مانند run.app) خارج شوید و یک ساب‌دامین اختصاصی روی آن تنظیم کنید تا کوکی‌ها به عنوان کدهای First-party شناخته شوند.
چالش پنهان در این مرحله: طبق مستندات گوگل، اتصال دامنه به Cloud Run یک فرایند یک‌کلیکی نیست. شما باید وارد یک چرخه جدید از تایید مالکیت دامنه، تنظیمات پیچیده DNS در پنل‌های خارجی و پیکربندی Load Balancer برای صدور گواهی SSL شود.
پس از عبور از این موانع زیرساختی، تازه باید به تگ منیجر اعلام کنید که ترافیک را به این سرور جدید هدایت کند:
وارد پنل GTM شوید و کانتینر سرورساید خود را باز کنید.
از تب Admin به بخش Container Settings بروید.
روی گزینه Add URL کلیک کرده و آدرس سرور اختصاصی خود را وارد و ذخیره کنید.
۷. اعتبارسنجی (Validation) و مانیتورینگ سلامت سرور
اکنون که سرور تگ‌گذاری پیکربندی شده است، باید از عملکرد صحیح آن و جریان سالم داده‌ها مطمئن شوید. شما می‌توانید این اعتبارسنجی را از دو مسیر مجزا انجام دهید:
الف) بررسی رابط کاربری (UI Verification): در Workspace تگ منیجر روی دکمه Preview کلیک کنید. اگر صفحه پیش‌نمایش بدون خطا لود شود، نشان‌دهنده این است که اتصال کانتینر با سرور شما به درستی برقرار است.
ب) بررسی سلامت از طریق API (Health Check): می‌توانید وضعیت پاسخگویی سرور را به صورت مستقیم تست کنید. آدرس سرور خود را کپی کرده و پسوند /healthy را به انتهای مسیر اضافه کنید (مثلا https://www.example.com/metrics/healthy). این آدرس را در یک تب جدید مرورگر باز کنید. اگر زیرساخت شما بدون مشکل کار کند، کلمه ok را به تنهایی در صفحه مشاهده خواهید کرد.
۸. به‌روزرسانی نسخه سرور (تله نگهداری مداوم)
گوگل مدام نسخه‌های جدیدی برای رفع آسیب‌پذیری‌های امنیتی (Security vulnerability fixes) و افزودن قابلیت‌های جدید منتشر می‌کند. اما به‌روزرسانی سرورها در Cloud Run به هیچ وجه خودکار نیست. برای اعمال این پچ‌های امنیتی، تیم فنی شما باید به صورت دستی وارد یک چرخه نگهداری (Maintenance) شود:
۱. ورود به محیط Cloud Run و انتخاب سرویس مورد نظر.
۲. کلیک روی گزینه Edit & Deploy New Revision.
۳. اطمینان از اینکه آدرس ایمیج دقیقا روی gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable تنظیم شده است و کلیک روی دکمه Deploy.
۴. بازگشت به پنل GTM، کلیک روی دکمه Preview و بررسی تب Console برای اطمینان از اینکه پیام هشدار آپدیت حذف شده و دیپلوی موفقیت‌آمیز بوده است.
روش دوم: استقرار روی گوگل کلود (App Engine)
دومین راهکار گوگل برای استقرار سرور تگ‌گذاری، استفاده از محیط App Engine است. نکته قابل توجه این است که گوگل در مستندات رسمی‌اش صراحتا توصیه می‌کند که از این روش استفاده نکرده و به جای آن محیط Cloud Run (روش اول) را انتخاب کنید. دلیل این توصیه، هزینه‌های بالاتر و خطاهای زیرساختی مکرر در اپ انجین است که در ادامه به آن‌ها می‌پردازیم. مراحل کلی این روش شامل همان پیش‌نیازهای ساخت حساب GCP و مدیریت لاگ‌ها است، اما فرایند استقرار و هزینه‌ها تفاوت‌های معناداری دارند:
۱. استقرار از طریق خط فرمان (Shell Script)
برخلاف کلود ران که تا حدودی با رابط کاربری (UI) قابل مدیریت بود، در اپ انجین تمام فرایند باید از طریق اجرای یک اسکریپت ناشناس در Cloud Shell انجام شود. پس از تنظیم Project ID، باید دستور زیر را اجرا کنید تا کانتینر ساخته شود:
۲. شروع هزینه از ۱۲۰ دلار در ماه
هزینه محیط پروداکشن در اپ انجین به شدت غیرمنطقی است. هر سرور (شامل ۱ vCPU و ۰.۵ گیگابایت رم) ماهانه ۴۰ دلار هزینه دارد. مستندات گوگل صراحتا تاکید می‌کند که برای جلوگیری از قطع شدن سرور و از دست رفتن دیتا، باید حداقل ۳ سرور فعال داشته باشید. این یعنی هزینه پایه و ثابت شما در این روش ۱۲۰ دلار در ماه خواهد بود.
۳. مراحل مشترک با Cloud Run (لاگ‌ها، دامنه و اعتبارسنجی)
از آنجا که معماری پایه هر دو روش یکسان است، چالش‌های زیرساختی زیر دقیقا مشابه روش اول است و برای انجام آن‌ها باید همان مسیرهای قبلی را طی کنید:
شما همچنان باید برای جلوگیری از هزینه‌های اضافی، لاگ‌های درخواست و کنسول را به صورت دستی غیرفعال کنید.
برای اتصال دامنه اختصاصی (Custom Domain) و ثبت URLها باید با تنظیمات DNS و لودبالانسر درگیر شوید.
فرایند اعتبارسنجی (Validation) و بررسی سلامت سرور از طریق آدرس /healthy کاملا یکسان است.
۴. خطاهای قطعی و تایم‌اوت در استقرار (Timeouts)
یکی از بزرگترین باگ‌های اپ انجین که گوگل نیز به آن اعتراف کرده، خطای تایم‌اوت در زمان استقرار یا به‌روزرسانی سرور است. این خطا معمولا به دو دلیل رخ می‌دهد که رفع آن‌ها نیازمند دانش عمیق DevOps است:
خطای دسترسی (IAM Permissions): اگر در سیاست‌های سازمانی اکانت گوگل شما، نقش Editor از حساب‌های کاربری سیستم (Compute Engine و App Engine) حذف شده باشد، کل فرایند استقرار قفل می‌شود.
محدودیت منابع (Insufficient quota): اگر در ریجن انتخابی شما، ظرفیت CPUهای تخصیص‌یافته به اکانتتان پر شده باشد، دیپلوی با شکست مواجه می‌شود و باید به صورت دستی در بخش Quotas، درخواست افزایش منابع ثبت کنید.
۵. به‌روزرسانی دستی و تکراری
برای هر بار آپدیت امنیتی (که گوگل مدام هشدار آن را در GTM نمایش می‌دهد)، تیم شما موظف است مجددا وارد Cloud Shell شده و همان اسکریپت نصب (setup.sh) را دوباره اجرا کند تا تغییرات اعمال شود.
ارزیابی استراتژیک: وقتی خود گوگل روش App Engine را اولویت دوم می‌داند و هزینه نگهداری آن ۳۰ درصد بیشتر از کلود ران (حداقل ۱۲۰ دلار در ماه) است، عملا هیچ توجیه منطقی برای انتخاب این مسیر وجود ندارد. درگیری با خطاهای تایم‌اوت، دسترسی‌های IAM و اجرای اسکریپت‌های ترمینال، تنها باعث هدررفت بیشتر منابع تیم فنی شما خواهد شد.
روش سوم: استقرار دستی با داکر
علاوه بر محیط‌های مدیریت‌شده گوگل، امکان استقرار سرور GTM به صورت کاملا دستی و از طریق Docker نیز وجود دارد. در این حالت، شما کنترل کاملی روی زیرساخت دارید، اما به دلیل ماهیت خام داکر، با فرایند استقرار و چرخه نگهداری پیچیده‌تری روبرو خواهید شد. سرور GTM یک سرور Node.js است که داخل یک ایمیج داکر (Docker Image) اجرا می‌شود. استقرار دستی به دو جزء اساسی نیاز دارد:
کلاستر سمت سرور (SST Cluster): نقطه ورود اصلی تمامی درخواست‌ها و مدیریت ریکوئست‌ها.
سرور پیش‌نمایش (Preview Server): صرفا برای مشاهده پیش‌نمایش کانتینر.
پیش‌نیاز: ابزار خط فرمان Docker باید روی سیستم شما نصب باشد.
مشاهده تنظیمات ایمیج داکر
هر دو سرور SST و پیش‌نمایش از یک ایمیج داکر یکسان اما با فلگ‌های (Flags) متفاوت استفاده می‌کنند. این ایمیج در آدرس زیر قرار دارد:
برای مشاهده تمامی تنظیمات در دسترس، دستور زیر را اجرا کنید:
افزودن کلیدهای دسترسی Google Cloud
برای استفاده از APIهای BigQuery یا Firestore خارج از محیط گوگل کلود، به Service Account Credential نیاز دارید.
۱. حساب خدماتی با نقش BigQuery Data Editor (برای بیگ‌کوئری) یا Cloud Datastore User (برای فایراستور) ایجاد کنید.
۲. کلید JSON را با نام local_service_account_key.json دانلود کنید.
۳. این فایل را در والیوم داکر مونت (Mount) کنید و متغیر محیطی GOOGLE_APPLICATION_CREDENTIALS را به مسیر آن اختصاص دهید.
۴. شناسه پروژه را در متغیر GOOGLE_CLOUD_PROJECT تنظیم کنید. (اختیاری)
نمونه دستور اجرا با کلیدها:
۱. استقرار دستی سرور پیش‌نمایش (Preview Server)
برای اجرای سرور پیش‌نمایش جهت مشاهده کانتینر سرور، متغیرهای محیطی زیر الزامی است:
CONTAINER_CONFIG: رشته پیکربندی کانتینر. (مسیر در تگ منیجر: تب کانتینر سرور > Container ID > کلیک روی Manually provision tagging server).
RUN_AS_PREVIEW_SERVER: باید روی true تنظیم شود.
دستور استقرار محلی:
تست سلامت: ارسال درخواست به http://localhost:8080/healthy باید کد پاسخ ۲۰۰ برگرداند. برای تغییر پورت از متغیر PORT استفاده کنید.
الزامات زیرساخت:
دقیقا یک سرور پیش‌نمایش دیپلوی کنید. به هیچ وجه مقیاس‌پذیری خودکار (Autoscaling) برای آن تنظیم نکنید.
پس از راه‌اندازی، یک آدرس HTTPS به آن اختصاص دهید (برای راه‌اندازی کلاستر در مرحله بعد الزامی است).
تایم‌اوت لودبالانسر یا CDN حتما باید بیشتر از ۲۰ ثانیه باشد، در غیر این صورت حالت پیش‌نمایش از کار می‌افتد.
۲. استقرار دستی کلاستر سمت سرور (SST Cluster)
این کلاستر ترافیک اصلی را مدیریت کرده و به عنوان واسطه، درخواست‌های پیش‌نمایش را به سرور مجزا هدایت می‌کند.
متغیرهای الزامی:
CONTAINER_CONFIG: رشته پیکربندی کانتینر.
PREVIEW_SERVER_URL: آدرس HTTPS سرور پیش‌نمایش که در مرحله قبل تنظیم کردید.
دستور استقرار محلی:
تست سلامت: مشابه سرور پیش‌نمایش، درخواست به مسیر /healthy روی پورت تعیین‌شده باید پاسخ ۲۰۰ برگرداند.
محدودیت‌های سخت‌افزاری و عملیاتی در روش استقرار دستی (داکر)
الزام به پیاده‌سازی کلاستر: راه‌اندازی یک سرور واحد، ریسک از دست رفتن داده‌ها را به شدت بالا می‌برد. شما مجبورید سرورها را به صورت کلاستر دیپلوی کنید، که این یعنی تمام نمونه‌ها باید به صورت دستی با پیکربندی‌های کاملا یکسان (CONTAINER_CONFIG و PREVIEW_SERVER_URL) همگام‌سازی شوند.
هم‌دامنه‌بودن اجباری (Same Origin): برای جلوگیری از مسدود شدن تگ‌ها توسط مرورگرها، سرور GTM حتما باید روی همان دامنه سایت اصلی یا یک ساب‌دامین اختصاصی (مانند example.com/analytics) میزبانی شود.
پیچیدگی در جداسازی مسیرها: ا گر سرور پیش‌نمایش و کلاستر اصلی را روی یک دامنه بالا می‌آورید، مجبورید مسیرهای (Path) کاملا متفاوتی برای آن‌ها تعریف و مدیریت کنید تا ترافیک دیباگ و ترافیک واقعی با هم تداخل پیدا نکنند.
محدودیت در تخصیص منابع پردازشی: برخلاف منطق رایج در سرورها، هر سرور در این کلاستر حداکثر مجاز به استفاده از ۱ هسته پردازشی (vCPU) است. تخصیص هسته اضافی نه‌تنها کاملا بی‌استفاده می‌ماند، بلکه عملکرد مقیاس‌پذیری خودکار (Autoscaling) را به طور کامل مختل می‌کند.
نیاز به مانیتورینگ و ری‌استارت‌های دوره‌ای: کانتینر داکر به صورت خودکار آپدیت نمی‌شود. تیم فنی شما موظف است با استفاده از دستور داخلی HEALTHCHECK یک فرایند مانیتورینگ بسازد و سرورها را به صورت دوره‌ای ری‌استارت کند تا کدهای منبع دچار ناسازگاری نشوند.
۳. اعتبارسنجی تنظیمات
اتصال آدرس: در پنل تگ منیجر به مسیر Admin > Container Settings بروید، آدرس سرور GTM را در فیلد Server container URL وارد کرده و ذخیره کنید.
تست عملکرد: دکمه Preview را در تگ منیجر بزنید. سپس در یک تب جدید مرورگر، یکی از مسیرهای آدرس کانتینر سرور را باز کنید. اگر صفحه پیش‌نمایش ریکوئست شما را لاگ کرد، فرایند استقرار به درستی انجام شده است.
پیکربندی چند دامنه‌ای: اگر سرور را به چندین ساب‌دامین متصل کرده‌اید، آدرس‌های اضافی را در Container Settings وارد کنید. دقت کنید که ساختار مسیر (رشته بعد از دامنه) باید در تمام آن‌ها کاملا یکسان باشد. در این حالت هنگام زدن دکمه Preview، منویی برای انتخاب دامنه هدف جهت دیباگ نمایش داده می‌شود.
۴. به‌روزرسانی نسخه سرور GTM
ایمیج داکر برای رفع باگ‌های امنیتی و افزودن ویژگی‌های جدید، به صورت دوره‌ای آپدیت می‌شود. اکیدا پیشنهاد می‌شود حداقل برای انتشار نسخه‌های اصلی (مثلا ارتقا از ۱٫x به ۲٫x) فرایند آپدیت را انجام دهید:
۱. ایمیج به‌روز را از gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable دریافت کنید.
۲. سرورها را با تنظیمات استقرار قبلی مجددا دیپلوی کنید.
۳. سرور پیش‌نمایش و سپس تمامی سرورهای داخل کلاستر را آپدیت کنید.
۴. سرورهای قدیمی را کاملا خاموش (Shut down) کنید.
تایید موفقیت آپدیت: در کانتینر سرور روی دکمه Preview کلیک کنید و در یک تب مجزا درخواستی بفرستید. در بخش Summary به تب Console بروید؛ نباید هیچ پیامی مبنی بر درخواست آپدیت سرور وجود داشته باشد.
روش چهارم: راه‌اندازی سریع سرور GTM در PaaS پارس‌پک
در سه روش بررسی‌شده، با محدودیت‌های عملیاتی و مالی زیرساخت‌های خارجی آشنا شدیم: از هزینه‌های پایه ۹۰ و ۱۲۰ دلاری و قفل شدن موقعیت مکانی (Region Lock) در محیط‌های گوگل، تا سربار سنگین وظایف دواپس، محدودیت تخصیص منابع و همگام‌سازی دستی کلاسترها در معماری داکر.
استقرار کانتینر روی PaaS پارس‌پک، یک راهکار مدیریت‌شده برای عبور از این موانع است. در این ساختار، پیچیدگی‌های استقرار دستی (مانند اجرای کدهای ترمینال و مانیتورینگ سلامت) و چالش‌های زیرساختی پرداخت ارزی به طور کامل حذف می‌شوند. پلتفرم ابری پارس‌پک فرایندهای کلاسترینگ، مقیاس‌پذیری و دریافت آپدیت‌های امنیتی را به صورت خودکار مدیریت می‌کند تا تیم شما بتواند به جای نگهداری از زیرساخت، مستقیما روی پردازش داده‌ها متمرکز شود.
مرحله ۱: ساخت کانتینر و استقرار اولیه در پارس‌پک
برای راه‌اندازی این سرور، ابتدا باید هسته کانتینر را در گوگل تگ منیجر تعریف کرده و سپس آن را PaaS پارس‌پک مستقر کنید:
۱. در پنل وب Google Tag Manager، یک کانتینر جدید ایجاد کرده و پلتفرم هدف (Target platform) را روی Server تنظیم کنید.
۲. در پنجره نصب، گزینه Manually provision tagging server را انتخاب کرده و رشته متنی تولید شده (Container Config) را کپی کنید.
۳. وارد داشبورد پارس‌پک شوید و در فرایند ساخت اپلیکیشن Google Tag Manager، رشته کپی‌شده را دقیقا در فیلد sst_container_config قرار دهید و بعد از تنظیمات منابع، روی دکمه «ایجاد اپلیکیشن» کلیک کرده و سرویس خود را مستقر کنید.
مرحله ۲: ثبت دامنه پردازشی (sst) در کانتینر سرور
پلتفرم ابری پارس‌پک به محض استقرار اپلیکیشن، دو ساب‌دامین اختصاصی در اختیار شما می‌گذارد. دامنه‌ای که با پیشوند sst آغاز می‌شود، آدرس اصلی دریافت‌کننده ترافیک است.
دقیقا اینجاست که ارزش زیرساخت مدیریت‌شده نمایان می‌شود؛ برخلاف روش کلود ران که شما را مجبور می‌کرد برای دور زدن ادبلاکرها وارد یک چرخه فرسایشی از تایید مالکیت دامنه، تنظیمات پیچیده DNS در پنل‌های خارجی و کانفیگ دستی لود بالانسر شوید، پارس‌پک این دامنه ایزوله و آماده را به صورت خودکار تنظیم کرده و در اختیار شما می‌گذارد.
۱. در داشبورد پارس‌پک، از بخش دامنه‌های اپلیکیشن، آدرس شروع‌شونده با sst را کپی کنید.
۲. به پنل GTM برگردید و کانتینر Server را باز کنید. از منوی بالا روی Admin کلیک کرده و وارد Container Settings شوید.
۳. روی دکمه Add URL کلیک کنید و آدرس sst را با پیشوند https:// (بدون اسلش در انتها) وارد کرده و تنظیمات را ذخیره کنید.
پیکربندی نهایی در پنل GTM (مشترک برای تمامی روش‌ها)
اکنون که سرور شما در یکی از زیرساخت‌های بالا (کلود ران، اپ انجین، داکر یا پارس‌پک) مستقر شده و آدرس آن تایید شده است، باید جریان داده‌ها را در پنل تگ منیجر تنظیم کنید.
گام اول: پیکربندی کلاینت Web Container در سرور (جلوگیری از مسدود شدن تگ‌ها)
برای اینکه فایل‌های اصلی GTM مستقیما از روی سرور اختصاصی خودتان بارگذاری شوند و از سد مسدودکننده‌های تبلیغاتی (Ad-Blockers) عبور کنند، باید کلاینت وب کانتینر را تنظیم کنید.
۱. در کانتینر Server، از منوی سمت چپ روی Clients کلیک کنید.
۲. کلاینت Web Container را در Google Tag Manager باز کنید.
۳. در بخش Allowed Container IDs روی دکمه Add Container ID کلیک کنید و شناسه کانتینر کلاینت‌ساید خود (آیدی شروع‌شونده با GTM- که روی سایت نصب است) را وارد کنید.
۴. در پایین صفحه، حتما تیک گزینه Enable region-specific settings را بردارید و تغییرات را ذخیره کنید.
گام دوم: هدایت ترافیک کانتینر Web به سرور ابری
اکنون باید به مرورگر کاربران دستور دهیم که داده‌های رهگیری را به جای سرورهای گوگل، به سرور اختصاصی شما (مانند کلاستر ابری پارس‌پک یا زیرساخت انتخابی دیگر) ارسال کنند. این کار از طریق کانتینر کلاینت‌ساید انجام می‌شود.
حالت A: اگر از قبل تگ پایه دارید
اگر روی وب‌سایت خود کانتینر Web فعال دارید، نیازی به ساخت تگ جدید نیست. تگ پایه (Google Tag) سایت خود را باز کرده و مستقیما به مرحله ۴ بروید.
حالت B: ایجاد تگ پایه جدید
۱. وارد فضای کاری کانتینر Web شوید. از منوی سمت چپ به بخش Tags رفته و روی New کلیک کنید.
۲. روی کادر Tag Configuration کلیک کرده و از منوی بازشده ابزار Google Tag را انتخاب کنید.
۳. در فیلد Tag ID، شناسه Measurement ID اکانت گوگل آنالیتیکس خود را وارد کنید.
تنظیم پارامتر هدایت ترافیک (مشترک برای هر دو حالت)
۴. بخش Configuration settings را باز کرده و روی دکمه Add parameter کلیک کنید.
۵. در ستون سمت چپ، پارامتر server_container_url را از لیست انتخاب کنید.
۶. در ستون Value، دقیقا آدرس سرور اختصاصی خود را وارد کنید (برای مثال، همان دامنه sst پارس‌پک که در مراحل قبل متصل کردید، یا آدرس خروجی سرور گوگل کلود).
۷. روی کادر Triggering کلیک کنید و تریگر Initialization – All Pages را برای این والپیپر اچ دی تگ انتخاب کرده و تگ را ذخیره کنید.
با این تنظیمات ساده، تمام داده‌های جمع‌آوری‌شده توسط این کانتینر مستقیما به سرور ابری شما سرازیر می‌شود.
گام سوم: پیکربندی تگ و تریگر GA4 در کانتینر سرور
اکنون داده‌ها به سرور می‌رسند. برای پردازش نهایی و ارسال دیتا به گوگل آنالیتیکس، به یک تگ و یک تریگر شرطی نیاز است.
حالت A: دارای تگ سمت سرور از پیش‌ساخته شده
اگر پیش‌تر تگ GA4 را در کانتینر سرور خود ساخته‌اید، آن را باز کنید و برای تنظیم شرایط اجرا مستقیما به مرحله ۳ بروید.
حالت B: ایجاد تگ جدید
۱. وارد کانتینر Server شوید و از منوی Tags روی New کلیک کنید. روی کادر Tag Configuration کلیک کرده و Google Analytics: GA4 را انتخاب کنید.
۲. در فیلد Measurement ID، شناسه آنالیتیکس خود را وارد کنید.
تعریف تریگر پردازشی (مشترک در هر دو حالت)
۳. برای تعیین شرط اجرا، روی کادر Triggering کلیک کنید.
۴. با کلیک روی آیکون + در بالا سمت راست، یک تریگر جدید ایجاد کنید.
۵. روی Trigger Configuration کلیک کرده و نوع تریگر را Custom انتخاب کنید.
۶. در بخش شرایط اجرا، تیک گزینه Some Events را بزنید.
۷. روی لیست کشویی متغیرها کلیک کرده و گزینه Choose Built-In Variable را انتخاب کنید. از پنل بازشده، متغیر Client Name را به فضای کاری اضافه کنید.
۸. شرط را به این شکل کامل کنید: متغیر را روی Client Name قرار دهید، عملگر را equals انتخاب کنید و در کادر مقدار، دقیقا عبارت GA4 را تایپ کنید.
۹. تریگر و سپس تگ سرورساید خود را ذخیره کنید.
فرایند استقرار و اتصال به پایان رسید. با استفاده از گزینه Preview در هر دو کانتینر، می‌توانید جریان ورود ترافیک به سرور ابری را دیباگ و بررسی کنید.
جمع‌بندی
پیاده‌سازی Server-Side Tagging تنها راهکار قطعی برای عبور از سد مسدودکننده‌های تبلیغاتی و حفظ دقیق داده‌های مارکتینگ است. در این مقاله پس از بررسی چالش‌های فنی و هزینه‌های سنگین دلاری در استقرار روی گوگل کلود و داکر، مسیر جایگزین و بدون دردسر آن را یاد گرفتیم. برای رهایی از دغدغه‌های زیرساختی و تمرکز کامل روی تحلیل داده‌ها، می‌توانید سرور GTM خود را روی پلتفرم ابری (PaaS) پارس‌پک راه‌اندازی کنید تا تمام فرایندهای مدیریت سرور به صورت خودکار انجام شود.
