تحقيق الدخل مع شريك إدارة الإعلانات

عزيزي المجتمع،

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

باستخدام إضافة الإعلانات (Ad Plugin)، يمكنك تقديم الإعلانات عبر الشبكات/خوادم الإعلانات التالية:

Google AdSense 565

DoubleClick for Publishers (DFP) (المعروف أيضًا باسم Google Ad Manager 145)، بما في ذلك الاستهداف المخصص

Google Double Click for Publishers 89

Amazon Affiliates 137 - إعلانات اللافتات وروابط المنتجات

Carbon Ads 140

المشكلة: الاختيار لا يغطي الإمكانات الكاملة لتحقيق الدخل بأي حال من الأحوال. هذا ليس المقصود منه انتقاد الإضافة؛ أود أن أبدأ مناقشة حول تحقيق الدخل من مواقع الويب باستخدام Discourse وأشرح لماذا من المنطقي استخدام نصوص برمجية لطرف ثالث من شبكات الإعلانات مثل Mediavine (سوق الولايات المتحدة) أو Symplr (سوق ألمانيا).

لماذا هذا مهم؟:

شبكات الإعلانات متصلة بمجموعة متنوعة من منصات جانب العرض (SSPs). يتم طلبها للمزاد جنبًا إلى جنب مع Google ويمكنها تقديم عروض. هذا يزيد من المنافسة وضغط الإعلانات على Google، مما يؤدي في النهاية إلى سعر أعلى لكل ألف اتصال (TKP) وإيرادات أكبر مما هو عليه مع Google AdSense أو Google AdManager فقط.

ميزة للناشر:

إيرادات أكبر بسبب زيادة المنافسة وضغط الإعلانات على Google.

العقبات التقنية:

يتطلب تحقيق الدخل من تطبيقات الصفحة الواحدة جهدًا تقنيًا إضافيًا.

لا يمكن لإضافة الإعلانات تنفيذ منطق مخصص بسهولة لكل شريك تسويقي/شريك في تكنولوجيا الإعلانات.

حل ممكن:

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

السؤال: هل هذه الميزة متاحة بالفعل؟

لماذا تحتاج شبكات الإعلانات إلى تنفيذ نصوصها البرمجية المخصصة؟:

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

ميزة لمستخدم Discourse من خلال استخدام شريك في تكنولوجيا الإعلانات:

يمكن للناشر التركيز على إنشاء محتواه بينما يتولى شركاء AdTech التنفيذ الفني لتوصيل إعلانات محسّنة.

أتطلع إلى آرائكم واقتراحاتكم حول هذا الموضوع!

إعجابَين (2)

كل هذا ممكن تمامًا إما عن طريق إنشاء نسخة من المكون الإضافي للإعلانات، وربما تقديم طلب سحب، أو استخدامه كنموذج لإنشاء مكون إضافي خاص بشبكة الإعلانات الخاصة بك (مما يمنحك مزيدًا من التحكم، ولكنه سيحد من جمهورك ليشمل المواقع المستضافة ذاتيًا والمواقع الأخرى التي يمكنها تثبيت مكونات إضافية عشوائية).\n\nأنت مرحب بك للنشر على Marketplace أو الاطلاع على مواضيع المكونات الإضافية المختلفة مثل هذا الموضوع الأول الذي وجدته تطوير مكونات Discourse الإضافية - الجزء 2 - الاتصال بمنفذ مكون إضافي.

إعجاب واحد (1)

قد يكون من الجدير بالذكر أن المكون الإضافي للإعلانات يبدو أنه قيد العمل النشط

يحتاج شخص لديه مصلحة في تحقيق إيرادات إلى نشر إعلان في Marketplace للحصول على مطور لمساعدته في دعم مزوده المحدد.

لقد كنت أقوم بصيانة إضافة إعلانية لعميل لفترة من الوقت الآن.

@pfaffman
شكراً على الرد السريع. أود تسليط الضوء على بعض النقاط المتعلقة بهذا:

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

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

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

@merefield
هل فهمت منك بشكل صحيح أن الناشر الذي يرغب في دمج شبكة إعلانية يفتح منشورًا في تهديد السوق ويطلب الدعم في عملية الدمج؟

إعجاب واحد (1)

في حالتي، قام مسؤول موقع المستخدم النهائي برعاية العمل دون الدعم المباشر من ناشر الإعلان.

ومع ذلك، مع أخذ كل شيء في الاعتبار، سيكون من الرائع لو انخرط ناشر الإعلان في مجتمع المطورين ورعاية العمل لضمان دعم إعلاناتهم بشكل مباشر.

كان عملي مفتوح المصدر بالمناسبة (بالاتفاق مع العميل)، لذا من الممكن للآخرين الاستفادة من هذا العمل (على الرغم من أنني للأسف لا أستطيع تقديم أي دعم مجاني).

إذا كنت مهتمًا بهذا المستودع، يمكنني إرسال التفاصيل الأساسية إليك عبر الرسائل الخاصة.

إعجابَين (2)

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

بشكل عام، إذا كان الناشر يتطلب تشغيل نصوص برمجية مخصصة، فعادةً ما يتطلب ذلك تدخل مطور لربط كل شيء.

القضية الأساسية هي أنه عادةً ما يمكن “تشغيل” الكود مرة واحدة فقط بعد عرض العنصر المعني في DOM، وهذا يتطلب بعض الجدولة في الكود. يمكن أن يتفاقم هذا بسبب المتطلبات الخاصة مثل معرفات التسلسل.

السبب في ذلك هو أن Discourse مبني كتطبيق ويب ويستخدم إطار عمل جافاسكريبت، لذا فهو أكثر تعقيدًا بعض الشيء.

إعجاب واحد (1)

هذا مفهوم. لقد أشرت بالفعل إلى مشكلة تطبيق الويب في المنشور الافتتاحي.

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

إعجاب واحد (1)