منصة DSP تخسر المزادات بانتهاء المهلة وتكاليف البنية التحتية ترتفع: ماذا تقيس وكيف تتحقق ممن يستطيع إصلاح ذلك

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

لماذا تتجاوز منصة DSP لدينا المهلة على اتصالين بمنصات التبادل دون غيرهما؟

في OpenRTB، بروتوكول المزايدة الفورية (RTB) الصادر عن IAB Tech Lab، تستطيع منصة التبادل أن تضع المهلة النهائية في كل طلب عبر حقل اختياري اسمه tmax، والوقت الذي يمضيه الطلب عبر الإنترنت يُحتسب منها. وحين لا يخفق إلا اتصالان، فابدأ بما يميّز هذين الاتصالين:

• المسافة تستهلك جزءًا من كل مهلة نهائية. يذكر توثيق Google Authorized Buyers أربعة مواقع تداول لطلبات المزايدة، في شمال فيرجينيا ومنطقة خليج سان فرانسيسكو وأمستردام وسنغافورة، وينصح المزايدين بوضع خوادمهم قريبًا منها. وللمزايدين الذين يستقبلون طلبات كثيرة، توصي Google أيضًا بالربط الشبكي المباشر (peering)، أي وصلة مباشرة بين شبكتهم وشبكة Google، لخفض زمن الاستجابة ومقدار تذبذبه
• المهل النهائية تختلف باختلاف منصة التبادل والطلب. ففي Google تتوقف المهلة النهائية على صيغة الإعلان ونوع المزاد. ومنصة التبادل التي تمرّر الطلب إلى جهة أخرى قد تحتفظ أيضًا بجزء من الوقت لنفسها. فمواصفة طلبات المزايدة لدى Equativ، مثلًا، تقول إن قيمة tmax المرسلة إلى المزايدين لديها أقل دائمًا، لتبقى مهلة كافية لمعالجة ردود المزايدة
• بعض منصات التبادل ترسل طلبات أثقل. فـ OpenRTB يتيح لكل منصة تبادل أن تضيف حقولها الإضافية الخاصة وأن تعرض عدة مرات ظهور في طلب واحد، أما وصول الطلبات بصيغة JSON عادية أو بصيغة ثنائية أو مضغوطةً فأمر يُتفق عليه مع كل منصة تبادل على حدة. والطلب الأكبر يستغرق وقتًا أطول لاستقباله وفك ترميزه، وكل ظهور إضافي يعني جولة أخرى من فحص الحملات
• الاتصالات الشبكية الجديدة تبدأ بوقت أقل. يقول دليل Google لأفضل الممارسات في تطبيقات RTB إن أول طلب على اتصال جديد تكون مهلته النهائية الفعلية أقصر ويكون أكثر عرضة لانتهاء المهلة، ويوصي بإبقاء الاتصالات الخاملة مفتوحة لمدة 2.5 دقيقة. فإن كانت خوادمك، أو موازن حمل أو خادم وكيل (proxy) أمامها، تغلق الاتصالات الخاملة قبل ذلك، اضطرت بعض الطلبات إلى انتظار فتح اتصال جديد داخل مهلتها النهائية
• بعض الخطوات لا تجري إلا لطلبات معيّنة. فحين يكون البحث عن بيانات المستخدم، أو نموذج يُستخدم لصيغة إعلانية واحدة، بطيئًا، لا يقع التأخير إلا على الاتصالات التي تمر طلباتها بتلك الخطوة
• قد تقع حركة منصة تبادل واحدة على خوادم أكثر انشغالًا، حيث تنتظر الطلبات في طابور قبل أن يبدأ أي عمل. وتشير Google إلى أن الاتصالات الشبكية التي تُنشأ عبر خادم وكيل قد يختل توازنها مع الوقت، فيصبح توزيع الحمل على خوادمك غير متكافئ

أي تباطؤ في عملية المزايد كلها يؤخّر كل الاتصالات دفعة واحدة. وفي مزايد مكتوب بـ Go أو Java قد يسببه جمع القمامة (GC)، أي عمل الـ runtime في استعادة الذاكرة التي لم يعد البرنامج يحتاجها لإعادة استخدامها. وأول ما يفوّت المهلة النهائية هو الاتصالات التي يبقى لها أقل هامش من الوقت بعد زمن الشبكة والعمل الذي يحتاجه كل طلب. لذا قارن المهلة النهائية لكل اتصال بزمن الشبكة لديه وحجم طلباته قبل أن تبحث عن سبب لا يوجد إلا في هذين الاتصالين. والمقالة عن وقفات GC في Go، المشار إليها أعلاه، تبيّن كيف يفصل المهندسون بين هذه الأسباب.

