جذب ترافیک
گزارش تفصیلی نشستمحور: هر نشست به برخوردی نسبت داده میشود که خودِ همان نشست را آورد، نه به کمپینی که شش ماه پیش آن آدم را پیدا کرده بود. ابعاد قابل تعویض، ستونهای تعامل و درآمد، و یک جدول که همهچیزش قابل مرتبسازی و جستجو است.
چیزی که این گزارش را از بقیه جدا میکند#
«جذب ترافیک» در مسیر /traffic است و واحد شمارشش نشست است. هر نشست به برخوردی نسبت داده میشود که خودِ آن نشست را آورد — یعنی منبع، رسانه و کمپینِ نخستین رویداد همان نشست.
این جمله ساده به نظر میرسد ولی نقطهای است که پیشتر اشتباه بود و اصلاحش عددها را بهطور محسوس عوض کرد. تا پیش از آن، گزارش نشستها را بر پایه اولین برخورد همیشگی کاربر گروه میکرد؛ نتیجهاش این بود که مشتری بازگشتیای که امروز روی آگهی فیسبوک کلیک کرده بود، زیر آگهی گوگلی گزارش میشد که شش ماه پیش او را پیدا کرده بود. هر بازدیدکننده بازگشتی — یعنی بهترین بخش مخاطب شما — بهطور نظاممند اشتباه اسناد میشد و کمپینهای تازه همیشه ضعیفتر از واقع به نظر میرسیدند.
امروز تقسیم کار روشن است:
| پرسش | گزارش | دامنه |
|---|---|---|
| این کاربرها را چه چیزی برای اولین بار آورد؟ | نمای کلی جذب | اولین برخورد کاربر |
| این ماه چه چیزی ترافیک آورد؟ | جذب ترافیک | برخورد خودِ نشست |
همین تفکیک در GA4 هم هست: «User acquisition» اولینبرخوردی است و «Traffic acquisition» نشستمحور. اگر عدد این صفحه را با «نمای کلی جذب» مقایسه کنید و اختلاف ببینید، چیزی خراب نیست — دو دامنه متفاوت را کنار هم گذاشتهاید.
بعد اصلی و بعد ثانویه#
بعد اصلی، ستون اول جدول است و از فهرست بالای جدول عوض میشود. شش گزینه دارد و هر ششتا نشستمحورند:
- «گروه کانال اصلی نشست»
- «منبع / رسانه نشست»
- «منبع نشست»
- «رسانه نشست»
- «کمپین نشست»
- «پلتفرم منبع نشست» — نوع شناسه کلیکی که نشست با آن آمده، و در نبود شناسه کلیک، مقدار
Manual
با دکمه «+ بعد ثانویه» یک ستون گروهبندی دوم اضافه میشود که در چهار دسته سازمان یافته است: «منبع ترافیک» (منبع، رسانه، منبع / رسانه، کمپین)، «صفحه / نمایشگر» (نام میزبان، مسیر صفحه، صفحه فرود)، «جغرافیا» (کشور، منطقه، شهر) و «پلتفرم / دستگاه» (دسته دستگاه، مرورگر، سیستمعامل).
بعد ثانویه هم مثل بعد اصلی از اولین رویداد نشست خوانده میشود. یعنی «صفحه فرود» واقعا صفحه ورود همان نشست است، و «کشور» جایی است که نشست از آن شروع شده.
انتخاب بعد، بعد ثانویه، دانهبندی زمانی و حتی مرتبسازی و تعداد ردیف در هر صفحه، برای شما ذخیره میشوند و دفعه بعد همانطور باز میشوند.
ستونهای جدول#
| ستون | تعریف |
|---|---|
| «کاربران» | کاربران یکتایی که دستکم یک نشست در این ردیف دارند |
| «نشستها» | شمار نشستهای ردیف |
| «نشستهای متعامل» | نشستهایی که شرط تعامل را برآورده میکنند (پایینتر) |
| «نرخ تعامل» | سهم نشستهای متعامل از کل نشستهای ردیف، برحسب درصد |
| «میانگین زمان تعامل» | مجموع زمان تعامل تقسیم بر شمار نشستها |
| «رویداد در هر نشست» | مجموع رویدادها تقسیم بر شمار نشستها |
| «تعداد رویداد» | شمار رویدادهای ردیف — با انتخابگر ستون میتوان آن را به یک رویداد محدود کرد |
| «رویدادهای کلیدی» | شمار رویدادهایی که در دارایی به عنوان رویداد کلیدی علامت خوردهاند |
| «نرخ رویداد کلیدی نشست» | سهم نشستهایی که دستکم یک رویداد کلیدی داشتهاند |
| «درآمد کل» | مجموع پارامتر value روی رویدادهای کلیدی |
جدول همیشه بر پایه بیشترین نشست مرتب میشود و تا پانصد ردیف را برمیگرداند.
نشست متعامل#
نشست وقتی متعامل است که دستکم یکی از این سه شرط برقرار باشد:
- مدت تعامل دستکم ۱۰ ثانیه باشد.
- دستکم دو بازدید صفحه داشته باشد.
- دستکم یک رویداد کلیدی در آن رخ داده باشد.
نرخ پرش چیزی جز وارونه همین نیست: نرخ پرش برابر است با صد منهای نرخ تعامل. اگر نرخ تعامل ۶۲ درصد است، ۳۸ درصد نشستها پریدهاند. به همین دلیل هم در این گزارش ستون جداگانهای برای پرش وجود ندارد؛ همان عدد است، از آن سو نگاه شده.
یک صفحه فرود خوب میتواند نرخ پرش بالا و نرخ تعامل بالا داشته باشد، چون بازدیدکننده در همان یک صفحه میماند، اسکرول میکند و فرم میفرستد. اگر رویداد ارسال فرم را رویداد کلیدی کنید، آن نشستها متعامل شمرده میشوند و تصویر واقعیتر میشود.
زمان تعامل از کجا میآید#
«میانگین زمان تعامل» از رویداد user_engagement ساخته میشود؛ تراکر آن را هنگام پنهانشدن صفحه و در هر جابهجایی مسیر در سایتهای تکصفحهای میفرستد و مدت واقعی ماندن روی آن صفحه را در پارامتر engagement_time_msec حمل میکند. هر بازه بیشتر از سی دقیقه دور ریخته میشود تا یک تبِ فراموششده در پسزمینه، مدت ساعتی جعلی نسازد.
آنچه برای این محاسبه به کار نمیرود، زمان ثبت رویداد در سرور است. رویدادها دستهای ارسال میشوند، پس فاصله اولین و آخرین زمان ثبت یک نشست چیزی درباره مدت حضور واقعی نمیگوید.
نمودار و دانهبندی زمانی#
نمودار بالای جدول، نشستها را در طول زمان به تفکیک همان بعد اصلی نشان میدهد و با کلید بالای کارت روی «روز»، «هفته» یا «ماه» تنظیم میشود. بازههای روز و ماه در منطقه زمانی دارایی بریده میشوند و هفته از دوشنبه شروع میشود.
نمودار و جدول از یک دانهبندی واحد ساخته میشوند: هر دو یک ردیف به ازای هر نشست میشمارند. اگر جستجویی روی ردیفهای جدول بزنید، نمودار هم به همان مقادیر محدود میشود.
وقتی مقایسه دوره روشن باشد، سنجههای بالای صفحه درصد تغییر را نشان میدهند و دوره پیشین روی نمودار هم میآید.
کار با جدول#
- مرتبسازی روی هر ستون، با کلیک روی سرستون.
- جستجوی ردیف ردیفها را فیلتر میکند و در همان حال، ردیف «مجموع» سهم مجموعه فیلترشده از کل را نشان میدهد.
- سهم از کل زیر هر ستون جمعشونده میآید؛ برای ستونهای نرخ و زمان، بهجای سهم، فاصله از میانگین نمایش داده میشود.
- انتخابگر رویداد روی ستون دو ستون را محدود میکند: «تعداد رویداد» به یک رویداد دلخواه، و ستونهای رویداد کلیدی (بههمراه درآمدشان) به یک رویداد کلیدی مشخص. این همان کاری است که در GA4 با انتخاب رویداد در سرستون انجام میدهید.
- زیر جدول، فهرست رویدادهایی که به عنوان رویداد کلیدی شمرده شدهاند بههمراه تعریف نشست متعامل نوشته میشود.
اسناد درست، وقتی مسیر خرید از درگاه پرداخت میگذرد#
این را جدا مینویسیم چون مستقیما روی همین جدول اثر دارد. وقتی مشتری پرداخت میکند، درگاه او را به سایت شما برمیگرداند و مرورگر آن بازگشت را یک ارجاع از دامنه درگاه گزارش میکند. اگر دستنخورده بماند، نشستی که تبدیل میشود زیر ارجاع بانک میرود و فروش به نام درگاه پرداخت نوشته میشود؛ کانال آگهی بیسود به نظر میرسد و بودجه بر پایه عدد غلط جابهجا میشود.
ادپیکس درگاههای پرداخت شناختهشده را در زمان دریافت رویداد تنزل میدهد — دقیقا مثل ارجاع از دامنه خودتان — و بعد برخورد آخرِ ماندگارِ همان بازدیدکننده را دوباره برقرار میکند، تا نشست بدون کمپین نماند. فهرست پایه شامل سوییچ شاپرک و درگاههای داخلی و پردازشگرهای جهانی است، و هر دارایی میتواند میزبانهای خودش را به آن اضافه کند.
ردیفهای بالای جدول را نگاه کنید. اگر یک دامنه درگاه پرداخت، یک زیردامنه خودتان، یا یک شریک واسطه پرداخت آنجا نشسته، آن ترافیک جذب نیست و باید در فهرست میزبانهای مستثنا شده اضافه شود.
نکتههای ریز که سراغشان میآیند#
- رویدادهای ارسالی از سمت سرور نشست ندارند و در شمار نشستها نمیآیند؛ در شمار رویدادها، رویدادهای کلیدی و درآمد اما کاملا حاضرند.
- «کاربران» در این جدول از شناسه بازدیدکننده شمرده میشود، پس یک نفر با دو مرورگر دو کاربر است. برای پیونددادن آنها به یک شخص، شناسایی بازدیدکننده را ببینید.
- ستون «درآمد کل» مجموع پارامتر
valueاست و واحد پول را جدا نمیکند؛ برای تصویر تفکیکشده به ازای هر ارز، گزارش تجارت الکترونیک را ببینید.
پرسشهای پرتکرار#
«نشست متعامل» دقیقا یعنی چه؟
نشستی که دستکم یکی از این سه شرط را داشته باشد — مدت تعامل ۱۰ ثانیه یا بیشتر، دو بازدید صفحه یا بیشتر، یا دستکم یک رویداد کلیدی. نرخ تعامل یعنی سهم همین نشستها از کل نشستها؛ نرخ پرش هم دقیقا وارونه همان است، یعنی صد منهای نرخ تعامل.
چرا عدد این صفحه با «نمای کلی جذب» فرق دارد؟
چون این گزارش نشستمحور است و آن یکی کاربرمحور. اینجا هر نشست زیر برخوردی میرود که همان نشست را آورد؛ آنجا هر کاربر زیر اولین برخورد همیشگیاش میماند. برای مشتریهای بازگشتی این دو عمدا فرق میکنند.
میانگین زمان تعامل از کجا میآید؟
از رویداد user_engagement که تراکر میفرستد و مدت واقعی ماندن روی صفحه را حمل میکند. زمان ثبت رویداد در سرور برای این محاسبه به کار نمیرود، چون رویدادها دستهای ارسال میشوند و اختلاف زمانهای ثبت، مدت واقعی را نشان نمیدهد.
چرا سفارشهایی که از سمت سرور میفرستم در شمار نشستها نیستند؟
چون رویداد سمت سرور نشست مرورگری ندارد و ادپیکس عمدا برایش نشست جعلی نمیسازد. آن رویدادها در شمار رویدادها، رویدادهای کلیدی و درآمد کاملا حاضرند و فقط از سنجههایی که واحدشان نشست است بیرون میمانند.
ممنون — بازخورد شما به بهتر شدن مستندات کمک میکند.