يعد Ad Exchange كجزء من عرض الأسعار في الوقت الفعلي (RTB) أحد حلول AdTech التي تعمل على تغيير سوق الإعلان عبر الإنترنت. وتتمثل وظيفتها الرئيسية في إرساء عدد كبير من SSPs و DSPs التي ليس لها تكامل مباشر بين بعضها البعض ، وكذلك إعادة بيع مجموعة متنوعة من حركة الإعلانات بينهما.
بفضل طلب للسوق الأمريكية ، انغمسنا بشدة في تفاصيل بناء منصة Ad Exchange. وفي هذه المقالة نقدم بعض الأفكار والنتائج.
بيان المشكلة
توفر عروض الأسعار في الوقت الفعلي (RTB) بيع مساحات إعلانية على المواقع في الوقت الفعلي لعرض الإعلانات ذات الصلة على الجمهور المستهدف.
باختصار ، فإن مخطط العملية هو كما يلي:
- يطلب المستخدم النهائي صفحة ويب أو تطبيق جوال يتم فيه حجز مكان لإعلان بانر (رمز منصة بيع المخزون الإعلاني مدمج - SSP ، Supply Side Platform) ؛
- لضمان الحد الأقصى لسعر البيع للمخزون ، ينظم SSP العطاءات بين مختلف DSPs (منصة جانب الطلب) من خلال Ad Exchange ، الذي يهدف إلى شراء المخزون بأرخص سعر ممكن ؛
- بعد الإعلان عن الفائز في المزاد ، يرسل DSP الفائز رمز بانر SSP ، والذي يتم عرضه للمستخدم ؛
- جانب آخر من العملية هو DMP ، وهو نظام تابع لجهة خارجية يزود DSP بمعلومات تفصيلية عن المستخدم النهائي (بخلاف ما يمكن أن ينقل SSPs في شكل ملفات تعريف الارتباط ، وما إلى ذلك) لتبرير سرعة الشراء والتكلفة المقترحة.
هناك عدد غير قليل من بورصات Ad Exchange اليوم. بالإضافة إلى ذلك ، يقوم العديد من موفري الخدمات المشتركة (SSP) بتنفيذ عروض التسعير الخاصة بهم (مما يؤدي في الواقع إلى إغلاق وظيفة Ad Exchange). لكن عميلنا كان على يقين من أنه بسبب بعض الأفكار الجديدة يمكنه دخول السوق بسرعة وتحمل المنافسة.
يعمل التبادل على مبادئ مختلفة: يقدم شخص ما هامشًا أكبر ، وشخصًا أقل ، ويبيع شخصًا معدات فريدة ، بينما يركز الآخرون على السلع الاستهلاكية المشروطة. السوق صغير للغاية ويتطور بنشاط ، وبالتالي لا توجد نماذج أعمال تم اختبارها على مر السنين هنا: كل شيء مبني على فرضيات وتجارب جريئة. يعمل معظم اللاعبين وفقًا لمخطط بسيط: حيث يتلقون طلبًا من أحد مقدمي خدمات SSP الذين تمكنوا من الموافقة عليه ، وإرساله إلى جميع DSPs المتكاملة توقعًا لرهان أفضل. أرباح Ad Exchange - الفرق بين سعر الشراء وسعر البيع لمخزون الإعلانات في SSP و DSP ناقصًا تكاليف التشغيل.
اقترح عميلنا تحسين هذا النظام من خلال توزيع طلبات SSP بشكل صحيح على DSP - عدم إرسال طلبات "فقدان" عمدا ، وبالتالي تقليل تكاليف التشغيل. ونتيجة لذلك ، يمكنك تقليل عمولة البورصة دون خسارة الإيرادات ، وجعل عرضك أكثر جاذبية على خلفية المنافسة في Ad Exchange في النضال من أجل SSP و DSP. وربط المزيد من الشركاء سيعطي الدخل والاستقرار في السوق.
لتنفيذ هذه الإستراتيجية في السوق الأمريكية ، كُلّفنا بجعل Ad Exchange بتوزيع ذكي للطلبات ، وهو توفير نسبة إعادة شراء جيدة. نظريًا ، لمثل هذا التوزيع ، يمكنك استخدام الكثير من المعلومات المصاحبة للطلب ، حتى البيانات من أنظمة الجهات الخارجية المذكورة أعلاه (DMP). ومع ذلك ، تتطلب التحليلات المعقدة موارد ، لذا فإن المهمة هي في الواقع إيجاد توازن بين تكاليف التوزيع الذكي والمكاسب (مقارنة بالجهات الفاعلة الأخرى في السوق) من تنفيذه. في سوق غير ناضجة جديدة نسبيًا ، فإن بناء حلول معقدة للغاية ، والضغط على أعشار التحسين ، ببساطة لا معنى له.
ومن السمات المهمة للمشروع ، بالإضافة إلى الأحمال العالية المتوقعة ، تلبية المتطلبات غير الوظيفية لسرعة المزاد الذي طرحه SSP. الوقت المناسب في هذا الجزء من السوق هو مهلة انتظار استجابة من SSP إلى 300 مللي ثانية ، والتي يجب تلبيتها مع المكالمات إلى الأنظمة الخارجية (DSP).
بدأ المشروع في خريف عام 2016. بفضل خبرة الفريق في هذا المجال ، قمنا بعمل أول نموذج أولي بعد ثلاثة أشهر ، وبعد أن أصبح ثلاثة منتجات أخرى (الحد الأدنى من المنتجات القابلة للتطبيق) جاهزة ، مما سمح لنا بجمع التحليلات الأولى لبدء التوزيع الذكي للطلبات داخل Ad Exchange.
أظهر إطلاق MVP أن الفرضية حول النجاح التجاري للمشروع صحيحة - بدأت Ad Exchange في كسب المال للعميل. تضمنت خطط التطوير الأولية لبرنامج Ad Exchange دراسة أعمق للبيانات - ربط معلومات المستخدم النهائي من الأنظمة الخارجية بالتحليلات. ولكن في مرحلة MVP ، تقرر استخدام البيانات التي يمتلكها SSP فقط. كان هذا كافيا لتحقيق الربح المتوقع.
هندسة الحلول
تم بناء الحل على نموذج سلسلة المسؤولية ، والذي يسمح بعدم إصلاح مسار الطلبات داخل النظام ، وإضافة المعالجات والخدمات المختلفة بسهولة ، من المزاد نفسه إلى أدوات التصفية.
لم يقيدنا العميل في مجموعة التقنيات المستخدمة. لذلك ، مع الاهتمام بالتطوير والدعم المستقبليين للمشروع ، قمنا ببناء حل قابل للتوسيع أفقيًا باستخدام Postgres و Hadoop.
Ad Exchange نفسه مكتوب بلغة جافا - في الوقت نفسه ، لم نستخدم أي أطر عمل حتى لا نتراجع في الحمل (عملنا على مستوى منخفض).
للحفاظ على مهلة SSP المذكورة ، اخترنا معلمات جامع البيانات المهملة (تم استخدام G1) وعملنا على عمل متزامن مع عدد كبير من الطلبات - استخدمنا عميل HTTP لا يمنع التدفق ، بالإضافة إلى امتداد بروتوكول HTTP المستمر الذي يسمح بإرسال العديد من الطلبات في غضون اتصال TCP واحد.
يتم نشر مكونات البرامج على الأجهزة المستأجرة من المضيف ، مثل لم تسمح ظروف المهمة باستخدام السحابة بسبب تداخل الموارد لأجهزة السحابة الافتراضية (قد يستغرق تخصيص الموارد اللازمة بعض الوقت ، لكن ليس لدينا ذلك). في الوقت الحالي ، يستخدم Ad Exchange أربعة خوادم فعلية ، أحدها فائض (للتحديثات السلسة ، وما إلى ذلك).
يتم استخدام Apache Kafka مفتوح المصدر كوسيط للرسائل - فهو مدمج بشكل مثالي في نموذج "مشترك واحد - العديد من الناشرين" ، على الرغم من أنه كان يجب أن يكون ملتويًا قليلاً حتى لا تصل الرسائل المتكررة.
يوفر كل خادم في الوضع العادي معالجة حوالي 10 آلاف طلب في الثانية (تم وضع هذه المعلمات أثناء تطوير الحل). الآن يبلغ متوسط الحمل 15-20 ألف طلب في الثانية ، وفي ذروة تدفق الطلب وصل إلى 40 ألف في الثانية لعدة ساعات ، وقام Ad Exchange بعمل رائع في هذا الأمر.
يتم توزيع الطلبات بين الخوادم بواسطة موازن تحميل برنامج nginx ، والذي تم تكوينه لمهمتنا. في تجربتنا ، على nginx ، يمكنك الاحتفاظ بما يصل إلى 60-70 ألف طلب في الثانية ، دون تخصيص موازن أجهزة منفصل. إذا كان الحمل في Ad Exchange في المستقبل أعلى من هذا الحد ، فنحن نخطط لشراء موازن أجهزة يوزع الطلبات بين العديد من نفس النوع nginx.
يراقب ما يحدث ، ويخضع لزيادة مستمرة في الحمل ، ونظام مراقبة ، وهو جزء من Ad Exchange الذي تم إنشاؤه.
التخزين
نظرًا للاعتماد على التحليلات أثناء توزيع طلبات البحث ، تعد قاعدة البيانات جزءًا لا يتجزأ من Ad Exchange. يخزن النظام معلومات حول العطاءات والمشاركين في المزاد والمعاملات.
لا معنى لجمع مثل هذا الحجم من البيانات طوال فترة Ad Exchange بالكامل ، لذا فإن التخزين له بنية متعددة المستويات. يتم تخزين جميع بيانات المزاد في الأسبوع. وبناءً عليها ، يتم بناء وحدات وسيطة عالية المستوى ، يتم تخزينها لعدة أشهر. وعلى أساس الوسيطات ، يتم استخدام المجاميع النهائية ، والتي يتم استخدامها في التحليلات طويلة الأجل وللتوفيق مع SSP و DSP. من بين المعلومات الأخرى في هذه الوحدات ، هناك بيانات حول عدد الرهانات التي تم إجراؤها ومقدار الأموال التي ستدفعها البورصة SSP أو تتوقع تلقيها من DSP.
يتم تخزين نقاط النهاية طوال مدة Ad Exchange.
تقدم مجموعة التحليلات وتشكيل المجاميع خدمات منفصلة.
حتى يتوافق التخزين مع سرعة النظام نفسه ، كان علي أيضًا العمل معه. على وجه الخصوص ، لبعض الوقت قاتلنا مع المضيف ، لأنه بيانات المعاملات ببساطة لم يكن لديها الوقت للكتابة إلى قاعدة البيانات. اتضح أن الخطأ كان مشكلة في الأجهزة مع مجموعة RAID. بعد استبدالها ، تمكنا من الضغط على 90.000 طلب في الثانية على Postgres (عن طريق إدراج البيانات في قاعدة البيانات).
ما تبقى من Ad Exchange عديم الحالة ، مما يوفر تحجيمًا أفقيًا سهلاً في المستقبل. لا يقوم بتخزين أي بيانات عن الطلبات - الحد الأقصى من المعلومات المستلمة حول DSP التي يجب تحديدها. حتى نتمكن من إضافة خوادم جديدة لمعالجة الطلبات حسب الحاجة.
تصفية حركة المرور
يعد ترشيح حركة المرور أحد العناصر الرئيسية في النظام التي تسمح لك بتقليل الحمل والاحتفاظ بها خلال المهلات المحددة من قبل العميل.
وفقًا للمهمة المطروحة ، أي Ad Exchange:
- قبول الطلبات من SSP ؛
- عقد مزاد (يرسل الطلبات إلى العديد من DSPs ، يقارن الأسعار المعروضة ، ويحدد الفائز) ؛
- يوافق على فوز SSP (يُبلغ عن سعر الفائز مطروحًا منه عمولته ، وينتظر الرد بالسعر النهائي للعرض) ؛
- يكمل المعاملة (يقدم التقارير إلى DSP اللازمة حول فوزه ، ويقوم بإجراء حركة مرور المستخدم).
يتم تضمين توزيع الطلبات الذكية في Ad Exchange في المرحلة الأولى من المزاد.
عندما نتلقى طلبًا من SSP بمعلومات معينة (IP ، وكيل المستخدم) ، نقوم بتفصيله باستخدام المعلومات المتراكمة في النظام - معلومات المستخدم المعروفة ، وقائمة DSPs التي تم إرسال الطلبات المماثلة إليها ، وردودهم ، وما إلى ذلك. يعد ذلك ضروريًا لتحديد أكثر تركيبة DSP فائدة لكل طلب. بفضل اختيار مثل هذه المجموعة ، يسمح لك النظام بعدم إرسال الطلبات إلى DSPs التي لا تقدم عطاءات أو تقدم عروض ، ولكنها منخفضة للغاية. للقيام بذلك ، تقوم خدمة منفصلة في الوقت الحقيقي بتجميع خريطة لكيفية استجابة DSP للطلبات (يتم تخزين هذه البطاقات في Redis).
بالتوازي ، نتحقق من حالة DSP - إذا انخفضت نسبة الاستجابات خلال المهلة ، فإن النظام يقلل تلقائيًا من عدد الطلبات إلى DSP هذا. بمجرد أن يتم تقليل الحمل على DSP (وتزايد نسبة الإجابات الصحيحة في وقت مقبول) ، يعود عدد الطلبات تدريجيًا إلى مستواه السابق.
من بين DSPs التي تم الرد عليها في الوقت المحدد ، نعقد مزادًا داخليًا - حدد أفضل عرض وأرسله إلى SSP. من وقت الطلب من SSP إلى ردنا ، لا يمر أكثر من 300 مللي ثانية ، وفقًا لمتطلبات الصناعة.
نظرًا لأننا نرسل البيانات إلى موفر الخدمات المشتركة SSP ، حيث يُعقد مزادنا ، نحتاج إلى النظر في العطاءات التي فازت بها هناك. يشارك خادم المزاد في تسجيله بالفعل في المرحلة التالية ، عند معالجة حركة مرور المستخدم. بفضله ، تم إثراء خريطة استجابة DSP ببيانات جديدة (جنبًا إلى جنب مع المعلومات التي تم جمعها عن المستخدم النهائي).
تسمح لنا مقارنة البيانات التي تم الحصول عليها في مرحلة المزاد والمعلمات المعروفة من حركة مرور المستخدم بتصفية برامج التتبُّع (النقرات الإعلانية ، برامج البحث ، وما إلى ذلك). لا يسترد DSP حركة المرور هذه ، وفي غياب نظام التصفية الخاص بها ، يتحول إلى خسائر في العميل ، والتي يجب تغطيتها بالهامش.
وتجدر الإشارة إلى أن تصفية حركة الروبوت لم تبدأ على الفور. ولكن بعد إدراج أقفال بسيطة ، كان كسب الهامش حوالي 50٪.
بالمناسبة ، بالإضافة إلى أدوات تصفية حركة المرور التلقائية في نظامنا ، من الممكن للعميل تغيير قيم العتبة لعدد من المعلمات يدويًا ، وبالتالي تعديل الهامش.
تعد حركة المستخدم في حد ذاتها أمرًا بالغ الأهمية بالنسبة لنا ، ولكن عند معالجتها ، لم يعد من الضروري احتواء 300 مللي ثانية. يستخدم نظام معالجة منفصل ، والذي يمكن أن يحمل المستخدم قليلاً ، ولكنه لن يسمح بفقدان هذا الطلب.
لضمان استقرار الحل ، تم تقديم نظام فرعي ، والذي ، بفهم حمل Ad Exchange الحالي ، "يقطع" طلبات المزادات ، التي لا يمكن معالجتها فعليًا. وبالتالي ، فإن النظام محمي من نمو الحمل غير المنضبط من SSP.
الآفاق
حتى الآن ، أنشأنا Ad Exchange أعمالًا وحقق ربحًا جيدًا. ونحن نقدم الدعم والتكامل للشركاء الجدد (DSP / SSP) حسب الضرورة. في المجموع ، تم بالفعل دمج عشرات الأنظمة. لا يعني كل تكامل من هذا القبيل اتصال البرنامج فحسب ، بل أيضًا اختبارًا شاملاً للخدمة ، لأنه في ظل الأحمال الثقيلة ، يمكن أن تؤثر مشكلات الخدمة المتصلة على الشركاء الآخرين.
بشكل عام ، يتحرك السوق نحو حقيقة أن SSP و DSP سيربطان مباشرة ، مما يجعل التبادل غير ضروري. لكن التكامل يعتمد على قدرات SSP و DSP. على الرغم من وجود API المفتوح الموصوف (بروتوكول OpenRTB) ، إلا أنه لم يتم التعرف عليه عالميًا بعد في السوق. على سبيل المثال ، قام لاعب رئيسي مثل Appnexus بدمج دعم OpenRTB مؤخرًا.
بشكل أساسي ، يعد Ad Exchange مزودًا للسيولة. لذا من غير المحتمل أن يفقد القرار أهميته في المستقبل القريب. علاوة على ذلك ، يكتسب نموذج التبادل شعبية فقط في بقية سوق الإعلانات.
كاتب المقالة: نيكولاي إريمين
ملحوظة: نحن ننشر مقالاتنا على عدة مواقع في Runet. اشترك في صفحاتنا على
VK أو
FB أو
قناة Telegram لمعرفة المزيد عن جميع منشوراتنا وأخبار Maxilect الأخرى.