हमने ऑनलाइन प्लेटफ़ॉर्म (उत्पाद के लिए कांटेदार पथ) से विज्ञापन अभियानों पर डेटा कैसे एकत्र किया

ऐसा लगता है कि ऑनलाइन विज्ञापन का क्षेत्र तकनीकी और यथासंभव स्वचालित होना चाहिए। वास्तव में, ऐसे दिग्गज और उनके क्षेत्र में विशेषज्ञ जैसे कि यैंडेक्स, मेल.रू, गूगल और फेसबुक वहां काम करते हैं। लेकिन, जैसा कि यह पता चला है, पूर्णता की कोई सीमा नहीं है और स्वचालित करने के लिए हमेशा कुछ होता है।


स्रोत

संचार समूह डेंटसु एजिस नेटवर्क रूस डिजिटल विज्ञापन बाजार में सबसे बड़ा खिलाड़ी है और प्रौद्योगिकी में सक्रिय रूप से निवेश करता है, अपनी व्यावसायिक प्रक्रियाओं को अनुकूलित और स्वचालित करने की कोशिश करता है। ऑनलाइन विज्ञापन बाजार की अनसुलझे समस्याओं में से एक विभिन्न ऑनलाइन साइटों से विज्ञापन अभियानों पर आंकड़े एकत्र करने का कार्य था। इस समस्या के समाधान के परिणामस्वरूप अंततः D1.Digital उत्पाद (DiVan के रूप में पढ़ा गया) का निर्माण हुआ, जिसे हम विकसित करने के लिए बात करना चाहते हैं।

क्यों?

1. परियोजना की शुरुआत के समय, बाजार पर एक भी तैयार उत्पाद नहीं था जो विज्ञापन अभियानों पर आंकड़ों के संग्रह को स्वचालित करने के कार्य को हल करता था। इसका मतलब यह है कि कोई भी नहीं बल्कि खुद हमारी जरूरतों को बंद कर देगा।

इम्प्रोवैडो, रोइस्टैट, सुपरमेट्रिक्स, सेगमेंटस्ट्रीम जैसी सेवाएं साइटों, सोशल नेटवर्कों और गूगल एनालिटिक्स के साथ एकीकरण की पेशकश करती हैं, और विज्ञापन अभियानों के सुविधाजनक विश्लेषण और नियंत्रण के लिए विश्लेषणात्मक डैशबोर्ड बनाने की क्षमता भी प्रदान करती हैं। अपने उत्पाद को विकसित करने के लिए शुरू करने से पहले, हमने साइटों से डेटा एकत्र करने के लिए अपने काम में इनमें से कुछ प्रणालियों का उपयोग करने की कोशिश की, लेकिन, दुर्भाग्य से, वे हमारी समस्याओं को हल नहीं कर सके।

मुख्य समस्या यह थी कि परीक्षण किए गए उत्पादों को डेटा स्रोतों से हटा दिया गया था, साइटों द्वारा अनुभागों में प्लेसमेंट के आंकड़े प्रदर्शित किए गए थे, और विज्ञापन अभियानों पर आंकड़ों के एकत्रीकरण की अनुमति नहीं दी थी। इस दृष्टिकोण ने एक ही स्थान पर विभिन्न साइटों के आंकड़े देखने और अभियान की स्थिति का समग्र रूप से विश्लेषण करने की अनुमति नहीं दी।

एक अन्य कारक यह था कि शुरुआती चरणों में उत्पाद पश्चिमी बाजार के लिए उन्मुख थे और रूसी साइटों के साथ एकीकरण का समर्थन नहीं करते थे। और उन साइटों के लिए जिनके साथ एकीकरण लागू किया गया था, पर्याप्त विवरण के साथ सभी आवश्यक मैट्रिक्स हमेशा अपलोड नहीं किए गए थे, और एकीकरण हमेशा सुविधाजनक और पारदर्शी नहीं था, खासकर जब यह कुछ पाने के लिए आवश्यक था जो सिस्टम इंटरफ़ेस में नहीं था।
सामान्य तौर पर, हमने तीसरे पक्ष के उत्पादों के अनुकूल नहीं होने का फैसला किया, लेकिन अपना खुद का विकास करना शुरू कर दिया ...

