در بیشتر بحث‌های تقلب کلیک دو پرسش با هم ادغام می‌شوند و تصمیم‌های بد از همین ادغام می‌آیند. پرسش نخست این است که درخواست از کجا آمده، که یک طبقه‌بندی شبکه تقریباً پاسخ می‌دهد. پرسش دوم این است که آیا رویداد باید شمرده شود، که به قواعد واجد شرایط بودن، رفتار و نتیجه بستگی دارد. برچسب VPN شاهد پرسش نخست است و به‌تنهایی هیچ چیزی دربارهٔ پرسش دوم نمی‌گوید.

دو پرسشی که شبیه یکی به نظر می‌رسند

پرسش نخست توصیفی است: آیا این درخواست از طریق ارائه‌دهندهٔ میزبانی، VPN حفظ حریم خصوصی یا اتصال خانگی رسیده است؟ پرسش دوم هنجاری است: آیا این رویداد تعریفی را برآورده می‌کند که کسب‌وکار شما بر آن توافق کرده است؟ پاسخ‌های توصیفی ارزان و آماری‌اند. پاسخ‌های هنجاری به تعریف و به یک مالک نیاز دارند.

اشتباه گرفتن این دو، آشکارساز مغرور و نادرستی می‌سازد. می‌توانید هر درخواست را درست طبقه‌بندی کنید و همچنان رویدادهای نامعتبر را بشمارید، چون طبقه‌بندی هرگز نپرسیده است که رویداد واجد شرایط چیست.

برچسب شبکه از چه چیزی می‌تواند پشتیبانی کند

کلاس نشانی بیانیه‌ای دربارهٔ جمعیت است، نه دربارهٔ یک فرد. یک IP واحد می‌تواند جلوی NAT سطح اپراتور با هزاران مشترک، خروجی سازمانی برای یک دفتر کامل، یا VPN حفظ حریم خصوصی با کاربران بی‌ارتباط باشد. نامیدن آن نشانی به‌عنوان مشکوک، رفتار چند نفر را به همهٔ افراد پشت آن نسبت می‌دهد.

راهنمای Google دربارهٔ ترافیک نامعتبر نمونهٔ مشخص و سودمندی از مسئلهٔ تعریف است. این راهنما تقلب عمدی و کلیک‌های تصادفی را یکسان پوشش می‌دهد، یعنی مدل خود پلتفرم رویداد و بافت آن را موضوع می‌داند، نه فقط شبکهٔ تحویل را.

رشتهٔ عامل کاربر این را نجات نمی‌دهد. خودِ کلاینت آن را گزارش می‌کند، به‌سادگی تغییر می‌کند و هویت تأییدشده نیست. آن را نشانه‌ای بدانید که با خانوادهٔ دستگاه همبستگی دارد، هرگز نه بیانیه‌ای دربارهٔ قصد.

بازبینی در سطح رویداد چه چیزی اضافه می‌کند

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

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

هر رویکرد کجا شکست می‌خورد

سه سیگنال را کنار هم بگذارید تا نقاط کور آشکار شوند.

SignalQuestion it answersCharacteristic failure
Address classificationWhere did this arrive fromRejects shared exits and privacy-conscious users
Automation signalsDoes this look scriptedMisses paid human interaction entirely
Event and outcome reviewShould this countNeeds a definition and an owner to be meaningful

جدول تمام مقایسه است. هر سطر یک سیگنال واقعی با یک نقطهٔ کور واقعی است و هیچ‌یک از آن‌ها تعریف تقلب نیست.

آشکارساز را بسنجید، نه فقط ترافیک را

سه مجموعه نگه دارید: رویدادهایی که می‌دانید مشروع‌اند، رویدادهای تأییدشده به‌عنوان نامعتبر، و مواردی که نتوانستید حل کنید. آشکارساز را در برابر هر سه ارزیابی کنید. قاعده‌ای که هر خروجی مشترک را رد می‌کند روی مجموعهٔ تأییدشدهٔ نامعتبر قاطع به نظر می‌رسد و بی‌صدا به کاربران عادی آسیب می‌زند، و این دقیقاً همان بده‌بستانی است که هیچ‌کس نمی‌سنجد.

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

به تصمیم یک مالک بدهید

پیش از تغییر یک قاعده با پلتفرم سنجش یا تبلیغات و مالک سرویس هماهنگ کنید. از فرایند گزارش‌دهی و اصلاح پشتیبانی‌شدهٔ پلتفرم استفاده کنید، نه آزمودن تبلیغات درآمدزا با کلیک‌های مصنوعی، که دقیقاً همان ترافیک نامعتبری را می‌سازد که می‌خواهید از آن جلوگیری کنید.

جمع‌آوری را به هدفی محدود کنید که می‌توانید توجیه کنید. تمایل به طبقه‌بندی تقلب، اثرانگشت‌گیری بی‌پایان را به یک الزام تبدیل نمی‌کند، و راهنمای AdSense دربارهٔ ترافیک نامعتبر مرجع معقولی است برای اینکه یک پلتفرم چگونه دسته‌ها را قالب‌بندی می‌کند.

با نوشتن رویداد واجد شرایط در یک جمله شروع کنید. اگر جمله دربارهٔ منشأ شبکه باشد، شما یک سنجهٔ واسط دارید، نه یک تعریف.

مقالات مرتبط