توسّط إعلانات الجوال لتطبيقاتك أو لشبكتك الإعلانية: استخدام منصة توسّط، أم ترخيص منتج توسّط، أم بناء نظامك الخاص

توسّط الإعلانات (ad mediation) كودٌ داخل التطبيق يطلب إعلانًا من عدة مصادر إعلانات في كل مرة تتوفر فيها لدى التطبيق مساحة إعلانية شاغرة. ثم يحاول أن يعرض الإعلان الذي يدفع أكثر. ومصدر الإعلانات هو أي شبكة أو منصة تبادل تستطيع توفير الإعلانات. ويمكن لناشر التطبيقات أو للشبكة الإعلانية العاملة داخل التطبيقات استخدام منصة جاهزة مثل Google AdMob أو AppLovin MAX أو Unity LevelPlay. ويمكن أيضًا الحصول على ترخيص منتج من مورّد وتشغيله تحت العلامة التجارية الخاصة (white-label)، أو بناء طبقة توسّط خاصة. ويتوقف الاختيار في الغالب على ما تحتاج إلى امتلاكه. ويتوقف أيضًا على قدرة فريقك على إبقاء SDK، أي حزمة الكود التي تعرض الإعلانات، محدَّثةً في كل تطبيق.

ما الذي يفعله التوسّط داخل التطبيق؟

يعرض التطبيق الإعلانات عبر SDK (حزمة تطوير البرمجيات)، وهي حزمة من الكود يضيفها المطوّرون إلى التطبيق. ومع التوسّط، تتولى حزمة SDK واحدة زمام الأمر. فهي تستدعي عدة مصادر إعلانات عبر المحوّلات (adapters)، وهي أجزاء صغيرة من الكود تربطها بحزمة SDK الخاصة بكل شبكة.

ويصوغ مركز مساعدة AdMob لدى Google الأمر هكذا: «يتيح لك التوسّط إدارة مصادر الإعلانات المستخدمة لعرض الإعلانات في تطبيقاتك، كلها من مكان واحد». وتصف Unity منصة LevelPlay بأنها «حل لتحقيق الدخل يتيح لمطوّري التطبيقات إدارة شبكات إعلانية متعددة وتحسين أدائها بحزمة SDK واحدة فقط». وقد جرى الاطلاع على جميع المصادر في هذه المقالة في 6 نوفمبر 2026.

ما الفرق بين الشلال والمزايدة داخل التطبيق؟

الشلال (waterfall) هو الطريقة الأقدم. يرتّب الناشر مصادر الإعلانات بحسب eCPM، أي الإيراد لكل ألف إعلان معروض، وتسألها حزمة SDK واحدًا تلو الآخر إلى أن يعيد أحدها إعلانًا. ويقول دليل AdMob: «يستدعي التوسّط عبر الشلال مصادر الإعلانات واحدًا تلو الآخر بناءً على متوسط eCPM الذي تحدّده أنت، لا على ما يرغب مصدر الإعلانات في دفعه».

أما المزايدة داخل التطبيق (in-app bidding) فتسأل جميع مصادر المزايدة في اللحظة نفسها، فيحدد كل منها سعرًا لهذا الإعلان بعينه. ويقول الدليل نفسه: «تقدّم مصادر المزايدة مزايداتها في الوقت الفعلي وتتنافس في مزاد واحد، بينما تُستدعى مصادر الشلال كلٌّ على حدة بترتيب eCPM الخاص بها، الذي تحدّده أنت».

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

تصف AppLovin المزاد في MAX بأنه مزاد «بالسعر الأول» (first-price)، أي أن الفائز يدفع ما زايد به. وتصل المزايدات «عبر بروتوكول OpenRTB 2.5». وOpenRTB هو معيار طلبات المزايدة الصادر عن IAB Tech Lab، وهي هيئة غير ربحية تضع المعايير التقنية للإعلان الرقمي. ويجب أن تصل المزايدات خلال مهلة زمنية تُسمّى tmax، ثم «يدمج خادم مزاد MAX هذه المزايدات مع مصادر الطلب غير المزايِدة في شلال الناشر».

ما الطرق الثلاث لتشغيل التوسّط؟

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