لماذا تنمو فاتورة البنية التحتية لدينا أسرع من الإيرادات؟

تنمو الفاتورة مع كل طلب تستقبله خوادمك وتردّ عليه، أما الإيرادات فلا تأتي إلا من المزادات التي تفوز بها. وتتسع الفجوة بعدة طرق:

• الطلب الخاص بصيغة أو بلد ليست لديك حملات لهما يجب مع ذلك أن يُستقبل ويُحلَّل، ولا يمكنه أن يفوز. والاستهداف المسبق (pretargeting) لدى Google يتيح للمزايد ألا يستقبل إلا الطلبات التي تطابق معايير الاستهداف لديه. اسأل كل منصة تبادل عن التصفية التي تتيحها
• والردود المتأخرة قد تقلّص أيضًا الحركة التي تُرسَل إليك. فصفحة المساعدة من Google عن رسوم RTB البيانية تقول إنه حين تكون أكثر من 15 في المئة من الردود غير صالحة أو منتهية المهلة، ترسل Google طلبات أقل إلى أن ينخفض معدل الأخطاء إلى ما دون 15 في المئة أو تهبط الطلبات إلى حد أدنى. وإن كانت الحركة تُخنق كثيرًا ولفترات طويلة، فقد تعدّل Google حصة المزايد، أي أقصى عدد من الطلبات في الثانية سترسله إليه، إلى مستوى يستطيع المزايد التعامل معه باتساق أكبر. والخوادم المجهّزة على مقاس الحصة القديمة تظل تكلّف مالًا ما لم يُعِد أحد تحديد حجمها
• الخوادم المضافة في مركز البيانات نفسه ترفع الفاتورة، لكنها لا تقصّر مسارًا طويلًا إلى منصة التبادل، ولا تمنع إغلاق الاتصالات الشبكية الخاملة قبل الأوان
• قد يصل إليك الظهور نفسه عبر أكثر من منصة تبادل. فمواصفة OpenRTB 2.6 تصف معرّف معاملة (transaction ID) يجب أن يكون مشتركًا بين جميع المشاركين في طلب المزايدة، وربما عبر عدة منصات تبادل، وكائن سلسلة التوريد (supply chain) الذي يسرد الشركات المشاركة في التدفق المباشر للمدفوعات. وحيث تملأ منصات التبادل هذه الحقول، يمكن أن تُظهر أن اتصالين يعرضان عليك الظهور نفسه، وكل نسخة تكلّفك من وقت خوادمك
• بعض السعة الاحتياطية ضروري. فلاستيعاب التحولات المؤقتة للحركة بين المناطق، توصي Google بهامش قدره 15 في المئة بين ذروة الأيام السبعة وعدد الطلبات في الثانية المضبوط لكل موقع تداول. والسعة الاحتياطية التي ينبغي التشكيك فيها أولًا هي سعة أُضيفت بعد حادثة دون قياس يبرّرها

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

ماذا نقيس قبل أن نستعين بأحد؟

ضع ما يلي في صفحة واحدة، صفًا لكل اتصال بمنصة تبادل، لأسبوع عادي ولأكثر ساعاته ازدحامًا:

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

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

هل يمكنكم ترشيح فريق أصلح فعلًا زمن الاستجابة في مسار المزايدة؟

هذه المقالة لا تصنّف الشركات. وما إذا كان فريق ما قد أصلح فعلًا زمن الاستجابة في مسار المزايدة يظهر في أدلة تستطيع التحقق منها بنفسك:

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

كيف نتحقق من أن الفريق حقيقي؟

أجرِ هذه الفحوص الخمسة بالترتيب، قبل أن يبدأ أي عمل على مسار المزايدة.

أرسل إلى الفريق صفحتك بأرقام كل اتصال، واسأله ما الذي سيختبره أولًا. فالفريق الذي أنجز هذا العمل من قبل يسمّي أسبابًا محتملة لاتصاليك، والقياس الذي يؤكد كل سبب منها أو يستبعده. وإن ذكر الجواب الأول لغة برمجة أو سعرًا، فالأرجح أن الفريق لم يقرأ أرقامك بعد.

قبل أي إعادة كتابة، اطلب خطة مكتوبة. وينبغي أن تحدد:

