نگــــــــار پـــورجــــــــــواد
متخصص تبلیغات کلیکی، ایکامرس ترکینگ و …
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
در دنیای دیجیتال امروز، دادهها نقش کلیدی در تحلیل رفتار کاربران، بازاریابی هدفمند و بهبود تجربهی کاربری ایفا میکنند. اما همزمان با رشد نگرانیها درباره حریم خصوصی، دولتها در سراسر جهان قوانین سختگیرانهتری در حوزهی حفاظت از دادهها وضع کردهاند. در این میان، مفهومی به نام 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) شوند. در این صورت، عبارت “(اطلاعات در دسترس نیست)” برای آن داده نمایش داده میشود.
جمعبندی
عبارت “(اطلاعات در دسترس نیست)” لزوماً نشاندهنده مشکلی در عملکرد 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 به عنوان معیار).
اگر ایونت مورد نظر خود را در این بخشها مشاهده کردید، مشکلی وجود ندارد.
ابزارهای تحلیل وب مثل Google Analytics، Yandex Metrica، Woopra، Kissmetrics و Crazy Egg، تنوع زیادی دارند. همین موضوع باعث شده وبمسترها در انتخاب بهترین ابزار گیج شوند.
در دنیای وب، گوگل نقش اصلی را بازی میکند و Google Analytics اطلاعات زیادی به شما میدهد. اما هر ابزاری ویژگیهای خاص خودش را دارد و مثلاً Yandex Metrica در بعضی موارد عملکرد بهتری دارد.
با اینکه گوگل در محبوبیت و سهم بازار پیشتاز است، اما Google Analytics هم محدودیتهایی دارد که شاید از آنها خبر نداشته باشید. این محدودیتها ممکن است باعث شود اطلاعات ارزشمندی درباره عملکرد سایت و رفتار کاربران را از دست بدهید. فراموش نکنید هر ابزار مزایا و معایب خودش را دارد. هدف این نیست که Google Analytics را کنار بگذارید، بلکه میخواهیم نقاط ضعف آن را بررسی کنیم و راهکارهایی برای بهتر کردن نتایج ارائه دهیم.
با استفاده از ابزارهای جایگزین مثل Yandex Metrica، میتوانید به دادههایی دست پیدا کنید که Google Analytics در اختیار شما نمیگذارد.
اگر میخواهید تفاوتها را ببینید، میتوانید یک دموی زنده از Yandex Metrica و Google Analytics دریافت کنید.
وب آنالیتیکس چیست؟
به زبان خیلی ساده، وب آنالیتیکس یک ابزار دیجیتال مارکتینگ است که برای اندازهگیری، جمعآوری، تحلیل و گزارش اطلاعات مهم درباره یک صفحه یا کل سایت استفاده میشود.
یاندکس متریکا چیست؟
Yandex Metrica دومین ابزار بزرگ تحلیل وب در جهان است که توسط موتور جستجوی معروف روسی، Yandex، ارائه شده است. این ابزار در سال 2008، سه سال پس از معرفی Google Analytics، عرضه شد. برای استفاده از این ابزار، باید یک کد جاوااسکریپت (counter) را در بخش هد (Head) صفحات سایت خود قرار دهید. این کد اطلاعات مربوط به هر بازدید را جمعآوری میکند.
خبر خوب این است که یاندکس متریکا کاملاً رایگان است! استفاده از این ابزار فقط به سایتهای روسی محدود نیست و برخلاف Google Analytics، در بازار چین هم بدون محدودیت قابل استفاده است. شما میتوانید از هر نقطهای در جهان برای تحلیل دادههای وبسایت خود از این ابزار بهره ببرید. Yandex Metrica به شما کمک میکند تا معیارهای مهم سایتتان را بررسی کنید، اطلاعات ارزشمندی به دست آورید و برای بهبود عملکرد سایت و رفع مشکلات، اقدامات موثری انجام دهید.
چرا Yandex Metrica متفاوت است؟
یکی از ویژگیهای مهم Yandex Metrica این است که هیچ محدودیتی برای دادههای شما ایجاد نمیکند. فرقی ندارد که سایت شما چند بازدید یا چند جلسه (Session) داشته باشد، این ابزار برخلاف Google Analytics، دادههای شما را نمونهگیری نمیکند و اطلاعات کاملاً دقیق و کامل ارائه میدهد.
اما این تازه شروع ماجراست! تصور کنید بتوانید رفتار کاربران در سایت خود را بهطور دقیق مشاهده کنید. Yandex Metrica این امکان را با ابزارهای جذابی مثل نقشههای حرارتی (Heatmaps) و بازپخش سشن ها (Session Replays) فراهم میکند. این قابلیتها به شما نشان میدهند که کاربران دقیقاً چه مسیری را در سایت شما طی میکنند و چه اقداماتی انجام میدهند.
ابزارهای Yandex.Metrica: مشابه سرویس Hotjar
Yandex.Metrica ابزارهایی شبیه به سرویس Hotjar ارائه میدهد که برای تحلیل پیشرفته رفتار کاربران طراحی شدهاند. این ابزارها شامل Webvisor، نقشه کلیک (Click Map) و نقشه اسکرول (Scrolling Map) هستند و به شما کمک میکنند تا:
- مشکلات فنی سایت را شناسایی کنید، نوع آنها را بفهمید و تأثیرشان را بر کاهش نرخ تبدیل بررسی کنید.
- مراحلی را که کاربران در تعامل با سایت سردرگم یا منصرف میشوند، شناسایی کنید.
- خطاهای کاربران را بازسازی کرده و آنها را به توسعهدهندگان گزارش دهید.
- میزان راحتی کاربران در استفاده از سایت، ناوبری، پر کردن فرمها، کلیک روی دکمهها و تعامل با سایت روی دستگاهها و مرورگرهای مختلف را ارزیابی کنید.
- مشکلات منطقی موجود در ساختار و طراحی رابط کاربری سایت را کشف کنید.
Webvisor: مشاهده دقیق رفتار کاربران
Webvisor ابزاری است که به شما امکان میدهد فعالیت بازدیدکنندگان وبسایت را بهصورت ویدئوی آنلاین مشاهده کنید. با استفاده از پلیر داخلی این ابزار، میتوانید تمامی حرکات کاربران را بهصورت دقیق بازبینی کنید، از جمله:
- حرکت ماوس
- کلیکها
- پیمایش صفحات
- تایپ کردن
- پر کردن فرمها
- هایلایت و کپی کردن متنها
نقشه کلیک و نقشه اسکرول
ابزارهای Click Map و Scrolling Map به شما اطلاعات ارزشمندی میدهند:
- شناسایی مکانهایی که کاربران بیشترین کلیک را روی آنها انجام میدهند.
- بررسی اینکه کاربران تا کجا در صفحات پیمایش میکنند و کدام بخشها بیشتر دیده میشوند.
تحلیل فرمها
این ابزار به شما کمک میکند تعامل کاربران با فرمهای سایت را بهینه کنید. میتوانید بفهمید:
- کدام فیلدها کاربران را بیشتر درگیر میکنند؟
- کاربران در کدام مرحله از پر کردن فرم منصرف میشوند؟
- چگونه میتوان فرمها را کاربرپسندتر کرد؟
نکات فنی:
- Webvisor محتوای عناصر
iframe
وcanvas
و اطلاعات واردشده در فیلدهای رمز عبور را ثبت نمیکند. - دادههای جمعآوریشده توسط Webvisor به مدت ۱۵ روز از زمان بازدید ذخیره میشوند.
تحلیل تجربه کاربری (UX) و رابط کاربری (UI)
این ابزارها مخصوصاً برای بررسی تجربه کاربری (UX) و طراحی رابط کاربری (UI) مناسب هستند. آنها به شما کمک میکنند تا راحتی و کارایی سایت را برای کاربران ارزیابی کنید، چه کاربران از طریق:
- نتایج ارگانیک موتورهای جستجو
- تبلیغات در موتورهای جستجو یا سایتهای همکار
- شبکههای اجتماعی
- یا ایمیل مارکتینگ
به سایت شما دسترسی پیدا کرده باشند.
Link Map: بررسی دکمهها و لینکها
ویژگی Link Map ابزار مفیدی برای شناسایی و بهینهسازی لینکها و دکمههای سایت است:
- شناسایی بخشها و دکمههایی که بیشترین کلیک را دارند.
- پیدا کردن مسیرهایی که کاربران از طریق آنها به صفحات دیگر سایت منتقل میشوند.
- شناسایی دکمهها و لینکهای غیرضروری یا ناکارآمد که هیچ تأثیری در تعامل کاربر ندارند و میتوان آنها را حذف کرد.
در ادامه، به مقایسه ویژگیهای مشترک و منحصربهفرد Yandex Metrica و Google Analytics میپردازیم.
تفاوتهای کلیدی بین Google Analytics و Yandex Metrica
Google Analytics و Yandex Metrica دو ابزار محبوب برای تحلیل وب هستند که اطلاعات ارزشمندی درباره عملکرد سایت و رفتار کاربران ارائه میدهند. با این حال، تفاوتهای مهمی بین آنها وجود دارد که مدیران وبسایت و بازاریابان باید از آن آگاه باشند:
یکپارچگی با پلتفرمهای تبلیغاتی
Google Analytics بهطور کامل با ابزارهای تبلیغاتی گوگل مانند Google Ads و Display & Video 360 هماهنگ است و به کاربران امکان میدهد اثربخشی کمپینهای تبلیغاتی خود را مستقیماً از طریق این ابزار بررسی کنند. در مقابل، Yandex Metrica با پلتفرمهای تبلیغاتی Yandex.Direct، Yandex.Display و Yandex.Audience ادغام میشود و امکانات مشابهی را در اکوسیستم تبلیغاتی Yandex ارائه میدهد. انتخاب ابزار مناسب به پلتفرم تبلیغاتی مورد استفاده شما بستگی دارد.
رابط کاربری و امکانات گزارشدهی
Google Analytics امکانات پیشرفتهای برای سفارشیسازی گزارشها، داشبوردها و بخشبندیها فراهم میکند و برای کاربران حرفهای بسیار انعطافپذیر است. در مقابل، Yandex Metrica با یک رابط کاربری ساده و طراحی کاربرپسند ارائه میشود. این طراحی سادهتر، استفاده از ابزار را برای کاربران مبتدی یا کسانی که به دنبال یک تجربه سریعتر هستند، راحتتر میکند.
روش ردیابی
یک تفاوت کلیدی در نحوه جمعآوری دادهها بین این دو ابزار وجود دارد. Google Analytics از تگهای جاوااسکریپت و کوکیها استفاده میکند که ممکن است با مرورگرها یا مسدودکنندههای تبلیغاتی محدود شود. در حالی که Yandex Metrica از کدهای مبتنی بر Beacon استفاده میکند که کمتر در معرض محدودیتهای مسدودکنندهها قرار دارد. این تفاوت میتواند بر دقت و کامل بودن دادههای جمعآوریشده تأثیر بگذارد.
مقایسه Yandex Metrica و Google Analytics
معیار مقایسه | Yandex Metrica | Google Analytics |
---|---|---|
رتبه محبوبیت | رتبه چهارم در میان ابزارهای تحلیل وب | رتبه اول و پرطرفدارترین ابزار |
سهم بازار | ۴٪ | ۹۶٪ |
ضبط سشن کاربران | موجود | موجود نیست |
نقشه حرارتی کلیک و لینک | دارد | ندارد |
محدودیت ردیابی کانورژن | ۲۰۰ هدف | ۲۰ هدف |
محدودیت ترافیک | نامحدود | ۱۰ میلیون ایونت در ماه برای نسخه رایگان |
تأثیر بر سرعت سایت | تأثیر قابل توجه بر سرعت | تأثیر کمتری بر سرعت بارگذاری صفحات دارد |
مانیتورینگ سایت | امکان نظارت بر دسترسپذیری سایت در صورت وقوع خطا یا قطعی | این قابلیت را ندارد |
محاسبه بازدید صفحات | اگر صفحه در کمتر از ۱۵ ثانیه رفرش شود، بازدید جدید محسوب نمیشود | هر بار رفرش، بازدید جدید محسوب میشود |
نرخ پرش (Bounce Rate) | کاربر تنها زمانی بانس محسوب میشود که کمتر از ۱۵ ثانیه در صفحه بماند | – |
نمونهگیری دادهها | دادهها بدون سمپلینگ نمایش داده میشوند | در صورت پیچیدگی و بالا بودن حجم دیتا، گزارشها نمونه گیری می شوند. |
تعداد سایتها در هر حساب | نامحدود | حداکثر ۵۰ سایت |
هزینه ابزار | کاملاً رایگان | نسخه پرمیوم: ۱۵۰,۰۰۰ دلار در سال |
کسبوکارها برای شناخت بهتر مشتریان و بهبود خدمات خود به دادههای آنلاین وابسته هستند. اگر یک فروشگاه آنلاین را مدیریت میکنید، چگونه میتوانید رفتار کاربران در وبسایت خود را زیر نظر داشته باشید؟ با استفاده از Measurement Protocol (MP) در آنالیتیکس 4 ، میتوانید نه تنها بازدید از صفحات را بهطور دقیق رصد کنید، بلکه اتفاقات جزئیتری مانند کلیک روی محصولات، اضافه کردن به سبد خرید، و تکمیل خریدها را نیز ردیابی کنید.
Measurement Protocol به شما امکان میدهد متوجه شوید کدام محصولات محبوبتر هستند، کاربران در کجای قیف فروش از خرید منصرف میشوند و کدام کمپین های بازاریابی بیشترین کانورژن را ایجاد میکنند. با تحلیل این دادهها، میتوانید محصولات یا تبلیغاتی که برای مشتریان جذابتر هستند را شناسایی کنید، مسیر کاربران را بهبود بخشید و در نهایت درآمد خود را افزایش دهید.
Measurement Protocol در آنالیتیکس 4 چیست؟
Measurement Protocol هسته اصلی جمعآوری دادهها در Google Analytics 4 (GA4) محسوب میشود.
این پروتکل، مجموعهای از قوانین و دستورالعملهاست که به کسبوکارها و توسعهدهندگان اجازه میدهد تا دادههای مختلف را بهصورت بهینه و هوشمندانه به GA4 ارسال کنند.
دادههای ارسالشده میتوانند شامل هر چیزی باشند؛ از بازدید صفحات و تعاملات کاربران گرفته تا خرید آنلاین و ایونت های سفارشی. ویژگی برجسته Measurement Protocol این است که میتواند دادهها را از منابع مختلف، مانند وبسایت، اپلیکیشنهای موبایل و هر پلتفرم دیجیتالی دیگری که توانایی ارسال درخواستهای HTTP را دارد، دریافت کند.
بهعنوان مثال، وقتی کاربری محصولی را به سبد خرید خود در وبسایت شما اضافه میکند، کدی که در پشتصحنه وبسایت قرار دارد، یک درخواست ویژه به GA4 ارسال میکند. این درخواست شامل اطلاعاتی مانند نام محصول، قیمت آن و اقدام به اضافه کردن به سبد خرید است. GA4 این اطلاعات را دریافت و پردازش میکند تا به شما نشان دهد چند کاربر محصولات را به سبد خرید خود اضافه کردهاند.
این روش، به شما کمک میکند تا رفتار کاربران را بهتر درک کنید و تصمیمات دادهمحور برای بهبود تجربه کاربری و افزایش فروش اتخاذ کنید.
کلاینت چیست؟
در زبان Measurement Protocol، کلاینت مسئولیت ارسال اطلاعات (درخواست) را به عهده دارد. این کلاینت میتواند یک مرورگر وب هنگام بازدید از یک وبسایت، یک اپلیکیشن موبایل یا حتی یک صندوق فروشگاهی باشد که هنگام خرید مشتری، دادهها را ارسال میکند. کلاینتها از طریق پیامهای خاص وب به نام HTTP requests دادهها را به GA4 ارسال میکنند. این پیامها اطلاعاتی درباره اقدامات کاربران دارند و از قوانین مشخصی در پروتکل اندازهگیری پیروی میکنند.
نمونههایی از کلاینتها در پروتکل اندازهگیری:
مرورگرهای وب
وقتی کاربری با مرورگری مانند Google Chrome یا Safari به یک وبسایت وارد میشود، آن مرورگر نقش کلاینت را دارد.
اپلیکیشنهای موبایل
اپلیکیشنهایی که روی دستگاههای موبایل نصب شدهاند – مانند اپلیکیشنهای شبکههای اجتماعی، بازیها، یا فروشگاهی – بهعنوان کلاینت عمل میکنند وقتی دادهها را به GA4 ارسال میکنند.
سیستمهای پایانه فروش (POS)
در فروشگاههای فیزیکی، صندوقها و پایانههای پرداخت بهعنوان کلاینت دادههای تراکنش را به GA4 ارسال میکنند.
دستگاههای هوشمند
تلویزیونهای هوشمند، دستیارهای صوتی (مانند Amazon Echo) و یخچالهای هوشمند میتوانند نقش کلاینت را ایفا کنند و دادههای مربوط به استفاده کاربر را به GA4 ارسال کنند.
کنسولهای بازی
کنسولهایی مانند Xbox، PlayStation یا Nintendo Switch کلاینتهایی هستند که دادههای مربوط به استفاده و تعامل کاربر با بازیها را ارسال میکنند.
دستگاههای IoT (اینترنت اشیا)
دستگاههایی مانند دستبندهای تناسباندام، ترموستاتها، و لوازم خانگی هوشمند نیز میتوانند به عنوان کلاینت عمل کنند.
اپلیکیشنهای سمت سرور
برنامههایی که روی سرورها اجرا میشوند – مانند پلتفرمهای تجارت الکترونیک یا سرورهای ایمیل – نیز میتوانند دادههای تراکنش یا تعامل کاربران را به GA4 ارسال کنند.
این تنوع کلاینتها امکان جمعآوری دادهها از منابع متعدد را فراهم میکند و به شما کمک میکند تصویر جامعتری از رفتار کاربران و مشتریان خود داشته باشید.
سرور چیست؟
در Measurement Protocol، سرور مانند یک دریافتکننده درخواست عمل میکند که دادهها را از کامپیوتر یا اپلیکیشنهای شما از طریق درخواستهای HTTP دریافت میکند.
سرورها با سرعت و دقت بالا حجم زیادی از دادهها را مدیریت میکنند. پس از دریافت دادهها، وظایف مهمی را انجام میدهند، از جمله:
- بررسی صحت و اعتبار دادهها
- پردازش و تحلیل اطلاعات
- ذخیرهسازی امن دادهها
این دادهها نقش حیاتی در تحلیل رفتار کاربران دارند و ابزار ارزشمندی برای تصمیمگیریهای هوشمندانه در کسبوکار شما محسوب میشوند.
سرورها با اطمینان از صحت دادههای ارسالشده و فراهم کردن بستری امن برای ذخیرهسازی و پردازش آنها، یکی از ارکان کلیدی در مدیریت دادهها هستند.
اصول کار با Measurement Protocol
Measurement Protocol (MP) یک ابزار مکمل برای زیرساختهای گوگل آنالیتیکس است و قرار نیست جایگزین روشهای خودکار جمعآوری داده مانند gtag.js، Google Tag Manager یا Google Analytics for Firebase SDK شود. درواقع، MP در شرایطی که روشهای رایج کافی نیستند، میتواند به کمک شما بیاید.
این پروتکل زمانی کارآمد است که بخواهید فعالیتهایی را ردیابی کنید که با کد جاوااسکریپت معمولی امکانپذیر نیست، مثل برخی تعاملات در اپلیکیشنها، ارسال فرم به سرور یا ارتباط با دستگاههای خارجی.
در ادامه، به چند نمونه از کاربردهای Measurement Protocol اشاره میکنیم:
1. ردیابی فروش آفلاین
فرض کنید یک سیستم پرداخت، موفقیت یک تراکنش را ثبت می کند. با استفاده از MP، میتوانید اطلاعات این تراکنش را مانند شناسه پرداخت، مبلغ، لیست محصولات خریداریشده و سایر جزئیات به Google Analytics (GA) ارسال کنید. این دادهها به شما کمک میکند تا عملکرد فروشگاه و رفتار مشتریان خود را بهتر تحلیل کنید.
2. ثبت رویدادهای اپلیکیشنهای موبایل و پلتفرمهای خاص
گاهی ایونت ترکینگ در شرایطی که نمیتوانید از جاوااسکریپت استفاده کنید (مانند اپلیکیشنهای موبایل)، چالشبرانگیز است. در این شرایط، MP میتواند ایونت هایی مثل باز شدن اپلیکیشن، کلیک روی تبلیغات یا استفاده از امکانات خاص را مستقیماً به GA ارسال کند. این اطلاعات برای بهبود تجربه کاربری و سنجش اثربخشی قابلیتهای اپلیکیشن ضروری است.
3. ردیابی فرمهایی که بدون بارگذاری مجدد ارسال میشوند
در وبسایتهایی که از تکنولوژی AJAX برای ارسال فرم استفاده میکنند، میتوانید از MP برای فرم ترکینگ استفاده کنید. در این شرایط به جای استفاده از مرورگر کاربر، MP این دادهها را مستقیماً از سمت سرور به سیستم آنالیتیکس ارسال میکند. برای مثال، اگر کاربری در خبرنامه ثبتنام کند، اطلاعات مربوط به این ایونت (مانند زمان و صفحه تکمیل فرم) از طریق MP قابل ثبت است.
4. تحلیل تبدیلها و رفتار کاربران
وقتی یک فرم (مثل سفارش یا اشتراک) با موفقیت ارسال میشود، میتوانید با کمک MP اطلاعات کانورژن را به گوگل آنالیتیکس منتقل کنید. این اطلاعات میتواند شامل نام فرم، موقعیت جغرافیایی کاربر، زمان ارسال و هر دادهی دیگری باشد که برای تحلیل نیاز دارید.
5. تحلیل دادههای خارج از مرورگر
گاهی نیاز دارید اطلاعاتی را که در سمت سرور تولید شدهاند، تحلیل کنید. MP این امکان را میدهد که این دادهها را مستقیماً به سیستم آنالیتیکس ارسال کنید. نمونههایی از این دادهها شامل موارد زیر است:
- لاگهای سرور: اطلاعاتی مثل بازدید صفحات، سرچ در پایگاه داده و خطاها.
- فرآیندهای داخلی سرور: نتایج اجرای اسکریپتها، اطلاعات تراکنشها و پردازش درخواستهای API.
برای مثال، در یک فروشگاه آنلاین، زمانی که خریدی انجام میشود، سرور اطلاعاتی مثل نام محصول، قیمت و مشخصات خریدار را ذخیره میکند. با MP میتوانید این اطلاعات را به گوگل آنالیتیکس ارسال کنید تا تحلیل دقیقی از فروش و رفتار مشتریان انجام شود.
آموزش گوگل تگ منیجر
در گوگل تگ منیجر (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) کنید.
آیا حالت پیشنمایش (Preview Mode) در Google Tag Manager برای شما کار نمیکند؟ احتمالاً شما هم مثل بسیاری از کاربران حداقل یکبار با این مشکل روبهرو شدهاید. حالت Preview و Debug فعال میشود، اما روی سایت نه دیده میشود و نه درست کار میکند. در ادامه، چند راهحل کاربردی برای برطرف کردن این مشکل ارائه میدهم که احتمالاً حداقل یکی از آنها به درد شما میخورد.
اگر در حین بررسی، راهحلی پیدا کردید که در این مقاله به آن اشاره نشده، حتماً در بخش نظرات با ما به اشتراک بگذارید. من این محتوا را بهروزرسانی میکنم تا افراد بیشتری بتوانند از تجربیات شما بهرهمند شوند.
۱. کد GTM بهدرستی روی سایت اضافه نشده است
یکی از رایجترین دلایل کار نکردن حالت پیشنمایش، اضافه نشدن صحیح کد تگ منیجر به وبسایت است. فرض کنید از توسعهدهنده خواستهاید که کد GTM را مطابق دستورالعملهای گوگل روی سایت شما قرار دهد. او هم اعلام میکند که کار تمام شده؛ اما همچنان حالت پیشنمایش نمایش داده نمیشود.
پس مشکل کجاست؟ احتمال زیاد این است که کد GTM فقط در نسخهی پیشنویس (draft) ذخیره شده و به نسخهی نهایی و زندهی سایت منتشر نشده است. این اشتباه ساده اما رایج، باعث میشود هیچ اتفاقی روی سایت شما نیفتد.
چگونه بررسی کنیم که کد GTM درست نصب شده؟
چند راه ساده برای این کار وجود دارد:
- استفاده از افزونهی Tag Assistant در مرورگر کروم: این افزونه بررسی میکند که آیا تگهای گوگل مثل Google Analytics، Google Ads یا GTM روی صفحه فعال هستند یا نه.
- بررسی سورس کد سایت: کافیست در مرورگر خود کلیدهای
Ctrl + U
را فشار دهید (یا روی مک،CMD + Option + U
) و دنبال کد کانتینر GTM بگردید.
۲. کد نادرست یا اشتباه GTM روی سایت قرار گرفته
شاید عجیب بهنظر برسد، اما وارد کردن کد اشتباه GTM هم یکی از دلایل رایج است. برای بررسی این موضوع، وارد حساب کاربری Google Tag Manager شوید و در گوشهی بالا سمت راست، شناسهی GTM (Container ID) را بررسی کنید.
حالا کد GTM موجود در سایت خود را با آن مقایسه کنید. میتوانید از همان افزونهی Tag Assistant هم برای مقایسه کمک بگیرید.
نکته مهم: هرگز نباید کدی که از GTM کپی میکنید را تغییر دهید. این کد باید دقیقاً به همان صورت در سایت قرار گیرد؛ هرگونه تغییر، باعث اختلال در عملکرد آن خواهد شد.
۳. پیشنمایش را روی کانتینر اشتباه فعال کردهاید
وقتی چندین اکانت یا کانتینر GTM دارید، ممکن است بهاشتباه حالت پیشنمایش را روی کانتینر اشتباه فعال کنید. این یکی از رایجترین خطاهاست که حتی برای حرفهایها هم پیش میآید. پس همیشه دوباره بررسی کنید که پیشنمایش را روی کانتینر درست فعال کردهاید. برای این کار، میتوانید از روش توضیح داده شده در مرحله دوم راهنمای رسمی گوگل استفاده کنید.
۴. استفاده از مرورگر متفاوت ممنوع!
زمانی که حالت Preview & Debug فعال میشود، یک تب یا پنجره جدید در همان مرورگر باز میکند که سایت را با حالت دیباگ نمایش میدهد. اگر بعد از آن، مرورگر را تغییر دهید یا وارد حالت ناشناس (Incognito) شوید، ممکن است دیباگ به درستی کار نکند. بنابراین، حتماً از همان مرورگری که حالت پیشنمایش را فعال کردهاید استفاده کنید.
۵. پاک کردن کش و کوکی مرورگر
اگر با وجود رعایت نکات بالا، همچنان مشکلاتی دارید، شاید لازم باشد کش (Cache) و کوکی (Cookies) مرورگر را پاکسازی کنید. روش انجام این کار در مرورگرهای مختلف متفاوت است. برای مثال میتوانید در گوگل جستجو کنید:
“نحوه پاک کردن کش و کوکی مرورگر کروم / فایرفاکس / سافاری”
اگر از مرورگر کروم استفاده میکنید، این گزینه در بخش تنظیمات > حریم خصوصی و امنیت در دسترس است.
۶. حذف پارامتر پیشنمایش از آدرس URL
در حالت Preview & Debug، بهطور پیشفرض پارامتر gtm_debug=x
به انتهای آدرس سایت اضافه میشود. اما بعضی وبسایتها ممکن است با این پارامتر به درستی کار نکنند و حتی خطای 404 نمایش دهند. اگر چنین مشکلی دارید، تیک گزینه مربوط به پارامتر دیباگ را در تنظیمات Preview بردارید. این کار ممکن است مشکل را حل کند.
۷. تداخل Cloudflare با بارگذاری فایل gtm.js
یکی از رایجترین CDNهایی که در ایران و جهان استفاده میشود، Cloudflare است. وظیفهی CDN این است که محتوای استاتیک سایت شما (مثل فایلهای CSS، JS و تصاویر) را از نزدیکترین سرور به کاربر نهایی ارائه دهد و این کار باعث افزایش سرعت بارگذاری صفحات میشود.
اما این نکته را در نظر داشته باشید که Cloudflare ممکن است در بارگذاری فایل JavaScript مخصوص GTM (یعنی gtm.js
) اختلال ایجاد کند. مخصوصاً اگر قابلیت Rocket Loader در تنظیمات فعال باشد. این ویژگی با هدف بهینهسازی بارگذاری JS طراحی شده، اما گاهی باعث بههمریختگی عملکرد GTM میشود. از برنامهنویس سایت خود بخواهید بررسی کند که Rocket Loader در Cloudflare غیرفعال باشد.
۸. تغییر ناخواسته کد GTM هنگام کپیبرداری
شاید برایتان پیش آمده باشد که قصد دارید کد کانتینر GTM را برای توسعهدهنده سایت ارسال کنید. معمولاً این کد را از پنل GTM کپی میکنید، در یک فایل Word یا Google Docs قرار میدهید و سپس آن را میفرستید. اما همین کار ساده ممکن است باعث خراب شدن کد شود!
چرا؟ چون ابزارهای ویرایش متن ممکن است برخی از نمادهای کد، مثل نقلقولها (‘ ’)، فاصلهها یا حتی علائم نگارشی را بهصورت خودکار تغییر دهند. در نتیجه، هرچند ظاهر کد تغییری نکرده، ولی GTM دیگر کار نمیکند؛ حالت Preview و Debug هم نمایش داده نمیشود.
✅ راهحل بهتر: کد را در یک فایل .txt
(مثلاً با Notepad) قرار دهید و فایل را مستقیماً برای توسعهدهنده بفرستید. یا از سایت pastebin.com استفاده کنید تا کد بهصورت خام و بدون تغییر در دسترس برنامهنویس باشد.
۹. مسدود شدن پاپآپها و ریدایرکتها توسط مرورگر
یکی دیگر از مشکلاتی که کاربران GTM ممکن است با آن مواجه شوند، مسدود شدن پنجره پیشنمایش (Preview) توسط مرورگر است. وقتی دکمهی Preview را در محیط GTM میزنید، یک تب جدید باز میشود که به سایت tagassistant.google.com متصل میشود.
گاهی مرورگر (مثل Chrome) این پنجره را مسدود میکند. اگر این اتفاق افتاد، کافیست روی آیکن هشدار در نوار آدرس کلیک کنید و گزینهی:
“Always allow popups and redirects from tagassistant.google.com”
را انتخاب کرده و روی “Done” بزنید. این تنظیم فقط برای GTM اعمال میشود و امنیت مرورگر شما را به خطر نمیاندازد.
۱۰. کانتینر را منتشر کنید (حتی اگر جدید نیست)
برخی کاربران گفتهاند که قبل از فعالسازی حالت پیشنمایش، کانتینر را منتشر کردهاند و همین کار به عملکرد بهتر پیشنمایش کمک کرده است. هرچند این مورد تایید قطعی ندارد، اما ارزش امتحان کردن را دارد.
از حالت پیشنمایش خارج شده و دوباره وارد شویدگاهی تنها بستن تب حالت پیشنمایش و تب سایت و سپس ورود مجدد از طریق دکمه “Preview” در پنل GTM، مشکل را حل میکند. این راهحل در چندین مورد مؤثر بوده است.
۱۱. افزونههای مرورگر مانند AdBlock یا Ghostery ممکن است GTM را مسدود کنند
با افزایش استفاده از افزونههای مسدودکننده تبلیغات، ابزارهایی مانند GTM نیز در معرض مسدود شدن قرار گرفتهاند. افزونههایی نظیر Ghostery، AdGuard، AdBlock Plus و حتی uBlock Origin ممکن است مانع اجرای صحیح حالت پیشنمایش شوند.
🔒 اگر یکی از این افزونهها روی مرورگر شما فعال است، موقتاً آن را غیرفعال کرده و دوباره پیشنمایش را بررسی کنید.
۱۲. سیستم شما ممکن است بهصورت خودکار از تنظیم کوکیها جلوگیری کند
در پی اجرای قوانین مربوط به حریم خصوصی مانند GDPR، برخی وبسایتها از ابزارهایی برای بلاککردن خودکار کوکیها استفاده میکنند. نمونههایی از این ابزارها:
- OneTrust Auto-blocking
- CookieBot Auto-blocking
در این حالت، باید مطمئن شوید که کوکی با نام _TAG_ASSISTANT مجاز به ذخیرهسازی است. اگر اطلاعات کافی ندارید، با فردی که در زمینه مدیریت کوکی یا ابزارهای رضایتسنجی تخصص دارد مشورت کنید.
۱۳. بررسی کنید که کانتینر صحیح را انتخاب کردهاید
در صورتی که چند کانتینر در یک سایت استفاده میشود، احتمال دارد شما به اشتباه در حال پیشنمایش کانتینر اشتباهی باشید. با کلیک روی آیکن فلش پایین در گوشه بالا سمت چپ پنجره Preview، کانتینر فعال را بررسی و در صورت نیاز، مورد صحیح را انتخاب کنید.
۱۴. توجه به تفاوت Workspace و Environment
اگر در حال استفاده از Google Tag Manager هستید و در زمان فعالسازی حالت Preview با پیام “هیچ تگی در این کانتینر اجرا نشد” مواجه شدید، احتمال زیادی وجود دارد که در حال پیشنمایش محیط (environment) نیستید، بلکه صرفاً ورکاسپیس (workspace) را مشاهده میکنید. این مسئله میتواند کاربران زیادی را گیج کند. در این مقاله به زبان ساده توضیح میدهیم که دلیل این مشکل چیست و چطور میتوانید آن را برطرف کنید.
تفاوت Workspace و Environment در GTM چیست؟
وقتی Google Tag Manager روی یک وبسایت نصب میشود، معمولاً توسعهدهندگان از اسنیپتی استفاده میکنند که در رابط کاربری GTM و با کلیک روی Container ID قابل دسترسی است. این اسنیپت پیشفرض، پارامترهای اضافی مربوط به Environment را ندارد.
اما گوگل تگ منیجر قابلیتی به نام محیطها (Environments) هم ارائه میدهد که به شما اجازه میدهد نسخههای مختلفی از تگها را برای محیطهای متفاوت مثل توسعه (development)، تست (staging) یا حتی نسخه زنده (live) داشته باشید. هرکدام از این محیطها اسنیپت مخصوص به خودشان را دارند.
مشکل زمانی پیش میآید که…
گاهی اوقات توسعهدهندگان به اشتباه اسنیپت مربوط به محیط Live را روی وبسایت نصب میکنند، در حالی که این اسنیپت با نسخه پیشفرض GTM تفاوتهایی دارد. حالا اگر شما در رابط GTM دکمهی PREVIEW را بزنید، در واقع پیشنمایش ورکاسپیس فعلی فعال میشود، نه محیط خاصی که روی وبسایت نصب شده است. در نتیجه، هیچ تگی لود نمیشود و پیامی شبیه به این دریافت میکنید:
«No tags were evaluated in this container»
راهحل چیست؟
برای اینکه پیشنمایش به درستی عمل کند، باید لینک مخصوص به پیشنمایش همان محیطی که روی سایت نصب شده را ایجاد و استفاده کنید:
- به بخش Admin > Environments در GTM بروید.
- محیط مورد نظر (مثلاً Live) را انتخاب کنید.
- روی Actions > Share Link کلیک کنید.
- حالا با استفاده از این لینک وارد حالت Preview شوید.
نکته مهم: باید حداقل یک نسخهی منتشرشده از GTM روی کانتینر شما وجود داشته باشد تا گزینه Share Link در دسترس قرار بگیرد.
چطور متوجه شویم که کدام اسنیپت روی سایت نصب شده؟
برای این کار:
- به وبسایت بروید.
- روی صفحه راستکلیک کرده و گزینه View Page Source را انتخاب کنید.
- کد GTM را پیدا کرده و با اسنیپت پیشفرض GTM مقایسه کنید.
اگر اسنیپت شامل پارامترهای اضافی بود، یعنی مربوط به یکی از محیطهاست. در این صورت، باید از روش توضیحدادهشده برای فعالسازی پیشنمایش استفاده کنید.
۱۵. از مرورگر Brave برای کار با GTM استفاده نکنید
مرورگر Brave با اینکه به خاطر حفظ حریم خصوصی محبوب شده، اما در کار با ابزارهایی مثل Google Tag Manager (GTM) دردسرساز است. این مرورگر بهطور پیشفرض بسیاری از درخواستهای مرتبط با سرویسهای گوگل، از جمله Google Analytics، Google Ads و همین GTM را مسدود میکند.
اگر Brave مرورگر اصلیتان است، دو راه پیشرو دارید:
- از مرورگر دیگری مثل Chrome یا Microsoft Edge فقط برای کار با GTM استفاده کنید (چون افزونههای زیادی برای این مرورگرها در دسترس است)
- یا قابلیت امنیتی اصلی Brave یعنی Shields را غیرفعال کنید
پیشنهاد حرفهای ما؟ از یک مرورگر دیگر استفاده کنید. چون اگر بخواهید Shields را غیرفعال کنید، عملاً Brave را بیاثر کردهاید.
۱۶. دامنه سایتتان هنوز از HTTP استفاده میکند؟
اگر وبسایت شما هنوز روی HTTP است و نه HTTPS، احتمالاً با مشکل در حالت پیشنمایش GTM مواجه خواهید شد. این قابلیت فقط روی سایتهایی که گواهینامه امنیتی SSL دارند (و آدرسشان با https شروع میشود) به درستی کار میکند.
✅ راهحل ساده است:
از توسعهدهنده یا مدیر وبسایت خود بخواهید که SSL را فعال کرده و مطمئن شود سایت فقط از طریق HTTPS لود میشود. این کار نه تنها برای GTM لازم است، بلکه برای اعتماد کاربران و سئو سایتتان هم حیاتی است.
۱۷. سیاست امنیتی محتوا (CSP) مانع بارگذاری GTM میشود
اگر وبسایتتان از Content Security Policy (CSP) استفاده میکند، ممکن است همین تنظیمات باعث شود حالت پیشنمایش GTM لود نشود. برای تشخیص این موضوع، میتوانید از کنسول توسعهدهنده مرورگر استفاده کنید.
مراحل کار (در ویندوز و مرورگر کروم):
وارد منوی مرورگر شوید → More Tools → Developer Tools → زبانه Console
صفحه را رفرش کنید و دنبال ارورهایی با محتوای “Content Security Policy” بگردید.
اگر چنین خطایی را دیدید، باید با توسعهدهنده سایت تماس بگیرید تا CSP را اصلاح کند. اینجا دیگر راه میانبری وجود ندارد و حتماً نیاز به تغییر در تنظیمات سمت سرور دارید.
۱۸. افزونه GA Debugger را غیرفعال کنید
اگر هنگام استفاده از GA4، در حالت Preview فقط آیدی را میبینید ولی جزئیاتی نمایش داده نمیشود، احتمالاً افزونه GA Debugger در مرورگر شما فعال است. این افزونه باعث میشود حالت دیباگ مخصوص GA4 کار نکند، اما تأثیری روی دیباگ کلی GTM ندارد و تگهای شما همچنان اجرا میشوند.
راهحل: افزونه GA Debugger را غیرفعال کنید تا بتوانید اطلاعات دقیق GA4 را در حالت پیشنمایش مشاهده کنید.
۱۹. مرورگر را کامل ببندید و دوباره باز کنید
گاهی اوقات فقط بستن تب کافی نیست. باید مرورگر را کاملاً ببندید (در Chrome از منوی سهنقطهای گزینه Exit را انتخاب کنید) و مطمئن شوید که فرآیند آن در پسزمینه هم بسته شده است. سپس مرورگر را مجدد باز کنید و وضعیت را بررسی نمایید.
۲۰. سیستم مدیریت رضایت کوکی (Cookie Consent)
اگر از ابزارهایی مثل OneTrust استفاده میکنید و این ابزارها تا زمانی که کاربر روی «موافقم» کلیک نکرده باشد، GTM را بلاک میکنند، حالت Preview نیز تا آن لحظه فعال نخواهد شد.
راهحل: پس از ورود به سایت در حالت پیشنمایش، روی گزینه «موافقم» یا مشابه آن در نوار کوکی کلیک کنید.
۲۱. آرایهای که Data Layer را خراب میکند
گاهی یک قطعه کد اشتباه میتواند Data Layer را مختل کند. مثلاً اگر آرایهای به شکل نادرست به Data Layer پوش داده شود، حالت Preview چیزی نشان نخواهد داد.
راهحل: با توسعهدهنده سایت همکاری کرده و کدی که مشکل ایجاد میکند را حذف یا افزونهای که آن را اضافه میکند، غیرفعال کنید.
۲۲. VPN میتواند مانع GTM شود
برخی سرویسهای VPN بهمنظور افزایش امنیت، دسترسی به سرویسهایی مثل GTM را مسدود میکنند. اگر از VPN استفاده میکنید و حالت Preview درست عمل نمیکند، VPN را غیرفعال کرده و مجدد تست کنید.
۲۳. افزونه TikTok Pixel Helper را غیرفعال کنید
طبق گزارشها، افزونه TikTok Pixel Helper میتواند باعث اختلال در حالت Preview شود. این احتمال وجود دارد که باگ موقتی باشد، اما تا زمان رفع آن، بهتر است افزونه را غیرفعال کنید.
۲۴. حذف افزونه Tag Assistant
در برخی موارد مشاهده شده که افزونه Tag Assistant باعث ایجاد مشکل در حالت Preview میشود. بهطور خاص، حالت پیشنمایش فقط برای اولین بازدید از صفحه کار میکند و پس از آن قطع میشود.
راهحل: این افزونه را حذف یا غیرفعال کرده و عملکرد مجدد را بررسی نمایید.
یکی از امکانات کاربردی در گوگل تگ منیجر (یا به اختصار GTM) قابلیت ردیابی کلیکهای کاربر روی صفحه وب است. با استفاده از «کلیک تریگر» (Click Trigger)، میتوان مشخص کرد که وقتی کاربر روی یک المان خاص در صفحه کلیک کرد، یک تگ خاص اجرا شود. این قابلیت برای تحلیل رفتار کاربران، بهینهسازی نرخ تبدیل (Conversion Rate) و اجرای دقیقتر کمپینهای دیجیتال مارکتینگ بسیار مفید است.
مراحل تنظیم Click Trigger در Google Tag Manager
۱. ایجاد یک تریگر جدید برای کلیک
در محیط GTM به بخش Triggers بروید و روی دکمه New کلیک کنید تا یک تریگر جدید بسازید.
۲. انتخاب نوع تریگر کلیک
در بخش Trigger Configuration، یکی از گزینههای زیر را انتخاب کنید:
- All Elements: اگر میخواهید تمام کلیکها را ردیابی کنید، از جمله کلیک روی لینکها، دکمهها، تصاویر و سایر المانها.
- Just Links: اگر فقط کلیکهایی را میخواهید ردیابی کنید که روی لینکهای HTML انجام میشوند، مثلاً:
<a href="https://www.google.com">Google</a>
۳. تنظیمات اختیاری برای تریگر “Just Links”
- Wait for Tags: این گزینه را فعال کنید تا GTM صبر کند تا همه تگها اجرا شوند یا مدت زمان مشخصی سپری شود.
- Check Validation: با فعال کردن این گزینه، فقط کلیکهای معتبر منجر به اجرای تگ میشوند. در غیر این صورت، هر کلیکی روی لینک باعث اجرای تگ خواهد شد.
۴. محدودسازی اجرای تریگر برای بهینهسازی عملکرد
برای جلوگیری از اجرای بیرویه تگها و بهبود عملکرد سایت، پیشنهاد میشود شرایطی برای فعال شدن تریگر تعریف کنید:
- در بخش This trigger fires on گزینه Some Clicks را انتخاب کنید.
- سپس در بخش Fire this trigger when an Event occurs and all of these conditions are true یک فیلتر اضافه کنید، مثلاً:
Click URL contains /landing/promo
با این کار، تریگر فقط روی صفحاتی فعال خواهد بود که مسیر URL آنها با الگوی خاصی مطابقت دارد.
تفاوت بین All Elements و Just Links در Google Tag Manager؛ کدام گزینه برای ردیابی کلیک مناسبتر است؟
در هنگام پیکربندی تریگر کلیک در Google Tag Manager، دو گزینه اصلی در اختیار شما قرار دارد: All Elements و Just Links. هر یک از این گزینهها برای سناریوهای خاصی طراحی شدهاند و انتخاب نادرست آنها میتواند دقت دادههای شما را تحت تأثیر قرار دهد.
در این مطلب، به بررسی تفاوت این دو گزینه و کاربردهای مناسب هر کدام میپردازیم.
All Elements؛ ردیابی کلیک روی تمام المانهای صفحه
با انتخاب گزینه All Elements، GTM قادر خواهد بود هر نوع کلیکی را که روی صفحه انجام میشود ردیابی کند؛ فرقی نمیکند کلیک روی لینک، دکمه، تصویر یا حتی یک بلوک متنی باشد.
موارد استفاده از All Elements:
- دکمههایی که با تگ
<button>
طراحی شدهاند - تصاویر قابل کلیک
- آیکونها یا بلوکهایی که با CSS یا جاوااسکریپت تعامل دارند
- المانهایی که بهصورت دستی قابلیت کلیک به آنها اضافه شده است (مثلاً با
onclick
)
🔧 نمونه کد HTML:
htmlCopyEdit<button>افزودن به سبد خرید</button>
<div onclick="...">اطلاعات بیشتر</div>
<img src="banner.jpg" onclick="...">
نکته مهم:
استفاده از All Elements نیازمند فیلترگذاری دقیق است؛ زیرا در غیر این صورت، ممکن است دادههای غیرضروری یا اشتباه ثبت شود.
Just Links؛ ردیابی کلیک فقط روی لینکها
گزینه Just Links مخصوص ردیابی کلیکهایی است که صرفاً روی تگهای HTML از نوع <a>
انجام میشود. این روش سبکتر و دقیقتر است و امکاناتی برای کنترل بیشتر نیز در اختیار شما قرار میدهد.
موارد استفاده از Just Links:
- لینکهای داخلی سایت
- لینک به صفحات خارجی (مانند شبکههای اجتماعی)
- لینکهای دارای پارامتر UTM برای کمپینهای تبلیغاتی
🔧 نمونه کد HTML:
htmlCopyEdit<a href="/product/123">مشاهده محصول</a>
<a href="https://instagram.com/example">اینستاگرام ما</a>
تنظیمات پیشرفته:
- Wait for Tags: GTM منتظر میماند تا اجرای تگها کامل شود.
- Check Validation: فقط کلیکهایی که بهعنوان “اقدام معتبر” در نظر گرفته میشوند، منجر به اجرای تگ خواهند شد.
کدام گزینه را انتخاب کنیم؟
اگرچه گزینه All Elements توانایی ردیابی کلیک روی همه بخشهای صفحه را دارد، اما همیشه بهترین انتخاب نیست. در جدول زیر، مقایسهای بین این دو گزینه ارائه شده است:
نوع تریگر | مناسب برای ردیابی کلیک روی | مزایا | نکات مهم |
---|---|---|---|
All Elements | دکمه، عکس، آیکون، بلوک متنی | پوشش جامع | نیاز به فیلتر دقیق |
Just Links | لینکهای متنی یا تصویری | سبکتر و سریعتر | محدود به تگ <a> |
جمعبندی
استفاده از Click Trigger در Google Tag Manager به شما کمک میکند تا با دقت بالا، رفتار کاربران را تحلیل و بهصورت هدفمند اقدام به اجرای تگها کنید. اگر صاحب یک فروشگاه اینترنتی، وبسایت خدماتی یا حتی یک بلاگ تخصصی هستید، پیشنهاد میشود از این قابلیت بهره ببرید تا بتوانید دادههای دقیقتری از تعامل کاربران جمعآوری کرده و کمپینهای تبلیغاتی خود را بهینه کنید.
نصب Google Tag Manager (GTM) یکی از مهمترین مراحل در راهاندازی ابزارهای آنالیتیکس و بازاریابی دیجیتال در وبسایت است. اما همیشه این سؤال مطرح میشود که بهترین محل قرار دادن کد GTM کجاست؟ در تگ <head>
یا داخل <body>
؟
پیشنهاد رسمی گوگل چیست؟
گوگل بهصورت رسمی پیشنهاد میدهد که کد <script>
مربوط به GTM را در بخش <head>
وبسایت قرار دهید و کد <noscript>
را بلافاصله پس از تگ باز <body>
درج کنید. این کار باعث میشود که GTM در سریعترین زمان ممکن بارگذاری شود و ابزارهای ردیابی بهموقع فعال شوند.
اما اگر شرایط ایدهآل نبود چه؟
گاهی اوقات توسعهدهندگان وب، بهویژه آنهایی که وسواس زیادی روی بهینهسازی سرعت سایت دارند، با این روش موافق نیستند. ممکن است ترجیح دهند که GTM را در انتهای <body>
قرار دهند تا زمان بارگذاری صفحه تحت تأثیر قرار نگیرد.
در برخی موارد نیز، محدودیتهای سیستم مدیریت محتوا (CMS) مانند وردپرس، جوملا یا حتی پلتفرمهای ایرانی، مانع از قرار دادن کد در <head>
میشوند. در چنین شرایطی، ممکن است هر دو بخش کد GTM (اسکریپت و noscript) در داخل <body>
قرار داده شوند—حتی در فوتر سایت.
آیا این روش باعث اختلال در عملکرد GTM میشود؟
خوشبختانه، پاسخ کوتاه این است: نه الزاماً. GTM همچنان کار خواهد کرد، اما نکته کلیدی اینجاست: هرچه کد GTM در محل بالاتری از سورسکد صفحه قرار گیرد، سریعتر بارگذاری میشود. و هرچه زودتر بارگذاری شود، زودتر هم میتواند تگها را اجرا کرده و رفتار کاربران را ثبت کند.
بنابراین اگر GTM را در فوتر سایت قرار دهید، ممکن است در برخی موارد فرصت اجرای تگها را از دست بدهید. مثلاً اگر کاربری قبل از لود کامل GTM، صفحه را ترک کند، آن بازدید در ابزارهایی مانند Google Analytics ثبت نخواهد شد.
چند نکته مهم برای وبمسترها و دیجیتال مارکترها
- قرار دادن GTM در
<body>
بهتر از نداشتن آن است، اما قرار دادن آن در<head>
، بهترین حالت ممکن است. - تنها حالتی که کد GTM باعث خطای HTML خواهد شد، این است که تگ
<noscript>
را در<head>
بگذارید—از این کار خودداری کنید. - اگر سایت شما سرعت پایینی دارد، احتمال از دست رفتن دادههای تحلیلی بیشتر میشود؛ بهویژه اگر کد GTM در پایینترین بخش صفحه قرار گرفته باشد.
نتیجهگیری
در یک دنیای ایدهآل، کد GTM باید دقیقاً طبق توصیه گوگل نصب شود: <script>
در <head>
و <noscript>
درست بعد از <body>
. اما اگر به دلایلی این امکان وجود نداشت، نگران نباشید—GTM همچنان قابل استفاده خواهد بود، فقط ممکن است بخشی از اطلاعات بازدیدها را از دست بدهید.
برای سایتهای ایرانی با سرعت پایین یا هاستهای ضعیف، این موضوع حتی مهمتر است. اگر سئو و تحلیل رفتار کاربران برایتان مهم است، نصب اصولی گوگل تگ منیجر را در اولویت قرار دهید.
آموزش گوگل ادز
تفاوت کانورژن Primary و Secondary
عوارض متوقف شدن کمپین های خوب بازده در گوگل
Enhanced Conversions در گوگل ادز چیست؟
آموزش دیجیتال مارکتینگ
قانون ۷ در بازاریابی چیست؟ | موضوعی مهم برای تدوین مدیا پلن
گروه کنترل در مارکتینگ چیست؟
بهینه سازی اپ استور (ASO) چیست؟ راهنمای جامع سال 2024
فرم درخواست دوره های آموزشی
معرفی کتاب
کتاب انسان در جستجوی معنا
کتاب انسان در جستجوی معنا “Man’s Search for Meaning” که توسط عصبشناس – روانپزشک اتریشی
کتاب مدیریت توجه (Indistractable)
الان که در حال نوشتن مطلب بررسی کتاب مدیریت توجه (Indistractable: How to Control Your