قواعد ایجاد و اصلاح رویداد

دو کاری که یک قاعده می‌تواند بکند#

قواعد رویداد در «مدیریت» ← «تنظیمات دارایی» ← «رویدادها» زندگی می‌کنند و دو نوع دارند:

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

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

شرط‌ها: با چه چیزی می‌توان تطبیق داد#

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

شش نام رزرو شده مستقیم به فیلدهای خود رویداد وصل می‌شوند:

هر نام دیگری از پارامترهای همان رویداد خوانده می‌شود؛ همان‌هایی که با ap('track', …) یا ap('ecommerce', …) فرستاده‌اید. کادر پارامتر خودش پارامترهای دیده‌شده در داده شما را پیشنهاد می‌دهد و اجازه تایپ دستی هم می‌دهد.

عملگرها: eq و neq (برابر و نابرابر)، eq_ci و neq_ci (بدون حساسیت به حروف بزرگ و کوچک)، contains و not_contains، starts_with، ends_with، regex، و چهار عملگر عددی gt، gte، lt، lte. عملگرهای عددی روی مقدار غیرعددی هرگز نمی‌خوانند و عبارت باقاعده نامعتبر هم فقط «نخواندن» است، نه خطا.

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

دامنه: کدام جریان داده#

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

این تنها جایی است که رویدادها به جریان مبدأشان تفکیک می‌شوند — در گزارش‌ها این تفکیک وجود ندارد. پس اگر دو سایت زیر یک دارایی هستند و صفحه «پرداخت موفق» هر دو مسیر یکسانی دارد، قاعده را به جریان درست ببندید تا خرید یکی به حساب دیگری نوشته نشود.

شمارش: مهم‌ترین انتخاب این صفحه#

برای قاعده‌های ساخت، فهرست «این رویداد شمرده شود…» سه گزینه دارد. این انتخاب تعیین می‌کند وقتی قاعده چند بار روی یک وضعیت اجرا می‌شود، چند رویداد واقعا شمرده شود.

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

بعد از آن، ریشه اصلی درست شد: امروز هر بارگذاری صفحه دقیقا یک بازدید صفحه می‌سازد. با آن اصلاح، «یک بار به ازای هر رویداد» دوباره درست می‌شمارد — یعنی یک تبدیل به ازای هر بار بارگذاری صفحه موفقیت، همان چیزی که GA4 نشان می‌دهد — و پیش‌فرض قواعد تازه همین است.

انتخاب امروز شما:

• یک بار به ازای هر رویداد — پیش‌فرض و انتخاب درست برای بیشتر موارد.
• یک بار به ازای هر نشست — وقتی صفحه موفقیت آدرس ثابتی دارد و کاربران آن را زیاد نو می‌کنند. توجه کنید که این گزینه دو سفارش در یک نشست نیم‌ساعته را یکی می‌شمارد.
• یک بار برای هر کاربر برای هر آدرس صفحه — فقط وقتی آدرس صفحه خودش سفارش را مشخص می‌کند، مثل viewinvoice.php?id=123. اگر آدرس صفحه پرداخت موفق ثابت باشد، این گزینه هر خرید تکراری همان مشتری را برای همیشه حذف می‌کند؛ برای کسب‌وکاری که تمدید دارد، بیشتر سفارش‌ها.

شناسه تراکنش از هر حدس آدرسی قوی‌تر است#

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

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

دو راه برای رساندن این شناسه:

• سفارش را از سرور بفرستید. مسیر سرور به سرور شناسه سفارش دارد و از ابتدا دقیق است — ردیابی سمت سرور.
• یا در همان قاعده، با یک اصلاح پارامتر، transaction_id را از جایی که در دسترستان است پر کنید.

ساختن یک قاعده#

تیک «علامت‌گذاری به عنوان رویداد کلیدی» فقط میان‌بُر است؛ همان کاری را می‌کند که دستی در «رویدادهای کلیدی» انجام می‌دادید. تفاوت مهمشان را در رویدادهای کلیدی ببینید.

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

قواعد اصلاح، در عمل#

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

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

مرزهایی که باید بدانید#

• از این پس، نه گذشته‌نگر. ذخیره یک قاعده، داده‌های قبلی را تغییر نمی‌دهد.
• حداکثر یک دقیقه تا اثر. مجموعه قواعد هر دارایی هر ۶۰ ثانیه تازه می‌شود.
• فقط مسیر مرورگر. رویدادهای سرور به سرور از قواعد رد نمی‌شوند.
• مقصدهای CRM سخت‌گیرترند. رویداد تجاری‌ای که یک قاعده ساخته، تنها وقتی به مقصدهای بیرونی فرستاده می‌شود که شناسه تراکنش یا سفارش داشته باشد، یا مقدار مثبتی حمل کند. تبدیلی که فقط از آدرس صفحه ساخته شده در گزارش‌های ادپیکس می‌ماند ولی در CRM شما سفارش ثبت نمی‌کند — این عمدی است و جلوی سفارش‌های جعلی در پنل مشتری را می‌گیرد.
• ساخت، ویرایش و حذف قاعده در گزارش ممیزی ثبت می‌شود و هر سه به نقش «بازاریاب» یا بالاتر نیاز دارند.

پرسش‌های پرتکرار#

مطالب مرتبط#