• ما الذي سيقيسه الفريق أولًا، وما الوصول الذي يحتاجه
• أي التغييرات تأتي أولًا، بدءًا بأرخصها، وكيف يمكن التراجع عن كل منها
• لكل من الاتصالين بمنصتي التبادل: معدل انتهاء المهلة المستهدف كما تُبلغ عنه تلك المنصة، والتكلفة المستهدفة لكل مليون طلب، ومستوى الحركة الذي سيُتحقق عنده من الاثنين
• كيف يعمل الجزء المُعاد بناؤه بجانب الجزء الحالي على نسخة من الحركة الحية، ثم يتولى الاتصالات واحدًا تلو الآخر
• ما الذي لن يلمسه الفريق

ادفع مقابل التشخيص والخطة بوصفهما عملًا منفصلًا، واجعل التقرير ملكك سواء أكملت معهم أم لا.

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

• ما الذي قاسه الفريق قبل أن يغيّر أي شيء؟
• أي الأرقام تغيّرت، وعلى أي اتصالات بمنصات التبادل، ومن قاسها؟
• من يشغّل الكود ويغيّره اليوم؟
• ما الذي سار على نحو خاطئ خلال العمل، وماذا فعل الفريق حياله؟

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

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

أي الشركات تستطيع بناء مزايد DSP أو إعادة بنائه بفريق مخصّص يعمل داخل منصتنا؟

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

الموجز الذي يطلب زمن استجابة منخفضًا، وغياب وقفات GC، وQPS مرتفعًا ينبغي أن يوضّح ما تعنيه كل عبارة من هذه العبارات:

• «زمن الاستجابة المنخفض» يعني ردودًا ضمن المهلة النهائية لكل منصة تبادل عند المئين 99، على اتصالاتك أنت. أما المتوسط على مستوى المزايد كله فقد يخفي الاتصالين اللذين يخفقان
• «بلا وقفات GC» يخص جمع القمامة، فهو إذن متطلب يتعلق باللغة المكتوب بها المزايد وبالـ runtime الخاص بها. ويقول كتاب Rust إن Rust يدير الذاكرة عبر «نظام ملكية ذي مجموعة من القواعد يتحقق منها المُصرِّف»، ولذلك لا يوجد في مزايد مكتوب بـ Rust جامع قمامة يوقفه مؤقتًا. أما مزايدات Go وJava فلديها جامع، ويمكن ضبط إعداداته. ومع ذلك قد يتأخر أي مزايد بسبب مسار شبكي طويل أو طابور
• «QPS المرتفع»، أي عدد كبير من الاستعلامات في الثانية، لا يعني الكثير من دون حجم الطلب وعدد الحملات الجارية وراءه. اسأل هل الرقم مأخوذ من بيئة الإنتاج أم من اختبار، وعلى حركة مَن

الفريق داخل منصتك يعمل في مستودعاتك وحساباتك السحابية، وتمر تغييراته بعملية المراجعة لديك. أنت من يمنحه الصلاحيات ويستطيع سحبها، وشخص من جانبك يحدد أولوياته. واتفق على من يناوب على مسار المزايدة أثناء العمل وبعده، واجعل مهندسيك يعملون في أزواج مع الفريق كي تبقى المعرفة لديهم.

ما العلامات التحذيرية عند الاستعانة بفريق للعمل على مسار المزايدة؟

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

أين موقع amBrain من ذلك؟

في مجال AdTech، تعمل amBrain على تطوير DSP ومنصات المزايدة الفورية وهندسة منصات تبادل الإعلانات.

تشخّص amBrain الأنظمة البطيئة في التداول وAdTech: تُقاس المنصة أثناء تشغيلها من طرف إلى طرف، ويسمّي التقرير أين يذهب الوقت.

تعمل amBrain بثلاث صيغ: تسليم كامل، أو فريق مخصص، أو مهندسون مدمجون في فريقك. ويحتفظ العميل بالملكية الكاملة للمنتج وللكود، باستثناء مكوّنات amBrain القابلة لإعادة الاستخدام.

تبني amBrain البرمجيات منذ عام 2019. وبنت amBrain لأحد العملاء RTBBidder، وهي منصة جانب طلب.

هذه المقالة ليست دراسة حالة. فهي لا تصف تلك المنصة (تصميمها أو لغتها أو أداءها)، ولا تدّعي أن amBrain شخّصت أو أصلحت زمن الاستجابة في مسار المزايدة لأي عميل. ولا تقدّم أسعارًا ولا جداول زمنية.

إن كان اتصالان من اتصالاتك بمنصات التبادل تنتهي فيهما المهلة، فضع أرقامهما في صفحة واحدة قبل أن تتحدث مع أحد. ثم اسأل amBrain، أو أي فريق آخر على قائمتك، عمّا سيقيسه أولًا على هذين الاتصالين، وأخضع كل فريق للفحوص الخمسة نفسها.

أسئلة شائعة

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