2. ऑनलाइन विज्ञापन बाजार साल-दर-साल बढ़ रहा है, और 2018 में, विज्ञापन विज्ञापनों के मामले में यह परंपरागत रूप से सबसे बड़े टीवी विज्ञापन बाजार से आगे निकल गया। तो एक पैमाना है ।

3. टीवी विज्ञापन बाजार के विपरीत, जहां वाणिज्यिक विज्ञापन की बिक्री का एकाधिकार है, इंटरनेट पर उनके विज्ञापन कार्यालयों के साथ विभिन्न आकारों के विज्ञापन उपकरण के व्यक्तिगत मालिकों का द्रव्यमान काम करता है। चूंकि विज्ञापन अभियान, एक नियम के रूप में, एक साथ कई साइटों पर चलता है, विज्ञापन अभियान की स्थिति को समझने के लिए, सभी साइटों से रिपोर्ट एकत्र करना और उन्हें एक बड़ी रिपोर्ट में एक साथ लाना आवश्यक है जो पूरी तस्वीर दिखाएगा। तो, अनुकूलन की संभावना है।

4. हमें यह प्रतीत हुआ कि इंटरनेट पर विज्ञापन सूची के मालिकों के पास पहले से ही आँकड़े इकट्ठा करने और उन्हें विज्ञापन कार्यालयों में प्रदर्शित करने के लिए एक बुनियादी ढांचा था, और वे इस डेटा के लिए एक एपीआई प्रदान कर सकते थे। तो, एक तकनीकी व्यवहार्यता है। हम तुरंत कहेंगे कि यह इतना सरल नहीं था।

सामान्य तौर पर, परियोजना के कार्यान्वयन के लिए सभी आवश्यक शर्तें हमारे लिए स्पष्ट थीं, और हम परियोजना को लागू करने के लिए दौड़े ...

भव्य योजना

सबसे पहले, हमने एक आदर्श प्रणाली की दृष्टि बनाई:

• यह स्वचालित रूप से 1C कॉर्पोरेट सिस्टम से विभिन्न प्लेटफार्मों पर उनके नाम, अवधि, बजट और प्लेसमेंट के साथ विज्ञापन अभियानों को लोड करना चाहिए।
• विज्ञापन अभियान के अंदर प्रत्येक प्लेसमेंट के लिए, जिन साइटों पर प्लेसमेंट चल रहा है, उनके सभी संभावित आंकड़े स्वचालित रूप से डाउनलोड होने चाहिए, जैसे इंप्रेशन, क्लिक, व्यू आदि की संख्या।
• कुछ विज्ञापन अभियानों की निगरानी तथाकथित विज्ञापन-प्रसार प्रणालियों द्वारा तीसरे पक्ष की निगरानी से की जाती है, जैसे कि एड्रिवर, वेबोरमा, डीसीपी आदि। रूस में एक औद्योगिक इंटरनेट मीटर भी है - मेडिसीस्कोप। हमारे विचार के अनुसार, स्वतंत्र और औद्योगिक निगरानी का डेटा भी स्वचालित रूप से संबंधित विज्ञापन अभियानों पर अपलोड किया जाना चाहिए।
• इंटरनेट पर अधिकांश विज्ञापन अभियान कुछ लक्षित क्रियाओं (उद्देश्य, परीक्षण ड्राइव के लिए रिकॉर्डिंग, कॉलिंग, रिकॉर्डिंग) पर लक्षित होते हैं, जिन्हें Google Analytics का उपयोग करके ट्रैक किया जाता है, और जिन आंकड़ों पर अभियान की स्थिति को समझना भी महत्वपूर्ण है और जिन्हें हमारे टूल पर अपलोड किया जाना चाहिए ।

पहला पैनकेक गांठदार है

