التلفزيون المتصل في منصة DSP أو SSP لديك: ما الذي يتغيّر وما الذي تبنيه بنفسك

إعلانات التلفزيون المتصل (CTV) إعلانات فيديو تُعرض على أجهزة التلفزيون المتصلة بالإنترنت، وتأتي عادةً في فاصل يضم عدة إعلانات داخل تطبيق بث. ومنصة DSP أو SSP المبنية لإعلانات البانر على الويب وفي التطبيقات يجب أن تتغير في أربعة مواضع كي تتعامل معها. فطلب المزايدة يصف فاصلًا إعلانيًا كاملًا بدل موضع إعلاني واحد. والإعلان يصل في صورة استجابة VAST، وهي مستند XML يشير إلى ملفات الفيديو. وكثير من تطبيقات التلفزيون لا تستطيع طلب الإعلانات وتتبّعها كما يفعل المتصفح، لذا تُدرج خدمةُ دمج (stitching) الإعلانَ في البث. ثم ترسل تلك الخدمة طلبات الإعلانات، وكثيرًا ما ترسل استدعاءات التتبع أيضًا، نيابةً عن التلفزيون، لذا عليك أن تحدد الأجهزة وتعدّ مرات الظهور بطريقة مختلفة. والمزايدة على الفواصل الإعلانية ودعم VAST جديران بأن تبنيهما في منصتك الخاصة. أما الدمج فمكانه لدى الناشر أو لدى خدمة مبنية لهذه المهمة.

ما الذي يختلف في إعلانات التلفزيون المتصل؟

على الموقع الإلكتروني، يكون طلب الإعلان عادةً لإعلان واحد في موضع واحد، فيحمّل المتصفح ذلك الإعلان ويُبلغ عن الظهور. أما على التلفزيون، فيشاهد المشاهد برنامجًا في تطبيق بث، وتأتي الإعلانات في فواصل، كما في البث التلفزيوني التقليدي. وتسمّي IAB Tech Lab، الهيئة التي تتولى صيانة بروتوكول المزايدة OpenRTB، مثل هذا الفاصل ad pod (حزمة إعلانية): أي إعلان واحد أو أكثر «يُعرض على التوالي دون انقطاع ضمن بث لمحتوى فيديو أو صوت».

تصف مواصفة OpenRTB 2.6 الصادرة عن IAB Tech Lab الإصدار 2.6 بأنه الإصدار الذي «يقدّم الحزم الإعلانية (Ad Pods) لمعاملات CTV». وتستند هذه المقالة إلى تلك المواصفة وإلى ملاحظات التنفيذ التي وضعتها IAB Tech Lab لها، وقد جرى الاطلاع عليهما في 2 نوفمبر 2026 شأنهما شأن المصادر الأخرى هنا.

كيف يصل الفاصل الإعلاني في طلب المزايدة؟

في OpenRTB 2.6، يصل الفاصل في صورة كائن ظهور (impression object) واحد أو أكثر في طلب المزايدة، وكائنات الظهور التي تشترك في قيمة podid نفسها تنتمي إلى الفاصل نفسه. وتصف ملاحظات التنفيذ ثلاثة أنواع من الفواصل:

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

معظم منصات البانر لم تضطر قط إلى قراءة الحقول التالية:

• poddur، وهو إجمالي عدد الثواني التي يجوز للمعلنين ملؤها في فاصل ديناميكي، وmaxseq، وهو أكبر عدد من الإعلانات يجوز أن يضمه الفاصل
• rqddurs، وهو قائمة بمدد إعلانية محددة بدقة. وتقول المواصفة إنه مخصّص للبث التلفزيوني المباشر، «حيث تؤدي مدد الإعلانات غير الدقيقة إلى “فراغ في البث” غير مرغوب فيه»
• slotinpod، الذي يبيّن ما إذا كان البائع يستطيع ضمان الموضع الأول أو الأخير، وpodseq، أي موقع الفاصل في البرنامج
• mincpmpersec، وهو حد أدنى للسعر لكل ثانية من وقت الإعلان في الجزء الديناميكي من الفاصل

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

