نگــــــــار پـــورجــــــــــواد
متخصص تبلیغات کلیکی، ایکامرس ترکینگ و …
Analytics 4
آموزش بیگ کوئری
با توجه به اینکه هزینه Google BigQuery کاملا بر اساس میزان مصرف شما محاسبه میشود، در هنگام برآورد هزینهها، عمدتا فقط سه جنبه اصلی در مورد ذخیره سازی دادههای BigQuery خود باید در نظر بگیرید: ذخیره سازی داده (Storage Data)، ذخیره سازی بلندمدت داده (Long Term Storage Data) و پردازش کوئری (Query Data Usage). صفحه رسمی هزینه بیگ کوئری شامل جزئیات و اطلاعات مفید بسیار بیشتری است که حتما باید آن را بررسی کنید، در این راهنما به طور خلاصه هر یک از این سه عنصر قیمت گذاری را برای برآورد هزینه های ماهانه خود بررسی خواهیم کرد.
برای خرید دوره 9 ساعته آموزش بیگ کوئری، روی لینک کلیک کنید و فرم موجود را تکمیل کنید. در سریع ترین زمان ممکن به شما تماس میگیرم 🙂
تاثیر هزینه ذخیره سازی بر قیمت استفاده از BigQuery
هزینههای ذخیره سازی معمولا به صورت ماهانه برای دادههایی که در جداول یا پارتیشنهای BigQuery ذخیره شدهاند و فعال هستند، محاسبه میشود. منظور از دادههای فعال، دادههایی است که در 90 روز گذشته تغییر کردهاند. اگر در 90 روز گذشته هیچ تغییری در جداول یا پارتیشنهای BigQuery خود ایجاد نکردهاید، میتوانید با کاهش 50 درصدی هزینه ها، همچنان داده های خود را در انبار داده بیگ کوئری داشته باشید.
هنگام استفاده از API های ذخیره سازی BigQuery، بسته به حجم دادههای ورودی ممکن است نیاز به پرداخت هزینه باشد. در این صورت هزینه هر 200 مگابایت داده ورودی که با موفقیت در بیگ کوئری ذخیره می شود، 0.01 دلار است.
تاثیر هزینه کوئری بر قیمت هزینه استفاده از بیگ کوئری
در حالت قیمت گذاری بر اساس میزان مصرف (On-Demand Pricing)، هزینه بر اساس حجم داده پردازش شده کوئریهایتان محاسبه میشود. برای کوئریهای ناموفق یا کوئریهایی که از حافظه کش بارگذاری شدهاند، هزینه پرداخت نمیکنید. علاوه بر این، اولین 1 ترابایت داده کوئری پردازش شده در هر ماه رایگان است. همچنین، قیمتها بر اساس منطقه جغرافیایی که هنگام ساخت پروژه در بیگ کوئری تعیین کرده اید، متفاوت است.
به عنوان مثال، انتخاب بمبئی (asia-south1) به عنوان مکان ذخیره سازی 0.023 دلار به ازای هر گیگابایت هزینه از شما دریافت میکند، در حالی که با انتخاب ایالات متحده (چند منطقه ای) (ایالات متحده) یا اتحادیه اروپا (چند منطقه) (اروپا) 0.02 دلار به ازای هر گیگابایت باید هزینه پرداخت کنید.
در حالت قیمت گذاری با نرخ ثابت (Flat-Rate Pricing)، بدون توجه به حجم داده پردازش شده توسط کوئریهایتان، هزینه ثابتی را پرداخت میکنید. این گزینه قیمتی برای مشتریانی ایدهآل است که به هزینه ماهانه قابل پیش بینی با بودجه مشخص نیاز دارند. برای بهره مندی از قیمت گذاری با نرخ ثابت، باید اسلاتهای BigQuery را خریداری کنید که در ادامه به بررسی آن خواهیم پرداخت.
هزینه ذخیره سازی داده در بیگ کوئری چقدر است؟
هزینه ذخیره سازی به فضایی که برای نگهداری اطلاعات خود در BigQuery نیاز دارید اشاره دارد. شما برای هر دو نوع ذخیره سازی فعال و بلندمدت هزینه پرداخت می کنید.
ذخیره سازی فعال: هر جدول یا پارتیشنی از یک جدول که در 90 روز گذشته به روز شده باشد، ذخیره سازی فعال در نظر گرفته می شود. در حال حاضر، BigQuery برای ذخیره سازی فعال، هزینه ماهانه ثابتی معادل 0.02 دلار به ازای هر گیبی بایت در ماه دریافت می کند. هزینه ذخیره سازی فیزیکی فعال نیز 0.04 دلار به ازای هر گیگابایت در ماه است. 10 گیبی بایت اولیه هر ماه رایگان است. بنابراین، اگر یک جدول 200 گیبی بایتی را برای یک ماه نگه داریم، هزینه آن (200 * 0.02) = 4 دلار خواهد بود.
توجه: با احتساب 10 گیگابایت رایگان هر ماه، کاربر با 4 دلار مجموعا 210 گیگابایت دریافت خواهد کرد.
برای مثال، ذخیره سازی بلندمدت یک جدول 200 گیبی بایتی برای یک ماه (200 * 0.01) = 2 دلار هزینه خواهد داشت. اگر جدول به روز شود، به ذخیره سازی فعال تبدیل می شود و دوره 90 روزه مجددا از ابتدا شروع می شود.
ذخیره سازی بلندمدت: هر جدول یا پارتیشنی از یک جدول که در 90 روز گذشته به روز نشده باشد، ذخیره سازی بلندمدت در نظر گرفته می شود. پس از 90 روز، قیمت داده های ذخیره سازی 50 درصد کاهش می یابد. هزینه ذخیره سازی منطقی بلندمدت 0.01 دلار به ازای هر گیگابایت در ماه است. هزینه ذخیره سازی فیزیکی بلندمدت، بیشتر بوده و 0.02 دلار به ازای هر گیگابایت در ماه است. 10 گیگابایت اولیه هر ماه رایگان است.برای مثال، ذخیره سازی بلندمدت یک جدول 200 گیبی بایتی برای یک ماه (200 * 0.01) = 2 دلار هزینه خواهد داشت. اگر جدول به روز شود، به ذخیره سازی فعال تبدیل می شود و دوره 90 روزه مجددا از ابتدا شروع می شود.
برای مثال، ذخیره سازی بلندمدت یک جدول 200 گیبی بایتی برای یک ماه (200 * 0.01) = 2 دلار هزینه خواهد داشت. اگر جدول به روز شود، به ذخیره سازی فعال تبدیل می شود و دوره 90 روزه مجددا از ابتدا شروع می شود.
1 گیبی بایت (gibibyte) معادل 1.1 گیگابایت (gigabyte)
عملکرد، پایداری داده و دسترسی در هر دو نوع ذخیره سازی فعال و بلندمدت یکسان است.
هزینه BigQuery به ازای هر ۱ ترابایت
حجم دادههای ذخیره شده و دادههای پردازش شده توسط کوئریهای شما بر حسب گیبیبایت (GiB) اندازهگیری میشود. اگر هزینه هر گیگابایت فضای ذخیرهسازی ۰.۰۲ دلار باشد و ۱ ترابایت تقریباً معادل ۱,۰۰۰ گیگابایت (۹۳۱.۳۲۳) باشد، در این صورت هزینه ۱ ترابایت ۲۰ دلار خواهد بود.
برای محاسبه هزینه ۵ ترابایت، به سادگی مقدار داده را در ۱۰۰۰ (برای تبدیل به گیبیبایت) ضرب میکنیم، سپس حاصل را در ۰.۰۲ دلار به ازای هر گیگابایت ضرب میکنیم.
۵ ترابایت * ۱۰۰۰ = ۵,۰۰۰ گیبیبایت
۵,۰۰۰ گیبیبایت * ۰.۰۲ دلار = ۱۰۰ دلار
حجم ذخیره سازی أنواع داده در بیگ کوئری
همانطور که گفته شد، هزینه بر اساس میزان داده ای که در BigQuery قرار می دهید محاسبه می شود. برای تعیین حجم کل داده های خود، باید بدانید که حجم أنواع داده ای که در بیگ کوئری ذخیره می شود، داده چقدر است..در ادامه حجم انواع داده های موجود در BigQuery آورده شده است:
نوع داده | اندازه |
INT64 | 8 بایت |
FLOAT | 8 بایت |
NUMERIC | 16 بایت |
Bool | 1 بایت |
STRING | 2 بایت |
Date | 8 بایت |
Datetime | 8 بایت |
Time | 8 بایت |
Timestamp | 8 بایت |
Interval | 16 بایت |
جدول هزینه ذخیره داده به ازای هر 1 گیگابایت در بیگ کوئری
نوع ذخیره سازی | قیمت | سطح رایگان |
ذخیره سازی منطقی فعال | 0.02 دلار به ازای هر گیگابایت | 10 گیگابایت اول هر ماه رایگان است |
ذخیره سازی فیزیکی فعال | 0.04 دلار به ازای هر گیگابایت | 10 گیگابایت اول هر ماه رایگان است |
ذخیره سازی منطقی بلندمدت | 0.01 دلار به ازای هر گیگابایت | 10 گیگابایت اول هر ماه رایگان است |
ذخیره سازی فیزیکی بلندمدت | 0.02 دلار به ازای هر گیگابایت | 10 گیگابایت اول هر ماه رایگان است |
تحلیل ساختار قیمت گذاری کوئری در Google BigQuery
در BigQuery، از قیمت گذاری تحلیلی برای محاسبه هزینه اجرای کوئریها (شامل کوئریهای SQL، توابع تعریفشده توسط کاربر و اسکریپتها) و همچنین قیمت گذاری ذخیرهسازی برای محاسبه هزینه ذخیره دادههایی که در BigQuery بارگذاری میکنید، استفاده میشود.
BigQuery دو مدل قیمتگذاری مجزا برای انتخاب کاربران هنگام اجرای کوئری ارائه میدهد. این مدل های قیمتی به شرح زیر هستند:
قیمت گذاری بر اساس تقاضا (On-demand pricing)
در قیمتگذاری بر اساس تقاضا، شما بر اساس اندازه هر کوئری و تعداد بایتهایی که توسط هر کوئری مدیریت میشود، هزینه پرداخت میکنید. در صورت عدم اجرای کوئری، هیچ هزینهای از شما دریافت نمیشود. برای تمام کاربران، اولین ترابایت داده کوئری پردازش شده در هر ماه رایگان ارایه میشود.
قیمت گذاری با نرخ ثابت (Flat-rate pricing)
با رویکرد قیمتگذاری با نرخ ثابت، صرف نظر از حجم دادههایی که کوئریهای شما اشغال میکنند، هزینه ثابتی را پرداخت میکنید. این بهترین انتخاب قیمت گذاری برای کاربرانی است که یک هزینه ماهانه ثابت را در محدودیت هزینه تعیین شده میخواهند. دسترسی کاربران به قیمت گذاری با نرخ ثابت با خرید اسلاتهای BigQuery، که اساسا CPUهای مجازی مورد استفاده BigQuery برای اجرای کوئریهای SQL هستند، امکان پذیر است. ظرفیت اسلات اختصاصی که خریداری میکنید، میزان قدرت پردازش اختصاصیافته برای تمام کوئریهای شما در هر زمان خاص را تعیین میکند، نه برای هر کوئری به صورت جداگانه. اگر درخواستهای شما از ظرفیت اختصاصی شما فراتر رود، BigQuery واحدهای کاری را به صف انتظار میفرستد و منتظر میشود تا اسلاتها در دسترس قرار گیرند.با پیشرفت پردازش کوئری و در دسترس قرار گرفتن اسلاتها، واحدهای کاری صف انتظار به صورت پویا برای اجرا انتخاب میشوند و هیچ هزینه اضافی دریافت نمیشود.
اسلاتها در هر دو قیمت گذاری بر اساس تقاضا و با نرخ ثابت استفاده میشوند، اما رویکرد با نرخ ثابت کنترل خاصی بر اسلاتها و ظرفیت تجزیه و تحلیل به شما ارائه میدهد. به عنوان مثال، در قیمت گذاری با نرخ ثابت، میتوانید انتخاب کنید که اسلاتها را برای موارد زیر رزرو کنید:
- ۶۰ ثانیه: اسلاتهای انعطافپذیر
- ماهانه: ۳۰ روز
- سالانه: ۳۶۵ روز
شما همیشه میتوانید این دو مدل را برای برآورده کردن نیازهای خاص خود ترکیب کنید. با قیمت گذاری بر اساس تقاضا، هزینه آنچه مصرف میکنید را پرداخت میکنید، در حالی که با قیمت گذاری با نرخ ثابت، در ازای یک برنامه بلندمدت، ظرفیت تضمین شدهای را با هزینه کمتری دریافت میکنید.
چه عواملی بر هزینه ذخیره داده در بیگ کوئری تاثیر میگذارند؟
هنگام استفاده از BigQuery با GA4، سه نوع هزینه اصلی وجود دارد که ممکن است متحمل شوید: ذخیره سازی، محاسبات و دریافت داده. این ابزار محاسبه بر ارائه تخمین هزینه ذخیره سازی به شما تمرکز دارد، که جزء کلیدی هزینه کلی BigQuery شما خواهد بود.
هزینه ای که برای ذخیره سازی پرداخت می کنید به میزان داده، مدت زمان ذخیره سازی و مکان ذخیره سازی بستگی دارد. 10 گیگابایت اول ذخیره شده در هر ماه رایگان است، بنابراین بسیاری از سایت های کوچک ممکن است اصلاً هزینه ای پرداخت نکنند.
برای مناطق ایالات متحده (ایالات متحده) و اروپا (اتحادیه اروپا) هر گونه داده ای بالاتر از 10 گیگابایت برای هر گیگابایت در ماه برای ذخیره سازی فعال (هر جدولی که در 90 روز گذشته اصلاح شده است) 0.02 دلار یا برای ذخیره سازی بلندمدت (هر جدولی که برای بیش از 90 روز اصلاح نشده است) 0.01 دلار در ماه محاسبه می شود. ممکن است سایر مناطق قیمت گذاری کمی متفاوتی داشته باشند، به عنوان مثال برای منطقه لندن (اروپا-غرب2) قیمت 0.023 دلار در هر گیگابایت در ماه برای فعال و 0.016 دلار در هر گیگابایت در ماه برای ذخیره سازی بلندمدت است. برای مشاهده قیمت فعلی هر منطقه می توانید به اینجا: BigQuery Pricing مراجعه کنید.
میزان داده ای که در BigQuery ذخیره می کنید به تعداد ایونت هایی که توسط پراپرتی GA4 شما جمع آوری می شود و میزان داده ای که با آن ایونت ها جمع آوری می شود بستگی دارد. اگر با هر ایونت پارامترهای زیادی ارسال میکنید یا ایونت های ایکامرسی را با تعداد زیادی آیتم در هر رویداد جمعآوری میکنید، جداول شما بسیار بزرگتر از سایتی خواهند بود که فقط تنظیمات پیاده سازی آنالیتیکس 4 را انجام داده است.
گوگل تخمین می زند که 1 گیگابایت تقریباً معادل 600 هزار رویداد است، اما در بین پراپرتی های مختلف، این رقم از 800 هزار تا 1.6 میلیون متغیر است.
چگونه با استفاده از ماشین حساب هزینه BigQuery، هزینههای خود را برآورد کنیم؟
قیمتگذاری بر اساس تقاضا (On-demand Pricing)
- به صفحه اصلی کنسول BigQuery خود بروید.
- هنگام وارد کردن یک کوئری، اعتبارسنج کوئری (علامت تیک سبز) آن را تأیید میکند و تخمین میزند که چند بایت پردازش کند.
همانطور که در تصویر مشاهده میکنید، این کوئری برای اجرا تقریباً 10.07 MB فضا برای پردازش نیاز دارد.
- گام بعدی دسترسی به ماشین حساب قیمتگذاری GCP است. BigQuery را به عنوان محصول خود و قیمتگذاری بر اساس تقاضا را به عنوان روش قیمتگذاری خود انتخاب کنید. فرم موجود در صفحه را با تمام اطلاعات لازم، همانطور که در تصویر نشان داده شده است، تکمیل کنید.
اگر هنوز ۱ ترابایت رایگان ماهانه خود را تمام نکرده باشید، هزینه اجرای کوئری صفر است. با این حال، اگر نیاز دارید این کوئری را هر روز برای ماه آینده اجرا کنید؛ قطعا مقدار پردازش رایگان هر ماه را رد خواهید کرد و باید هزینه پرداخت کنید. برای محاسبه این هزینه باید مقدار مورد نیاز برای پردازش کوئری را در 30 ضرب کنید.
چگونه هزینه ذخیره سازی و اجرای کوئری در BigQuery را برآورد کنیم؟
برای محاسبه هزینه ذخیره سازی و اجرای کوئری در BigQuery، ابتدا باید اطلاعات لازم برای تخمین هزینه ها را جمع آوری کنیم:
- تعداد کاربران (Number of Users)
- تعداد کوئری در روز (Number of Queries)
- میانگین حجم دیتای مصرفی (Average Data Usage)
به عنوان مثال، فرض کنید 10 کاربر در روز از دیتایی که از آنالیتیکس به بیگ کوئری انتقال داده شده است، استفاده میکنند. به طوری که هر کاربر روزانه پنج کوئری با میانگین مصرف داده 2 گیگابایت برای هر کوئری اجرا می کند. ما هزینه را بر اساس ماه (فرض می کنیم 30 روز) محاسبه می کنیم.
با استفاده از این پارامترها، می توانیم با یک محاسبه ساده، هزینه ماهانه متوسط خود را با BigQuery تخمین بزنیم.
کل حجم کوئری دیتا در ماه:
10 کاربر در روز * 5 کوئری در روز * 2 گیگابایت در کوئری * 30 روز = 3000 گیگابایت = 3 ترابایت
محاسبه هزینه ذخیره سازی BigQuery:
در زمان نگارش این متن، هزینه ذخیره سازی برای 1 ترابایت داده حدود 20 دلار است (قیمت دقیق بستگی به منطقه انتخابی شما دارد). بنابراین، برای به دست آوردن هزینه ذخیره سازی در هر ماه، به سادگی 3 ترابایت را در 20 دلار ضرب می کنیم.
3 ترابایت * 20 دلار در هر ترابایت = 60 دلار
محاسبه هزینه اجرای کوئری بر اساس میزان مصرف (On-Demand):
با استفاده از همان داده های کوئری، قیمت پردازش 1 ترابایت داده 5 دلار است. بنابراین، برای به دست آوردن هزینه اجرای کوئری بر اساس میزان مصرف در هر ماه، به سادگی 3 ترابایت را در 5 دلار ضرب می کنیم.
3 ترابایت * 5 دلار در هر ترابایت = 15 دلار
این قیمت ممکن است کاهش یابد، به شرطی که از 1 ترابایت فضای ذخیره سازی رایگان ماهانه خود استفاده نکرده باشید.
هزینه پردازش 1 ترابایت داده در BigQuery چقدر است؟
برای قیمت گذاری بر اساس میزان مصرف (On-Demand)، هزینه پردازش 1 ترابایت داده 6.25 دلار است.
هزینه اجرای یک کوئری 12 گیگابایتی در BigQuery چقدر است؟
12 گیگابایت تقریباً معادل 0.01288 ترابایت است. از آنجایی که هزینه پردازش 1 ترابایت 6.25 دلار است، هزینه اجرای یک کوئری 12 گیگابایتی به شرح زیر محاسبه می شود:
6.25 دلار در هر ترابایت * 0.01288 ترابایت = 0.08 دلار
هزینه اجرای یک کوئری 100 گیگابایتی در BigQuery چقدر است؟
100 گیگابایت تقریباً معادل 0.107 ترابایت است. برای محاسبه هزینه اجرای یک کوئری 100 گیگابایتی، محاسبه زیر را انجام می دهیم:
6.25 دلار در هر ترابایت * 0.107 ترابایت = 0.66 دلار
آیا استفاده از ویوها (Views) در BigQuery هزینه اضافی دارد؟
خیر. جداول مجازی (Virtual Tables) با استفاده از کوئری های SQL به عنوان ویو تعریف می شوند. به همان روشی که می توانید روی یک کوئری بزنید، می توانید همین کار را با ویوها نیز انجام دهید. ویوها ممکن است فقط داده هایی را از جداول و فیلدهایی ارائه دهند که توسط کاربر هنگام اجرای کوئری درخواست می شود. بنابراین افزودن یا حذف یک ویو هیچ هزینه ای ندارد.
بهینه سازی هزینه BigQuery
به عنوان یک متخصص پرفورمنس مارکتینگ، بهینه سازی هزینه در BigQuery اهمیت زیادی دارد. فرقی نمی کند که داده های خود را از طریق آنالیتیکس 4 یا از Google Sheets وارد BigQuery کنید، رعایت برخی نکات برای بهینه سازی هزینه در BigQuery ضروری است. این موارد عبارتند از:
- *استفاده بهینه از عبارت SELECT : در کوئری های خود از عبارت
SELECT *
کمتر استفاده کنید و فقط اطلاعات مورد نیاز خود را درخواست نمایید. - استفاده از قابلیت پیش نمایش BigQuery: هنگامی که می خواهید نمونه کوچکی از داده های خود را ببینید، به جای اجرای یک کوئری برای مشاهده بخش کوچکی از داده ها، از قابلیت پیش نمایش BigQuery استفاده کنید.
- بررسی هزینه ها قبل از اجرا: قبل از اجرای هر کوئری یا فعالیت ذخیره سازی، با استفاده از ابزار محاسبه گر قیمت GCP (Google Cloud Platform Price Calculator)، هزینه های مرتبط را بررسی کنید.
- تقسیم کوئری به بخش های کوچکتر: اگر قصد دارید روی یک مجموعه داده بزرگ پرس و جو انجام دهید، کوئری خود را به بخش های کوچکتر تقسیم کنید. اجرای تک تک کوئری های کوچکتر بهتر است. این کار باعث کاهش حجم داده هایی که باید خوانده شوند و در نتیجه صرفه جویی در هزینه می شود.
گوگل ادز یکی از ابزارهای تبلیغاتی محبوب است که توسط بیزینسهای کوچک تا بزرگ برای تبلیغ محصولات و خدمات استفاده می شود. اما گوگل ادز نمی تواند اطلاعات زیادی در مورد کمپین های تبلیغاتی شما ارائه دهد. بنابراین، شما باید داده های خود را از گوگل ادز به بیگ کوئری، یک انبار داده ابری کاملا مدیریت شده و نسبتا کم هزینه، منتقل کنید. با انتقال داده های خود از گوگل ادز به بیگ کوئری، می توانید چندین تحلیل داده انجام دهید تا اطلاعات مفید دوره ای یا زمان واقعی برای بهینه سازی کمپین های خود بدست اورید. در این راهنما، ما به قدم فرآیند انتقال داده های گوگل ادز به بیگ کوئری را با استفاده از چند روش ساده بررسی خواهیم کرد.
مقدمهای بر گوگل ادز
گوگل ادز یکی از پلتفرمهای تبلیغات آنلاین پرکاربرد است که به شما امکان میدهد تا خدمات و محصولات خود را تبلیغ کنید. این پلتفرم گزینههای متنوعی برای هدفگیری مخاطبان دارد تا آگهیهای محصول یا خدمات توسط مخاطبین مرتبط در زمان درست مشاهده شوند. شما میتوانید از گوگل ادز برای نمایش تبلیغات از طریق تصاویر، تماس تلفنی، متن و ویدئو، بسته به کمپین تبلیغاتی و هدف خود استفاده کنید. برای بهبود عملکرد، گوگل ادز از قابلیت تبلیغات ریسپانسیو و از دستگاههای مختلف مانند دسکتاپ، موبایل، تلویزیون و غیره پشتیبانی میکنند.
علاوه بر این، گوگل ادز ابزارهای جامع تحلیلی و گزارشدهی ارائه میدهد که اطلاعات مفیدی در مورد عملکرد کمپینهای تبلیغاتی در اختیارتان قرار میدهد. برای سنجش اثربخشی کمپینهای تبلیغاتی خود، میتوانید معیارهایی مانند دسترسی، نرخ کلیکها (CTR)، نرخ تبدیل و بازگشت سرمایه (ROI) را ردیابی کنید. همچنین این فرصت را در اختیار شما قرار میدهد که با دقت بودجه خود را کنترل کنید و حداکثر بودجه روزانه یا ماهانه را برای مدیریت موثر هزینههای تبلیغاتی خود تعیین کنید.
مقدمهای بر بیگ کوئری
گوگل بیگ کوئری، یک انبار دادههای بدون سرور و پلتفرم تحلیلی است که توسط گوگل کلود ارائه میشود. بیگ کوئری به عنوان یک انبار دادههای آماده، امکان ذخیرهسازی و استخراج گزارش های کاربردی از مجموعه دادههای بزرگ (بیگ دیتا) را برای بیزینس های مختلف در هر مقیاسی فراهم میآورد. برای مدیریت و تحلیل دادهها، بیگ کوئری از زبان SQL پشتیبانی میکند که این امر برای طیف وسیعی از متخصصان، فرآیند کار را بدون درز میکند.
علاوه بر این، به عنوان بخشی از گوگل کلود، بیگ کوئری به راحتی با سایر خدمات گوگل کلود مانند گوگل کلود استوریج، گوگل شیتس و گوگل دیتا استودیو یکپارچه میشود. این یکپارچگی، جذب سریع دادهها، ذخیرهسازی و تجسم آنها را فراهم میکند و یک اکوسیستم تحلیلی جامع را ارائه میدهد.
بیگ کوئری همچنین با پشتیبانی از تحلیل دادههای زمان واقعی از طریق جذب دادههای جاری، به شما کمک میکند تا بینشهای لحظهای را به دست آورید و تصمیمات مبتنی بر داده را به سرعت اتخاذ کنید.
روش های اتصال گوگل ادز به بیگ کوئری
روشهای متنوعی برای ادغام دادههای گوگل ادز با بیگ کوئری گوگل وجود دارد. در ادامه برخی از رایجترین روشهای استفاده شده برای انتقال دادهها از گوگل ادز به بیگ کوئری را به شما عزیزان آموزش میدهیم.
- روش ۱: بارگذاری دستی دادهها از گوگل ادز به بیگ کوئری با استفاده از فایلهای CSV . این روش شامل استخراج دادهها از گوگل ادز به صورت فایل CSV و سپس بارگذاری آنها در بیگ کوئری است. این فرآیند میتواند به صورت دستی انجام شود و یک روش مستقیم برای اتصال گوگل ادز به بیگ کوئری است.
- روش ۲: بارگذاری دادهها از گوگل ادز به بیگ کوئری با استفاده از سرویس انتقال داده بیگ کوئری. سرویس انتقال داده بیگ کوئری گوگل امکان اتوماتیک کردن فرآیند انتقال دادهها را فراهم میآورد. این روش به کاربران اجازه میدهد تا دادهها را به صورت خودکار و بدون دخالت دستی از گوگل ادز به بیگ کوئری منتقل کنند.
بارگذاری دستی دادهها از گوگل ادز به بیگ کوئری با استفاده از فایلهای CSV
اگر به دنبال روشی فوری برای انتقال دادهها از گوگل ادز به بیگ کوئری هستید، استفاده از فایلهای CSV گزینه مناسبی است. تنها کاری که لازم است انجام دهید، خروجی گرفتن از دادههای گوگل ادز به صورت فایلهای CSV و سپس بارگذاری این فایلها در بیگ کوئری است.
مرحله 1: وارد حساب گوگل ادز خود شوید و از گزارش تبلیغات یا کمپینی که میخواهید تحلیل کنید، خروجی بگیرید. میتوانید این گزارش را با تنظیم بخشها، فیلدها، تاریخ و زمانی که میخواهید در فایل CSV خود خروجی بگیرید، سفارشی سازی کنید.
مرحله 2: پس از انتخاب گزارش مورد نظر، روی دکمه دانلود واقع در سمت راست صفحه کلیک کنید. یک پنجره بازشو ظاهر میشود، فرمت فایل را به عنوان CSV برای دانلود فایل انتخاب کنید.
مرحله 3: حالا، فایل CSV شما آماده بارگذاری در انبار دادههای بیگ کوئری است. پیش از بارگذاری دادهها در بیگ کوئری، مطمئن شوید که یک دیتاست بیگ کوئری برای ذخیره دادههای خود دارید. سپس، میتوانید دادههای CSV را در یک جدول بیگ کوئری جدید بارگذاری کنید.
هر چند این روند به طور کلی ساده است، اما با محدودیتهای تاخیر و آسیبپذیری به خطاها همراه است.
بارگذاری گوگل ادز به بیگ کوئری با استفاده از سرویس انتقال دادههای بیگ کوئری
روش دیگر برای انتقال اطلاعات گوگل ادز به بیگ کوئری، استفاده از سرویس انتقال دادههای بیگ کوئری است. این سرویس به طور خودکار زمانبندی، بارگذاری، و مدیریت دادههای مورد نیاز از گوگل ادز به جداول بیگ کوئری شما را به طور منظم انجام میدهد. قبل از انتقال گوگل ادز به بیگ کوئری، اطمینان حاصل کنید که دارای دسترسی های زیر هستید:
- دسترسی ادمین در بیگ کوئری.
- دسترسی حداقل read در حساب گوگل ادز.
- فعال کردن سرویس انتقال دادههای بیگ کوئری.
شما میتوانید اطلاعات گوگل ادز را به بیگ کوئری با استفاده از سرویس انتقال دادهها به چهار روش منتقل کنید:
- کنسول گوگل کلود
- ابزار خط فرمان bq
- API سرویس انتقال دادهها
- زبان برنامهنویسی جاوا
در این روش، ما از کنسول گوگل کلود برای انتقال دادهها از گوگل ادز به بیگ کوئری استفاده خواهیم کرد.
گام 1: وارد پلتفرم گوگل کلود شوید و صفحه بیگ کوئری را باز کنید.
گام 2: روی گزینه انتقال دادهها در سمت چپ پنل کلیک کنید.
گام 3: حالا روی گزینه Creat a Transfer کلیک کنید.
به صفحه ایجاد انتقال هدایت خواهید شد. در بخش نوع سورس، گوگل ادز را جستجو کنید.
گام 4: در بخش Transfer config name، نام منحصر به فردی برای این انتقال داده وارد کنید. سپس، در بخش گزینههای برنامهریزی، میتوانید زمانبندی انتقال خود را با انتخاب فرکانس و زمان شروع انتقال مشخص کنید.
الف) میتوانید فرکانس به روز شدن اطلاعات را تعیین کنید. میتوانید گزینههای روزانه (پیشفرض)، هفتگی، ماهانه، سفارشی، یا درخواستی را از جعبه کشویی تکرار انتخاب کنید.
ب) در گزینه دوم، میتوانید حالت هم اکنون شروع کنید تا یا روی گزینه شروع در زمان تعیین شده برای شروع فرآیند انتقال داده از گوگل ادز به بیگ کوئری کلیک کنید تا انتقال دادههای خود را زمانبندی کنید.
گام 5: در بخش Destination settings، دیتاست مورد نظر برای ذخیره دادههای گوگل ادز خود را ایجاد کنید یا انتخاب کنید.
گام 6: در بخش Data source details، کاستومر آیدی حساب گوگل ادز را وارد کنید.
گام 7: به طور پیشفرض، Refresh window به مدت 7 روز تنظیم شده است تا دادههای 7 روز گذشته را در هر انتقال وارد بیگ کوئری و بهروزرسانی کند. با این حال، میتوانید این مقدار را به 30 روز تغییر دهید.
گام 8: گزینههای اطلاعرسانی ایمیل را فعال کنید تا هر زمان که روند انتقال با مشکل رو به رو شود، اطلاعیه ایمیل دریافت کنید.
گام 9: روی دکمه ذخیره کلیک کنید.
نتیجهگیری
انتقال دادهها از گوگل ادز به بیگ کوئری به شما امکان انجام تحلیلهای پیشرفته از طریق ماشین لرنینگ و ابزارهای قدرتمند تصویرسازی را فراهم میکند. تمامی روشهایی که در این راهنما پوشش داده شدهاند، میتوانند به طور موثری دادههای گوگل ادز را با بیگ کوئری ادغام کرده و به شما کمک کنند تا تحلیل بهتری برای بهینهسازی کمپین تبلیغاتی خود انجام دهید.
در یکی از به روز رسانی های مربوط به اتصال بیگ کوئری به آنالیتیکس ۴، بخشی به اسم user data به آنالیتیکس ۴ در قسمت اتصال به بیگ کوئری اضافه شد. همانطور که در توضیحات این بخش نوشته شده است، با انتخاب این گزینه، به اطلاعات مرتبط با کاربر در بیگ کوئری به صورت خام دسترسی خواهید داشت. این اطلاعات از طریق جدول هایی به اسم pseudonymous_users_( number of days) و users_(number of days) در بیگ کوئری در دسترس هستند. برای آشنایی بیشتر با این جداول در بیگ کوئری در ادامه این مطلب همراه من باشید.
جدول pseudonymous_users در داده های آنالیتیکس ۴ در بیگ کوئری چیست؟
اگر قبل از این آنالیتیکس ۴ را به بیگ کوئری وصل کرده باشید، حتما میدانید که بعد از اتصال این دو ابزار به یک دیگر، اطلاعات مربوط به هر یک از ایونت های انجام شده توسط کاربر در سایت یا اپلیکیشن در بیگ کوئری از طریق جدولی به اسم events_ یا events_intraday_ در اختیار شما قرار داده می شود. احتمالا این سوال برای شما مطرح می شود که تفاوت این جدول ها با جداول events چیست؟
به طور کلی میتوان گفت که مزیت استفاده از جدول های نسبت به جدول های …، دسترسی به اطلاعات بیشتری از کاربران است. درواقع در این جدول ها شما به اطلاعاتی همچون audience ، prediction data، موقعیت جغرافیایی، دیوایس و … دسترسی دارید که در جدول های مربوط به ایونت در دسترس نیست.
همانطور که در اسکیمای جداول در بیگ کوئری میتوانید مشاهده کنید، میتوانید مشاهده کنید که کاربران سایت به کدام یک از سگمنت هایی که در آنالیتیکس ۴ ساخته اید، تعلق دارند. در نتیجه میتوانید از این اطلاعات برای استفاده در ابزارهایی به غیر از ابزارهای گوگل برای ری تارگتینگ استفاده کنید.
نام فیلد | نوع داده | توضیحات |
audiences | RECORD | اطلاعات audience |
audiences.id | INTEGER | آیدی audience |
audiences.name | STRING | اسم audience |
audiences.membership_start_timestamp_micros | INTEGER | زمانی که کاربر برای اولین بار در این audience قرار گرفت (بر حسب میکروثانیه) |
audiences.membership_expiry_timestamp_micros | INTEGER | زمانی که عضویت کاربر در این گروه مخاطبی منقضی میشود (برحسب میکروثانیه). |
audience.npa | BOOLEAN | درست یا نادرست بر اساس تنظیمات NPA شما برای ایونت و custom dimensions یوزر اسکوپ |
نام فیلد | نوع داده | توضیحات |
predictions | RECORD | اطلاعات پیش بینی |
predictions.in_app_purchase_score_7d | DOUBLE | احتمال اینکه کاربری که در 28 روز گذشته فعال بوده است، یک رویداد in_app_purchase را طی 7 روز آینده انجام دهد |
predictions.purchase_score_7d | DOUBLE | احتمال اینکه کاربری که در 28 روز گذشته فعال بوده است، یک ایونت خرید را طی 7 روز آینده انجام دهد. |
predictions.churn_score_7d | DOUBLE | احتمال اینکه کاربری که در ۷ روز گذشته در اپلیکیشن یا سایت شما فعال بوده است، در ۷ روز آینده فعال نخواهد بود. |
predictions.revenue_28d_in_usd | FLOAT | درآمد مورد انتظار (به دلار آمریکا) از همه ایونت های خرید در 28 روز آینده توسط کاربری که در 28 روز گذشته فعال بوده است. |
جدول pseudonymous_users در بیگ کوئری شامل چه اطلاعاتی می شود؟
در این جدول اطلاعات تمام کاربران سایت شما که یوزر آیدی ندارند، وجود دارد. اطلاعات این جدول هر زمان که اطلاعات مربوط به کاربران تغییر کند، به روز می شود.
به خاطر داشته باشید که اطلاعات این جدول در بیگ کوئری، تنها یک بار در روز به روز می شود و امکان ارسال اطلاعات به صورت لایو یا استریم وجود ندارد.
pseudonymous_users_( number of days) به معنای اطلاعات تمام کاربرانی است که درواقع شبه یوزر هستند و توسط سایت شما یوزر آیدی به آنها اختصاص داده نشده است. عدد داخل پرانتز، به تعداد روزهایی که اطلاعات از آنالیتیکس ۴ به بیگ کوئری انتقال پیدا کرده است، اشاره دارد.
- در این جدول، هر ردیف به یک user_pseudo_id اختصاص دارد.
- زمانی که یکی از مقادیر فلیدهای جدول تغییر کند، اطلاعات جدول به روز می شود.
- اطلاعات کاربرانی که با قوانین کوکی اعلام موافقت نکرده اند، در این جدول در دسترس نیست.
- فیلد user_id در جدول pseudonymous_users_ در دسترس نیست.
- در هر ردیف یک timestamp است که به آخرین زمانی که کاربر اکتیو بوده است، اشاره دارد.
منظور از شبه یوزر چیست؟
زمانی که کاربر برای اولین بار وارد سایت شما می شود، آنالیتیکس برای ردیابی کاربر، یک آیدی منحصر به فرد به ان اختصاص می دهد. تا زمانی که کاربر کوکی خود را پاک نکند و تا یک مدت زمان مشخص، آنالیتیکس کاربر را از طریق همین کلاینت آیدی، شناسایی و ردیابی می کند.
در حال حاضر آنالیتیکس ۴ برای شناسایی کاربر از روش های زیر استفاده می کند:
- User ID: در صورتی که یک سایت قابلیت ثبت نام یا لاگین داشته باشد، میتوان به کاربری که داخل سایت ثبت نام میکند، یک آیدی منحصر به فرد اختصاص داد و این آی دی را برای آنالیتیکس ۴ ارسال کرد. این روش، بهترین و شاید دقیق ترین روش ردیابی کاربران است. اما با توجه به اینکه تمام سایتها قابلیت لاگین ندارند، برای همه قابل استفاده نیست.
- Google Signals: در صورتی که کاربر در دیوایس های مختلف وارد اکانت گوگل خود شده باشد، آنالیتیکس میتواند از این طریق کاربر را شناسایی کرده و اطلاعات مربوط به آن را به صورت یکپارچه در اختیار شما قرار دهد.
- Device ID: اگر آنالیتیکس قادر به استفاده از دو روش قبلی نباشد، از این روش برای شناسایی و ردیابی کاربران استفاده می کند. این روش نسبت به روش های قبلی دقت کمتری دارد چون اگر کاربر از چند دیوایس برای مراجعه به سایت شما استفاده کند، به اشتباه چندین بار شمرده می شود.
جدول users در داده های آنالیتیکس ۴ در بیگ کوئری چیست؟
این جدول حاوی اطلاعات شبه یوزرهایی است که توسط سایت شما یک یوزر آیدی به آنها اختصاص داده شده است.
مهمترین نکاتی که در خصوص این جدول ها باید در نظر داشته باشید، عبارت هستند از:
- در صورتی که سایت شما قابلیت لاگین نداشته باشد یا یوزر ترکینگ انجام نشده باشد، این جدول در بیگ کوئری ایجاد نخواهد شد.
- در صورتی که چک باکس ارسال طالاعات به صورت روزانه را هنگام اتصال آنالیتیکس ۴ به بیگ کوئری نزده باشید، این اطلاعات در بیگ کوئری در دسترس نخواهند بود.
- در صورتی که یک وب سایت اروپایی دارید و کاربر با قوانین کوکی اعلام موافقت نکرده باشد، اما توسط سایت شما دارای یک یوزر آی دی اختصاصی باشد، اطلاعات کاربر در جدول users در دسترس خواهد بود.
چه اطلاعاتی در جدول users_ وجود دارد؟
- در این جدول، هر ردیف به یک user_ id اختصاص دارد.
- زمانی که یکی از مقادیر فلیدهای جدول تغییر کند، اطلاعات جدول به روز می شود.
- اطلاعات کاربرانی که با قوانین کوکی اعلام موافقت نکرده اند، در این جدول در دسترس هست.
- فیلد user_pseudo_id در جدول users_ در دسترس نیست.
- در هر ردیف یک timestamp است که به آخرین زمانی که کاربر اکتیو بوده است، اشاره دارد.
بیگ کوئری از چهار گروه تابع مربوط به تاریخ و زمان DATE، TIME، DATETIME، و TIMESTAMP پشتیبانی می کند. این 4 گروه شامل توابع خاصتری مانند CURRENT_DATETIME، DATE_SUB، EXTRACT، FORMAT_TIME و غیره هستند. این توابع به کاربران اجازه می دهد تا انواع دادههای مربوط به تاریخ و زمان را در BigQuery به راحتی استخراج و ویرایش کنند. به عنوان مثال، با استفاده از این توابع میتوان بخشی از عبارت تاریخ یا زمان را استخراج کرد، یک فاصله زمانی به تاریخ یا زمان اضافه کرد و غیره. با توجه به اینکه تنوع و کارکرد هریک از این توابع متنوع و گاها گیج کننده است، در این مطلب به بررسی توابع مربوط به تاریخ در بیگ کوئری و کاربرد هریک میپردازیم.
انواع دادههای مربوط به تاریخ و زمان در BigQuery
قبل از آنکه به بررسی انواع توابع مربوط به تاریخ و زمان در بیگ کوئری بپردازیم، بهتر است که با انواع داده در بیگ کوئری در رابطه با تاریخ و زمان آشنا شوید:
توابع DATE، TIME، DATETIME، و TIMESTAMP در BigQuery SQL
در زیر جدولی از چهار گروه تابع تاریخ و زمان در BigQuery و همچنین توابع فرعی آنها آورده شده است.
دریافت تاریخ امروز در بیگ کوئری
برای دریافت عبارت تاریخ یا زمان امروز می توانید از تابع CURRENT در BigQuery استفاده کنید. برای استفاده از این تابع، از ساختار زیر استفاده کنید:
CURRENT_DATE()
CURRENT_DATETIME()
CURRENT_TIMESTAMP()
CURRENT_TIME()
مثال زیر نحوه استفاده از تابع CURRENT_DATETIME را برای دریافت تاریخ امروز و زمان حال نشان می دهد.
نحوه تغییر فرمت تاریخ در بیگ کوئری
هنگامی که با دادههای مربوط به تاریخ و زمان سروکار دارید، ممکن است بخواهید فرمتی که داده در آن ظاهر میشود را با استفاده از تابع FORMAT تغییر دهید. به عنوان مثال، بعد از اتصال آنالیتیکس 4 به بیگ کوئری، در بخش اسکیمای جدول آنالیتیکس متوجه میشوید که اطلاعات مربوط به event_date به صورت رشته در بیگ کوئری ذخیره می شوند. با توجه به اینکه خروجی تابع FORMAT از جنس رشته است؛ به راحتی میتوانید از این تابع همراه با ستون event_date استفاده کنید.
برای استفاده از این تابع، از ساختار زیر استفاده کنید:
FORMAT_DATE(format_string, date)
FORMAT_DATETIME(format_string, datetime)
FORMAT_TIMESTAMP(format_string, timestamp,[timezone])
FORMAT_TIME(format_string, time)
در مثال زیر با استفاده از تابع FORMAT، نحوه نمایش تاریخ را تغییر دادهایم:
فرمت رشته “%x” تاریخ را به صورت MM/DD/YY نشان می دهد.
اضافه یا کم کردن تاریخ و زمان در بیگ کوئری
در BigQuery میتوانیم عملیاتی مانند اضافه کردن یک سال به تاریخ، کم کردن یک هفته، اضافه کردن یک ساعت یا دقیقه به یک زمان و غیره را اجرا کنیم.
اضافه کردن به تاریخ یا زمان در بیگ کوئری
برای اضافه کردن به تاریخ و زمان در BigQuery باید از دستورات زیر استفاده کنید:
DATE_ADD(date_expression, INTERVAL int64_expression date_part)
DATETIME_ADD(datetime_expression, INTERVAL int64_expression date_part)
TIMESTAMP_ADD(timestamp_expression, INTERVAL int64_expression date_part)
TIME_ADD(time_expression, INTERVAL int64_expression date_part)
- با استفاده از interval برای بیگ کوئری مشخص میکنیم که قصد داریم دیتای مربوط به تاریخ یا زمان را به چه صورتی تغییر دهیم.
- int64_expression حاوی مقادیری است که از (9,223,372,036,854,775,808- تا 9,223,372,036,854,775,807-) متغیر است.
- به جای بخش date_part میتوانید از یکی از مقادیر DAY، HOUR، MINUTE، SECOND، MILLISECOND، MICROSECOND، WEEK، QUARTER، MONTH و YEAR استفاده کنید.
به عنوان مثال، در کوئری زیر از تابع DATE_ADD برای اضافه کردن یک روز به تاریخ استفاده میکنیم:
کم کردن از تاریخ یا زمان در بیگ کوئری
برای کم کردن از تاریخ و زمان در BigQuery باید از دستورات زیر استفاده کنید:
DATE_SUB(date_expression, INTERVAL int64_expression part)
DATETIME_SUB(datetime_expression, INTERVAL int64_expression part)
TIMESTAMP_SUB(timestamp_expression, INTERVAL int64_expression part)
TIME_SUB(time_expression, INTERVAL int64_expression part)
- با استفاده از interval برای بیگ کوئری مشخص میکنیم که قصد داریم دیتای مربوط به تاریخ یا زمان را به چه صورتی تغییر دهیم.
- int64_expression حاوی مقادیری است که از (9,223,372,036,854,775,808- تا 9,223,372,036,854,775,807-) متغیر است.
- به جای بخش date_part میتوانید از یکی از مقادیر DAY، HOUR، MINUTE، SECOND، MILLISECOND، MICROSECOND، WEEK، QUARTER، MONTH و YEAR استفاده کنید.
به عنوان مثال، در کوئری زیر از تابع DATETIME_SUB برای کم کردن یک روز از تاریخ استفاده میکنیم:
نحوه گروه بندی تاریخ/زمان در BigQuery
هنگام ارزیابی دادههای تاریخ/زمان در BigQuery، میتوانیم دادههای خود را بر اساس بخشهای مختلف تاریخ مانند دقیقه، ساعت، روز، سال، هفته و غیره سازماندهی و گروهبندی کنیم. برای انجام این کار میتوانید از دستورات زیر استفاده کنید:
DATE_TRUNC(date_expression, date_part)
DATETIME_TRUNC(datetime_expression, date_part)
TIMESTAMP_TRUNC(timestamp_expression, date_part)
TIME_TRUNC(time_expression, date_ part)
- به جای بخش date_part میتوانید از یکی از مقادیر DAY، HOUR، MINUTE، SECOND، MILLISECOND، MICROSECOND، WEEK، QUARTER، MONTH، YEAR، DAYOFWEEK، DAYOFYEAR، ISOWEEK و ISOYEAR استفاده کنید.
در مثال زیر از تابع DATE_TRUNC برای برگرداندن اولین روز ماه استفاده میکنیم.
SELECT
DATE_TRUNC(DATE ‘2021-07-25’, MONTH) AS first_day_of_month;
علاوه بر این، به جای استفاده از تابع TRUNC، می توانید از تابع LAST DAY برای بدست آوردن آخرین روز هر date_part استفاده کنید.
LAST_DAY(date_expression, [date_part])
LAST_DAY(datetime_expression, [date_part])
مثال زیر از تابع LAST_DAY برای برگرداندن آخرین روز هفته که از یکشنبه شروع می شود استفاده می کند.
SELECT
LAST_DAY(DATETIME ‘2021-07-10 11:45:00’, WEEK(SUNDAY))
7-last-day
نحوه استخراج بخشی از تاریخ و زمان در بیگ کوئری
میتوانید بخشی از تاریخ را از داده تاریخ خود استخراج کنید، مانند بررسی زمان ورود کاربر یا بررسی آمار کلی ماهانه برای بررسی اینکه کدام ماهها فروش بیشتری دارند. برای اجرای چنین عملیاتی میتوانید از دستورات زیر استفاده کنید:
EXTRACT(part FROM date_expression)
EXTRACT(part FROM datetime_expression)
EXTRACT(part FROM timestamp_expression)
EXTRACT(part FROM time_expression)
- به جای بخش date_part میتوانید از یکی از مقادیر DAY، HOUR، MINUTE، SECOND، MILLISECOND، MICROSECOND، WEEK، QUARTER، MONTH، YEAR، DAYOFWEEK، DAYOFYEAR، ISOWEEK و ISOYEAR استفاده کنید.
مثال زیر از تابع EXTRACT برای برگرداندن مقدار دقیقه استفاده می کند.
SELECT
EXTRACT(MINUTE FROM DATETIME(“2020-12-25 15:30:00”)) as minute;
8-extract
چگونه تفاوت بین دو تاریخ یا زمان را بیگ کوئری محاسبه کنیم؟
برای محاسبه تفاوت بین دو تاریخ، میتوانید از دستورات زیر استفاده کنید:
DATE_DIFF(date_expression_a, date_expression_b, part)
DATETIME_DIFF(datetime_expression_a, datetime_expression_b, part)
TIMESTAMP_DIFF(timestamp_expression_a, timestamp_expression_b, part)
TIME_DIFF(time_expression_a,time_expression_b, part)
در مثال زیر از تابع DATE_DIFF برای محاسبه تفاوت ماه بین دو تاریخ استفاده شده است:
SELECT
DATE “2021-12-15 12:30:10” as first_date,
DATE “2021-07-15 17:45:33” as second_date,
DATE_DIFF(DATE “2021-12-15”,
DATE “2021-07-15”, MONTH) as month_difference;
9-date-diff
نحوه تبدیل انواع دادههای تاریخ و زمان در BigQuery
با تابع CAST میتوانید نوع یک داده را به یک نوع دیگر تبدیل کنیم. نحوه استفاده از تابع CAST به صورت زیر است:
CAST(expression AS datatype)
تبدیل رشته به تاریخ یا زمان
SELECT
CAST(’19:30:12′ AS TIME) AS time
10-cast-string
تبدیل datetime به date
SELECT
CAST(CURRENT_DATETIME() AS DATE);
11-cast-datetime-date
توجه: برای انجام این کار میتوانید از DATE(datetime expression) هم استفاده کنید.
عملگرهای موجود برای مقایسه تاریخ در بیگ کوئری
در BigQuery، گاهی اوقات ممکن است نیاز به مقایسه تاریخ و زمان برای انجام عملیاتی مانند دریافت دادههای هفته قبل یا در محدوده خاصی با استفاده از عملگرهای مختلف مقایسه داشته باشید:
<, <=, >, >=, = , != or <>, [NOT] BETWEEN, [NOT] LIKE, [NOT] IN
مثال زیر از عملگرهای >= و < برای دریافت تمام تاریخ های مشخص شده بین دو تاریخ استفاده می شود:
SELECT
date
FROM
(
SELECT
CAST(‘2021-07-02’ AS DATE) AS date
UNION ALL
( SELECT
CAST(‘2021-07-11’ AS DATE) AS date)
UNION ALL
( SELECT
CAST(‘2021-10-02’ AS DATE) AS date)
) AS table_3
WHERE
((date >= ‘2021-07-02’) AND (date < ‘2021-07-30’))
12-date-comparison
خدمات نصب و راه اندازی آنالیتیکس 4
قبل از شروع صحبت در مورد مهاجرت به آنالیتیکس 4، مهم است که تنظیمات GA فعلی شما را بررسی کنم. قبل از هرچیز من تمام ایونت ترکینگ هایی که انجام داده اید را بررسی میکنم. بعد از آن نوبت به بررسی تنظیمات آنالیتیکس شما میرسد. سپس بر اساس آنچه که میتوانید ردیابی کنید اما هنوز این کار را انجام نداده اید، پیشنهادات خودم را در اختیار شما قرار میدهم. بسیاری از مشتریان نمیدانند (یا مطمئن نیستند که چگونه باید ایونت ترکینگ را انجام دهند. بر اساس تجربه میگویم که بسیاری از صاحبان بیزینسهای مختلف نمیدانند که میتوانند به اطلاعاتی مانند تجزیه و تحلیل ویدیو، تراکنشها، پر کردن فرمها و حتی موارد دیگر با استفاده از GA4 دسترسی داشته باشند. اما جای نگرانی نیست؛ چون من این کار را به طور کامل برای شما انجام خواهم داد.
آموزش آنالیتیکس 4
بعد از نصب و راه اندازی آنالیتیکس 4 و ساخت گزارش در بخش explore، احتمالاً متوجه وجود ردیفی به اسم not set شدهاید. اگر میخواهید بدانید که دلیل نمایش not set در آنالیتیکس 4 چیست و باید با آن چه کرد، در ادامه این مطلب همراه من باشید. به طور کلی در خصوص Not set در GA4 میتوان گفت:
- در برخی شرایط، امکان رفع و حذف Not set در GA4 وجود دارد
- در شرایط دیگر، میتوان تعداد دفعات ظاهرشدن Not set را کاهش داد
- و در بقیه موارد، Not set چیزی است که باید وجود آن را در آنالیتیکس 4 بپذیریم تا زمانی که Google برخی موارد را تغییر دهد یا به روز کند!
همانطور که حتماً میدانید، ابزار آنالیتیکس 4، همچنان یک ابزار در حال توسعه است که ابهامات زیادی در خصوص برخی از موارد آن، مانند Not set وجود دارد.
Not set در آنالیتیکس 4 چیست؟
Not set مقداری است که به عنوان مقدار یک دایمنشن در گزارشهای آنالیتیکس 4 نمایش داده میشود، زمانی که آن دایمنشن، هیچ مقدار منحصر به فرد یا مشخصی نداشته باشد. به عنوان مثال، اگر قصد موضوعی در خصوص سایتتان را دارید؛ اما به اشتباه از دایمنشنهای مربوط به اپ استفاده کنید، مقداری که برای دایمنشن نمایش داده میشود، Not set خواهد بود.اما زمانی با مشکل روبهرو خواهید شد که برای دایمنشنی که درست انتخاب کردهاید، باز هم مقدار NOT SET را مشاهده میکنید.
علت وجود (Not Set) در گزارشهای لندینگپیج در آنالیتیکس 4 چیست؟
در آنالیتیکس یونیورسال گاهی اوقات مدار دایمنشن landing page در گزارشها، not set تعیین میشد. این مشکل همچنان در آنالیتیکس 4 هم وجود دارد. اما علت این مشکل چیست؟
اگر سشن کاربر با ایونتی به اسم page_view همراه نباشد، یعنی پارامتر یا اطلاعات اضافهای به اسم page_location هم وجود ندارد. در نتیجه مقدار landing page، Not set تعیین میشود. گرچه page_view به صورت خودکار توسط آنالیتیکس 4 ردیابی میشود، اما باز هم ممکن است که در برخی از شرایط خاص، page_view اتفاق نیفتند و در نتیجه گزارش لندینگپیج در آنالیتیکس 4 دچار مشکل شود.
یک سناریوی احتمالی عبارت هستند از:
- تنظیمات پیشفرض مدت زمان سشن را در GA4 تغییر ندادهاید، به این معنی که پس از 30 دقیقه عدم فعالیت، سشن بازدیدکنندگان وبسایت شما منقضی میشود.
- یک بازدیدکننده وب سایت شما را در یک تب مرورگر باز میکند و آن را برای بیش از 30 دقیقه بازمیگذارد (بهعنوانمثال، او برای خوردن ناهار رفته است).
- زمان سشن تمام میشود.
- آن شخص به وب سایت شما برمیگردد و سپس کاری انجام میدهد؛ مثلاً اسکرول میکند، ایونت user_engagement و … اتفاق میافتد و ردیابی آنالیتیکس 4 بدون اتفاق افتادن page_view جدید همراه با سشن جدید، آغاز میشود.
در این سناریو، دو سشن برای کاربر ثبت شده است که یکی همراه با page_view و دیگری بدون ایونت page_view اتفاق افتاده است.
دلایل نمایش (not set) در گزارشهای Google Ads
اگر در گزارشهای تبلیغاتیتان مقدار (not set) را مشاهده میکنید، احتمالاً یکی از موارد زیر دلیل آن است:
1. اتصال بین حساب Google Ads و GA4 برقرار نیست
اطمینان حاصل کنید که حساب گوگل ادز به درستی به خاصیت GA4 لینک شده باشد. در غیر این صورت، اطلاعات کلیکها و کمپینها منتقل نمیشود.
2. Auto-tagging فعال نیست
قابلیت Auto-tagging باید فعال باشد تا GA4 بتواند اطلاعات مربوط به کلیکها را به درستی دریافت کند. در تنظیمات Google Ads بررسی کنید که این گزینه فعال باشد.
3. ترافیک از حسابهای Google Ads غیرمتصل
اگر چند اکانت گوگل ادز دارید که به GA4 لینک نشدهاند، ترافیک حاصل از آنها با (not set) نمایش داده میشود. دلیل آن این است که GA4 نمیتواند کلیکها را به ایونت ها نسبت دهد.
4. استفاده از UTM ناقص یا اشتباه در URLهای مقصد
در صورتی که لینکهای مقصد را به صورت دستی تگ کردهاید ولی پارامترهای UTM ناقص یا نادرست باشند، مقدار (not set) نمایش داده میشود. این مشکل تنها محدود به Google Ads نیست و ممکن است در لینکهای شبکههای اجتماعی، وبلاگها یا سایر منابع نیز رخ دهد.
برای جلوگیری از این مشکل از ابزارهای رسمی Google برای ساخت URLهای تگشده استفاده کنید.
نمایش (not set) در دایمنشنهای مختلف GA4
دایمنشن Session Source / Medium
در صورت نبود ایونت session_start، GA4 نمیتواند منبع یا چنل را تعیین کند. معمولاً این مشکل به دلیل انتخاب اشتباه نوع Trigger در Google Tag Manager رخ میدهد.
راهحل:
نوع Trigger را به «Initialization – All pages» تغییر دهید. این کار را از طریق تگ مربوط به GA4 در محیط Google Tag Manager انجام دهید.
اگر session source / medium به عنوان (not set) گزارش شود، ترافیک شما در گروه کانالهای پیشفرض به عنوان “Unassigned” یا «اختصاصنیافته» دستهبندی خواهد شد.
دایمنشن Landing Page
اگر سشن شما ایونت page_view نداشته باشد، دایمنشن صفحه فرود مقدار (not set) خواهد داشت. این مورد ممکن است در کمپینهایی با لینکهای ناقص یا در صفحات با اسکریپتهای ناقص رخ دهد.
دایمنشن Content Group
اگر از این دایمنشن همراه با ایونت های خودکار مانند session_start یا first_visit استفاده کرده باشید، ممکن است مقدار (not set) را مشاهده کنید. دلیل این است که این ایونت ها پارامتر content_group را پشتیبانی نمیکنند.
همچنین اگر پارامتر content_group را ارسال کرده باشید ولی مقدار آن خالی باشد (مثلاً content_group: “”)، باز هم مقدار (not set) نمایش داده میشود.
دایمنشن Custom User ID
استفاده از User ID به عنوان یک دایمنشن سفارشی توصیه نمیشود. در این حالت، احتمال نمایش مقدار (not set) وجود دارد. گوگل پیشنهاد میکند از قابلیت رسمی User-ID استفاده کنید.
پارامترهای سفارشی (Custom Parameters)
برای ایونت هایی که پارامترهای سفارشی دارند، در ۲۴ ساعت اول ممکن است مقدار (not set) گزارش شود. پس از گذشت این بازه زمانی، دادههای مورد انتظار نمایش داده میشوند.
اگر پارامترهای سفارشی در اولین ایونت ها (مانند session_start یا first_visit) حضور نداشته باشند، مقدار (not set) ثبت میشود.
اگر مدتی است که با گوگل آنالیتیکس ۴ (Google Analytics 4) کار میکنید، احتمالاً متوجه حضور مرموز عبارتی به نام (not set) در برخی از گزارشها شدهاید. در این مطلب، دقیقاً توضیح میدهیم که برای از بین بردن (not set) در آنالیتیکس ۴ چه باید کرد.
قبل از اینکه وارد جزئیات شویم، بهتر است چند موضوع درباره این موضوع را شفاف کنیم:
- در بعضی موارد، امکان برطرف کردن و حذف (not set) در گوگل آنالیتیکس ۴ وجود دارد.
- در برخی موقعیتها، میتوانید میزان رخداد این مشکل را کاهش دهید.
- اما در سایر موارد، باید این موضوع را پذیرفت تا زمانی که گوگل تغییرات یا بهروزرسانیهای لازم را در این زمینه اعمال کند.
قبل از اینکه وارد توضیحات فنی شویم، لازم است چند نکته مهم را در نظر داشته باشید.
دلایل نمایش Landing Page به صورت (not set) در GA4
تایماوت سشن (Session Timeout)
یکی از دلایل اصلی نمایش (not set) در صفحهی فرود، پایان یافتن خودکار سشن به دلیل عدم فعالیت کاربر است.
سناریوی رایج
- مدت زمان پیشفرض سشن در GA4، سی دقیقه است.
- کاربر سایت را در یک تب مرورگر باز کرده و برای مدتی (مثلاً صرف ناهار) از سیستم دور میشود.
- سشن پس از ۳۰ دقیقه بیتحرکی منقضی میشود.
- کاربر بدون رفرش یا باز کردن صفحهی جدید، حرکتی انجام میدهد (مثلاً اسکرول میکند یا روی چیزی کلیک میکند).
- این رویداد جدید یک سشن تازه شروع میکند، اما چون رویداد page_view وجود ندارد، صفحهی فرودی ثبت نمیشود.
نتیجه: سشن جدید بدون page_view آغاز شده و در نتیجه صفحهی فرود به صورت (not set) نمایش داده میشود.
چطور این مشکل را کاهش دهیم؟
برای کاهش این مشکل میتوانید مدت زمان پیشفرض سشن را افزایش دهید.
آموزش افزایش مدت زمان سشن در GA4
۱. وارد GA4 شوید.
۲. به مسیر زیر بروید:
Admin > Data Streams > انتخاب وب دیتا استریم > Configure Tag Settings > Show All > Adjust Session Timeout
۳. مدت زمان سشن را به ۴ ساعت یا حتی حداکثر (۷ ساعت و ۵۵ دقیقه) افزایش دهید و ذخیره کنید.
نکته: با افزایش مدت سشن، تعداد سشنهای ثبت شده کاهش مییابد و میانگین مدت زمان سشن افزایش پیدا میکند. پیش از اعمال تغییرات این تاثیرات را در نظر بگیرید.
Measurement پروتکل در GA4
Measurement پروتکل یکی از روشهایی است که میتوانید با استفاده از آن دادهها را به Google Analytics 4 (GA4) ارسال کنید. این پروتکل برای انتقال دادهها از سرور شما (مثلاً سیستم CRM) به GA4 طراحی شده است. اما هدف اصلی آن، غنیسازی اطلاعات جمعآوریشده از وبسایت است، نه شروع سشن های (Session) جدید یا ایجاد کاربران/بازدیدکنندگان جدید.
ارسال ایونت های تکمیلی با پروتکل Measurement
این یعنی اگر کاربری وارد وبسایت شما شده و یک سشن را آغاز کرده باشد، میتوانید از سمت سرور خود، ایونت های بیشتری ارسال کرده و به همان سشن متصل کنید. این امکان تا ۷۲ ساعت پس از زمان ایونت اولیه در دسترس است.
یک نکتهی مهم درباره استفاده از پروتکل Measurement
با این حال، یک نکتهی مهم وجود دارد: رویدادهایی که از طریق پروتکل Measurement ارسال میشوند، بهطور خودکار اطلاعات ثبتشده توسط کد رهگیری وبسایت را بازیابی نمیکنند. به عنوان مثال، اگر کاربری وارد صفحهای خاص شود، GA4 به صورت خودکار پارامتری به نام page_location
را ثبت میکند. اما اگر در همان لحظه از طریق پروتکل Measurement یک رویداد ارسال کنید، آن رویداد پارامترهایی مانند page_location
یا سایر ابعاد (Dimensions) مرتبط با نشست را به ارث نمیبرد.
تاثیر عدم ارسال اطلاعات کاربر
برای نمونه، اگر اطلاعات مربوط به مرورگر کاربر (user agent) را هنگام ارسال رویداد نفرستید، رویداد ارسالی فاقد اطلاعاتی مانند نوع دستگاه (Device Category) یا نسخه مرورگر خواهد بود. در این صورت، این ابعاد با مقدار (not set)
در GA4 نمایش داده میشوند.
مشکل اصلی در حال حاضر این است که هیچ روش رسمی و مستندی وجود ندارد که اجازه دهد IP کاربر یا اطلاعات مرورگر (user agent) از طریق پروتکل Measurement به GA4 ارسال شود. در بخشهای بعدی این مقاله، به این موضوع بیشتر خواهم پرداخت.
نتیجهگیری درباره تاثیر پروتکل Measurement
بنابراین، اگر در تنظیمات GA4 خود از پروتکل Measurement استفاده میکنید، احتمال زیادی وجود دارد که برخی از دادههای ناقص یا مقدار (not set)
در گزارشهای شما، ناشی از همین موضوع باشد. در ادامه این مقاله به جزئیات بیشتری درباره سایر مشکلات احتمالی خواهم پرداخت.
از بین بردن not set در گزارش های سشن سورس مدیوم
یکی از مشکلات رایجی که در گزارشهای Google Analytics 4 (بهویژه در بخش Traffic Acquisition) مشاهده میشود، ظاهر شدن مقدار (not set) در دایمنشن Session Source/Medium است. این مشکل باعث میشود ترافیک بخشی از کاربران در دستهبندی Unassigned قرار گیرد و تحلیل رفتار کاربران دچار اختلال شود.
۱. بررسی پیادهسازی Measurement Protocol
اگر دولوپر هنگام ارسال Events از طریق Measurement Protocol مقدار session_id را بهدرستی تنظیم نکند، GA4 نمیتواند چنل ترافیک را شناسایی کند. این اتفاق بهخصوص زمانی رخ میدهد که ایونت ها با تاخیر (تا ۷۲ ساعت قبل) ارسال شده و مقدار timestamp_micros اشتباه یا حذف شده باشد.
⚠️ اگر session_id
بهصورت تصادفی تولید شده باشد و با سشن واقعی در سایت هماهنگ نباشد، مقدار (not set) در گزارشها ثبت خواهد شد.
۲. عدم وجود ایونت session_start
دایمنشن های مربوط به منابع ترافیکی مثل Session Source / Medium از ایونت session_start استخراج میشوند. اگر این ایونت به هر دلیلی در طول سشن ارسال نشود، مقدار (not set) جایگزین خواهد شد.
این مشکل معمولاً سرور ساید ترکینگ (Server-side Tagging) رخ میدهد، جایی که ممکن است session_start
در مسیر ارسال داده به GA4 فیلتر شده باشد.
۳. Audience Triggers و تأثیر آن بر مقدار (not set)
ویژگی Audience Trigger در GA4 امکان ارسال خودکار ایونت هنگام ورود کاربر به یک دسته خاص را فراهم میکند. اما نکته مهم اینجاست که در برخی موارد، این ایونت به هیچ سشنی اختصاص داده نمیشود؛ در نتیجه GA4 نمیتواند منبع ترافیک را تشخیص دهد.
حتی در Audienceهای معمولی (غیرپیشبینیشده)، این مشکل گاهی رخ میدهد و فعلاً راهحلی برای آن وجود ندارد.
۴. مشکلات مربوط به پارامترهای UTM
اگر پارامترهای UTM که در لینکهای تبلیغاتی یا شبکههای اجتماعی استفاده میکنید اشتباه تنظیم شده باشند، مثل ساختار نادرست یا مقادیر خالی — GA4 نمیتواند آنها را تحلیل کند و نتیجه آن (not set) خواهد بود.
🔍 پیشنهاد میشود لینکهای تبلیغاتی خود را بهطور کامل بازبینی کرده و از صحت مقادیر UTM مطمئن شوید.
۵. ترتیب اشتباه اجرای تگ ها در Google Tag Manager
یکی از خطاهای رایج در فروشگاههای آنلاین این است که تگهای مربوط به ایونت هایی مانند view_item
یا purchase
زودتر از Google Tag (پیکربندی GA4) اجرا میشوند. در چنین حالتی، دادهها بدون تنظیمات اولیه GA4 ارسال شده و به شکل (not set) در گزارشها ثبت میشوند.
راهکار: از حالت پیشنمایش (Preview) در GTM استفاده کنید تا ترتیب اجرای تگها را بررسی و اصلاح نمایید.
۶. پیادهسازی ناقص Google Tag Manager سمت سرور
اگر از Server-side GTM استفاده میکنید اما برخی از تگ های GA4 را به درستی به سرور هدایت نکرده باشید، ترافیک شما بین چند دامنه مختلف تقسیم شده و اطلاعات منبع/رسانه ناقص خواهد بود.
مطمئن شوید که همه برچسبهای GA4 شامل پارامتر server_container_url
هستند و به درستی به دامنه سرور ارسال داده میشود.
رفع مشکل not set در گزارش های گوگل ادز
بررسی اتصال اکانت Google Ads به GA4
اگر حساب Google Ads شما به درستی به property مورد نظر در GA4 متصل نشده باشد، هیچ دادهای از آن منتقل نخواهد شد. مطمئن شوید که اتصال به درستی انجام شده. همچنین اگر شرکت یا برند شما چند اکانت گوگل ادز دارد، حتی عدم اتصال یکی از آنها (که ترافیک به سایت ارسال میکند)، میتواند منجر به ثبت (not set) شود.
بررسی وضعیت Auto-tagging
قابلیت Auto-tagging بهطور خودکار دادههای Google Ads را به GA4 منتقل میکند. این ویژگی به شما امکان میدهد تا بفهمید کاربران بعد از کلیک روی تبلیغات دقیقاً چه کاری در سایت انجام دادهاند. توصیه میشود همیشه این قابلیت را فعال نگه دارید.
بررسی منوآل تگینگ ها (Manual tagging)
در صورتی که از تگگذاری دستی برای لینک مقصد استفاده میکنید، باید بسیار دقت داشته باشید؛ زیرا این روش احتمالا با خطای زیادی همراه است. اگر تگگذاری را بهدرستی انجام نداده باشید، یا کلاً تگی تعریف نکرده باشید، در گزارشها مقدار (not set) نمایش داده میشود.
بررسی تنظیمات Google Ads
اگر چند اکانت گوگل ادز را به GA4 متصل کردهاید اما در برخی از آنها Auto-tagging غیرفعال است، باز هم با مشکل (not set) مواجه میشوید. حتی اگر در URL کاربران پارامتر gclid
وجود داشته باشد، اما اتصال اکانت به درستی انجام نشده باشد، GA4 قادر به دریافت اطلاعات کمپین نخواهد بود.
رفع مشکل not set در گزارش صفحات
بررسی تعداد کاراکترهای آدرس صفحه
طبق بررسیها، اگر آدرس صفحات وبسایت شما (شامل پروتکل https، پارامترهای کوئری و…) بیش از ۵۰۰ کاراکتر باشد، GA4 دیگر نمیتواند مقدار page_location را ثبت کند. این موضوع نه فقط روی گزارشهای داخل GA4، بلکه روی دادههای خروجی به BigQuery هم تأثیر میگذارد.
🔧 راهحل چیست؟
میتوانید مقدار پارامتر page_location را بهصورت دستی در تگهای GA4 (یا GTAG) بازنویسی کرده و نسخهای کوتاهتر از URL را جایگزین کنید. بهعنوان مثال، حذف پارامترهای غیرضروری از URL، همانطور که برخی متخصصان سئو انجام میدهند، یک راهحل عملی است.
بررسی تگ <title>
در کد HTML صفحه
یکی از رایجترین دلایل این مشکل، نبود تگ عنوان در ساختار HTML صفحه است. اگر وبسایت بهخوبی نگهداری یا بهروزرسانی نشده باشد، احتمال اینکه برخی صفحات فاقد تگ <title>
باشند زیاد است.
چگونه بفهمیم کدام صفحات عنوان ندارند؟
برای شناسایی صفحات بدون عنوان، مراحل زیر را در GA4 دنبال کنید:
- وارد بخش Reports > Engagement > Pages and screens شوید.
- دو (dimension) زیر را تنظیم کنید:
- Page title and screen class (یا: Page title and screen name) بهعنوان بُعد اصلی
- Page Path and Screen class بهعنوان بُعد دوم
با این کار میتوانید صفحاتی که عنوان ندارند را تشخیص دهید. پس از شناسایی این صفحات، با توسعهدهندهی وبسایت همکاری کنید تا تگ <title>
به درستی در آنها اضافه شود.
بررسی بارگذاری زودهنگام GA4 نسبت به تگ عنوان
در برخی موارد نادر، ممکن است کد رهگیری GA4 در بالاترین بخش فایل HTML صفحه قرار گرفته باشد، در حالیکه تگ <title>
پایینتر در کد نوشته شده است. در این حالت، زمانیکه GA4 بارگذاری میشود، هنوز عنوان صفحه در دسترس نیست، بنابراین در گزارشها بهصورت «(not set)» ظاهر میشود.
این سناریو خیلی رایج نیست، اما از نظر تئوریک ممکن است اتفاق بیفتد و به همین دلیل اشاره به آن ضروری است.
علت نمایش «(not set)» در بخش Language گوگل آنالیتیکس ۴ (GA4)
در گوگل آنالیتیکس ۴، مقدار Language معمولاً بر اساس تنظیمات مرورگر کاربر تعیین میشود. بنابراین در شرایط عادی، بیشتر کاربران با یک مقدار مشخص برای این پارامتر شناسایی میشوند. با این حال، گاهی ممکن است در گزارشهای GA4 با مقدار «(not set)» در ستون Language مواجه شوید.
آیا باید نگران باشیم؟
بر اساس تجربیات موجود، معمولاً درصد این مقدار بسیار کم است و تأثیر قابل توجهی در تحلیلهای شما نخواهد داشت. با این حال، اگر درصد «(not set)» در گزارشهای شما بالاست، بهتر است دلایل آن را بررسی کنید.
دلایل رایج برای نمایش «(not set)» در Language
در ادامه، سه دلیل رایج برای بروز این وضعیت را مرور میکنیم:
۱. استفاده از Measurement Protocol بدون ارسال پارامتر زبان
اگر از Measurement Protocol برای ارسال ایونت ها به GA4 استفاده میکنید (مثلاً از طریق اسکریپت اختصاصی یا اتصال مستقیم سرور)، باید مطمئن شوید که پارامتر زبان کاربر (معمولاً با کلید ul
یا language
) همراه با هر ایونت ارسال میشود. در غیر این صورت، GA4 نمیتواند زبان کاربر را تشخیص دهد و مقدار «(not set)» را ثبت میکند.
۲. مرورگر یا افزونههایی که اطلاعات زبان را مخفی میکنند
برخی از کاربران از مرورگرهایی استفاده میکنند که به دلایل حریم خصوصی، اطلاعات مربوط به زبان را تغییر میدهند یا پنهان میکنند. افزونههای امنیتی یا حریم خصوصی مانند uBlock Origin یا Privacy Badger نیز ممکن است باعث حذف این اطلاعات از درخواستها شوند. در نتیجه، گوگل آنالیتیکس نمیتواند زبان کاربر را تشخیص دهد.
۳. سرورساید ترکینگ (Server-side Tagging) بدون ارسال ul
اگر از مدل برچسبگذاری سمت سرور (Server-side tagging) استفاده میکنید، احتمال دارد در فرآیند تنظیمات تگها، پارامتر ul
(User Language) به درخواست ارسال نشود. در این صورت نیز GA4 نمیتواند مقدار زبان را شناسایی کند و نتیجه بهصورت «(not set)» ثبت خواهد شد.
علت نماش not set در گزارش موقعیت جغرافیایی
اگر هنگام بررسی دادههای جمعیتشناسی در Google Analytics 4 (GA4) با عباراتی مثل (not set) در بخشهای مرتبط با مکان جغرافیایی (مثل شهر یا کشور) مواجه شدهاید، تنها نیستید. این مشکل یکی از چالشهای رایجی است که بسیاری از تحلیلگران داده در ایران و سایر کشورها تجربه کردهاند. در ادامه به دلایل اصلی این اتفاق و نکاتی برای درک بهتر آن میپردازیم.
مشکل از کجاست؟ نقش Measurement Protocol در گم شدن دادههای جغرافیایی
یکی از رایجترین دلایل دیده شدن (not set) در دادههای مکان جغرافیایی، مربوط به استفاده از Measurement Protocol (MP) است. اگر ایونت ها را از طریق MP به GA4 ارسال میکنید، باید بدانید که:
- در MP امکان ارسال یا بازنویسی IP کاربر یا User Agent وجود ندارد.
- در نتیجه، اطلاعاتی مانند موقعیت جغرافیایی یا مرورگر کاربر هنگام ثبت ایونت، به GA4 منتقل نمیشود.
محدودیتهای فعلی Measurement Protocol
در یکی از مکالمات رسمی با تیم گوگل، تأیید شده که در حال حاضر MP از بازنویسی IP یا User Agent پشتیبانی نمیکند. این یک محدودیت جدی محسوب میشود و باعث شده این پروتکل تنها در سناریوهای بسیار ساده قابل استفاده باشد.
البته توصیه میشود که این موضوع را از طریق فرومها و منابع رسمی گوگل دنبال کنید. شاید در نسخههای بعدی، امکان ارسال IP یا مرورگر در MP فراهم شود. اما در مستندات رسمی GA4 هنوز هیچ اشارهای به این امکان نشده است.
تأثیر ناشناسسازی IP بر دقت موقعیت جغرافیایی
یکی دیگر از دلایل نمایش (not set) در اطلاعات جغرافیایی، مربوط به فعال بودن IP anonymization بهصورت پیشفرض در GA4 است.
این ویژگی باعث میشود رقم آخر آدرس IP کاربر به صفر تبدیل شود، که همین موضوع دقت شناسایی مکان کاربر را کاهش میدهد.
بهطور کلی، گوگل هنوز میتواند کشور کاربر را تشخیص دهد، اما جزئیات دقیقتر مانند استان یا شهر ممکن است ثبت نشود.
تغییر یا حذف IP در پیادهسازی سمت سرور (Server-side Tagging)
اگر از Server-side Tagging (SGTM) استفاده میکنید، باید بدانید که این سیستم میتواند:
- IP کاربر را حذف کند
- یا آن را به مقدار ثابتی مثل 0.0.0.0 بازنویسی کند
در چنین شرایطی، بهطور طبیعی اطلاعات موقعیت جغرافیایی در GA4 ثبت نخواهد شد.
نقش ابزارهایی مثل VPN و پراکسی در نمایش (not set)
در نهایت، نباید از نقش کاربران در این موضوع غافل شد. بسیاری از بازدیدکنندگان سایتها از VPN، پراکسی یا ابزارهای مخفیسازی IP استفاده میکنند. این ابزارها باعث میشوند IP واقعی کاربر قابل شناسایی نباشد و در نتیجه، Google Analytics نتواند محل دقیق کاربر را تشخیص دهد.
نتیجه؟ بله، مجدداً با (not set) مواجه خواهید شد.
در دنیای دیجیتال امروز، دادهها نقش کلیدی در تحلیل رفتار کاربران، بازاریابی هدفمند و بهبود تجربهی کاربری ایفا میکنند. اما همزمان با رشد نگرانیها درباره حریم خصوصی، دولتها در سراسر جهان قوانین سختگیرانهتری در حوزهی حفاظت از دادهها وضع کردهاند. در این میان، مفهومی به نام Consent Mode یا «حالت رضایت» بهعنوان راهکاری برای ایجاد تعادل بین نیاز به داده و احترام به حقوق کاربران ظهور کرده است.
Consent Mode دقیقاً چیست؟
Consent Mode یک چارچوب فنی است که به وبسایتها و اپلیکیشنها اجازه میدهد شیوهی جمعآوری دادهها را بر اساس رضایت کاربران تنظیم کنند. بهبیان سادهتر، این فناوری بهعنوان یک پل ارتباطی بین ابزارهای ردیابی و ترجیحات کاربران در زمینهی حریم خصوصی عمل میکند.
وقتی کاربر با بنر مربوط به کوکیها در یک وبسایت روبهرو میشود و تصمیم میگیرد که آیا کوکیها را بپذیرد، رد کند یا تنظیمات دلخواهش را اعمال کند، Consent Mode مطابق با انتخاب کاربر، رفتار ابزارهایی مانند گوگل آنالیتیکس یا اسکریپتهای تبلیغاتی را تنظیم میکند.
مثال عملی از عملکرد Consent Mode
فرض کنید کاربر با بنر کوکیها مواجه میشود و یکی از گزینههای زیر را انتخاب میکند:
- پذیرش کامل: دادهها بهطور کامل جمعآوری و پردازش میشوند.
- رد کامل: هیچ اطلاعات قابلشناساییای از کاربر ذخیره نمیشود، اما دادههای کلی و مدلسازیشده ممکن است همچنان قابل استفاده باشند.
- تنظیمات سفارشی: کاربر میتواند، برای مثال، با استفاده از ابزارهایی مانند Cookiebot، اجازه دهد فقط دادههای آماری جمعآوری شود و از تبلیغات شخصیسازیشده صرفنظر کند.
چنین تنظیماتی به سایتها کمک میکند در عین رعایت قوانین حریم خصوصی، همچنان بتوانند اطلاعات مفیدی درباره رفتار کلی کاربران کسب کنند.
چرا Consent Mode برای سایتهای ایرانی هم مهم است؟
هرچند ممکن است در حال حاضر در ایران قوانین سختگیرانهی حفاظت از دادهها مانند GDPR در اروپا اعمال نشود، اما رعایت استانداردهای جهانی در این حوزه، بهخصوص برای کسبوکارهایی که با کاربران خارج از کشور سروکار دارند، یک الزام حرفهای محسوب میشود. علاوه بر این، این رویکرد میتواند حس اعتماد بیشتری در کاربران داخلی ایجاد کند؛ بهویژه در شرایطی که نگرانیها درباره سوءاستفاده از اطلاعات شخصی رو به افزایش است.
حالت رضایت پیشرفته (Advanced Consent Mode) چیست؟
حالت رضایت پیشرفته یا همان Consent Mode نسخه ۲، نسخه بهروزرسانیشدهای از ابزار مدیریت رضایت کاربران گوگل است که به کسبوکارها امکان میدهد کنترل دقیقتری بر نحوه استفاده از دادههای کاربران داشته باشند.
نسخه اولیه چه ویژگیهایی داشت؟
در نسخه اول این ابزار (v1)، تمرکز اصلی روی دو پارامتر کلیدی بود:
analytics_storage
: مربوط به ذخیرهسازی دادههای تحلیلی (مثل کوکیهای Google Analytics)ad_storage
: مربوط به ذخیرهسازی دادههای تبلیغاتی (مثل کوکیهای Google Ads)
این نسخه به کسبوکارها اجازه میداد مشخص کنند که آیا مجاز به استفاده از کوکیهای تحلیلی و تبلیغاتی هستند یا نه.
چه چیزهایی در نسخه دوم (v2) تغییر کرده است؟
در نسخه دوم، دو پارامتر جدید به ابزار اضافه شدهاند که سطح کنترل و تطبیق با قوانین حریم خصوصی مناطق مختلف را بالاتر میبرد:
ad_user_data
: مشخص میکند که آیا دادههای شخصی کاربران میتوانند به گوگل ارسال شوند یا خیر، آن هم صرفاً برای اهداف تبلیغاتی.ad_personalization
: تعیین میکند که آیا این دادهها میتوانند برای نمایش تبلیغات شخصیسازیشده مورد استفاده قرار گیرند یا نه.
چرا این موضوع برای کسبوکارها مهم است؟
با توجه به افزایش قوانین حریم خصوصی مانند GDPR در اروپا یا حتی قوانین محلیتری که احتمال دارد در کشورهای مختلف از جمله ایران مطرح شوند، کسبوکارها باید بتوانند دقیقاً مشخص کنند که با چه نوع دادههایی و به چه نحوی رفتار میکنند.
استفاده از حالت رضایت پیشرفته به برندها کمک میکند تا هم قوانین را رعایت کنند و هم تبلیغات مؤثرتری ارائه دهند—بدون اینکه حریم خصوصی کاربران به خطر بیفتد.
جدول زمانی و سیر تحول Consent Mode
با افزایش فشارهای قانونی و مقرراتی در زمینه حفظ حریم خصوصی دادههای کاربران، ابزار Consent Mode به یک ضرورت برای کسبوکارهای آنلاین تبدیل شد.
در ادامه، روند شکلگیری و توسعه این ابزار را مرور میکنیم:
📅 ۲۵ مه ۲۰۱۸ – اجرای مقررات عمومی حفاظت از دادهها (GDPR) در اتحادیه اروپا
قانون GDPR از این تاریخ به اجرا درآمد و شرکتها را ملزم کرد تا پیش از جمعآوری یا پردازش اطلاعات شخصی کاربران، رضایت صریح آنها را دریافت کنند. این قانون نقطه آغاز نگاه سختگیرانهتر به حریم خصوصی در فضای دیجیتال بود.
📅 ۳ سپتامبر ۲۰۲۰ – معرفی ابزار Consent Mode توسط گوگل
گوگل از ابزار Consent Mode رونمایی کرد. این ابزار به وبسایتها امکان میدهد تا رفتار تگهای ردیابی گوگل را بر اساس نوع رضایت کاربر تنظیم کنند. به این معنا که اگر کاربر با ذخیرهسازی دادهها موافقت نکرده باشد، تگها بهصورت محدود و مطابق با قوانین اجرا میشوند.
📅 ۲ مه ۲۰۲۳ – تصویب قانون بازاریابی دیجیتال (DMA)
قانون جدیدی در اروپا به نام Digital Marketing Act (DMA) تصویب شد که با هدف ایجاد رقابت عادلانه در بازار دیجیتال و حفاظت از حقوق کاربران تدوین شده است. این قانون، شرکتهای بزرگ فناوری مثل گوگل (Alphabet)، آمازون، اپل، بایتدنس، متا و مایکروسافت را هدف قرار داده که تأثیر قابلتوجهی بر رفتار کاربران در پلتفرمهای آنلاین دارند.
📅 نوامبر ۲۰۲۳ – انتشار نسخه دوم Consent Mode توسط گوگل
گوگل نسخه جدیدی از ابزار خود را معرفی کرد که با عنوان Consent Mode v2 شناخته میشود. این نسخه بهگونهای طراحی شده که تطبیقپذیری بیشتری با الزامات قانونی در مناطق مختلف جهان داشته باشد و به کسبوکارها کمک کند تا راحتتر با مقررات هماهنگ شوند.
📅 ۶ مارس ۲۰۲۴ – اجباری شدن نسخه دوم در کشورهای اروپایی و بریتانیا
از این تاریخ، استفاده از Consent Mode v2 برای تمامی وبسایتهایی که از خدمات گوگل استفاده میکنند، در منطقه اقتصادی اروپا (EEA) و بریتانیا الزامی شد.
📅 ۳۱ ژوئیه ۲۰۲۴ – اضافه شدن سوئیس به لیست کشورهای مشمول
از پایان ژوئیه ۲۰۲۴، اجرای اجباری نسخه دوم Consent Mode در کشور سوئیس نیز آغاز شد.
🔮 آینده نزدیک – گسترش به سایر کشورها از جمله آمریکا
بر اساس روند موجود، انتظار میرود این الزامات بهزودی به کشورهای دیگری از جمله ایالات متحده آمریکا نیز تعمیم پیدا کند.
چرا «حالت رضایت کاربر» (Consent Mode) ایجاد شد؟
با افزایش سختگیری قوانین حریم خصوصی در سطح جهانی، شرکتها به راهکاری نیاز داشتند که هم بتوانند اطلاعات مفیدی از رفتار کاربران جمعآوری کنند و هم الزامات قانونی را رعایت کنند. در همین راستا، حالت رضایت کاربر یا Consent Mode طراحی شد تا این تعادل حساس را برقرار کند.
۱. قوانین سختگیرانهتر حریم خصوصی
قوانینی مانند GDPR (قانون حفاظت از دادههای اتحادیه اروپا) و CCPA (قانون حریم خصوصی مصرفکننده در کالیفرنیا) به وبسایتها الزام میکنند که پیش از ردیابی کاربران، از آنها رضایت بگیرند. دیگر دوران نصب کوکیها بدون اطلاع کاربر تمام شده است.
۲. آگاهی روزافزون کاربران
کاربران حالا بیش از گذشته نسبت به جمعآوری و استفاده از دادههایشان حساس شدهاند. در ایران هم، با افزایش استفاده از ابزارهای ضد ردیابی و افزونههای مرورگر، این موضوع به دغدغهای جدی تبدیل شده است. بنابراین برندها مجبورند شفافتر و مسئولانهتر عمل کنند.
۳. آمادگی برای دنیای بدون کوکی
با محدود شدن استفاده از کوکیهای شخص ثالث، شرکتها باید به دنبال روشهای جایگزین برای تحلیل رفتار کاربران باشند. حالت رضایت کاربر این امکان را فراهم میکند تا بدون نیاز به ردیابی مستقیم و مزاحم، اطلاعات کلیدی بهدست بیاید.
۴. حفظ امکان تحلیل رفتار کاربر حتی بدون رضایت
یکی از ویژگیهای مهم Consent Mode این است که حتی اگر کاربر با ردیابی موافقت نکند، سیستم میتواند با استفاده از دادههای مدلسازیشده یا ناشناس، همچنان دید کلی از عملکرد کمپینها ارائه دهد. این یعنی کسبوکارها دچار «کور شدن دادهای» نمیشوند.
نحوه عملکرد “Consent Mode” (حالت رضایت)
“حالت رضایت” یا Consent Mode با استفاده از پارامترهای رضایت، مشخص میکند که چه نوع دادههایی مجاز به ذخیرهسازی هستند. تعداد و نام این پارامترها ممکن است بسته به پلتفرمی که این حالت روی آن استفاده میشود، متفاوت باشد.
مقدار پیشفرض رضایت کاربر: عدم تأیید
زمانی که کاربر برای اولینبار وارد وبسایت میشود، بهصورت پیشفرض تمامی پارامترهای رضایت روی گزینه «رد شده» (denied) تنظیم میشوند. اگر کاربر از طریق بنر رضایتگیری سایت، اجازه دسترسی بدهد، این مقادیر به حالت «تأیید شده» (granted) تغییر میکنند.
رفتار تگهای رهگیری در صورت دریافت یا عدم دریافت رضایت
در صورتی که کاربر رضایت کامل بدهد، تگهای رهگیری مانند حالت عادی خود عمل میکنند و اطلاعات را ذخیره یا منتقل میکنند. اما اگر کاربر رضایت ندهد، رفتار این تگها به صورت زیر تغییر میکند:
- به جای استفاده از کوکیهای شخص ثالث (third-party cookies)، پلتفرم از سیگنالهای ناشناس (anonymous pings) استفاده میکند تا میزان بازدید و ترافیک را بهصورت تقریبی تخمین بزند.
- به جای ذخیرهسازی دادههای دقیق، از مدلسازی تبدیل (conversion modeling) استفاده میشود تا روندهای رفتاری کاربران را بدون نقض قوانین حریم خصوصی بررسی کند.
توازن بین حریم خصوصی و تحلیل داده
این روش به کسبوکارها کمک میکند تا در عین پایبندی به قوانین حریم خصوصی (مانند GDPR)، همچنان بتوانند از ابزارهای تحلیلی و بازاریابی خود—البته بهصورت محدودتر—استفاده کنند. به بیان ساده، کارایی ابزارهای دیجیتال حفظ میشود بدون آنکه حریم خصوصی کاربران قربانی شود.
مزایای کلیدی استفاده از حالت رضایت (Consent Mode)
استفاده از حالت رضایت در وبسایتها، مزایای قابل توجهی برای کسبوکارهای آنلاین به همراه دارد. در ادامه، به مهمترین دلایلی که صاحبان سایتها باید این قابلیت را جدی بگیرند، میپردازیم:
۱. تطابق با قوانین حفظ حریم خصوصی
با تنظیم جمعآوری دادهها بر اساس رضایت کاربران، وبسایتها میتوانند از جریمهها و مشکلات قانونی ناشی از نقض قوانین بینالمللی مانند GDPR (اروپا)، CCPA (کالیفرنیا) و مقررات مشابه دیگر در امان بمانند. این یعنی خیال راحت از بابت چالشهای حقوقی احتمالی در آینده راحت خواهد بود.
۲. افزایش اعتماد کاربران
امروزه کاربران نسبت به حفظ حریم خصوصیشان حساستر شدهاند. وبسایتهایی که شفاف عمل میکنند و به انتخاب کاربر احترام میگذارند، بهمرور زمان اعتماد بیشتری جلب میکنند. این اعتماد میتواند به افزایش ماندگاری کاربر در سایت و تعامل بیشتر با محتوا منجر شود.
۳. حفظ بخشی از دادههای تحلیلی
در شرایطی که کاربر رضایت خود را برای استفاده از کوکیها اعلام نمیکند، هنوز هم امکان جمعآوری دادههای ناشناس و غیرقابل شناسایی وجود دارد. این دادهها به وبسایتها کمک میکنند تا بدون نقض حریم خصوصی، بتوانند عملکرد سایت را تحلیل و بهبود دهند.
۴. آمادهسازی برای آیندهای بدون کوکیهای شخص ثالث
با توجه به اینکه مرورگرها بهتدریج در حال محدود کردن کوکیهای شخص ثالث هستند و قوانین حریم خصوصی نیز سختگیرانهتر میشوند، استفاده از حالت رضایت بهعنوان یک راهکار پایدار و آیندهنگرانه مطرح است. این مدل، به کسبوکارها کمک میکند که همچنان دادههای ضروری خود را برای تبلیغات و تحلیل رفتار کاربران جمعآوری کنند، بدون آنکه وارد حریم خصوصی کاربران شوند.
انواع حالت رضایت (Consent Mode)
حالت رضایت (Consent Mode) بسته به پلتفرمی که در آن استفاده میشود، کمی تفاوت دارد. در حال حاضر، دو نوع اصلی از این قابلیت وجود دارد:
حالت رضایت گوگل (Google Consent Mode)
این نسخه که توسط گوگل توسعه داده شده، امکاناتی نظیر ارسال داده بدون استفاده از کوکی (cookieless pings) و تبدیلهای مدلسازیشده (modeled conversions) را پشتیبانی میکند. این حالت با ابزارهای متنوعی از جمله Google Analytics، Google Ads، Google Tag Manager و همچنین Floodlight همخوانی دارد.
برای مثال، اگر وبسایتی از Google Analytics استفاده کند و کاربر اجازه ذخیره کوکیها را ندهد، این حالت کمک میکند تا همچنان اطلاعاتی پایهای از رفتار کاربر دریافت شود، بدون نقض حریم خصوصی او.
حالت رضایت مایکروسافت (Microsoft Consent Mode)
مایکروسافت نیز نسخهای از Consent Mode را برای پلتفرم تبلیغاتی خود – که پیشتر با نام Bing Ads شناخته میشد و اکنون Microsoft Advertising نام دارد – ارائه داده است. این نسخه، مشابه با مدل گوگل، به ترجیحات کاربران در زمینه حریم خصوصی احترام میگذارد و در چارچوب استانداردهای جدید تبلیغات مبتنی بر رضایت کاربر عمل میکند.
استفاده از این حالت در وبسایتهایی که از تبلیغات مایکروسافت بهره میبرند، به کسبوکارها اجازه میدهد تا عملکرد تبلیغات را بدون زیر پا گذاشتن تنظیمات حریم خصوصی کاربران، پایش و تحلیل کنند.
چگونه «Consent Mode» را فعال کنیم؟
روش بهینه برای پیادهسازی Consent Mode (حالت رضایت کاربران) بستگی به زیرساخت وبسایت شما دارد. در ادامه، رایجترین و مطمئنترین روشهای اجرای این قابلیت را مرور میکنیم.
۱. استفاده از پلتفرم مدیریت رضایت کاربران (CMP)
سادهترین و قابل اعتمادترین روش برای فعالسازی Consent Mode، استفاده از یک CMP تأییدشده توسط گوگل است؛ برای مثال پلتفرمی مانند Cookiebot که بهصورت پیشفرض از این قابلیت پشتیبانی میکند.
💡 قبل از هر چیز بررسی کنید که CMP مورد استفادهی شما در لیست تأییدشدههای گوگل باشد.
این ابزارها تمامی مراحل مدیریت رضایت کاربران را پوشش میدهند—از طراحی بنر اطلاعرسانی گرفته تا ثبت و ذخیرهی رضایت کاربران—و بهصورت خودکار سیگنالهای رضایت را به سیستم ارسال میکنند. به این ترتیب، هم در وقت صرفهجویی میکنید و هم احتمال خطا یا تنظیمات اشتباه به حداقل میرسد.
۲. پیادهسازی دستی از طریق Google Tag Manager یا gtag.js
اگر از CMP استفاده نمیکنید، امکان اجرای دستی Consent Mode نیز وجود دارد. برای این کار میتوانید از گوگل تگ منیجر یا اسکریپت gtag.js بهره بگیرید.
در این روش، شما باید ابتدا تنظیمات پیشفرض رضایت را مشخص کنید، سپس براساس انتخاب کاربران آنها را بهروزرسانی کرده و نهایتاً رفتار تگهای خود را بر اساس این انتخابها تنظیم نمایید.
این مدل پیادهسازی، آزادی و کنترل کامل در اختیارتان میگذارد؛ اما از سوی دیگر نیازمند دانش فنی بیشتر است و در صورت اجرای نادرست، میتواند به خطاهای عملکردی منجر شود.
با معرفی نسخه دوم «حالت رضایت کاربران» گوگل (Google Consent Mode v2) در مارس ۲۰۲۴، حالا این امکان وجود دارد که هم با قوانین حریم خصوصی تطبیق داشته باشید و هم بتوانید رفتار کاربران را ردیابی کرده و کمپینهای تبلیغاتی خود را بهینهسازی کنید—البته اگر تنظیمات بهدرستی انجام شده باشد.
در این مطلب، با هم بررسی میکنیم که چگونه میتوانید مطمئن شوید Consent Mode روی سایت شما فعال است و بهدرستی کار میکند.
بررسی وضعیت Consent Mode در Google Ads
ابتدا وارد حساب Google Ads خود شوید و به مسیر زیر بروید:
Tools and Settings > Measurement > Conversions > Diagnostics
در این بخش، میتوانید وضعیت Consent Mode را مشاهده کنید. اگر پیامی با مضمون زیر نمایش داده شود:
Your consent mode is active!
یعنی گوگل با موفقیت وضعیت رضایت کاربران را خوانده و ثبت میکند.
این مرحله برای اطمینان از عملکرد صحیح Consent Mode در Google Ads بسیار حیاتی است. فقط به این نکته توجه داشته باشید که اطلاعات این بخش بهصورت لحظهای (real-time) نمایش داده نمیشود؛ بنابراین اگر بهتازگی این قابلیت را فعال کردهاید یا تغییری در آن ایجاد کردهاید، باید کمی صبر کنید تا وضعیت بهروزرسانی شود.
بررسی وضعیت Consent Mode در Google Analytics 4
در Google Analytics 4 نیز امکان بررسی وضعیت Consent Mode وجود دارد. گوگل در حال حاضر یک گزارش اختصاصی جدید برای این منظور ارائه داده است. بسته به نسخهای که در حساب شما فعال است، با یکی از دو حالت زیر روبهرو خواهید شد:
نسخه قدیمی گزارش Consent
در صورتی که همچنان از نسخه قدیمی استفاده میکنید، مراحل زیر را دنبال کنید:
- به قسمت Admin بروید.
- وارد Property Settings شوید.
- گزینه Data Collection and Modification را انتخاب کنید.
- وارد Data Streams شده و استریم مربوط به وبسایتتان را انتخاب کنید.
- در بخش Consent Settings، بررسی کنید که آیا علامت تیک سبز در کنار گزینههای زیر وجود دارد یا خیر:
- Ads measurement consent signals active
- Ads personalization consent signals active
اگر هر دو مورد فعال باشند، یعنی تنظیمات بهدرستی انجام شده است.
نسخه جدید گزارش Consent
گوگل در حال عرضه نسخه جدید گزارش Consent است که جایگزین نسخه قبلی خواهد شد. در این نسخه جدید، برای بررسی وضعیت:
- وارد Admin شوید.
- به Property Settings بروید.
- گزینه Data Collection and Modification را انتخاب کنید.
- سپس روی Consent Settings کلیک کنید.
اگر همه چیز درست پیکربندی شده باشد، پیامی مانند زیر نمایش داده خواهد شد:
“All consent signals are active on this property”
و محتوایی مشابه تصویر زیر را نیز مشاهده خواهید کرد.
بررسی وضعیت Consent Mode با استفاده از Google Tag Manager
برای شروع، ابتدا حالت پیشنمایش (Preview Mode) را در Google Tag Manager فعال کنید. سپس از نوار کناری، رویدادی را که برای اجرای تگ (Tag) استفاده شده انتخاب کرده و روی تب Consent کلیک کنید.
بیشتر بخوانید: علت کار نکردن حالت پیش نمایش در گوگل تگ منیجر
در این بخش، میتوانید بهصورت لحظهای وضعیت بهروزرسانی رضایت کاربران (Consent Status) را بر اساس تنظیماتی که در پنجره اصلی پیشنمایش اعمال کردهاید، مشاهده کنید.
اگر تنظیماتی که در پنجره اصلی Preview انتخاب کردهاید با اطلاعات نمایشدادهشده در تب Consent همخوانی نداشته باشد، این موضوع نشاندهنده آن است که بنر دریافت رضایت کاربران (Consent Banner) بهدرستی کار نمیکند یا بهدرستی پیکربندی نشده است.
بررسی فعال بودن «Consent Mode» با افزونه Google Tag Assistant
اگر از افزونه Google Tag Assistant در مرورگر کروم استفاده میکنید، خیلی راحت میتونید مطمئن بشید که Consent Mode بهدرستی فعال شده.
وارد تگ مربوط به Google Tag Manager بشید، به تب Data Layer برید و تا بخش Consent: Update event اسکرول کنید.
نکته مهم: قبل از بررسی، حتماً صفحه رو رفِرش کنید و تنظیمات (Consent) را طبق ترجیحاتتان انتخاب کنید. بعد از اون میتونید وضعیت فعال بودن Consent Mode را در افزونه ببینید.
افزونههای کروم برای بررسی تنظیمات Consent Mode
برای آنهایی که دنبال یه روش ساده و بدون دردسر برای بررسی Consent Mode هستند، چندین افزونه کروم وجود دارد که بدون نیاز به دانش فنی خاص، این کار رو انجام میدهند.
یکی از افزونههای کاربردی، Consent Mode Inspector ساختهی شرکت InfoTrust هست.
این افزونه سبک و ساده، اطلاعات لحظهای (real-time) از تنظیمات اصلی Consent Mode ارائه میدهد و شما میتوانید خیلی راحت متوجه شوید که سیگنالهای رضایت (Consent Signals) به درستی ارسال میشوند یا نه.
بررسی تنظیمات Consent Mode با Cookiebot
اگه از Cookiebot بهعنوان سیستم مدیریت رضایتنامه (CMP) استفاده میکنید، ابزار اختصاصی Google Consent Mode Checker داخل پنل مدیریتی Cookiebot، یک راه سریع برای بررسی تنظیمات شماست.
این ابزار، دامنهی شما رو اسکن میکند و اگر مشکلی در پیادهسازی Consent Mode وجود داشته باشد، گزارش دقیقی قرار میدهد.
مراحل استفاده:
- وارد پنل ادمین Cookiebot بشید
- به بخش Domains and Aliases برید
- دامنهی موردنظر رو انتخاب کنید
- به قسمت Google Consent Mode Check اسکرول کنید
- روی دکمه Start GCM check کلیک کنید تا اسکن شروع بشه
این بررسی معمولاً بین ۱۰ تا ۱۵ ثانیه زمان میبرد و نتیجهی آن درست زیر دکمه نمایش داده میشود. گزارش تا ۳۰ روز در دسترس باقی می ماند، و هر زمان تغییر جدیدی اعمال کردید، میتوانید اسکن رو دوباره انجام بدید.
اگه با CMP فعلیتون به مشکل خوردید، میتونید به Cookiebot مهاجرت کنید. این ابزار مورد تأیید گوگل هست و فعالسازی Consent Mode در اون فقط با یک کلیک ساده در افزونه وردپرس یا Google Tag Manager انجام میشود.
بررسی فعال بودن Consent Mode در مرورگر Chrome (بدون نیاز به ابزار اضافه)
گاهی برای بررسی فعال بودن Consent Mode (حالت رضایت کاربر) در سایتتان، نیازی به ابزار خاصی نیست. با استفاده از خود مرورگر Google Chrome میتوانید این موضوع را بررسی کنید.
مراحل بررسی در حالت ناشناس (Incognito):
- وارد سایت مورد نظر شوید، اما حتماً با استفاده از Incognito Mode مرورگر کروم.
- با بنر رضایت (Consent Banner) تعامل داشته باشید.
- ابزار توسعهدهنده (Developer Tools) را فعال کنید: کلیک راست روی صفحه > گزینه Inspect یا فشردن کلید F12.
- وارد تب Console شوید.
- عبارت
dataLayer
را تایپ کرده و Enter بزنید.
در این مرحله، اگر با بنر رضایت تعامل کرده باشید، باید دو رویداد (Event) در dataLayer ثبت شده باشد:
- رویداد اولیه (Default Consent Event): نشاندهنده تنظیمات پیشفرض رضایت هنگام اولین بار باز شدن سایت است.
- رویداد بهروزرسانی (Update Consent Event): تنظیمات بهروزشده رضایت پس از تعامل کاربر با بنر را نمایش میدهد.
برای بررسی دقیقتر، روی فلش کنار رویداد Update کلیک کنید تا مقدار پارامترهای مختلف رضایت را مشاهده کنید و مطمئن شوید با تنظیماتی که انتخاب کردید هماهنگ هستند.
بررسی سریع Consent Mode با استفاده از بوکمارک در Chrome
آیا میدانستید میتوانید از جاوااسکریپت بهعنوان URL یک بوکمارک استفاده کنید؟ با این روش میتوان بهسادگی وضعیت Consent Mode را بررسی کرد.
مراحل انجام کار:
- یک بوکمارک جدید در Chrome بسازید.
- کد جاوااسکریپت زیر را بهعنوان URL آن وارد کنید:
javascript: (() => {
let l = s => s === undefined ? "" : s ? "granted" : "denied";
if (!window["google_tag_data"]) {
alert("No Consent Mode data found");
return;
}
var g = "ics" in google_tag_data ? google_tag_data.ics.entries : null;
let i = "",
u = "",
message = "";
for (var a in g) {
i = l(g[a][ % 27
default % 27
]);
u = l(g[a][ % 27 update % 27]);
if (i === "" && u === "") continue;
message += a.toUpperCase() + ":\n" + (i !== "" ? " Default: " + i + "\n" : "") + (u !== "" ? " Update: " + u : "") + "\n";
}
if (message === "") {
alert("No default Consent settings found");
} else {
let foundAdStorage = false,
foundAnalyticsStorage = false,
foundAdUserData = false,
foundAdPersonalization = false;
for (var a in g) {
if (a === "ad_storage") {
foundAdStorage = true;
} else if (a === "analytics_storage") {
foundAnalyticsStorage = true;
} else if (a === "ad_user_data") {
foundAdUserData = true;
} else if (a === "ad_personalization") {
foundAdPersonalization = true;
}
}
if (foundAdStorage && foundAnalyticsStorage) {
message += "\n**Consent Mode v2 detected**";
} else if ((foundAdStorage || foundAnalyticsStorage) && !(foundAdUserData || foundAdPersonalization)) {
message += "\n**Consent Mode v1 detected**";
}
alert(message.trim());
}
})();
پس از ذخیره بوکمارک، فقط کافیست در هر سایتی روی آن کلیک کنید. پنجرهای باز میشود که وضعیت پارامترهای رضایت کاربر را نشان میدهد. اگر پارامترهای خاصی مانند ad_storage
و analytics_storage
وجود داشته باشند، سیستم به شما اطلاع میدهد که Consent Mode نسخه ۲ فعال است.
با استفاده از این روشها، میتوانید مطمئن شوید که Consent Mode نسخه ۲ بهدرستی روی سایت شما پیادهسازی شده است. برخی روشها ساده و قابل استفاده برای همه کاربران هستند، در حالی که برخی دیگر نیاز به دانش فنی بیشتری دارند. روش مناسب با نیاز و سطح تخصصتان را انتخاب کنید تا مطابق با قوانین حریم خصوصی عمل کنید.
عبارت “(اطلاعات در دسترس نیست)” یا “(data not available)” زمانی در گزارشهای Google Analytics 4 (GA4) ظاهر میشود که دادهها برای برخی از دایمنشن مانند منبع ترافیک (Source) یا رسانه ترافیک (Medium) در دسترس نباشند یا هنوز پردازش نشده باشند. قبلا این داده ها در بخش Direct یا Unassigned نمایش داده می شدند. این پیغام یک چالش جدید نیست بلکه یک شیوه جدید برای اعلام برخی از مشکلات در دیتاهای شما است.
این وضعیت بهویژه در بازههای روزانه (Intraday) بیشتر مشاهده میشود، زیرا در این بازهها فرصت کمتری برای پردازش کامل دادهها نسبت به بازههای روزانه (Daily) وجود دارد. لازم به ذکر است که دادههای مربوط به رویدادها (Event-level data) میتوانند تا ۱۲ روز بعد، بهروزرسانی شده و مدلسازیهای جدید به بهبود کیفیت آنها کمک کنند؛ اما دادههای مربوط به کاربران (User-level) یا سشنها (Session-level) شامل این بهروزرسانی نخواهند شد.
دلایل اصلی نمایش عبارت “(data not available)” در گزارشهای GA4
۱. زمان پردازش دادهها
در بسیاری از موارد، این عبارت زمانی نمایش داده میشود که مقادیر مربوط به دایمنشن سورس یا همان منبع ترافیک هنوز مشخص نشدهاند. این موضوع به دلیل زمانبر بودن فرآیندهای تحلیل و اتریبیوشن منبع ترافیک است. در چنین شرایطی، دادههای سطح ایونت ممکن است بعداً بهروزرسانی شوند.
۲. تخصیص نادرست یوزر آیدی کاربر (User ID)
یکی دیگر از دلایل متداول، اختصاص نادرست یا بیشازحد یکسان User ID به ایونت های مختلف است. این مشکل معمولاً زمانی رخ میدهد که به اشتباه از یک یوزر آیدی عمومی یا از پیش تعریفشده (Canned User ID) برای همه کاربران استفاده شود. در این حالت، GA4 همه این کاربران را بهعنوان یک کاربر واحد در نظر میگیرد و ترافیک آنها را به کانال «مستقیم» (Direct) نسبت میدهد. این موضوع میتواند باعث بروز خطا در تعداد کاربران و گزارشهای دیگر شود.
۳. عدم موفقیت در پردازش دادهها
در برخی موارد نادر، مشکلات سیستمی ممکن است مانع از استخراج دایمنشن های مربوط به شناسه تبلیغاتی (Advertising ID) شوند. در این صورت، عبارت “(اطلاعات در دسترس نیست)” برای آن داده نمایش داده میشود.
تفاوت not set و data not available در آنالیتیکس
ویژگی | اطلاعات موجود نیست (data not available) | تنظیم نشده (not set) |
---|---|---|
کاربرد عمومی | زمانی نمایش داده میشود که گوگل اطلاعات مربوط به یک دایمنشن را دریافت کرده اما هنوز پردازش نکرده است. | زمانی نمایش داده میشود که گوگل اصلاً اطلاعاتی در مورد یک دایمنشن دریافت نکرده باشد. |
دایمنشنهای قابل اعمال | دایمنشنهای مربوط به منبع و رسانه ترافیک (source و medium) | قابل مشاهده در تمام دایمنشنها |
امکان اقدام اصلاحی توسط کاربر | خیر، معمولاً تحت کنترل کاربر نیست. | بله، معمولاً با بررسی تنظیمات یا پیکربندی تگ ها (tagging) میتوان مشکل را برطرف کرد. |
آیا گوگل بعداً مقدار را بهروزرسانی میکند؟ | در دادههای سطح رویداد (event-level)، بله | معمولاً خیر. |
دلایل رایج | تأخیر در پردازش دادهها | تنظیمات اشتباه یا خطا در پیکربندی برچسبها (tags) |
جمعبندی
عبارت “(اطلاعات در دسترس نیست)” لزوماً نشاندهنده مشکلی در عملکرد GA4 نیست، بلکه میتواند نشانهای از پردازش در حال انجام یا تنظیمات نادرست باشد. شناخت دلایل آن به تحلیل بهتر دادهها و بهینهسازی تنظیمات کمک خواهد کرد.
آیا با مشکل عدم نمایش ایونتهای Google Analytics 4 در گزارشهای خود مواجه هستید؟ یا شاید ایونتها نمایش داده میشوند، اما اطلاعات کلیدی مانند نام محصول یا دستهبندی آنها ناقص است؟ این مسئلهای رایج است که بسیاری از کاربران با آن روبرو میشوند. در این مقاله، به بررسی علل احتمالی این مشکل و ارائه راهکارهای مؤثر برای رفع آن میپردازیم. اگر به دنبال پاسخ این سوال هستید که “چرا Google Analytics من هیچ دادهای را نشان نمیدهد؟“، در ادامه با ما همراه باشید.
هدف این مقاله، ارائه راهنمایی جامع و کاربردی برای عیبیابی و رفع مشکل عدم نمایش ایونتها در گزارشهای Google Analytics 4 است. در بخشهای آتی، به تفصیل به دلایل رایج بروز این مشکل و راهکارهای عملی برای حل آنها خواهیم پرداخت.
دلایل عدم نمایش ایونت در آنالیتیکس
۱. ناکافی بودن زمان پردازش
گزارشهای Google Analytics (به جز گزارشهای Real-time و DebugView) برای پردازش و نمایش دادهها به زمان قابل توجهی نیاز دارند. معمولاً ۲۴ تا ۴۸ ساعت زمان برای پردازش دادهها مورد نیاز است.
بنابراین، اگر ایونتهای جدیدی برای GA4 ارسال کردهاید و فقط چند ساعت منتظر ماندهاید، این زمان کافی نیست. دادههای خود را روز بعد بررسی کنید. اگر همچنان مشکلی وجود داشت، یک روز دیگر نیز صبر کنید. در صورتی که پس از این مدت همچنان ایونتها نمایش داده نشدند، احتمالاً مشکل دیگری در تنظیمات GA4 وجود دارد که در ادامه به بررسی آنها میپردازیم.
۲. محدودیت داده (Data Thresholding)
در بالای گزارش استاندارد یا گزارشی که در بخش Exploration GA4 باز کردهاید، به دنبال علامت تیک سبز رنگ باشید. اگر این علامت را مشاهده کردید، محدودیت داده اعمال نشده است و میتوانید به بخش بعدی این مقاله مراجعه کنید.
در غیر این صورت، اگر علامت تعجب نارنجی رنگ را مشاهده میکنید، روی آن کلیک کنید. آیا در هشدار نمایش داده شده، به محدودیتی در داده ها اشاره دارد؟ در صورت تأیید، احتمالاً دلیل عدم نمایش برخی ایونتها مشخص شده است.
به طور خلاصه، زمانی که محدودیتی در داده ها اعمال میشود، Google Analytics 4 ردیفهایی با تعداد دادهی کم را پنهان میکند. تعداد دقیق این دادهها مشخص نیست، اما به نظر میرسد که کمتر از ۵۰ کاربر یا ایونت در هر ردیف باشد.
بنابراین، اگر تعداد ایونتهای ردیابی شده توسط شما کم باشد، این محدودیت اعمال می شود و ایونتها از گزارشها پنهان میشوند. نگران نباشید، دادهها از بین نرفتهاند، بلکه فقط نمایش داده نمیشوند.
معمولاً، محدودیت داده زمانی اعمال میشود که گزارش شما از دادههای جمعیتشناختی مانند سن یا جنسیت استفاده میکند. در صورت حذف این فیلترها از گزارش، تمامی ردیفها (حتی ردیفهایی با تعداد دادهی کم) مجدداً نمایش داده میشوند. ممکن است ایونت مورد نظر شما نیز در میان این دادهها باشد.
۳. انتخاب بازه زمانی اشتباه
همه ما انسان هستیم و گاهی اشتباه میکنیم. توصیه میکنم دوباره بررسی کنید که محدوده تاریخ صحیح را در گزارشهای خود انتخاب کرده باشید. شاید به تاریخی نگاه میکنید که ایونت مورد نظر هنوز پیاده سازی نشده بود.
شما میتوانید محدوده تاریخ را در گوشه سمت چپ بالا (در بخش Explorations) یا در گوشه سمت راست بالا (در گزارشهای استاندارد GA4) تغییر دهید.
۴. فعال کردن فیلتر ترافیک داخلی
در Google Analytics 4، میتوانید ترافیک داخلی خود (ترافیکی که از کارمندان/همکاران شما میآید) را حذف کنید. این ویژگی، آدرس IP بازدیدکننده را بررسی میکند و اگر با قوانین ترافیک داخلی/توسعهدهنده مطابقت داشته باشد، ایونتهای شما حذف میشوند. اما همین موضوع میتواند دلیل عدم نمایش ایونتهای شما در گزارشها باشد.
اولین جایی که باید بررسی کنید، رفتن به بخش Admin > Data settings > Data filters است. اگر در کنار فیلترهای “Internal” و “Developer” کلمه “Active” را مشاهده کردید، این میتواند دلیل آن باشد.
اما هنوز کار تمام نشده است. در پنل Admin، به بخش Data Streams > روی وب استریم خود کلیک کنید > Configure Tag Settings > Show All > Define internal traffic بروید.
این کار لیستی از قوانینی را که ترافیک داخلی/توسعهدهنده را تعریف میکنند، باز میکند.
اگر هیچ قانونی مشاهده نمیکنید، ایونتهای GA4 شما به دلیل دیگری نمایش داده نمیشوند (در این صورت، به خواندن این مطلب ادامه دهید).
اگر قوانینی را مشاهده میکنید، روی آنها کلیک کنید و ببینید چه آدرسهای IP در آنجا تعیین شدهاند. اگر یکی از آنها متعلق به شما باشد، ممکن است به همین دلیل ایونتهای خود را در گزارشهای GA4 نمیبینید.
۵. تنظیمات بخش Modify events
Google Analytics 4 به شما این امکان را میدهد که ایونتهای ورودی را مستقیماً از رابط GA4 تغییر دهید. برای مثال، میتوانید یک پارامتر خاص از ایونت را اضافه، ویرایش یا حذف کنید. یا حتی میتوانید نام ایونت را تغییر دهید. شاید مشکل شما هم همین باشد.
در Google Analytics 4، به بخش Admin > Events > Modify Event بروید.
اگر لیست خالی را مشاهده کردید، پس مشکل شما از “Modify events” نیست. اما اگر قوانینی را مشاهده کردید، روی هر کدام به صورت جداگانه کلیک کنید و ببینید چه کاری انجام میدهند.
۶. تأخیر زیاد در گزارشEvents در Admin
گاهی اوقات، با مشکلی مواجه میشویم که (به دلایلی نامعلوم) لیست ایونتها در پنل مدیریت GA4 از سایر گزارشهای Google Analytics عقب میماند. منظورم گزارش های مربوط به ایونت در بخش ادمین آنالیتیکس است.
گاهی اوقات، این لیست ایونتهای خاص را برای چند روز نشان نمیدهد (حتی اگر سایر گزارشها، مانند Reports > Engagement > Events به درستی کار کنند).
بنابراین، توصیه من این است که به لیست Admin > Events کاملاً اتکا نکنید. در عوض، مکانهای دیگر را برای بررسی ایونتها چک کنید:
- Reports > Engagement > Events
- یا یک Free form exploration بسازید (با Event name به عنوان بُعد اصلی و Event count به عنوان معیار).
اگر ایونت مورد نظر خود را در این بخشها مشاهده کردید، مشکلی وجود ندارد.
آموزش گوگل تگ منیجر
نصب گوگل تگ منیجر، اولین قدمی است که برای بهرهمندی از مزایای این ابزار دیجیتال مارکتینگ باید بردارید. بنابراین اگر قصد دارید مدیریت تگهای مورد نیاز جهت انجام فعالیتهای بازاریابی به عهده خودتان باشد و در سریعترین زمان انواع ترکینگ کدها را در سایت قرار دهید و ایونتهای جدید تعریف یا ویرایش کنید؛ در ادامه این مطلب همراه من باشید.
همانطور که در مقاله گوگل تگ منیجر چیست بیان شد؛ GTM به شما کمک میکند تا بدون نیاز به یک دولوپر یا توسعه دهنده، انواع ترکینگ کدها را در سایت قرار دهید و ویرایش کنید. در این راهنما، نحوه نصب صحیح Google Tag Manager را در وب سایت خود توضیح خواهم داد.
مراحل نصب گوگل تگ منیجر؛ آموزش تصویری
مرحله اول: وارد حساب Google خود شوید
برای نصب گوگل تگ منیجر، باید وارد آدرس tagmanager.google.com. شوید و از طریق حساب کاربری گوگل خود یک اکانت تگ منیجر بسازید و وارد آن شوید. لطفا توجه داشته باشید که برای استفاده از ابزارهایی مانند GTM و آنالیتیکس، به یک حساب گوگل نیاز خواهید داشت.
مرحله دوم: اکانت و کانتینر تگ منیجر ایجاد کنید
روی گزینه Create Account کلیک کنید. تنظیمات حساب تگ منیجر را مشابه با آنالیتیکس، میتوانید در دو سطح انجام دهید؛ سطح اکانت و سطح کانتینر (Container). شما میتوانید چندین اکانت و در هر اکانت، میتوانید چندین کانتینر داشته باشید.
کانتینر در گوگل تگ منیجر، مرکزی است که تمام قطعه کدهای قرار داده شده در سایت از طریق GTM را در خود نگه میدارد.
نکته مهم: در انتخاب نام اکانت و کانتینر تگ منیجر، دقت کنید. بهتر است نام هر دو را مرتبط با کسب و کار و یا آدرس سایت انتخاب کنید.
نام اکانت را وارد کرده و سپس کشور را از طریق منوی کشویی، انتخاب کنید. با انتخاب چک باکس، دیتاهای خود به صورت ناشناس در اختیار گوگل قرار میدهید تا همراه با هزاران دیتای دیگر، در فرایند بنچمارک، مورد استفاده قرار گیرد.
بعد از انجام تنظیمات مربوط به اکانت، میتوانید اسم کانتینر و پلتفرم که قصد نصب گوگل تگ منیجر روی آن را دارید، انتخاب کنید. در این مرحله میتوانید آدرس سایت را به عنوان اسم کانتینر انتخاب کنید. سپس روی گزینه Create کلیک کنید.
در مرحله بعد، قوانین و شرایط استفاده از این ابزار نمایش داده میشود؛ باید آنها را بپذیرید و روی Yes کلیک کنید. بعد از انجام این کار، اکانت گوگل تگ منیجر به همراه یک کانتینر، ساخته میشود.
در مرحله بعد، پیامی حاوی کدهای مخصوص برای نصب گوگل تگ منیجر به شما نمایش داده میشود. اگر به هر دلیلی این پیغام را نمیبیند؛ میتوانید از طریق Google Tag Manager ID، در بالای صفحه و کنار (Workspace Changes: )، به آن دسترسی داشته باشید.
توجه: برای دسترسی به کدهای مورد نیاز جهت نصب گوگل تگ منیجر در سایت، میتوانید مسیر زیر را دنبال کنید:
- از نوار ابزار بالای صفحه اصلی گوگل تگ منیجر، سمت چپ، روی گزینه Admin کلیک کنید.
- در صفحهای که نمایش داده میشود، روی گزینه Install Google Tag Manager کلیک کنید.
- در صفحه بعدی، شما به هر دو کد مورد نیاز برای نصب تگ منیجر روی سایت دسترسی خواهید داشت.
مرحله سوم: کدهای نصب گوگل تگ منیجر را در سایت قرار دهید
پاپ آپی که پیش از این به آن اشاره شد، حاوی دو قطعه کد است که اولی باید قبل از بسته شدن تگ <head> قرار گیرد و دومی دقیقا بعد از تگ <body> در سایت قرار گیرد. برای انجام این کار، شما باید یا به سورس کد سایت دسترسی و با کدهای HTML تا حدی آشنایی داشته باشید و یا از افزونه گوگل تگ منیجر برای وردپرس استفاده کنید.
نکته مهم اول:
کد noscript گوگل تگ منیجر که باید بلافاصله بعد از تگ <body> قرار گیرد، به عنوان نسخه پشتیبان عمل میکند و کاربران را بدون جاوا اسکریپت هم ردیابی میکند. درواقع اگر برخی از کاربران قابلیت جاوا اسکریپت سایت را غیر فعال کرده باشند، ورژن آی فریم گوگل تک منیجر رندر شده و کاربر ردیابی میشود.
نکته مهم دوم:
هر دو قطعه کدهای نصب گوگل تگ منیجر را میتوانید بعد از تگ <body> هم قرار دهید؛ اما نمیتوانید هردو را در بخش head قرار دهید. چون رندر شدن iframe در بخش head سایت ممکن نیست!
نکته مهم سوم:
قرار دادن کد دوم برای نصب گوگل تگ منیجر، یعنی کدی که در قسمت body قرار میگیرد؛ الزامی نیست. همانطور که گفته شد این کد مسئول ردیابی کاربرانی است که قابلیت جاوا اسکریپت را غیر فعال کردهاند. با توجه به آمار جهانی، درصد کمی از کاربران این قابلیت را غیر فعال کردهاند. بنابراین بدون ردیابی این دسته از کاربران هم به مشکل نخواهید خورد.
روشهای نصب کد گوگل تگ منیجر روی سایت
روشهای مختلفی برای قرار دادن کدهای نصب گوگل تگ منیجر روی سایت وجود دارد.
نصب از طریق دولوپر یا توسعه دهنده سایت
اگر برای راه اندازی وب سایت خود از یک توسعه دهنده کمک گرفتهاید و به او دسترسی دارید؛ پیشنهاد میکنیم با توجه به شناختی که او از زیرساخت سایت دارد؛ قرار دادن کدهای نصب GTM را به او بسپارید. در این حالت، خطر آسیب زدن به ساختار اصلی سایت و خرابکاری، تا حد زیادی کاهش مییابد.
نصب از طریق افزونههای وردپرس
اگر از سیستمهای مدیریت محتوای رایج مانند وردپرس، شاپیفای و… استفاده میکنید؛ میتوانید برای نصب گوگل تگ منیجر از افزونههای مختلفی که برای انجام این کار وجود دارد؛ استفاده کنید. به عنوان مثال، اگر از وردپرس به عنوان CMS استفاده میکنید، افزونه Google Tag Manager برای وردپرس توسط Thomas Geiger را توصیه میکنم. در ادامه روش نصب گوگل تگ منیجر از طریق افزونه وردپرس را به شما عزیزان آموزش میدهم.
- وارد پیشخوان وردپرس سایت شوید.
- روی گزینه افزونهها و سپس افزودن کلیک کنید.
- در قسمت جستجو، عبارت Google Tag Manager را وارد کنید.
- روی گزینه نصب کلیک کنید. (مطمئن شوید که این افزونه با وردپرس شما سازگار است.)
- بعد از نصب، روی گزینه “فعال نمایید” کلیک کنید.
- سپس به صفحه افزونههای نصب شده بروید و روی تنظیمات افزونه GTM4WP کلیک کنید.
- در صفحهای که نمایش داده میشود، در اولین کادر، باید کد گوگل تگ منیجر را وارد کنید. این کد کجاست؟ کنار بخش Workspace Changes. روی آی دی تگ منیجر کلیک کنید و در صفحهای که نمایش داده میشود، مشابه با تصویر زیر، آدرس کانتینر را کپی کنید و در کادر قرار دهید. در قسمت دوم، باید جایگاه پیشنهادی برای نصب کد دوم، درواقع کدی که قرار دادن آن در سایت ضروری نبود و بهتر بود که در بخش body قرار گیرد؛ را انتخاب کنید. با استفاده از افزونه GTM4WP، کد اول که کد اصلی و ضروری بود، در بخش head سایت قرار میگیرد.
- سپس روی گزینه “ذخیره تغییرات” کلیک کنید.
توجه: بعد از نصب و انجام تنظیمات مربوط به نصب گوگل تگ منیجر در سایت، به افزونه GTM4WP از طریق منوی تنظیمات در پیشخوان وردپرس دسترسی خواهید داشت.
چرا باید کد Google Tag Manager را در بخش <head>
قرار دهیم؟
شاید قرار دادن کد Google Tag Manager در بخش <head>
سایت اجباری نباشد، اما بهشدت توصیه میشود که بخش <script>
این کد را در ابتدای صفحه، یعنی داخل تگ <head>
قرار دهید.
دلیلش چیست؟ دقت بیشتر در ردیابی کاربران
هرچه کدهای ردیابی بالاتر در ساختار صفحه قرار بگیرند، زودتر بارگذاری میشوند. در نسخههای قدیمیتر گوگل تگ منیجر، پیشنهاد میشد کد را داخل <body>
قرار دهید، اما این کار ممکن بود باعث از دست رفتن اطلاعات کاربرانی شود که پیش از بارگذاری کامل صفحه از آن خارج میشدند.
برای مثال، اگر وبسایت شما خیلی دیر لود شود و بارگذاری آن چند ثانیه طول بکشد، اجرای GTM در <body>
با تأخیر شروع میشود. اما اگر آن را در <head>
قرار دهید، اجرای آن بسیار سریعتر آغاز میشود و در نتیجه، میتوانید رفتار تعداد بیشتری از بازدیدکنندگان را ثبت و تحلیل کنید.
فرصت ثبت کاربرانی که خیلی زود از سایت خارج میشوند
یکی از مزایای مهم این کار، امکان تحلیل دقیقتر نرخ پرش (Bounce Rate) است. با اجرای زودهنگام GTM، میتوانید کاربرانی را که حتی قبل از لود کامل صفحه خارج میشوند هم شناسایی کنید.
یادتان باشد: هرچه کدهای ردیابی پایینتر در کدهای سایت قرار بگیرند، دیرتر اجرا میشوند. و همین تأخیر میتواند باعث از دست رفتن بخشی از دیتاهای ارزشمند شما شود.
چگونه بفهمیم Google Tag Manager بهدرستی نصب شده است؟
پس از اینکه کد Google Tag Manager (GTM) را در صفحات سایتتان قرار دادید، باید مطمئن شوید که این کد واقعاً بهدرستی نصب شده است. برای این کار، چند روش ساده و کاربردی وجود دارد که در ادامه به آنها میپردازیم:
۱. مشاهده سورس صفحه
یکی از سریعترین روشها برای بررسی نصب GTM این است که روی پسزمینه سایت خود کلیک راست کرده و گزینهی View Page Source (مشاهده کد منبع صفحه) را انتخاب کنید.
در صفحهی بازشده، با فشردن کلیدهای ترکیبی Ctrl + F
عبارت gtm.js
را جستجو کنید.
اگر این عبارت را پیدا کردید، به احتمال زیاد کد GTM در صفحه شما قرار گرفته است.
۲. فعالسازی حالت پیشنمایش (Preview) و دیباگ
یکی از بهترین ابزارهایی که خود گوگل برای بررسی عملکرد تگها در اختیار شما قرار داده، حالت پیشنمایش و دیباگ گوگل تگ منیجر است.
برای استفاده از آن، وارد محیط کاربری GTM شوید و در گوشهی بالا سمت راست روی دکمهی Preview کلیک کنید.
سپس آدرس وبسایت خود را وارد کرده و آن را رفرش کنید. اگر کد GTM بهدرستی نصب شده باشد، در پایین صفحه، یک پنل مخصوص پیشنمایش و دیباگ ظاهر میشود که اطلاعات دقیقی از بارگذاری تگها را نشان میدهد.
اشتباهات رایج در نصب Google Tag Manager
نصب Google Tag Manager (یا به اختصار GTM) در ظاهر کار سادهای به نظر میرسد؛ اما در عمل، برخی اشتباهات رایج باعث میشوند این ابزار بهدرستی عمل نکند یا حتی بهکلی از کار بیفتد. در ادامه، به تعدادی از خطاهای پرتکرار که هنگام نصب GTM دیدهام میپردازم:
۱. بههمریختن علامت نقلقول در کد
یکی از اشتباهات رایج، زمانی اتفاق میافتد که بازاریابها کد GTM را از پنل گوگل کپی میکنند و از طریق نرمافزارهایی مثل Microsoft Word یا Google Docs برای توسعهدهندهها ارسال میکنند. این نرمافزارها اغلب علامتهای نقلقول (quotation marks) موجود در کد را بهطور خودکار تغییر میدهند. نتیجه؟ کدی که دیگر معتبر نیست و اجرا نمیشود.
برای جلوگیری از این مشکل، توصیه میکنم همیشه کد را از طریق ابزارهای متنی ساده مثل Notepad، VS Code یا حتی پلتفرمهایی مانند GitHub یا Pastebin ارسال کنید. این ابزارها تغییرات ناخواستهای در ساختار کد ایجاد نمیکنند.
۲. قرار ندادن قطعه کد GTM در همه صفحات سایت
تنها قرار دادن کد GTM در صفحه اصلی سایت کافی نیست. GTM فقط در صفحاتی عمل میکند که کد آن در آنها وجود داشته باشد. اگر حتی یکی از صفحات مهم، مثل صفحه پرداخت یا صفحه تماس با ما، فاقد این کد باشد، بخشی از دادههای حیاتی از دست خواهد رفت.
در سایتهای مدرن، معمولاً این موضوع با قرار دادن کد در فایلهایی مثل header.php
یا بخشهای مشترک قالب (مثل Layout
در پروژههای React یا Next.js) مدیریت میشود. اما همچنان توصیه میکنم بررسی کنید که کد GTM در تمام صفحات وبسایت شما بارگذاری میشود. این موضوع مخصوصاً برای کسبوکارهای ایرانی که از سیستمهای مدیریت محتوای بومی یا قالبهای اختصاصی استفاده میکنند، اهمیت بیشتری دارد.
سوالات متداول درباره نصب گوگل تگ منیجر
در حالت ایدهآل و توصیهشده، باید کد Google Tag Manager را به شکل زیر در ساختار سایت خود قرار دهید:
- بخش
<script>
را در قسمت<head>
سایت قرار دهید (معمولاً دقیقاً قبل از بسته شدن تگ</head>
). - بخش
<noscript>
باید بلافاصله بعد از تگ<body>
درج شود.
اما شرایط واقعی معمولاً با این سناریوی ایدهآل فاصله دارد. در بسیاری از مواقع، محدودیتهایی در دسترسی به کدهای سایت یا تنظیمات سیستم مدیریت محتوا (CMS) باعث میشود که نتوانید این ساختار را بهدرستی پیادهسازی کنید. در ادامه، برخی از این سناریوهای غیرایدهآل و پیامدهای آنها را بررسی میکنیم:
آیا میتوان تگ <noscript>
را در جایی غیر از ابتدای <body>
قرار داد؟
بله، امکانپذیر است.
این وضعیت اغلب زمانی رخ میدهد که از سیستمهای مدیریت محتوای محدودی استفاده میکنید—مثل برخی سرویسهای آماده ساخت سایت—که به شما اجازه دسترسی مستقیم به کدهای HTML سایت را نمیدهند. در این شرایط، معمولاً فقط یک فیلد مشخص برای وارد کردن کدهای رهگیری وجود دارد، و همه محتوای این فیلد در انتهای کد HTML سایت قرار میگیرد.
هرچند این روش توصیه نمیشود، اما همچنان میتوان تگهای <script>
و <noscript>
مربوط به Google Tag Manager را در بخش <body>
قرار داد.
اگر قصد شما اجرای تستهای A/B یا آزمایشهای مشابه با استفاده از GTM است، حتماً باید بخش اصلی اسکریپت را در تگ <head>
قرار دهید تا اطمینان حاصل شود که تستها بدون اختلال اجرا میشوند.
اما اگر صرفاً هدف شما فعالسازی Google Analytics یا رهگیریهای پایه مشابه است، در اغلب موارد مشکلی نخواهید داشت.
با این حال باید به این نکته توجه داشته باشید که هرچه کد رهگیری در پایینتر از ساختار HTML قرار گیرد، اجرای آن نیز با تأخیر بیشتری انجام خواهد شد. این موضوع میتواند منجر به از دست رفتن بخشی از دادهها، بهویژه در بازدیدهای بسیار کوتاه، شود.
آیا میتوانم بخش <noscript>
را حذف کنم و فقط از <script>
استفاده کنم؟
بله، میتوانید.
اگر برای شما اهمیتی ندارد که برخی کاربران ممکن است JavaScript را بهطور کامل غیرفعال کرده باشند، میتوانید بخش <noscript>
را بهطور کامل حذف کنید. البته توجه داشته باشید که قراردادن کد noscript
تگ منیجر در بخش <head>
از لحاظ استاندارد HTML اشتباه است، چون عنصر <iframe>
نباید در آن قسمت قرار بگیرد.
در نتیجه، اگر قصد استفاده از <noscript>
را دارید، آن را در بخش <body>
صفحه قرار دهید یا بهکلی از آن صرفنظر کنید.
اگر چند سال پیش Google Tag Manager را نصب کردهام و هر دو کد <script>
و <noscript>
در بخش body هستند، مشکلی وجود دارد؟
خیر، مشکلی نیست.
همانطور که پیشتر اشاره شد، تا اواخر سال ۲۰۱۶، گوگل توصیه میکرد که کل کد Google Tag Manager در بخش <body>
قرار بگیرد. این روش هنوز هم کار میکند و مشکلی از این بابت وجود ندارد.
اما یک نکته را در نظر داشته باشید: اگر کد GTM در بخش body قرار بگیرد، ممکن است بخشی از دادههای ردیابی (tracking) را از دست بدهید؛ چون بارگذاری GTM در body کمی دیرتر از زمانی انجام میشود که این کد در <head>
قرار گرفته باشد.
بنابراین اگر منابع فنی کافی در اختیار دارید، توصیه میشود که بخش <script>
را به <head>
منتقل کنید تا دادهها با دقت و سرعت بیشتری ثبت شوند.
در گوگل تگ منیجر Google Tag Manager، مجموعهی گستردهای از متغیرها در اختیار شماست؛ از متغیرهای از پیشتعریفشده گرفته تا آنهایی که خودتان میسازید. متغیر Click Element؛ یکی از متغیرهای داخلی یا همان Built-in variableهایی که کمتر کسی دربارهاش صحبت میکند. پس اگر اهل ردیابی رفتار کاربران در سایت هستید و میخواهید از GTM مثل یک پرفورمنس مارکتر حرفه ای استفاده کنید، پیشنهاد میکنم ادامهی این مطلب را از دست ندهید.
متغیر Click Element در گوگل تگ منیجر چیست؟
یکی از متغیرهای داخلی (Built-in Variable) در گوگل تگ منیجر، متغیری است به نام Click Element. این متغیر، عنصری از صفحه را که کاربر روی آن کلیک کرده، بهعنوان خروجی برمیگرداند. اما نکته مهم اینجاست که بهصورت پیشفرض در همه کانتینرهای جدید GTM غیرفعال است.
برای فعالسازی آن باید وارد مسیر زیر شوید:
Variables > Configure
و سپس گزینه Click Element را تیک بزنید.
فعالسازی متغیر بهتنهایی کافی نیست
اگر صرفاً این متغیر را فعال کنید، در حالت پیشنمایش و دیباگ (Preview and Debug Mode) گوگل تگ منیجر، هیچ دادهای به شما نشان داده نمیشود. چرا؟ چون برای اینکه این متغیر کار کند، باید حداقل یکی از تریگرهای زیر را هم فعال کرده باشید:
- All Elements Clicks
- Just Links
اگر با مفهوم ترکینگ کلیک در GTM آشنایی ندارید، پیشنهاد میکنم در دوره آموزش گوگل تگ منیجر شرکت کنید.
تفاوت Click Element با Click URL
در نگاه اول ممکن است در حالت پیشنمایش گوگل تگ منیجر، خروجی این متغیر با متغیر Click URL یکی به نظر برسد. اما این تصور اشتباه است.
متغیر Click Element، آبجکت کامل مربوط به عنصر کلیکشده را برمیگرداند. این یعنی:
- نهتنها لینک (URL) المان را برمیگرداند (اگر وجود داشته باشد)
- بلکه تمام ویژگیها (Attributes) و دادههای دیگر آن المان را هم در اختیار دارد
حتی اگر این اطلاعات برای یک کاربر معمولی قابل مشاهده نباشد، این متغیر آنها را نگه میدارد.
نکته مهم درباره Preview Mode
در حالت پیشنمایش GTM، ممکن است متغیر Click Element بهصورت یک رشته (String) نمایش داده شود. این نمایش گمراهکننده است. در واقع، زیرساخت اصلی این متغیر همچنان یک (Object) است، نه رشته.
پس اگر در حال تست تگ یا تریگر هستید و دیدید که مقدار این متغیر به صورت یک رشته ظاهر شده، نگران نباشید؛ کارکرد واقعی آن تغییر نکرده است.
متغیر «Click Element» شامل چه دیتایی است؟
دیتای این متیغر از لیسنرهای پیشفرض ایونت های خودکار در Google Tag Manager (GTM) تأمین میشوند. اگر حتی یکی از تریگرهای زیر را در تگ منیجر فعال کرده باشید:
- Just Links (کلیک روی لینکها)
- All Element Clicks (کلیک روی تمام عناصر)
- Form Submission (ارسال فرم)
- Element Visibility (قابل مشاهده شدن یک عنصر)
بهصورت خودکار، GTM در پسزمینه، لیسنر مرتبط با همان ایونت را فعال میکند و شروع به ترک کردن تعاملات کاربران با صفحه میکند.
این لیسنرها دقیقاً چه کاری میکنند؟
- Just Links کلیک روی لینکها را ردیابی میکند.
- All Element Clicks تمام کلیکهای روی المان های مختلف صفحه (بهجز عناصر داخل iFrame) را ردیابی میکند.
- Form Submission تکمیل فرم را میکند.
- Element Visibility بررسی میکند که چه زمانی یک المان خاص در صفحه نمایان میشود.
ارسال داده به Data Layer
وقتی این لیسنرها (Listeners) یک تعامل را شناسایی میکنند، یک سری داده به Data Layer ارسال میشود. این دادهها به المانی که کاربر با آن تعامل داشته مربوط هستند.
دادههایی که به dataLayer.push
ارسال میشوند، معمولاً شامل کلیدهای زیر هستند:
gtm.element
gtm.elementClasses
gtm.elementTarget
gtm.elementUrl
gtm.elementId
برای مشاهده این مقادیر، کافیست وارد بخش Preview و Debug در GTM شوید و به تب Data Layer سر بزنید.
این کلیدها چه کاربردی دارند؟
تمام این کلیدها به عنوان متغیرهای داخلی (Built-in Variables) در GTM قابل استفاده هستند، مانند:
Click Element
Click Classes
Click Target
Click URL
Click ID
به جز gtm.element
که یک (Object) است و اطلاعات بیشتری در دل خودش دارد، بقیه کلیدها صرفاً رشته متنی (String) هستند.
متغیر Click Element تنها گزینه موجود نیست!
اگر قبلاً با Google Tag Manager (یا به اختصار GTM) کار کرده باشید، احتمالاً میدانید که متغیر Click Element وظیفهاش این است که مقدار ذخیرهشده در Data Layer را از کلید gtm.element
دریافت کند. حالا اگر چنین کلیدی اصلاً در Data Layer وجود نداشته باشد، نتیجهای که این متغیر برمیگرداند چیزی نیست جز undefined
.
اما فقط Click Element نیست که از این کلید استفاده میکند!
چیزی که احتمالاً بسیاری از کاربران تازهکار GTM از آن بیخبرند این است که یک متغیر داخلی دیگر هم وجود دارد که دقیقاً به همین کلید در Data Layer دسترسی دارد، به نام Form Element.
در واقع، هم Click Element و هم Form Element، هر دو به کلید gtm.element
دسترسی دارند — یا اگر دقیقتر بگوییم، به کلیدی در Data Model دسترسی پیدا میکنند که با همین نام شناخته میشود.
جفت متغیرهای Form و Click دقیقاً یکسان هستند
جالب است بدانید تمامی متغیرهایی که برای ایونت های کلیک (Click) و فرم (Form) تعریف شدهاند، به کلیدهای یکسانی دسترسی دارند. به جدول زیر توجه کنید:
gtm.elementTarget
توسط Click Target و Form Targetgtm.elementUrl
توسط Click URL و Form URLgtm.elementClasses
توسط Click Classes و Form Classesgtm.elementId
توسط Click ID و Form ID- و در نهایت
gtm.element
توسط Click Element و Form Element
ایجاد متغیر دلخواه برای دسترسی به مقادیر مشترک در Data Layer
در کنار استفاده از متغیرهای پیشفرضی مانند Click Element یا Form Element، شما میتوانید متغیرهای دلخواه خودتان را هم تعریف کنید تا به همان مقادیر دسترسی پیدا کنید.
فرض کنید میخواهید نسخه اختصاصی خودتان از متغیر Click Element را بسازید. برای این کار، کافی است به مسیر زیر در Google Tag Manager بروید:
Variables > New > Data Layer Variable
در قسمت Data Layer Variable Name، مقدار gtm.element
را وارد کنید. این همان کلیدی است که دادهها در Data Layer در آن ذخیره میشوند.
نکته جالب اینجاست که متغیرهای Click Element و Form Element نیز دقیقاً از همین کلید استفاده میکنند. یعنی هر سه متغیر، به یک داده مشترک دسترسی دارند و نتیجه نهایی یکسانی را ارائه میدهند.
حالا شاید این سؤال پیش بیاید: “پس چرا باید خودمان یک متغیر جدید تعریف کنیم وقتی میتوانیم از متغیرهای آماده استفاده کنیم؟” پاسخ مشخصی برایش وجود ندارد—هدف این بخش بیشتر این است که به شما نشان دهد ساختار GTM چطور کار میکند و چطور اجزا به هم متصلاند.
در این مطلب، قصد دارم نحوه ترکینگ فرمهای AJAX با استفاده از گوگل تگ منیجر، موضوع اصلی این آموزش است. این آموزش بخشی از یک راهنمای جامعتر درباره ردیابی انواع فرمها در Google Tag Manager است.
ساخت تگ HTML سفارشی با Listener مخصوص AJAX در GTM
اگر در حال خواندن این مطلب هستید، احتمالاً فرمی روی سایتتان دارید که توسط تریگر پیشفرض «ارسال فرم» (Form Submission) در گوگل تگ منیجر پشتیبانی نمیشود. این فرم معمولاً به جای اینکه کاربر را به صفحه «تشکر» هدایت کند، فقط پیام موفقیتآمیز بودن ارسال را نشان میدهد، بدون آنکه صفحه واقعاً رفرش شود.
در اینجا به احتمال زیاد فرم شما از تکنولوژی AJAX استفاده میکند. نیازی نیست درگیر جزئیات فنی آن شوید؛ چیزی که باید بدانید این است که راهی برای شنود (Listener) رویدادهای AJAX وجود دارد.
معرفی Listener پیشنهادی برای رویدادهای AJAX
شرکت Bounteous یک Listener آماده و رایگان برای گوگل تگ منیجر معرفی کرده که میتوانید به راحتی از آن استفاده کنید. ما در این آموزش، کد پیشنهادی آنها را برای رهگیری ارسال فرمهای AJAX قرض خواهیم گرفت.
با وجود اینکه این کد مدتها پیش نوشته شده (حتی در آن به اینترنت اکسپلورر ۹ اشاره شده)، اما همچنان به خوبی کار میکند.
نحوه استفاده از کد AJAX Listener در GTM
برای پیادهسازی این Listener کافی است کد زیر را در یک تگ HTML سفارشی (Custom HTML Tag) در Google Tag Manager قرار دهید:
<script id="gtm-jq-ajax-listen" type="text/javascript">
(function() {
'use strict';
var $;
var n = 0;
init();
function init(n) {
if (typeof jQuery !== 'undefined') {
$ = jQuery;
bindToAjax();
} else if (n < 20) {
n++;
setTimeout(init, 500);
}
}
function bindToAjax() {
$(document).bind('ajaxComplete', function(evt, jqXhr, opts) {
var fullUrl = document.createElement('a');
fullUrl.href = opts.url;
var pathname = fullUrl.pathname[0] === '/' ? fullUrl.pathname : '/' + fullUrl.pathname;
var queryString = fullUrl.search[0] === '?' ? fullUrl.search.slice(1) : fullUrl.search;
var queryParameters = objMap(queryString, '&', '=', true);
var headers = objMap(jqXhr.getAllResponseHeaders(), '\n', ':');
dataLayer.push({
'event': 'ajaxComplete',
'attributes': {
'type': opts.type || '',
'url': fullUrl.href || '',
'queryParameters': queryParameters,
'pathname': pathname || '',
'hostname': fullUrl.hostname || '',
'protocol': fullUrl.protocol || '',
'fragment': fullUrl.hash || '',
'statusCode': jqXhr.status || '',
'statusText': jqXhr.statusText || '',
'headers': headers,
'timestamp': evt.timeStamp || '',
'contentType': opts.contentType || '',
'response': (jqXhr.responseJSON || jqXhr.responseXML || jqXhr.responseText || '')
}
});
});
}
function objMap(data, delim, spl, decode) {
var obj = {};
if (!data || !delim || !spl) {
return {};
}
var arr = data.split(delim);
var i;
if (arr) {
for (i = 0; i < arr.length; i++) {
var item = decode ? decodeURIComponent(arr[i]) : arr[i];
var pair = item.split(spl);
var key = trim_(pair[0]);
var value = trim_(pair[1]);
if (key && value) {
obj[key] = value;
}
}
}
return obj;
}
function trim_(str) {
if (str) {
return str.replace(/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g, '');
}
}
})();
</script>
بررسی استفاده از فرمهای مبتنی بر AJAX
حالا وقت آن است که بررسی کنیم آیا فرم سایت شما بر پایه AJAX ساخته شده یا خیر:
- حالت پیشنمایش و اشکالزدایی (Preview and Debug Mode) را فعال یا بهروزرسانی کنید.
- سعی کنید فرم موجود در وبسایتتان را ارسال کنید (بدون ایجاد خطا).
- در کنسول پیشنمایش و اشکالزدایی، بررسی کنید که آیا رویداد ajaxComplete ظاهر شده یا خیر.
- اگر رویداد ajaxComplete را مشاهده کردید، فرم شما از فناوری AJAX استفاده میکند.
- اگر چنین رویدادی وجود نداشت، پیشنهاد میکنم این مطلب آموزشی درباره فرمهای غیر AJAX را مطالعه کنید.
کار با فرمهای AJAX
اگر پاسخ شما به سؤال قبلی مثبت است و فرم شما بر پایه AJAX ساخته شده، گام بعدی این است که ببینیم چگونه میتوانیم از این ویژگی بهره ببریم:
- در حالت پیشنمایش و اشکالزدایی، روی رویداد ajaxComplete کلیک کنید و جزئیات API Call را باز کنید.
ممکن است این بخش در نگاه اول برای کسانی که توسعهدهنده حرفهای نیستند، کمی پیچیده به نظر برسد؛ اما در عمل بسیار سادهتر از چیزی است که فکر میکنید.
شناسایی ارسال موفق فرم
پس از ارسال موفق فرم، دادههایی به Data Layer سایت منتقل میشود. هر خط از این اطلاعات، بهصورت جداگانه، میتواند بهعنوان یک متغیر Data Layer در Google Tag Manager مورد استفاده قرار گیرد.
حالا باید به دنبال عبارتی باشید که نشاندهنده ارسال موفق فرم باشد. کمی پایینتر اسکرول کنید و به دنبال بخش “response” بگردید.
اگر دقت کنید، پیامی شبیه به این مشاهده میکنید:
“با تشکر از تماس شما! به زودی با شما تماس خواهیم گرفت.”
تبریک میگویم! دقیقاً همین پیام را میتوانید بهعنوان یک تریگر (Trigger) برای رهگیری موفقیتآمیز ارسال فرم در GTM استفاده کنید.
متغیر Data Layer و ایجاد تریگر برای رویداد سفارشی در Google Tag Manager
ایجاد متغیر Data Layer
ابتدا باید یک متغیر Data Layer در Google Tag Manager بسازیم. برای این کار مراحل زیر را دنبال کنید:
- وارد بخش Variables شوید.
- به پایین صفحه اسکرول کنید تا به بخش User-Defined Variables برسید و روی گزینه New کلیک کنید.
- در بخش Variable Configuration، نوع متغیر را Data Layer Variable انتخاب کنید.
- در قسمت Data Layer Variable Name، این مقدار را وارد کنید:
attributes.response.data.message
شاید برایتان سوال باشد که چرا به جای واژه سادهتر مثل response
، از مسیر کامل attributes.response.data.message
استفاده کردیم. اجازه بدهید دقیقتر این موضوع را بررسی کنیم.
بررسی ساختار داده در حالت Preview و Debug
در حالت Preview و Debug در GTM، اگر به خط دوم نگاه کنید، رویدادی با نام ajaxComplete
مشاهده خواهید کرد؛ این همان رویدادی است که در سمت چپ کنسول نیز نمایش داده میشود. در این رویداد:
- ابتدا آبجکتی به نام attributes داریم که شامل دادههای مختلف (به صورت کلید-مقدار) است.
- یکی از کلیدهای این آبجکت، response است.
- درون response، یک شیء دیگر به نام data داریم.
- و در نهایت، message در دل data قرار دارد.
میتوانید این روند را مانند دسترسی به پوشههای تو در تو تصور کنید:
ابتدا وارد attributes میشوید، سپس response، بعد data و در نهایت message.
🔵 نکته مهم:
ساختار داده در پروژههای مختلف میتواند متفاوت باشد. ممکن است نام پارامترها تغییر کند. همیشه مسیر از attributes.response
شروع میشود، اما ادامه آن ممکن است در فرمهای مختلف فرق کند؛ مثلاً ممکن است به جای attributes.response.data.message
، مسیر attributes.response.message
باشد. بنابراین باید ساختار دادههای خود را به دقت بررسی کنید و مسیر مناسب را انتخاب نمایید.
یک مثال دیگر:
فرض کنید میخواهید اطلاعات سرور (Server Data) را از پاسخ AJAX استخراج کنید. در این حالت باید نام متغیر Data Layer را اینگونه تعریف کنید:attributes.headers.Server
دیباگ کردن متغیر ساخته شده
پس از ساخت متغیر Data Layer، حالا نوبت به تست آن میرسد:
- حالت Preview and Debug را در GTM رفرش کنید (روی دکمه Preview کلیک کنید).
- فرم موردنظر را پر کرده و ارسال کنید.
- روی آخرین رویداد
ajaxComplete
کلیک کنید. - به تب Variables بروید و متغیر جدید با نام
dlv – attributes.response.data.message
را پیدا کنید.
اگر همه چیز را درست انجام داده باشید، این متغیر باید مقدار پیغام موفقیتآمیز ارسال فرم را نشان دهد.
⚠️ اگر مقدار این متغیر undefined
بود، باید دنبال خطا بگردید. رایجترین مشکلات شامل تایپ اشتباه نام متغیر یا تعریف نادرست مسیر دادههاست. برخی افراد به اشتباه فقط response
را به جای attributes.response.data.message
استفاده میکنند که باعث عدم دریافت داده میشود.
ساخت تریگر برای رویداد سفارشی
حالا بیایید تریگری بسازیم که فقط زمانی فعال شود که:
- رویداد ajaxComplete اتفاق بیفتد.
- و متغیر Data Layer حاوی عبارت “Thanks for contacting us” باشد.
مراحل ساخت تریگر:
- وارد بخش Triggers شوید و روی New کلیک کنید.
- نوع تریگر را Custom Event انتخاب کنید.
- در قسمت Event Name، مقدار
ajaxComplete
را وارد کنید. - مشخص کنید که این تریگر برای Some Custom Events فعال شود.
- شرط زیر را تعریف کنید:
متغیرdlv – attributes.response.data.message
شامل “Thanks for contacting us” باشد.
تست نهایی
- این تریگر جدید را به تگ Google Analytics 4 Event که قبلاً ساختهاید، متصل کنید.
- مجدداً حالت Preview and Debug را باز یا رفرش کنید.
- فرم AJAX را پر کرده و ارسال کنید.
- پس از ارسال موفقیتآمیز، باید تگ GA4 شما فعال شود (این مورد در حالت Preview and Debug قابل مشاهده خواهد بود).
- همچنین میتوانید در Google Analytics 4 Debug View این رویداد را بررسی کنید.
نکات مهم هنگام ردیابی فرمهای AJAX
- پاسخ فرم شما ممکن است ساختار متفاوتی داشته باشد. بنابراین، باید متناسب با آن متغیر Data Layer و تریگر خود را تنظیم کنید.
- اگر توسعهدهندگان تغییراتی در ساختار پاسخ ایجاد کنند، تریگر شما ممکن است از کار بیفتد. بنابراین، حتماً تیم فنی را در جریان پیادهسازیهای GTM قرار دهید.
- اگر صفحه شما چندین فرم AJAX داشته باشد، سعی کنید اطلاعات بیشتری از Data Layer استخراج کنید تا بتوانید فرمهای مختلف را از هم تفکیک کنید.
در گوگل تگ منیجر (GTM)، تریگرهای نمایش صفحه (Page View) این امکان را فراهم میکنند که تگها (Tags) هنگام بارگذاری صفحات وب، فعال شوند. پنج نوع تریگر مرتبط با رویداد بارگذاری صفحه وجود دارد که هرکدام بر اساس زمان و شرایط متفاوتی فعال میشوند. ترتیب اولویت این تریگرها به شرح زیر است:
1. Consent Initialization (راهاندازی اولیه برای مدیریت رضایت کاربران)
این نوع تریگر برای اطمینان از اعمال تنظیمات مربوط به رضایت کاربران طراحی شده است—پیش از آنکه تریگرهای دیگر فعال شوند. معمولاً از این تریگر برای برچسبهایی استفاده میشود که وضعیت رضایت کاربران را تنظیم یا بهروزرسانی میکنند؛ مثلاً:
- تگهای مربوط به پلتفرمهای مدیریت رضایت (CMP)
- تگهایی که پیشفرضهای رضایت را تعیین میکنند
در هر کانتینر (Container) در GTM، به صورت پیشفرض یک تریگر با عنوان Consent Initialization – All Pages وجود دارد. توجه داشته باشید که اگر نیاز دارید تگی خیلی زود در سایت اجرا شود، این تریگر گزینهی مناسبی نیست. در اینگونه موارد، باید از تریگر Initialization استفاده کنید.
2. Initialization (راهاندازی اولیه)
این تریگر طوری طراحی شده که قبل از همهی تریگرها اجرا شود—بهجز تریگر Consent Initialization. در هر کانتینر GTM به صورت پیشفرض یک تریگر Initialization – All Pages وجود دارد. این گزینه برای تگهایی مناسب است که باید پیش از سایر تگها اجرا شوند.
3. Page View (نمایش صفحه)
این تریگر به محض شروع بارگذاری صفحه در مرورگر فعال میشود. اگر فقط نیاز به جمعآوری دادههایی دارید که بر اساس بازدید صفحات شکل میگیرند، این نوع تریگر گزینهی مناسبیست.
4. DOM Ready (آماده بودن ساختار HTML)
وقتی مرورگر بارگذاری کامل HTML صفحه را به پایان میرساند و مدل شیء سند (DOM) برای پردازش آماده میشود، این تریگر فعال میشود. اگر تگهای شما برای استخراج اطلاعات یا پر کردن متغیرها نیاز به دسترسی به ساختار DOM دارند، حتماً از این تریگر استفاده کنید تا از دسترسی کامل به عناصر HTML مطمئن شوید.
5. Window Loaded (پایان کامل بارگذاری صفحه)
این تریگر زمانی فعال میشود که صفحه به طور کامل—شامل تمام منابع مانند تصاویر، اسکریپتها و فایلهای خارجی—بارگذاری شده باشد. معمولاً در پروژههایی که نیاز به اطمینان از بارگذاری کامل صفحه دارند، از این تریگر استفاده میشود.
کدام نوع تریگر (Trigger) را انتخاب کنیم؟
در زمان راهاندازی تگها در Google Tag Manager، انتخاب نوع مناسب «تریگر» اهمیت زیادی دارد. هر تریگر (یا محرک) بسته به هدفی که دارید باید بهدرستی انتخاب شود. در ادامه با رایجترین تریگرها و موارد استفادهی آنها آشنا میشویم:
اگر تگ مربوط به دریافت رضایت کاربر است:
در صورتی که تگی که میخواهید اجرا کنید به رضایتگیری از کاربر مرتبط باشد—مثلاً برای نمایش پنجرهی پاپآپ رضایت (Consent Popup) یا تعیین وضعیت رضایت—از تریگر Consent Initialization استفاده کنید. این تریگر زودتر از هر تریگر دیگری فعال میشود و مناسب سناریوهایی است که باید قبل از هر چیز، وضعیت رضایت مشخص شود.
اگر میخواهید یک تگ بلافاصله پس از شروع بارگذاری صفحه اجرا شود:
در شرایطی که نیاز دارید یک تگ در سریعترین زمان ممکن اجرا شود و وابستگی به هیچیک از عناصر یا محتوای صفحه ندارد، از تریگر Initialization استفاده کنید. این نوع تریگر قبل از بارگذاری محتوا اجرا میشود و برای کارهای زیرساختی یا آمادهسازی اسکریپتهای خاص بسیار مناسب است.
اگر میخواهید تگی همزمان با شروع بارگذاری صفحه اجرا شود:
تریگر Pageview زمانی فعال میشود که مرورگر شروع به بارگذاری صفحه میکند. اگر تگ شما نیازی به دسترسی به عناصر داخلی صفحه ندارد و تنها به لود شدن ابتدایی صفحه متکی است، این تریگر گزینهی مناسبی است.
اگر اجرای تگ شما نیاز به مقدار خاصی از یک عنصر در صفحه دارد:
در شرایطی که تگ باید به محتوای یک عنصر خاص در صفحه (مثل یک متن، دکمه یا فرم) دسترسی داشته باشد، بهتر است از تریگر DOM Ready یا Window Loaded استفاده کنید. این تریگرها بعد از بارگذاری بخشهای مختلف صفحه فعال میشوند و تضمین میکنند که اطلاعات مورد نظر در دسترس هستند.
اگر میخواهید تگ تنها بعد از بارگذاری کامل صفحه اجرا شود:
برای اطمینان از اینکه کل صفحه (از جمله تمام تصاویر و اسکریپتها) بارگذاری شده است، از تریگر Window Loaded استفاده کنید. این گزینه بهویژه برای تگهایی مفید است که نیاز به یک تجربهی کاربری کامل دارند یا باید در هماهنگی کامل با محتوای نهایی صفحه اجرا شوند.
نحوه ایجاد یک Page View Trigger جدید
برای ساخت یک تریگر جدید در GTM مراحل زیر را طی کنید:
- از منوی سمت چپ، روی Triggers کلیک کرده و سپس New را انتخاب کنید.
- روی Trigger Configuration کلیک کنید و یکی از انواع تریگر Page View را انتخاب نمایید.
- (اختیاری، اما توصیهشده برای بهبود عملکرد) شرایطی را برای محدودسازی فعالسازی تریگر مشخص کنید. مثلاً بر اساس آدرس صفحات (URL Pattern):
- در بخش This trigger fires on گزینهی Some Events را انتخاب کنید.
- در قسمت Fire this trigger when an Event occurs and all of these conditions are true فیلتری تعریف کنید. مثال:
Click URL contains /path/to/promo
- تریگر را ذخیره کرده و تغییرات را منتشر (Publish) کنید.
آموزش گوگل ادز
گزارش براساس چنل و asset در کمپین های پی مکس
بررسی تفاوت بین کلیکها و سشنها در کمپینهای دیجیتال
تفاوت کانورژن Primary و Secondary
آموزش دیجیتال مارکتینگ
قانون ۷ در بازاریابی چیست؟ | موضوعی مهم برای تدوین مدیا پلن
گروه کنترل در مارکتینگ چیست؟
بهینه سازی اپ استور (ASO) چیست؟ راهنمای جامع سال 2024
فرم درخواست دوره های آموزشی
معرفی کتاب
کتاب انسان در جستجوی معنا
کتاب انسان در جستجوی معنا “Man’s Search for Meaning” که توسط عصبشناس – روانپزشک اتریشی
کتاب مدیریت توجه (Indistractable)
الان که در حال نوشتن مطلب بررسی کتاب مدیریت توجه (Indistractable: How to Control Your