सॉफ्टवेयर विकास के लचीले सिद्धांतों (फुर्तीली, सभी चीजों) के लिए हमारी प्रतिबद्धता को ध्यान में रखते हुए, हमने पहले एमवीपी को विकसित करने का फैसला किया और फिर पुन: उद्देश्यपूर्ण लक्ष्य की ओर बढ़ गए।
हमने अपने उत्पाद DANBo (Dentsu Aegis Network Board) के आधार पर MVP बनाने का निर्णय लिया, जो हमारे ग्राहकों के विज्ञापन अभियानों पर सामान्य जानकारी के साथ एक वेब एप्लिकेशन है।

एमवीपी के लिए, परियोजना को कार्यान्वयन के संदर्भ में अधिकतम सरलीकृत किया गया था। हमने एकीकरण के लिए साइटों की एक सीमित सूची का चयन किया है। ये मुख्य मंच थे, जैसे कि Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB और मुख्य विज्ञापन देने वाली प्रणालियाँ Adriver और Weborama।

एपीआई के माध्यम से साइटों पर आंकड़ों तक पहुंचने के लिए, हमने एक खाते का उपयोग किया। ग्राहक समूह प्रबंधक, जो विज्ञापन अभियान पर आँकड़ों के स्वत: संग्रह का उपयोग करना चाहता था, उसे पहले साइटों पर आवश्यक विज्ञापन अभियानों की पहुँच प्लेटफ़ॉर्म खाते तक पहुँचाना था।

इसके अलावा, DANBo प्रणाली के उपयोगकर्ता को एक्सेल प्रणाली के लिए एक निश्चित प्रारूप की एक फ़ाइल अपलोड करनी थी, जिसमें प्लेसमेंट (विज्ञापन अभियान, साइट, प्रारूप, प्लेसमेंट अवधि, नियोजित संकेतक, बजट, आदि) और साइटों पर संबंधित विज्ञापन अभियानों के पहचानकर्ताओं के बारे में सभी जानकारी लिखी गई थी। और विज्ञापन देने वाले सिस्टम में काउंटर।

यह देखा, स्पष्ट रूप से, भयानक:



डाउनलोड किया गया डेटा डेटाबेस में संग्रहीत किया गया था, और फिर व्यक्तिगत सेवाओं ने उनसे साइटों से अभियान पहचानकर्ता एकत्र किए और उन पर आंकड़े डाउनलोड किए।

प्रत्येक साइट के लिए एक अलग विंडो सेवा लिखी गई थी, जो दिन में एक बार साइट के एपीआई में एक सेवा खाते के तहत जाती थी और निर्दिष्ट विशिष्ट पहचानकर्ताओं पर आंकड़े डाउनलोड करती थी। यही बात विज्ञापन देने वाली प्रणालियों के साथ भी हुई।

डाउनलोड किए गए डेटा को इंटरफ़ेस पर एक छोटे से स्व-लिखित डैशबोर्ड के रूप में प्रदर्शित किया गया था:



हमारे लिए अप्रत्याशित रूप से, एमवीपी ने कमाई की और इंटरनेट पर विज्ञापन अभियानों पर वर्तमान आंकड़े डाउनलोड करना शुरू कर दिया। हमने कई क्लाइंट्स पर सिस्टम लागू किया, लेकिन जब हमने स्केल करने की कोशिश की, तो हम गंभीर समस्याओं में भाग गए:

• मुख्य समस्या सिस्टम में लोड करने के लिए डेटा तैयार करने की श्रमसाध्यता थी। साथ ही, डाउनलोड करने से पहले प्लेसमेंट डेटा को कड़ाई से निर्धारित प्रारूप में कम करना होगा। लोड करने के लिए फ़ाइल में, विभिन्न साइटों से संस्थाओं के पहचानकर्ताओं को पंजीकृत करना आवश्यक था। हमें इस तथ्य का सामना करना पड़ रहा है कि तकनीकी रूप से अप्रशिक्षित उपयोगकर्ताओं के लिए यह समझाना बहुत मुश्किल है कि इन पहचानकर्ताओं को साइट पर कहां ढूंढना है और उन्हें फाइल में कहां रखना है। साइटों पर अभियानों का संचालन करने वाले डिवीजनों और टर्नओवर में कर्मचारियों की संख्या को ध्यान में रखते हुए, इसके परिणामस्वरूप हमारी तरफ से बड़ी मात्रा में सहायता मिली, जो स्पष्ट रूप से हमारे लिए उपयुक्त नहीं थी।
• एक अन्य समस्या यह थी कि सभी विज्ञापन प्लेटफ़ॉर्म में अन्य अभियानों के विज्ञापन अभियानों तक पहुँच को निर्धारित करने की व्यवस्था नहीं थी। लेकिन भले ही प्रतिनिधिमंडल तंत्र उपलब्ध था, लेकिन सभी विज्ञापनदाता अपने अभियानों में तृतीय-पक्ष खाता पहुंच प्रदान करने के लिए तैयार नहीं थे।
• एक महत्वपूर्ण कारक आक्रोश था, जिसके कारण उपयोगकर्ताओं ने सभी नियोजित संकेतकों और प्लेसमेंट विवरणों को बताया कि वे पहले से ही हमारे 1 सी लेखा प्रणाली में योगदान करते हैं, उन्हें डैनबो में फिर से दर्ज किया जाना चाहिए।

इससे हमें यह विचार आया कि स्थान के बारे में जानकारी का प्राथमिक स्रोत हमारी 1 सी प्रणाली होनी चाहिए, जिसमें सभी डेटा सही तरीके से दर्ज किए जाते हैं और समय के साथ (बिंदु यह है कि 1 सी डेटा के आधार पर, खाते बनते हैं, इसलिए 1 सी में डेटा की सही प्रविष्टि सभी के लिए है। KPI)। तो एक नई प्रणाली अवधारणा दिखाई दी ...

संकल्पना

पहली चीज़ जो हमने करने का फैसला किया, वह था इंटरनेट पर विज्ञापन अभियानों के आंकड़े एकत्र करने की प्रणाली को एक अलग उत्पाद - D1.Digital में अलग करना ।

नई अवधारणा में, हमने 1C से D1.Digital में विज्ञापन अभियानों और उनके अंदर नियुक्तियों के बारे में जानकारी लोड करने का फैसला किया, और फिर साइटों और AdServes सिस्टम से इन प्लेसमेंट के आंकड़े खींचे। यह उपयोगकर्ताओं के जीवन को बहुत सरल बनाने वाला था (और, हमेशा की तरह, डेवलपर्स में काम जोड़ें) और समर्थन की मात्रा को कम करें।

पहली समस्या जो हमें सामने आई, वह एक संगठनात्मक प्रकृति की थी और इस तथ्य से संबंधित थी कि हम एक कुंजी या विशेषता नहीं पा सकते थे जिसके द्वारा हम विभिन्न प्रणालियों से संस्थाओं की तुलना 1 सी से अभियानों और प्लेसमेंट से कर सकते थे। तथ्य यह है कि हमारी कंपनी में प्रक्रिया को इस तरह से व्यवस्थित किया जाता है कि विज्ञापन अभियान विभिन्न लोगों (मीडिया खिलाड़ियों, खरीद, आदि) द्वारा अलग-अलग प्रणालियों में दर्ज किए जाते हैं।

इस समस्या को हल करने के लिए, हमें एक अद्वितीय हैशेड कुंजी, DANBoID का आविष्कार करना पड़ा, जो विभिन्न प्रणालियों में संस्थाओं को एक साथ जोड़ देगा, और जो लोड किए गए डेटासेट में काफी आसानी से और स्पष्ट रूप से पहचाने जा सकते हैं। यह पहचानकर्ता प्रत्येक व्यक्ति प्लेसमेंट के लिए आंतरिक 1C प्रणाली में उत्पन्न होता है और सभी प्लेटफार्मों पर और सभी विज्ञापन प्रणालियों में अभियानों, प्लेसमेंट और काउंटरों में खुद को फेंक देता है। DANBoID को सभी स्थानों पर चिपकाए जाने की प्रथा को लागू करने में कुछ समय लगा, लेकिन हमने यह किया :)