أرسل نطاق المعلن (adomain) ومعرّف المادة الإعلانية (crid) مع كل مزايدة. فالمواصفة تُدرج كليهما ضمن السمات المستخدمة «لفحوص جودة الإعلانات أو لفرض قيود الناشر».

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

ما الذي يجب أن تتضمنه استجابة VAST؟

تُسلَّم إعلانات الفيديو عبر VAST، الذي تصفه IAB Tech Lab بأنه «مخطط XML موحّد لتقديم الإعلانات إلى مشغّلات الفيديو الرقمية». وتذكر صفحتها الخاصة بـ VAST، التي حُدّثت آخر مرة في يوليو 2024، أن VAST 4.3 الصادر في ديسمبر 2022 هو أحدث إصدار. ويضم مستودع VAST 4.x التابع لـ IAB Tech Lab على GitHub أيضًا VAST 4.4، الذي تصفه ملاحظة لأحد القائمين على المستودع هناك بأنه صدر في 22 يوليو 2026. ويضيف VAST 4.4 صيغًا لـ CTV مثل إعلانات الإيقاف المؤقت وإعلانات شاشة التوقف. والاقتباسات الواردة أدناه مأخوذة من VAST 4.3.

وفي يوليو 2024، نشرت IAB Tech Lab أيضًا ملحقًا خاصًا بـ CTV ينقل معرّف المادة الإعلانية وملف mezzanine من VAST 4 إلى الإصدارين الأقدم VAST 2 و3. ويقول الملحق إن هذين الإصدارين السابقين «لا يزالان يهيمنان على السوق اليوم».

جزءان من VAST هما الأهم على التلفزيون:

• ملف mezzanine، أي «ملف الفيديو الخام عالي الجودة» الذي تصنع منه أنظمة الناشر نسخةً لكل شاشة. ويقول VAST 4.3 إن ملف mezzanine «مطلوب في عمليات التنفيذ التي تُدمج فيها الإعلانات»، وإن خدمة الدمج قد ترفض استجابةً لا تتضمنه
• معرّف UniversalAdId، وهو معرّف يبقى مع المادة الإعلانية من نظام إلى آخر. ويشترطه VAST 4.3 للإعلانات الخطية، أي الإعلانات التي تُعرض داخل البرنامج، ويضيفه الملحق إلى VAST 2 و3 بوصفه امتدادًا. وتستخدمه خدمات الدمج لمعرفة ما إذا كانت قد حوّلت مادة إعلانية ما من قبل

في عملية الدمج التي يصفها VAST 4.3، يجب أن تُحوَّل المادة الإعلانية التي لم ترها الخدمة من قبل حتى يمكن عرضها، لذا يعرض الفاصل إعلانًا آخر مكانها. ويلاحظ VAST 4.3 أن التنزيل الأول لملف mezzanine «قد يستغرق عدة ساعات». وتصف AWS القاعدة نفسها لـ MediaTailor، خدمتها السحابية التي تدمج الإعلانات في البث: «إذا لم يكن الإعلان قد حُوِّل ترميزه بعدُ ليطابق المحتوى، فإن MediaTailor سيتخطى إدراجه»، ويُجهَّز الإعلان للطلب التالي.

لذلك قد تفوّت المادة الإعلانية الجديدة فرصها الأولى للعرض لدى كل خدمة دمج. ويقول VAST 4.3 إن المادة الإعلانية التي تتغير بأي شكل ينبغي أن تحصل على معرّف جديد. فلا تغيّر المعرّف ما دامت المادة الإعلانية نفسها لم تتغير، كي تحوّلها كل خدمة دمج مرة واحدة فقط.

أما كود التحقق، فيوصي VAST 4.3 بـ Open Measurement (OMID)، ويوصي «بشدة بعدم استخدام VPAID»، وهو الطريقة الأقدم لتشغيل الكود داخل إعلان فيديو. ويسمّي SIMID بديلًا لـ VPAID في الإعلانات التفاعلية. ويفصل VAST 4.3 الكود التفاعلي عن ملف الفيديو، كي تتمكن المشغّلات التي تعمل مع خدمة دمج من تشغيل الفيديو حين لا تستطيع تشغيل الكود. فتأكد من أن كل مادة إعلانية للتلفزيون تعمل بوصفها فيديو عاديًا.

