نگــــــــار پـــورجــــــــــواد

متخصص تبلیغات کلیکی، ایکامرس ترکینگ و …

من تا کنون تجربه نصب و راه اندازی ۱۰ ها پراپرتی آنالیتیکس ۴ برای بیزینس‌های مختلف با شرایط متنوع را داشته‌ام. بیزینس‌هایی که همگی با موفقیت و به راحتی از اطلاعات آنالیتیکس یونیورسال خود بک آپ گرفته و به آنالیتیکس ۴ مهاجرت کرده‌اند. بیزینس‌هایی که من تجربه همکاری با آنها را داشته‌ام، در زمینه‌های مختلف از جمله پزشکی، حسابداری، مهاجرت و… فعالیت داشته‌اند. درواقع من نصب و راه اندازی آنالیتیکس بیزینس‌های متنوعی را داشته‌ام؛ بنابراین چالش‌های جدیدی وجود ندارد که من قبل از این با آنها روبه‌رو نشده باشم.

آموزش بیگ کوئری

آموزش بیگ کوئری (BigQuery)

۱۴۰۳-۰۱-۰۳

هزینه ذخیره سازی و پردازش داده در بیگ کوئری چقدر است؟

با توجه به اینکه هزینه Google BigQuery کاملا بر اساس میزان مصرف شما محاسبه می‌شود، در هنگام برآورد هزینه‌ها، عمدتا فقط سه جنبه اصلی در مورد ذخیره سازی داده‌های BigQuery خود باید در نظر بگیرید: ذخیره سازی داده (Storage Data)، ذخیره سازی بلندمدت داده (Long Term Storage Data) و پردازش کوئری (Query Data Usage). صفحه رسمی هزینه بیگ کوئری شامل جزئیات و اطلاعات مفید بسیار بیشتری است که حتما باید آن را بررسی کنید، در این راهنما به طور خلاصه هر یک از این سه عنصر قیمت گذاری را برای برآورد هزینه های ماهانه خود بررسی خواهیم کرد.

برای خرید دوره ۹ ساعته آموزش بیگ کوئری، روی لینک کلیک کنید و فرم موجود را تکمیل کنید. در سریع ترین زمان ممکن به شما تماس میگیرم 🙂

تاثیر هزینه ذخیره سازی بر قیمت استفاده از BigQuery

هزینه‌های ذخیره سازی معمولا به صورت ماهانه برای داده‌هایی که در جداول یا پارتیشن‌های BigQuery ذخیره شده‌اند و فعال هستند، محاسبه می‌شود. منظور از داده‌های فعال، داده‌هایی است که در ۹۰ روز گذشته تغییر کرده‌اند. اگر در ۹۰ روز گذشته هیچ تغییری در جداول یا پارتیشن‌های BigQuery خود ایجاد نکرده‌اید، میتوانید با کاهش ۵۰ درصدی هزینه ها، همچنان داده های خود را در انبار داده بیگ کوئری داشته باشید.

هنگام استفاده از API های ذخیره سازی BigQuery، بسته به حجم داده‌های ورودی ممکن است نیاز به پرداخت هزینه باشد. در این صورت هزینه هر ۲۰۰ مگابایت داده ورودی که با موفقیت در بیگ کوئری ذخیره می شود، ۰.۰۱ دلار است.

تاثیر هزینه کوئری بر قیمت هزینه استفاده از بیگ کوئری

در حالت قیمت گذاری بر اساس میزان مصرف (On-Demand Pricing)، هزینه بر اساس حجم داده پردازش شده کوئری‌هایتان محاسبه می‌شود. برای کوئری‌های ناموفق یا کوئری‌هایی که از حافظه کش بارگذاری شده‌اند، هزینه پرداخت نمی‌کنید. علاوه بر این، اولین ۱ ترابایت داده کوئری پردازش شده در هر ماه رایگان است. همچنین، قیمت‌ها بر اساس منطقه جغرافیایی که هنگام ساخت پروژه در بیگ کوئری تعیین کرده اید، متفاوت است.

به عنوان مثال، انتخاب بمبئی (asia-south1) به عنوان مکان ذخیره سازی ۰.۰۲۳ دلار به ازای هر گیگابایت هزینه از شما دریافت میکند، در حالی که با انتخاب ایالات متحده (چند منطقه ای) (ایالات متحده) یا اتحادیه اروپا (چند منطقه) (اروپا) ۰.۰۲ دلار به ازای هر گیگابایت باید هزینه پرداخت کنید.

در حالت قیمت گذاری با نرخ ثابت (Flat-Rate Pricing)، بدون توجه به حجم داده پردازش شده توسط کوئری‌هایتان، هزینه ثابتی را پرداخت می‌کنید. این گزینه قیمتی برای مشتریانی ایده‌آل است که به هزینه ماهانه قابل پیش بینی با بودجه مشخص نیاز دارند. برای بهره مندی از قیمت گذاری با نرخ ثابت، باید اسلات‌های BigQuery را خریداری کنید که در ادامه به بررسی آن خواهیم پرداخت.

هزینه ذخیره سازی داده در بیگ کوئری چقدر است؟

هزینه ذخیره سازی به فضایی که برای نگهداری اطلاعات خود در BigQuery نیاز دارید اشاره دارد. شما برای هر دو نوع ذخیره سازی فعال و بلندمدت هزینه پرداخت می کنید.

ذخیره سازی فعال: هر جدول یا پارتیشنی از یک جدول که در ۹۰ روز گذشته به روز شده باشد، ذخیره سازی فعال در نظر گرفته می شود. در حال حاضر، BigQuery برای ذخیره سازی فعال، هزینه ماهانه ثابتی معادل ۰.۰۲ دلار به ازای هر گیبی بایت در ماه دریافت می کند. هزینه ذخیره سازی فیزیکی فعال نیز ۰.۰۴ دلار به ازای هر گیگابایت در ماه است. ۱۰ گیبی بایت اولیه هر ماه رایگان است. بنابراین، اگر یک جدول ۲۰۰ گیبی بایتی را برای یک ماه نگه داریم، هزینه آن (۲۰۰ * ۰.۰۲) = 4 دلار خواهد بود.

توجه: با احتساب ۱۰ گیگابایت رایگان هر ماه، کاربر با ۴ دلار مجموعا ۲۱۰ گیگابایت دریافت خواهد کرد.

برای مثال، ذخیره سازی بلندمدت یک جدول ۲۰۰ گیبی بایتی برای یک ماه (۲۰۰ * ۰.۰۱) = 2 دلار هزینه خواهد داشت. اگر جدول به روز شود، به ذخیره سازی فعال تبدیل می شود و دوره ۹۰ روزه مجددا از ابتدا شروع می شود.

ذخیره سازی بلندمدت: هر جدول یا پارتیشنی از یک جدول که در ۹۰ روز گذشته به روز نشده باشد، ذخیره سازی بلندمدت در نظر گرفته می شود. پس از ۹۰ روز، قیمت داده های ذخیره سازی ۵۰ درصد کاهش می یابد. هزینه ذخیره سازی منطقی بلندمدت ۰.۰۱ دلار به ازای هر گیگابایت در ماه است. هزینه ذخیره سازی فیزیکی بلندمدت، بیشتر بوده و ۰.۰۲ دلار به ازای هر گیگابایت در ماه است. ۱۰ گیگابایت اولیه هر ماه رایگان است.برای مثال، ذخیره سازی بلندمدت یک جدول ۲۰۰ گیبی بایتی برای یک ماه (۲۰۰ * ۰.۰۱) = 2 دلار هزینه خواهد داشت. اگر جدول به روز شود، به ذخیره سازی فعال تبدیل می شود و دوره ۹۰ روزه مجددا از ابتدا شروع می شود.

۱ گیبی بایت (gibibyte) معادل ۱.۱ گیگابایت (gigabyte)

عملکرد، پایداری داده و دسترسی در هر دو نوع ذخیره سازی فعال و بلندمدت یکسان است.

هزینه BigQuery به ازای هر ۱ ترابایت

حجم داده‌های ذخیره شده و داده‌های پردازش شده توسط کوئری‌های شما بر حسب گیبی‌بایت (GiB) اندازه‌گیری می‌شود. اگر هزینه هر گیگابایت فضای ذخیره‌سازی ۰.۰۲ دلار باشد و ۱ ترابایت تقریباً معادل ۱,۰۰۰ گیگابایت (۹۳۱.۳۲۳) باشد، در این صورت هزینه ۱ ترابایت ۲۰ دلار خواهد بود.

برای محاسبه هزینه ۵ ترابایت، به سادگی مقدار داده را در ۱۰۰۰ (برای تبدیل به گیبی‌بایت) ضرب می‌کنیم، سپس حاصل را در ۰.۰۲ دلار به ازای هر گیگابایت ضرب می‌کنیم.

۵ ترابایت * ۱۰۰۰ = ۵,۰۰۰ گیبی‌بایت

۵,۰۰۰ گیبی‌بایت * ۰.۰۲ دلار = ۱۰۰ دلار

حجم ذخیره سازی أنواع داده در بیگ کوئری

همانطور که گفته شد، هزینه بر اساس میزان داده ای که در BigQuery قرار می دهید محاسبه می شود. برای تعیین حجم کل داده های خود، باید بدانید که حجم أنواع داده ای که در بیگ کوئری ذخیره می شود، داده چقدر است..در ادامه حجم انواع داده های موجود در BigQuery آورده شده است:

نوع داده	اندازه
INT64	۸ بایت
FLOAT	۸ بایت
NUMERIC	۱۶ بایت
Bool	۱ بایت
STRING	۲ بایت
Date	۸ بایت
Datetime	۸ بایت
Time	۸ بایت
Timestamp	۸ بایت
Interval	۱۶ بایت

جدول هزینه ذخیره داده به ازای هر ۱ گیگابایت در بیگ کوئری

نوع ذخیره سازی	قیمت	سطح رایگان
ذخیره سازی منطقی فعال	۰.۰۲ دلار به ازای هر گیگابایت	۱۰ گیگابایت اول هر ماه رایگان است
ذخیره سازی فیزیکی فعال	۰.۰۴ دلار به ازای هر گیگابایت	۱۰ گیگابایت اول هر ماه رایگان است
ذخیره سازی منطقی بلندمدت	۰.۰۱ دلار به ازای هر گیگابایت	۱۰ گیگابایت اول هر ماه رایگان است
ذخیره سازی فیزیکی بلندمدت	۰.۰۲ دلار به ازای هر گیگابایت	۱۰ گیگابایت اول هر ماه رایگان است

تحلیل ساختار قیمت گذاری کوئری در Google BigQuery

در BigQuery، از قیمت گذاری تحلیلی برای محاسبه هزینه اجرای کوئری‌ها (شامل کوئری‌های SQL، توابع تعریف‌شده توسط کاربر و اسکریپت‌ها) و همچنین قیمت گذاری ذخیره‌سازی برای محاسبه هزینه ذخیره داده‌هایی که در BigQuery بارگذاری می‌کنید، استفاده میشود.

BigQuery دو مدل قیمت‌گذاری مجزا برای انتخاب کاربران هنگام اجرای کوئری ارائه می‌دهد. این مدل های قیمتی به شرح زیر هستند:

قیمت گذاری بر اساس تقاضا (On-demand pricing)

در قیمت‌گذاری بر اساس تقاضا، شما بر اساس اندازه هر کوئری و تعداد بایت‌هایی که توسط هر کوئری مدیریت می‌شود، هزینه پرداخت می‌کنید. در صورت عدم اجرای کوئری، هیچ هزینه‌ای از شما دریافت نمی‌شود. برای تمام کاربران، اولین ترابایت داده کوئری پردازش شده در هر ماه رایگان ارایه می‌شود.

قیمت گذاری با نرخ ثابت (Flat-rate pricing)

با رویکرد قیمت‌گذاری با نرخ ثابت، صرف نظر از حجم داده‌هایی که کوئری‌های شما اشغال می‌کنند، هزینه ثابتی را پرداخت می‌کنید. این بهترین انتخاب قیمت گذاری برای کاربرانی است که یک هزینه ماهانه ثابت را در محدودیت هزینه تعیین شده می‌خواهند. دسترسی کاربران به قیمت گذاری با نرخ ثابت با خرید اسلات‌های BigQuery، که اساسا CPUهای مجازی مورد استفاده BigQuery برای اجرای کوئری‌های SQL هستند، امکان پذیر است. ظرفیت اسلات اختصاصی که خریداری می‌کنید، میزان قدرت پردازش اختصاص‌یافته برای تمام کوئری‌های شما در هر زمان خاص را تعیین می‌کند، نه برای هر کوئری به صورت جداگانه. اگر درخواست‌های شما از ظرفیت اختصاصی شما فراتر رود، BigQuery واحدهای کاری را به صف انتظار می‌فرستد و منتظر می‌شود تا اسلات‌ها در دسترس قرار گیرند.با پیشرفت پردازش کوئری و در دسترس قرار گرفتن اسلات‌ها، واحدهای کاری صف انتظار به صورت پویا برای اجرا انتخاب می‌شوند و هیچ هزینه اضافی دریافت نمی‌شود.

اسلات‌ها در هر دو قیمت گذاری بر اساس تقاضا و با نرخ ثابت استفاده می‌شوند، اما رویکرد با نرخ ثابت کنترل خاصی بر اسلات‌ها و ظرفیت تجزیه و تحلیل به شما ارائه می‌دهد. به عنوان مثال، در قیمت گذاری با نرخ ثابت، می‌توانید انتخاب کنید که اسلات‌ها را برای موارد زیر رزرو کنید:

۶۰ ثانیه: اسلات‌های انعطاف‌پذیر
ماهانه: ۳۰ روز
سالانه: ۳۶۵ روز

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

چه عواملی بر هزینه ذخیره داده در بیگ کوئری تاثیر میگذارند؟

هنگام استفاده از BigQuery با GA4، سه نوع هزینه اصلی وجود دارد که ممکن است متحمل شوید: ذخیره سازی، محاسبات و دریافت داده. این ابزار محاسبه بر ارائه تخمین هزینه ذخیره سازی به شما تمرکز دارد، که جزء کلیدی هزینه کلی BigQuery شما خواهد بود.

هزینه ای که برای ذخیره سازی پرداخت می کنید به میزان داده، مدت زمان ذخیره سازی و مکان ذخیره سازی بستگی دارد. ۱۰ گیگابایت اول ذخیره شده در هر ماه رایگان است، بنابراین بسیاری از سایت های کوچک ممکن است اصلاً هزینه ای پرداخت نکنند.

برای مناطق ایالات متحده (ایالات متحده) و اروپا (اتحادیه اروپا) هر گونه داده ای بالاتر از ۱۰ گیگابایت برای هر گیگابایت در ماه برای ذخیره سازی فعال (هر جدولی که در ۹۰ روز گذشته اصلاح شده است) ۰.۰۲ دلار یا برای ذخیره سازی بلندمدت (هر جدولی که برای بیش از ۹۰ روز اصلاح نشده است) ۰.۰۱ دلار در ماه محاسبه می شود. ممکن است سایر مناطق قیمت گذاری کمی متفاوتی داشته باشند، به عنوان مثال برای منطقه لندن (اروپا-غرب۲) قیمت ۰.۰۲۳ دلار در هر گیگابایت در ماه برای فعال و ۰.۰۱۶ دلار در هر گیگابایت در ماه برای ذخیره سازی بلندمدت است. برای مشاهده قیمت فعلی هر منطقه می توانید به اینجا: BigQuery Pricing مراجعه کنید.

میزان داده ای که در BigQuery ذخیره می کنید به تعداد ایونت هایی که توسط پراپرتی GA4 شما جمع آوری می شود و میزان داده ای که با آن ایونت ها جمع آوری می شود بستگی دارد. اگر با هر ایونت پارامترهای زیادی ارسال می‌کنید یا ایونت های ایکامرسی را با تعداد زیادی آیتم در هر رویداد جمع‌آوری می‌کنید، جداول شما بسیار بزرگتر از سایتی خواهند بود که فقط تنظیمات پیاده سازی آنالیتیکس ۴ را انجام داده است.

گوگل تخمین می زند که ۱ گیگابایت تقریباً معادل ۶۰۰ هزار رویداد است، اما در بین پراپرتی های مختلف، این رقم از ۸۰۰ هزار تا ۱.۶ میلیون متغیر است.

چگونه با استفاده از ماشین حساب هزینه BigQuery، هزینه‌های خود را برآورد کنیم؟

