हामीले कसरी अनलाइन साइटहरूबाट विज्ञापन अभियानहरूमा डेटा सङ्कलन गर्यौं (उत्पादनको लागि काँटेदार बाटो)

यस्तो देखिन्छ कि अनलाइन विज्ञापनको क्षेत्र सम्भव भएसम्म प्राविधिक रूपमा उन्नत र स्वचालित हुनुपर्छ। निस्सन्देह, किनभने Yandex, Mail.Ru, Google र Facebook जस्ता तिनीहरूको क्षेत्रमा यस्ता दिग्गज र विशेषज्ञहरू काम गर्छन्। तर, यो बाहिर गएको रूपमा, पूर्णताको कुनै सीमा छैन र त्यहाँ सधैं स्वचालित गर्न केहि छ।

स्रोत

सञ्चार समूह Dentsu Aegis नेटवर्क रूस डिजिटल विज्ञापन बजारमा सबैभन्दा ठूलो खेलाडी हो र सक्रिय रूपमा टेक्नोलोजीमा लगानी गर्दैछ, यसको व्यापार प्रक्रियाहरू अनुकूलन र स्वचालित गर्न प्रयास गर्दैछ। अनलाइन विज्ञापन बजारको अनसुलझे समस्याहरू मध्ये एक विभिन्न इन्टरनेट प्लेटफर्महरूबाट विज्ञापन अभियानहरूमा तथ्याङ्क सङ्कलन गर्ने कार्य भएको छ। यस समस्याको समाधान अन्ततः उत्पादनको निर्माणमा परिणाम भयो D1. डिजिटल (DiVan को रूपमा पढ्नुहोस्), जसको विकास हामी कुरा गर्न चाहन्छौं।

किन?

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

सेवाहरू जस्तै Improvado, Roistat, Supermetrics, SegmentStream ले प्लेटफर्महरू, सामाजिक सञ्जालहरू र Google एनालिटिक्सहरूसँग एकीकरण प्रस्ताव गर्दछ, र यसले सुविधाजनक विश्लेषण र विज्ञापन अभियानहरूको नियन्त्रणको लागि विश्लेषणात्मक ड्यासबोर्डहरू निर्माण गर्न सम्भव बनाउँछ। हामीले हाम्रो उत्पादन विकास गर्न सुरु गर्नु अघि, हामीले साइटहरूबाट डाटा सङ्कलन गर्न यी प्रणालीहरू प्रयोग गर्ने प्रयास गर्यौं, तर दुर्भाग्यवश, तिनीहरूले हाम्रा समस्याहरू समाधान गर्न सकेनन्।

मुख्य समस्या यो थियो कि परीक्षण गरिएका उत्पादनहरू डाटा स्रोतहरूमा आधारित थिए, साइटद्वारा प्लेसमेन्ट तथ्याङ्कहरू प्रदर्शन गर्दै, र विज्ञापन अभियानहरूमा तथ्याङ्कहरू जम्मा गर्ने क्षमता प्रदान गर्दैनन्। यो दृष्टिकोणले हामीलाई एकै ठाउँमा विभिन्न साइटहरूबाट तथ्याङ्कहरू हेर्न र अभियानको अवस्थालाई समग्र रूपमा विश्लेषण गर्न अनुमति दिँदैन।

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

2. अनलाइन विज्ञापन बजार हरेक वर्ष बढ्दै गइरहेको छ, र 2018 मा, विज्ञापन बजेटको सन्दर्भमा, यसले परम्परागत रूपमा सबैभन्दा ठूलो टिभी विज्ञापन बजारलाई पछाडि पार्यो। त्यसैले त्यहाँ एक स्केल छ.

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