ويمكن الجمع بين المسارات. فـ Prebid Mobile، الذي تصفه Prebid.org بأنه «مكتبة مفتوحة المصدر لـ iOS وAndroid»، يُدرج AdMob وMAX ضمن منصات التوسّط التي يدعمها. ويحصل على مزايداته من Prebid Server، الذي تشرحه المقالة عن بناء منصة جانب العرض (SSP) الخاصة بك. وSSP هي النظام الذي يعرض المساحات الإعلانية للناشر على المشترين.

متى تكفي منصة توسّط جاهزة؟

استخدم منصة جاهزة حين ينطبق معظم ما يلي:

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

وفي المقابل، تقبل قواعد المنصة. فهي تقرر كيف يعمل المزاد وأيّ المزايدين يستطيعون الانضمام إليه، وتتغير حزمة SDK الخاصة بها وفق جدولها هي. وقد تبيع الشركة التي تدير المزاد إعلانات فيه أيضًا. وفي 6 نوفمبر 2026، كانت صفحة MAX لدى AppLovin تقول: «تتنافس كل شبكة، بما فيها AppLovin، على قدم المساواة في المزاد الموحّد». فقارن ادعاء المورّد هذا ببيانات إيراداتك أنت مصنّفةً حسب مصدر الإعلانات.

ومع ذلك تستطيع الشبكة الإعلانية الوصول إلى الناشرين العاملين على منصة جاهزة: فـ AdMob توفّر الأحداث المخصّصة (custom events)، التي تتيح للناشر إضافة «مصدر إعلانات لا يدعمه AdMob Mediation».

متى يكون المنتج المرخَّص أو منتج white-label خيارًا منطقيًا؟

تُعرض حِزم SDK للتوسّط بنظام white-label على الشركات التي تدير منصة إعلانية، مثل شبكة إعلانية تعمل داخل التطبيقات، أو SSP تريد أن يرسل الناشرون طلبات الإعلانات إليها مباشرةً. واختر واحدة منها حين:

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

وتبيّن Teqblaze، وهي مورّد في مجال AdTech، كيف تُوصف هذه المنتجات. فصفحة SDK لديها تسمّي العرض «حزمة تطوير برمجيات تحمل علامتك التجارية»، وتقول إنه «مبني للشركات التي تريد التحكم في تحقيق الدخل من إعلانات الجوال دون تطوير SDK من الصفر». ويقول منشور على مدونتها في يونيو 2024 إن الناشرين يستطيعون «إرسال الطلبات مباشرةً إلى منصة حل white-label». ولا تعرض صفحة SDK أي أسعار. وهذه ادعاءات المورّد نفسه.

العلامة التجارية لك، أما الكود فيبقى للمورّد. وXcode أداة Apple لبناء التطبيقات. وحين يعتمد تطبيق إصدارًا جديدًا من حزمة SDK تابعة لطرف ثالث، تتحقق Xcode من «أنها موقّعة من المطوّر نفسه»، لذا اسأل عن الجهة التي تحمل حزمة SDK لديك توقيعها. وإذا توقف المورّد عن تحديث حزمة SDK، فعلى كل ناشر أن يُصدر تحديثًا لتطبيقه كي ينتقل عنها.

متى يستحق بناء طبقة التوسّط الخاصة بك العناء؟

ابنِ بورصتك حين ينطبق واحد على الأقل مما يلي:

• التوسّط هو ما تبيعه، كأن تكون شبكة إعلانية تدير مزادات في تطبيقات ناشرين كثيرين
• تحتاج إلى قواعد لا تستطيع المنصات التي اختبرتها تطبيقها، مثل أسعارك الدنيا الخاصة لكل مجموعة من المستخدمين. والسعر الأدنى (floor price) هو أدنى مزايدة تقبلها.
• صارت الرسوم وحصص الإيرادات تكلّف أكثر مما سيكلّفه فريق يشغّل نظامك الخاص
• يجب أن تبقى البيانات الخام لكل ظهور (أي عرض إعلان واحد مرة واحدة) في أنظمتك الخاصة

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

ما الذي نملكه في كل مسار؟

تحقّق من أربعة أمور قبل أن توقّع أو تبدأ البناء.

