بررسی ترافیک: چگونه مطمئن شویم لینک‌ها به دامنه درست هدایت می‌شوند
چه چیزی را می‌توان بازدید از دامنه درست در نظر گرفت
ترافیک زمانی به دامنه درست می‌رسد که کاربر پس از همه تغییر مسیرها، صفحه‌ای را روی هاست هدف باز کند. بررسی آدرسی که در توضیحات استریم، پروفایل یا تبلیغ قرار داده شده کافی نیست: لینک ممکن است از یک کوتاه‌کننده، ترکر، دامنه قدیمی، لندینگ میانی یا ریدایرکت جغرافیایی عبور کند.
نه فقط نام دامنه، بلکه نوع آن را هم بررسی کنید: با www و بدون www، HTTP و HTTPS، دامنه اصلی و زیردامنه. آدرس‌های site.example، www.site.example و promo.site.example ممکن است به یک پروژه تعلق داشته باشند، اما برای مرورگر، آنالیتیکس و لاگ‌ها هاست‌های متفاوتی هستند.
لینک را همان‌طور باز کنید که مخاطب باز می‌کند
از همان جایی که لینک واقعاً قرار داده شده به آن بروید: از توضیحات پخش زنده، پروفایل، پیام سنجاق‌شده، پست یا آگهی. پس از بارگذاری صفحه، نوار آدرس را بررسی کنید. URLای که در مرورگر باقی مانده مهم است، نه آدرس اولیه در پست.
- هاست نهایی را با دامنه صفحه فرود مقایسه کنید.
- مسیر را بررسی کنید: لینک ممکن است به دامنه درست اما به بخشی قدیمی هدایت شود.
- مطمئن شوید که بازدید موبایلی به زیردامنه فنی نمی‌رود.
- نتیجه را برای لینک با تگ‌های UTM و بدون آن‌ها مقایسه کنید.
- بررسی کنید که پارامترهای کمپین پس از همه تغییر مسیرها حفظ شده‌اند یا نه.
عیب بررسی دستی: فقط یک سناریو را نشان می‌دهد — مرورگر، دستگاه، منطقه و مجموعه کوکی‌های شما. برای بخشی از مخاطبان قوانین ممکن است متفاوت عمل کنند.
کل زنجیره ریدایرکت را در مرورگر و با curl بررسی کنید
برای بررسی فنی از curl با پارامترهای -I و -L استفاده کنید: این دستور هدرهای پاسخ را نشان می‌دهد و از تغییر مسیرها عبور می‌کند. به دنبال وضعیت‌های 301، 302، 307، 308 و هدرهای Location بگردید. آن‌ها نشان می‌دهند سرور در هر مرحله کاربر را به کدام آدرس هدایت می‌کند.
برای بررسی در مرورگر واقعی، ابزارهای توسعه‌دهنده را باز کنید، به تب Network بروید و Preserve log را فعال کنید. سپس لینک اولیه را باز کنید. در فهرست درخواست‌ها ریدایرکت‌ها، سند نهایی و درخواست‌هایی که پس از بارگذاری صفحه انجام می‌شوند دیده می‌شوند.
- Preserve log را فعال کنید تا فهرست پس از تغییر مسیر پاک نشود.
- در صورت نیاز کش مرورگر را غیرفعال کنید.
- لینک اولیه را از پست باز کنید یا آن را در تب جدیدی بچسبانید.
- پاسخ‌های با وضعیت 3xx را پیدا کنید.
- Request URL هر مرحله را با مقدار Location مقایسه کنید.
- دامنه و URL آخرین سند با وضعیت 200 را بررسی کنید.
چه زمانی دامنه قدیمی در زنجیره طبیعی است و چه زمانی خطاست
دامنه قدیمی در زنجیره همیشه به معنای مشکل نیست. پس از انتقال، مسیری مانند old-site.example/stream → site.example/stream طبیعی است: آدرس قدیمی درخواست را می‌پذیرد و به‌طور دائمی کاربر را به صفحه معادل در سایت جدید هدایت می‌کند. دامنه نهایی درست است، مسیر حفظ شده و تگ‌های UTM ناپدید نشده‌اند.
باگ — وضعیتی است که old-site.example/stream به صفحه اصلی سایت جدید، به لندینگ دیگری هدایت شود یا کاربر را روی دامنه قدیمی باقی بگذارد. مشکل جداگانه زمانی پیش می‌آید که پس از ریدایرکت، رشته بعد از علامت سؤال از بین برود: کاربر به صفحه درست می‌رسد، اما آنالیتیکس utm_source، utm_medium و utm_campaign را از دست می‌دهد.
نه فقط دامنه نهایی، بلکه مسیر همراه با پارامترها را هم بررسی کنید. رفتن به site.example بدون صفحه یا تگ‌های موردنیاز می‌تواند داده‌های کمپین را به همان اندازه رفتن به هاست اشتباه مخدوش کند.
ریدایرکت‌های JavaScript و پارامترهای لینک را در نظر بگیرید
curl برای پاسخ‌های سروری مناسب است، اما همیشه تغییر مسیرهایی را که با اسکریپت پس از بارگذاری صفحه اجرا می‌شوند نمی‌بیند. DevTools در مرورگر به تشخیص چنین سناریویی کمک می‌کند: ابتدا یک صفحه میانی باز می‌شود، سپس اسکریپت آدرس را تغییر می‌دهد یا کاربر را به دامنه دیگری می‌فرستد.
در Network نه فقط سند اصلی، بلکه لحظه تغییر آدرس پس از بارگذاری آن را هم بررسی کنید. اگر تگ‌های UTM ناپدید شدند، URL اولیه، مقدار Location و رشته نهایی در نوار آدرس را مقایسه کنید. این‌گونه می‌توان فهمید در کدام مرحله قانون ریدایرکت پارامترها را حذف کرده است.
عیب انتقال همه پارامترها بدون بررسی: مقادیر فنی اضافی ممکن است به دامنه هدف برسند. برای لینک‌های مهم بهتر است از قبل مشخص کنید کدام تگ‌ها، کدهای تخفیف و پارامترهای همکاری باید حفظ شوند.
مرورگرهای داخلی اپلیکیشن‌ها را بررسی کنید
شبکه‌های اجتماعی، پیام‌رسان‌ها و پلتفرم‌های استریم اغلب لینک را نه در مرورگر اصلی دستگاه، بلکه در مرورگر داخلی باز می‌کنند. چنین مرورگری ممکن است user-agent متفاوتی ارسال کند، اسکریپت‌ها را محدود کند، کوکی‌ها را ذخیره نکند یا ریدایرکت‌ها را به شکل دیگری پردازش کند.
لینک را مستقیماً از اپلیکیشن همان پلتفرمی که در آن قرار داده شده باز کنید. سپس در صورت وجود، تست را از طریق گزینه «باز کردن در مرورگر» تکرار کنید. دامنه نهایی، مسیر، تگ‌های UTM و رفتار فرم، پرداخت یا احراز هویت را مقایسه کنید.
عیب بررسی در مرورگر داخلی: همه اپلیکیشن‌ها اجازه دیدن زنجیره فنی درخواست‌ها را نمی‌دهند. با این حال همچنان مهم است، چون مخاطبان موبایلی اغلب دقیقاً از همین راه وارد می‌شوند.
بازدیدها را از مناطق و شرایط مختلف مقایسه کنید
اگر سایت از ریدایرکت جغرافیایی، CDN یا نسخه‌های مختلف لندینگ استفاده می‌کند، بررسی را از طریق VPN، پروکسی یا دستگاه راه دور در منطقه موردنظر تکرار کنید. دامنه نهایی، مسیر، پارامترهای URL و محتوای صفحه فرود را مقایسه کنید.
نه فقط کشور، بلکه زبان مرورگر، احراز هویت، کوکی‌ها و نوع دستگاه را هم بررسی کنید. این شرایط می‌توانند بر مسیر تأثیر بگذارند: مثلاً کاربری از یک منطقه به زیردامنه محلی فرستاده می‌شود و بازدیدکننده‌ای بدون کوکی به لندینگ عمومی.
عیب VPN و پروکسی: آن‌ها همیشه شرایط واقعی بیننده را به‌طور کامل بازتولید نمی‌کنند. موقعیت جغرافیایی ممکن است بر اساس چند سیگنال تعیین شود، بنابراین چنین تستی مشکل احتمالی را تأیید می‌کند اما کل مخاطبان را پوشش نمی‌دهد.
دامنه را در Yandex Metrica و GA4 تأیید کنید
در Yandex Metrica گزارش‌های صفحات ورودی و URL صفحات را ببینید. داده‌ها را بر اساس آدرس کامل یا دامنه موردنظر فیلتر کنید، سپس بخش‌بندی بر اساس تگ UTM، منبع یا کمپین اضافه کنید. این‌گونه می‌توان دید بازدیدها پس از یک جایگذاری مشخص روی کدام هاست شروع شده‌اند.
در GA4 برای چنین بررسی‌ای از بُعد Hostname همراه با صفحه فرود، منبع جلسه و کمپین استفاده کنید. مقایسه کنید چند جلسه به دامنه اصلی، آدرس قدیمی و زیردامنه‌های مهم رسیده است. اگر تگ روی چند هاست نصب شده باشد، گزارش به‌سرعت اختلاط ترافیک را نشان می‌دهد.
عیب آنالیتیکس: شمارنده‌ها بخشی از بازدیدها را به دلیل مسدودکننده‌ها، غیرفعال بودن JavaScript یا بسته شدن صفحه پیش از بارگذاری تگ ثبت نمی‌کنند. همچنین داده‌ها برای دامنه‌ای که اصلاً شمارنده روی آن نصب نیست کمکی نمی‌کنند.
درخواست‌ها را در لاگ‌های سرور بررسی کنید
لاگ‌های سرور تأیید می‌کنند کدام درخواست‌ها واقعاً به زیرساخت سایت رسیده‌اند. برای بررسی به فیلدهای زمان، Host، URL، کد پاسخ، user-agent و در صورت ارسال، referer نیاز دارید. به دنبال درخواست‌ها در بازه زمانی راه‌اندازی لینک بگردید و جداگانه درخواست‌های دامنه قدیمی و هدف را ببینید.
پاسخ‌های 301، 302، 307 و 308 نشان می‌دهند که سرور کاربر را هدایت کرده است. درخواست‌های با وضعیت 200 به هاست هدف تأیید می‌کنند که صفحه از دامنه درست ارائه شده است. اگر در لاگ‌ها انتقال به هاست قدیمی وجود دارد اما درخواستی به هاست جدید نیست، قوانین ریدایرکت و خطاهای احتمالی اتصال را بررسی کنید.
عیب لاگ‌ها: ربات‌ها، اسکنرها و درخواست‌های فنی هم در آن‌ها ثبت می‌شوند. Referer اغلب در بازدیدهای از اپلیکیشن‌ها و پیام‌رسان‌ها وجود ندارد، بنابراین همیشه نمی‌توان منبع یک بازدید مشخص را بازسازی کرد.
دامنه اصلی و زیردامنه‌ها را در گزارش‌ها جدا کنید
لندینگ، پنل کاربری، پرداخت و پایگاه دانش ممکن است روی زیردامنه‌های مختلف باشند. اگر آن‌ها را بدون بخش‌بندی در یک گزارش جمع کنید، ممکن است متوجه نشوید که لینک استریم به promo.site.example به‌جای سایت اصلی می‌رود یا به checkout.site.example پیش از آشنایی با پیشنهاد.
یک بخش‌بندی جداگانه برای هاست هدف بسازید و گزارش کلی همه دامنه‌های پروژه را نگه دارید. اولی به کنترل ترافیک صفحه فرود کمک می‌کند، دومی مسیر کاربر بین لندینگ، پرداخت و پنل کاربری را نشان می‌دهد.
عیب فیلترگذاری بیش از حد سخت‌گیرانه: ممکن است انتقال طبیعی بین زیردامنه‌ها از گزارش ناپدید شود و قیف ناقص به نظر برسد.
چک‌لیست بررسی لینک پیش از جایگذاری
- لینک را از جایی باز کنید که مخاطب آن را می‌بیند.
- دامنه نهایی، مسیر و پارامترها را در نوار آدرس بررسی کنید.
- زنجیره 3xx و هدرهای Location را با curl یا Network ببینید.
- مطمئن شوید که دامنه قدیمی هنگام ریدایرکت مسیر و تگ‌های UTM را حفظ می‌کند.
- بازدید را در مرورگر داخلی اپلیکیشن تکرار کنید.
- اگر قوانین جغرافیایی استفاده می‌شود، منطقه دیگری را بررسی کنید.
- پس از راه‌اندازی، Hostname و صفحات فرود را در آنالیتیکس مقایسه کنید.
- درخواست‌ها به هاست موردنظر را با لاگ‌های سرور تأیید کنید.
پس از تغییر دامنه، CDN، لندینگ یا قوانین ریدایرکت، هم لینک‌های جدید و هم قدیمی را بررسی کنید. توضیحات قدیمی استریم‌ها، ویدیوها و پست‌های سنجاق‌شده ممکن است همچنان مخاطب را به مسیر قدیمی هدایت کنند.
Last Articles
چه چیزهایی در طراحی و عملکرد تغییر کرده است ما سایت را به‌روزرسانی کرده‌ایم تا کار با آن سریع‌تر و راحت‌تر باشد. تغییرات اصلی مربوط به رابط کاربری، ح..
Good afternoon, I've collected all the news during this time.: 1. The main news is that prices for twitch viewers have been greatly reduced, while Tw..
1. از کد تبلیغاتی "December2025" برای 15% تخفیف برای همه بینندگان ما استفاده کنید2. ما تا 1 ژانویه قیمت‌های پایه برای ابزار پیکربندی و مقرون‌به‌صرفه‌ت..
خدمات Twitch با ثبات کار ميکنيم ، پس آماده ايم با گروه ها و فروشنده ها همکاري کنيم, صاحبان خدمات ، صاحبان ربات ها و بسیاری دیگر.اصطلاحات فردی را م..
ما خدمات twitch viewer ما را به طور کامل به روز کرده اند و اکنون کار پایدار. ما فقط از آدرس های ip با کیفیت بالا برای بینندگان استفاده می کنیم.این..
Hello everyone! Today, we are announcing a new feature—"Twitch Viewer Configurator". Now, you can customize any plan for your Twitch channel. Choo..
Greetings, I have compiled a guide for streamers, which will be very relevant at the moment. Now YouTube and twitch have disabled monetization from vi..
We have finally developed the APINow it will be more convenient for our partner sites to work with us.To update the maximum tariffs for YouTube, an up..
با توجه به محبوبیت بسیار زیاد خدمات مشارکتی و برنامه ارجاع، جدول همکاری تهیه کرده ایم. ماهیت بسیار ساده است: مخاطبان زنده بیشتر - تبلیغات بیشتر از طرف..
خدمات ما برای استریمرها
Shopee
خدمات ما برای تولیدکنندگان محتوا
