بازدید صفحه دو بار شمرده میشود
وقتی شمارشها چند برابر واقعیتاند، خودِ ضریب جواب را میگوید. سه علت مستقل وجود دارد و هر کدام امضای عددی متفاوتی دارند؛ اول ضریب را اندازه بگیرید، بعد سراغ درمان بروید.
اول ضریب را اندازه بگیرید#
شمارش چندبرابری، عددی تصادفی نیست؛ تقریبا همیشه یک ضریب تمیز است. همان ضریب، علت را لو میدهد — پس پیش از هر تغییری اندازهاش بگیرید.
سریعترین راه، صفحه «صفحات لحظهای» است. کارت «بازدید به ازای هر کاربر فعال» را نگاه کنید. روی سایتی که بازدیدکنندهاش معمولا یکی دو صفحه میخواند، عددی نزدیک ۳ یعنی هر بارگذاری سه بار شمرده میشود.
راه دقیقتر، یک آزمایش دستی است:
page_view را بخوانید.عددی که میبینید، همان ضریب شماست.
امضای هر علت#
| چه میبینید | علت محتمل |
|---|---|
| دقیقا ۲ برابر، روی همه صفحهها بهطور یکنواخت | قطعه کد قدیمی: یک فرمان ap('page') کنار ap('init') |
| حدود ۳ برابر | همان قطعه کد قدیمی، روی سایتی که تگ دو بار روی آن نشسته |
| بازدید صفحه درست است ولی تبدیلها چند برابر سفارشها | قاعده «ساخت رویداد» که کلیدش آدرس صفحه است |
فقط page_view و user_engagement باد کردهاند، ولی session_start و form_submit درستاند |
تراکر قدیمی در کش، که قلاب History را روی replaceState همآدرس هم شلیک میکند |
| هر نوع رویداد به یک نسبت بالاست | ضریب نیست؛ احتمالا دو دارایی روی یک سایت یا دو بار ارسال از سمت سرور |
آن سطر چهارم مهمترین تشخیص افتراقی است: اگر همه رویدادها به یک نسبت بالا بودند، مشکل تکرار ردیف است؛ اگر فقط رویدادهای زاده بازدید صفحه بالا رفتهاند، مشکل شمارش بازدید صفحه است.
علت ۱ — قطعه کد قدیمی#
قطعه کدی که کنسول امروز میسازد فقط یک فرمان دارد: ap('init', …). همین یک فرمان اولین بازدید صفحه را میفرستد و قلاب History را هم نصب میکند.
نسخههای قدیمیتر قطعه کد، علاوه بر init یک ap('page') هم داشتند و آن فرمان دستی از قاعده حذف تکرار معاف بود. نتیجهاش دو بازدید صفحه در هر بارگذاری بود، بهطور ساختاری و همیشگی.
اندازهگیری روی ترافیک واقعی این را تایید کرد: روی یک سایت، هر بارگذاری واقعی صفحه بهطور میانگین ۳٫۳۲ بازدید صفحه ثبت میکرد.
چطور بررسی کنید: سورس صفحه زنده را باز کنید و دنبال ap('page') بگردید. اگر بلافاصله بعد از ap('init' نشسته، همین است.
درمان: کل بلوک را با قطعه کد تازه از «مدیریت» ← «جریانهای داده» ← جریان خود ← «مشاهده دستورالعمل نصب تگ» جایگزین کنید. خط ap('page') را برنگردانید.
ap('init') خودش اولین بازدید را میفرستد و مسیرهای بعدی سایت تکصفحهای را هم میشمارد. اضافهکردن ap('page') کنار آن، یک نقص است که به سایت مشتری تحویل میشود. برای هر چیزی جز بازدید صفحه، ap('track', …) را به کار ببرید.
علت ۲ — تگ دو بار نصب شده#
سایتی که تگ را هم در قالب و هم در یک تگ منیجر دارد، دو نسخه از تراکر را بارگذاری میکند. با قطعه کد قدیمی، صف مشترک فرمانها به [init, page, init, page] تبدیل میشد و نتیجه سه بازدید صفحه در هر بارگذاری بود — همان ضریب ۳.
چطور بررسی کنید: در سورس صفحه، تعداد دفعاتی را که شناسه اندازهگیری تکرار شده بشمارید. بعد کانتینر تگ منیجر را باز کنید و ببینید آنجا هم تگی برای همان شناسه هست یا نه. افزونههای سیستم مدیریت محتوا هم مظنوناند: بعضی ماژولها تگ را خودشان تزریق میکنند.
درمان: یک مسیر نصب را نگه دارید و بقیه را حذف کنید. مسیر پیشنهادی، تگ منیجر است اگر از آن استفاده میکنید، وگرنه قالب سایت.
تراکر برای هر شناسه اندازهگیری فقط یک بار در هر صفحه راهاندازی میشود، پس یک نصب دوم دیگر بازدید تکراری تولید نمیکند. این نگهبان، مشکل را در لحظه مهار میکند اما آن را حل نمیکند: دو مسیر نصب یعنی دو پیکربندی که میتوانند از هم جدا بیفتند، و روزی که یکیشان را عوض کنید بدون اینکه دیگری را ببینید، دوباره سراغتان میآید.
علت ۳ — قاعده تبدیل روی آدرس صفحه#
این علت، امضای متفاوتی دارد و بیشتر از دو تای دیگر پول از دست میدهد: شمار بازدید صفحه درست است ولی شمار تبدیل چند برابر سفارشهای واقعی است.
یک قاعده «ساخت رویداد» که شرطش آدرس صفحه است، از دل هر page_view منطبق یک رویداد تازه میسازد. تا وقتی هر بارگذاری دو بازدید صفحه میساخت، همان ضریب مستقیما روی تبدیل هم مینشست. آن ریشه اصلاح شده — ولی یک اثر باقی میماند که ربطی به نقص ندارد:
بارگذاری صفحه موفقیت با سفارش یکی نیست. مشتری صفحه فاکتور پرداختشده را نوسازی میکند، به عقب برمیگردد، یا فردا دوباره بازش میکند. هر بار، یک تبدیل دیگر.
راهنمای خودِ فرم همین را میگوید: «قاعده ای که بر اساس آدرس صفحه است با هر بازدید دوباره اجرا میشود — بارگذاری مجدد و بازدیدهای بعدی تبدیل ها را متورم میکند.»
پیش از هر تغییری: تنظیم «این رویداد شمرده شود…» روی قاعده سه هویت شمارش میدهد، و پیشفرضش همانی است که تا دلیل محکمی نداشته باشید باید بماند.
| گزینه | چه میکند |
|---|---|
| «یک بار به ازای هر رویداد» | پیشفرض. هر بارگذاری صفحه موفقیت یک تبدیل — همان عددی که GA4 نشان میدهد |
| «یک بار به ازای هر نشست» | همه اجراهای یک نشست را روی هم میگذارد. اندازهگیری روی یک دارایی واقعی نشان داد این حالت کمشمار میکند: یک روز عدد ۴۲ داد در برابر ۷۴ سفارش واقعی، چون صدها نشست واقعا بیش از یک سفارش داشتند |
| «یک بار برای هر کاربر برای هر آدرس صفحه» | برای هر بازدیدکننده و هر آدرس یکی میشمارد. فقط وقتی درست است که خودِ آدرس صفحه سفارش را مشخص کند، مثل viewinvoice.php?id=123 |
روی آدرس ثابتی مثل cart.php?a=complete، «یک بار برای هر کاربر برای هر آدرس صفحه» هر خرید تکراری همان مشتری را برای همیشه حذف میکند و «یک بار به ازای هر نشست» نشستهای چندسفارشی واقعی را یکی میکند. برای کسبوکاری که تمدید و سفارش دوباره دارد، این خطا از بازدیدهای مجددی که میخواستید حذف کنید بزرگتر است. این تنظیم را فقط وقتی عوض کنید که آدرس صفحه سفارش را حمل کند، یا سفارش دوم در یک نشست روی سایت شما ممکن نباشد.
شمارش دقیق سفارش، شناسه سفارش میخواهد#
هیچ قاعدهای که کلیدش آدرس صفحه باشد نمیتواند «سفارش» را بشمارد؛ فقط «بارگذاری صفحه» را میشمارد. اگر عدد شما باید دقیقا با تعداد سفارشهای واقعی بخواند، رویداد باید شناسه تراکنش را با خودش بیاورد. وقتی این شناسه باشد، تکرارها خودبهخود روی هم میافتند و سفارش دوم واقعی همچنان جدا شمرده میشود.
دو راه دارد: ماژول فروشگاه یا CRM شما رویداد خرید را با شناسه سفارش بفرستد، یا خودتان آن را از سمت سرور بفرستید. مسیرش در ارسال از سمت سرور آمده است.
علت ۴ — تراکر قدیمی در کش#
اگر فقط page_view و user_engagement باد کردهاند و session_start و ارسال فرم درستاند، امضای یک نقص دیگر را میبینید که در نسخههای قدیمی تراکر بود: قلاب History روی هر فراخوانی pushState و replaceState بازدید صفحه میساخت، حتی وقتی آدرس عوض نشده بود.
پنلهای کاربری و WHMCS این دو را برای مرتبسازی جدول، عوضکردن زبانه و هر درخواست AJAX صدا میزنند. روی یک سایت واقعی همین باعث شده بود شمارش بازدید صفحه چهار تا پنج برابر GA4 شود، در حالی که شمار نشستها دقیقا میخواند.
امروز بازدید خودکار فقط با تغییر واقعی آدرس ثبت میشود. اگر هنوز این امضا را میبینید، یعنی نسخه قدیمی تراکر در کش مرورگرها یا CDN مانده است. کاری لازم نیست: عمر کش فایل تراکر کوتاه است و نسخه روی CDN — کندترین حلقه زنجیره — حداکثر ظرف حدود یک شبانهروز عوض میشود و از آن به بعد هر بازدیدکننده تراکر اصلاحشده را میگیرد. قاعده کامل شمارش در بازدید صفحه و سایتهای تک صفحهای است.
سه سپری که امروز فعالاند#
پیش از اینکه دنبال علت پنجم بگردید، بدانید چه چیزهایی دیگر نمیتوانند خراب باشند:
- قطعه کد تازه فقط
ap('init')دارد. - تراکر یک بازدید را به ازای هر آدرس یکتا در هر زمینه صفحه میفرستد — و این حذف تکرار به فرمان دستی هم اعمال میشود.
- گیرنده بازدیدهای تکراری را داخل یک بسته ارسالی روی هم میگذارد. نوسازی واقعی صفحه بسته تازهای میسازد، پس هیچوقت قربانی نمیشود.
هر سه مستقلاند. یعنی حتی سایتی که قطعه کد قدیمی دارد و بهروزرسانی هم نمیکند، ظرف حدود یک شبانهروز درست میشود.
بعد از اصلاح#
رویدادهای تازه از همان لحظه درستاند، ولی ردیفهای گذشته سر جایشان میمانند. پس عدد ماه گذشته همچنان چند برابر است و مقایسه دورهبهدوره تا وقتی هر دو دوره بعد از اصلاح نباشند، بیمعناست.
برای تایید اینکه اصلاح گرفته، ضریب را دوباره اندازه بگیرید — همان آزمایش ابتدای این صفحه. اگر «بازدید به ازای هر کاربر فعال» به عددی طبیعی برگشت، کار تمام است.
پرسشهای پرتکرار#
قطعه کد من یک خط `ap('page')` دارد. حذفش کنم؟
بله. آن خط، کنار ap('init')، هر بارگذاری را دو بار میشمرد. امروز هم تراکر و هم گیرنده این تکرار را خنثی میکنند، ولی درستترین کار برداشتن خط و جایگزینی کل بلوک با قطعه کدی است که کنسول میسازد.
بازدید صفحهام درست است ولی تبدیلها چند برابر سفارشهای واقعیاند. چرا؟
چون قاعده «ساخت رویداد» شما کلیدش آدرس صفحه است و با هر بازدید همان صفحه دوباره اجرا میشود — از جمله نوسازی، بازگشت به عقب و بازدید مجدد فاکتور. بارگذاری صفحه موفقیت با سفارش یکی نیست. شمارش دقیق سفارش نیاز دارد رویداد شناسه سفارش یا تراکنش را با خودش بیاورد؛ عوض کردن تنظیم «این رویداد شمرده شود…» فقط یک خطا را با خطای دیگری عوض میکند.
تگ را هم در قالب سایت و هم در تگ منیجر گذاشتهام. الان هم دو برابر میشمارد؟
با تراکر امروز نه — برای هر شناسه اندازهگیری فقط یک بار در هر صفحه راهاندازی میشود، پس نسخه دوم بازدید اضافه نمیسازد. با تراکر قدیمی که هنوز در کش مانده، بله. در هر حال دو مسیر نصب اشتباه است و باید به یکی کاهش پیدا کند.
بعد از اصلاح، چقدر طول میکشد تا عددها درست شوند؟
رویدادهای تازه از همان لحظه درستاند. ردیفهای گذشته خودبهخود اصلاح نمیشوند؛ برای پاکسازی تاریخچه باید یک عملیات جداگانه روی داده اجرا شود که تیم پلتفرم انجامش میدهد. بازه گزارش را طوری انتخاب کنید که از تاریخ اصلاح شروع شود.
ممنون — بازخورد شما به بهتر شدن مستندات کمک میکند.