• بيانات الظهور والإيرادات. تُبلغ المنصات الثلاث كلها عن الإيراد لكل ظهور، واثنتان منها تحتفظان به مدة محدودة. فحزمة SDK من AdMob تُبلغ عنه «عند حدوث ظهور»، وتعليق في الكود النموذجي من Google يقول بإرساله إلى «خادم التحليلات المفضّل لديك مباشرةً ضمن دالة الاستدعاء هذه (callback)». وواجهة User-Level Ad Revenue API لدى AppLovin، أي الواجهة التي تُسحب بها تلك البيانات، «لها نافذة طلب مدتها 45 يومًا». وتُبقي Unity بيانات LevelPlay على مستوى الظهور لكل تاريخ «متاحةً لمدة 14 يومًا فقط». فانسخها إلى وحدة التخزين الخاصة بك كل يوم. ومع مورّد white-label، احصل كتابةً على ما يثبت أن السجلات الخام ملك لك وتستطيع تصديرها في أي وقت.
• العلاقات مع مصادر الإعلانات. تقول صفحة الإعداد لدى Unity: «يجب أن يكون لديك حساب نشط لدى هذه الشبكة لعرض مخزونها الإعلاني في تطبيقك». وفي MAX، يرسل المزايدون مزايداتهم إلى خادم المزاد لدى AppLovin. فاسأل كل منصة أي الاتصالات تبقى لك إن غادرت. ومع منتج white-label، تحقّق من الاسم الوارد على العقود مع المشترين. أما إن بنيت نظامك الخاص، فأنت من يوقّع كل عقد منها.
• حزمة SDK في تطبيقاتك. تملك المنصة حزمة SDK الخاصة بها وتحديثاتها، ويملك مورّد white-label الكود الخاص به. وإن بنيت نظامك، يمكن أن يكون الكود لك، ومعه كل تحديث وكل ملف خصوصية.
• تكلفة الانتقال. تقول إرشادات مراجعة App Store لدى Apple إن التطبيقات لا يجوز لها «تنزيل كود أو تثبيته أو تنفيذه يضيف ميزات التطبيق أو وظائفه أو يغيّرها». وتقول سياسة Google Play إن التطبيق «لا يجوز له تعديل نفسه أو استبدال نفسه أو تحديث نفسه بأي طريقة غير آلية التحديث في Google Play». فحزمة SDK الجديدة للتوسّط لا تصل إلى الناس إلا في إصدار جديد من التطبيق، ومن لا يحدّث تطبيقه يبقى على الإصدار القديم.

وبعض التغييرات لا يحتاج إلى تحديث للتطبيق. فترتيب الشلال وإعدادات المزايدة موجودة في لوحة التحكم الخاصة بالمنصة. وملف app-ads.txt، الذي يُدرج كل شركة مسموح لها ببيع المساحة الإعلانية للناشر، موجود على الموقع الإلكتروني للمطوّر. وتذكّر AdMob الناشرين: «إن كنت تستخدم شبكة إعلانية أخرى، فتذكّر إضافة تلك الشبكة إلى ملف app-ads.txt لديك».

ما الالتزامات المتعلقة بمتاجر التطبيقات والخصوصية التي تأتي مع أي حزمة SDK إعلانية؟

تنطبق هذه الالتزامات في كل مسار. تقول Apple: «المطوّرون مسؤولون عن كل الكود المضمَّن في تطبيقاتهم». وهذا ما تقوله صفحات Apple وGoogle نفسها:

• App Tracking Transparency (ATT). على iOS، تقول Apple: «عليك الحصول على إذن المستخدم عبر إطار App Tracking Transparency (ATT) لكي تتتبّعه أو تصل إلى المعرّف الإعلاني لجهازه». وتعرّف Apple التتبّع بأنه ربط بيانات من تطبيقك ببيانات من تطبيقات شركات أخرى أو مواقعها الإلكترونية أو ممتلكاتها خارج الإنترنت «لأغراض الإعلان الموجَّه أو قياس الإعلانات». ويُعدّ تتبّعًا أيضًا مشاركةُ بيانات المستخدم أو الجهاز مع وسطاء البيانات.
• AdAttributionKit وSKAdNetwork. يُبلغ هذان الإطاران من Apple عن الإعلانات التي أدّت إلى تثبيت التطبيقات. وتقول صفحة SKAdNetwork لدى Apple الآن: «استخدم AdAttributionKit لحملات إعلانات التطبيقات على App Store وفي متاجر التطبيقات البديلة». أما الشبكات الإعلانية فإنها «تسجّل لدى Apple للحصول على معرّف شبكة إعلانية». وتقول Apple أيضًا: «لا تكون مؤهَّلة للتحقق من التثبيت إلا الإعلانات الصادرة عن شبكات إعلانية لها إدخال في قائمة خصائص المعلومات (Information Property List) الخاصة بالتطبيق». وهذه القائمة تأتي مضمَّنة في التطبيق نفسه، لذا فإن أي شبكة جديدة تعني إصدارًا جديدًا من التطبيق.
• ملفات بيان الخصوصية والتواقيع. بيان الخصوصية (privacy manifest) ملف يذكر فيه التطبيق أو حزمة SDK البيانات التي يجمعها وسبب جمعها. وتُدرج Apple حِزم SDK معيّنة بأسمائها. وحين تقدّم تطبيقًا يحتوي على إحداها، يجب أن تُرفق بيان الخصوصية الخاص بها. وإذا كانت حزمة SDK مضافة كملف ثنائي (binary)، أي كود مبني جاهز لا كود مصدري، فيجب أن تُرفق توقيعها أيضًا. أما حِزم SDK الأخرى، فتطلب Apple من مطوّريها إرفاق بيان إذا كانت الحزمة، ضمن حالات أخرى، «تجمع بيانات عن الشخص الذي يستخدم التطبيقات التي تتضمن SDK الطرف الثالث» أو «تتصل بنطاقات تتبّع».
• نماذج الخصوصية في المتاجر. تطلب Apple معلومات عن ممارساتك المتعلقة بالخصوصية «بما في ذلك ممارسات الشركاء من الأطراف الثالثة الذين تدمج كودهم في تطبيقك»، وتذكر الشبكات الإعلانية بين هؤلاء الشركاء. وتقول Google: «يجب على جميع المطوّرين الذين لديهم تطبيق منشور على Google Play إكمال نموذج أمان البيانات (Data safety)». ويغطي النموذج البيانات «التي تُجمع وتُعالَج عبر أي مكتبات أو حِزم SDK تابعة لأطراف ثالثة تُستخدم في تطبيقاتهم».
• التطبيقات الموجّهة إلى الأطفال. تقول Google Play: «إذا كنت تعرض إعلانات في تطبيقك وكان جمهورك المستهدف يقتصر على الأطفال، فيجب ألا تستخدم إلا إصدارات حِزم SDK الإعلانية المعتمدة ذاتيًا ضمن برنامج Families». أما التطبيقات الموجّهة إلى الأطفال والمستخدمين الأكبر سنًا معًا فيجب أن تتحقق من العمر، مثلًا عبر شاشة محايدة تسأل عن العمر دون أن توحي بإجابة. ولا يجوز لهذه التطبيقات أن تعرض على الأطفال إعلانات إلا من إصدارات حِزم SDK الإعلانية المعتمدة ذاتيًا. وتشترط Google أن «تعتمد حِزم SDK الإعلانية ومنصات التوسّط ذاتيًا ملاءمتها للأطفال». وتقول AdMob إن مصادر المزايدة لديها «لا تدعم عرض الإعلانات في التطبيقات الموجّهة إلى الأطفال أو في طلبات الإعلانات الموجّهة إليهم». وتقول Apple إن تطبيقات فئة الأطفال (Kids Category) «ينبغي ألا تتضمن تحليلات من أطراف ثالثة أو إعلانات من أطراف ثالثة». وتضيف أن الإعلانات السياقية من أطراف ثالثة، أي الإعلانات التي تُختار بحسب ما يعرضه التطبيق لا بحسب بيانات عن المستخدم، «قد يُسمح بها أيضًا في حالات محدودة».

تتغير سياسات المتاجر، ويختلف قانون الخصوصية من بلد إلى آخر. فتحقّق من هذه النقاط مع محامٍ قبل أن تضيف حزمة SDK إعلانية أو تغيّرها، ولا سيما في التطبيقات التي يستخدمها الأطفال.

كيف نتحقق من قابلية الرؤية والزيارات غير الصالحة؟

قابلية الرؤية (viewability) تعني ما إذا كان الإعلان قد ظهر على الشاشة في موضع يستطيع فيه شخص أن يراه. وتتيح Open Measurement SDK (OM SDK) من IAB Tech Lab لشركات القياس الخارجية التحقق من الإعلانات داخل التطبيقات. وتقول IAB Tech Lab إنها «تؤكّد متى تظهر الإعلانات على الشاشة، ونسبة ما يظهر منها، ومدة ظهورها»، و«تسهّل تحقق الأطراف الثالثة من الزيارات غير الصالحة ومن متطلبات العلامات التجارية».