तब हमें पता चला कि सभी साइटों में स्वचालित सांख्यिकी संग्रह के लिए एपीआई नहीं है, और यहां तक ​​कि जिनके पास एपीआई है वे सभी आवश्यक डेटा वापस नहीं करते हैं।

इस स्तर पर, हमने एकीकरण के लिए साइटों की सूची को महत्वपूर्ण रूप से कम करने और उन मुख्य साइटों पर ध्यान केंद्रित करने का निर्णय लिया, जो अधिकांश विज्ञापन अभियानों में शामिल हैं। इस सूची में विज्ञापन बाज़ार (Google, Yandex, Mail.ru), सोशल नेटवर्क (VK, Facebook, Twitter), मुख्य विज्ञापन और विश्लेषण प्रणाली (DCM, Adriver, Weborama, Google Analytics) और अन्य प्लेटफार्मों के सभी सबसे बड़े खिलाड़ी शामिल हैं।

हमारे द्वारा चुनी गई साइटों के थोक में एक एपीआई था जो हमें आवश्यक मैट्रिक्स देता था। उन मामलों में जब एपीआई नहीं था, या इसके पास आवश्यक डेटा नहीं था, हमने डेटा डाउनलोड करने के लिए रोज़ाना व्यापार मेल पर आने वाली रिपोर्टों का उपयोग किया (कुछ प्रणालियों में ऐसी रिपोर्टों को कॉन्फ़िगर करना संभव है, दूसरों में वे हमारे लिए ऐसी रिपोर्टों के विकास पर सहमत हुए)।

विभिन्न साइटों से डेटा का विश्लेषण करते समय, हमने पाया कि विभिन्न प्रणालियों में संस्थाओं का पदानुक्रम समान नहीं है। इसके अलावा, विभिन्न प्रणालियों की जानकारी को अलग-अलग तरीके से लोड किया जाना चाहिए।

इस समस्या को हल करने के लिए, SubDANBoID अवधारणा विकसित की गई थी। SubDANBoID का विचार काफी सरल है, हम साइट पर अभियान का मुख्य सार उत्पन्न किए गए DANBoID के साथ चिह्नित करते हैं, और हम साइट के अनन्य पहचानकर्ताओं के साथ सभी नेस्टेड संस्थाओं को अपलोड करते हैं और DANBoID सिद्धांत के पहचानकर्ता + एनएआईटी के प्रथम स्तर के पहचानकर्ता इकाई के डीएएनबीआईडी ​​सिद्धांत के अनुसार सबडैनबॉडी बनाते हैं। विभिन्न प्रणालियों में विज्ञापन अभियान और उन पर विस्तृत आँकड़े अपलोड करना।

हमें विभिन्न साइटों पर अभियानों तक पहुँच की समस्या को भी हल करना था। जैसा कि हमने ऊपर लिखा है, अभियान के लिए एक अलग तकनीकी खाते तक पहुंच को प्रस्तुत करने का तंत्र हमेशा लागू नहीं होता है। इसलिए, हमें इन टोकन के लिए टोकन और अपडेट तंत्र का उपयोग करके OAuth के माध्यम से स्वचालित प्राधिकरण के लिए एक बुनियादी ढांचे का विकास करना था।

लेख में आगे हम समाधान की वास्तुकला और कार्यान्वयन के तकनीकी विवरणों के बारे में अधिक विस्तार से वर्णन करने का प्रयास करेंगे।

समाधान वास्तुकला 1.0

एक नए उत्पाद के कार्यान्वयन की शुरुआत करते हुए, हम समझ गए कि नई साइटों को जोड़ने की संभावना के लिए प्रदान करना तुरंत आवश्यक था, इसलिए हमने माइक्रोसर्विस आर्किटेक्चर के रास्ते का पालन करने का फैसला किया।

