# نشست‌ها و نرخ پرش درست به نظر نمی‌رسند

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

## علامتی که شما را به اینجا آورده

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

| چیزی که می‌بینید | از کجا شروع کنید |
| --- | --- |
| دو عدد «تعامل» روی دو صفحه با هم فرق دارند | بررسی ۱ |
| نرخ پرش با گزارش قدیمی یا اسکرین‌شات پارسال نمی‌خواند | بررسی ۲ |
| عددها با ابزار دیگری یا با انتظار روزانه شما چند درصد فاصله دارند | بررسی ۳ |
| نرخ پرش ناگهان به صفر یا نزدیک صفر رسید | بررسی ۴ |
| میانگین مدت نشست صفر یا چند ثانیه است | بررسی ۵ |
| نشست‌ها از چیزی که انتظار داشتید کمترند | بررسی ۶ |

## بررسی ۱ — تعریف‌ها را با هم اشتباه نگرفته‌اید؟

بیشتر «عدد اشتباه»ها اصلا اشتباه نیستند؛ سنجه‌ای‌اند که تعریفش با تصور شما فرق دارد. این پنج تعریف را یک بار بخوانید:

| سنجه | تعریف دقیق در ادپیکس |
| --- | --- |
| نشست | مجموعه رویدادهای یک بازدیدکننده تا وقتی ۳۰ دقیقه بی‌فعالیتی پیش بیاید. پنجره غلتان است: هر رویداد تازه، ۳۰ دقیقه را از نو شروع می‌کند. |
| پرش | نشستی که یک بازدید صفحه یا کمتر دارد. |
| تعامل (کارت خانه) | ۱۰۰ منهای نرخ پرش. یعنی سهم نشست‌هایی که بیش از یک بازدید صفحه داشته‌اند. |
| نشست متعامل (جذب ترافیک) | نشستی با مدت دست‌کم ۱۰ ثانیه **یا** دست‌کم ۲ بازدید صفحه **یا** دست‌کم یک رویداد کلیدی. |
| میانگین مدت نشست | میانگین مجموع `engagement_time_msec` هر نشست — یعنی زمانی که تراکر واقعا کاربر را روی صفحه فعال دیده. |

> **دو عدد «تعامل» عمدا با هم فرق دارند**
>
> کارت «تعامل» در «خانه» فقط متمم نرخ پرش است و تنها به بازدید صفحه نگاه می‌کند. ستون «نرخ تعامل» در «جذب ترافیک» تعریف کامل نشست متعامل را به کار می‌برد و مدت و رویداد کلیدی را هم می‌پذیرد. برای همین، نشستی که یک بازدید صفحه دارد ولی کاربر سی ثانیه رویش مانده، در خانه پرش شمرده می‌شود و در جذب ترافیک متعامل. عدد جذب ترافیک همیشه بزرگ‌تر یا مساوی است.
>
> خودِ گزارش جذب ترافیک این تعریف را زیر نمودار چاپ می‌کند: «نشست متعامل = مدت ≥ ۱۰ ثانیه یا ≥ ۲ بازدید یا یک رویداد کلیدی.» وقتی عددی را برای مدیر گزارش می‌دهید، بگویید از کدام صفحه آمده.

نکته دوم: **رویداد کلیدی وارد تعریف نشست متعامل می‌شود.** اگر امروز رویدادی را در «مدیریت» ← «رویدادهای کلیدی» علامت بزنید، نرخ تعامل گذشته هم بی‌درنگ بالا می‌رود، چون فهرست رویدادهای کلیدی در زمان خواندن گزارش اعمال می‌شود، نه در زمان جمع‌آوری.

## بررسی ۲ — با عددی از پیش از اصلاح داده مقایسه می‌کنید؟

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

سوابق نشست در ادپیکس زمانی به این شکل ساخته می‌شدند که هر بار تگ یک دسته رویداد می‌فرستاد، یک ردیف نشست تازه نوشته می‌شد. نشستی که رویدادهایش در چند نوبت می‌رسید — یعنی تقریبا هر نشست واقعی — به چند ردیف تکه‌تکه می‌شد و هیچ‌کدام روی دیگری ننشست. اندازه‌گیری روی یک نصب واقعی: **۴۶۴٬۰۳۹ ردیف نشست برای ۲۵٬۰۹۹ نشست واقعی**، یعنی حدود ۱۸٫۵ برابر.

