حظر إعلانات IMA SDK، مُفسَّر

ما هي واجهة برمجة تطبيقات (SDK) الإعلانات المدمجة (IMA) بالضبط

يُعد حزمة تطوير البرمجيات لإعلانات الوسائط التفاعلية (IMA) مكتبة من جانب العميل تُستخدم من قِبل جوجل لإدارة الإعلانات الفيديو. فالموقع الإلكتروني الذي يرغب في تحقيق العائد من الفيديو لا يبني عادةً مشغّل إعلاناته الخاص: بل يقوم بتحميل imasdk.googleapis.com/js/sdkloader/ima3.js (أو النسخة الديناميكية ima3_dai.js)، ثم يُهيّئ AdDisplayContainer، ويُمرّر عنوان URL الخاص بوسوم الإعلان إلى حزمة تطوير البرمجيات (SDK). وتقوم الحزمة بعد ذلك باسترجاع استجابة VAST، وعرض الإعلان داخل المشغّل، وتتبع عدد مرات ظهور الإعلان (Impressions) ونِسب التقدّم (Quartiles)، وأخيرًا تُعيد التحكم في المحتوى الأصلي للمُنشئ.

بما أنه سكريبت واحد مشترك يُقدَّم من مجال واحد، فإن واجهة برمجة تطبيقات IMA تُعد النقطة الحرجة الأكثر استغلالًا في الإعلانات الفيديو على الويب: أوقفها مرة واحدة فقط، وستتوقف جميع المشغلات المبنية عليها عن عرض الإعلانات.

دورة حياة طلب الإعلان

عندما يضغط المشاهد على زر التشغيل، يعمل المشغل عادةً هذا التسلسل:

1. يُحمّل الصفحة ملف ima3.js من خوادم Google.
2. يُنشئ المشغّل محمل إعلانات ويطلب إعلانات باستخدام علامة إعلان تشير إلى خادم إعلانات.
3. يُجلب الـ SDK الإعلان (عادةً مستند VAST/VMAP عبر DoubleClick)، ويُحلّله، ويُعرض محتوى الإعلان في حاوية تُوضع فوق الفيديو.
4. تُفعّل بكسلات التتبع؛ وينتظر المشغّل.
5. عند انتهاء الإعلان (أو حدوث خطأ)، يُطلق الـ SDK الحدث CONTENT_RESUME_REQUESTED، ويُستأنف تشغيل الفيديو الفعلي.

هذا الحدث الأخير هو المفتاح: يُكتَب اللاعب لينتظره. من يتحكم في SDK يتحكم في توقيت استئناف المحتوى.

لماذا يؤدي حظر واجهة برمجة التطبيقات (SDK) ببساطة إلى تعطيل مشغّلات الفيديو

النهج الخشن هو حظر imasdk.googleapis.com على مستوى الشبكة والاعتبار أن الأمر انتهى عندئذٍ. المشكلة: تفسّر العديد من مشغّلات الفيديو فشل أو غياب SDK كخطأ فادح، وترفض بدء تشغيل الفيديو تمامًا، مع عرض مؤشر تحميل أو جدار يُظهر «تم اكتشاف مانع إعلانات» بدلًا من المحتوى.

لهذا السبب تُعدّ المُحجبات الكلاسيكية على مستوى الشبكة ضعيفة أمام إعلانات الفيديو: فهي تستطيع منع طلب الإعلان، لكنها لا تستطيع الإجابة على سؤال المشغّل: "هل يمكنني الاستئناف الآن؟". فقط شيء يُمثّل SDK يمكنه فعل ذلك.

التعادل عبر الاستبدال: نهج "الكود الوهمي" (stub)

يسلك AdOff مسارًا مختلفًا: بدلًا من حظر SDK، فإنه يستبدله. حيث يتم استبداله بنسخة مُصغَّرة (stub) تحاكي واجهة API العامة لـ IMA SDK، بحيث يستمر المشغّل في «رؤية» SDK يعمل — SDK يتصرف وكأن كل فاصل إعلاني فارغ تمامًا.

عندما يستدعي المشغل adsManager.start()، يُطلق الوحدة الوهمية فورًا الحدث CONTENT_RESUME_REQUESTED. ويُستأنف محتوى الفيديو فورًا من قِبل المشغل. ولا يتم جلب أي إعلان، ولا يتم عرض أي إعلان، ولا يدخل المشغل أبدًا في حالة خطأ، لأنه لا يلاحظ أي نقص أصلًا.

قناة توصيل واحدة للكود الوهمي نفسه

يُرسِل AdOff نفس الـ stub عبر قناتين، لأن المواقع المختلفة تحمّل SDK بطريقة مختلفة:

• حقن داخل الصفحة. على المواقع التي لا تُستثني، يُعرّف سكريبت عالم الصفحة (main-world) window.google.ima قبل تهيئة المشغّل، مما يجعل حزمة SDK أو SDK الذي يُحمّل خارجيًا تُستبدَل بالملف الوصفي (stub).
• إعادة توجيه الشبكة. بالنسبة لمجموعة من 42 نطاقًا لشركات بث أوروبية، تُعيد قواعد declarativeNetRequest توجيه الطلب إلى ملفَي ima3.js وima3_dai.js إلى الملف الوصفي (stub) المُضمّن داخل الإضافة. وتُحمّل الصفحة ما تظنه مكتبة جوجل، بينما تحصل في الحقيقة على مكتبة AdOff.

كلا القناتين تنتهيان في النهاية بالنتيجة نفسها: يحصل اللاعب على SDK متجاوب، ويحصل المشاهد على المحتوى.

المجالات التي يغطيها هذا النهج والمجالات التي لا يغطيها

يُلغِي الـ stub تأثير الإعلانات القائمة على IMA من جانب العميل. ولا يؤثر على إدراج الإعلانات من جانب الخادم (SSAI)، حيث تُدمج الإعلانات في تدفق الفيديو نفسه قبل التوصيل — ولا توجد مكالمة SDK يمكن اعتراضها. كما تم استبعاد خدمات الاشتراك المدفوعة المتّبعة لخطوط إعلانية خاصة بها عمداً، لضمان استمرار عمل مشغّليها.

يحصل أيضًا المنصة الرئيسية للفيديو على خط أنابيب مخصص مُضاف فوقها: يتم إزالة جدولة الإعلانات من استجابة المشغل قبل أن تقرأها الصفحة، وأي شيء يُفلت من ذلك يتم تخطيه بسرعة.

لماذا يهمّ هذا الأمر مستقبل أدوات حظر الإعلانات

تُعيد منصات الإعلانات توزيع الوزن تدريجيًّا نحو مكتبات SDK من جانب العميل، بالضبط لأن مانعي الإعلانات البسيطين يواجهون صعوبة في التعامل معها. إن النهج الذي يُجبر المُشغِّل على الاستجابة بدلًا من حظره بالكامل هو نهج قوي: فهو لا يعتمد على إدراج كل رابط إعلاني على حدة، بل يعتمد فقط على العقد المُتفق عليه من قبل مكتبة SDK نفسه، والمتمثل في ضرورة استئناف المحتوى.

AdOff هو امتداد مجاني وبدون حساب، متوافق مع معيار Manifest V3، يعمل على متصفحات Chrome وFirefox وSafari وEdge وOpera، ويتضمن طبقة تحييد الفيديو لجميع المستخدمين.

الأسئلة الشائعة

هل حظر SDK الخاص بـ IMA يعادل استبداله؟

لا. حظره على مستوى الشبكة غالبًا ما يمنع تشغيل الفيديو، لأن المشغلات تنتظر من حزمة التطوير (SDK) أن تُشير إلى إمكانية استئناف المحتوى. استبداله بنسخة وهمية (stub) يحافظ على عمل المشغل بشكل كامل مع ضمان عدم طلب أي إعلانات أبدًا.

ماذا يحدث عندما يتلقى الـ stub طلب إعلان؟

النسخة الوهمية (stub) تعرض واجهة برمجة التطبيقات (API) نفسها التي يتوقعها المشغلات. وعند طلب بدء الإعلانات، تُطلق فورًا حدث استئناف المحتوى (content-resume)، لذا يستمر التشغيل دون جلب أي إعلانات أو عرضها.

هل يعمل الـ stub الخاص بـ IMA ضد إدراج الإعلانات من الخادم؟

لا. مع نظام SSAI (Server-Side Ad Insertion)، تُدمج الإعلانات في تدفق الفيديو على الخادم قبل التوصيل، لذا لا توجد مكالمة عميلية لحزمة التطوير (SDK) يمكن اعتراضها. يتطلب الإدراج من جانب الخادم تدابير مكافحة مختلفة، وهو خارج نطاق ما يمكن أن تعالجه إضافة المتصفح.

ما المتصفحات التي يمكنها تشغيل هذا النوع من الإضافات؟

تم بناء AdOff باستخدام Manifest V3، ويعمل على متصفحات Chrome وFirefox وSafari وEdge وOpera. تشمل طبقة إبطال IMA في النسخة المجانية، دون الحاجة إلى حساب أو تسجيل.

هل يمكن لموقع الكتروني اكتشاف أن الـ SDK قد تم استبداله؟

هذه هي وظيفة طبقة التخفي (stealth layer): تضليل الهدف (bait spoofing) واعتراض fetch/XHR يجعلان البيئة تبدو عادية أمام نصوص مكافحة الإعلانات المُخفية. ولا توجد طريقة دائمة، نظرًا لأن المنصات تُغيّر أساليب الكشف باستمرار.

مزيد حول هذا الموضوع: حظر الإعلانات أثناء البث: دليل شامل, الإعلانات قبل التشغيل، أثناء التشغيل، وبعده: شرح تنسيقات الإعلانات الفيديو, كيف يعمل AdOff، طبقة تلو الأخرى.