आर्किटेक्चर को डिजाइन करते समय, हमने अलग-अलग सर्विस कनेक्टर में सभी बाहरी सिस्टमों - 1 सी, विज्ञापन प्लेटफार्मों और विज्ञापन योग्य सिस्टमों को एकतरफा किया।
मुख्य विचार यह है कि साइटों के सभी कनेक्टर्स में एक ही एपीआई है और यह एडेप्टर हैं जो साइट एपीआई को हमारे सुविधाजनक इंटरफ़ेस में लाते हैं।

हमारे उत्पाद के केंद्र में एक वेब एप्लिकेशन है, जो एक मोनोलिथ है, जिसे डिज़ाइन किया गया है ताकि इसे सेवाओं में आसानी से जोड़ा जा सके। यह एप्लिकेशन डाउनलोड किए गए डेटा को संसाधित करने, विभिन्न प्रणालियों के आंकड़ों की तुलना करने और सिस्टम के उपयोगकर्ताओं को प्रस्तुत करने के लिए जिम्मेदार है।

वेब एप्लिकेशन के साथ कनेक्टर्स को संप्रेषित करने के लिए, हमें एक अतिरिक्त सेवा बनानी होगी, जिसे हम कनेक्टर प्रॉक्सी कहते हैं। यह सेवा डिस्कवरी और टास्क समयबद्धक के कार्य करता है। यह सेवा हर रात प्रत्येक कनेक्टर के लिए डेटा संग्रह कार्य करती है। एक संदेश दलाल को जोड़ने की तुलना में एक सेवा परत लिखना आसान था, और हमारे लिए यह परिणाम जितना जल्दी हो सके महत्वपूर्ण था।

सादगी और विकास की गति के लिए, हमने यह भी तय किया कि सभी सेवाएं एक वेब एपीआई होगी। इससे एक सबूत-अवधारणा को जल्दी से इकट्ठा करना और यह सत्यापित करना संभव हो गया कि पूरी डिजाइन काम कर रही थी।



एक अलग, बल्कि कठिन, कार्य विभिन्न अलमारियाँ से डेटा एकत्र करने के लिए पहुंच स्थापित कर रहा था, जो कि हमने तय किया था, जिसे वेब इंटरफ़ेस के माध्यम से उपयोगकर्ताओं द्वारा किया जाना चाहिए। इसमें दो अलग-अलग चरण होते हैं: पहला, OAuth के माध्यम से उपयोगकर्ता खाते तक पहुंचने के लिए एक टोकन जोड़ता है, और फिर एक विशिष्ट खाते से क्लाइंट के लिए डेटा संग्रह सेट करता है। OAuth के माध्यम से एक टोकन प्राप्त करना आवश्यक है, क्योंकि, जैसा कि हमने पहले ही लिखा था, साइट पर वांछित कैबिनेट तक पहुंच को सौंपना हमेशा संभव नहीं होता है।

साइटों से एक कैबिनेट चुनने के लिए एक सार्वभौमिक तंत्र बनाने के लिए, हमें कनेक्टर्स एपीआई में एक विधि को जोड़ना होगा जो JSON स्कीमा को प्रस्तुत करता है, जिसे संशोधित JSONEditor घटक का उपयोग करके प्रपत्र में प्रदान किया जाता है। इसलिए उपयोगकर्ता उन खातों को चुनने में सक्षम थे जिनसे डेटा डाउनलोड किया जा सके।

साइटों पर मौजूद अनुरोध सीमाओं का पालन करने के लिए, हम एक ही टोकन में सेटिंग्स के लिए अनुरोध को जोड़ते हैं, लेकिन हम समानांतर में विभिन्न टोकन की प्रक्रिया कर सकते हैं।

हमने एक वेब एप्लिकेशन और कनेक्टर्स के लिए डाउनलोड करने योग्य डेटा के लिए एक रिपॉजिटरी के रूप में MongoDB को चुना, जिसने हमें विकास के शुरुआती चरणों में डेटा संरचना के बारे में ज्यादा परेशान नहीं होने दिया, जब एप्लिकेशन मॉडल एक दिन बाद बदल जाता है।