4. इन्टरनेटमा विज्ञापन सूचीका मालिकहरूसँग पहिले नै तथ्याङ्क सङ्कलन र विज्ञापन खाताहरूमा प्रदर्शन गर्न पूर्वाधार छ, र तिनीहरूले यस डाटाको लागि API प्रदान गर्न सक्षम हुनेछन् भन्ने लाग्थ्यो। यसको मतलब यो प्राविधिक रूपमा कार्यान्वयन गर्न सम्भव छ। तुरुन्तै भनौं कि यो यति सरल थिएन।

सामान्यतया, परियोजनाको कार्यान्वयनको लागि सबै पूर्व शर्तहरू हामीलाई स्पष्ट थिए, र हामी परियोजनालाई जीवनमा ल्याउन दौड्यौं ...

भव्य योजना

सुरु गर्नको लागि, हामीले एक आदर्श प्रणालीको दर्शन बनायौं:

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

पहिलो लाजमर्दो कुरा लम्पी हो

सफ्टवेयर विकासका लचिलो सिद्धान्तहरू (चपल, सबै चीजहरू) प्रति हाम्रो प्रतिबद्धतालाई ध्यानमा राख्दै, हामीले पहिले MVP विकास गर्ने निर्णय गर्यौं र त्यसपछि पुनरावृत्ति रूपमा इच्छित लक्ष्य तिर लाग्ने निर्णय गर्यौं।
हामीले हाम्रो उत्पादनमा आधारित MVP निर्माण गर्ने निर्णय गर्यौं DANBo (Dentsu Aegis नेटवर्क बोर्ड), जुन हाम्रा ग्राहकहरूको विज्ञापन अभियानहरूमा सामान्य जानकारी भएको वेब अनुप्रयोग हो।

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

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

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

यो देखियो, स्पष्ट रूपमा, डरलाग्दो:

डाउनलोड गरिएको डाटा डाटाबेसमा सुरक्षित गरियो, र त्यसपछि अलग-अलग सेवाहरूले तिनीहरूबाट साइटहरूमा अभियान पहिचानकर्ताहरू सङ्कलन गरे र तिनीहरूमा तथ्याङ्कहरू डाउनलोड गरे।

प्रत्येक साइटको लागि, एउटा छुट्टै विन्डोज सेवा लेखिएको थियो, जुन दिनमा एक पटक साइटको API मा एक सेवा खाता अन्तर्गत जान्छ र निर्दिष्ट अभियान आईडीहरूको लागि तथ्याङ्कहरू डाउनलोड गर्दछ। विज्ञापन प्रणालीमा पनि त्यस्तै भयो।

डाउनलोड गरिएको डाटा सानो अनुकूलन ड्यासबोर्डको रूपमा इन्टरफेसमा प्रदर्शित गरिएको थियो:

हाम्रो लागि अप्रत्याशित रूपमा, MVP ले काम गर्न थाल्यो र इन्टरनेटमा विज्ञापन अभियानहरूमा हालको तथ्याङ्कहरू डाउनलोड गर्न थाल्यो। हामीले धेरै ग्राहकहरूमा प्रणाली लागू गर्यौं, तर मापन गर्ने प्रयास गर्दा, हामीले गम्भीर समस्याहरूको सामना गर्‍यौं:

• मुख्य समस्या प्रणाली मा लोड लागि डाटा तयारी को जटिलता थियो। साथै, प्लेसमेन्ट डाटा लोड गर्नु अघि कडा रूपमा निश्चित ढाँचामा रूपान्तरण गर्नुपर्थ्यो। डाउनलोड फाइलमा विभिन्न साइटहरूबाट संस्था पहिचानकर्ताहरू समावेश गर्न आवश्यक थियो। हामी यस तथ्यको सामना गरिरहेका छौं कि प्राविधिक रूपमा अप्रशिक्षित प्रयोगकर्ताहरूलाई साइटमा यी पहिचानकर्ताहरू कहाँ फेला पार्ने र फाइलमा तिनीहरूलाई प्रविष्ट गर्न आवश्यक छ भनेर व्याख्या गर्न धेरै गाह्रो छ। साइटहरूमा अभियान चलाउने विभागहरूमा कर्मचारीहरूको संख्या र कारोबारलाई ध्यानमा राख्दै, यसले हाम्रो पक्षमा ठूलो मात्रामा समर्थन प्राप्त गर्यो, जुन हामी पूर्ण रूपमा खुसी थिएनौं।
• अर्को समस्या यो थियो कि सबै विज्ञापन प्लेटफर्महरूमा अन्य खाताहरूमा विज्ञापन अभियानहरूमा पहुँच प्रत्यायोजन गर्ने संयन्त्रहरू थिएनन्। तर एक प्रतिनिधिमण्डल संयन्त्र उपलब्ध भए पनि, सबै विज्ञापनदाताहरू तेस्रो-पक्ष खाताहरूमा उनीहरूको अभियानहरूमा पहुँच प्रदान गर्न इच्छुक थिएनन्।
• एउटा महत्त्वपूर्ण कारक भनेको प्रयोगकर्ताहरू बीचको आक्रोश थियो जुन तथ्यले गर्दा सबै योजनाबद्ध सूचकहरू र प्लेसमेन्ट विवरणहरू जुन तिनीहरूले पहिले नै हाम्रो 1C लेखा प्रणालीमा प्रवेश गरे, तिनीहरूले पुन: प्रवेश गर्नुपर्छ। DANBo.

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

अवधारणा

हामीले गर्ने निर्णय गरेको पहिलो कुरा इन्टरनेटमा विज्ञापन अभियानहरूमा तथ्याङ्क सङ्कलन गर्न प्रणालीलाई छुट्टै उत्पादनमा अलग गर्ने थियो - D1. डिजिटल.

नयाँ अवधारणामा, हामीले लोड गर्ने निर्णय गर्यौं D1. डिजिटल 1C बाट तिनीहरू भित्रको विज्ञापन अभियानहरू र प्लेसमेन्टहरूमा जानकारी, र त्यसपछि यी प्लेसमेन्टहरूमा साइटहरू र AdServing प्रणालीहरूबाट तथ्याङ्कहरू तान्नुहोस्। यसले प्रयोगकर्ताहरूको लागि जीवनलाई महत्त्वपूर्ण रूपमा सरल बनाउने (र, सामान्य रूपमा, विकासकर्ताहरूलाई थप काम थप्ने) र समर्थनको मात्रा घटाउने अपेक्षा गरिएको थियो।

हामीले सामना गरेको पहिलो समस्या संगठनात्मक प्रकृतिको थियो र यो तथ्यसँग सम्बन्धित थियो कि हामीले एउटा कुञ्जी वा चिन्ह फेला पार्न सकेनौं जसद्वारा हामीले विभिन्न प्रणालीहरूका संस्थाहरूलाई 1C बाट अभियान र प्लेसमेन्टहरूसँग तुलना गर्न सक्छौं। तथ्य यो हो कि हाम्रो कम्पनीमा प्रक्रिया यस्तो तरिकाले डिजाइन गरिएको छ कि विज्ञापन अभियानहरू विभिन्न व्यक्तिहरू (मिडिया योजनाकारहरू, खरिदहरू, आदि) द्वारा विभिन्न प्रणालीहरूमा प्रवेश गरिन्छ।

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

त्यसपछि हामीले पत्ता लगायौं कि सबै साइटहरूमा स्वचालित रूपमा तथ्याङ्कहरू सङ्कलन गर्न API छैन, र तिनीहरूसँग पनि API छ, यसले सबै आवश्यक डेटा फिर्ता गर्दैन।

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

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

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

