لماذا لا تطابق تقارير الإعلانات سجلات المزايد، ومن يستطيع إعادة بناء خط الأحداث

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

ماذا يعني ألا تطابق تقارير الإعلانات سجلات المزايد؟

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

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

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

كيف نميّز الأحداث الضائعة من الأحداث المعدودة بقواعد مختلفة؟

طابِق الجانبين حدثًا حدثًا. يمنح OpenRTB، بروتوكول المزايدة الفورية الصادر عن IAB Tech Lab، كل مزاد معرّفًا لطلب المزايدة تُسنده منصة التبادل، ويمنح كل ظهور في الطلب معرّفًا خاصًا به. ويستطيع مزايدك أن يطلب من منصة التبادل كتابة هذه المعرّفات في الإشعار الذي ترسله حين تفوز، وفي الإعلان نفسه. وعندها يحمل كل حدث ظهور المعرّفات نفسها التي في سجلات المزايد لديك.

ولا يكفي أيٌّ من المعرّفين وحده. فبموجب OpenRTB 2.6، تحدد كل منصة تبادل معرّفات طلباتها بنفسها، فلا شيء يمنع منصتي تبادل من استخدام المعرّف نفسه. ومعرّف الظهور فريد داخل طلبه فقط، ويبدأ عادةً من 1. لذا طابِق على ثلاث قيم معًا: منصة التبادل، ومعرّف الطلب، ومعرّف الظهور.

ثم أجرِ إعادة العدّ:

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

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

أين تضيع الأحداث عند ذروة الحركة؟

خذ خط أحداث مبنيًا على Kafka وClickHouse. يستقبل المُجمِّع (collector) كل حدث من المتصفح أو التطبيق ويكتبه إلى Kafka، وهو طابور رسائل. ويقرأ المُحمِّل (loader) من Kafka ويكتب الأحداث في دفعات إلى ClickHouse، وهي قاعدة البيانات التحليلية التي تقوم عليها تقاريرك. وعند الذروة، قد تختفي الأحداث عند كل خطوة:

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

اطلب من مهندسيك هذه السجلات من أكثر ساعات يوم سيئ ازدحامًا:

• الأخطاء وحالات انتهاء المهلة عند موازن الحمل وعند المُجمِّع، وعمليات الكتابة الفاشلة إلى Kafka في سجلات المُجمِّع
• تأخّر المستهلك (consumer lag)، أي مقدار تأخّر المُحمِّلات، وأي أحداث حذفها Kafka قبل أن تُقرأ لأنها انتظرت أطول من المدة التي يحتفظ فيها بالبيانات
• عمليات الكتابة الفاشلة إلى ClickHouse، مع رسائل الخطأ الخاصة بها
• عدد لكل ساعة عند كل خطوة: ما استقبله المُجمِّع، وما كُتب إلى Kafka، وما قرأه المُحمِّل، وما خُزّن في ClickHouse

السجل الأخير هو الذي يؤدي معظم العمل. فإن انخفض العدد عند خطوة ما في الذروة بينما صمد عند الخطوة التي قبلها، فقد ضاعت الأحداث بين هاتين الخطوتين.

هل نُصلح خط الأحداث، أم ننتقل إلى خدمة مُدارة، أم نعيد بناءه؟

أصلح خط الأحداث الحالي:

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

انتقل إلى خدمة مُدارة، مثل Amazon MSK لتشغيل Kafka أو ClickHouse Cloud لتشغيل ClickHouse، حيث يشغّل المزوّد الخوادم:

• متى يناسبك: حين يقضي مهندسوك في إبقاء خوادم Kafka وClickHouse تعمل وقتًا أطول مما يقضونه في منطق العدّ، ويأتي الفقد من نفاد سعة تلك الخوادم عند الذروة
• ما تدفعه: فاتورة شهرية تكبر مع حركتك. فكلتا الخدمتين تتقاضى رسومًا على الحوسبة والتخزين، وتُدرج ClickHouse Cloud نقل البيانات إلى الخارج وخدمة استيعاب البيانات الخاصة بها كبندين منفصلين، بحسب صفحات الأسعار لديهما التي جرى الاطلاع عليها في 7 أكتوبر 2026. وقدّر فاتورة أكثر أشهرك ازدحامًا، وتكلفة الانتقال إلى غيرها لاحقًا
• ما لا تصلحه: المُجمِّع والمُحمِّل اللذان ما زلت تشغّلهما، والتكرارات، والأحداث المتأخرة، والمطابقة مع سجلات المزايد لديك. فالخدمة تخزّن ما ترسله إليها ولا تعرف شيئًا عمّا عدّه مزايدك
• من يملك الكود: أنت، أما الخدمة فتعمل بشروط المزوّد