जल्द ही हमें पता चला कि सभी डेटा MongoDB में अच्छी तरह से फिट नहीं हैं और उदाहरण के लिए, एक रिलेशनल डेटाबेस में स्टोर करने के लिए दैनिक आंकड़े अधिक सुविधाजनक हैं। इसलिए, उन कनेक्टरों के लिए जिनकी डेटा संरचना एक रिलेशनल डेटाबेस के लिए अधिक उपयुक्त है, हमने भंडारण के रूप में PostgreSQL या MS SQL सर्वर का उपयोग करना शुरू कर दिया।

चयनित वास्तुकला और प्रौद्योगिकी ने हमें D1.Digital उत्पाद को अपेक्षाकृत जल्दी बनाने और लॉन्च करने की अनुमति दी। उत्पाद विकास के दो वर्षों में, हमने 23 साइट कनेक्टर विकसित किए, तीसरे पक्ष के एपीआई के साथ काम करने के लिए अमूल्य अनुभव प्राप्त किया, सीखा कि विभिन्न साइटों के नुकसान को कैसे कम किया जाए, जिनमें से प्रत्येक का अपना स्वयं का था, एपीआई के विकास में कम से कम 3 साइटों का योगदान दिया, स्वचालित रूप से लगभग 15,000 अभियानों पर जानकारी डाउनलोड की और 80,000 से अधिक प्लेसमेंट में, हमने उत्पाद के बारे में उपयोगकर्ताओं से बहुत सारी प्रतिक्रिया एकत्र की और इस प्रतिक्रिया के आधार पर कई बार उत्पाद की मुख्य प्रक्रिया को बदलने में कामयाब रहे।

समाधान वास्तुकला 2.0

D1.Digital के विकास की शुरुआत के दो साल बीत चुके हैं। सिस्टम पर लोड में निरंतर वृद्धि और कभी नए डेटा स्रोतों के उद्भव ने धीरे-धीरे मौजूदा समाधान वास्तुकला में समस्याओं का खुलासा किया।

पहली समस्या साइटों से डाउनलोड किए गए डेटा की मात्रा से संबंधित है। हमें इस तथ्य का सामना करना पड़ा कि सबसे बड़ी साइटों से सभी आवश्यक डेटा एकत्र करना और अपडेट करना बहुत अधिक समय लेने लगा। उदाहरण के लिए, AdRiver विज्ञापन देने वाली प्रणाली पर डेटा एकत्र करना, जिसके साथ हम अधिकांश स्थानों के आँकड़ों को ट्रैक करते हैं, लगभग 12 घंटे लगते हैं।

इस समस्या को हल करने के लिए, हमने साइटों से डेटा डाउनलोड करने के लिए सभी प्रकार की रिपोर्टों का उपयोग करना शुरू कर दिया है, हम साइटों के साथ मिलकर उनके एपीआई को विकसित करने की कोशिश कर रहे हैं ताकि इसकी गति हमारी जरूरतों को पूरा कर सके, और जितना संभव हो उतना डेटा लोड करने में समानांतर हो।

एक अन्य समस्या डाउनलोड किए गए डेटा के प्रसंस्करण की है। अब, प्लेसमेंट पर नए आंकड़ों के आने के साथ, मैट्रिक्स को पुनर्गणना करने की एक बहु-चरण प्रक्रिया शुरू की जाती है, जिसमें कच्चे डेटा को लोड करना, प्रत्येक साइट के लिए कुल मीट्रिक की गणना करना, विभिन्न स्रोतों से डेटा की तुलना करना और अभियान के लिए सारांश मीट्रिक की गणना करना शामिल है। यह वेब एप्लिकेशन पर एक बड़े लोड का कारण बनता है, जो सभी गणना करता है। कई बार, पुनरावर्ती की प्रक्रिया में, एप्लिकेशन सर्वर पर सभी मेमोरी को खाता है, लगभग 10-15 जीबी, जो सिस्टम के साथ उपयोगकर्ता के काम पर सबसे हानिकारक प्रभाव पड़ता है।