यो समस्या समाधान गर्न, SubDANBoID अवधारणा विकसित गरिएको थियो। SubDANBoID को विचार एकदम सरल छ, हामी उत्पन्न गरिएको DANBoID को साथ साइटमा अभियानको मुख्य इकाई चिन्ह लगाउँछौं, र हामी अद्वितीय साइट पहिचानकर्ताहरू सहित सबै नेस्टेड संस्थाहरू अपलोड गर्छौं र DANBoID सिद्धान्त + पहिलो स्तरको पहिचानकर्ता अनुसार SubDANBoID बनाउँछौं। नेस्टेड इकाई + दोस्रो स्तरको नेस्टेड इकाईको पहिचानकर्ता +... यो दृष्टिकोणले हामीलाई विभिन्न प्रणालीहरूमा विज्ञापन अभियानहरू जडान गर्न र तिनीहरूमा विस्तृत तथ्याङ्कहरू डाउनलोड गर्न अनुमति दियो।

हामीले विभिन्न प्लेटफर्महरूमा अभियानहरूमा पहुँचको समस्या पनि समाधान गर्नुपर्‍यो। हामीले माथि लेखेझैं, अभियानको पहुँचलाई छुट्टै प्राविधिक खातामा प्रत्यायोजन गर्ने संयन्त्र सधैं लागू हुँदैन। तसर्थ, हामीले यी टोकनहरू अद्यावधिक गर्नका लागि टोकनहरू र संयन्त्रहरू प्रयोग गरेर OAuth मार्फत स्वचालित प्राधिकरणको लागि पूर्वाधार विकास गर्नुपर्‍यो।

लेखमा पछि हामी समाधानको वास्तुकला र कार्यान्वयनको प्राविधिक विवरणहरू थप विवरणमा वर्णन गर्ने प्रयास गर्नेछौं।

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

नयाँ उत्पादनको कार्यान्वयन सुरु गर्दा, हामीले बुझ्यौं कि हामीले तुरुन्तै नयाँ साइटहरू जडान गर्ने सम्भावना प्रदान गर्न आवश्यक छ, त्यसैले हामीले माइक्रोसर्भिस आर्किटेक्चरको मार्ग अनुसरण गर्ने निर्णय गर्यौं।

वास्तुकला डिजाइन गर्दा, हामीले सबै बाह्य प्रणालीहरू - 1C, विज्ञापन प्लेटफर्महरू र विज्ञापन प्रणालीहरू - अलग-अलग सेवाहरूमा कनेक्टरहरू छुट्यायौं।
मुख्य विचार यो हो कि साइटहरूमा सबै कनेक्टरहरू एउटै एपीआई हुन्छन् र एडेप्टरहरू हुन् जसले साइट API लाई हाम्रो लागि सुविधाजनक इन्टरफेसमा ल्याउँदछ।

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

कनेक्टरहरू र वेब अनुप्रयोगहरू बीच सञ्चार गर्न, हामीले एउटा अतिरिक्त सेवा सिर्जना गर्नुपर्‍यो, जसलाई हामीले कनेक्टर प्रोक्सी भन्यौं। यसले सेवा खोज र कार्य तालिकाको कार्यहरू गर्दछ। यो सेवाले हरेक रात प्रत्येक कनेक्टरको लागि डाटा सङ्कलन कार्यहरू चलाउँछ। सेवा तह लेख्नु सन्देश ब्रोकर जडान गर्नु भन्दा सजिलो थियो, र हाम्रो लागि यो सकेसम्म चाँडो परिणाम प्राप्त गर्न महत्त्वपूर्ण थियो।

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

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

साइटहरूबाट खाता चयन गर्नको लागि एक सार्वभौमिक संयन्त्र सिर्जना गर्न, हामीले JSON स्कीमा फिर्ता गर्ने कनेक्टर API मा एक विधि थप्नुपर्थ्यो, जुन परिमार्जित JSONEditor कम्पोनेन्ट प्रयोग गरी फारममा रेन्डर गरिएको छ। यसरी, प्रयोगकर्ताहरूले डाटा डाउनलोड गर्ने खाताहरू चयन गर्न सक्षम थिए।

साइटहरूमा अवस्थित अनुरोध सीमाहरूको पालना गर्न, हामी एक टोकन भित्र सेटिङहरूको लागि अनुरोधहरू संयोजन गर्छौं, तर हामी समानान्तर रूपमा विभिन्न टोकनहरू प्रशोधन गर्न सक्छौं।

