طلب العطاء

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

ما بداخل طلب العطاء#

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

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

لماذا تهم طلبات العطاء المشترين#

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

هذا أيضًا هو المكان الذي يتم فيه تصفية الاحتيال أو تسربه. طلب العطاء الذي يدعي تمثيل مخزون ناشر متميز، دون سجلات ads.txt أو sellers.json المصاحبة لدعم هذا الادعاء، هو بالضبط نوع الإشارة التي تستخدمها منصات الشراء DSP والمشترون لرفض المخزون المزيف أو الممثل بشكل خاطئ قبل تقديم عرض عليه.

قراءة حجم طلبات العطاء كإشارة سوقية#

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

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

هل يرى كل منصة شراء DSP نفس طلب العطاء؟

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

ما مدى السرعة التي يجب أن تستجيب بها منصة الشراء DSP لطلب العطاء؟

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

هل يتم دائمًا تضمين بيانات المستخدم في طلب العطاء؟

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

ماذا يحدث إذا كان طلب العطاء يفتقد بيانات سلسلة التوريد؟

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