على المنصة الجاهزة، اسأل أيّ مصادر الإعلانات لديك تدعم OM SDK. أما على حزمة SDK الخاصة بك، فتدمجها بنفسك، وتقدّم IAB Tech Lab شهادة «تتحقق من أن تنفيذك لـ OM SDK يعمل مع مزوّدي القياس».

الزيارات غير الصالحة هي مشاهدات الإعلانات والنقرات التي لا تأتي من اهتمام حقيقي لدى المستخدم. ويقول مركز مساعدة AdMob إنها «تشمل الزيارات الاحتيالية المتعمَّدة وكذلك النقرات العَرَضية». وتشرح مقالتان سابقتان كيف تصفّي منصة الإعلانات هذه الزيارات، ولماذا تتباعد أرقام مجموعتين من التقارير.

كم يكلّف كل مسار؟

تتوقف الأسعار على المورّد وحجم عملك، لذا قارن طريقة احتساب تكلفة كل مسار:

• المنصة الجاهزة: تحقّق من الطريقة التي تكسب بها المنصة أموالها. ففي 6 نوفمبر 2026، كانت صفحة MAX لدى AppLovin تقول: «التوسّط في Max مجاني للناشرين. وتدفع شبكات المزايدة لـ AppLovin رسمًا على إيرادات الإعلانات المحقَّقة». ولم تذكر مقدار هذا الرسم، ولم تذكر صفحات AdMob وLevelPlay التي جرى الاطلاع عليها لهذه المقالة أي رسم للتوسّط. فاسأل عمّا يُقتطع بين مزايدة المعلن والمبلغ الذي تتقاضاه أنت، ومن يقتطعه.
• منتج white-label: رسم إعداد أو ترخيص، أو رسم شهري، أو حصة من الإيرادات، أو مزيج منها. واسأل على أي أساس تُحتسب الحصة.
• نظام تبنيه لنفسك: مهندسون لحزمة SDK والمحوّلات وخادم المزاد. وبعد الإطلاق تأتي تكاليف الخوادم وحركة البيانات التي تنمو مع طلبات الإعلانات، والموظفين المناوبين، وشهادة OM SDK، وتحديثات المحوّلات.
• كل المسارات: وقت المطوّرين لاختبار كل تحديث لحزمة SDK قبل إصدار التطبيق، والمراجعة القانونية لإفصاحاتك عن الخصوصية.

ويكلّف البناء أكثر ما يكلّف قبل عرض أول إعلان، بينما تكبر حصص الإيرادات مع كل إعلان تبيعه.

ماذا نسأل شركة تعرض أن تبني لنا التوسّط أو تدمجه؟

• كيف ستصل بيانات الإيرادات الخام لكل ظهور إلى وحدة التخزين الخاصة بنا، وكيف ستطابقونها مع تقارير كل شبكة؟
• أي الشبكات الإعلانية ستكون لها محوّلات عند الإطلاق، ومن يحدّث كل محوّل حين تُصدر شبكة حزمة SDK جديدة؟
• كيف ستتصرف حزمة SDK على iOS حين يرفض الشخص التتبّع، وماذا سيُعلن بيان الخصوصية الخاص بها؟
• من يوقّع حزمة SDK، وتحت أي اسم سيراها الناشرون ومتاجر التطبيقات؟
• هل ستدعم حزمة SDK معيار OM SDK، ومن سيتولى الحصول لها على شهادة IAB Tech Lab؟
• كيف ستلتزم الإعلانات الموجّهة إلى الأطفال وإلى المستخدمين غير المعروفة أعمارهم بسياسة Families في Google Play؟
• هل تستطيعون عرض ذلك عمليًا في تطبيق منشور في المتاجر اليوم؟

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

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

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

هذه المقالة ليست دراسة حالة، ولا تصف أي عمل لعميل. فسطور amBrain أعلاه لا تذكر منصة توسّط، ولا حزمة SDK لإعلانات الجوال، ولا محوّلًا لأي شبكة إعلانية. ولا تذكر المقالة كذلك أسعارًا أو جداول زمنية لـ amBrain. والاقتباسات من Google وAppLovin وUnity وTeqblaze وPrebid.org وApple وIAB Tech Lab مأخوذة من صفحاتها الخاصة. ولا توصي المقالة بأي منها، ولا تدّعي أي علاقة بأي منها.

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