قیمت‌گذاری بر اساس تقاضا (On-demand Pricing)

به صفحه اصلی کنسول BigQuery خود بروید.
هنگام وارد کردن یک کوئری، اعتبارسنج کوئری (علامت تیک سبز) آن را تأیید می‌کند و تخمین می‌زند که چند بایت پردازش کند.

همانطور که در تصویر مشاهده می‌کنید، این کوئری برای اجرا تقریباً ۱۰.۰۷ MB فضا برای پردازش نیاز دارد.

گام بعدی دسترسی به ماشین حساب قیمت‌گذاری GCP است. BigQuery را به عنوان محصول خود و قیمت‌گذاری بر اساس تقاضا را به عنوان روش قیمت‌گذاری خود انتخاب کنید. فرم موجود در صفحه را با تمام اطلاعات لازم، همانطور که در تصویر نشان داده شده است، تکمیل کنید.

اگر هنوز ۱ ترابایت رایگان ماهانه خود را تمام نکرده باشید، هزینه اجرای کوئری صفر است. با این حال، اگر نیاز دارید این کوئری را هر روز برای ماه آینده اجرا کنید؛ قطعا مقدار پردازش رایگان هر ماه را رد خواهید کرد و باید هزینه پرداخت کنید. برای محاسبه این هزینه باید مقدار مورد نیاز برای پردازش کوئری را در ۳۰ ضرب کنید.

چگونه هزینه ذخیره سازی و اجرای کوئری در BigQuery را برآورد کنیم؟

برای محاسبه هزینه ذخیره سازی و اجرای کوئری در BigQuery، ابتدا باید اطلاعات لازم برای تخمین هزینه ها را جمع آوری کنیم:

تعداد کاربران (Number of Users)
تعداد کوئری در روز (Number of Queries)
میانگین حجم دیتای مصرفی (Average Data Usage)

به عنوان مثال، فرض کنید ۱۰ کاربر در روز از دیتایی که از آنالیتیکس به بیگ کوئری انتقال داده شده است، استفاده میکنند. به طوری که هر کاربر روزانه پنج کوئری با میانگین مصرف داده ۲ گیگابایت برای هر کوئری اجرا می کند. ما هزینه را بر اساس ماه (فرض می کنیم ۳۰ روز) محاسبه می کنیم.

با استفاده از این پارامترها، می توانیم با یک محاسبه ساده، هزینه ماهانه متوسط خود را با BigQuery تخمین بزنیم.

کل حجم کوئری دیتا در ماه:

۱۰ کاربر در روز * ۵ کوئری در روز * ۲ گیگابایت در کوئری * ۳۰ روز = 3000 گیگابایت = 3 ترابایت

محاسبه هزینه ذخیره سازی BigQuery:

در زمان نگارش این متن، هزینه ذخیره سازی برای ۱ ترابایت داده حدود ۲۰ دلار است (قیمت دقیق بستگی به منطقه انتخابی شما دارد). بنابراین، برای به دست آوردن هزینه ذخیره سازی در هر ماه، به سادگی ۳ ترابایت را در ۲۰ دلار ضرب می کنیم.

۳ ترابایت * ۲۰ دلار در هر ترابایت = 60 دلار

محاسبه هزینه اجرای کوئری بر اساس میزان مصرف (On-Demand):

با استفاده از همان داده های کوئری، قیمت پردازش ۱ ترابایت داده ۵ دلار است. بنابراین، برای به دست آوردن هزینه اجرای کوئری بر اساس میزان مصرف در هر ماه، به سادگی ۳ ترابایت را در ۵ دلار ضرب می کنیم.

۳ ترابایت * ۵ دلار در هر ترابایت = 15 دلار

این قیمت ممکن است کاهش یابد، به شرطی که از ۱ ترابایت فضای ذخیره سازی رایگان ماهانه خود استفاده نکرده باشید.

هزینه پردازش ۱ ترابایت داده در BigQuery چقدر است؟

برای قیمت گذاری بر اساس میزان مصرف (On-Demand)، هزینه پردازش ۱ ترابایت داده ۶.۲۵ دلار است.

هزینه اجرای یک کوئری ۱۲ گیگابایتی در BigQuery چقدر است؟

۱۲ گیگابایت تقریباً معادل ۰.۰۱۲۸۸ ترابایت است. از آنجایی که هزینه پردازش ۱ ترابایت ۶.۲۵ دلار است، هزینه اجرای یک کوئری ۱۲ گیگابایتی به شرح زیر محاسبه می شود:

۶.۲۵ دلار در هر ترابایت * ۰.۰۱۲۸۸ ترابایت = 0.۰۸ دلار

هزینه اجرای یک کوئری ۱۰۰ گیگابایتی در BigQuery چقدر است؟

۱۰۰ گیگابایت تقریباً معادل ۰.۱۰۷ ترابایت است. برای محاسبه هزینه اجرای یک کوئری ۱۰۰ گیگابایتی، محاسبه زیر را انجام می دهیم:

۶.۲۵ دلار در هر ترابایت * ۰.۱۰۷ ترابایت = 0.۶۶ دلار

آیا استفاده از ویوها (Views) در BigQuery هزینه اضافی دارد؟

خیر. جداول مجازی (Virtual Tables) با استفاده از کوئری های SQL به عنوان ویو تعریف می شوند. به همان روشی که می توانید روی یک کوئری بزنید، می توانید همین کار را با ویوها نیز انجام دهید. ویوها ممکن است فقط داده هایی را از جداول و فیلدهایی ارائه دهند که توسط کاربر هنگام اجرای کوئری درخواست می شود. بنابراین افزودن یا حذف یک ویو هیچ هزینه ای ندارد.

بهینه سازی هزینه BigQuery

به عنوان یک متخصص پرفورمنس مارکتینگ، بهینه سازی هزینه در BigQuery اهمیت زیادی دارد. فرقی نمی کند که داده های خود را از طریق آنالیتیکس ۴ یا از Google Sheets وارد BigQuery کنید، رعایت برخی نکات برای بهینه سازی هزینه در BigQuery ضروری است. این موارد عبارتند از:

*استفاده بهینه از عبارت SELECT : در کوئری های خود از عبارت SELECT * کمتر استفاده کنید و فقط اطلاعات مورد نیاز خود را درخواست نمایید.
استفاده از قابلیت پیش نمایش BigQuery: هنگامی که می خواهید نمونه کوچکی از داده های خود را ببینید، به جای اجرای یک کوئری برای مشاهده بخش کوچکی از داده ها، از قابلیت پیش نمایش BigQuery استفاده کنید.
بررسی هزینه ها قبل از اجرا: قبل از اجرای هر کوئری یا فعالیت ذخیره سازی، با استفاده از ابزار محاسبه گر قیمت GCP (Google Cloud Platform Price Calculator)، هزینه های مرتبط را بررسی کنید.
تقسیم کوئری به بخش های کوچکتر: اگر قصد دارید روی یک مجموعه داده بزرگ پرس و جو انجام دهید، کوئری خود را به بخش های کوچکتر تقسیم کنید. اجرای تک تک کوئری های کوچکتر بهتر است. این کار باعث کاهش حجم داده هایی که باید خوانده شوند و در نتیجه صرفه جویی در هزینه می شود.

آموزش بیگ کوئری (BigQuery), آموزش گوگل ادز

۱۴۰۲-۱۰-۳۰

اتصال گوگل ادز به بیگ کوئری

گوگل ادز یکی از ابزارهای تبلیغاتی محبوب است که توسط بیزینسهای کوچک تا بزرگ برای تبلیغ محصولات و خدمات استفاده می شود. اما گوگل ادز نمی تواند اطلاعات زیادی در مورد کمپین های تبلیغاتی شما ارائه دهد. بنابراین، شما باید داده های خود را از گوگل ادز به بیگ کوئری، یک انبار داده ابری کاملا مدیریت شده و نسبتا کم هزینه، منتقل کنید. با انتقال داده های خود از گوگل ادز به بیگ کوئری، می توانید چندین تحلیل داده انجام دهید تا اطلاعات مفید دوره ای یا زمان واقعی برای بهینه سازی کمپین های خود بدست اورید. در این راهنما، ما به قدم فرآیند انتقال داده های گوگل ادز به بیگ کوئری را با استفاده از چند روش ساده بررسی خواهیم کرد.

مقدمه‌ای بر گوگل ادز

گوگل ادز یکی از پلتفرم‌های تبلیغات آنلاین پرکاربرد است که به شما امکان می‌دهد تا خدمات و محصولات خود را تبلیغ کنید. این پلتفرم گزینه‌های متنوعی برای هدف‌گیری مخاطبان دارد تا آگهی‌های محصول یا خدمات توسط مخاطبین مرتبط در زمان درست مشاهده ‌شوند. شما می‌توانید از گوگل ادز برای نمایش تبلیغات از طریق تصاویر، تماس تلفنی، متن و ویدئو، بسته به کمپین تبلیغاتی و هدف خود استفاده کنید. برای بهبود عملکرد، گوگل ادز از قابلیت تبلیغات ریسپانسیو و از دستگاه‌های مختلف مانند دسکتاپ، موبایل، تلویزیون و غیره پشتیبانی می‌کنند.

علاوه بر این، گوگل ادز ابزارهای جامع تحلیلی و گزارش‌دهی ارائه می‌دهد که اطلاعات مفیدی در مورد عملکرد کمپین‌های تبلیغاتی در اختیارتان قرار می‌دهد. برای سنجش اثربخشی کمپین‌های تبلیغاتی خود، می‌توانید معیارهایی مانند دسترسی، نرخ کلیک‌ها (CTR)، نرخ تبدیل و بازگشت سرمایه (ROI) را ردیابی کنید. همچنین این فرصت را در اختیار شما قرار میدهد که با دقت بودجه خود را کنترل کنید و حداکثر بودجه روزانه یا ماهانه را برای مدیریت موثر هزینه‌های تبلیغاتی خود تعیین کنید.

مقدمه‌ای بر بیگ کوئری

گوگل بیگ کوئری، یک انبار داده‌های بدون سرور و پلتفرم تحلیلی است که توسط گوگل کلود ارائه می‌شود. بیگ کوئری به عنوان یک انبار داده‌های آماده، امکان ذخیره‌سازی و استخراج گزارش های کاربردی از مجموعه داده‌های بزرگ (بیگ دیتا) را برای بیزینس های مختلف در هر مقیاسی فراهم می‌آورد. برای مدیریت و تحلیل داده‌ها، بیگ کوئری از زبان SQL پشتیبانی می‌کند که این امر برای طیف وسیعی از متخصصان، فرآیند کار را بدون درز می‌کند.

علاوه بر این، به عنوان بخشی از گوگل کلود، بیگ کوئری به راحتی با سایر خدمات گوگل کلود مانند گوگل کلود استوریج، گوگل شیتس و گوگل دیتا استودیو یکپارچه می‌شود. این یکپارچگی، جذب سریع داده‌ها، ذخیره‌سازی و تجسم آن‌ها را فراهم می‌کند و یک اکوسیستم تحلیلی جامع را ارائه می‌دهد.

بیگ کوئری همچنین با پشتیبانی از تحلیل داده‌های زمان واقعی از طریق جذب داده‌های جاری، به شما کمک می‌کند تا بینش‌های لحظه‌ای را به دست آورید و تصمیمات مبتنی بر داده را به سرعت اتخاذ کنید.

روش های اتصال گوگل ادز به بیگ کوئری

روش‌های متنوعی برای ادغام داده‌های گوگل ادز با بیگ کوئری گوگل وجود دارد. در ادامه برخی از رایج‌ترین روش‌های استفاده شده برای انتقال داده‌ها از گوگل ادز به بیگ کوئری را به شما عزیزان آموزش میدهیم.

روش ۱: بارگذاری دستی داده‌ها از گوگل ادز به بیگ کوئری با استفاده از فایل‌های CSV . این روش شامل استخراج داده‌ها از گوگل ادز به صورت فایل CSV و سپس بارگذاری آنها در بیگ کوئری است. این فرآیند می‌تواند به صورت دستی انجام شود و یک روش مستقیم برای اتصال گوگل ادز به بیگ کوئری است.
روش ۲: بارگذاری داده‌ها از گوگل ادز به بیگ کوئری با استفاده از سرویس انتقال داده بیگ کوئری. سرویس انتقال داده بیگ کوئری گوگل امکان اتوماتیک کردن فرآیند انتقال داده‌ها را فراهم می‌آورد. این روش به کاربران اجازه می‌دهد تا داده‌ها را به صورت خودکار و بدون دخالت دستی از گوگل ادز به بیگ کوئری منتقل کنند.

بارگذاری دستی داده‌ها از گوگل ادز به بیگ کوئری با استفاده از فایل‌های CSV

اگر به دنبال روشی فوری برای انتقال داده‌ها از گوگل ادز به بیگ کوئری هستید، استفاده از فایل‌های CSV گزینه مناسبی است. تنها کاری که لازم است انجام دهید، خروجی گرفتن از داده‌های گوگل ادز به صورت فایل‌های CSV و سپس بارگذاری این فایل‌ها در بیگ کوئری است.

مرحله ۱: وارد حساب گوگل ادز خود شوید و از گزارش تبلیغات یا کمپینی که می‌خواهید تحلیل کنید، خروجی بگیرید. می‌توانید این گزارش را با تنظیم بخش‌ها، فیلدها، تاریخ و زمانی که می‌خواهید در فایل CSV خود خروجی بگیرید، سفارشی سازی کنید.

مرحله ۲: پس از انتخاب گزارش مورد نظر، روی دکمه دانلود واقع در سمت راست صفحه کلیک کنید. یک پنجره بازشو ظاهر می‌شود، فرمت فایل را به عنوان CSV برای دانلود فایل انتخاب کنید.

مرحله ۳: حالا، فایل CSV شما آماده بارگذاری در انبار داده‌های بیگ کوئری است. پیش از بارگذاری داده‌ها در بیگ کوئری، مطمئن شوید که یک دیتاست بیگ کوئری برای ذخیره داده‌های خود دارید. سپس، می‌توانید داده‌های CSV را در یک جدول بیگ کوئری جدید بارگذاری کنید.

هر چند این روند به طور کلی ساده است، اما با محدودیت‌های تاخیر و آسیب‌پذیری به خطاها همراه است.

بارگذاری گوگل ادز به بیگ کوئری با استفاده از سرویس انتقال داده‌های بیگ کوئری

روش دیگر برای انتقال اطلاعات گوگل ادز به بیگ کوئری، استفاده از سرویس انتقال داده‌های بیگ کوئری است. این سرویس به طور خودکار زمان‌بندی، بارگذاری، و مدیریت داده‌های مورد نیاز از گوگل ادز به جداول بیگ کوئری شما را به طور منظم انجام می‌دهد. قبل از انتقال گوگل ادز به بیگ کوئری، اطمینان حاصل کنید که دارای دسترسی های زیر هستید:

دسترسی ادمین در بیگ کوئری.
دسترسی حداقل read در حساب گوگل ادز.
فعال کردن سرویس انتقال داده‌های بیگ کوئری.

شما می‌توانید اطلاعات گوگل ادز را به بیگ کوئری با استفاده از سرویس انتقال داده‌ها به چهار روش منتقل کنید:

کنسول گوگل کلود
ابزار خط فرمان bq
API سرویس انتقال داده‌ها
زبان برنامه‌نویسی جاوا

در این روش، ما از کنسول گوگل کلود برای انتقال داده‌ها از گوگل ادز به بیگ کوئری استفاده خواهیم کرد.

گام ۱: وارد پلتفرم گوگل کلود شوید و صفحه بیگ کوئری را باز کنید.

بارگذاری گوگل ادز به بیگ کوئری با استفاده از سرویس انتقال داده‌های بیگ کوئری

گام ۲: روی گزینه انتقال داده‌ها در سمت چپ پنل کلیک کنید.

گام ۳: حالا روی گزینه Creat a Transfer کلیک کنید.

به صفحه ایجاد انتقال هدایت خواهید شد. در بخش نوع سورس، گوگل ادز را جستجو کنید.

گام ۴: در بخش Transfer config name، نام منحصر به فردی برای این انتقال داده وارد کنید. سپس، در بخش گزینه‌های برنامه‌ریزی، می‌توانید زمان‌بندی انتقال خود را با انتخاب فرکانس و زمان شروع انتقال مشخص کنید.