उत्पाद के आगे विकास के लिए पहचानी गई समस्याओं और भव्य योजनाओं ने हमें एप्लिकेशन आर्किटेक्चर को संशोधित करने की आवश्यकता के लिए प्रेरित किया।

हमने कनेक्टर्स के साथ शुरुआत की।
हमने देखा कि सभी कनेक्टर एक ही मॉडल के अनुसार काम करते हैं, इसलिए हमने एक पाइपलाइन-कन्वेयर बनाया जिसमें कनेक्टर को बनाने के लिए आपको केवल चरणों के तर्क को प्रोग्राम करना था, बाकी सार्वभौमिक था। यदि किसी भी कनेक्टर को सुधारने की आवश्यकता है, तो हम कनेक्टर को अंतिम रूप देते समय इसे तुरंत एक नए ढांचे में स्थानांतरित करेंगे।

समानांतर में, हमने कनेक्टर्स को डॉकटर और कुबेरनेट्स में रखना शुरू कर दिया।
हमने लंबे समय तक कुबेरनेट्स में जाने की योजना बनाई, सीआई / सीडी सेटिंग्स के साथ प्रयोग किया, लेकिन केवल तभी शुरू हुआ जब एक कनेक्टर ने एक त्रुटि के कारण सर्वर पर 20 जीबी से अधिक मेमोरी खाना शुरू कर दिया, लगभग सभी प्रक्रियाओं को मार दिया। जांच के दौरान, कनेक्टर को कुबरनेटेस क्लस्टर में स्थानांतरित कर दिया गया था, जहां अंततः यह त्रुटि बनी रहने पर भी बनी रही।

काफी जल्दी, हमने महसूस किया कि कुबेरनेट्स सुविधाजनक था, और छह महीनों के भीतर हमने 7 कनेक्टर और कनेक्टर्स प्रॉक्सी को उत्पादन क्लस्टर में स्थानांतरित कर दिया, जो सबसे अधिक संसाधनों का उपभोग करते हैं।

कनेक्टर्स के बाद, हमने बाकी एप्लिकेशन के आर्किटेक्चर को बदलने का फैसला किया।
मुख्य समस्या यह थी कि डेटा कनेक्टर्स से बड़े बंडलों में समीपता के लिए आता है, और फिर उन्होंने डेनबीआईडी ​​पर हमला किया और प्रसंस्करण के लिए एक केंद्रीय वेब एप्लिकेशन को स्थानांतरित कर दिया। बड़ी संख्या में मैट्रिक्स की गणना होने के कारण, एप्लिकेशन पर एक बड़ा लोड होता है।

, , web , , , - .

2.0.

, Web API RabbitMQ MassTransit . Connectors Proxy, Connectors Hub. , , .

केंद्रीय वेब एप्लिकेशन से, हम साइटों से प्लेसमेंट और आंकड़ों के बारे में अलग-अलग सेवाओं की जानकारी में अलग हो गए, जिससे प्लेसमेंट के स्तर पर केवल पहले से गणना की गई और एकत्रित आंकड़ों से अनावश्यक गणना से छुटकारा पाना और स्टोर करना संभव हो गया। हमने कच्चे डेटा के आधार पर बुनियादी आँकड़ों की गणना के लिए तर्क को फिर से लिखा और अनुकूलित किया।

इसी समय, हम सभी सेवाओं और अनुप्रयोगों को docker और Kubernetes में स्थानांतरित कर रहे हैं, ताकि समाधान अधिक आसानी से हो और प्रबंधन करने में सुविधाजनक हो।

अब हम कहां हैं

Proof-of-concept 2.0 D1.Digital . — 20 , , , , .

, API, .

, , adserving .

, web , Kubernetes. , , .

, MongoDB. SQL-, , , , .

, , :)

R&D Dentsu Aegis Network Russia: ( shmiigaa ), ( hitexx )