حد استبعاد IP في إعلانات Google: سقف الـ 500 وCIDR وما لا يستطيع حظره
حد استبعاد IP في إعلانات Google هو 500 لكل حملة و500 لكل حساب. كيف يوسّع CIDR كل خانة، وأي عناوين IP تستحق خانة، من ستة استعلامات مباشرة أجريناها.

لديك سجل نقرات. تتكرر عودة حفنة من العناوين، وصندوق الاستبعاد يتسع لـ 500، وتتساءل ماذا يحدث حين يمتلئ. ابحث عن الحد وستجد أن كل صفحة تقريبًا تجيبك هي لمزوّد لمكافحة الاحتيال بالنقر، وتنتهي كل إجابة تقريبًا بالطريقة نفسها: أداتنا تدوّر لك القائمة.
نرى أن هذا هو السؤال الخطأ. توثيق الواجهة البرمجية لدى Google نفسها يعدّ الحد بـ "كتل IP"، فيمكن أن يغطي الإدخال الواحد نطاقًا كاملًا، ويصبح السؤال المفيد: أي النطاقات تستحق خانة؟ موقفنا بسيط. قائمة الاستبعاد مخصصة للمصادر المزعجة الثابتة، مثل مكتبك أنت أو كتلة استضافة تواصل الظهور، لا للاحتيال. وتقول Google إنها ترشّح النقرات غير الصالحة من جانبها أصلًا، ونقتبس تلك الصفحة قرب النهاية.
نذكر أدناه الحدّين بكلمات Google نفسها، ونبيّن كيف تُدخل نطاقًا في الواجهة وبصيغة CIDR عبر الواجهة البرمجية، ونشغّل ستة عناوين حقيقية عبر واجهتنا البرمجية لنقرر أيها يستحق خانة، ونسرد ما لا يستطيع أي استبعاد إيقافه. وللحجة الأوسع في تقييم كل نقرة بدل حظرها، ابدأ بدليلنا عن الاحتيال بالنقر.

