منع الاحتيالكيف تكتشف احتيال النقرات عبر عنوان IP (دون قائمة استبعاد)
اكتشف احتيال النقرات عبر عنوان IP بالتقييم لا بقوائم الاستبعاد: يحدّ Google Ads هذه القوائم بـ 500 لكل حملة، وتتبدل عناوين الاحتيال أسرع مما تستطيع إضافتها.
يكتشف كل معلن احتيال النقرات بالطريقة نفسها. يبدو رسم الإنفاق طبيعيًّا، ويبدو رسم النقرات رائعًا، ويبدو رسم التحويلات خطًّا مسطحًا. تفتح السجلات الخام، وترتّبها بحسب IP، وها هو: العنوان نفسه، أربعين مرة، دون تحويلات، كلها في عصر يوم واحد.
فتفعل البديهي. تلصق ذلك العنوان في قائمة استبعاد IP.
ينجح الأمر، لوقت قصير. ثم تعود النقرات من عنوان مختلف، ثم آخر، ثم آخر، وعند الإدخال الثلاثين تقريبًا في قائمة الاستبعاد تبدأ بالشك في أنك تلعب لعبة لا تستطيع الفوز بها. وهو كذلك. قائمة الاستبعاد ليست نسخة ضعيفة من الأداة الصحيحة. إنها الأداة الخاطئة، ويستحق الأمر أن نفهم بالضبط لماذا قبل أن ننظر في ما يحل محلها: درجة احتيال للشبكة الواقفة خلف كل نقرة.
ما الذي تفعله منصات الإعلانات فعلًا بشأن النقرات غير الصالحة
ابدأ بما يفترض معظم المعلنين أنه معالَج أصلًا.
يرشّح Google الحركة غير الصالحة، ويقول ذلك بوضوح. تعرّف وثائقه عن الحركة غير الصالحة الحركة غير الصالحة بأنها «حركة لا تمثّل اهتمامًا حقيقيًّا بنشاطك التجاري»، وتنص على أنه «إذا حدّد Google تفاعلًا على أنه غير صالح قبل نهاية دورة الفوترة، فلن تدفع مقابله». أعدنا قراءة تلك الصفحة في 2026-10-13 وقد أُعيدت كتابتها، فالاقتباسات في هذا القسم هي صياغتها الحالية.
هذا حقيقي، وليس بالأمر الهيّن. لكن اقرأ ما الذي يحميه. إنه يحمي الفاتورة. فالحركة غير الصالحة المكتشفة قبل نهاية الشهر «تُزال تلقائيًّا من فواتيرك وتقارير حملاتك، فلا حاجة إلى استرداد». وإن وجدها Google بعد محاسبتك، «ستتلقى أرصدة على شكل تسوية فوترة بقيمة النشاط غير الصالح». لا شيء من ذلك يخبرك أي كلمة مفتاحية أو موضع أو جمهور يجذب الاحتيال. ولا يمنع الحركة من تلويث تحليلاتك، ولا يمنع تحويلًا مزيفًا من الوصول إلى نموذج المزايدة لديك.
يمكنك أن تطلب من Google التحقيق في حركة فاتته، ضمن حدود. فـ Google «يحصر التحقيقات في الأيام الستين الماضية»، وتحذر الصفحة نفسها من أن «التحقيق لن يستطيع تأكيد ما إذا كانت نقرات بعينها قد صُنّفت صالحة أم غير صالحة». وسبب Google أن مشاركة تلك التفاصيل ستساعد الجهات السيئة على تفادي دفاعاته. وهو سبب وجيه، لكنه يتركك دون إجابة على مستوى النقرة.
أقرب ما يكون إلى تفصيل هو تقرير رصيد النشاط غير الصالح. فهو «يفصّل هذه الأرصدة بحسب الحملة والشبكة» ويضيف النقرات والتفاعلات وراء كل رصيد. وهو متاح لحملات البحث وPerformance Max فقط، ويغطي الأرصدة، التي تُصدر عن النشاط غير الصالح المكتشف بعد الفاتورة. أما الحركة التي رشّحها Google قبل الفوترة فلا تصير رصيدًا أبدًا، فهي ليست في هذا التقرير.
وإفصاح Meta المماثل أرق من ذلك. تقول صفحتها عن النقرات غير الصالحة إن Meta «تتخذ عدة خطوات لتقليل خطر إساءة الاستخدام من النقرات غير الصالحة»، وتجري مراجعة يدوية حين يُكتشف نشاط مشبوه أو يُبلَّغ عنه، ولن تحاسبك على النقرات التي تقرر أنها غير صالحة. وذلك هو الالتزام كله.
كلتا المنصتين تصحّحان واجبهما بنفسيهما، على المقياس الوحيد الذي تتباعد فيه مصالحهما عن مصالحك. وما يتبقى بعد ترشيحهما هو مشكلتك، ومشكلتك تُقاس بالاستراتيجية لا بالدولارات فحسب.
لماذا تفشل قائمة استبعاد IP
- ينفد مكانها، ولا تستطيع تسمية شبكة. يحدّ Google Ads استبعادات IP بـ 500 لكل حملة و500 لكل حساب، وتوثّق الواجهة حرفًا بدلًا (wildcard) في الثمانية الأخيرة فقط، ولا تقبل Performance Max الاستبعادات إلا على مستوى الحساب. نغطي الحدود الدقيقة، وإدخالات CIDR عبر الواجهة البرمجية، وأي العناوين تستحق مكانًا في دليل حد استبعاد IP في Google Ads.
- لا وجود لها في Meta. ليس في مدير إعلانات Meta ميزة استبعاد IP. وتلتف كل أدوات احتيال النقرات الخارجية لـ Meta على ذلك بدفع المستخدمين المشبوهين إلى استبعاد في جمهور مخصص، وهي آلية مختلفة جوهريًّا وأكثر فظاظة.
هذه هي الحدود الميكانيكية. أما الحد الاستراتيجي فأسوأ.
العناوين تتبدل أسرع مما تستطيع أن تكتب
الطرف المحترف من احتيال الإعلانات لا يعمل من عنوان ثابت. إنه يستأجر عناوين IP سكنية بالملايين.
في 2025 رفعت Google دعوى على مشغلي شبكة البوتات BADBOX 2.0، التي اخترقت أكثر من 10 ملايين جهاز Android غير معتمد. اقرأ ما استُخدم له كل جهاز من هذه الأجهزة المصابة: إنشاء عقد بروكسي سكنية، واحتيال الإعلانات البرمجي، والإعلانات المخفية، واحتيال النقرات. كل ذلك من صندوق تلفاز واحد مخترق في غرفة معيشة أحدهم. ووجد بحث PROXYLIB من HUMAN Security سلسلة الإمداد التي تغذيها: تطبيقات Android منشورة على Google Play تضم هواتف مستخدميها بصمت كعقد خروج بروكسي.
هذه هي البنية التحتية نفسها التي كتبنا عنها في لماذا توجد بروكسيات سكنية كثيرة في حركتك. وبالنسبة إلى المعلن يعني ذلك أن النقرة الاحتيالية التي كلفتك للتو 14 دولارًا جاءت من اتصال نطاق عريض منزلي حقيقي في مدينتك المستهدفة، يعود إلى شخص حقيقي لا يعلم أن جهاز التوجيه لديه مؤجَّر. لا يوجد عنوان لتحظره. هناك عشرة ملايين منها، وغدًا ستكون عشرة ملايين مختلفة.
وحظرها يصيب العملاء الحقيقيين
وهذا هو الجزء الذي يكلف بصمت أكثر من الاحتيال نفسه.
لم يعد عنوان IP عام واحد يعني شخصًا واحدًا. تضع ترجمة العناوين على مستوى المشغل مئات أو آلاف مشتركي الجوال خلف عنوان عام واحد، وRFC 6269، تقييم IETF لما يكسره تشارك العناوين، سمّت النتيجة منذ سنوات: حين يعاقب خادم عنوانًا مشتركًا، فإن «مستخدمًا واحدًا يفشل في عدد من محاولات الدخول قد يحجب مستخدمين آخرين لم يجروا أي محاولات سابقة».
استبدل "محاولات الدخول" بـ"النقرات الاحتيالية" وستحصل على قائمة الاستبعاد لديك. استبعد استبعادًا دائمًا عنوان IP المشغل الذي صادف أن كان محتال واحد خلفه، وستكون قد محوت عددًا مجهولًا من متسوقي الجوال الحقيقيين من كل حملة في الحساب: بصمت، دون تقرير، إلى الأبد. وهو نسخة إنفاق الإعلانات من مشكلة الرفض الخاطئ التي غطيناها في اكتشاف الحركة المجهولة الهوية دون حجب العملاء الحقيقيين.
ليس لقائمة الاستبعاد مفهوم "ربما سيئ". لديها فقط "محظور". وذلك هو عيب التصميم القاتل، ولهذا فالجواب ليس قائمة أطول.
إعادة الصياغة: عنوان IP دليل لا حكم
توقف عن السؤال "هل هذا العنوان في قائمتي السيئة؟" وابدأ بالسؤال "من أي نوع من الشبكات تأتي هذه النقرة، وكم أثق بها؟"
لهذا السؤال جواب غني، لأن عنوان IP يحمل قدرًا كبيرًا من السياق لا علاقة له بتاريخ سمعته. وهذا السياق يصعب على المحتال تزييفه، لأنه خاصية للبنية التحتية التي يستعيرها لا للطلب الذي يرسله.
وقد أضفى القطاع على هذا طابعًا رسميًّا أصلًا، وهو ما يفوته معظم نصائح الدفع بالنقرة.
ما تشترطه المعايير أصلًا
تقسّم معايير الكشف عن الحركة غير الصالحة وترشيحها لدى Media Rating Council الحركة غير الصالحة إلى مستويين، ويطابق هذا التقسيم تقريبًا مدى صعوبة قراءة عنوان IP. الحركة غير الصالحة العامة (GIVT) تُلتقط «بتطبيق القوائم أو بفحوص معاملات قياسية أخرى»، وأول فئة تدرجها MRC تحتها هي حركة مراكز البيانات غير الصالحة المعروفة. أما الحركة غير الصالحة المتطورة (SIVT) فهي المستوى الأصعب الذي يتطلب «تحليلات متقدمة، وتأييدًا/تنسيقًا متعدد النقاط، وتدخلًا بشريًّا كبيرًا»، وتقع فيه حركة البروكسي غير الصالحة. نستعرض كل فئة في المستويين، إلى جانب فئات Google التسع، ونقول أيها يستطيع استعلام IP رؤيته، في GIVT مقابل SIVT: فئات الحركة غير الصالحة لدى Google.
وتجعل إرشادات Certified Against Fraud لدى TAG نصف مراكز البيانات إلزاميًّا: فالشركة المعتمدة «يجب أن تطبق ترشيح تهديدات IP لمراكز البيانات عبر كل المعاملات القابلة للتحقيق (بما فيها مرات الظهور والنقرات والتحويلات وغيرها)»، ويضيف البند 4.8.a أن استخدام قائمة TAG Data Center IP List وحدها لا يُحتسب. ويترتب على ذلك أمران للمعلن. إذا كانت هيئات المعايير تعد ترشيح عناوين IP لمراكز البيانات حدًّا أدنى للامتثال، فالمعلن الذي لا يفعله دون الحد الأدنى. وتقول المعايير ما يقوله هذا المقال: القوائم تعالج المستوى السهل، والمستوى الصعب يحتاج إلى تحليل.
إشارات عنوان IP التي تكتشف احتيال النقرات
إليك ما تقرؤه من عنوان IP، تقريبًا بترتيب نسبة الإشارة إلى الضجيج للحركة المدفوعة. وللاطلاع على الأعلام نفسها مطبقة على البوتات خارج نقرات الإعلانات، وأين يعمى كل منها، انظر أي إشارات IP تحدد البوتات.
| الإشارة | ما تلتقطه | كيف تعاملها |
|---|---|---|
| نوع الاتصال / نوع ASN هو استضافة | البوتات والسكربتات والكاشطات ومزارع النقرات التي تعمل على السحابة. أول فئة GIVT لدى MRC. | سلبية قوية. البشر لا يتسوقون من AWS. |
| زاحف مزوَّر | حركة تدّعي أنها Googlebot/GPTBot من عنوان IP خارج نطاقات المشغّل المنشورة. | سلبية قوية. تتحقق واجهتنا البرمجية من العنوان مقابل نطاقات المشغّل المنشورة (`threat.crawler.verified`)؛ ويقارن كودك ذلك مع User-Agent الذي يدّعيه الطلب. |
| أعلام الماسح / شبكة البوتات / مرسل السبام | بنية تحتية لها سجل إساءة نشط في مصادر التهديد العامة. | سلبية قوية حين تكون حديثة. زِن بحسب last_seen لا بمجرد الإدراج. |
| بروكسي عام / Tor / VPN | إخفاء متعمد للمصدر. | ضعيفة بمفردها، فكثير من المشترين الحقيقيين يستخدمون VPN. زِنها ولا تحظر بناءً عليها أبدًا. |
| بروكسي سكني / جوال | الاحتيال الباهظ: حركة من فئة BADBOX ترتدي مزود إنترنت منزليًّا حقيقيًّا. | المستوى الصعب (SIVT). لا يلتقطه استعلام IP واحد: يقيّم GeoIPHub هذه العناوين على أنها سكنية. استخدم سرعة النقرات ومعدلات التحويل ومزودًا متخصصًا. |
| عنوان وهمي (Bogon) | فضاء عناوين غير مخصص أو محجوز لا يمكن أن تصدر عنه نقرة مشروعة. | سلبية قوية. النقرة من عنوان وهمي معطوبة أو مزوَّرة. |
| CGNAT / عنوان مشترك | مستخدمو الجوال والخطوط المشتركة خلف عنوان عام واحد. | مبرِّئة لا مجرِّمة. قيّد المخاطر هنا وإلا عاقبت أناسًا حقيقيين. |
لاحظ اتجاه الصف الأخير. لا يضيف نموذج التقييم الجيد نقاطًا فحسب. إنه يطرحها أيضًا. فمزود الإنترنت السكني والزاحف الموثَّق سببان للتسامح أكثر، ونطاق ترجمة العناوين على مستوى المشغل تُقيَّد درجته، ونظام يفتقر إليها سيطحن جمهورك الحقيقي على الجوال في إيجابيات كاذبة. وهذا المبدأ موضح سببًا سببًا في الأسباب المبرِّئة وراء درجة الاحتيال، وهو أهم في الإعلان منه في أي مكان تقريبًا، لأن الإيجابية الكاذبة في الحركة المدفوعة ليست محاولة دخول محجوبة. إنها عميل دفعت لاكتسابه ثم رميته.
قراءته في استدعاء واحد
عمليًّا، هذا استعلام واحد عن عنوان IP الذي أطلق النقرة، قبل أن تقرر ما قيمتها. يمكنك إجراء الفحص نفسه يدويًّا في أداة فحص درجة احتيال IP المجانية.
curl -H "x-api-key: YOUR_API_KEY" \
https://api.geoiphub.com/v1/lookup/45.33.32.156
الحقول المهمة لنقرة مدفوعة موزعة على أربع مجموعات من الاستجابة:
const res = await fetch(`https://api.geoiphub.com/v1/lookup/${clickIp}`, {
headers: { "x-api-key": process.env.GEOIPHUB_API_KEY },
});
const ip = await res.json();
ip.asn.asn_type; // "hosting": the MRC's first GIVT category
ip.asn.connection_type; // "datacenter" | "residential" | "mobile"
ip.detection.is_hosting; // true for cloud and hosting ranges
ip.threat.crawler.verified; // true only inside an operator's published ranges; compare with the User-Agent in your code
ip.threat.is_cgnat; // shared address: a reason for leniency, not suspicion
ip.scoring.fraud_score; // 0 to 100 composite
ip.scoring.recommended_action; // "allow" | "review" | "step_up" | "block"
ip.scoring.detection_methods; // exactly which signals fired: your audit trail
نقرة من الاستضافة تحصل على درجة منخفضة، ونقرة من Tor تحصل على 100
لن تخصم الدرجة وحدها نقرة مركز البيانات نيابةً عنك، وتبيّن ذلك نتيجتان حقيقيتان لماذا تقرأ الحقول مع ذلك. استعلمنا عن العنوانين في 2026-10-13 وأعدنا تشغيلهما في 2026-10-14 بالقيم نفسها؛ والكتلة الأولى هي استجابة 2026-10-14. تتغير النتائج مع تحرك النطاقات. الأول هو عنوان الاستضافة من الطلب أعلاه: scanme.nmap.org، مضيف الاختبار العام الذي تشغّله Nmap على Akamai Connected Cloud في فريمونت، كاليفورنيا. لم ينقر على إعلان أحد. إنه يمثّل أي خادم سحابي عادي:
{
"ip": "45.33.32.156",
"asn": {
"asn": 63949,
"org": "AKAMAI-LINODE-AP - Akamai Connected Cloud",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"detection": {
"is_vpn": false,
"is_tor": false,
"is_hosting": true
},
"threat": {
"is_cgnat": false,
"crawler": { "verified": false }
},
"scoring": {
"fraud_score": 10,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip"]
}
}
والثاني عقدة خروج Tor في هامبورغ:
{
"ip": "185.220.101.1",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"detection": {
"is_tor": true,
"is_hosting": true,
"anonymity_level": "high"
},
"threat": {
"is_spammer": true,
"threat_types": ["spammer", "tor"]
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"]
}
}
يحصل الخادم السحابي على 10 وallow، وطريقته الوحيدة datacenter_ip. وهذا مقصود: فالدرجة العامة مبنية لكل أنواع الحركة، بما فيها استدعاءات الواجهات البرمجية والخروج المؤسسي، حيث لا يُعد عنوان الاستضافة وحده احتيالًا. والنقرة المدفوعة مختلفة، لأن المتسوق لا ينقر على إعلانك من خادم، فلحركة الإعلانات طبّق قاعدتك الخاصة على asn.connection_type أو detection.is_hosting بدل أن تنتظر الدرجة لتقول block. أما عقدة خروج Tor فلا تحتاج قاعدة إضافية: إنها تحصل على 100 وblock، وتسمّي detection_methods أربعة أسباب مستقلة (عقدة خروج Tor، ونطاق مركز بيانات في قائمة حجب، وDNS عكسي بنمط Tor، ومرسل سبام معروف).
ويقع VPN بين الاثنين. حتى هذا التحديث، كان هذا المقال يستخدم 45.83.220.7 مثالًا لعنوان استضافة عادي. وفي 2026-10-13 تسمّيه الواجهة البرمجية خادم Mullvad وتقيّمه بـ 46 وreview، مع known_vpn_server وdatacenter_ip. وهذا هو الوزن الذي يطلبه جدول الإشارات: نقرة VPN سبب لتدقق النظر لا لتحظر، وهي أيضًا تذكير بإعادة أي استعلام قبل أن تثق بنتيجة قديمة.
هذا الحقل هو ما يحوّل الأمر من صندوق أسود إلى شيء تستطيع الدفاع عنه في مراجعة جودة الوسائط. فحين تُخصم نقرة، تستطيع أن تقول بدقة لماذا: اتصال مركز بيانات على نقرة مدفوعة، أو عقدة خروج Tor مع إدراج سبام. "قالت الدرجة ذلك" ليست جوابًا ينبغي أن يقبله أحد، وأقلهم من أدوات الاحتيال الخاصة به.
احمِ إشارة المزايدة، لا النقرة فحسب
هذا هو الجزء الذي يغيّر الاقتصاد، وهو الموضع الذي يقصّر فيه المعلنون في الاستثمار باستمرار.
حجب نقرة احتيالية يوفر عليك تكلفة تلك النقرة. أما منع تحويل احتيالي فيوفر عليك شيئًا أغلى بكثير: تعليم خوارزمية المزايدة لديك أن تشتري المزيد من الاحتيال.
تعمل المزايدة الذكية Smart Bidding وتحسين Meta بتعلّم أي مجموعات إشارات تنتج تحويلات والمزايدة بقوة أكبر نحوها. فإذا غذّيت تلك الحلقة بتحويل مزيف فلم تخسر نقرة واحدة. بل دفعت لتدريب النموذج على أن يذهب ويجد مزيدًا من الحركة التي تشبه تمامًا الحركة التي احتالت عليك للتو. وسيطاردها النظام بحماسة ويُبلغ عن نتائج ممتازة، لأنه بمقياسه هو ناجح.
ولنكن دقيقين فيما هو موثَّق هنا وما ليس موثَّقًا: لا ينشر Google بيانًا بأن التحويلات الاحتيالية تسمّم المزايدة الآلية. وما تقوله وثائق المزايدة الذكية لدى Google هو أنه «إذا كانت بيانات تتبع التحويلات غير دقيقة، فقد ترى تقلبات في حجمك أو CPA أو ROAS»، مع إشارتها أيضًا إلى أن المزايدة الذكية تستطيع التفاعل مع البيانات غير الدقيقة والتكيف معها. والادعاء الأقوى أعلاه حجة مستدلة من طريقة عمل التحسين، لا اقتباس من Google، وينبغي أن تعامله على هذا الأساس. لكنه حجة مباشرة: فالمُحسِّن يعظّم أي شيء يُطلب منه عدّه.
والضابط العملي من جهة الخادم، وهو الموضع الوحيد الذي تمنحك فيه Meta تحكمًا أكبر من Google لا أقل. فلأن Conversions API قناة من خادم إلى خادم، يقرر خادمك أي الأحداث تُرسل إلى Meta أصلًا. ويتيح لك استعلام IP لحظة التحويل (لا لحظة النقرة) أن تحجب الحدث كليًّا حين يكون "العميل" عنوان مركز بيانات. فلا تتعلم Meta أبدًا أن تطلب المزيد منه. وينطبق الأمر نفسه على استيرادات التحويل دون اتصال في Google.
قيّم النقرة لحماية الميزانية. ورشّح التحويل لحماية النموذج.
لا تزال لقائمة الاستبعاد مهمة صغيرة
لا شيء من هذا يعني أن تفرغ القائمة. بل يعني أن تتوقف عن اعتبارها الاستراتيجية.
قائمة الاستبعاد هي الأداة الصحيحة لحالة واحدة بالضبط: عدد قليل من المسيئين المتكررين الثابتين عالي الثقة: نطاق مكتب منافس، أو كاشط على مضيف ثابت، أو عنوان IP داخلي يحرق ميزانيتك. هذه حفنة من الإدخالات، لا تتبدل، ولن تقترب أبدًا من 500.
وكل ما عداها (كل ما يتبدل، وكل ما هو مشترك، وكل ما لست متأكدًا منه تمامًا) مكانه الدرجة، حيث يمكن وزنه وتخفيف أثره بمرور الوقت وتأييده بإشارات أخرى وعكسه غدًا حين تتغير الأدلة. الحظر دائم وثنائي. أما الاحتيال فليس كذلك.
أين يعمل هذا في الإنتاج
أبني هذا على جانبَي السلك، ويجدر الإفصاح عن ذلك. GeoIPHub هو طبقة استخبارات IP الموصوفة أعلاه. وClickFortify هو منتجنا لاحتيال النقرات المبني فوقه. يقيّم نقرات الإعلانات الحية على Google وMeta، ويزامن المجموعة الصغيرة من المسيئين عالي الثقة فعلًا مع استبعادات IP في Google Ads، ويرشّح التحويلات المشبوهة قبل أن تصل إلى CAPI لدى Meta والمزايدة الذكية لدى Google.
البنية هي حجة هذا المقال مجسّدة: استخبارات IP تقوم بـالتقييم، وقائمة الاستبعاد لا تُستخدم إلا للشريحة الضيقة من الحالات التي يكون فيها الحظر الدائم هو الاستجابة الصحيحة فعلًا. وإن فضّلت بناء هذا المنطق بنفسك، فالواجهة البرمجية أعلاه هي نفسها التي يستدعيها.
ستة تغييرات قبل حملتك التالية
- سجّل عنوان IP عند كل نقرة إعلان. لا تستطيع تقييم ما لم تسجّله. التقط العنوان عند زيارة صفحة الهبوط، بجانب
gclid/fbclid. - قيّم ولا تحظر. مرّر عنوان IP لكل نقرة عبر استعلام وخزّن الدرجة مع الجلسة، لتقسّم تقاريرك بحسب نطاق المخاطر بأثر رجعي.
- ابدأ بحد مراكز البيانات الأدنى. حركة ASN الاستضافة هي خط الأساس لـ GIVT عند MRC، وأعلى إشارة ثقةً وأقلها إيجابيات كاذبة. إنه أرخص مكسب متاح.
- رشّح التحويلات من جهة الخادم. احجب أحداث التحويل عن CAPI والاستيرادات دون اتصال حين يكون عنوان IP عالي المخاطر. وهذا يحمي نموذج المزايدة، وهو يساوي أكثر من النقرة.
- قيّد المخاطر على عناوين IP المشتركة. تأكد أن نطاقات CGNAT ومشغلي الجوال تُعامَل على أنها مشتركة لا سيئة. هذا هو الحاجز الذي يمنع منع الاحتيال من أن يصير منع إيرادات.
- أبقِ قائمة الاستبعاد قصيرة. احتفظ بها للمسيئين المتكررين الثابتين المؤكَّدين، واضبطها على مستوى الحساب لتشمل Performance Max أيضًا.
لقد أخبرتك النقرة أصلًا من أين جاءت. والسؤال الوحيد هو هل أصغيت بما يكفي لتسمع أكثر من عنوان.
الأسئلة الشائعة
كيف تكتشف احتيال النقرات عبر عنوان IP؟
لا بمطابقته مع قائمة حظر، بل بتقييم الشبكة التي جاءت منها النقرة. الحقول الأعلى إشارةً هي نوع الاتصال (فالنقرة من ASN استضافة أو مركز بيانات ليست متسوقًا)، وأعلام إخفاء الهوية (VPN أو بروكسي عام أو Tor)، وأدلة مصادر التهديد (شبكة بوتات أو ماسح أو مرسل سبام) مع طابع زمني للحداثة، والتحقق من الزواحف (طلب يدّعي أنه Googlebot من عنوان IP خارج نطاقات Google المنشورة يفشل في التحقق؛ ويقارن كودك هذا الادعاء بحقل verified في الواجهة البرمجية). كل واحدة منها مدخل موزون في درجة مخاطر، والدرجة، لا عنوان IP الخام، هي ما تتصرف بناءً عليه.
هل يمكن حجب احتيال النقرات في إعلانات Meta بحسب IP؟
لا. لا يوفر مدير إعلانات Meta أي ميزة لاستبعاد IP على الإطلاق، ولهذا تعمل كل أدوات احتيال النقرات الخارجية لـ Meta بدفع المستخدمين المشبوهين إلى استبعاد في جمهور مخصص بدل حجب عنوان. وفي Meta، الرافعة ليست النقرة بل Conversions API: لأن CAPI من جهة الخادم، فإن خادمك هو من يقرر أي أحداث تحويل تُرسل إلى Meta، فيمكن ببساطة حجب تحويل قادم من عنوان IP لمركز بيانات.
ألا يرشّح Google النقرات غير الصالحة نيابةً عني؟
يرشّح بعضها، وهو صريح في كيفية ذلك. تقول مساعدة Google Ads إن الحركة غير الصالحة المكتشفة قبل نهاية الشهر «تُزال تلقائيًّا من فواتيرك وتقارير حملاتك، فلا حاجة إلى استرداد»، وإن الحركة غير الصالحة المكتشفة بعد محاسبتك تعود في صورة «أرصدة على شكل تسوية فوترة». وهذا يحمي فاتورتك لا استراتيجية حملتك. تغطي التحقيقات الأيام الستين الماضية فقط، وتقول Google إن التحقيق «لن يستطيع تأكيد ما إذا كانت نقرات بعينها قد صُنّفت صالحة أم غير صالحة»، فلا تستطيع تتبع الاحتيال إلى الكلمات المفتاحية أو المواضع أو الجماهير التي تجذبه.
لماذا يُعد حجب عنوان IP احتيالي أمرًا خطرًا؟
لأن عنوانًا عامًّا واحدًا في الإنترنت الحديث يتشاركه اعتياديًّا أشخاص كثيرون لا صلة بينهم. وثّقت RFC 6269 هذه النتيجة منذ سنوات: حين يعاقب خادم عنوانًا مشتركًا، فقد يحجب مستخدم مسيء واحد مستخدمين آخرين لم يرتكبوا خطأ. تضع ترجمة العناوين على مستوى المشغل مئات أو آلاف مشتركي الجوال خلف عنوان IP عام واحد، فقد يمحو استبعاد دائم موجّه إلى محتال واحد شريحة من جمهورك الحقيقي على الجوال من كل حملة بصمت.
هل تُعد حركة مراكز البيانات رسميًّا حركة غير صالحة؟
حركة مراكز البيانات غير الصالحة المعروفة نعم، لكن ليست كل حركة مراكز البيانات. تدرج معايير الكشف عن الحركة غير الصالحة وترشيحها لدى Media Rating Council «حركة مراكز البيانات غير الصالحة المعروفة» أول فئة من الحركة غير الصالحة العامة، وتستثني التصفح المشروع عبر الأجهزة الافتراضية وأعراض التوجيه لدى المستخدمين الحقيقيين، وتشترط MRC ترشيح حركة مراكز البيانات من أكبر ثلاث جهات استضافة (Amazon AWS وGoogle وMicrosoft) حدًّا أدنى. وتذهب إرشادات Certified Against Fraud لدى TAG أبعد، وتشترط على الشركات المعتمدة تطبيق ترشيح تهديدات IP لمراكز البيانات عبر كل المعاملات القابلة للتحقيق.
الفريق الذي يقف وراء واجهة GeoIPHub API
بقلم فريق GeoIPHub، وهم من يبنون واجهة GeoIPHub API لاستخبارات IP وماسحها. تُعَدّ المسودات بمساعدة الذكاء الاصطناعي ويحررها الفريق، وأمثلة API استعلامات حقيقية على واجهة API الحية ما لم تُوصف بأنها توضيحية.