ما الذي يتغير حين يدمج خادمٌ الإعلانَ في البث؟

كثير من تطبيقات التلفزيون لا تستطيع طلب الإعلانات وتتبّعها كما يفعل المتصفح. ويصف VAST 4.3 البديل، ويُسمّى إدراج الإعلانات من جانب الخادم (SSAI) أو دمج الإعلانات (ad stitching). فالتطبيق يطلب البث من خدمة الدمج، والخدمة تطلب الإعلانات من خادم الإعلانات، ثم تُدمج الإعلانات في المحتوى كي يحصل المشاهد على «بث واحد متصل».

يضيف OpenRTB 2.6 إلى كائن الظهور حقلًا اسمه ssai يبيّن مقدار ما يجري على الخادم من الدمج والتتبع. وتمتد قيمه من «كله من جانب العميل» إلى «كله من جانب الخادم». وفي الحالة الوسطى، يُدمج الفيديو على الخادم ويُطلق الجهاز بكسلات التتبع. والقيمة الافتراضية، 0، تعني أن الحالة غير معروفة، لذا فالطلب الذي يخلو من هذا الحقل لا يخبرك بشيء في أي من الاتجاهين.

حين تأتي طلبات الإعلانات واستدعاءات التتبع من خادم، يبدو كأن كثيرًا من المشاهدين يتشاركون عنوان IP واحدًا. ويحذّر VAST 4.3: «بالنسبة إلى خادم إعلانات يتلقى معلومات التتبع، تبدو التقارير شبيهة بالزيارات غير الصالحة». ويقول إن مزوّدي خدمات الدمج يجب أن يرسلوا عنوان IP الخاص بالجهاز ووكيل المستخدم في ترويستين، X-Device-IP وX-Device-User-Agent، مع طلبات التتبع الخاصة بهم، وإن هذه القيم يجب أن تطابق القيم الواردة في طلب الإعلان الأصلي.

ويعني هذا لمنصتك ما يلي:

• حين تأتي الحركة عبر خدمة دمج، خذ بيانات الجهاز من هذه الترويسات ومن طلب المزايدة. فعنوان IP الذي يتصل بك يعود عندئذٍ إلى خدمة الدمج، لذا لا تستخدمه عنوانًا للجهاز
• اسأل البائع عن أي حركة من جانب الخادم تصل دون ترويسات X-Device
• تحقّق من أن البائع مُدرج في ملف app-ads.txt لدى الناشر. فمواصفة IAB Tech Lab توسّع ads.txt ليشمل التطبيقات القادمة من «متاجر تطبيقات التلفزيون المتصل»
• ابنِ حدود التكرار وشرائح الجمهور على معرّفات الأجهزة. فـ VAST 4.3 يلاحظ أن خدمة الدمج «لا تستطيع الوصول إلى ملفات تعريف الارتباط». وفي OpenRTB 2.6، يحمل الحقل ifa معرّفًا إعلانيًا يُتوقع أن يأتي من نظام تشغيل الجهاز، ويبيّن الحقل lmt متى يجب تقييد التتبع

كيف تُعدّ مرات الظهور وتُفوتَر؟

تقارن ملاحظات التنفيذ الخاصة بـ OpenRTB بين طرق عدّ الأحداث القابلة للفوترة. وتوصي للصوت والفيديو بحدث الظهور في VAST. أما عنوان URL لإشعار الفوترة (burl)، الذي يعمل جيدًا مع إعلانات البانر، فهو «غير موصى به للصوت/الفيديو».

وتنصح الملاحظات المزايدين أيضًا بتتبّع التأخير بين المزاد وإشعار الفوترة، لأن أهداف الإنفاق وحدود التكرار وضبط الوتيرة تعتمد عليه. وفي جدولها للتأخيرات المعقولة، يرد في صف الصوت أو الفيديو مع الدمج من جانب الخادم: «طويل جدًا أو غير معروف».

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