हामीले वेब एप्लिकेसन र कनेक्टरहरू दुवैका लागि लोड गरिएको डाटाको भण्डारणको रूपमा MongoDB रोज्यौं, जसले हामीलाई विकासको प्रारम्भिक चरणहरूमा डेटा संरचनाको बारेमा धेरै चिन्ता नगर्न अनुमति दियो, जब अनुप्रयोगको वस्तु मोडेल हरेक दिन परिवर्तन हुन्छ।

हामीले चाँडै पत्ता लगायौं कि सबै डेटा MongoDB मा राम्रोसँग फिट हुँदैन र, उदाहरणका लागि, दैनिक तथ्याङ्कहरू रिलेसनल डाटाबेसमा भण्डारण गर्न सजिलो छ। तसर्थ, कनेक्टरहरूका लागि जसको डेटा संरचना रिलेशनल डाटाबेसको लागि बढी उपयुक्त छ, हामीले PostgreSQL वा MS SQL सर्भर भण्डारणको रूपमा प्रयोग गर्न थाल्यौं।

छनोट गरिएको वास्तुकला र प्रविधिहरूले हामीलाई D1.Digital उत्पादन तुलनात्मक रूपमा छिटो निर्माण गर्न र लन्च गर्न अनुमति दियो। उत्पादन विकासको दुई वर्षमा, हामीले साइटहरूमा 23 कनेक्टरहरू विकास गर्‍यौं, तेस्रो-पक्ष API सँग काम गर्ने अमूल्य अनुभव प्राप्त गर्‍यौं, विभिन्न साइटहरूको समस्याहरूबाट बच्न सिक्यौं, जुन प्रत्येकको आफ्नै थियो, कम्तिमा 3 को API को विकासमा योगदान गर्‍यौं। साइटहरू, लगभग 15 अभियानहरू र 000 भन्दा बढी प्लेसमेन्टहरूमा स्वचालित रूपमा डाउनलोड गरिएका जानकारीहरू, उत्पादनको सञ्चालनमा प्रयोगकर्ताहरूबाट धेरै प्रतिक्रियाहरू सङ्कलन गरियो र यस प्रतिक्रियाको आधारमा धेरै पटक उत्पादनको मुख्य प्रक्रिया परिवर्तन गर्न व्यवस्थित गरियो।

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

विकास निर्माण सुरु भएको दुई वर्ष बितिसकेको छ D1. डिजिटल। प्रणालीमा लोडमा निरन्तर वृद्धि र अधिक र अधिक नयाँ डेटा स्रोतहरूको उदयले बिस्तारै अवस्थित समाधान वास्तुकलामा समस्याहरू प्रकट गर्यो।

पहिलो समस्या साइटहरु बाट डाउनलोड डाटा को मात्रा संग सम्बन्धित छ। हामीले यस तथ्यको सामना गर्‍यौं कि सबैभन्दा ठूलो साइटहरूबाट सबै आवश्यक डाटा सङ्कलन र अद्यावधिक गर्न धेरै समय लाग्न थाल्यो। उदाहरणका लागि, AdRiver adserving प्रणालीबाट डेटा सङ्कलन गर्न, जसको साथमा हामीले धेरैजसो स्थानहरूका लागि तथ्याङ्कहरू ट्र्याक गर्छौं, लगभग 12 घण्टा लाग्छ।

यस समस्याको समाधान गर्न, हामीले साइटहरूबाट डाटा डाउनलोड गर्न सबै प्रकारका रिपोर्टहरू प्रयोग गर्न थाल्यौं, हामी तिनीहरूको एपीआईलाई साइटहरूसँग मिलेर विकास गर्ने प्रयास गरिरहेका छौं ताकि यसको सञ्चालनको गतिले हाम्रो आवश्यकताहरू पूरा गर्छ, र डाटा डाउनलोडलाई सकेसम्म समानान्तर बनाउन।

