يبدو أن مجال الإعلان عبر الإنترنت يجب أن يكون تقنيًا وآليًا قدر الإمكان. في الواقع ، هناك عمالقة وخبراء في مجال عملهم مثل Yandex و Mail.Ru و Google و Facebook يعملون هناك. ولكن ، كما اتضح ، ليس هناك حد للكمال ، وهناك دائمًا شيء ما للتشغيل الآلي.
مصدرمجموعة الاتصالات
Dentsu Aegis Network Russia هي أكبر لاعب في سوق الإعلانات الرقمية وتستثمر بنشاط في التكنولوجيا ، في محاولة لتحسين وأتمتة عملياتها التجارية. كانت إحدى المشكلات التي لم يتم حلها في سوق الإعلانات عبر الإنترنت مهمة جمع إحصائيات حول الحملات الإعلانية من مواقع مختلفة على الإنترنت. أدى حل هذه المشكلة في النهاية إلى إنشاء منتج
D1.Digital (اقرأ باسم DiVan) ، والذي نريد التحدث عن تطويره.
لماذا؟
1. في وقت بدء المشروع ، لم يكن هناك منتج نهائي واحد في السوق يحل مهمة أتمتة جمع الإحصاءات عن الحملات الإعلانية.
هذا يعني أنه لا أحد غيرنا سوف يغلق احتياجاتنا.تقدم خدمات مثل Improvado و Roistat و Supermetrics و SegmentStream التكامل مع المواقع والشبكات الاجتماعية و Google Analitycs ، كما توفر القدرة على إنشاء لوحات معلومات تحليلية لتحليل الحملات الإعلانية والتحكم فيها بشكل مناسب. قبل البدء في تطوير منتجاتنا ، حاولنا استخدام بعض هذه الأنظمة في عملنا لجمع البيانات من المواقع ، لكن للأسف لم يتمكنوا من حل مشكلاتنا.
كانت المشكلة الرئيسية هي أن المنتجات التي تم اختبارها تم صدها من مصادر البيانات ، وعرض إحصاءات المواضع في الأقسام حسب المواقع ، ولم تسمح بتجميع الإحصاءات في الحملات الإعلانية. لم يسمح هذا النهج بمشاهدة الإحصاءات من مواقع مختلفة في مكان واحد وتحليل حالة الحملة ككل.
عامل آخر هو أنه في المراحل الأولية كانت المنتجات موجهة إلى السوق الغربية ولم تدعم التكامل مع المواقع الروسية. وبالنسبة إلى تلك المواقع التي تم تطبيق التكامل بها ، لم يتم دائمًا تحميل جميع المقاييس الضرورية بتفاصيل كافية ، ولم يكن التكامل دائمًا مناسبًا وشفافًا ، خاصةً عندما كان من الضروري الحصول على شيء غير موجود في واجهة النظام.
بشكل عام ، قررنا عدم التكيف مع منتجات الجهات الخارجية ، لكننا بدأنا في تطوير منتجاتنا ...
2. ينمو سوق الإعلانات عبر الإنترنت من سنة إلى أخرى ، وفي عام 2018 ، تجاوز تقليديًا أكبر سوق للإعلانات التلفزيونية من حيث ميزانيات الإعلانات.
لذلك هناك مقياس .
3. على عكس سوق الإعلانات التلفزيونية ، حيث يتم احتكار بيع الإعلانات التجارية ، تعمل مجموعة من مالكي الأجهزة الفردية من مختلف الأحجام مع مكاتب الإعلان الخاصة بهم على الإنترنت. نظرًا لأن الحملة الإعلانية ، كقاعدة عامة ، تعمل على عدة مواقع في وقت واحد ، لفهم حالة الحملة الإعلانية ، فمن الضروري جمع التقارير من جميع المواقع وجمعها في تقرير واحد كبير يعرض الصورة بأكملها.
لذلك ، هناك إمكانية للتحسين.4. يبدو لنا أن مالكي مخزون الإعلانات على الإنترنت لديهم بالفعل بنية تحتية لجمع الإحصاءات وعرضها في مكاتب الإعلان ، ويمكنهم توفير واجهة برمجة تطبيقات لهذه البيانات.
لذلك ، هناك جدوى فنية. سنقول على الفور أنه لم يكن بهذه البساطة.
بشكل عام ، كانت جميع المتطلبات الأساسية لتنفيذ المشروع واضحة بالنسبة لنا ، وقد ركضنا لتنفيذ المشروع ...
خطة الكبرى
أولاً ، شكلنا رؤية لنظام مثالي:
- يجب أن تقوم تلقائيًا بتحميل الحملات الإعلانية من نظام الشركات 1C بأسمائها وفتراتها وميزانياتها ومواضعها على منصات مختلفة.
- بالنسبة إلى كل موضع داخل الحملة الإعلانية ، يجب تلقائيًا تنزيل جميع الإحصائيات الممكنة من المواقع التي يتم وضع الإعلان عليها ، مثل عدد مرات الظهور والنقرات وطرق العرض ، إلخ.
- تتم مراقبة بعض الحملات الإعلانية من خلال مراقبة الجهات الخارجية بواسطة ما يسمى بأنظمة تقديم الإعلانات ، مثل Adriver ، Weborama ، DCM ، إلخ. هناك أيضا متر الإنترنت الصناعي في روسيا - Mediascope. وفقًا لفكرتنا ، ينبغي أيضًا تحميل بيانات المراقبة المستقلة والصناعية تلقائيًا على الحملات الإعلانية المقابلة.
- تهدف معظم الحملات الإعلانية على الإنترنت إلى بعض الإجراءات المستهدفة (الشراء ، الاتصال ، التسجيل لاختبار القيادة ، وما إلى ذلك) ، والتي يتم تتبعها باستخدام Google Analytics ، والإحصائيات التي تعد أيضًا مهمة لفهم حالة الحملة ويجب تحميلها على أداة لدينا .
فطيرة الأولى هي العقدي
النظر في التزامنا بالمبادئ المرنة لتطوير البرمجيات (رشيقة ، كل شيء) ، قررنا أولاً تطوير MVP ثم التحرك نحو الهدف المقصود بشكل متكرر.
قررنا إنشاء MVP على أساس منتجنا
DANBo (Dentsu Aegis Network Board) ، وهو تطبيق ويب يحتوي على معلومات عامة عن الحملات الإعلانية لعملائنا.
بالنسبة لـ MVP ، تم تبسيط المشروع إلى الحد الأقصى من حيث التنفيذ. لقد اخترنا قائمة محدودة من المواقع للتكامل. كانت هذه الأنظمة الأساسية مثل Yandex.Direct و Yandex.Display و RB.Mail و MyTarget و Adwords و DBM و VK و FB وأنظمة aderving الرئيسية و Adriver و Weborama.
للوصول إلى الإحصائيات على المواقع من خلال واجهة برمجة التطبيقات ، استخدمنا حسابًا واحدًا. كان على مدير مجموعة العملاء ، الذي أراد استخدام المجموعة التلقائية للإحصائيات حول الحملة الإعلانية ، أولاً تفويض الوصول إلى الحملات الإعلانية الضرورية على المواقع إلى حساب النظام الأساسي.
ثم ،
اضطر مستخدم نظام
DANBo إلى تحميل ملف بتنسيق معين على نظام Excel ، حيث تمت كتابة جميع المعلومات حول الموضع (الحملة الإعلانية ، الموقع ، التنسيق ، فترة الموضع ، المؤشرات المخططة ، الميزانية ، إلخ) ومعرفات الحملات الإعلانية المقابلة على المواقع وعدادات في أنظمة adserving.
بدا الأمر بصراحة مرعباً:
تم تخزين البيانات التي تم تنزيلها في قاعدة البيانات ، ثم قامت الخدمات الفردية بجمع معرفات الحملة منها من المواقع وتنزيل الإحصاءات عليها.
تمت كتابة خدمة نوافذ منفصلة لكل موقع ، والتي كانت تُخضع لمرة واحدة يوميًا لحساب خدمة واحد في واجهة برمجة التطبيقات الخاصة بالموقع وتنزيل إحصائيات حول معرّفات الحملة المحددة. حدث الشيء نفسه مع أنظمة adserving.
تم عرض البيانات التي تم تنزيلها على الواجهة في شكل لوحة معلومات صغيرة مكتوبة ذاتياً:
بشكل غير متوقع بالنسبة لنا ، كسبت MVP وبدأت في تنزيل الإحصاءات الحالية حول الحملات الإعلانية على الإنترنت. قمنا بتطبيق النظام على العديد من العملاء ، ولكن عندما حاولنا التوسع ، واجهنا مشاكل خطيرة:
- كانت المشكلة الرئيسية هي صعوبة إعداد البيانات للتحميل في النظام. أيضًا ، يجب تقليل بيانات المواضع إلى تنسيق ثابت تمامًا قبل التنزيل. في ملف التحميل ، كان من الضروري تسجيل معرفات الكيانات من مواقع مختلفة. إننا نواجه حقيقة أنه من الصعب جدًا على المستخدمين غير المدربين تقنيًا توضيح مكان العثور على هذه المعرّفات على الموقع ومكان وضعها في الملف. بالنظر إلى عدد الموظفين في الأقسام الذين يقومون بحملات على المواقع ، ودورانها ، نتج عن ذلك قدر كبير من الدعم من جانبنا ، وهو ما لم يناسبنا بشكل قاطع.
- مشكلة أخرى هي أنه ليس كل منصات الإعلان لديها آليات لتفويض الوصول إلى الحملات الإعلانية إلى حسابات أخرى. ولكن حتى لو كانت آلية التفويض متاحة ، فلن يكون جميع المعلنين على استعداد لتوفير وصول حساب الطرف الثالث إلى حملاتهم.
- كان العامل المهم هو السخط الذي تسبب في إعادة إدخال جميع المؤشرات المخططة وتفاصيل المواضع التي يساهمون بها بالفعل في نظام المحاسبة 1C لدينا في DANBo .
أعطانا هذا فكرة أن المصدر الرئيسي للمعلومات حول الموقع يجب أن يكون نظام 1C ، حيث يتم إدخال جميع البيانات بدقة وفي الوقت المحدد (النقطة هي أنه بناءً على بيانات 1C ، يتم تشكيل الحسابات ، وبالتالي ، فإن الإدخال الصحيح للبيانات في 1C هو للجميع KPI). لذلك ظهر مفهوم نظام جديد ...
مفهوم
أول شيء قررنا القيام به هو فصل نظام جمع الإحصاءات حول الحملات الإعلانية على الإنترنت إلى منتج منفصل -
D1.Digital .
في المفهوم الجديد ، قررنا تحميل معلومات عن الحملات الإعلانية والمواضع بداخلها من 1C إلى
D1.Digital ، ثم سحب الإحصاءات من المواقع ومن أنظمة AdServing إلى هذه المواضع. كان من المفترض أن يؤدي ذلك إلى تبسيط حياة المستخدمين إلى حد كبير (وكالعادة ، إضافة عمل للمطورين) وتقليل مقدار الدعم.
كانت المشكلة الأولى التي واجهناها ذات طابع تنظيمي وكانت مرتبطة بحقيقة أننا لم نتمكن من العثور على مفتاح أو سمة يمكننا من خلالها مقارنة الكيانات من أنظمة مختلفة مع الحملات والمواضع من 1C. الحقيقة هي أن العملية في شركتنا مرتبة بطريقة تدخل بها الحملات الإعلانية في أنظمة مختلفة من قبل أشخاص مختلفين (مشغلات الوسائط ، الشراء ، إلخ).
لحل هذه المشكلة ، اضطررنا إلى اختراع مفتاح تجزئة فريد ، DANBoID ، والذي يربط الكيانات في الأنظمة المختلفة معًا ، والتي يمكن تحديدها بسهولة ودون لبس في مجموعات البيانات المحملة. يتم إنشاء هذا المعرف في نظام 1C الداخلي لكل موضع فردي ، ويلقي نفسه في الحملات والمواضع والعدادات على جميع المنصات وفي جميع أنظمة AdServing. استغرق تطبيق ممارسة تثبيت DANBoID على جميع المواضع بعض الوقت ، لكننا فعلنا ذلك :)
ثم اكتشفنا أنه ليس كل المواقع بها واجهة برمجة تطبيقات لتجميع الإحصاءات التلقائية ، وحتى تلك المواقع التي لديها واجهة برمجة التطبيقات لا تُرجع جميع البيانات اللازمة.
في هذه المرحلة ، قررنا تقليل قائمة المواقع بشكل كبير للتكامل والتركيز على المواقع الرئيسية المشاركة في الغالبية العظمى من الحملات الإعلانية. تشمل هذه القائمة جميع أكبر اللاعبين في سوق الإعلانات (Google و Yandex و Mail.ru) والشبكات الاجتماعية (VK و Facebook و Twitter) وأنظمة AdServing والتحليلات الرئيسية (DCM و Adriver و Weborama و Google Analytics) ومنصات أخرى.
يحتوي الجزء الأكبر من المواقع التي اخترناها على واجهة برمجة التطبيقات التي منحتنا المقاييس اللازمة. في تلك الحالات التي لم تكن فيها واجهة برمجة التطبيقات (API) موجودة ، أو لم تكن لديها البيانات اللازمة ، لاستخدام البيانات التي استخدمناها والتي وصلت يوميًا على بريد العمل (من الممكن في بعض الأنظمة تكوين مثل هذه التقارير ، وفي حالات أخرى اتفقنا على تطوير مثل هذه التقارير لنا).
عند تحليل البيانات من مواقع مختلفة ، وجدنا أن التسلسل الهرمي للكيانات ليس هو نفسه في الأنظمة المختلفة. علاوة على ذلك ، يجب تحميل المعلومات من النظم المختلفة بتفاصيل مختلفة.
لحل هذه المشكلة ، تم تطوير مفهوم SubDANBoID. فكرة SubDANBoID بسيطة جدًا ، حيث نحتفل بالجوهر الرئيسي للحملة على الموقع باستخدام DANBoID الذي تم إنشاؤه ، ونقوم بتحميل جميع الكيانات المتداخلة ذات المعرفات الفريدة للموقع ونشكل SubDANBoID وفقًا لمبدأ DANBoID + الكيان المتداخل للكيان المتداخل من المستوى الأول + المعرف للكيان المتداخل المسموح به + ... حملات إعلانية في أنظمة مختلفة وتحميل إحصاءات مفصلة عليها.
كان علينا أيضًا حل مشكلة الوصول إلى الحملات في مواقع مختلفة. كما كتبنا أعلاه ، فإن آلية تفويض الوصول إلى الحملة إلى حساب فني منفصل لا تنطبق دائمًا. لذلك ، كان علينا تطوير بنية أساسية للترخيص التلقائي من خلال OAuth باستخدام الرموز وتحديث آليات هذه الرموز.
علاوة على ذلك ، سنحاول أن نوضح بمزيد من التفصيل بنية الحل والتفاصيل الفنية للتنفيذ.
هندسة الحلول 1.0
عند بدء تنفيذ منتج جديد ، أدركنا أنه كان من الضروري على الفور توفير إمكانية توصيل مواقع جديدة ، لذلك قررنا اتباع مسار هندسة الخدمات المصغرة.
عند تصميم البنية ، خصصنا في موصلات خدمات منفصلة لجميع الأنظمة الخارجية - 1C ، ومنصات الإعلان وأنظمة تقديم الإعلانات.
الفكرة الرئيسية هي أن جميع الموصلات إلى المواقع لها نفس واجهة برمجة التطبيقات وأن تكون محولات تنقل واجهات برمجة التطبيقات الخاصة بالموقع إلى واجهتنا المريحة.
في منتصف منتجنا ، يوجد تطبيق ويب ، وهو مجموعة متجانسة ، تم تصميمها بحيث يمكن تفكيكها بسهولة إلى خدمات. هذا التطبيق مسؤول عن معالجة البيانات التي تم تنزيلها ، ومقارنة الإحصاءات من أنظمة مختلفة وتقديمها إلى مستخدمي النظام.
للتواصل مع الموصلات من خلال تطبيق ويب ، اضطررنا إلى إنشاء خدمة إضافية ، أطلقنا عليها اسم الموصل Proxy. ينفذ وظائف خدمة اكتشاف وجدولة المهام. تقوم هذه الخدمة بتشغيل مهام جمع البيانات لكل موصل كل ليلة. كانت كتابة طبقة خدمة أسهل من توصيل وسيط الرسائل ، وكان من المهم بالنسبة لنا الحصول على النتيجة في أسرع وقت ممكن.
للبساطة وسرعة التطوير ، قررنا أيضًا أن تكون جميع الخدمات عبارة عن واجهة برمجة تطبيقات ويب. هذا جعل من الممكن تجميع بسرعة إثبات صحة المفهوم والتحقق من أن التصميم بأكمله كان يعمل.
هناك مهمة منفصلة ، صعبة إلى حد ما ، تتمثل في إعداد الوصول لجمع البيانات من خزانات مختلفة ، والتي ، كما قررنا ، ينبغي تنفيذها من خلال المستخدمين عبر واجهة ويب. يتكون من خطوتين منفصلتين: أولاً ، يضيف المستخدم من خلال OAuth رمزًا مميزًا للوصول إلى الحساب ، ثم يقوم بإعداد جمع البيانات للعميل من حساب معين. من الضروري الحصول على رمز مميز عبر بروتوكول OAuth ، لأنه ، كما كتبنا بالفعل ، لا يمكن دائمًا تفويض الوصول إلى الخزانة المطلوبة على الموقع.
لإنشاء آلية عالمية لاختيار خزانة من المواقع ، اضطررنا إلى إضافة طريقة إلى واجهة برمجة التطبيقات للموصلات التي تقدم مخطط JSON ، والذي يتم تقديمه في النموذج باستخدام مكون JSONEditor المعدل. حتى يتمكن المستخدمون من اختيار الحسابات التي يمكن من خلالها تنزيل البيانات.
للامتثال لحدود الطلبات الموجودة على المواقع ، نقوم بدمج طلب الإعدادات في نفس الرمز المميز ، ولكن يمكننا معالجة الرموز المميزة المختلفة على التوازي.
اخترنا MongoDB كمستودع للبيانات القابلة للتنزيل لكل من تطبيق الويب والموصلات ، مما سمح لنا بعدم إزعاج الكثير عن بنية البيانات في المراحل الأولية من التطوير ، عندما يتغير نموذج التطبيق بعد يوم واحد.
اكتشفنا قريبًا أن البيانات غير مناسبة تمامًا في MongoDB ، على سبيل المثال ، الإحصاءات اليومية أكثر ملاءمة للتخزين في قاعدة بيانات علائقية. لذلك ، بالنسبة للموصلات التي يكون هيكل بياناتها أكثر ملاءمة لقاعدة بيانات علائقية ، بدأنا في استخدام PostgreSQL أو MS SQL Server كتخزين.
سمحت لنا الهندسة والتكنولوجيا المختارة ببناء وإطلاق منتج D1.Digital بسرعة نسبياً. على مدار عامين من تطوير المنتج ، قمنا بتطوير 23 رابط موقع ، واكتسبنا خبرة لا تقدر بثمن في العمل مع واجهات برمجة التطبيقات الخاصة بالجهات الخارجية ، وتعلمنا كيفية تجاوز مطبات المواقع المختلفة التي كان لكل منها ملكه ، وساهمنا في تطوير واجهة برمجة التطبيقات على الأقل 3 مواقع ، وقمنا تلقائيًا بتنزيل المعلومات على حوالي 15000 حملة و في أكثر من 80،000 موضع ، جمعنا الكثير من التعليقات من المستخدمين حول المنتج وتمكنا من تغيير العملية الرئيسية للمنتج عدة مرات ، بناءً على هذه التعليقات.
هندسة الحلول 2.0
لقد مر عامين منذ بداية تطوير
D1.Digital . كشفت الزيادة المستمرة في الحمل على النظام وظهور مصادر بيانات جديدة تدريجيًا عن مشكلات في بنية الحلول الحالية.
المشكلة الأولى تتعلق بحجم البيانات التي تم تنزيلها من المواقع. لقد واجهنا حقيقة أن جمع وتحديث جميع البيانات اللازمة من أكبر المواقع بدأ يستغرق الكثير من الوقت. على سبيل المثال ، يستغرق جمع البيانات على نظام AdRiver adserving ، والذي نتتبع به إحصائيات معظم المواضع ، حوالي 12 ساعة.
لحل هذه المشكلة ، بدأنا في استخدام جميع أنواع التقارير لتنزيل البيانات من المواقع ، ونحن نحاول تطوير واجهات برمجة التطبيقات الخاصة بهم مع المواقع بحيث تلبي سرعتها احتياجاتنا ، وموازنة تحميل البيانات قدر الإمكان.
مشكلة أخرى هي معالجة البيانات التي تم تنزيلها. الآن ، مع وصول إحصاءات جديدة عن المواضع ، تم إطلاق عملية متعددة المقاييس لإعادة حساب المقاييس ، والتي تشمل تحميل البيانات الأولية ، وحساب المقاييس المجمعة لكل موقع ، ومقارنة البيانات من مصادر مختلفة مع بعضها البعض وحساب مقاييس الملخص للحملة. يؤدي هذا إلى حمل كبير على تطبيق الويب ، الذي يؤدي جميع العمليات الحسابية. عدة مرات ، أثناء عملية إعادة الحساب ، يستهلك التطبيق جميع الذاكرة الموجودة على الخادم ، حوالي 10-15 جيجابايت ، والذي له التأثير الأكثر ضررًا على عمل المستخدم مع النظام.
أدت المشكلات التي تم تحديدها وخطط الفخامة لمزيد من التطوير للمنتج إلى الحاجة إلى مراجعة بنية التطبيق.
بدأنا مع الموصلات.
لقد لاحظنا أن جميع الموصلات تعمل وفقًا لنفس النموذج ، لذلك قمنا ببناء ناقل خط أنابيب لإنشاء الرابط الذي كان عليك فقط برمجة منطق الخطوات ، وكان الباقي عالميًا. إذا احتاج أي موصل إلى تحسين ، فسوف ننقله على الفور إلى إطار جديد أثناء الانتهاء من الموصل.
في موازاة ذلك ، بدأنا وضع الموصلات في عامل ميناء و Kubernetes.
لقد خططنا للانتقال إلى Kubernetes لفترة طويلة إلى حد ما ، حيث جربنا إعدادات CI / CD ، لكننا بدأنا ننتقل فقط عندما بدأ موصل واحد في تناول أكثر من 20 جيجابايت من الذاكرة على الخادم بسبب خطأ ، مما أدى إلى مقتل باقي العمليات تقريبًا. أثناء التحقيق ، تم نقل الموصل إلى مجموعة Kubernetes ، حيث بقي في النهاية ، حتى عندما تم إصلاح الخطأ.
بسرعة كبيرة ، أدركنا أن Kubernetes كانت مريحة ، وخلال ستة أشهر ، قمنا بنقل 7 موصلات ووصلات Proxy إلى مجموعة الإنتاج ، والتي تستهلك معظم الموارد.
بعد الموصلات ، قررنا تغيير بنية بقية التطبيق.
كانت المشكلة الرئيسية هي أن البيانات تأتي من الموصلات إلى الوكلاء في حزم كبيرة ، ثم تغلبوا على DANBoID ونقلوها إلى تطبيق ويب مركزي للمعالجة. نظرًا للعدد الكبير من إعادة فرز المقاييس ، يحدث حمل كبير على التطبيق.
, , web , , , - .
2.0.
, Web API RabbitMQ MassTransit . Connectors Proxy, Connectors Hub. , , .
web , . .
Kubernetes, .
Proof-of-concept 2.0
D1.Digital . — 20 , , , , .
, API, .
, , adserving .
, web , Kubernetes. , , .
, MongoDB. SQL-, , , , .
, , :)
R&D Dentsu Aegis Network Russia: ( shmiigaa ), ( hitexx )