الف) میتوانید فرکانس به روز شدن اطلاعات را تعیین کنید. می‌توانید گزینه‌های روزانه (پیش‌فرض)، هفتگی، ماهانه، سفارشی، یا درخواستی را از جعبه کشویی تکرار انتخاب کنید.

ب) در گزینه دوم، می‌توانید حالت هم اکنون شروع کنید تا یا روی گزینه شروع در زمان تعیین شده برای شروع فرآیند انتقال داده از گوگل ادز به بیگ کوئری کلیک کنید تا انتقال داده‌های خود را زمان‌بندی کنید.

گام ۵: در بخش Destination settings، دیتاست مورد نظر برای ذخیره داده‌های گوگل ادز خود را ایجاد کنید یا انتخاب کنید.

گام ۶: در بخش Data source details، کاستومر آیدی حساب گوگل ادز را وارد کنید.

گام ۷: به طور پیش‌فرض، Refresh window به مدت ۷ روز تنظیم شده است تا داده‌های ۷ روز گذشته را در هر انتقال وارد بیگ کوئری و به‌روزرسانی کند. با این حال، می‌توانید این مقدار را به ۳۰ روز تغییر دهید.

گام ۸: گزینه‌های اطلاع‌رسانی ایمیل را فعال کنید تا هر زمان که روند انتقال با مشکل رو به رو شود، اطلاعیه ایمیل دریافت کنید.

گام ۹: روی دکمه ذخیره کلیک کنید.

نتیجه‌گیری

انتقال داده‌ها از گوگل ادز به بیگ کوئری به شما امکان انجام تحلیل‌های پیشرفته از طریق ماشین لرنینگ و ابزارهای قدرتمند تصویرسازی را فراهم میکند. تمامی روش‌هایی که در این راهنما پوشش داده شده‌اند، می‌توانند به طور موثری داده‌های گوگل ادز را با بیگ کوئری ادغام کرده و به شما کمک کنند تا تحلیل بهتری برای بهینه‌سازی کمپین تبلیغاتی خود انجام دهید.

آموزش بیگ کوئری (BigQuery)

۱۴۰۲-۰۸-۰۷

جدول pseudonymous_users و users در بیگ کوئری

در یکی از به روز رسانی های مربوط به اتصال بیگ کوئری به آنالیتیکس ۴، بخشی به اسم 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	احتمال اینکه کاربری که در ۲۸ روز گذشته فعال بوده است، یک رویداد in_app_purchase را طی ۷ روز آینده انجام دهد
predictions.purchase_score_7d	DOUBLE	احتمال اینکه کاربری که در ۲۸ روز گذشته فعال بوده است، یک ایونت خرید را طی ۷ روز آینده انجام دهد.
predictions.churn_score_7d	DOUBLE	احتمال اینکه کاربری که در ۷ روز گذشته در اپلیکیشن یا سایت شما فعال بوده است، در ۷ روز آینده فعال نخواهد بود.
predictions.revenue_28d_in_usd	FLOAT	درآمد مورد انتظار (به دلار آمریکا) از همه ایونت های خرید در ۲۸ روز آینده توسط کاربری که در ۲۸ روز گذشته فعال بوده است.

جدول 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 است که به آخرین زمانی که کاربر اکتیو بوده است، اشاره دارد.

آموزش بیگ کوئری (BigQuery)

۱۴۰۲-۰۶-۳۰

آموزش توابع مربوط به تاریخ و زمان در بیگ کوئری

بیگ کوئری از چهار گروه تابع مربوط به تاریخ و زمان DATE، TIME، DATETIME، و TIMESTAMP پشتیبانی می کند. این ۴ گروه شامل توابع خاص‌تری مانند 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 تغییر دهید. به عنوان مثال، بعد از اتصال آنالیتیکس ۴ به بیگ کوئری، در بخش اسکیمای جدول آنالیتیکس متوجه می‌شوید که اطلاعات مربوط به 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 حاوی مقادیری است که از (۹,۲۲۳,۳۷۲,۰۳۶,۸۵۴,۷۷۵,۸۰۸- تا ۹,۲۲۳,۳۷۲,۰۳۶,۸۵۴,۷۷۵,۸۰۷-) متغیر است.
به جای بخش 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 حاوی مقادیری است که از (۹,۲۲۳,۳۷۲,۰۳۶,۸۵۴,۷۷۵,۸۰۸- تا ۹,۲۲۳,۳۷۲,۰۳۶,۸۵۴,۷۷۵,۸۰۷-) متغیر است.
به جای بخش 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))

۷-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;

۸-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;

۹-date-diff

نحوه تبدیل انواع داده‌های تاریخ و زمان در BigQuery

با تابع CAST میتوانید نوع یک داده را به یک نوع دیگر تبدیل کنیم. نحوه استفاده از تابع CAST به صورت زیر است:

CAST(expression AS datatype)

تبدیل رشته به تاریخ یا زمان

SELECT

CAST(’19:30:12′ AS TIME) AS time

۱۰-cast-string

تبدیل datetime به date

SELECT

CAST(CURRENT_DATETIME() AS DATE);

۱۱-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’))

۱۲-date-comparison

خدمات نصب و راه اندازی آنالیتیکس ۴