अर्को समस्या डाउनलोड गरिएको डाटाको प्रशोधनसँग सम्बन्धित छ। अब, जब नयाँ नियुक्ति तथ्याङ्कहरू आइपुग्छन्, मेट्रिक्स पुन: गणना गर्ने बहु-चरण प्रक्रिया सुरु हुन्छ, जसमा कच्चा डाटा लोड गर्ने, प्रत्येक साइटको लागि एकत्रित मेट्रिक्स गणना गर्ने, विभिन्न स्रोतहरूबाट डेटा एक-अर्कासँग तुलना गर्ने, र अभियानका लागि सारांश मेट्रिक्स गणना गर्ने समावेश छ। यसले वेब अनुप्रयोगमा धेरै भार निम्त्याउँछ जुन सबै गणनाहरू गर्दछ। धेरै पटक, पुन: गणना प्रक्रियाको क्रममा, अनुप्रयोगले सर्भरमा सबै मेमोरी उपभोग गर्‍यो, लगभग 10-15 GB, जसले प्रणालीसँग प्रयोगकर्ताहरूको काममा सबैभन्दा हानिकारक प्रभाव पारेको थियो।

पहिचान गरिएका समस्याहरू र उत्पादनको थप विकासको लागि महत्वाकांक्षी योजनाहरूले हामीलाई एप्लिकेसन आर्किटेक्चरमा पुनर्विचार गर्नुपर्ने आवश्यकतातर्फ डोऱ्‍यायो।

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

एकै समयमा, हामीले Docker र Kubernetes मा कनेक्टरहरू तैनाथ गर्न थाल्यौं।
हामीले धेरै लामो समयको लागि कुबेरनेटमा सार्ने योजना बनायौं, CI/CD सेटिङहरू प्रयोग गर्‍यौं, तर एक कनेक्टरले त्रुटिको कारणले सर्भरमा 20 GB भन्दा बढी मेमोरी खान थालेपछि मात्र सार्न थाल्यौं, व्यावहारिक रूपमा अन्य प्रक्रियाहरूलाई मार्दै। । अनुसन्धानको क्रममा, कनेक्टरलाई Kubernetes क्लस्टरमा सारियो, जहाँ यो अन्ततः रह्यो, त्रुटि ठीक भएपछि पनि।

धेरै चाँडै हामीले Kubernetes सुविधाजनक थियो भनेर बुझ्यौं, र छ महिना भित्र हामीले 7 कनेक्टरहरू र कनेक्टर्स प्रोक्सी, जसले सबैभन्दा धेरै स्रोतहरू उपभोग गर्छ, उत्पादन क्लस्टरमा स्थानान्तरण गर्यौं।

जडानकर्ताहरू पछ्याउँदै, हामीले बाँकी अनुप्रयोगको वास्तुकला परिवर्तन गर्ने निर्णय गर्यौं।
मुख्य समस्या यो थियो कि डाटा कनेक्टरहरूबाट प्रोक्सीहरूमा ठूला ब्याचहरूमा आउँछ, र त्यसपछि DANBoID मा हिट हुन्छ र प्रक्रियाको लागि केन्द्रीय वेब अनुप्रयोगमा पठाइन्छ। मेट्रिक्स पुन: गणनाहरूको ठूलो संख्याको कारणले गर्दा, अनुप्रयोगमा ठूलो भार छ।

यो पनि व्यक्तिगत डेटा सङ्कलन कार्यहरूको स्थिति निगरानी गर्न र केन्द्रीय वेब अनुप्रयोगमा जडानकर्ताहरू भित्र हुने त्रुटिहरू रिपोर्ट गर्न धेरै गाह्रो साबित भयो ताकि प्रयोगकर्ताहरूले के भइरहेको छ र किन डेटा सङ्कलन भइरहेको छैन भनेर देख्न सकून्।

