استثناهای ارجاعدهنده: دامنههای خودتان و درگاه پرداخت
دو ارجاعدهنده هستند که هیچوقت «جذب» نیستند: دامنههای خودِ شما، و درگاه پرداختی که مشتری را پس از پرداخت به سایت برمیگرداند. ادپیکس هر دو را کنار میگذارد تا اعتبار فروش به کمپینی برسد که واقعا آن را آورده — نه به بانک.
دو مسئله که شبیه هم به نظر میرسند#
هر بازدید یک «ارجاعدهنده» دارد: صفحهای که مرورگر میگوید کاربر از آن آمده. ادپیکس از این ارجاعدهنده برای تشخیص کانال جذب استفاده میکند. دو حالت هست که این ارجاعدهنده اصلا جذب نیست، و اگر کنارشان نگذارید، اعتبار فروش را از کمپین میدزدند.
| مسئله | چه اتفاقی میافتد | کجا تنظیم میشود |
|---|---|---|
| ارجاع از دامنه خودتان | رفتن از shop.example.com به example.com یک نشست جدید با منبع «Referral / shop.example.com» میسازد |
مدیریت ← «جریانهای داده» ← جریان ← «پیکربندی دامنهها» |
| بازگشت از درگاه پرداخت | مشتری پول را میدهد، بانک او را برمیگرداند، و بازدیدی که تبدیل میشود منبعش sep.shaparak.ir میشود |
فهرست داخلی — بدون تنظیم؛ میزبانهای اضافه از راه API |
هر دو یک درمان دارند: آن برخورد بهجای «جذب تازه»، به Direct تنزل مییابد — یعنی (direct) / (none) — و برخورد واقعی قبلی سرِ جایش میماند. اما دو جای مختلف تنظیم میشوند و هرکدام محدوده خودشان را دارند.
ارجاع از دامنههای خودتان#
اگر یک کسبوکار روی چند دامنه یا چند زیردامنه پخش شده — فروشگاه، وبلاگ، پنل کاربری، صفحه تسویه — هر پرش بین آنها از دید مرورگر یک ارجاع است. بدون استثنا، سایت خودتان بزرگترین «ارجاعدهنده» گزارش جذب ترافیک میشود و هر بازدیدکننده در میانه سفرش دوباره جذب میشود.
ادپیکس این میزبانها را بهصورت خودکار «داخلی» میشمارد:
- دامنه هر جریان وب این دارایی (همانی که موقع ساخت جریان وارد کردید)؛
- دامنه اصلی دارایی، که خودش از دامنه نخستین جریان وب گرفته میشود؛
- هر شرطی که در پیکربندی لینک میاندامنه همان جریان اضافه کرده باشید.
ارجاعی که با هرکدام از اینها بخورد، جذب نیست. همچنین وقتی دامنه ریشه ارجاعدهنده با دامنه ریشه صفحه فعلی یکی باشد، بدون هیچ تنظیمی داخلی حساب میشود — پس رفتوآمد بین زیردامنههای یک دامنه از روز اول درست است.
افزودن دامنههای دیگرتان#
پنج نوع تطبیق دارید. برای دامنههای خودتان تقریبا همیشه «تطبیق دقیق» درست است:
| نوع تطبیق | با چه چیزی میخورد |
|---|---|
| «تطبیق دقیق» | خود میزبان، هر زیردامنهاش، یا هر میزبانی با همان دامنه ریشه |
| «شامل» | میزبان این رشته را در خود داشته باشد |
| «شروع با» | میزبان با این رشته شروع شود |
| «پایان با» | میزبان با این رشته تمام شود |
| «تطبیق با عبارت باقاعده» | میزبان با این عبارت باقاعده بخورد |
این فهرست دو کار همزمان میکند: به تگ میگوید هنگام پرش بین دامنهها شناسه بازدیدکننده را منتقل کند (تا یک نفر دو نفر شمرده نشود)، و به سرور میگوید آن ارجاع را جذب نشمارد. برای همین در کنسول یک کارت است، نه دو تا. جزئیات لینکدهی در اندازهگیری میاندامنه و زیردامنه است.
بازگشت از درگاه پرداخت#
این همان موردی است که مستقیم روی درآمد اثر میگذارد. مشتری روی تبلیغ گوگل کلیک میکند، محصول را انتخاب میکند، به درگاه بانک میرود، پرداخت میکند، و بانک او را به صفحه «پرداخت موفق» شما برمیگرداند. مرورگر آن بازگشت را یک ارجاع تازه از sep.shaparak.ir گزارش میکند — و آخرین برخوردِ همان بازدیدی که تبدیل میشود با این ارجاع بازنویسی میشد.
نتیجهاش برای کسی که بودجه میبندد فاجعه است: کانال تبلیغاتی بیسود به نظر میرسد، یک کانال «ارجاع» خیالی ستاره فروش میشود، و تصمیم بودجه پشت عدد اشتباه میرود.
ادپیکس یک فهرست درونساخت از پردازشگرهای پرداخت دارد. این فهرست بر پایه کارکرد بسته شده، نه جغرافیا — سوییچ شاپرک کنار استرایپ و پیپال نشسته و هیچچیزش مخصوص یک بازار نیست:
| گروه | دامنههای ریشه |
|---|---|
| ایران | shaparak.ir · zarinpal.com · nextpay.org · idpay.ir · payping.ir · pay.ir · zibal.ir · behpardakht.com · vandar.io · jibit.ir · novinpal.com |
| جهانی | stripe.com · checkout.stripe.com · paypal.com · paypalobjects.com · adyen.com · checkout.com · squareup.com · square.com · razorpay.com · payu.com · braintreegateway.com · 2checkout.com · worldpay.com · klarna.com · mollie.com · authorize.net · verifone.com · ecpay.com.tw |
تطبیق روی دامنه ریشه انجام میشود و زیرمیزبانها را هم میگیرد، پس یک سطر shaparak.ir همه سوییچهای بانکی — sep، pep، sadad، asan و بقیه — را پوشش میدهد.
کمپین واقعی از کجا برمیگردد#
تنزل دادن درگاه بهتنهایی کافی نیست: اگر فقط ارجاع را دور بیندازیم، همان تبدیل بدون هیچ کمپینی میماند و به Direct میافتد — که فقط شکل دیگری از گم شدن اعتبار است.
برای همین ادپیکس آخرین برخورد هر بازدیدکننده ناشناس را سمت سرور نگه میدارد و وقتی برخورد فعلی سیگنال واقعی جذبی ندارد، همان را برمیگرداند. قاعدهاش ساده است:
- نخستین برخورد: اولین نوشتن برنده است و بعدا عوض نمیشود.
- آخرین برخورد: آخرین نوشتن برنده است، ولی فقط برای برخوردی که واقعا سیگنال جذب دارد — یعنی کمپین یا شناسه کلیک تبلیغاتی. ترافیک Direct، ارجاع دامنه خودی و بازگشت از درگاه هیچکدام این آزمون را رد نمیکنند، پس هیچکدام نمیتوانند کمپین ذخیرهشده را پاک کنند.
نتیجه عملی: خریدی که با کلیک روی تبلیغ گوگل شروع شده و از شاپرک برگشته، در اتریبیوشن زیر همان کمپین گوگل مینشیند و در جذب ترافیک دیگر یک نشست «Referral» تازه برای بانک نمیسازد.
افزودن میزبان دلخواه به فهرست استثنا#
اگر درگاه یا واسط پرداختی دارید که در فهرست درونساخت نیست — یا یک شریک که کاربر را بعد از تایید هویت یا امضای قرارداد به شما برمیگرداند — میتوانید میزبانش را به فهرست همان دارایی اضافه کنید. این فهرست روی فهرست درونساخت اجتماع میشود.
فعلا برای این کار صفحهای در کنسول نیست؛ فقط API دارد و مثل بقیه محافظت در برابر تقلب روی پلن قفل است.
| فراخوانی | کار |
|---|---|
GET /api/v1/integrity/referral-exclusion?site=<property_id> |
فهرست میزبانهای استثناشده این دارایی |
POST /api/v1/integrity/referral-exclusion?site=<property_id> |
افزودن یا بهروزرسانی یک میزبان — بدنه {"host":"…","note":"…"} |
DELETE /api/v1/integrity/referral-exclusion/{host}?site=<property_id> |
حذف یک میزبان |
خواندن فهرست برای هر بیننده دارایی باز است؛ افزودن و حذف دسترسی ویرایش میخواهد و هر دو در گزارش ممیزی ثبت میشوند. میزبان کوچک و بدون فاصله ذخیره میشود و مثل فهرست درونساخت زیرمیزبانها را هم میگیرد.
همین فهرست، گزارش تقلب را هم پاک نگه میدارد#
بازگشت از درگاه پرداخت دقیقا برعکس تقلب است: نشستی که پول داده. با این حال شکل آماریاش عجیب است — منبعی که ناگهان ظاهر میشود، تکصفحهای، با الگوی یکنواخت — و موتور تشخیص بدون راهنمایی آن را ناهنجار میبیند.
به همین دلیل محافظت در برابر تقلب همان فهرست را بهعنوان فهرست سفید میخواند: منبعی که میزبانش با یک درگاه درونساخت یا با یکی از استثناهای خود دارایی بخورد، همیشه «پاک» میماند و هرگز علامت نمیخورد. در کنار آن، شناسههای خود کسبوکار — دامنه اصلی دارایی، نام دارایی و نام سازمان — هم بهطور خودکار همین محافظت را دارند، تا ترافیک برند و داخلی خودتان بهعنوان تقلب گزارش نشود.
استثناهای ارجاعدهنده هنگام جمعآوری اعمال میشوند، نه هنگام خواندن گزارش. یک میزبان تازه ظرف حدود یک دقیقه روی رویدادهای بعدی اثر میگذارد، ولی رویدادهایی که پیشتر ذخیره شدهاند همان اسنادی را که با آن نوشته شدهاند نگه میدارند. این دقیقا برعکس تعریفهای کانال است که هنگام خواندن اعمال میشوند و ویرایششان کل تاریخچه را همان لحظه دوباره دستهبندی میکند. برای اصلاح داده تاریخی — مثلا وقتی ماهها فروش به یک درگاه نسبت داده شده — با پشتیبانی تماس بگیرید؛ اصلاح گذشته یک عملیات سمت پلتفرم است.
چطور مطمئن شوم کار میکند#
utm_source و utm_campaign مشخص باز کنید و یک خرید کامل با پرداخت واقعی یا تستی انجام دهید.اگر تقریبا همه ترافیکتان زیر Direct افتاده — نه فقط تبدیلها — مسئله جای دیگری است و اتریبیوشن نقطه شروع بهتری برای پیدا کردنش است.
پرسشهای پرتکرار#
چرا خریدهای من زیر «Referral / sep.shaparak.ir» نشستهاند؟
چون بازگشت از درگاه پرداخت، در مرورگر یک ارجاع تازه بهحساب میآمد و روی آخرین برخورد نوشته میشد — یعنی همان بازدیدی که تبدیل میشود، اعتبارش را به بانک میداد. ادپیکس حالا بازگشت از درگاه را در لحظه جمعآوری کنار میگذارد و کمپین واقعی را از آخرین برخورد ماندگارِ همان بازدیدکننده برمیگرداند. سطرهایی که پیشتر جمع شدهاند با همان اسناد قبلی میمانند.
درگاه پرداخت ما در فهرست داخلی نیست. چه کار کنم؟
میزبان آن را به فهرست استثنای همان دارایی اضافه کنید. این فهرست فعلا فقط از راه API در دسترس است — POST به /api/v1/integrity/referral-exclusion با بدنهای شامل host — و روی ویژگی محافظت در برابر تقلب قفل است. تطبیق شامل زیرمیزبانها هم میشود، پس افزودن دامنه ریشه کافی است.
استثنا کردن یک ارجاعدهنده، ترافیکش را حذف میکند؟
نه. هیچ رویدادی دور ریخته نمیشود و هیچ بازدیدکنندهای پاک نمیشود. تنها چیزی که عوض میشود این است که آن بازگشت دیگر یک «جذب» تازه شمرده نمیشود، پس نمیتواند اعتبار کمپین قبلی را پاک کند.
فرقش با تعریفهای کانال چیست؟
تعریفهای کانال هنگام خواندن اعمال میشوند، برای همین ویرایششان کل تاریخچه را همان لحظه دوباره دستهبندی میکند. استثناهای ارجاعدهنده هنگام جمعآوری اعمال میشوند و روی رویدادهای گذشته اثر ندارند — فقط ترافیک بعد از تغییر را میسازند.
ممنون — بازخورد شما به بهتر شدن مستندات کمک میکند.