لم يغيّر الدمج من جانب الخادم قواعد العدّ. فـ VAST 4.3 يقتبس إرشادات القياس الصادرة عن IAB، والتي وُضعت بالتعاون مع مجلس تصنيف وسائل الإعلام (MRC): «تشترط إرشادات القياس أن يعتمد عدّ الإعلانات نهجًا يبدأ من جانب العميل». ويسمح المقطع نفسه بالعدّ على الخادم «ما دام يبدأ بناءً على أحداث وأصول قياس من جانب العميل». ويرفض العدّ الذي يبدؤه الخادم من تلقاء نفسه، لأنه «الأبعد عن رؤية المستخدم للإعلان فعليًا». فاسأل كل بائع عن الحدث الذي يبدأ عنده عدّ مرات الظهور لديه حين يدمج خادمٌ الإعلان.

ما الذي تبنيه بنفسك، وما الذي يتولاه الشركاء أصلًا؟

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

أما الأجزاء الأخرى فهي التي تحدد ما تكسبه منصتك، وهذه تستحق أن تبنيها بنفسك:

• في DSP: اختيار الإعلانات التي تتسع للفاصل وتسعيرها بالثانية
• في DSP: ضبط وتيرة إنفاق الميزانيات حين تتأخر إشعارات الفوترة
• في DSP: تقديم المواد الإعلانية مع ملف mezzanine ومعرّف مادة إعلانية لا يتغير إلا حين تتغير المادة نفسها، في العنصر UniversalAdId من VAST 4 أو في امتداد الملحق لـ VAST 2 و3
• في SSP: بناء كل فاصل من مزايدات عدة مشترين، وتطبيق قواعد الناشر بشأن المعلنين الذين يجوز أن يظهروا
• في SSP: تمرير حقول الحزمة الإعلانية وقيمة ssai إلى كل مشترٍ
• في كلتيهما: قراءة بيانات الجهاز من ترويسات X-Device، وتصفية الزيارات غير الصالحة الواردة من جانب الخادم
• في كلتيهما: عدّ مرات الظهور بطريقة يقبلها المشترون والمدققون

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

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

ماذا نسأل الشركة التي تضيف CTV إلى منصتنا؟

• أي حقول الحزم الإعلانية في OpenRTB 2.6 سيقرأها النظام، وكيف يختار الإعلانات لفاصل ديناميكي؟
• كيف يسعّر النظام المزايدات بالثانية، وهل يلتزم بـ mincpmpersec؟
• أي إصدارات VAST ستستخدمها موادنا الإعلانية، ومن أين تأتي ملفات mezzanine؟
• هل ستحمل موادنا الإعلانية معرّفات UniversalAdId مسجّلة، أم القيمة الافتراضية «unknown»؟
• كيف يتعامل النظام مع الحركة الواردة من جانب الخادم، ومن أين يأخذ عنوان IP الخاص بالجهاز ووكيل المستخدم؟
• كيف تُعدّ مرات الظهور لكل بائع؟
• كيف يبقى ضبط الوتيرة دقيقًا حين تصل إشعارات الفوترة متأخرة جدًا؟
• مع أي الشركاء سنختبر أولًا، وأي الميزات يمكن أن تنتظر؟

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

في مجال AdTech، تعمل amBrain على تطوير DSP ومنصات المزايدة الفورية وهندسة منصات تبادل الإعلانات. ويرد في قائمة خدماتها سطران نصّهما: «تبني amBrain منصات جانب العرض (SSP) للناشرين» و«تبني amBrain خوادم الإعلانات: الاستهداف، وتحديد تكرار الظهور، والتقارير». وRTBBidder منصة جانب طلب بنتها amBrain لأحد العملاء.

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

هذه المقالة ليست دراسة حالة. وفيما عدا ذكر RTBBidder، لا تصف أي عمل لعميل: فهي لا تقول إن amBrain أضافت التلفزيون المتصل إلى أي منصة، ولا تقدّم أي أرقام عن RTBBidder، ولا أسعارًا أو جداول زمنية لـ amBrain. والاقتباسات من IAB Tech Lab وAWS مأخوذة من وثائقهما الخاصة، ولا تدّعي المقالة أي علاقة بين amBrain وأيٍّ منهما. وإن كانت amBrain في قائمتك المختصرة، فاطرح عليها الأسئلة نفسها التي تطرحها على أي شركة أخرى.