حد استبعاد IP في إعلانات Google: كم عنوانًا يمكنك استبعاده؟
يمكنك استبعاد 500 إدخال IP لكل حملة و500 لكل حساب. يرد الرقمان في صفحتين مختلفتين لدى Google، ولهذا يخطئ كثير من المقالات في الثاني.
فتحنا كل صفحة من صفحات Google المقتبسة في هذه المقالة عند 06:12 بالتوقيت العالمي المنسّق في 14 أكتوبر 2026. سقف الحملة موجود في صفحة مساعدة Google، استبعاد عناوين IP:
"يمكنك استبعاد ما يصل إلى 500 عنوان IP لكل حملة."
لا تذكر صفحة المساعدة رقمًا لمستوى الحساب. سقف الحساب موجود في مرجع واجهة Google Ads البرمجية الخاص بـ CustomerNegativeCriterion، المورد الذي يحمل استبعادات مستوى الحساب. ينص حقله ip_block على: "Immutable. IpBlock. You can exclude up to 500 IP addresses per account." (أي: غير قابل للتغيير. كتلة IP. يمكنك استبعاد ما يصل إلى 500 عنوان IP لكل حساب.) وتفوّت بعض الصفحات المتصدرة ذلك. فمقالة Lunio عن حد الـ 500، التي فتحناها في الوقت نفسه، تقول "ينطبق حد استبعاد الـ 500 عنوان IP لكل حملة لا لكل حساب." ومرجع Google يقول إن لقائمة الحساب سقفها الخاص البالغ 500.
والوحدة أهم من الرقم. يدرج جدول حدود نظام الواجهة البرمجية لدى Google الصف بعنوان "Excluded IP blocks per campaign" (كتل IP المستبعدة لكل حملة)، والقيمة "500"، والخطأ ResourceCountLimitExceededError.CAMPAIGN_LIMIT. يُنشأ معيار واحد لكل عنوان أو لكل كتلة CIDR، ولذلك فإن /24 مُدخلة مرة واحدة هي إدخال واحد في توثيق Google للواجهة البرمجية. لم نختبر هذا في حساب فعلي. ولهذا نسمّيها 500 خانة لا 500 عنوان.
وحين يحمل المستويان إدخالات، تقول صفحة مساعدة Google إن القائمتين تُدمجان:
"إذا كانت لديك استبعادات IP مضبوطة على مستوى الحساب وعلى مستوى الحملة تحت معرّف العميل (CID) نفسه: ستدمج إعلانات Google قائمتي الاستبعاد. وهذا يعني أن جميع عناوين IP المستبعدة على أي من المستويين ستُمنع من رؤية إعلاناتك لتلك الحملة."
مثال Google نفسها: "تخيّل أنك استبعدت عناوين IP 1 و2 و3 على مستوى الحملة (الحملة A). ثم استبعدت عنواني IP 4 و5 على مستوى الحساب. بالنسبة إلى الحملة التي أعددتها (الحملة A)، ستحظر إعلانات Google فعليًا عناوين IP 1 و2 و3 و4 و5." ولا تقول Google شيئًا آخر عن كيفية تفاعل السقفين، ونحن كذلك.
| المستوى | السقف | أين تذكره Google | ما يغطيه |
|---|---|---|---|
| الحملة | 500 | صفحة المساعدة 2456098؛ وCampaignCriterion.ip_block في الواجهة البرمجية | حملة واحدة، وليس كل أنواع الحملات |
| الحساب | 500 | CustomerNegativeCriterion.ip_block في الواجهة البرمجية فقط | جميع حملات الحساب، ومنها Performance Max |
| كلاهما مضبوط | تُدمج القوائم لكل حملة | صفحة المساعدة 2456098 | تحظر كل حملة إدخالاتها الخاصة مضافًا إليها إدخالات الحساب |
مستوى الحساب أم مستوى الحملة: أين تضيف استبعادات IP
أضف الاستبعاد على مستوى الحساب حين ينبغي أن يسري في كل مكان، وعلى مستوى الحملة فقط حين تكون لحملة واحدة مشكلتها الخاصة. مثال Google نفسها على استبعاد جيد هو موظفوك: "تقرر استبعاد عنوان IP لشبكة شركتك." مكان هذا العنوان هو مستوى الحساب.
هذه خطوات Google لمستوى الحساب، من صفحة المساعدة نفسها:
- في حساب إعلانات Google، انقر على أيقونة الإدارة (Admin).
- انقر على إعدادات الحساب (Account settings).
- انتقل إلى قسم "استبعادات IP".
- أدخل عناوين IP التي تريد منعها من رؤية إعلاناتك.
- انقر على حفظ (Save).
وبالنسبة لحملة واحدة:
- في حساب إعلانات Google، انقر على أيقونة الحملات (Campaigns).
- انقر على القائمة المنسدلة الحملات في قائمة القسم.
- انقر على الحملات، ثم الإعدادات (Settings).
- اختر الحملة التي تريد استبعاد عناوين IP منها.
- في صفحة "الإعدادات"، انقر على إعدادات إضافية (Additional settings).
- وسّع قسم "استبعادات IP"، وأدخل العناوين وانقر على حفظ.
يستخدم حذف إدخال المسار نفسه على أي من المستويين. تعليمات Google هي اتباع الخطوات أعلاه، و"أزل أي استبعادات لعناوين IP لا تريد تطبيقها"، ثم النقر على حفظ. وهناك فخ واحد: "لا يمكنك تعديل استبعادات مستوى الحساب أو إزالتها من داخل الحملات الفردية." فإذا بدا إدخال عالقًا في حملة، فابحث عنه في إعدادات الحساب.
والإدخالات الجيدة على مستوى الحساب هي مكتبك ومكتب وكالتك وكتلة استضافة مؤكدة تواصل النقر. ونطاق مكتب منافس ثابت خانة معقولة على مستوى الحملة أيضًا. وإن كان هدفك الحقيقي هو الجغرافيا فإن Google تحيلك إلى مكان آخر: "إذا كنت تحاول منع ظهور إعلاناتك في مواقع جغرافية معينة، فجرّب استبعاد الإعلانات من موقع جغرافي بدل استبعاد عناوين IP."
أي أنواع الحملات لا تستطيع استخدام استبعادات IP على مستوى الحملة؟
لا تقبل حملات الفيديو والفنادق والتطبيقات وPerformance Max وSmart Display استبعادات IP على مستوى الحملة. وتلخّص صفحة مساعدة Google ذلك في ملاحظة واحدة:
"ملاحظة: استبعادات IP غير متاحة لحملات الفيديو وحملات الفنادق وحملات التطبيقات وحملات Performance Max وحملات Smart Display."
ومستوى الحساب يمتد أبعد. تقول Google إن بإمكانك استخدامه "لمنع عناوين IP محددة من رؤية إعلاناتك عبر جميع الحملات في حسابك بما فيها Performance Max وDemand Gen والبحث والتسوق والعرض وDiscover وYouTube." أي أن Performance Max تقبل استبعادات IP على مستوى الحساب فقط، وهذه القائمة هي نفسها الـ 500 إدخال التي تشترك فيها كل الحملات الأخرى.
| نوع الحملة | الاستبعادات على مستوى الحملة | الاستبعادات على مستوى الحساب |
|---|---|---|
| البحث، التسوق، العرض | متاحة | مذكورة لدى Google |
| Performance Max | غير متاحة | مذكورة لدى Google |
| الفيديو | غير متاحة | تذكر Google YouTube |
| الفنادق، التطبيقات، Smart Display | غير متاحة | غير مذكورة في الصفحة |
| Demand Gen | ليست في قائمة Google لغير المدعومة | مذكورة لدى Google |
تختلف صفحات المزوّدين حول هذه القائمة، جزئيًا لأن صفحات Google نفسها تختلف. فصفحة مساعدة Search Ads 360 الأقدم تذكر حملات الفيديو والتطبيقات وSmart Display وDiscovery. ونحن نستخدم الخمس الواردة في صفحة إعلانات Google الحالية فقط.
كيف تستبعد نطاق IP: النجمة وCIDR وIPv6
في الواجهة، الصيغة الموثقة للنطاق هي علامة نجمة على الخانة الأخيرة. وعبر الواجهة البرمجية، تُعد أي كتلة CIDR من IPv4 أو IPv6 إدخالًا واحدًا.
تقول صفحة مساعدة Google: "يمكنك إدخال عناوين IP محددة، أو استخدام علامة نجمة (*) لتحل محل الأرقام الثلاثة الأخيرة إذا أردت استبعاد كتلة من العناوين." والأرقام الثلاثة الأخيرة تعني الخانة الأخيرة: 198.51.100.* تغطي 256 عنوانًا، أي ما تغطيه /24. توثّق Google نجمة واحدة في ذلك الموضع ولا شيء غيره. وتظهر صيغ بنجمتين أو بنجمة في المقدمة في بعض الصفحات المتصدرة، لكن Google لا توثّق مثل هذه الصيغة، فلا تعتمد عليها.
والواجهة البرمجية أكثر مرونة. يقول مرجع IpBlockInfo لدى Google: "نحن ندعم استبعاد عناوين IP الفردية أو كتل CIDR. أنشئ معيار IpBlockInfo واحدًا لكل عنوان IP فردي أو كتلة CIDR تريد استبعادها." وأمثلته هي 192.168.0.0/24 وعنوان مفرد بصيغة 192.168.0.1/32 لـ IPv4، و2001:db8::/48 و2001:db8:a0b:12f0::1/128 لـ IPv6.
توثّق الواجهة العناوين المفردة والنجمة. أما كتل CIDR وIPv6 فموثقة للواجهة البرمجية. لم نختبر ما تفعله الواجهة مع إدخال CIDR أو IPv6، فلن نقول لك إنه يعمل.
وحساب الخانات هو الموضع الذي يؤتي فيه CIDR ثماره. خذ نطاقًا من 194.83.41.0 إلى 194.83.47.255، وهو المثال الذي تستخدمه وكالة بريطانية على WebSuccess Insights. شغّلناه عبر ipaddress.summarize_address_range في Python:
| ما تكتبه | أين | العناوين المغطاة | الإدخالات المستخدمة |
|---|---|---|---|
من 194.83.41.* إلى 194.83.47.*، صف لكل /24 | الواجهة | 1,792 | 7 |
194.83.41.0/24, 194.83.42.0/23, 194.83.44.0/22 | الواجهة البرمجية | 1,792 | 3 |
2001:db8::/48 | الواجهة البرمجية | 65,536 شبكة فرعية /64 | 1 |
مثال Google على IPv6 هو /48، وتحوي 65,536 شبكة فرعية /64. شبكة جهاز واحد هي عادةً /64 واحدة، بينما يمنح مزوّدو الخدمة المنزل عادةً /56 أو /48، ولذلك فإن إدخال /48 قد يغطي موقع عميل كاملًا. نشرح ما تغطيه /48 مقارنة بـ /64 في مقالتنا عن IPv6.
وتضيف Google سطرًا آخر: "قد تظهر عناوين IP بإصدارات مختلفة، فتأكد من استخدام جميع إصدارات عنوان IP الذي تريد استبعاده." اقرأ ذلك على أن المكتب أو الخادم الذي له عنوان IPv4 وعنوان IPv6 معًا يحتاج إلى الإدخالين.
إضافة استبعادات IP بالجملة عبر واجهة Google Ads البرمجية
عبر الواجهة البرمجية، استبعاد الحملة هو CampaignCriterion سالب مع ip_block، واستبعاد الحساب هو CustomerNegativeCriterion مع ip_block. يدرج جدول المعايير لدى Google كتلة IP قابلة للاستبعاد فقط، على مستويي الحملة والعميل.
قبل أن تدفع أي شيء، قلّص القائمة. يحوّل هذا السكربت العناوين المرشحة والكتل إلى أقل عدد من إدخالات CIDR يغطيها، الأكثر نشاطًا أولًا، بسقف 500. وهو الشيفرة نفسها التي شغّلناها في 14 أكتوبر، على Python 3.9.6، بالمكتبة القياسية فقط:
"""Turn candidate IPs and CIDR blocks into a Google Ads exclusion list of at most 500 entries.
Input: one entry per line, an IPv4/IPv6 address or a CIDR block (for example the
registered block you looked up in RDAP), optionally followed by a click count.
Output: the fewest CIDR entries that cover every input, busiest first, capped at 500.
"""
import ipaddress
import sys
GOOGLE_ADS_LIMIT = 500 # per campaign, and per account, in Google's API reference
def build_exclusions(lines, limit=GOOGLE_ADS_LIMIT):
clicks = {}
for line in lines:
line = line.split("#", 1)[0].strip()
if not line:
continue
parts = line.split()
net = ipaddress.ip_network(parts[0], strict=False) # 1.2.3.4 -> 1.2.3.4/32
clicks[net] = clicks.get(net, 0) + (int(parts[1]) if len(parts) > 1 else 1)
merged = []
for version in (4, 6): # collapse_addresses refuses to mix IPv4 and IPv6
nets = [n for n in clicks if n.version == version]
merged += ipaddress.collapse_addresses(nets)
# Credit each merged entry with the clicks of everything it now covers.
totals = {m: sum(c for n, c in clicks.items() if n.version == m.version and n.subnet_of(m))
for m in merged}
ranked = sorted(merged, key=lambda m: totals[m], reverse=True)
return ranked[:limit], ranked[limit:], totals
if __name__ == "__main__":
keep, dropped, totals = build_exclusions(sys.stdin)
for net in keep:
print(f"{net}\tclicks={totals[net]}")
print(f"# {len(keep)} entries kept, {len(dropped)} over the limit", file=sys.stderr)
ليست لدينا سجلات نقرات حقيقية لننشرها، فغذّيناه بعيّنة اصطناعية مبنية من نطاقات عناوين التوثيق فقط. هذه ليست نقرات حقيقية ولم يُستعلم عنها قط:
# SYNTHETIC sample: documentation ranges (RFC 5737, RFC 3849), not real clicks
198.51.100.7 3
198.51.100.0/25 12 # a registered block you looked up
198.51.100.128/25 9 # its neighbour: merges with the line above into one /24
203.0.113.10 2
203.0.113.11 2 # adjacent to .10: the two merge into one /31
192.0.2.200 1
2001:db8::42 4
2001:db8::/48 6 # covers the address above
طبع تشغيل python3 -I build_exclusions.py < synthetic_clicks.txt:
198.51.100.0/24 clicks=24
2001:db8::/48 clicks=10
203.0.113.10/31 clicks=4
192.0.2.200/32 clicks=1
# 4 entries kept, 0 over the limit
تحولت ثمانية أسطر إلى أربعة إدخالات. كما غذّيناه بـ 600 عنوان /32 اصطناعيًا غير متجاور من 198.18.0.0/15، فأبقى على الـ 500 الأكثر نشاطًا وأبلغ عن 100 فوق الحد.
ثلاثة أشياء لا يفعلها السكربت عمدًا:
- لا يوسّع عنوانًا أبدًا. يدمج
collapse_addressesالكتل المتلامسة أو المتداخلة فقط. وتحويل عنوان واحد إلى /24 الخاصة به قرار تتخذه بعد استعلام RDAP، لا شيء ينبغي أن تخمّنه الشيفرة. - لا يهتم بصيغة الواجهة. كتلة /31 أو /48 مقبولة للواجهة البرمجية. أما في الواجهة فستكتب الـ /31 كعنوانين، ولا توثّق Google صيغة نطاق IPv6 فيها.
- لا يرشّح العناوين المشتركة. شغّله فقط بعد أن تكون القاعدة الواردة في الأقسام التالية قد أزالت عناوين الترحيل وترجمة الشبكة لدى المشغّل.
كما أنه لا يستدعي واجهتنا البرمجية أبدًا. وإذا أضفت خطوة استعلام، فهي طلب GET واحد لكل عنوان مع وضع IP في المسار ومفتاحك في ترويسة x-api-key، كما يبيّن مرجع الواجهة البرمجية. لا يوجد استدعاء دفعي. ومن urllib في Python، اضبط User-Agent صريحًا، لأن واجهتنا البرمجية تعيد حاليًا 403 لـ User-Agent الافتراضي لـ urllib.
يبدو دفع إدخال هكذا. كتبناه من مرجع IpBlockInfo وCampaignCriterion لدى Google، الذي أظهر v25 في 14 أكتوبر، باستخدام تسمية مكتبة عميل Python. لم نشغّله على حساب فعلي.
# Written from Google's IpBlockInfo and CampaignCriterion reference (v25); not run against a live account.
operation = client.get_type("CampaignCriterionOperation")
criterion = operation.create
criterion.campaign = client.get_service("CampaignService").campaign_path(customer_id, campaign_id)
criterion.negative = True # IP blocks can only be excluded
criterion.ip_block.ip_address = "198.51.100.0/24" # one CIDR block = one criterion
client.get_service("CampaignCriterionService").mutate_campaign_criteria(
customer_id=customer_id, operations=[operation]
)
# Account level: CustomerNegativeCriterionOperation, criterion.ip_block.ip_address,
# CustomerNegativeCriterionService.mutate_customer_negative_criteria.
# At 501 campaign entries the API returns ResourceCountLimitExceededError.CAMPAIGN_LIMIT.
توثّق Google الخطأ لسقف الحملة فقط. لم نجد رمز خطأ موثقًا لسقف الحساب، فلا نسمّي واحدًا. وفي ملاحظات الإصدار 2.11 من Google Ads Editor عنوان "Account-level placement and IP exclusions"، لكننا لم نختبر Editor، فلا نقدّم خطوات له.
لماذا لا تتسع 500 إدخال لشبكة استضافة
لا تتسع خمسمئة إدخال لمزوّد سحابي كبير، لأن Google لا توثّق طريقة لاستبعاد شبكة عبر ASN الخاص بها، والمزوّد الكبير يعلن آلاف البادئات. أحصينا عند 06:14 بالتوقيت العالمي المنسّق في 14 أكتوبر:
| الشبكة | الإدخالات التي ستحتاجها | المصدر |
|---|---|---|
| AS16509 (Amazon) | 27,319 بادئة معلنة (21,267 IPv4، 6,052 IPv6) | RIPEstat announced-prefixes، النافذة من 2026-09-30 إلى 2026-10-14 |
| نطاقات AWS المنشورة | 11,336 بادئة فريدة (7,863 IPv4، 3,473 IPv6) | ip-ranges.amazonaws.com، createDate 2026-10-14-03-37-06 |
| AS63949 (Akamai Connected Cloud، Linode سابقًا) | 452 (354 IPv4، 98 IPv6) | RIPEstat، النافذة نفسها |
| AS39351 (31173 Services، شبكة Mullvad) | 74 (53 IPv4، 21 IPv6) | RIPEstat، النافذة نفسها |
| AS60729 (TORSERVERS-NET) | 6 (3 IPv4، 3 IPv6) | RIPEstat، النافذة نفسها |
تشمل أعداد RIPEstat البادئات الأكثر تحديدًا المتداخلة وكل ما شوهد خلال نافذة الأسبوعين، فاعتبرها حدًا أعلى لعدد الإدخالات لا مساحة عناوين فريدة. وهي تتغير يوميًا. ومع ذلك تحتاج Amazon وحدها إلى إدخالات أكثر مما تحمله قائمتاك معًا، بأضعاف كثيرة.
فسؤال الاستضافة ليس "هل أستطيع استبعاد السحابة؟" لا تستطيع. بل هو "أي كتل الاستضافة تواصل الظهور في سجلي أنا؟" نشرح ما الذي يجعل العنوان عنوان مركز بيانات على حدة. تعلّم واجهتنا البرمجية الاستضافة من 853 ASN استضافة منتقاة إضافة إلى نطاقات رسمية من 10 مزوّدي سحابة، ويمكنك اختبار عنوان واحد في فحص IP لمركز البيانات المجاني.
وتنبيه واحد قبل أن تكتب قاعدة على هذه العلامة. حركة الاستضافة هي أول فئة حركة غير صالحة عامة في معيار MRC، لكن المعيار نفسه يستثني منها توجيه VPN المشروع والتصفح عبر الأجهزة الافتراضية، وهو ما نفصّله في GIVT مقابل SIVT: فئات الحركة غير الصالحة لدى Google. الاستضافة وحدها تسجّل درجة منخفضة بالتصميم: العنوان 45.33.32.156 أدناه يعيد detection.is_hosting: true ودرجة 10، allow. وبالنسبة للنقرات المدفوعة، فهل ينبغي لحركة الاستضافة أن ترى إعلاناتك قاعدة تكتبها أنت لا الدرجة.
أي العناوين تستحق إحدى خاناتك الـ 500
ينبغي أن تذهب الخانة إلى نطاق ثابت لا يشاركك فيه أحد وقد رأيته في سجل نقراتك أنت. ولنبيّن كيف يبدو ذلك، استعلمنا عن ستة عناوين عامة عند 06:12 بالتوقيت العالمي المنسّق في 14 أكتوبر بطلب GET https://api.geoiphub.com/v1/lookup/{ip} مجهول. أعادت الستة كلها HTTP 200. لم ينقر أي منها إعلان أحد. وهي تمثّل أنواع العناوين التي يحتويها سجل النقرات.
ليس في استجابتنا حقل للبادئة، فأخذنا كل كتلة مسجلة من RDAP عند 06:14 بالتوقيت العالمي المنسّق، عبر rdap.org الذي أعاد التوجيه إلى ARIN وRIPE.
| عنوان IP وما هو | asn / org | user_type | is_hosting | is_vpn | is_relay | is_cgnat | الدرجة، الإجراء | detection_methods | كتلة RDAP | خانة؟ |
|---|---|---|---|---|---|---|---|---|---|---|
| 45.33.32.156، scanme.nmap.org | 63949 AKAMAI-LINODE-AP | hosting | true | false | false | false | 10، allow | datacenter_ip | 45.33.0.0/17 (LINODE) | فقط إذا تكررت هذه الكتلة في سجل نقراتك، كقاعدة خاصة بحركتك الإعلانية |
| 185.220.101.1، مخرج Tor، هامبورغ | 60729 TORSERVERS-NET | hosting | true | false | false | false | 100، block | tor_exit, datacenter_blocklisted, rdns_tor, known_spammer | 185.220.101.0/27 (ARTIKEL10) | نعم: كتلة مشغّل ثابتة بأربعة أسباب مستقلة |
| 45.83.220.7، شبكة Mullvad، مالمو | 39351 31173 Services AB | hosting | true | true, "Mullvad (31173 Services)", 85 | false | false | 46، review | known_vpn_server, datacenter_ip | 45.83.220.0/24 | لا افتراضيًا: قيّمها وقت النقر |
| 185.213.155.73، Mullvad de-fra-wg-001 | 39351 31173 Services AB | hosting | true | true, "Mullvad", 95 | false | false | 100، block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | 185.213.155.0/24 | ممكن، لكن المشغّل نفسه سجّل 46 في الصف أعلاه |
| 104.28.46.99، iCloud Private Relay | 13335 Cloudflare | consumer_privacy_network | false | false | true | false | 9، allow | relay_ip | 104.16.0.0/12 (CLOUDFLARENET) | أبدًا |
| 172.224.226.1، iCloud Private Relay | 36183 AKAMAI-AS | consumer_privacy_network | true | false | true | false | 24، allow | datacenter_ip, no_ptr_datacenter, relay_ip | 172.224.0.0/12 (AKAMAI) | أبدًا. ترحيل مع is_hosting: true |
يحتاج صفّان إلى توضيح. اسم VPN في 45.83.220.7 يأتي من جدولنا لشبكات استضافة VPN بثقة 85، لا من قائمة خوادم Mullvad نفسها التي لم تتضمنه حين تحققنا في 13 أكتوبر. أما 104.28.46.99 فيقع داخل /12 المسجلة لـ Cloudflare لكن خارج النطاقات التي تنشرها Cloudflare لشبكتها الخاصة، ولذلك فإن "استبعاد كتلة Cloudflare" سيقطع مستخدمي ترحيل Apple لا خوادم Cloudflare.
عنوان واحد من البداية إلى النهاية
تتبّع 185.220.101.1 من النقرة إلى الإدخال. مع تفعيل الوسم التلقائي، تضيف Google معرّف GCLID إلى عنوان صفحتك المقصودة، "www.example.com/?gclid=123xyz" في مثال Google. سجّل عنوان IP للعميل بجانب gclid هذا على صفحتك المقصودة، لأن هذا الاقتران هو ما يربط عنوانًا بنقرة مدفوعة.
ثم استعلم عن العنوان. هذه نسخة مختصرة من استجابتنا عند 06:12 بالتوقيت العالمي المنسّق، مع إبقاء التداخل وبلا تعديل في القيم:
{
"ip": "185.220.101.1",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"user_type": "hosting"
},
"whois": {
"netname": "ARTIKEL10",
"status": "ASSIGNED PA"
},
"detection": {
"is_vpn": false,
"is_tor": true,
"is_hosting": true,
"is_relay": false,
"is_anonymous": true
},
"threat": {
"is_spammer": true,
"is_cgnat": false
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"]
}
}
detection.is_tor صحيحة، والدرجة 100، وانطلقت أربع طرق منفصلة. تسمّي الاستجابة الشبكة المسجلة لكنها لا تذكر حجمها، فسألنا RDAP: من 185.220.101.0 إلى 185.220.101.31، أي /27. تصبح هذه الكتلة إدخالًا واحدًا، 185.220.101.0/27، عبر الواجهة البرمجية. وهي تكلّف خانة واحدة من 500 وتغطي 32 عنوانًا يديرها مشغّل Tor واحد. وهذه صفقة جيدة.
القاعدة التي سنتبعها
- أنفق الخانات فقط على نطاقات ثابتة غير مشتركة رأيتها في سجل نقراتك أنت: كتل الاستضافة مع
is_relay: false، وكتل مشغّلي Tor. - لا تنفق خانة أبدًا على عنوان تكون فيه
detection.is_relayأوthreat.is_cgnatصحيحة، مهما كانت الدرجة. - قيّم كل ما عدا ذلك لكل نقرة عند الوصول، بما في ذلك VPN، لأن مشغّل VPN واحدًا سجّل 46 و100 على عنوانين له.
- خذ الكتلة من RDAP أو من ملف نطاقات المزوّد نفسه، لا من استجابتنا.
نطاقات الدرجة وراء تلك الإجراءات هي: allow حتى 25، وreview حتى 50، وstep_up حتى 75، وblock فوق 75. نشرح كيف تعمل نطاقات درجة الاحتيال في مقالة منفصلة، ويمكنك فحص عنوان في فاحص درجة احتيال IP المجاني قبل أن تنفق عليه خانة.
لا تنفق خانة على عنوان مشترك: ترجمة الشبكة لدى المشغّل وPrivate Relay
تحمل عناوين ترجمة الشبكة لدى المشغّل وiCloud Private Relay أشخاصًا حقيقيين كثيرين في وقت واحد، فاستبعاد واحد منها يخفي إعلاناتك عنهم جميعًا. لا درجة ولا عدد نقرات يغيّر ذلك.
ابدأ بـ Private Relay. يشترك مستخدمو Apple الكثيرون في كل عنوان خروج، وتحدّ درجاتنا الترحيل بسقف 60، فلا يمكن أن يبلغ عنوان Private Relay مستوى block. والفخ في الجدول أعلاه. فالعنوان 172.224.226.1 موجود في قائمة ترحيل Apple ومع ذلك يعيد detection.is_hosting: true، لأنه يعمل في مراكز بيانات Akamai. وقاعدة تقول "استبعد كل كتلة استضافة" ستستبعد مستخدمي Apple. افحص is_relay قبل أي شيء آخر، كما نشرح في السماح لمستخدمي الترحيل وVPN بالمرور.
وترجمة الشبكة لدى المشغّل هي نسخة الجوال من المشكلة نفسها. ليس لدينا عنوان مشغّل آمن لنعرضه عليك، لأننا لا نستعلم عن عناوين المستهلكين ولا ننشرها أبدًا، فهذا الجزء نثري فقط. يحدّد threat.is_cgnat العناوين التي يشترك فيها كثير من مشتركي المشغّل، وفي درجاتنا سقف لترجمة شبكة المشغّل هو 50، فيبقى عنوان مشغّل مشترك لا شيء آخر ضده دون مستوى step_up. أما النطاق الوارد في RFC 6598، أي 100.64.0.0/10، فهو الجانب الداخلي للمشغّل ولا يظهر أبدًا كعنوان IP لنقرة. سترى بدلًا منه العنوان العام للمشغّل.
وقد دُوِّنت كلفة الخطأ في هذا قبل سنوات. يحذّر RFC 6269 من أنه مع العناوين المشتركة "قد يحجب مستخدم واحد فشلت محاولات تسجيل دخوله مستخدمين آخرين لم تكن لهم محاولات سابقة لكنهم سيفشلون الآن في محاولتهم الأولى." استبدل محاولات تسجيل الدخول بنقرات الإعلانات وستحصل على مشكلة الاستبعاد. ويتناول منشورنا المحوري لماذا يصيب حظر عنوان مشترك العملاء الحقيقيين بمزيد من التفصيل.
ما لا يستطيع استبعاد IP حظره
لا يستطيع استبعاد IP إيقاف كل نقرة من عنوان، ولا تسمية شبكة، ولا يمس النقرات التي دفعت ثمنها أصلًا. تقول Google الجزء الأول بنفسها في لماذا أحصل على نقرات من عناوين IP مستبعدة؟:
"عند استخدام أداة استبعاد بروتوكول الإنترنت (IP)، قد تظل النقرات من عناوين IP المستبعدة تظهر في سجلات الويب لديك."
وتعطي ثلاثة أسباب:
- التبديل. "بعض مزوّدي خدمة الإنترنت يبدّلون عناوين IP للمستخدمين باستمرار." يظهر الإعلان على عنوان وتصل النقرة من عنوان آخر.
- البيانات المفقودة. "بعض مواقع شبكة Google لا توفّر معلومات IP، فقد يرى المستخدمون الذين لهم عناوين IP المستبعدة إعلانك على هذه المواقع. لا يمكننا ضمان عدم حدوث نقرات من عنوان IP معين."
- النقرات العضوية. "سيكون عنوان URL للمُحيل لنقرة على نتائج بحث Google العضوية وعلى إعلان هو نفسه. ولأن استبعاد IP ينطبق على الإعلانات فقط، فمن الممكن أن تكون النقرة التي تراها قد نشأت أصلًا من نتائج البحث لدينا."
ثم الجملة التي تشكّل موقفنا كله:
"ترشّح Google النقرات غير الصالحة من حسابك تلقائيًا واستباقيًا. لا يتعين عليك فعل أي شيء لتلقّي هذه الحماية. ومع ذلك، يمكنك استخدام أداة استبعاد عناوين IP للحصول على تحكم إضافي في مواضع ظهور إعلاناتك."
تحكم في المواضع، بكلمات Google، لا دفاع ضد الاحتيال. كما لا توثّق Google أي إعداد لـ ASN أو مزوّد خدمة الإنترنت أو VPN أو البروكسي أو مركز البيانات للاستبعادات، ولا يعيد لك الاستبعاد مالًا عن نقرات حوسبت أصلًا.
ولجانبنا حدوده أيضًا. تصنّف واجهتنا البرمجية عنوان IP تعطيها إياه. ولا تستطيع رؤية نقرات إعلانات Google أو معرّفات GCLID لديك، فهي تأتي فقط من سجل صفحتك المقصودة. ولا تعيد بادئة، فالكتلة تأتي دائمًا من RDAP. والاستعلامات تتغير: فحتى 13 أكتوبر استخدم دليلنا للاحتيال بالنقر العنوان 45.83.220.7 مثالًا على استضافة عادية، واليوم تسمّيه الواجهة البرمجية شبكة Mullvad. أرِّخ كل نتيجة تتصرف بناءً عليها.
ماذا تفعل مع كل نوع من العناوين:
| نوع العنوان | ماذا تفعل | لماذا |
|---|---|---|
| مكتبك، نطاق مكتب منافس ثابت، كتلة استضافة أو Tor ثابتة تُرى مرارًا في سجلك | استبعد، إدخال CIDR واحد لكل كتلة، على مستوى الحساب | ثابت، غير مشترك، إدخالات قليلة |
ترجمة شبكة المشغّل (threat.is_cgnat: true)، iCloud Private Relay (is_relay: true) | لا تستبعد أبدًا | مستخدمون حقيقيون كثيرون لكل عنوان |
| مخارج VPN، عناوين استضافة لمرة واحدة، أي شيء يتبدّل | قيّم عند الوصول باستخدام scoring.recommended_action | المشغّل نفسه سجّل 46 و100 |
فحصان على قائمة الاستبعاد الخاصة بك هذا الأسبوع:
- قلّصها. صدّر إدخالاتك الحالية ومرّرها عبر السكربت أعلاه. الإدخالات التي تندمج تحرّر خانات، فاحسب ما تبقى قبل أن تضيف أي جديد.
- أزل العناوين المشتركة. استعلم عن عنوان واحد من كل إدخال في فاحص درجة الاحتيال. احذف أي إدخال تعود فيه
is_relayأوis_cgnatصحيحة.
الأسئلة الشائعة
كم عنوان IP يمكنك استبعاده في إعلانات Google؟
حتى 500 لكل حملة، ويضع مرجع الواجهة البرمجية لدى Google السقف نفسه، 500، لاستبعادات مستوى الحساب. قائمة الحساب ليست مجموعة أكبر.
هل يمكنك استخدام CIDR أو IPv6 في استبعادات IP في إعلانات Google؟
عبر واجهة Google Ads البرمجية نعم: كل كتلة CIDR من IPv4 أو IPv6 تُعد إدخالًا واحدًا. أما صفحة مساعدة Google فتوثّق العناوين المفردة وعلامة نجمة في الخانة الأخيرة فقط للواجهة.
هل يمكنك استبعاد عناوين IP من Performance Max؟
على مستوى الحساب فقط. استبعادات IP على مستوى الحملة غير متاحة لحملات الفيديو والفنادق والتطبيقات وPerformance Max وSmart Display.
لماذا ما زالت النقرات تأتي من عناوين IP مستبعدة؟
تذكر Google ثلاثة أسباب: بعض مزوّدي خدمة الإنترنت يبدّلون عناوين المستخدمين، وبعض مواقع شبكة Google لا توفّر معلومات IP، والنقرات العضوية والمدفوعة تشترك في المُحيل نفسه.
هل يؤدي استبعاد عنوان IP إلى استرداد النقرات التي دفعت ثمنها؟
لا. الاستبعاد يوقف ظهور إعلاناتك لذلك العنوان من تلك اللحظة فصاعدًا. أما أرصدة النقرات غير الصالحة فعملية منفصلة.
هل ينبغي استبعاد IP لمشغّل جوال أو iCloud Private Relay؟
لا. يشترك في كل واحد من هذه العناوين أشخاص حقيقيون كثيرون، فقيّم النقرة بدل إنفاق خانة عليه.
الفريق الذي يقف وراء واجهة GeoIPHub API
بقلم فريق GeoIPHub، وهم من يبنون واجهة GeoIPHub API لاستخبارات IP وماسحها. تُعَدّ المسودات بمساعدة الذكاء الاصطناعي ويحررها الفريق، وأمثلة API استعلامات حقيقية على واجهة API الحية ما لم تُوصف بأنها توضيحية.