أعد بناء خط الأحداث:

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

أي الشركات تستطيع إعادة بناء خط أحداث إعلانية على Kafka وClickHouse؟

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

ماذا نسأل قبل أن نستعين بشركة؟

اطرح الأسئلة الخمسة نفسها على كل شركة في قائمتك.

كيف تزيلون التكرارات؟ انتبه في الجواب إلى ذِكر معرّف يحصل عليه كل حدث لحظة إنشائه، قبل أي إعادة محاولة، ويُبنى من معرّفات المزاد ونوع الحدث. ويزيل خط الأحداث التكرارات مرتين: مرة عند تخزين الأحداث، ومرة أخرى عندما تقرؤها التقارير. والمرور الثاني مهم لأن ClickHouse يزيل التكرارات في الخلفية في أوقات لا يمكنك التخطيط لها. ويقول توثيقه إن ذلك «لا يضمن غياب التكرارات».

كيف تتعاملون مع الأحداث التي تصل متأخرة؟ انتبه في الجواب إلى ذِكر مدة محددة لكل نوع حدث تظل الأرقام خلالها قابلة للتغيير، ونقطة تصبح بعدها نهائية. والحدث الذي يصل بعد ذلك ينبغي أن يُعدّ مع ذلك ويُعلَّم بأنه متأخر، لا أن يُرمى.

كيف تتحققون من أرقامكم مقابل سجلات المزايد لدينا وتقارير شركائنا؟ ابحث في الجواب عن إعادة عدّ يومية على معرّفات المزادات، وسبب مكتوب لكل فرق. واتفق على حجم فجوة يتولى عنده أحدٌ إثارة المسألة مع منصة التبادل.

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

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

ما العلامات التحذيرية؟

• تُقترح إعادة البناء قبل أن يُجري أحد إعادة العدّ أو يفتح سجلات المزايد لديك
• تَعِد الشركة بأن التقارير الجديدة ستطابق المزايد تمامًا
• الجواب الوحيد عن التكرارات وعدٌ بأن كل حدث يُسلَّم «مرة واحدة بالضبط» (exactly once)، دون أي كلمة عن التكرارات التي يُنشئها كودك أنت، مثل بكسل تتبّع ينطلق مرتين
• الدليل الوحيد اختبار حمل على أحداث مصطنعة، لا إعادة تشغيل لحركتك أنت

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

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

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

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

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

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

أسئلة شائعة

• هل ستتطابق تقاريرنا وسجلات المزايد يومًا بنسبة 100 في المئة؟ لا. فبحسب OpenRTB، فإن رسالة منصة التبادل التي تبلغك بفوزك «لا تدل بالضرورة على إعلان سُلِّم أو شوهد أو يمكن فوترته»، كما أن بعض الأحداث تُستبعد بالترشيح بوصفها حركة روبوتات. واجعل هدفك فجوة مستقرة لكل جزء منها سبب مكتوب، واتفق مع كل شريك على العدّ الذي تفوتر على أساسه
• هل علينا استخدام Kafka وClickHouse؟ لا. فطوابير أخرى وقواعد بيانات تحليلية أخرى تستطيع أداء العمل نفسه، وإعادة العدّ والأسئلة الخمسة تنطبق على أيٍّ منها
• كيف نُبقي التقارير القديمة تعمل أثناء بناء خط أحداث جديد؟ غذِّ الخطين بالأحداث نفسها، وقارن كلًّا منهما بسجلات المزايد كل يوم. وانقل التقارير التي تفوتر على أساسها في النهاية، بعد دورة فوترة كاملة يُشرح فيها كل فرق