شرح header bidding للناشرين

غيّر header bidding الطريقة التي تبيع بها الوسيلة الرقمية مخزونها الإعلاني: فبدلاً من عرض كل مساحة على مشترٍ تلو الآخر، يعرضها على الجميع في آن واحد. إليك المشكلة التي جاء ليحلها، وكيف يعمل من الداخل، وما الذي يتطلبه تشغيله.

قبل header bidding: الشلال

ظلت الوسيلة الرقمية لسنوات تبيع إعلاناتها وفق ترتيب الأفضلية. فكان خادم الإعلانات، وهو البرنامج الذي يقرر أي إعلان يظهر في كل مساحة وأكثرها انتشاراً Google Ad Manager، يحتفظ بقائمة مرتبة من المشترين. وكانت المساحة تُعرض أولاً على من في رأس القائمة. فإن لم يردها، أو لم يبلغ الحد الأدنى المحدد للسعر، تنتقل إلى الثاني. وهكذا نزولاً حتى يشتري أحدهم. وهذه القائمة المرتبة هي ما يُسمى في القطاع waterfall، أي الشلال.

لم يكن الترتيب يُحدد لكل ظهور على حدة، بل وفق المتوسطات التاريخية. فكان الناشر (publisher)، أي مالك الوسيلة الذي يبيع مساحته الإعلانية، يضع في الأعلى الشبكة التي دفعت أكثر في المتوسط، وتحتها الشبكات التي دفعت أقل.

لماذا كان الشلال يهدر المال

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

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

المزاد الموحّد

يقلب header bidding هذا المنطق. فبدلاً من سؤال المشترين واحداً تلو الآخر، يُسأل الجميع في آن واحد، قبل أن يقرر خادم الإعلانات أي شيء. ويأتي الاسم من المكان الذي كانت توضع فيه الشيفرة في البداية: في الـheader، أي رأس صفحة HTML، لكي تُنفَّذ مع بدء تحميل الصفحة.

والنتيجة مزاد موحّد: يقدّم جميع المشترين المتصلين عروضهم على الظهور نفسه، في الوقت نفسه وبالشروط نفسها. ويدخل العرض الفائز إلى خادم الإعلانات كسعر محدد، وهناك يتنافس مع ما باعته الوسيلة بشكل مباشر.

الشلال يسأل: من يدفع أكثر عادةً؟ والمزاد الموحّد يسأل: من يدفع أكثر مقابل هذا الظهور؟

كيف يجري المزاد

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

بعد انتهاء الانتظار، تحتفظ الشيفرة بأعلى عرض وتمرره إلى خادم الإعلانات كمعطى إضافي. فيقارنه الخادم بمصادر الطلب الأخرى لديه ويعرض الإعلان الفائز. وغالباً ما يكون الشركاء المزايدون منصات SSP (supply-side platform)، أي منصات جانب العرض التي تجمع طلب كثير من المعلنين وتجعله يتنافس على مخزون الوسيلة.

header bidding من جانب العميل

في صيغة جانب العميل (client-side) يجري المزاد كله في متصفح القارئ. إذ يفتح جهازه اتصالاً بكل شريك، وينتظر الردود، ويجري الحسابات. والميزة أن ملفات تعريف الارتباط الخاصة بالمتصفح موجودة هناك، وهي ما يتيح للمشترين التعرف على المستخدم والمزايدة بمعلومات أكثر. كما يرى الناشر كل عرض في سجله الخاص: فالشفافية كاملة.

الثمن أن جهاز القارئ هو من يقوم بالعمل. فكل شريك يُضاف يعني اتصالاً متزامناً آخر، والمتصفحات تحدّ من عدد الاتصالات التي يمكن فتحها في وقت واحد. وبعد عدد معين من الشركاء، لا تعود إضافة شريك جديد مجدية.

header bidding من جانب الخادم

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

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

ما هو Prebid

Prebid مشروع مفتوح المصدر أصبح المعيار الفعلي لـheader bidding. وهو ليس شركة تشتري المخزون، بل البنية التحتية التي تنظم المزاد. فـPrebid.js هي المكتبة التي تُثبَّت في الصفحة وتنسق المزايدة من جانب العميل؛ وPrebid Server يؤدي المهمة المقابلة من جانب الخادم. وتتولى صيانته Prebid.org، وهي منظمة غير ربحية تدعمها شركات من القطاع.

فائدته العملية أن كل شريك طلب يكتب محوّلاً (adapter) لـPrebid، فيفعّله الناشر من الإعدادات بدلاً من دمج كل شريك على حدة. ولأنه مفتوح المصدر، يمكن لأي شخص قراءة الشيفرة والتحقق من طريقة حسم المزاد.

ما يكلّفه من سرعة

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

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

ما الذي تحتاجه لتطبيقه

أول ما تحتاجه خادم إعلانات خاص بك، عادةً Google Ad Manager، مع بنية أسعار مضبوطة لاستقبال العروض. فالوسيلة التي تحقق الدخل عبر AdSense وحده لا يمكنها إضافة header bidding قبل اتخاذ هذه الخطوة. ثم تحتاج إلى شركاء طلب يقبلون الدمج، وهنا يكون لحجم الزيارات وزنه: فمنصات SSP لا تفتح حساباً لأي موقع.

ثم تأتي الصيانة، وهي التي تحدد ما إذا كان هذا سيحقق عائداً أم لا. إذ يجب مراجعة مدد الانتظار، وإضافة شركاء وإخراج آخرين، ومراقبة نسبة المساحات التي تبقى دون تعبئة. وتفوّض كثير من الوسائل هذه العملية إلى شريك لتحقيق الدخل يوفّر البنية التحتية ويديرها. وسواء تم ذلك داخلياً أو خارجياً، فإن السؤال الذي يستحسن حسمه قبل البدء واحد: من سيضبط هذا عندما يتوقف عن العمل؟

كيف نعمل عليه في ADEQ Media

إعداد header bidding بنفسك يعني صيانة wrapper، والتفاوض مع كل شريك، وضبط مدد الانتظار، ومراقبة ألا يستحوذ شريك بطيء على المزاد. إنه عمل مستمر، لا مجرد تثبيت.

في ADEQ نتولى ذلك نحن: عدة شركاء طلب (demand partners) مميزين يتنافسون في الوقت نفسه، والإعداد والتحسين خلال أول 15 يوماً، وهي الفترة التي يتضح فيها من بياناتك أنت أي المواضع تحقق عائداً وأيها يعيق.

لا يوجد التزام بمدة. ونوصي بتجربة لمدة 30 يوماً لأنك قبل هذه المدة ستقيس ضجيجاً لا نتيجة. والشروط موجودة في الأسئلة الشائعة.