بازدید صفحه و سایتهای تک صفحهای
قاعده یک جمله است — هر تغییر واقعی آدرس، یک بازدید صفحه. این صفحه میگوید تراکر چطور این قاعده را اجرا میکند، چرا نباید `ap('page')` دستی بنویسید، و چرا یک replaceState روی همان آدرس نباید چیزی بشمارد.
یک بارگذاری، یک بازدید صفحه#
قطعه کدی که کنسول میسازد فقط یک فرمان دارد: ap('init', …). همین یک فرمان دو کار میکند:
- اولین
page_viewرا میفرستد. - قلاب History را نصب میکند تا در سایتهای تک صفحهای، مسیرهای بعدی هم شمرده شوند.
پس برای شمردن بازدید صفحه هیچ فرمان دیگری لازم نیست — و نباید نوشته شود.
تا نسخههای پیشین، قطعه کد نصب علاوه بر init یک ap('page') هم داشت و آن فرمان دستی از قاعده حذف تکرار معاف بود. نتیجه اش دو بازدید صفحه در هر بارگذاری بود، و اگر تگ روی صفحه دو بار حاضر بود، سه بازدید. اندازهگیری روی ترافیک واقعی نشان داد هر بارگذاری واقعی صفحه به طور میانگین بیش از سه بازدید صفحه ثبت میکند.
هزینه اش فقط عدد بازدید صفحه نبود. تبدیل هایی که با قاعده «ساخت رویداد» روی آدرس صفحه تعریف شدهاند، از دل هر page_view ساخته میشوند؛ پس همان ضریب مستقیم روی شمار سفارش ها هم مینشست. در یکی از موارد واقعی، صفحهای که در GA4 دوازده بازدید داشت در ادپیکس ۲۹۶ بازدید نشان میداد.
قاعده شمارش#
تراکر برای هر زمینه صفحه، آخرین آدرس ای را که برایش بازدید فرستاده به خاطر میسپارد. کلید مقایسه مسیر به اضافه پرس وجو است؛ قطعه hash عمدا کنار گذاشته میشود.
| اتفاق | بازدید صفحه ثبت میشود؟ |
|---|---|
| بارگذاری اول صفحه | بله |
| رفتن به مسیر دیگر در سایت تک صفحهای | بله |
| تغییر پارامتر پرس وجو، مثل صفحه دوم فهرست | بله |
| نوسازی کامل صفحه | بله — زمینه صفحه تازه است |
replaceState یا pushState روی همان آدرس |
خیر |
| تغییر فقط در قطعه hash | خیر |
ap('page') دستی روی آدرس ای که همین حالا شمرده شده |
خیر |
سه مسیر خودکار — بازدید نخست، قلاب History، و شلیک دوباره پس از دریافت رضایت — همگی از همین یک دروازه رد میشوند. آدرس فقط وقتی «شمرده شده» علامت میخورد که رویداد واقعا ارسال شود؛ بنابراین بازدیدی که به دلیل نبود رضایت نرفته، بعد از پذیرش رضایت شلیک میشود و از دست نمیرود.
چرا replaceState روی همان آدرس نباید بشمارد#
این مهم ترین جزئیات این صفحه است. برنامه های وب مدرن — و به طور خاص WHMCS و پنل های کاربری مشابه — replaceState و pushState را برای وضعیت های غیرناوبری صدا میزنند: مرتب سازی یک جدول، عوض کردن زبانه، اعمال یک فیلتر، بازیابی موقعیت اسکرول، هر درخواست AJAX. تقریبا همیشه هم با همان آدرس قبلی.
اگر قلاب History روی هر صدا زدن شلیک کند، همه اینها بازدید صفحه میشوند. در یک سایت واقعی همین باعث شده بود شمارش بازدید صفحه و رویداد تعامل چهار تا پنج برابر GA4 شود، در حالی که شمار نشستها و ارسال فرم ها دقیقا میخواند — همان امضایی که ریشه را لو میدهد.
GA4 هم دقیقا همین کار را میکند: در اندازهگیری پیشرفته آن، «تغییر صفحه بر پایه رویدادهای History» فقط وقتی بازدید میسازد که آدرس عوض شده باشد. ادپیکس با همین قاعده هم تراز است تا اعداد دو ابزار کنار هم معنا داشته باشند.
قلاب History بازدید را در تیک بعدی مرورگر میفرستد، نه دقیقا در همان لحظه فراخوانی. این فاصله کوتاه به چارچوب سایت شما فرصت میدهد آدرس و عنوان صفحه را به روز کند، تا رویداد با عنوان درست ثبت شود.
مسیریابی با hash#
اگر مسیرهای سایت شما به شکل #/checkout هستند، تغییر مسیر بازدید صفحه نمیسازد. این عمدی است و با پیشفرض GA4 یکی است.
توجه کنید که دستور دستی هم اینجا راه حل نیست: از زمانی که حذف تکرار به مسیر دستی هم اعمال شد، ap('page') روی آدرس ای که مسیر و پرس وجویش تغییر نکرده چیزی نمیفرستد. تنها راه درست، مسیرهای واقعی با History API است — همان چیزی که هر مسیریاب مدرنی به صورت پیشفرض ارائه میدهد.
بازدید صفحه و زمان تعامل#
در سایت تک صفحهای، هر بازدید صفحهای که واقعا ثبت شود یک رویداد user_engagement هم با خود میآورد که مدت ماندن روی مسیر قبلی را حمل میکند. اگر بازدید صفحه ثبت نشود، این رویداد هم فرستاده نمیشود — به همین دلیل بود که شمارش تعامل هم دقیقا به همان نسبت باد کرده بود.
این عدد، همان چیزی است که گزارشها برای «میانگین مدت نشست» میخوانند. زمان رویداد در سرور ثبت میشود و برای محاسبه مدت به کار نمیآید، پس هر خطایی در شمارش بازدید صفحه مستقیما روی عددهای تعامل هم مینشیند.
کاری که باید بکنید#
ap('page') در آن هست، حذفش کنید و کل بلوک را با نسخه تازه جایگزین کنید.ap('track', …) را به کار ببرید؛ آن دستور حذف تکرار ندارد و هر بار میفرستد.اگر شمارش هنوز بالا بود#
سه سپر مستقل امروز از این خطا جلوگیری میکنند: قطعه کد تازه دیگر فرمان اضافه ندارد، تراکر مسیر دستی را هم حذف تکرار میکند، و گیرنده بازدیدهای تکراری را داخل یک بسته ارسالی جمع میکند. با این حال چند حالت باقی میماند:
- تراکر قدیمی هنوز در کش مرورگرها یا CDN است. فایل تراکر تا حدود یک شبانه روز کش میشود؛ بعد از آن، حتی صفحهای که قطعه کد قدیمی دارد هم خودبه خود درست میشود. منتظر نمانید و قطعه کد را عوض کنید.
- تگ دو بار روی صفحه است. تراکر برای هر شناسه اندازهگیری فقط یک بار در هر صفحه راه اندازی میشود، پس نسخه دوم بازدید اضافه نمیسازد؛ ولی داشتن دو مسیر نصب همچنان اشتباه است و باید به یکی کاهش پیدا کند.
- تبدیل های ساخته شده روی آدرس صفحه. هر بار که صفحه «پرداخت موفق» بارگذاری شود — از جمله با نوسازی یا بازگشت به عقب — یک تبدیل دیگر ساخته میشود. شمارش بازدید درست است، ولی «بارگذاری صفحه موفقیت» با «سفارش» یکی نیست. برای شمارش دقیق سفارش، شناسه سفارش لازم است و بهترین راهش ارسال از سمت سرور است.
نشانه های هر حالت و راه تشخیصشان در بازدید صفحه دو بار شمرده میشود آمده است.
پرسشهای پرتکرار#
قطعه کد قدیمی من یک خط `ap('page')` دارد. باید حذفش کنم؟
بله. آن خط بازدید صفحه را دو برابر میشمرد و ریشه شمارش چندبرابری بود. امروز هم تراکر و هم گیرنده این تکرار را خنثی میکنند، ولی درست ترین کار برداشتن خط و جایگزینی با قطعه کد تازه ای است که کنسول میسازد.
مسیریابی سایت من با hash است — چیزی شمرده نمیشود؟
تغییر hash به تنهایی بازدید صفحه نمیسازد؛ این هم رفتاری عمدی با GA4 است. دستور page دستی هم اینجا کمکی نمیکند، چون شمارش بر پایه مسیر و پرس وجوی آدرس است و آن دو در مسیریابی hash تغییر نمیکنند. راه حل، مسیرهای واقعی با History API است.
چرا شمارش من از GA4 بیشتر است؟
در بیشتر موارد یکی از این سه: قطعه کد قدیمی با دستور page اضافه، تگی که هم در قالب سایت و هم در تگ منیجر نصب شده، یا رویداد تبدیلی که با قاعده ساخت رویداد روی آدرس صفحه تعریف شده و با هر بازدید تکراری یک بار دیگر ساخته میشود.
نوسازی صفحه بازدید جدید حساب میشود؟
بله. نوسازی یعنی زمینه صفحه کاملا تازه، پس حافظه «آخرین آدرس شمرده شده» خالی میشود و بازدید دوباره ثبت میگردد. آنچه شمرده نمیشود، تغییر وضعیت داخل همان صفحه است.
ممنون — بازخورد شما به بهتر شدن مستندات کمک میکند.