यी समस्याहरू समाधान गर्न, हामीले आर्किटेक्चर 2.0 विकास गरेका छौं।

आर्किटेक्चरको नयाँ संस्करण बीचको मुख्य भिन्नता भनेको वेब API को सट्टामा, हामी सेवाहरू बीच सन्देशहरू आदानप्रदान गर्न RabbitMQ र MassTransit पुस्तकालय प्रयोग गर्छौं। यो गर्नको लागि, हामीले कनेक्टर्स प्रोक्सीलाई लगभग पूर्ण रूपमा पुन: लेख्नुपर्‍यो, यसलाई कनेक्टर्स हब बनाउँदै। नाम परिवर्तन गरिएको थियो किनभने सेवाको मुख्य भूमिका अब कनेक्टरहरू र पछाडि अनुरोधहरू पठाउनमा होइन, तर कनेक्टरहरूबाट मेट्रिक्सको सङ्कलन व्यवस्थापनमा।

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

एकै समयमा, हामी सबै सेवाहरू र अनुप्रयोगहरू Docker र Kubernetes मा स्थानान्तरण गर्दैछौं समाधान मापन गर्न सजिलो र व्यवस्थापन गर्न थप सुविधाजनक बनाउन।

हामी अहिले कहाँ छौं

अवधारणाको प्रमाण वास्तुकला २.० उत्पादन D1. डिजिटल कनेक्टरहरूको सीमित सेटको साथ परीक्षण वातावरणमा तयार र काम गर्दै। के गर्न बाँकी छ अर्को 20 कनेक्टरहरू नयाँ प्लेटफर्ममा पुन: लेख्न, डाटा सही रूपमा लोड गरिएको छ र सबै मेट्रिकहरू सही रूपमा गणना गरिएको छ भनेर परीक्षण गर्नुहोस्, र सम्पूर्ण डिजाइनलाई उत्पादनमा रोल आउट गर्नुहोस्।

वास्तवमा, यो प्रक्रिया बिस्तारै हुनेछ र हामीले पुरानो एपीआईहरूसँग सबै काम गर्नको लागि पछाडि अनुकूलता छोड्नुपर्छ।

हाम्रा तत्काल योजनाहरूमा नयाँ जडानकर्ताहरूको विकास, नयाँ प्रणालीहरूसँग एकीकरण र जडान गरिएका साइटहरू र विज्ञापन प्रणालीहरूबाट डाउनलोड गरिएका डेटाको सेटमा थप मेट्रिकहरू थप्ने समावेश छ।

हामी केन्द्रीय वेब अनुप्रयोग सहित सबै अनुप्रयोगहरू डकर र कुबर्नेट्समा स्थानान्तरण गर्ने योजना पनि गर्छौं। नयाँ वास्तुकलासँग जोडेर, यसले उपभोग गरिएका स्रोतहरूको परिचालन, अनुगमन र नियन्त्रणलाई महत्त्वपूर्ण रूपमा सरल बनाउनेछ।

अर्को विचार भनेको तथ्याङ्कहरू भण्डारण गर्नको लागि डाटाबेसको छनोटको साथ प्रयोग गर्नु हो, जुन हाल MongoDB मा भण्डार गरिएको छ। हामीले पहिले नै धेरै नयाँ कनेक्टरहरू SQL डाटाबेसमा स्थानान्तरण गरिसकेका छौं, तर त्यहाँ भिन्नता लगभग ध्यान नदिने खालको छ, र दिनमा एकत्रित तथ्याङ्कहरूका लागि, जुन स्वेच्छाचारी अवधिको लागि अनुरोध गर्न सकिन्छ, लाभ एकदम गम्भीर हुन सक्छ।

सामान्यतया, योजनाहरू भव्य छन्, अगाडि बढौं :)

लेख R&D Dentsu Aegis Network रसियाका लेखकहरू: Georgy Ostapenko (shmiigaaमिखाइल कोटसिक (hitexx)

स्रोत: www.habr.com