هر چیزی که از سوابق نشست می‌خواند، روی همان قطعه‌ها حساب می‌شد:

| چه چیزی | جهت خطا | چرا |
| --- | --- | --- |
| نرخ پرش | به‌شدت بالاتر از واقع | قطعه‌ای که فقط یک بازدید صفحه در خود داشت، یک نشست پرشی به نظر می‌رسید |
| کارت «تعامل» در خانه | پایین‌تر از واقع | متمم همان نرخ پرش است |
| فیلترهای نشست در نقشه‌های حرارتی | نامعتبر | «نشست اول» و «نشست‌های بعدی» روی قطعه شمرده می‌شدند، نه روی نشست |
| ورودی مطالعات مارکتینگ میکس و لیفت | متورم | هر دو شمار نشست را از همین سوابق می‌خوانند |

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

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

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

## بررسی ۳ — بازه، منطقه زمانی و مرز نشست

سه چیز که چند درصد اختلاف را توضیح می‌دهند:

- **همه بازه‌ها در منطقه زمانی دارایی حساب می‌شوند**، نه منطقه زمانی مرورگر شما. اگر دارایی روی `UTC` مانده و شما در تهران گزارش می‌خوانید، «دیروز» شما با «دیروز» گزارش سه‌ساعت‌و‌نیم جابه‌جاست و در نمودار ساعتی خیلی بیشتر به چشم می‌آید. منطقه زمانی در «مدیریت» ← «جزئیات دارایی» ← «منطقه زمانی» است. تغییرش روی گذشته هم اثر می‌کند، چون سطل‌بندی در زمان خواندن انجام می‌شود.
- **نشست‌های مرزی در دو سنجه یکسان شمرده نمی‌شوند.** شمار نشست، هر نشستی را که در بازه رویدادی داشته می‌شمارد؛ ولی نرخ پرش، نشست به ازای هر کاربر و میانگین مدت روی نشست‌هایی حساب می‌شوند که **شروعشان** در بازه افتاده باشد. نشستی که یازده و نیم شب شروع شده و تا بامداد ادامه داشته، در یکی هست و در دیگری نه. روی بازه‌های کوتاه — یک روز، یک ساعت — این اختلاف دیده می‌شود؛ روی ۲۸ روز عملا ناپیداست.
- **مقایسه دوره، بازه را می‌سازد نه فیلتر.** اگر عدد دوره پیشین عجیب است، اول بازه‌ای را که انتخابگر تاریخ ساخته نگاه کنید.

## بررسی ۴ — نرخ پرش ناگهان به صفر رسید

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

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

- یک فراخوانی `ap('page')` اضافه کنار `init` — خودِ `init` نخستین بازدید صفحه را می‌فرستد و قلاب مسیریابی تک‌صفحه‌ای را هم نصب می‌کند.
- دو نسخه از تگ روی یک صفحه، مثلا یکی در قالب سایت و یکی از طریق یک افزونه.

هر دو در [بازدید صفحه دو بار شمرده می‌شود](analytics/troubleshooting/page-views-counted-twice) باز شده‌اند. برای رفتار سایت‌های تک‌صفحه‌ای، [بازدید صفحه و سایت‌های تک‌صفحه‌ای](analytics/collect/spa-and-page-view) را ببینید.

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

## بررسی ۵ — میانگین مدت نشست صفر یا چند ثانیه است

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

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

اگر عدد صفر یا غیرواقعی کوتاه است، به این ترتیب بررسی کنید:

1. در گزارش رویدادها ببینید رویداد `user_engagement` اصلا وجود دارد یا نه. اگر نیست، مشکل در جمع‌آوری است نه در گزارش.
2. نسخه تگ نصب‌شده را بررسی کنید. قطعه نصب در «مدیریت» ← «جریان‌های داده» ساخته می‌شود و نسخه را روی خودش دارد؛ نسخه‌های بسیار قدیمی این سیگنال را نمی‌فرستند.
3. اگر بنر رضایت روشن است، ببینید رضایت «آماری» گرفته می‌شود یا نه. بدون آن هیچ رویدادی — از جمله همین — فرستاده نمی‌شود. مسیرش در [رضایت جلوی داده را گرفته است](analytics/troubleshooting/consent-is-blocking-data) است.
4. رفتار واقعی کاربر را کنار بگذارید: ترافیکی که با یک کلیک می‌آید و بلافاصله می‌رود، واقعا مدت نزدیک صفر دارد. اگر فقط یک کانال مدت صفر دارد و بقیه سالم‌اند، مشکل داده نیست.

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

## بررسی ۶ — نشست‌ها از انتظار کمترند

سه چیز عمدا در سنجه‌های نشست شمرده نمی‌شوند:

- **رویدادهای سمت سرور نشست ندارند.** یک سفارش که از بک‌اند شما یا از ماژول CRM می‌آید در مرورگر رخ نداده و ادپیکس عمدا برایش نشست جعلی نمی‌سازد — وگرنه هر سفارش یک «نشست» تازه می‌شد و نرخ تبدیل را خراب می‌کرد. این رویدادها در شمار رویداد، رویداد کلیدی، درآمد و اسناد کاربر کاملا حاضرند و فقط از سنجه‌هایی که واحدشان نشست است بیرون می‌مانند. جزئیات در [ردیابی سمت سرور](analytics/collect/server-side-tracking).
- **محدوده‌های IP حذف‌شده شمرده نمی‌شوند.** فهرستشان در «مدیریت» ← «جزئیات دارایی» ← «CIDRهای حذف شده» است. اگر دفتر خودتان را آنجا گذاشته‌اید، ترافیک داخلی نباید دیده شود. حذف در گیرنده انجام می‌شود، پس این بازدیدها اصلا نشستی نمی‌سازند.
- **در حالت پذیرش، بازدیدکننده‌ای که هنوز روی بنر تصمیم نگرفته اصلا رویدادی نمی‌فرستد** و نشستی هم نمی‌سازد.

## اگر هیچ‌کدام جواب نداد

پیش از باز کردن تیکت، این چهار چیز را کنار هم بگذارید — همین‌ها نصف کار بررسی را جلو می‌اندازند:

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

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

### چرا «تعامل» در خانه با «نرخ تعامل» در جذب ترافیک یکی نیست؟

چون دو تعریف متفاوت‌اند و هر دو عمدی. «تعامل» خانه دقیقا متمم نرخ پرش است: هر نشستی که بیش از یک بازدید صفحه دارد. «نرخ تعامل» در جذب ترافیک تعریف کامل نشست متعامل را به کار می‌برد: مدت دست‌کم ۱۰ ثانیه یا دست‌کم ۲ بازدید یا یک رویداد کلیدی. عدد دوم همیشه بزرگ‌تر یا مساوی است.

### نرخ پرش من ناگهان صفر شد. چه اتفاقی افتاده؟

تقریبا همیشه یعنی هر بازدید صفحه دو بار شمرده می‌شود، پس هیچ نشستی زیر دو بازدید نمی‌ماند و چیزی پرش حساب نمی‌شود. معمول‌ترین علتش یک `ap('page')` اضافه کنار `init` یا دو نسخه تگ روی یک صفحه است.

### چرا میانگین مدت نشست من صفر است؟

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

### عددهای امسالم با خروجی سال گذشته‌ام نمی‌خواند. کدام درست است؟

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

## مطالب مرتبط

- [صفحه خانه](https://docs.adpix.io/fa/analytics/reports/home/)
- [جذب ترافیک](https://docs.adpix.io/fa/analytics/reports/traffic-acquisition/)
- [ردیابی سمت سرور](https://docs.adpix.io/fa/analytics/collect/server-side-tracking/)
- [بازدید صفحه دو بار شمرده می‌شود](https://docs.adpix.io/fa/analytics/troubleshooting/page-views-counted-twice/)

---

[مستندات](https://docs.adpix.io/fa/analytics/troubleshooting/sessions-and-bounce-look-wrong/) · AdPix