قبل از شروع صحبت در مورد مهاجرت به آنالیتیکس ۴، مهم است که تنظیمات GA فعلی شما را بررسی کنم. قبل از هرچیز من تمام ایونت ترکینگ هایی که انجام داده اید را بررسی می‌کنم. بعد از آن نوبت به بررسی تنظیمات آنالیتیکس شما میرسد. سپس بر اساس آنچه که میتوانید ردیابی کنید اما هنوز این کار را انجام نداده اید، پیشنهادات خودم را در اختیار شما قرار میدهم. بسیاری از مشتریان نمی‌دانند (یا مطمئن نیستند که چگونه باید ایونت ترکینگ را انجام دهند. بر اساس تجربه میگویم که بسیاری از صاحبان بیزینس‌های مختلف نمیدانند که میتوانند به اطلاعاتی مانند تجزیه و تحلیل ویدیو، تراکنش‌ها، پر کردن فرم‌ها و حتی موارد دیگر با استفاده از GA4 دسترسی داشته باشند. اما جای نگرانی نیست؛ چون من این کار را به طور کامل برای شما انجام خواهم داد.

آموزش آنالیتیکس ۴

آموزش گوگل آنالیتیکس ۴ (GA4)

۱۴۰۴-۰۵-۱۳

Move Property در آنالیتیکس ۴ چیست؟

در گذشته، انتقال پراپرتی بین اکانت های Google Analytics امکان‌پذیر نبود. گوگل به تازگی قابلیت انتقال پراپرتی را معرفی کرده است که به شما اجازه می‌دهد یک پراپرتی منبع را به پراپرتی مقصد در چند کلیک منتقل کنید. کاربران GA4 می‌توانند چندین پراپرتی در یک اکانت داشته باشند که این امر تحلیل داده‌ها و مدیریت پراپرتی ها را تسهیل می‌کند. در این محتوای آموزشی، مراحل ساده انتقال پراپرتی آنالیتیکس ۴ به اکانت دیگری را به شما آموزش می‌دهد.

سه دلیل برای انتقال یک پراپرتی در گوگل آنالیتیکس ۴

دلایل متعددی برای انتقال یک پراپرتی از یک اکانت گوگل آنالیتیکس به اکانت دیگر وجود دارد. در ادامه، ۲ مورد از رایج‌ترین آنها را بررسی می‌کنیم:

افزایش کنترل بر پراپرتی: اگر پراپرتی شما در اکانت گوگل فرد یا تیم دیگری باشد (مانند تیم بازاریابی)، انتقال پراپرتی به اکانت شخصی خود می‌تواند به شما امکان کنترل بیشتر بر داده‌های آن را بدهد.
حذف اکانت GA4: اگر قصد دارید یک اکانت گوگل آنالیتیکس که دیگر استفاده نمی‌شود را حذف کنید، اما همچنان می‌خواهید داده‌های پراپرتی خود را حفظ کنید، انتقال پراپرتی می‌تواند راهکار مناسبی باشد.

با انجام Move Property چه اتفاقی رخ میدهد؟

اگر یک پراپرتی (Property) را در گوگل آنالیتیکس به اکانت دیگری منتقل کنید، اتفاقات زیر رخ خواهد داد:

تمام دیتا استریم ها، داده‌های ایمپورت شده، داده های قدیمی، گزارش های سفارشی و Custom Definationها که به آن پراپرتی مربوط هستند، از اکانت مبدأ به اکانت مقصد منتقل می‌شوند.

کد رهگیری (Tracking Code) پراپرتی تغییر نمی‌کند و همان شناسه رهگیری (ID) باقی می‌ماند، حتی بعد از انتقال.

برخی از اکانتهای لینک شده به پراپرتی آنالیتیکس ۴ به اکانت مقصد متصل می‌شوند (مانند گوگل سرچ کنسول، گوگل ادز، بیگ کوئری و غیره).
تنظیمات و فیلترهای دیگر به اکانت مقصد کپی می‌شوند، مگر اینکه اکانت مقصد همان فیلتر را داشته باشد. در این صورت، فیلترهای موجود در اکانت مبدأ از بین نمی‌روند.

به طور خلاصه، بیشتر داده‌ها و تنظیمات پراپرتی به صورت کامل به اکانت جدید منتقل می‌شوند و تغییر خاصی در کد رهگیری یا داده‌های اصلی نخواهد بود، مگر در موارد استثنا.

نحوه انتقال یک پراپرتی از یک اکانت به اکانت دیگر در آنالیتیکس

برای انتقال یک پراپرتی در گوگل آنالیتیکس به یک اکانت دیگر، باید مطمئن شوید که دارای دسترسی “Admin” هستید. تنها کاربرانی که این سطح دسترسی را دارند، امکان استفاده از ویژگی انتقال پراپرتی را دارند.

بسیاری از سازمان‌ها و شرکت‌های بازاریابی این دسترسی‌ها را به مشتریان خود نمی‌دهند، زیرا در این صورت، آن‌ها به دیگر پراپرتی‌های مشتریان نیز دسترسی خواهند داشت.

بنابراین، قبل از اقدام به انتقال، از داشتن دسترسی‌های لازم اطمینان حاصل کنید. پس از آن، می‌توانید تنها در چهار مرحله، یک پراپرتی GA4 را از یک اکانت به اکانت دیگری منتقل کنید.

مرحله ۱: ورود به بخش تنظیمات پنل Admin

ابتدا وارد اکانت کاربری Google Analytics خود شوید و پنل Admin را باز کنید. پس از ورود به بخش مدیریت GA4، می‌توانید به مرحله بعد بروید.

مرحله ۲: انتخاب تنظیمات پراپرتی (Property) و کلیک روی “انتقال پراپرتی”

در پنل مدیریت، روی گزینه “Property Settings” کلیک کنید. صفحه جدیدی برای تنظیمات باز می‌شود. پراپرتی مورد نظر را پیدا کنید، روی گزینه “Move Property” کلیک کنید و به صفحه بعد بروید.

مرحله ۳: انتخاب اکانت مقصد و تأیید دسترسی‌های پراپرتی

در این مرحله، باید اکانت مقصدی که می‌خواهید پراپرتی را به آن منتقل کنید، انتخاب کنید و سپس درباره دسترسی‌های کاربران تصمیم بگیرید.
دو گزینه برای دسترسی‌های پراپرتی وجود دارد:

جایگزینی دسترسی‌ها: دسترسی‌های پراپرتی منتقل‌شده از اکانت مقصد به ارث برده می‌شوند.
حفظ دسترسی‌های فعلی: تمامی دسترسی‌های فعلی همراه با پراپرتی منتقل می‌شوند.

گزینه مناسب را انتخاب کرده، تیک “تأیید تغییرات” را بزنید، روی “ذخیره” کلیک کنید و ادامه دهید.

مرحله ۴: تغییر مالکیت پراپرتی در Google Analytics

در این مرحله درخواست انتقال انجام می‌شود و باید چند دقیقه منتظر بمانید تا انتقال به اکانت مقصد با موفقیت انجام شود.
سپس روی “رفتن به خانه” کلیک کنید و پس از مدت کوتاهی پراپرتی مورد نظر در اکانت مقصد GA4 نمایش داده خواهد شد. به این ترتیب پراپرتی به اکانت جدید در Google Analytics منتقل می‌شود.

دلایلی که نمی‌توانید یک Property در گوگل آنالیتیکس (GA4) جابه‌جا کنید:

اگرچه جابه‌جایی یک Property در GA4 به‌طور کلی فرآیندی ساده است، اما در برخی موارد ممکن است با مشکل مواجه شوید. این مشکلات معمولاً به دلیل رعایت نکردن قوانین پایه جابه‌جایی Property‌ها پیش می‌آید. سه دلیل اصلی که باعث می‌شود نتوانید یک Property را از یک اکانت به اکانت دیگر منتقل کنید عبارتند از:

اتصال Property به Google Ad Manager. اگر پراپرتی به Google Ad Manager متصل باشد، باید ابتدا آن را از این سرویس جدا کنید.
شما در حال تلاش برای جابه‌جایی یک Roll-Up Property هستید. اگر می‌خواهید یک Roll-Up Property را جابه‌جا کنید (یعنی یک Property که داده‌های چند Property دیگر را در خود دارد)، ابتدا باید تمام Property‌های منبع آن را حذف کنید. همچنین اگر می‌خواهید یک Property منبع را جابه‌جا کنید، باید آن را از Roll-Up Property جدا کنید. برای انجام این کار، می‌توانید از طریق پنل مدیریت GA4 به بخش تنظیمات Property بروید و آن را از Roll-Up جدا کنید.
پردازش گزارش‌های سمپل نشده (Unsampled Reports). اگر برای پراپرتی گزارش‌هایی در حال پردازش باشند که بدون نمونه‌گیری اجرا شده‌اند، انتقال انجام نمی‌شود. در این حالت باید صبر کنید تا پردازش این گزارش‌ها تمام شود و سپس مجدداً عملیات انتقال را انجام دهید.
محدودیت تعداد Property در حساب مقصد. هر اکانت در آنالیتیکس ۴ به طور پیش‌فرض می‌تواند حداکثر ۵۰ پراپرتی داشته باشد. اگر این سقف پر شده باشد، امکان انتقال پراپرتی جدید وجود ندارد.

آموزش گوگل آنالیتیکس ۴ (GA4)

۱۴۰۴-۰۴-۲۴

Conversion Window در آنالیتیکس ۴ (GA4) چیست و چگونه باید تنظیم شود؟

یکی از مفاهیم کلیدی در تحلیل رفتار کاربران و اندازه‌گیری اثربخشی کمپین‌های تبلیغاتی در Google Analytics 4، مفهوم Conversion Window یا همان پنجره تبدیل است. در این مقاله، به زبان ساده و کاربردی توضیح می‌دهیم که Conversion Window چیست، چه تأثیری بر داده‌های شما دارد، تنظیم پیش‌فرض آن در GA4 چگونه است، و بهترین روش برای تنظیم بهینه آن چیست.

Conversion Window بازه‌ای زمانی (بر حسب روز) است که تعیین می‌کند یک «نقطه تماس» (Touchpoint) ، مثل کلیک روی یک تبلیغ، بازدید از صفحه فرود یا تعامل با یک کمپین ایمیلی، تا چه مدت می‌تواند به‌عنوان منبع یک «تبدیل» (Conversion) شناسایی و ثبت شود.

به زبان ساده:
اگر پنجره تبدیل روی ۳۰ روز تنظیم شده باشد، یعنی اگر کاربر تا ۳۰ روز پس از اولین تعامل، تبدیل (مثلاً خرید) انجام دهد، نقطه تماس اولیه اعتبار تبدیل را دریافت می‌کند.

در اسکرین‌شات، بخش تنظیمات GA4 را می‌بینیم که در آن می‌توان پنجره تبدیل برای رویدادهای مختلف را مشخص کرد.
مثلاً برای رویدادهای جذب (Acquisition Key Events) مانند first_visit یا first_open، گزینه‌های زیر وجود دارد:

۷ روز
۳۰ روز (پیش‌فرض)

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

۳۰ روز
۶۰ روز
۹۰ روز
یکی را انتخاب کرد.

آموزش گوگل آنالیتیکس ۴ (GA4)

۱۴۰۴-۰۴-۲۱

افزایش ترافیک دایرکت (Direct) در آنالیتیکس ۴ [علت و روش اصلاح]

در صورتی که به‌طور منظم گزارش‌های تحلیلی Google Analytics را بررسی می‌کنید، ممکن است متوجه رشد تدریجی ترافیک دایرکت (Direct) در وب‌سایت خود شده باشید. این روند اگر نادیده گرفته شود، می‌تواند به جایی برسد که بخش قابل‌توجهی از ورودی‌های وب‌سایت، بدون منبع مشخص ثبت شود؛ به‌عبارتی «دایرکت».

زمانی که منبع ورودی کاربران به‌درستی شناسایی نشود، تحلیل اثربخشی کانال‌های بازاریابی، ارزیابی عملکرد کمپین‌ها و حتی تصمیم‌گیری برای تخصیص بودجه تبلیغاتی، با خطا مواجه خواهد شد. در این مقاله، دلایل اصلی افزایش ترافیک دایرکت (Direct) بررسی شده و راهکارهایی برای اصلاح این مسئله در ساختار تحلیلی GA4 ارائه خواهد شد.

دلایل رایج افزایش ترافیک دایرکت (Direct) در گزارش‌های Google Analytics

در ادامه، فهرستی از شایع‌ترین عوامل ثبت نادرست منبع ترافیک کاربران به‌صورت دایرکت (Direct) ارائه می‌شود:

تگ‌گذاری نادرست در URLهای مربوط به کمپین‌های بازاریابی
نبود کد رهگیری Google Analytics در تعدادی از صفحات وب‌سایت
ارسال ایمیل‌های تبلیغاتی بدون تگ‌گذاری صحیح
تنیمات نادرست کراس دامین ترکینگ (Cross-Domain Tracking)
استفاده از ساختار Headless در طراحی سایت
استفاده از اپلیکیشن‌های تک‌صفحه‌ای (SPA)
عدم فیلترگذاری مناسب بر روی ترافیک داخلی سازمان
استفاده از (HTTP) در برخی صفحات
اختلال در ثبت Referrer به‌دلیل کش مرورگر
طراحی نامناسب فرآیند جذب سرنخ که منجر به ثبت ترافیک به‌صورت دایرکت می‌شود
استفاده کاربران از افزونه‌های مسدودکننده تبلیغات (Adblocker)
افزایش آگاهی از برند و ورود مستقیم کاربران از طریق بوکمارک یا تایپ URL
ثبت ترافیک جعلی ناشی از فعالیت اسپم‌بات‌ها

۱. تگ‌گذاری نادرست در URLهای کمپین‌های بازاریابی

یکی از مهم‌ترین دلایلی که موجب افزایش ترافیک دایرکت (Direct) در گزارش‌های Google Analytics می‌شود، تگ‌گذاری نادرست یا ناقص URLهای مورد استفاده در کمپین‌های بازاریابی است.

در صورتی که لینک‌های کمپین‌های ایمیلی، شبکه‌های اجتماعی، تبلیغات کلیکی یا حتی پیامک‌ها به‌درستی تگ‌گذاری نشده باشند، مرورگر کاربر نمی‌تواند منبع ارجاع‌دهنده (Referrer) را به Google Analytics ارسال کند. در نتیجه، آنالیتیکس این بازدید را به‌صورت دایرکت ثبت خواهد کرد، در حالی که واقعیت چنین نیست.

به‌عنوان مثال، اگر در یک کمپین تبلیغاتی در تلگرام یا لینکدین، از لینکی استفاده شود که فاقد پارامترهای UTM باشد، ممکن است ورودی کاربران از طریق آن کمپین در Google Analytics به‌عنوان دایرکت (Direct) شناسایی شوند. این موضوع نه‌تنها باعث گمراهی در تحلیل عملکرد کمپین‌ها می‌شود، بلکه می‌تواند ارزیابی کلی از منابع ورودی را نیز مخدوش کند.

راهکار پیشنهادی:

برای پیشگیری از این خطا، توصیه می‌شود از ابزار Google URL Builder یا سایر ابزارهای معتبر جهت تولید لینک‌های تگ‌گذاری‌شده استفاده شود. به کمک این ابزار می‌توان پارامترهای تحلیلی زیر را به لینک‌ها اضافه کرد:

utm_source: مشخص‌کننده منبع ترافیک (مثلاً telegram، newsletter)
utm_medium: نوع رسانه یا کانال (مثلاً cpc، social، email)
utm_campaign: نام کمپین
utm_content و utm_term (در صورت نیاز برای جزئیات بیشتر)

نمونه لینک تگ‌گذاری‌شده:
https://example.com/landing-page/?utm_source=telegram&utm_medium=cpc&utm_campaign=summer_offer

همان لینک بدون تگ:

https://example.com/landing-page/

۲. نبود کد رهگیری Google Analytics در برخی از صفحات وب‌سایت

یکی دیگر از دلایل افزایش ثبت ترافیک به‌صورت دایرکت (Direct)، عدم وجود یا بارگذاری ناقص کد رهگیری Google Analytics در برخی از صفحات وب‌سایت است. این موضوع معمولاً در وب‌سایت‌هایی مشاهده می‌شود که دارای ساختار پیچیده، صفحات فرعی متعدد یا چندین قالب (Template) متفاوت هستند.

در صورتی که کاربر از طریق یک کمپین وارد صفحه‌ای از سایت شود که فاقد کد رهگیری باشد، Google Analytics نمی‌تواند آن بازدید را ثبت کند. اگر کاربر از آن صفحه به صفحه‌ای دیگر (که کد رهگیری دارد) هدایت شود، آنالیتیکس آن بازدید را به‌عنوان شروعی جدید در نظر گرفته و از آنجا که اطلاعاتی درباره منبع اولیه در دست ندارد، آن را به‌صورت دایرکت (Direct) ثبت می‌کند.

این اتفاق به‌ویژه در شرایط زیر بیشتر رخ می‌دهد:

وجود صفحات قدیمی که به‌روز نشده‌اند و هنوز کد رهگیری در آن‌ها درج نشده است
عدم هماهنگی میان تیم فنی و بازاریابی در زمان انتشار صفحات لندینگ کمپین‌ها
خطاهای فنی یا اسکریپت‌هایی که مانع از بارگذاری صحیح کد رهگیری می‌شوند (مثلاً تداخل با پلاگین‌ها یا خطا در بارگذاری تگ‌ها)

راهکار پیشنهادی:

۱. ممیزی کامل صفحات سایت
با استفاده از ابزارهایی مانند Google Tag Assistant یا افزونه‌های مرورگر مانند GA Debugger می‌توانید بررسی کنید که آیا در تمامی صفحات موردنظر، تگ‌های رهگیری فعال هستند یا خیر.

۲. یکپارچه‌سازی کد رهگیری در قالب‌ها
در صورت استفاده از CMS مانند وردپرس یا سیستم‌های مشابه، توصیه می‌شود کد رهگیری Google Analytics در بخش‌های مشترک قالب سایت (مانند Header یا Footer) قرار گیرد تا در تمام صفحات به‌صورت خودکار بارگذاری شود.

۳. استفاده از گوگل تگ منیجر
انتقال مدیریت تگ‌ها به GTM باعث افزایش دقت، انعطاف‌پذیری و قابلیت کنترل بهتر می‌شود. به‌علاوه، با استفاده از تریگرها و شرط‌ها می‌توان تضمین کرد که کد رهگیری تنها در صفحات مورد نظر یا در همه صفحات سایت به‌درستی فعال شود.

۳. ارسال ایمیل‌های تبلیغاتی بدون تگ‌گذاری صحیح

کمپین‌های ایمیلی یکی از پرکاربردترین ابزارهای بازاریابی دیجیتال محسوب می‌شوند. با این حال، در صورتی که لینک‌های موجود در ایمیل‌ها فاقد پارامترهای تحلیلی UTM باشند، Google Analytics نمی‌تواند منبع واقعی بازدید کاربران را شناسایی کند و ترافیک حاصل از این ایمیل‌ها را به‌صورت دایرکت (Direct) ثبت خواهد کرد.

در بسیاری از سیستم‌های مدیریت ایمیل (چه خارجی مانند Mailchimp و چه داخلی مانند نجوا یا پاکت)، اگر قابلیت تگ‌گذاری خودکار لینک‌ها فعال نباشد، تمامی کلیک‌های دریافتی از ایمیل‌ها در آنالیتیکس، بدون منبع مشخص ثبت می‌شوند. این موضوع به‌ویژه زمانی که در حال اجرای کمپین‌های چندمرحله‌ای (Multi-Touch) هستید، موجب ایجاد خطای تحلیلی قابل‌توجه خواهد شد.

راهکار پیشنهادی:

۱. تگ‌گذاری همه لینک‌های موجود در ایمیل:
پیش از ارسال هر کمپین ایمیلی، اطمینان حاصل کنید که تمامی لینک‌های به‌کاررفته در متن ایمیل، دارای پارامترهای UTM مناسب هستند.

حداقل پارامترهایی که باید در لینک‌ها لحاظ شود:

utm_source=email
utm_medium=newsletter یا مشابه آن
utm_campaign=summer_offer (یا هر عنوان اختصاصی کمپین)

۲. استفاده از پارامترهای یکسان در کل کمپین
برای تحلیل دقیق‌تر نتایج، توصیه می‌شود که در هر کمپین، از پارامترهای هماهنگ و استاندارد استفاده شود. این امر موجب سهولت در فیلتر کردن داده‌ها و تحلیل عملکرد کمپین در آنالیتیکس خواهد شد.

۳. تست پیش از ارسال نهایی
پیشنهاد می‌شود پیش از انتشار نهایی ایمیل، با ارسال نسخه‌ی آزمایشی (Test Email) به یک آدرس داخلی، عملکرد لینک‌ها و ثبت درست اطلاعات در Google Analytics بررسی شود. همچنین ابزارهایی مانند Google Tag Assistant می‌توانند در شناسایی لینک‌های ناقص یا بدون تگ کمک مؤثری باشند.

۴. پیکربندی نادرست رهگیری بین دامنه‌ای (Cross-Domain Tracking)

در بسیاری از کسب‌وکارها، ساختار وب‌سایت‌ها به‌گونه‌ای است که کاربر در جریان یک فرآیند مشخص، مانند ثبت‌نام یا خرید، میان چند دامنه یا زیر‌دامنه جابه‌جا می‌شود. در چنین شرایطی، اگر رهگیری بین دامنه‌ای (Cross-Domain Tracking) به‌درستی پیکربندی نشده باشد، Google Analytics قادر نخواهد بود مسیر ورود کاربر را به‌درستی دنبال کند و در نتیجه، ادامه مسیر را به‌عنوان یک بازدید جدید و از نوع دایرکت (Direct) ثبت می‌کند.

برای نمونه، فرض کنید وب‌سایت اصلی شما به آدرس www.example.com قرار دارد، اما مراحل پرداخت از طریق دامنه‌ای مانند payment.partner.com انجام می‌شود. اگر انتقال بین این دو دامنه با تنظیمات صحیح رهگیری همراه نباشد، کاربر هنگام ورود به دامنه دوم، به‌عنوان یک بازدیدکننده جدید و با منبع ناشناخته (دایرکت) در آنالیتیکس شناسایی خواهد شد.

راهکار پیشنهادی:

۱. تنیمات Referral Exclusion List
در تنظیمات GA4، اطمینان حاصل کنید که دامنه‌هایی مانند صفحات پرداخت، زیر دامنه‌ها یا درگاه‌های خارجی که بخشی از تجربه کاربری شما هستند، در لیست دامنه‌های مجاز (Referral Exclusion List) قرار گرفته‌اند تا به‌عنوان Referrer جدید در نظر گرفته نشوند.

۲. آزمایش عملی رهگیری با ابزارهای تست
برای اطمینان از صحت عملکرد رهگیری بین دامنه‌ای، می‌توانید از ابزارهایی مانند Google Analytics Debugger و افزونه‌های مرورگر استفاده کرده و مسیر حرکت کاربران از یک دامنه به دامنه دیگری را بررسی نمایید.

۵. استفاده از معماری Headless در طراحی سایت

معماری Headless در طراحی وب‌سایت، به‌خصوص در پروژه‌های بزرگ یا پلتفرم‌های مدرن، به‌سرعت در حال گسترش است. در این ساختار، رابط کاربری وب‌سایت (Frontend) و بخش مدیریت محتوا یا بک‌اند (Backend) به‌طور کامل از یکدیگر جدا هستند و ارتباط آن‌ها از طریق API برقرار می‌شود.

با وجود مزایایی چون انعطاف‌پذیری بالا، سرعت بارگذاری بیشتر و تجربه کاربری پیشرفته، این نوع معماری در صورت عدم پیاده‌سازی صحیح رهگیری، می‌تواند موجب اختلال در شناسایی منابع ورودی کاربران شود. چرا که در بسیاری از مواقع، محتوای صفحات بدون بارگذاری مجدد (Page Reload) و از طریق جاوااسکریپت رندر می‌شود. در چنین ساختاری، Google Analytics ممکن است اطلاعات Referrer یا پارامترهای UTM را دریافت نکند و بازدید کاربر را به‌صورت ترافیک دایرکت (Direct) ثبت کند.

راهکار پیشنهادی:

۱. استفاده از ایونت های اختصاصی (Custom Events)
در معماری Headless، لازم است رهگیری تعاملات کاربر به‌صورت دستی و با استفاده از Eventهای سفارشی انجام شود. به‌عنوان مثال، پس از بارگذاری محتوای جدید به‌صورت داینامیک، باید ایونتی به Google Analytics ارسال شود تا رفتار کاربر به‌درستی ثبت گردد.

۲. مدیریت انتقال پارامترهای UTM در مسیرهای داخلی
در وب‌سایت‌هایی با ساختار Headless، ضروری است که پارامترهای UTM از لحظه ورود کاربر تا انتهای مسیر تعامل، در URL یا حافظه محلی (Local Storage/Session Storage) حفظ شده و در انتقال بین صفحات گم نشود.

۳. هماهنگی با تیم فنی و توسعه‌دهنده فرانت‌اند
پیاده‌سازی صحیح رهگیری در ساختار Headless نیازمند همکاری نزدیک میان تیم بازاریابی و تیم توسعه است. تدوین یک استاندارد مشترک برای رهگیری ورودی‌ها، ثبت رفتار کاربر، و انتقال دقیق داده‌ها، نقش کلیدی در جلوگیری از خطا در گزارش‌های آنالیتیکس دارد.

۶. استفاده از اپلیکیشن‌های تک‌صفحه‌ای (Single Page Applications – SPA)

در ساختار سنتی وب‌سایت‌ها، زمانی که کاربر روی یک لینک داخلی کلیک می‌کند، مرورگر درخواست دریافت یک صفحه HTML جدید از سرور ارسال می‌کند. این فرآیند شامل بارگذاری مجدد کامل صفحه و انتقال هدرهای مرورگر (از جمله اطلاعات Referrer) به سمت سرور است؛ بنابراین Google Analytics به‌راحتی می‌تواند منبع ورود کاربر را شناسایی کند.

اما در اپلیکیشن‌های تک‌صفحه‌ای (SPA)، به‌جای ارسال درخواست جدید به سرور، محتوای صفحه به‌صورت پویا (دینامیک) در مرورگر بارگذاری می‌شود، بدون آنکه کل صفحه رفرش شود. این فرآیند که با عنوان “ناوبری سمت کلاینت” (Client-Side Navigation) شناخته می‌شود، از ارسال هدرهای Referrer جلوگیری کرده و در نتیجه، آنالیتیکس نیز قادر به تشخیص منبع اولیه ترافیک نخواهد بود. در چنین مواردی، بازدید به‌عنوان ترافیک دایرکت (Direct) ثبت می‌شود.

بیشتر بخوانید: ایونت ترکینگ در سایت های SPA

راهکار پیشنهادی:

۱. تنظیم صحیح تگ رهگیری برای SPA
در پروژه‌های مبتنی بر SPA، لازم است نصب انالیتیکس ۴ به‌گونه‌ای انجام شود که برای هر بار تغییر مسیر داخلی (Route Change) نیز یک بازدید جدید (Pageview) ثبت گردد. این کار معمولاً از طریق ارسال دستی Pageview با استفاده از تابع gtag() یا ga() انجام می‌شود.

۲. استفاده از Google Tag Manager
با استفاده از GTM، می‌توان ایونت های تغییر مسیر در SPA را شناسایی کرده و به‌طور خودکار برای آن‌ها Pageview ارسال کرد. این راهکار علاوه بر افزایش دقت رهگیری، امکان مدیریت متمرکز و ساده‌تر تگ‌ها را نیز فراهم می‌کند.

۳. مستندسازی نحوه پیاده‌سازی در تیم توسعه:
از آنجا که رهگیری در SPA نیازمند دخالت مستقیم در کدهای جاوااسکریپت است، توصیه می‌شود هماهنگی دقیقی میان تیم فنی و تیم مارکتینگ برقرار شود و دستورالعمل‌های فنی مرتبط با Google Analytics به‌درستی پیاده‌سازی گردد.

۷. ترافیک داخلی سازمان می‌تواند باعث افزایش چشمگیر ترافیک دایرکت (Direct) شود

یکی دیگر از منابع پنهان تولید ترافیک دایرکت (Direct) در Google Analytics، ترافیکی است که از سوی کارکنان، تیم‌های داخلی یا پیمانکاران فنی سازمان تولید می‌شود. از آنجا که این کاربران به‌صورت مداوم و اغلب از طریق بوکمارک یا تایپ مستقیم URL به سایت دسترسی پیدا می‌کنند، تمامی بازدیدهای آن‌ها به‌عنوان ترافیک دایرکت ثبت می‌گردد.

در شرایطی که فعالیت‌های توسعه، تست یا بروزرسانی وب‌سایت از طریق تیم داخلی انجام شود و فیلترهای مناسبی برای حذف ترافیک سازمانی از داده‌های آنالیتیکس در نظر گرفته نشده باشد، این ترافیک می‌تواند به‌طور جدی داده‌ها را مخدوش کند و منجر به تحلیل‌های اشتباه شود.

راهکار پیشنهادی:

۱. فیلتر کردن IPهای داخلی
در صورتی که کارکنان از شبکه مشخصی (مانند اینترنت شرکت) استفاده می‌کنند، توصیه می‌شود آدرس‌های IP مربوطه را در تنظیمات Google Analytics فیلتر کنید تا این بازدیدها در گزارش‌های عمومی لحاظ نشوند.

۲. استفاده از Dimensionهای سفارشی برای کاربران داخلی
در پروژه‌های پیشرفته‌تر، می‌توان از کوکی‌ها یا متغیرهای خاص برای شناسایی کاربران داخلی استفاده کرد و آن‌ها را از طریق Custom Dimension علامت‌گذاری نمود. سپس در زمان تحلیل داده‌ها، این کاربران از گزارش‌های اصلی حذف یا جداگانه تحلیل می‌شوند.

۳. تست در پراپرتی جداگانه
برای بررسی‌های فنی یا تست عملکرد وب‌سایت، بهتر است از یک پراپرتی اختصاصی در Google Analytics استفاده شود که ترافیک داخلی را ثبت کرده ولی در گزارش‌های تحلیلی اصلی لحاظ نشود.

۸. استفاده از اتصال غیر امن (HTTP) به‌جای اتصال امن (HTTPS)

در حال حاضر، تقریباً تمامی مرورگرها، موتورهای جست‌وجو و پلتفرم‌های وب، استفاده از اتصال امن مبتنی بر HTTPS را به‌عنوان یک استاندارد ضروری در نظر می‌گیرند. با این حال، برخی از وب‌سایت‌ها هنوز از پروتکل قدیمی HTTP استفاده می‌کنند که می‌تواند منجر به از بین رفتن اطلاعات Referrer و در نتیجه افزایش ثبت ترافیک به‌صورت دایرکت (Direct) در Google Analytics شود.

بر اساس استانداردهای امنیتی مرورگرها، وب‌سایت‌هایی که از HTTPS استفاده می‌کنند، اطلاعات مربوط به Referrer را به صفحات HTTP منتقل نمی‌کنند. این بدان معناست که اگر کاربری از سایتی با اتصال امن به وب‌سایت شما (که از HTTP استفاده می‌کند) هدایت شود، Google Analytics قادر به شناسایی منبع ارجاع‌دهنده نخواهد بود و ترافیک ورودی را به‌عنوان دایرکت (Direct) ثبت می‌کند.

راهکار پیشنهادی:

۱. مهاجرت سریع به HTTPS
استفاده از گواهی SSL معتبر برای تبدیل وب‌سایت به HTTPS نه‌تنها به بهبود امنیت و سئو کمک می‌کند، بلکه از کاهش کیفیت داده‌های تحلیلی نیز جلوگیری خواهد کرد.

۲. استفاده از ریدایرکت ۳۰۱ پس از مهاجرت
پس از اعمال HTTPS، باید تمامی صفحات HTTP به نسخه امن خود از طریق ریدایرکت دائم (۳۰۱) هدایت شوند. این اقدام مانع از ایجاد محتوای تکراری (Duplicate Content) شده و موجب حفظ ارزش سئوی صفحات می‌شود.

۳. اطمینان از پوشش کامل HTTPS در کل اجزای سایت
حتماً بررسی شود که تمام منابع بارگذاری‌شده در سایت، مانند تصاویر، فایل‌های CSS و JavaScript نیز از طریق HTTPS فراخوانی شوند. ترکیب منابع امن و ناامن (Mixed Content) می‌تواند موجب بروز خطا یا هشدارهای امنیتی در مرورگر شود.

۴. تهیه گواهی SSL از منابع معتبر
می‌توانید از سرویس‌دهندگانی مانند Cloudflare یا Let’s Encrypt برای دریافت گواهی SSL رایگان استفاده کنید. در صورت نیاز به راهکار حرفه‌ای‌تر، شرکت‌هایی مانند Comodo یا Digicert گواهی‌های تجاری ارائه می‌دهند.

۹. کش می‌تواند باعث ثبت ترافیک به‌صورت دایرکت شود

کش کردن (Caching) یکی از تکنیک‌های رایج برای بهبود عملکرد وب‌سایت است. در این روش، بخش‌هایی از صفحات وب در حافظه مرورگر یا سرور ذخیره می‌شوند تا در بازدیدهای بعدی، بارگذاری سریع‌تر و مصرف منابع کمتر داشته باشند. با وجود مزایای فراوان، caching در برخی شرایط خاص می‌تواند مانع از بارگذاری صحیح تگ رهگیری Google Analytics شده و در نتیجه، باعث ثبت ترافیک به‌صورت دایرکت (Direct) گردد.

این مشکل معمولاً زمانی رخ می‌دهد که بخش <head> صفحه یا فایل‌های JavaScript (که شامل تگ رهگیری هستند) به‌طور کامل از کش بارگذاری می‌شوند و در نتیجه، تگ موردنظر اجرا نمی‌شود یا داده‌ای به سرورهای آنالیتیکس ارسال نمی‌گردد. در چنین وضعیتی، آنالیتیکس نمی‌تواند اطلاعات مربوط به Referrer را دریافت کرده و بازدید را به‌صورت ناشناس یا دایرکت ثبت می‌کند.

راهکار پیشنهادی:

۱. جلوگیری از کش شدن فایل‌های کلیدی رهگیری
اطمینان حاصل کنید که فایل‌های JavaScript مربوط به رهگیری، به‌ویژه کد Google Analytics که در بخش <head> صفحات قرار دارد، در تنظیمات CDN یا پلاگین‌های کش، از فرآیند کش شدن مستثنی شده‌اند.

۲. استفاده از پارامترهای اجباری برای بارگذاری مجدد کد
در صورت امکان، از پارامترهای تغییر‌دهنده (مثل ?v=1.2) در انتهای URL فایل‌های رهگیری استفاده کنید تا مرورگر آن‌ها را در هر بار بارگذاری به‌عنوان فایل جدید شناسایی کرده و از کش استفاده نکند.

۳. بررسی عملکرد کد در شرایط واقعی
با استفاده از ابزارهایی مانند Google Tag Assistant یا مرورگرهایی با کش غیرفعال‌شده، عملکرد کد رهگیری در سناریوهای مختلف را آزمایش کرده و از ارسال صحیح داده به آنالیتیکس اطمینان حاصل کنید.

۴. هماهنگی با تیم توسعه و مسئولین CDN:
در وب‌سایت‌هایی که از شبکه‌های توزیع محتوا (CDN) مانند Cloudflare یا سرویس‌های کش سرور استفاده می‌شود، لازم است تنظیمات مربوط به Cache-Control و Expires به‌درستی پیکربندی شوند تا مانع از اجرای کدهای رهگیری نشوند.

۱۰. استراتژی جذب سرنخ (Demand Generation)

برخی از استراتژی‌های بازاریابی، به‌ویژه در حوزه جذب سرنخ (Lead/Demand Generation)، به‌صورت ناخواسته منجر به افزایش ترافیک دایرکت (Direct) در گزارش‌های Google Analytics می‌شوند. این اتفاق زمانی رخ می‌دهد که کانال‌های ارتباطی انتخاب‌شده برای هدایت کاربر به وب‌سایت، اطلاعات مربوط به Referrer را منتقل نمی‌کنند.

برای مثال، اگر سازمان شما برای هدایت ترافیک از پادکست، تبلیغات رادیویی، چاپی، تلویزیونی یا بیلبوردهای محیطی استفاده می‌کند، اغلب کاربران به‌صورت مستقیم (از طریق تایپ URL در نوار مرورگر یا کلیک روی بوکمارک) وارد وب‌سایت می‌شوند. چون در این کانال‌ها، لینکی برای کلیک وجود ندارد، اطلاعاتی درباره منبع ورودی ثبت نخواهد شد و در نتیجه، ترافیک مربوطه به‌صورت دایرکت (Direct) گزارش می‌شود.

راهکار پیشنهادی:

۱. استفاده از دامنه یا URL اختصاصی برای هر کانال آفلاین
به جای معرفی آدرس اصلی سایت، می‌توانید برای هر کانال بازاریابی آفلاین یک URL کوتاه‌شده اختصاصی یا دامنه مجزا تعریف کنید (مثلاً: example.com/podcast) که به صفحه‌ای با UTMهای مناسب ریدایرکت شود.

۲. استفاده از کدهای QR با لینک‌های تگ‌شده
در تبلیغات چاپی یا فیزیکی می‌توانید از کد QR استفاده کنید که به لینک دارای پارامترهای UTM ارجاع می‌دهد. این روش به‌ویژه برای بروشورها، نمایشگاه‌ها و بسته‌های تبلیغاتی مؤثر است.

۳. هماهنگی میان تیم‌های بازاریابی آفلاین و دیجیتال
اطمینان حاصل کنید که کمپین‌های آفلاین نیز با رویکرد تحلیلی طراحی می‌شوند و امکان شناسایی دقیق منابع ورودی کاربران را فراهم می‌سازند.

۴. تحلیل تفکیکی صفحات فرود آفلاین:
در صورتی که برای هر کانال آفلاین یک لندینگ پیج اختصاصی طراحی شده است، می‌توان از عملکرد آن صفحات به‌عنوان شاخصی برای تحلیل تأثیر هر کانال استفاده کرد.

۱۱. افزایش استفاده کاربران از افزونه‌های مسدودکننده تبلیغات (Adblocker)

در سال‌های اخیر، استفاده از افزونه‌های مسدودکننده تبلیغات (Adblocker) در مرورگرهای وب به‌شدت افزایش یافته است. بسیاری از کاربران برای جلوگیری از نمایش تبلیغات مزاحم یا حفظ حریم خصوصی، از این ابزارها استفاده می‌کنند. با این حال، این موضوع می‌تواند به‌صورت مستقیم بر دقت داده‌های Google Analytics تأثیر بگذارد و منجر به افزایش ثبت ترافیک دایرکت در گزارش‌ها شود.

افزونه‌های Adblock نه‌تنها تبلیغات، بلکه بسیاری از اسکریپت‌های تحلیلی از جمله کدهای Google Analytics، Google Tag Manager و سایر ابزارهای رهگیری را نیز مسدود می‌کنند. در نتیجه، اگر کاربری از چنین افزونه‌ای استفاده کند، هیچ اطلاعاتی از جمله منبع ترافیک، رفتار کاربر یا حتی خود بازدید به آنالیتیکس ارسال نخواهد شد. در برخی موارد خاص، ترافیک مربوط به این کاربران به‌صورت ناقص یا دایرکت (Direct) ثبت می‌شود.

نکات قابل توجه و اقدامات پیشنهادی

۱. درک صحیح از ماهیت محدودیت:
باید پذیرفت که ترافیک ناشی از کاربران مجهز به Adblock به‌طور کامل و دقیق قابل رهگیری نیست. این یک محدودیت ساختاری است و به پیکربندی اشتباه در آنالیتیکس مربوط نمی‌شود.

۲. استفاده از راهکارهای رهگیری سمت سرور (Server-Side Tracking):
در صورت نیاز به دقت بالاتر در رهگیری، می‌توان از معماری‌های پیشرفته‌تر مانند سرور تگینگ (Server-Side GTM) استفاده کرد. این روش تا حدی می‌تواند اثر ادبلاکرها را کاهش دهد، هرچند هزینه و پیچیدگی پیاده‌سازی بالاتری دارد.

۳. تحلیل تأثیر Adblock بر نرخ دایرکت
با مقایسه نرخ دایرکت در مرورگرها یا سیستم‌های عامل مختلف، می‌توان به‌صورت غیرمستقیم تأثیر استفاده از Adblock را ارزیابی کرد. مرورگرهایی مانند Brave یا نسخه‌های دسکتاپ Firefox، معمولاً نرخ بالاتری از ترافیک دایرکت دارند که می‌تواند ناشی از مسدودسازی اسکریپت‌ها باشد.

۱۲. افزایش آگاهی از برند (Brand Awareness)

زمانی که برند شما به شناخت بالایی در میان مخاطبان هدف دست پیدا می‌کند، بخشی از کاربران ترجیح می‌دهند مستقیماً نام دامنه‌ی وب‌سایت را در نوار مرورگر وارد کرده یا از طریق بوکمارک وارد سایت شوند. این نوع رفتار کاملاً طبیعی است و در واقع نشانه‌ای از موفقیت استراتژی‌های برندینگ محسوب می‌شود.

در چنین شرایطی، Google Analytics بازدید این کاربران را به‌عنوان ترافیک دایرکت (Direct) ثبت می‌کند؛ چرا که مرورگر اطلاعاتی درباره منبع ارجاع‌دهنده (Referrer) ارائه نمی‌دهد.

افزایش آگاهی از برند ممکن است ناشی از فعالیت‌های تبلیغاتی گسترده، حضور در رسانه‌ها، تبلیغات محیطی، عملکرد مثبت در نتایج جست‌وجو یا حتی رضایت بالای مشتریان باشد که به شکل دهان‌به‌دهان منتقل می‌شود. با این حال، این رشد ترافیک دایرکت در صورتی که با سایر منابع ترکیب شود، ممکن است تحلیل رفتار کاربران را با چالش مواجه کند.

نکات تحلیلی و اقدامات پیشنهادی

۱. ارزیابی همزمان سایر شاخص‌های برندینگ
برای اطمینان از اینکه افزایش ترافیک دایرکت ناشی از رشد آگاهی برند است، شاخص‌هایی مانند افزایش جست‌وجوی نام برند در گوگل، رشد دنبال‌کنندگان شبکه‌های اجتماعی و نرخ تکرار بازدید کاربران را نیز بررسی کنید.

۲. استفاده از Google Search Console
با بررسی داده‌های مربوط به کوئری‌های جست‌وجو، می‌توانید متوجه شوید که کاربران چقدر مستقیماً نام برند یا دامنه شما را جست‌وجو کرده‌اند. این داده‌ها به‌صورت مکمل می‌توانند دلیل افزایش ترافیک دایرکت را روشن‌تر کنند.

۳. بازدیدکنندگان بازگشتی (Returning Users):
افزایش بازدیدکنندگان تکراری، به‌ویژه در دوره‌های کمپین‌های برندینگ، نشانه‌ای از موفقیت در تثبیت نام برند و ایجاد وفاداری است. این کاربران معمولاً به‌صورت مستقیم وارد سایت می‌شوند.

۴. ایجاد صفحات فرود اختصاصی برای کمپین‌های برندینگ:
در صورت اجرای کمپین‌های آگاهی‌رسانی، می‌توانید صفحات فرودی طراحی کنید که فقط در آن کمپین‌ها معرفی شده‌اند. تحلیل ترافیک این صفحات کمک می‌کند سهم واقعی ترافیک ناشی از برند را تشخیص دهید.

۱۳. اسپم‌بات‌ها (Spam Bots)

یکی از عوامل پنهان و در عین حال تأثیرگذار بر افزایش ترافیک دایرکت در Google Analytics، فعالیت اسپم‌بات‌ها (Spam Bots) و ربات‌های خودکار است. این ربات‌ها بدون تعامل انسانی، به‌صورت مستقیم از طریق آدرس URL به صفحات مختلف وب‌سایت دسترسی پیدا می‌کنند و معمولاً هیچ Referrer یا منبع ارجاع‌دهنده‌ای را همراه ندارند. در نتیجه، تمامی بازدیدهای آن‌ها به‌صورت دایرکت ثبت می‌شود.

این نوع ترافیک می‌تواند باعث افزایش غیرواقعی تعداد سشن (Sessions)، کاهش نرخ تعامل، و در نهایت تحلیل‌های نادرست در گزارش‌های آنالیتیکس شود. به‌ویژه برای وب‌سایت‌هایی که ترافیک نسبتاً پایینی دارند، چند صد بازدید از جانب اسپم‌بات‌ها می‌تواند به‌شدت داده‌ها را تحت تأثیر قرار دهد.

راهکار پیشنهادی برای شناسایی و جلوگیری:

۱. تحلیل رفتار بازدیدهای مشکوک:
بررسی داده‌هایی نظیر نرخ پرش ۱۰۰٪، میانگین زمان حضور صفر ثانیه می‌تواند در شناسایی بازدیدهای مشکوک کمک کند. معمولاً اسپم‌بات‌ها رفتار طبیعی انسانی ندارند.

۲. استفاده از فیلترهای سفارشی برای مسدودسازی IPها یا hostnameهای نامعتبر
در صورتی که الگوهای ثابتی در ترافیک‌های اسپم مشاهده می‌کنید، می‌توانید با ایجاد فیلترهای مخصوص، این بازدیدها را از گزارش‌های اصلی حذف کنید.

۳. بررسی hostname در گزارش‌ها
در Google Analytics، با بررسی بخش Hostname می‌توانید اطمینان حاصل کنید که بازدیدها واقعاً از دامنه اصلی شما صورت گرفته‌اند. اسپم‌بات‌ها اغلب از hostnameهای غیرمعتبر استفاده می‌کنند.

۴. استفاده از ابزارهای امنیتی و فایروال‌های حرفه‌ای
سرویس‌هایی مانند Cloudflare می‌توانند در شناسایی و مسدودسازی بات‌ها قبل از رسیدن به لایه Analytics مؤثر باشند. این ابزارها همچنین قابلیت محدودسازی دسترسی‌های غیرعادی را نیز فراهم می‌کنند.

آموزش گوگل تگ منیجر

ایمپورت کردن در تگ منیجر

در Google Tag Manager قابلیتی وجود دارد که به کاربران اجازه می‌دهد از تنظیمات یک کانتینر خروجی بگیرند و آن را در یک پروژه دیگر وارد کنند. این قابلیت یکی از مهم‌ترین امکانات GTM برای مدیریت حرفه‌ای تگ‌ها، تریگرها و متغیرها در پروژه‌های مختلف است. در این مقاله با کاربردهای اصلی ایمپورت کردن کانتینر در گوگل تگ منیجر آشنا می‌شوید و بررسی می‌کنیم در چه موقعیت‌هایی این کار می‌تواند زمان و هزینه اجرای پروژه را به شکل قابل توجهی کاهش دهد.

مشاوره برای شرکت در دوره تگ منیجر

مزایای وارد کردن کانتینر در GTM

۱. پیاده‌سازی تنظیمات مشابه در چند پروژه مختلف

فرض کنید مجموعه‌ای فعال در حوزه سلامت، دارای ۱۰ وب‌سایت با ساختار مشابه است و برای هر وب‌سایت یک کانتینر جداگانه در تگ منیجر تعریف شده. در این شرایط، برای اعمال تنظیمات یکسان، دو مسیر وجود دارد:

تنظیمات به‌صورت دستی و تکراری روی هر کانتینر اعمال شود
یا ابتدا یک کانتینر به‌صورت کامل پیکربندی شده، سپس از آن خروجی گرفته و در سایر کانتینرها وارد شود. در نهایت، فقط مقادیر متغیرهای خاص مانند Measurement ID در GA4 به‌روزرسانی می‌شود.

بدیهی است که روش دوم سریع‌تر، دقیق‌تر و کاملاً مقیاس‌پذیر است.

۲. استفاده از کانتینرهای آماده همکاران

در تیم‌های مارکتینگ یا آنالیتیکس، معمولاً قالب‌های از پیش طراحی‌شده‌ای وجود دارد که توسط یکی از اعضا تهیه شده و قابل استفاده در پروژه‌های مختلف است. با وارد کردن چنین فایل‌هایی در GTM، می‌توان از دوباره‌کاری جلوگیری کرد و فرآیند راه‌اندازی را تسریع بخشید.

۳. بهره‌مندی از GTM Recipeهای آنلاین

وب‌سایت‌های تخصصی زیادی، مجموعه‌ای از کانتینرهای آماده (GTM Recipe) را ارائه می‌کنند که شامل تنظیمات رایج مانند اسکرول ترکینگ، کلیک روی دکمه‌ها، تایمر و سایر ایونت های مهم هستند. وارد کردن این فایل‌ها در GTM، راهکاری سریع و قابل اتکا برای پیاده‌سازی این قابلیت‌ها است.

۴. مدیریت نسخه‌های مختلف پروژه (توسعه، آزمایشی و اصلی)

در بسیاری از پروژه‌ها، محیط‌های مجزایی برای توسعه (Development)، پیش‌نمایش (Staging) و اجرای نهایی (Production) تعریف می‌شود. با استفاده از امکان خروجی گرفتن از کانتینر در یکی از این محیط‌ها و وارد کردن آن در محیط دیگر، می‌توان ضمن حفظ دقت، روند استقرار تنظیمات را به‌شکل مؤثری مدیریت کرد.

مراحل وارد کردن یک کانتینر در Google Tag Manager

در این بخش به‌صورت گام‌به‌گام با فرآیند وارد کردن یک فایل کانتینر (فرمت JSON) در GTM آشنا می‌شویم. این فایل می‌تواند از منابع مختلفی مانند کتابخانه GTM Recipes تهیه شده باشد.

مرحله ۱: ورود به بخش Admin و انتخاب گزینه Import Container

در پنل مدیریت کانتینر موردنظر در GTM وارد بخش Admin شوید و روی گزینه Import Container کلیک کنید.

مرحله ۲: انتخاب فایل کانتینر (JSON)

در این مرحله باید فایل JSON مربوط به کانتینری که قصد وارد کردن آن را دارید، انتخاب کنید. این فایل ممکن است از کتابخانه GTM Recipeها یا پروژه‌های قبلی شما تهیه شده باشد.

مرحله ۳: انتخاب Workspace

در گام بعدی، باید مشخص کنید که فایل کانتینر در کدام Workspace وارد شود. اگر تاکنون با مفهوم Workspace کار نکرده‌اید، احتمالاً در حال حاضر فقط از Default Workspace استفاده می‌کنید.

در این صورت، روی گزینه Existing در بخش «Choose workspace» کلیک کرده و Default Workspace را انتخاب کنید.

مرحله ۴: انتخاب نوع واردسازی (Import Option)

در این مرحله با دو گزینه مواجه می‌شوید:

Overwrite (بازنویسی کامل)

با انتخاب این گزینه، تمام تگ‌ها، تریگرها و متغیرهای فعلی کانتینر حذف می‌شوند و فقط اطلاعاتی که در فایل JSON موجود است وارد می‌شود. این گزینه معمولاً برای موقعیت‌هایی کاربرد دارد که قصد دارید کانتینر را به‌طور کامل پاک‌سازی کرده و از نو بسازید.

Merge (ادغام)

این گزینه باعث می‌شود که تگ‌ها، تریگرها و متغیرهای جدید به کانتینر موجود اضافه شوند بدون اینکه موارد قبلی حذف شوند.

در صورت وجود تداخل (یعنی اگر یک تگ یا متغیر جدید، نامی مشابه با یکی از آیتم‌های موجود داشته باشد)، GTM دو انتخاب به شما می‌دهد:

Overwrite: آیتم قبلی حذف و آیتم جدید جایگزین می‌شود.
Rename: آیتم جدید با نام متفاوت (مثلاً با پیشوند «Copy of…») وارد می‌شود و آیتم قبلی باقی می‌ماند.

پس از انتخاب هرکدام از این گزینه‌ها، GTM یک پیش‌نمایش از تغییراتی که در کانتینر ایجاد خواهد شد نمایش می‌دهد تا بتوانید نتیجه نهایی را بررسی کنید.

در صورت تمایل، می‌توانید روی لینک View Detailed Changes کلیک کنید تا لیست دقیق آیتم‌هایی که قرار است اضافه یا حذف شوند را مشاهده کنید.

مرحله ۵: تأیید و نهایی‌سازی

در نهایت، روی دکمه Confirm کلیک کنید تا فرآیند واردسازی فایل کانتینر به پایان برسد.

مرحله نهایی: بررسی با حالت Preview

پس از انجام واردسازی، پیشنهاد می‌شود بلافاصله روی دکمه Preview کلیک کرده و تغییرات را در سایت بررسی کنید.

آموزش خروجی گرفتن از کانتینر در گوگل تگ منیجر

در نسخه‌های قبلی Google Tag Manager، تنها راه گرفتن خروجی از تنظیمات پروژه‌ها، خروجی گرفتن از کل Container بود. اما حالا، یک ویژگی جدید و بسیار کاربردی اضافه شده که به شما اجازه می‌دهد فقط از بخشی از Container موردنظر خود خروجی بگیرید.

مشاوره برای شرکت در دوره تگ منیجر

چرا قابلیت Import/Export در GTM مفید است؟

یکی از امکانات بسیار کارآمد در گوگل تگ منیجر، قابلیت درون‌ریزی (Import) و برون‌ریزی (Export) تنظیمات است. این قابلیت، مخصوصاً زمانی به کار می‌آید که می‌خواهید یک Container را به شکل کامل در پروژه‌ای دیگر بازسازی کنید.

برای این کار، کافی‌ست از Container اول خروجی بگیرید (به‌صورت فایل JSON) و آن را در Container دوم بارگذاری کنید.

در واقع، همین قابلیت پایه‌ و اساس چیزی است که به آن GTM Recipe گفته می‌شود، فایل‌های آماده‌ای که شامل مجموعه‌ای از تگ‌ها، تریگرها و متغیرها هستند و می‌توان آن‌ها را در پروژه‌های مختلف استفاده کرد.

آیا خروجی گرفتن از بخشی از Container امکان‌پذیر است؟

تا قبل از اوت ۲۰۲۰ (مرداد ۱۳۹۹)، چنین امکانی به‌صورت مستقیم در GTM وجود نداشت. اما از آن تاریخ به بعد، شما می‌توانید بدون نیاز به افزونه یا راه‌حل‌های پیچیده، فقط بخش‌هایی از Container خود (مثل چند تگ خاص یا فقط متغیرها) را انتخاب و از همان بخش‌ها خروجی بگیرید.

در ادامه این مطلب، دقیقاً مراحل انجام این کار را توضیح می‌دهیم.

خروجی گرفتن از بخشی از Container در گوگل تگ منیجر

اگر قصد دارید فقط بخشی از یک Container را در Google Tag Manager خروجی بگیرید، کافی‌ست وارد بخش Admin کانتینر شوید و روی گزینه‌ی Export Container کلیک کنید.

در مرحله‌ی بعد، باید workspace موردنظر خود را انتخاب کنید.

سپس، یک پنجره جدید از سمت راست باز می‌شود که لیستی از تمام آیتم‌هایی که می‌توانید خروجی بگیرید را نمایش می‌دهد.

به‌صورت پیش‌فرض، همه‌ی آیتم‌ها انتخاب شده‌اند (یعنی همان خروجی کامل از کل Container).

اما اگر فقط می‌خواهید بخش خاصی از Container را خروجی بگیرید، ابتدا باید تیک گزینه‌ی “Select all” را بردارید.

حالا می‌توانید فقط موارد دلخواه‌تان (تگ‌ها، تریگرها یا متغیرهای خاص) را انتخاب کنید تا در فایل JSON قرار بگیرند.

اگر از قابلیت پوشه‌بندی (Folders) در GTM استفاده می‌کنید و می‌خواهید ساختار پوشه‌ها هم در فایل خروجی حفظ شود، حتماً تیک مربوط به آن را فعال بگذارید.

در بالای پنجره، خلاصه‌ای از تعداد آیتم‌هایی که قرار است خروجی بگیرید نمایش داده می‌شود.

نکته کاربردی دیگر اینکه شما می‌توانید تمام آیتم‌های متعلق به یک پوشه خاص را به‌صورت یکجا انتخاب یا از انتخاب خارج کنید.
در لیست آیتم‌ها، مشخص است هر کدام متعلق به کدام پوشه‌اند. کافی‌ست روی نام پوشه کلیک کنید تا به‌صورت خودکار تمام آیتم‌های داخل آن پوشه انتخاب یا لغو انتخاب شوند.

برای مثال، اگر روی پوشه‌ای به نام “testing” کلیک کنید، دو آیتم زیر با هم انتخاب یا غیرفعال می‌شوند:

GA Event – File Download
Link Click – PDF or DOCX File

پس از انجام انتخاب‌های مورد نظر، می‌توانید روی دکمه‌ی Export در گوشه بالا سمت راست کلیک کنید. همچنین این امکان وجود دارد که قبل از دانلود، پیش‌نمایشی از فایل JSON را مشاهده کنید.

این قابلیت جدید در GTM، یک تغییر خوشایند و کاربردی است: ساده، قابل‌فهم و بدون نیاز به ابزار جانبی.
با این حال، اگر ترجیح می‌دهید با فایل‌های JSON کاری نداشته باشید و مثلاً می‌خواهید آیتم‌هایی از چند کانتینر مختلف را بردارید و مستقیم به یک کانتینر جدید منتقل کنید، بخش بعدی برایتان مفید خواهد بود.

نصب گوگل تگ منیجر از طرق چند روش؛ آموزش ویدئویی و تصویری

نصب گوگل تگ منیجر، اولین قدمی است که برای بهره‌مندی از مزایای این ابزار دیجیتال مارکتینگ باید بردارید. بنابراین اگر قصد دارید مدیریت تگ‌های مورد نیاز جهت انجام فعالیت‌های بازاریابی به عهده خودتان باشد و در سریع‌ترین زمان انواع ترکینگ کدها را در سایت قرار دهید و ایونت‌های جدید تعریف یا ویرایش کنید؛ در ادامه این مطلب همراه من باشید.

همان‌طور که در مقاله گوگل تگ منیجر چیست بیان شد؛ GTM به شما کمک می‌کند تا بدون نیاز به یک دولوپر یا توسعه دهنده، انواع ترکینگ کدها را در سایت قرار دهید و ویرایش کنید. در این راهنما، نحوه نصب صحیح Google Tag Manager را در وب سایت خود توضیح خواهم داد.

مراحل نصب گوگل تگ منیجر؛ آموزش تصویری

مرحله اول: وارد حساب Google خود شوید

برای نصب گوگل تگ منیجر، باید وارد آدرس tagmanager.google.com. شوید و از طریق حساب کاربری گوگل خود یک اکانت تگ منیجر بسازید و وارد آن شوید. لطفا توجه داشته باشید که برای استفاده از ابزارهایی مانند GTM و آنالیتیکس، به یک حساب گوگل نیاز خواهید داشت.

مرحله دوم: اکانت و کانتینر تگ منیجر ایجاد کنید

روی گزینه Create Account کلیک کنید. تنظیمات حساب تگ منیجر را مشابه با آنالیتیکس، می‌توانید در دو سطح انجام دهید؛ سطح اکانت و سطح کانتینر (Container). شما می‌توانید چندین اکانت و در هر اکانت، می‌توانید چندین کانتینر داشته باشید.

کانتینر در گوگل تگ منیجر، مرکزی است که تمام قطعه کدهای قرار داده شده در سایت از طریق GTM را در خود نگه می‌دارد.

نکته مهم: در انتخاب نام اکانت و کانتینر تگ منیجر، دقت کنید. بهتر است نام هر دو را مرتبط با کسب و کار و یا آدرس سایت انتخاب کنید.

نام اکانت را وارد کرده و سپس کشور را از طریق منوی کشویی، انتخاب کنید. با انتخاب چک باکس، دیتاهای خود به صورت ناشناس در اختیار گوگل قرار می‌دهید تا همراه با هزاران دیتای دیگر، در فرایند بنچمارک، مورد استفاده قرار گیرد.

بعد از انجام تنظیمات مربوط به اکانت، می‌توانید اسم کانتینر و پلتفرم که قصد نصب گوگل تگ منیجر روی آن را دارید، انتخاب کنید. در این مرحله می‌توانید آدرس سایت را به عنوان اسم کانتینر انتخاب کنید. سپس روی گزینه Create کلیک کنید.

در مرحله بعد، قوانین و شرایط استفاده از این ابزار نمایش داده می‌شود؛ باید آنها را بپذیرید و روی Yes کلیک کنید. بعد از انجام این کار، اکانت گوگل تگ منیجر به همراه یک کانتینر، ساخته می‌شود.

در مرحله بعد، پیامی حاوی کدهای مخصوص برای نصب گوگل تگ منیجر به شما نمایش داده می‌شود. اگر به هر دلیلی این پیغام را نمی‌بیند؛ می‌توانید از طریق Google Tag Manager ID، در بالای صفحه و کنار (Workspace Changes: )، به آن دسترسی داشته باشید.

توجه: برای دسترسی به کدهای مورد نیاز جهت نصب گوگل تگ منیجر در سایت، می‌توانید مسیر زیر را دنبال کنید:

از نوار ابزار بالای صفحه اصلی گوگل تگ منیجر، سمت چپ، روی گزینه Admin کلیک کنید.

در صفحه‌ای که نمایش داده می‌شود، روی گزینه Install Google Tag Manager کلیک کنید.

در صفحه بعدی، شما به هر دو کد مورد نیاز برای نصب تگ منیجر روی سایت دسترسی خواهید داشت.

مرحله سوم: کدهای نصب گوگل تگ منیجر را در سایت قرار دهید

پاپ آپی که پیش از این به آن اشاره شد، حاوی دو قطعه کد است که اولی باید قبل از بسته شدن تگ <head> قرار گیرد و دومی دقیقا بعد از تگ <body> در سایت قرار گیرد. برای انجام این کار، شما باید یا به سورس کد سایت دسترسی و با کدهای HTML تا حدی آشنایی داشته باشید و یا از افزونه گوگل تگ منیجر برای وردپرس استفاده کنید.

نکته مهم اول:

کد noscript گوگل تگ منیجر که باید بلافاصله بعد از تگ <body> قرار گیرد، به عنوان نسخه پشتیبان عمل می‌کند و کاربران را بدون جاوا اسکریپت هم ردیابی می‌کند. درواقع اگر برخی از کاربران قابلیت جاوا اسکریپت سایت را غیر فعال کرده باشند، ورژن آی فریم گوگل تک منیجر رندر شده و کاربر ردیابی می‌شود.

نکته مهم دوم:

هر دو قطعه کدهای نصب گوگل تگ منیجر را می‌توانید بعد از تگ <body> هم قرار دهید؛ اما نمی‌توانید هردو را در بخش head قرار دهید. چون رندر شدن iframe در بخش head سایت ممکن نیست!

نکته مهم سوم:

قرار دادن کد دوم برای نصب گوگل تگ منیجر، یعنی کدی که در قسمت body قرار می‌گیرد؛ الزامی نیست. همان‌طور که گفته شد این کد مسئول ردیابی کاربرانی است که قابلیت جاوا اسکریپت را غیر فعال کرده‌اند. با توجه به آمار جهانی، درصد کمی از کاربران این قابلیت را غیر فعال کرده‌اند. بنابراین بدون ردیابی این دسته از کاربران هم به مشکل نخواهید خورد.

روش‌های نصب کد گوگل تگ منیجر روی سایت

روش‌های مختلفی برای قرار دادن کدهای نصب گوگل تگ منیجر روی سایت وجود دارد.

نصب از طریق دولوپر یا توسعه دهنده سایت

اگر برای راه اندازی وب سایت خود از یک توسعه دهنده کمک گرفته‌اید و به او دسترسی دارید؛ پیشنهاد می‌کنیم با توجه به شناختی که او از زیرساخت سایت دارد؛ قرار دادن کدهای نصب GTM را به او بسپارید. در این حالت، خطر آسیب زدن به ساختار اصلی سایت و خرابکاری، تا حد زیادی کاهش می‌یابد.

نصب از طریق افزونه‌های وردپرس

اگر از سیستم‌های مدیریت محتوای رایج مانند وردپرس، شاپیفای و… استفاده می‌کنید؛ می‌توانید برای نصب گوگل تگ منیجر از افزونه‌های مختلفی که برای انجام این کار وجود دارد؛ استفاده کنید. به عنوان مثال، اگر از وردپرس به عنوان CMS استفاده می‌کنید، افزونه Google Tag Manager برای وردپرس توسط Thomas Geiger را توصیه می‌کنم. در ادامه روش نصب گوگل تگ منیجر از طریق افزونه وردپرس را به شما عزیزان آموزش می‌دهم.

وارد پیشخوان وردپرس سایت شوید.
روی گزینه افزونه‌ها و سپس افزودن کلیک کنید.
در قسمت جستجو، عبارت Google Tag Manager را وارد کنید.
روی گزینه نصب کلیک کنید. (مطمئن شوید که این افزونه با وردپرس شما سازگار است.)

بعد از نصب، روی گزینه “فعال نمایید” کلیک کنید.
سپس به صفحه افزونه‌های نصب شده بروید و روی تنظیمات افزونه GTM4WP کلیک کنید.
در صفحه‌ای که نمایش داده می‌شود، در اولین کادر، باید کد گوگل تگ منیجر را وارد کنید. این کد کجاست؟ کنار بخش Workspace Changes. روی آی دی تگ منیجر کلیک کنید و در صفحه‌ای که نمایش داده می‌شود، مشابه با تصویر زیر، آدرس کانتینر را کپی کنید و در کادر قرار دهید. در قسمت دوم، باید جایگاه پیشنهادی برای نصب کد دوم، درواقع کدی که قرار دادن آن در سایت ضروری نبود و بهتر بود که در بخش body قرار گیرد؛ را انتخاب کنید. با استفاده از افزونه GTM4WP، کد اول که کد اصلی و ضروری بود، در بخش head سایت قرار می‌گیرد.

سپس روی گزینه “ذخیره تغییرات” کلیک کنید.

توجه: بعد از نصب و انجام تنظیمات مربوط به نصب گوگل تگ منیجر در سایت، به افزونه GTM4WP از طریق منوی تنظیمات در پیشخوان وردپرس دسترسی خواهید داشت.

چرا باید کد Google Tag Manager را در بخش `<head>` قرار دهیم؟

شاید قرار دادن کد Google Tag Manager در بخش <head> سایت اجباری نباشد، اما به‌شدت توصیه می‌شود که بخش <script> این کد را در ابتدای صفحه، یعنی داخل تگ <head> قرار دهید.

دلیلش چیست؟ دقت بیشتر در ردیابی کاربران

هرچه کدهای ردیابی بالاتر در ساختار صفحه قرار بگیرند، زودتر بارگذاری می‌شوند. در نسخه‌های قدیمی‌تر گوگل تگ منیجر، پیشنهاد می‌شد کد را داخل <body> قرار دهید، اما این کار ممکن بود باعث از دست رفتن اطلاعات کاربرانی شود که پیش از بارگذاری کامل صفحه از آن خارج می‌شدند.

برای مثال، اگر وب‌سایت شما خیلی دیر لود شود و بارگذاری آن چند ثانیه طول بکشد، اجرای GTM در <body> با تأخیر شروع می‌شود. اما اگر آن را در <head> قرار دهید، اجرای آن بسیار سریع‌تر آغاز می‌شود و در نتیجه، می‌توانید رفتار تعداد بیشتری از بازدیدکنندگان را ثبت و تحلیل کنید.

فرصت ثبت کاربرانی که خیلی زود از سایت خارج می‌شوند

یکی از مزایای مهم این کار، امکان تحلیل دقیق‌تر نرخ پرش (Bounce Rate) است. با اجرای زودهنگام GTM، می‌توانید کاربرانی را که حتی قبل از لود کامل صفحه خارج می‌شوند هم شناسایی کنید.

یادتان باشد: هرچه کدهای ردیابی پایین‌تر در کدهای سایت قرار بگیرند، دیرتر اجرا می‌شوند. و همین تأخیر می‌تواند باعث از دست رفتن بخشی از دیتاهای ارزشمند شما شود.

چگونه بفهمیم Google Tag Manager به‌درستی نصب شده است؟

پس از اینکه کد Google Tag Manager (GTM) را در صفحات سایت‌تان قرار دادید، باید مطمئن شوید که این کد واقعاً به‌درستی نصب شده است. برای این کار، چند روش ساده و کاربردی وجود دارد که در ادامه به آن‌ها می‌پردازیم:

۱. مشاهده سورس صفحه

یکی از سریع‌ترین روش‌ها برای بررسی نصب GTM این است که روی پس‌زمینه سایت خود کلیک راست کرده و گزینه‌ی View Page Source (مشاهده کد منبع صفحه) را انتخاب کنید.
در صفحه‌ی بازشده، با فشردن کلیدهای ترکیبی Ctrl + F عبارت gtm.js را جستجو کنید.
اگر این عبارت را پیدا کردید، به احتمال زیاد کد GTM در صفحه شما قرار گرفته است.

۲. فعال‌سازی حالت پیش‌نمایش (Preview) و دیباگ

یکی از بهترین ابزارهایی که خود گوگل برای بررسی عملکرد تگ‌ها در اختیار شما قرار داده، حالت پیش‌نمایش و دیباگ گوگل تگ منیجر است.
برای استفاده از آن، وارد محیط کاربری GTM شوید و در گوشه‌ی بالا سمت راست روی دکمه‌ی Preview کلیک کنید.

سپس آدرس وب‌سایت خود را وارد کرده و آن را رفرش کنید. اگر کد GTM به‌درستی نصب شده باشد، در پایین صفحه، یک پنل مخصوص پیش‌نمایش و دیباگ ظاهر می‌شود که اطلاعات دقیقی از بارگذاری تگ‌ها را نشان می‌دهد.

اشتباهات رایج در نصب Google Tag Manager

نصب Google Tag Manager (یا به اختصار GTM) در ظاهر کار ساده‌ای به نظر می‌رسد؛ اما در عمل، برخی اشتباهات رایج باعث می‌شوند این ابزار به‌درستی عمل نکند یا حتی به‌کلی از کار بیفتد. در ادامه، به تعدادی از خطاهای پرتکرار که هنگام نصب GTM دیده‌ام می‌پردازم:

۱. به‌هم‌ریختن علامت نقل‌قول در کد

یکی از اشتباهات رایج، زمانی اتفاق می‌افتد که بازاریاب‌ها کد GTM را از پنل گوگل کپی می‌کنند و از طریق نرم‌افزارهایی مثل Microsoft Word یا Google Docs برای توسعه‌دهنده‌ها ارسال می‌کنند. این نرم‌افزارها اغلب علامت‌های نقل‌قول (quotation marks) موجود در کد را به‌طور خودکار تغییر می‌دهند. نتیجه؟ کدی که دیگر معتبر نیست و اجرا نمی‌شود.

برای جلوگیری از این مشکل، توصیه می‌کنم همیشه کد را از طریق ابزارهای متنی ساده مثل Notepad، VS Code یا حتی پلتفرم‌هایی مانند GitHub یا Pastebin ارسال کنید. این ابزارها تغییرات ناخواسته‌ای در ساختار کد ایجاد نمی‌کنند.

۲. قرار ندادن قطعه کد GTM در همه صفحات سایت

تنها قرار دادن کد GTM در صفحه اصلی سایت کافی نیست. GTM فقط در صفحاتی عمل می‌کند که کد آن در آن‌ها وجود داشته باشد. اگر حتی یکی از صفحات مهم، مثل صفحه پرداخت یا صفحه تماس با ما، فاقد این کد باشد، بخشی از داده‌های حیاتی از دست خواهد رفت.

در سایت‌های مدرن، معمولاً این موضوع با قرار دادن کد در فایل‌هایی مثل header.php یا بخش‌های مشترک قالب (مثل Layout در پروژه‌های React یا Next.js) مدیریت می‌شود. اما همچنان توصیه می‌کنم بررسی کنید که کد GTM در تمام صفحات وب‌سایت شما بارگذاری می‌شود. این موضوع مخصوصاً برای کسب‌وکارهای ایرانی که از سیستم‌های مدیریت محتوای بومی یا قالب‌های اختصاصی استفاده می‌کنند، اهمیت بیشتری دارد.

سوالات متداول درباره نصب گوگل تگ منیجر

در حالت ایده‌آل و توصیه‌شده، باید کد Google Tag Manager را به شکل زیر در ساختار سایت خود قرار دهید:

بخش <script> را در قسمت <head> سایت قرار دهید (معمولاً دقیقاً قبل از بسته شدن تگ </head>).
بخش <noscript> باید بلافاصله بعد از تگ <body> درج شود.

اما شرایط واقعی معمولاً با این سناریوی ایده‌آل فاصله دارد. در بسیاری از مواقع، محدودیت‌هایی در دسترسی به کدهای سایت یا تنظیمات سیستم مدیریت محتوا (CMS) باعث می‌شود که نتوانید این ساختار را به‌درستی پیاده‌سازی کنید. در ادامه، برخی از این سناریوهای غیرایده‌آل و پیامدهای آن‌ها را بررسی می‌کنیم:

آیا می‌توان تگ `<noscript>` را در جایی غیر از ابتدای `<body>` قرار داد؟

بله، امکان‌پذیر است.

این وضعیت اغلب زمانی رخ می‌دهد که از سیستم‌های مدیریت محتوای محدودی استفاده می‌کنید—مثل برخی سرویس‌های آماده ساخت سایت—که به شما اجازه دسترسی مستقیم به کدهای HTML سایت را نمی‌دهند. در این شرایط، معمولاً فقط یک فیلد مشخص برای وارد کردن کدهای رهگیری وجود دارد، و همه محتوای این فیلد در انتهای کد HTML سایت قرار می‌گیرد.

هرچند این روش توصیه نمی‌شود، اما همچنان می‌توان تگ‌های <script> و <noscript> مربوط به Google Tag Manager را در بخش <body> قرار داد.

اگر قصد شما اجرای تست‌های A/B یا آزمایش‌های مشابه با استفاده از GTM است، حتماً باید بخش اصلی اسکریپت را در تگ <head> قرار دهید تا اطمینان حاصل شود که تست‌ها بدون اختلال اجرا می‌شوند.

اما اگر صرفاً هدف شما فعال‌سازی Google Analytics یا رهگیری‌های پایه مشابه است، در اغلب موارد مشکلی نخواهید داشت.

با این حال باید به این نکته توجه داشته باشید که هرچه کد رهگیری در پایین‌تر از ساختار HTML قرار گیرد، اجرای آن نیز با تأخیر بیشتری انجام خواهد شد. این موضوع می‌تواند منجر به از دست رفتن بخشی از داده‌ها، به‌ویژه در بازدیدهای بسیار کوتاه، شود.

آیا می‌توانم بخش `<noscript>` را حذف کنم و فقط از `<script>` استفاده کنم؟

بله، می‌توانید.

اگر برای شما اهمیتی ندارد که برخی کاربران ممکن است JavaScript را به‌طور کامل غیرفعال کرده باشند، می‌توانید بخش <noscript> را به‌طور کامل حذف کنید. البته توجه داشته باشید که قراردادن کد noscript تگ منیجر در بخش <head> از لحاظ استاندارد HTML اشتباه است، چون عنصر <iframe> نباید در آن قسمت قرار بگیرد.

در نتیجه، اگر قصد استفاده از <noscript> را دارید، آن را در بخش <body> صفحه قرار دهید یا به‌کلی از آن صرف‌نظر کنید.

اگر چند سال پیش Google Tag Manager را نصب کرده‌ام و هر دو کد `<script>` و `<noscript>` در بخش body هستند، مشکلی وجود دارد؟

خیر، مشکلی نیست.

همان‌طور که پیش‌تر اشاره شد، تا اواخر سال ۲۰۱۶، گوگل توصیه می‌کرد که کل کد Google Tag Manager در بخش <body> قرار بگیرد. این روش هنوز هم کار می‌کند و مشکلی از این بابت وجود ندارد.

اما یک نکته را در نظر داشته باشید: اگر کد GTM در بخش body قرار بگیرد، ممکن است بخشی از داده‌های ردیابی (tracking) را از دست بدهید؛ چون بارگذاری GTM در body کمی دیرتر از زمانی انجام می‌شود که این کد در <head> قرار گرفته باشد.

بنابراین اگر منابع فنی کافی در اختیار دارید، توصیه می‌شود که بخش <script> را به <head> منتقل کنید تا داده‌ها با دقت و سرعت بیشتری ثبت شوند.

متغیر Click Element در گوگل تگ منیجر

در گوگل تگ منیجر Google Tag Manager، مجموعه‌ی گسترده‌ای از متغیرها در اختیار شماست؛ از متغیرهای از پیش‌تعریف‌شده گرفته تا آن‌هایی که خودتان می‌سازید. متغیر Click Element؛ یکی از متغیرهای داخلی یا همان Built-in variableهایی که کمتر کسی درباره‌اش صحبت می‌کند. پس اگر اهل ردیابی رفتار کاربران در سایت هستید و می‌خواهید از GTM مثل یک پرفورمنس مارکتر حرفه ای استفاده کنید، پیشنهاد می‌کنم ادامه‌ی این مطلب را از دست ندهید.

متغیر Click Element در گوگل تگ منیجر چیست؟

یکی از متغیرهای داخلی (Built-in Variable) در گوگل تگ منیجر، متغیری است به نام Click Element. این متغیر، عنصری از صفحه را که کاربر روی آن کلیک کرده، به‌عنوان خروجی برمی‌گرداند. اما نکته مهم اینجاست که به‌صورت پیش‌فرض در همه کانتینرهای جدید GTM غیرفعال است.

برای فعال‌سازی آن باید وارد مسیر زیر شوید:

Variables > Configure
و سپس گزینه Click Element را تیک بزنید.

فعال‌سازی متغیر به‌تنهایی کافی نیست

اگر صرفاً این متغیر را فعال کنید، در حالت پیش‌نمایش و دیباگ (Preview and Debug Mode) گوگل تگ منیجر، هیچ داده‌ای به شما نشان داده نمی‌شود. چرا؟ چون برای اینکه این متغیر کار کند، باید حداقل یکی از تریگرهای زیر را هم فعال کرده باشید:

All Elements Clicks
Just Links

اگر با مفهوم ترکینگ کلیک در GTM آشنایی ندارید، پیشنهاد می‌کنم در دوره آموزش گوگل تگ منیجر شرکت کنید.

تفاوت Click Element با Click URL

در نگاه اول ممکن است در حالت پیش‌نمایش گوگل تگ منیجر، خروجی این متغیر با متغیر Click URL یکی به نظر برسد. اما این تصور اشتباه است.

متغیر Click Element، آبجکت کامل مربوط به عنصر کلیک‌شده را برمی‌گرداند. این یعنی:

نه‌تنها لینک (URL) المان را برمی‌گرداند (اگر وجود داشته باشد)
بلکه تمام ویژگی‌ها (Attributes) و داده‌های دیگر آن المان را هم در اختیار دارد

حتی اگر این اطلاعات برای یک کاربر معمولی قابل مشاهده نباشد، این متغیر آن‌ها را نگه می‌دارد.

نکته مهم درباره Preview Mode

در حالت پیش‌نمایش GTM، ممکن است متغیر Click Element به‌صورت یک رشته (String) نمایش داده شود. این نمایش گمراه‌کننده است. در واقع، زیرساخت اصلی این متغیر همچنان یک (Object) است، نه رشته.

پس اگر در حال تست تگ یا تریگر هستید و دیدید که مقدار این متغیر به صورت یک رشته ظاهر شده، نگران نباشید؛ کارکرد واقعی آن تغییر نکرده است.

متغیر «Click Element» شامل چه دیتایی است؟

دیتای این متیغر از لیسنرهای پیش‌فرض ایونت های خودکار در Google Tag Manager (GTM) تأمین می‌شوند. اگر حتی یکی از تریگرهای زیر را در تگ منیجر فعال کرده باشید:

Just Links (کلیک روی لینک‌ها)
All Element Clicks (کلیک روی تمام عناصر)
Form Submission (ارسال فرم)
Element Visibility (قابل مشاهده شدن یک عنصر)

به‌صورت خودکار، GTM در پس‌زمینه، لیسنر مرتبط با همان ایونت را فعال می‌کند و شروع به ترک کردن تعاملات کاربران با صفحه می‌کند.

این لیسنرها دقیقاً چه کاری می‌کنند؟

Just Links کلیک روی لینک‌ها را ردیابی می‌کند.
All Element Clicks تمام کلیک‌های روی المان های مختلف صفحه (به‌جز عناصر داخل iFrame) را ردیابی می‌کند.
Form Submission تکمیل فرم را می‌کند.
Element Visibility بررسی می‌کند که چه زمانی یک المان خاص در صفحه نمایان می‌شود.

ارسال داده به Data Layer

وقتی این لیسنرها (Listeners) یک تعامل را شناسایی می‌کنند، یک سری داده به Data Layer ارسال می‌شود. این داده‌ها به المانی که کاربر با آن تعامل داشته مربوط هستند.

داده‌هایی که به dataLayer.push ارسال می‌شوند، معمولاً شامل کلیدهای زیر هستند:

gtm.element
gtm.elementClasses
gtm.elementTarget
gtm.elementUrl
gtm.elementId

برای مشاهده این مقادیر، کافی‌ست وارد بخش Preview و Debug در GTM شوید و به تب Data Layer سر بزنید.

این کلیدها چه کاربردی دارند؟

تمام این کلیدها به عنوان متغیرهای داخلی (Built-in Variables) در GTM قابل استفاده هستند، مانند:

Click Element
Click Classes
Click Target
Click URL
Click ID

به جز gtm.element که یک (Object) است و اطلاعات بیشتری در دل خودش دارد، بقیه کلیدها صرفاً رشته متنی (String) هستند.

متغیر Click Element تنها گزینه موجود نیست!

اگر قبلاً با Google Tag Manager (یا به اختصار GTM) کار کرده باشید، احتمالاً می‌دانید که متغیر Click Element وظیفه‌اش این است که مقدار ذخیره‌شده در Data Layer را از کلید gtm.element دریافت کند. حالا اگر چنین کلیدی اصلاً در Data Layer وجود نداشته باشد، نتیجه‌ای که این متغیر برمی‌گرداند چیزی نیست جز undefined.

اما فقط Click Element نیست که از این کلید استفاده می‌کند!

چیزی که احتمالاً بسیاری از کاربران تازه‌کار GTM از آن بی‌خبرند این است که یک متغیر داخلی دیگر هم وجود دارد که دقیقاً به همین کلید در Data Layer دسترسی دارد، به نام Form Element.

در واقع، هم Click Element و هم Form Element، هر دو به کلید gtm.element دسترسی دارند — یا اگر دقیق‌تر بگوییم، به کلیدی در Data Model دسترسی پیدا می‌کنند که با همین نام شناخته می‌شود.

جفت‌ متغیرهای Form و Click دقیقاً یکسان هستند

جالب است بدانید تمامی متغیرهایی که برای ایونت های کلیک (Click) و فرم (Form) تعریف شده‌اند، به کلیدهای یکسانی دسترسی دارند. به جدول زیر توجه کنید:

gtm.elementTarget توسط Click Target و Form Target
gtm.elementUrl توسط Click URL و Form URL
gtm.elementClasses توسط Click Classes و Form Classes
gtm.elementId توسط Click ID و Form ID
و در نهایت gtm.element توسط Click Element و Form Element

ایجاد متغیر دلخواه برای دسترسی به مقادیر مشترک در Data Layer

در کنار استفاده از متغیرهای پیش‌فرضی مانند Click Element یا Form Element، شما می‌توانید متغیرهای دلخواه خودتان را هم تعریف کنید تا به همان مقادیر دسترسی پیدا کنید.

فرض کنید می‌خواهید نسخه اختصاصی خودتان از متغیر Click Element را بسازید. برای این کار، کافی است به مسیر زیر در Google Tag Manager بروید:

Variables > New > Data Layer Variable

در قسمت Data Layer Variable Name، مقدار gtm.element را وارد کنید. این همان کلیدی است که داده‌ها در Data Layer در آن ذخیره می‌شوند.

نکته جالب اینجاست که متغیرهای Click Element و Form Element نیز دقیقاً از همین کلید استفاده می‌کنند. یعنی هر سه متغیر، به یک داده مشترک دسترسی دارند و نتیجه نهایی یکسانی را ارائه می‌دهند.

حالا شاید این سؤال پیش بیاید: “پس چرا باید خودمان یک متغیر جدید تعریف کنیم وقتی می‌توانیم از متغیرهای آماده استفاده کنیم؟” پاسخ مشخصی برایش وجود ندارد—هدف این بخش بیشتر این است که به شما نشان دهد ساختار GTM چطور کار می‌کند و چطور اجزا به هم متصل‌اند.

چه زمانی باید از متغیر Click Element در تگ منیجر استفاده کنیم؟

همانطور که گفته شد، این متغیر، دیتای المانی را (Object) را بازمی‌گرداند که کاربر با آن تعامل داشته است، مانند کلیک کردن روی یک عنصر، مشاهده یک المان یا ارسال یک فرم. بنابراین زمانی که نیاز دارید مستقیماً با یک عنصر واقعی در صفحه وب کار کنید، باید از این متغیر استفاده کنید.

کاربرد اصلی: استفاده از Click Element همراه با CSS Selectorها

یکی از رایج‌ترین سناریوهای استفاده از متغیر Click Element، در کنار CSS Selectorهاست. فرض کنید قصد دارید کلیک روی برخی عناصر مشخص در وب‌سایت را ردیابی کنید، اما هیچ‌کدام از آن عناصر شناسه (ID) منحصربه‌فردی ندارند. در چنین شرایطی، استفاده از CSS Selector می‌تواند راه‌گشا باشد.

ممکن است این پرسش مطرح شود که CSS Selector چیست؟
CSS Selector الگویی است که امکان انتخاب عناصر خاص در یک صفحه وب را فراهم می‌کند.

در فرآیند پیاده‌سازی ردیابی کلیک در Google Tag Manager، یکی از سناریوهای نسبتاً پیشرفته زمانی مطرح می‌شود که بخواهیم کلیک بر روی یک دکمه بدون لینک را ردیابی کنیم. در چنین شرایطی، روش‌هایی مانند استفاده از تریگرهای مرتبط با لینک (Just Links) کاربردی نخواهند بود و باید از تریگر کلی‌تر یعنی All Element Clicks بهره گرفت.

فرض کنید در حال پیاده‌سازی ردیابی کلیک روی دکمه‌ای در یک وب‌سایت فروشگاهی هستید. این دکمه فاقد لینک است و ساختار آن از دو بخش مجزا تشکیل شده است:

متن دکمه
پس‌زمینه یا قاب گرافیکی دکمه

در صورتی که این دو بخش دارای شناسه (ID) یا کلاس (Class) مشابه باشند، می‌توان از متغیرهایی نظیر Click ID یا Click Classes استفاده کرد. به‌عنوان مثال، اگر متن دکمه دارای ID با نام AddToCartText و پس‌زمینه دارای ID با نام AddToCart باشد، امکان تعریف تریگری با شرطی مانند “شروع ID با AddToCart” وجود دارد.

اما در مواردی که عناصر مورد نظر فاقد شناسه یا کلاس قابل استفاده باشند و یا ساختار آن‌ها پیچیده‌تر از این باشد (مثلاً از چندین عنصر داخلی تشکیل شده باشند)، لازم است از راهکار حرفه‌ای‌تری استفاده کنیم.

راهکار پیشنهادی: استفاده از CSS Selector برای ردیابی کلیک

به جای تعریف چند تریگر برای هر عنصر داخلی، رویکرد بهینه این است که یک تریگر واحد ایجاد کرده و از CSS Selector برای تعیین عناصر هدف بهره ببریم.

ساده ترین کاری که در این مرحله میتوانید انجام دهید این است که روی المان مورد نظر در بخش inspect راست کلیک کنید و سپس گزینه Copy Selector را انتخاب نمایید. با انجام این کار میتوانید به آدرس اختصاصی که به این المان در صفحه اشاره دارد، دسترسی پیدا کنید.

برای ساخت تریگر با استفاده از این آدرس، مراحل زیر را دنبال کنید:

به بخش Triggers مراجعه کرده و یک تریگر جدید از نوع All Elements Clicks تعریف کنید.
در قسمت شرط‌ها (Trigger Conditions)، تنظیمات زیر را اعمال کنید:

Variable: Click Element  
Condition: Matches CSS Selector  
#product-401 > div:nth-child(1) > div.row.product-image-summary-wrap > div > div > div.col-lg-8.col-12.col-md-6.text-right.summary.entry-summary > div > form > button

در این تنظیمات از متغیر Click Element استفاده می‌شود، چرا که قصد داریم کل عنصر کلیک‌شده را با Selector تطبیق دهیم. این روش تنها با همین متغیر قابل استفاده است.

آشنایی با شیء `gtm.element` در گوگل تگ منیجر

در این بخش پایانی از مقاله، به بررسی دقیق‌تری از یکی از قابلیت‌های پیشرفته گوگل تگ منیجر می‌پردازیم: شیء gtm.element. اما این آبجکت دقیقاً چه اطلاعاتی را در خود ذخیره می‌کند؟ و چگونه می‌توان به این داده‌ها دسترسی داشت، در حالی که ابزار preview و دیباگ GTM چنین امکانی را مستقیماً فراهم نمی‌کند؟

استفاده از Console برای مشاهده داده‌ها

برای مشاهده داده‌های موجود در شیء gtm.element، لازم است از ابزار توسعه‌دهنده (Developer Tools) مرورگر و به‌ویژه بخش Console استفاده نمایید. لازم است حداقل یکی از تریگرهای کلیک در صفحه فعال باشد. گزینه‌های رایج شامل موارد زیر هستند:

All Element Clicks
Just Links
Form Submission
Element Visibility

فعال‌سازی حالت Preview & Debug در GTM گرچه الزامی نیست، اما فرآیند بررسی را ساده‌تر خواهد کرد.

پس از فعال‌سازی تریگر، روی یکی از عناصر صفحه کلیک کنید. در صورتی که رویداد کلیک در پنل دیباگ GTM نمایش داده نشد، صفحه را مجدداً بارگذاری کرده و از فعال بودن تریگر اطمینان حاصل نمایید.

در این مرحله، لیستی از تمام dataLayer.push‌های اتفاق‌افتاده در صفحه قابل مشاهده خواهد بود. رویدادهایی که با gtm.click، gtm.linkClick، gtm.formSubmit یا gtm.elementVisibility آغاز می‌شوند، بسته به نوع تریگر مورد استفاده، قابل مشاهده هستند.

در صورت مشاهده چندین رویداد gtm.click، به این معناست که روی چند عنصر مختلف کلیک کرده‌اید. جهت یافتن رویداد دقیق مربوط به کلیک اخیر، عدد اختصاص داده‌شده به هر ایونت را با عدد نمایش‌داده‌شده در ابزار دیباگ GTM مقایسه نمایید (معمولاً در ابزار دیباگ، عدد یک واحد بیشتر است).

با باز کردن مثلث کنار ایونت مورد نظر در لیست dataLayer، بخشی با عنوان gtm.element قابل مشاهده خواهد بود. این بخش شامل داده‌هایی از قبیل gtm.elementId، gtm.elementClasses و سایر ویژگی‌های مرتبط با عنصر کلیک‌شده است.

با ادامه بررسی، می‌توان داده‌هایی همچون کلاس یا شناسه عنصر والد را نیز استخراج کرد. برای مثال:

مسیر gtm.element.parentElement.className کلاس عنصر والد را برمی‌گرداند.
مسیر gtm.element.parentElement.id شناسه (ID) عنصر والد را نمایش می‌دهد.

جهت بهره‌برداری از اطلاعات موجود در gtm.element، کافی است یک متغیر از نوع Data Layer Variable در GTM ایجاد نموده و مسیر کامل کلید مورد نظر را وارد نمایید. به‌عنوان نمونه:
gtm.element.parentElement.className

این متغیر مقدار کلاس عنصر والدِ عنصری را بازمی‌گرداند که کاربر روی آن کلیک کرده است. این رویکرد در سناریوهای دیگری از جمله تریگر Element Visibility یا Form Submission نیز کاربرد دارد.

سایر مسیرهای کاربردی: