आम्ही ऑनलाइन साइट्सवरून जाहिरात मोहिमेचा डेटा कसा गोळा केला (उत्पादनाचा काटेरी मार्ग)

असे दिसते की ऑनलाइन जाहिरातीचे क्षेत्र शक्य तितके तांत्रिकदृष्ट्या प्रगत आणि स्वयंचलित असावे. अर्थात, यॅन्डेक्स, मेल.रू, गुगल आणि फेसबुक यांसारख्या क्षेत्रातील दिग्गज आणि तज्ञ तेथे काम करतात. परंतु, जसे हे दिसून आले की, परिपूर्णतेची कोणतीही मर्यादा नाही आणि स्वयंचलित करण्यासाठी नेहमीच काहीतरी असते.

स्त्रोत

संप्रेषण गट Dentsu एजिस नेटवर्क रशिया डिजिटल जाहिरात बाजारातील सर्वात मोठा खेळाडू आहे आणि तंत्रज्ञानामध्ये सक्रियपणे गुंतवणूक करत आहे, त्याच्या व्यवसाय प्रक्रियांना अनुकूल आणि स्वयंचलित करण्याचा प्रयत्न करीत आहे. विविध इंटरनेट प्लॅटफॉर्मवरून जाहिरात मोहिमेची आकडेवारी गोळा करणे हे ऑनलाइन जाहिरात बाजारातील न सुटलेल्या समस्यांपैकी एक बनले आहे. या समस्येचे निराकरण शेवटी उत्पादनाच्या निर्मितीमध्ये होते D1.डिजिटल (दिवान म्हणून वाचा), ज्याच्या विकासाबद्दल आपण बोलू इच्छितो.

का?

1. प्रकल्पाच्या प्रारंभाच्या वेळी, बाजारात एकही तयार-तयार उत्पादन नव्हते जे जाहिरात मोहिमांवरील आकडेवारीचे संकलन स्वयंचलित करण्याच्या समस्येचे निराकरण करते. याचा अर्थ आपल्याशिवाय कोणीही आपल्या गरजा पूर्ण करणार नाही.

इम्प्रोव्हाडो, रोईस्टॅट, सुपरमेट्रिक्स, सेगमेंटस्ट्रीम सारख्या सेवा प्लॅटफॉर्म, सोशल नेटवर्क्स आणि Google ॲनालिटीक्ससह एकीकरण देतात आणि जाहिरात मोहिमांचे सोयीस्कर विश्लेषण आणि नियंत्रणासाठी विश्लेषणात्मक डॅशबोर्ड तयार करणे देखील शक्य करतात. आम्ही आमचे उत्पादन विकसित करण्यास सुरुवात करण्यापूर्वी, आम्ही साइटवरून डेटा संकलित करण्यासाठी यापैकी काही सिस्टम वापरण्याचा प्रयत्न केला, परंतु, दुर्दैवाने, ते आमच्या समस्या सोडवू शकले नाहीत.

मुख्य समस्या अशी होती की चाचणी केलेली उत्पादने डेटा स्रोतांवर अवलंबून होती, साइटनुसार प्लेसमेंट आकडेवारी प्रदर्शित करत होती आणि जाहिरात मोहिमांवर आकडेवारी एकत्रित करण्याची क्षमता प्रदान करत नव्हती. या दृष्टिकोनामुळे आम्हाला वेगवेगळ्या साइटवरील आकडेवारी एकाच ठिकाणी पाहण्याची आणि संपूर्ण मोहिमेच्या स्थितीचे विश्लेषण करण्याची परवानगी दिली नाही.

आणखी एक घटक असा होता की सुरुवातीच्या टप्प्यावर उत्पादने पाश्चात्य बाजारपेठेसाठी होती आणि रशियन साइट्ससह एकत्रीकरणास समर्थन देत नाही. आणि ज्या साइट्ससह एकत्रीकरण लागू केले गेले त्यांच्यासाठी, सर्व आवश्यक मेट्रिक्स नेहमी पुरेशा तपशीलांसह डाउनलोड केल्या जात नाहीत आणि एकत्रीकरण नेहमीच सोयीस्कर आणि पारदर्शक नव्हते, विशेषत: जेव्हा सिस्टम इंटरफेसमध्ये नसलेले काहीतरी मिळवणे आवश्यक होते.
सर्वसाधारणपणे, आम्ही तृतीय-पक्ष उत्पादनांशी जुळवून घेण्याचे ठरवले नाही, परंतु आमचे स्वतःचे विकास करण्यास सुरुवात केली...

2. ऑनलाइन जाहिरात बाजार वर्षानुवर्षे वाढत आहे आणि 2018 मध्ये, जाहिरातींच्या बजेटच्या बाबतीत, त्याने पारंपारिकपणे सर्वात मोठ्या टीव्ही जाहिरात बाजाराला मागे टाकले. तर एक स्केल आहे.

3. टीव्ही जाहिरातींच्या बाजाराच्या विपरीत, जेथे व्यावसायिक जाहिरातींची विक्री मक्तेदारी आहे, तेथे इंटरनेटवर त्यांच्या स्वत: च्या जाहिरात खात्यांसह कार्यरत असलेल्या विविध आकारांच्या जाहिरातींच्या यादीचे बरेच वैयक्तिक मालक आहेत. जाहिरात मोहीम, नियमानुसार, एकाच वेळी अनेक साइट्सवर चालत असल्याने, जाहिरात मोहिमेची स्थिती समजून घेण्यासाठी, सर्व साइटवरून अहवाल गोळा करणे आणि त्यांना एका मोठ्या अहवालात एकत्र करणे आवश्यक आहे जे संपूर्ण चित्र दर्शवेल. याचा अर्थ ऑप्टिमायझेशनची क्षमता आहे.

4. आम्हाला असे वाटले की इंटरनेटवरील जाहिरातींच्या यादीच्या मालकांकडे आधीच आकडेवारी गोळा करण्यासाठी आणि जाहिरात खात्यांमध्ये प्रदर्शित करण्यासाठी पायाभूत सुविधा आहे आणि ते या डेटासाठी API प्रदान करण्यास सक्षम असतील. याचा अर्थ तांत्रिकदृष्ट्या त्याची अंमलबजावणी करणे शक्य आहे. चला लगेच म्हणूया की ते इतके सोपे नाही.

सर्वसाधारणपणे, प्रकल्पाच्या अंमलबजावणीसाठी सर्व पूर्व-आवश्यकता आमच्यासाठी स्पष्ट होत्या आणि आम्ही प्रकल्पाला जिवंत करण्यासाठी धावलो...

भव्य योजना

सुरुवातीला, आम्ही एक आदर्श प्रणालीची दृष्टी तयार केली:

• 1C कॉर्पोरेट सिस्टीममधील जाहिरात मोहिमा आपोआप त्यामध्ये त्यांची नावे, कालावधी, बजेट आणि विविध प्लॅटफॉर्मवरील प्लेसमेंटसह लोड केल्या पाहिजेत.
• जाहिरात मोहिमेतील प्रत्येक प्लेसमेंटसाठी, प्लेसमेंट होत असलेल्या साइटवरून सर्व संभाव्य आकडेवारी आपोआप डाउनलोड केली जावी, जसे की इंप्रेशन, क्लिक, व्ह्यू इ.
• ॲड्रिव्हर, वेबोरामा, डीसीएम इत्यादी तथाकथित जाहिरात प्रणालींद्वारे तृतीय-पक्ष निरीक्षण वापरून काही जाहिरात मोहिमांचा मागोवा घेतला जातो. रशियामध्ये एक औद्योगिक इंटरनेट मीटर देखील आहे - मेडियास्कोप कंपनी. आमच्या योजनेनुसार, स्वतंत्र आणि औद्योगिक निरीक्षणाचा डेटा संबंधित जाहिरात मोहिमांमध्ये स्वयंचलितपणे लोड केला जावा.
• इंटरनेटवरील बऱ्याच जाहिरातींच्या मोहिमा काही लक्ष्य कृती (खरेदी, कॉल, चाचणी ड्राइव्हसाठी साइन अप इ.) या उद्देशाने असतात, ज्याचा Google Analytics वापरून मागोवा घेतला जातो आणि मोहिमेची स्थिती समजून घेण्यासाठी ज्याची आकडेवारी देखील महत्त्वाची असते आणि आमच्या टूलमध्ये लोड केले पाहिजे.

पहिली उद्गार म्हणजे ढेकूण

सॉफ्टवेअर डेव्हलपमेंटच्या (चपळ, सर्व गोष्टी) लवचिक तत्त्वांप्रती आमची वचनबद्धता लक्षात घेता, आम्ही प्रथम MVP विकसित करण्याचा आणि नंतर पुनरावृत्तीने अपेक्षित उद्दिष्टाकडे जाण्याचा निर्णय घेतला.
आम्ही आमच्या उत्पादनावर आधारित MVP तयार करण्याचा निर्णय घेतला डॅनबो (डेंट्सू एजिस नेटवर्क बोर्ड), जे आमच्या क्लायंटच्या जाहिरात मोहिमांवरील सामान्य माहितीसह एक वेब अनुप्रयोग आहे.

MVP साठी, प्रकल्पाच्या अंमलबजावणीच्या दृष्टीने शक्य तितके सोपे केले गेले. आम्ही एकत्रीकरणासाठी प्लॅटफॉर्मची मर्यादित यादी निवडली आहे. हे मुख्य प्लॅटफॉर्म होते, जसे की Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, आणि मुख्य जाहिरात प्रणाली Adriver आणि Weborama.

API द्वारे साइटवरील आकडेवारीमध्ये प्रवेश करण्यासाठी, आम्ही एक खाते वापरले. क्लायंट ग्रुप मॅनेजर ज्याला जाहिरात मोहिमेवर आकडेवारीचा स्वयंचलित संग्रह वापरायचा होता, त्याला प्रथम प्लॅटफॉर्म खात्यावर साइटवरील आवश्यक जाहिरात मोहिमांचा प्रवेश सोपवावा लागला.

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

हे स्पष्टपणे, भयानक दिसत होते:

डाउनलोड केलेला डेटा डेटाबेसमध्ये सेव्ह केला गेला आणि नंतर वेगळ्या सेवांनी त्यांच्याकडून साइट्सवरील मोहिम अभिज्ञापक गोळा केले आणि त्यावरील आकडेवारी डाउनलोड केली.

प्रत्येक साइटसाठी, एक स्वतंत्र विंडो सेवा लिहिली होती, जी दिवसातून एकदा साइटच्या API मधील एका सेवा खात्याखाली जाते आणि निर्दिष्ट मोहिम आयडीसाठी आकडेवारी डाउनलोड केली जाते. जाहिरात प्रणालींमध्येही असेच घडले.

डाउनलोड केलेला डेटा इंटरफेसवर एका लहान सानुकूल डॅशबोर्डच्या स्वरूपात प्रदर्शित केला गेला:

आमच्यासाठी अनपेक्षितपणे, MVP ने काम करण्यास सुरुवात केली आणि इंटरनेटवरील जाहिरात मोहिमांवरील वर्तमान आकडेवारी डाउनलोड करण्यास सुरुवात केली. आम्ही अनेक क्लायंटवर प्रणाली लागू केली, परंतु स्केल करण्याचा प्रयत्न करताना, आम्हाला गंभीर समस्या आल्या:

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

यावरून आम्हाला कल्पना आली की प्लेसमेंटबद्दल माहितीचा प्राथमिक स्त्रोत आमची 1C प्रणाली असावी, ज्यामध्ये सर्व डेटा अचूकपणे आणि वेळेवर प्रविष्ट केला जातो (येथे मुद्दा असा आहे की 1C डेटावर आधारित पावत्या तयार केल्या जातात, त्यामुळे 1C मध्ये डेटाची योग्य प्रविष्टी करा. प्रत्येकासाठी KPI हे प्राधान्य आहे). अशा प्रकारे प्रणालीची एक नवीन संकल्पना उदयास आली ...

संकल्पना

आम्ही ठरवलेली पहिली गोष्ट म्हणजे इंटरनेटवरील जाहिरातींच्या मोहिमेची आकडेवारी संकलित करण्यासाठी सिस्टमला वेगळ्या उत्पादनामध्ये वेगळे करणे - D1.डिजिटल.

नवीन संकल्पनेत, आम्ही मध्ये लोड करण्याचा निर्णय घेतला D1.डिजिटल 1C पासून जाहिरात मोहिमा आणि त्यामधील प्लेसमेंटची माहिती, आणि नंतर साइट्स आणि ॲडसर्व्हिंग सिस्टम्सकडून या प्लेसमेंटसाठी आकडेवारी काढा. हे वापरकर्त्यांचे जीवन लक्षणीयरीत्या सुलभ करेल (आणि नेहमीप्रमाणे, विकसकांना अधिक काम जोडेल) आणि समर्थनाची रक्कम कमी करेल.

आम्हाला पहिली समस्या आली ती संस्थात्मक स्वरूपाची होती आणि ती या वस्तुस्थितीशी संबंधित होती की आम्हाला एक कळ किंवा चिन्ह सापडले नाही ज्याद्वारे आम्ही 1C मधील मोहिमा आणि प्लेसमेंटसह विविध प्रणालींमधील घटकांची तुलना करू शकू. वस्तुस्थिती अशी आहे की आमच्या कंपनीतील प्रक्रिया अशा प्रकारे तयार केली गेली आहे की जाहिरात मोहिम वेगवेगळ्या प्रणालींमध्ये वेगवेगळ्या लोकांद्वारे (मीडिया नियोजक, खरेदी इ.) प्रविष्ट केल्या जातात.

या समस्येचे निराकरण करण्यासाठी, आम्हाला एक अनन्य हॅश की, DANBoID शोधून काढावी लागली, जी वेगवेगळ्या प्रणालींमधील घटकांना एकत्र जोडेल आणि डाउनलोड केलेल्या डेटा सेटमध्ये ती अगदी सहज आणि अद्वितीयपणे ओळखली जाऊ शकते. हा आयडेंटिफायर प्रत्येक वैयक्तिक प्लेसमेंटसाठी अंतर्गत 1C सिस्टममध्ये तयार केला जातो आणि सर्व साइट्सवर आणि सर्व AdServing सिस्टममध्ये मोहिमा, प्लेसमेंट आणि काउंटरमध्ये हस्तांतरित केला जातो. सर्व प्लेसमेंटमध्ये DANBoID टाकण्याचा सराव लागू करण्यास थोडा वेळ लागला, परंतु आम्ही ते करू शकलो :)

मग आम्हाला आढळले की सर्व साइट्सकडे स्वयंचलितपणे आकडेवारी गोळा करण्यासाठी API नाही आणि ज्यांच्याकडे API आहे, ते सर्व आवश्यक डेटा परत करत नाही.

या टप्प्यावर, आम्ही एकीकरणासाठी प्लॅटफॉर्मची यादी लक्षणीयरीत्या कमी करण्याचा आणि मोठ्या प्रमाणात जाहिरात मोहिमांमध्ये सहभागी असलेल्या मुख्य प्लॅटफॉर्मवर लक्ष केंद्रित करण्याचा निर्णय घेतला. या यादीमध्ये जाहिरात बाजारातील सर्व मोठ्या खेळाडूंचा समावेश आहे (Google, Yandex, Mail.ru), सोशल नेटवर्क्स (VK, Facebook, Twitter), प्रमुख AdServing आणि विश्लेषण प्रणाली (DCM, Adriver, Weborama, Google Analytics) आणि इतर प्लॅटफॉर्म.

आम्ही निवडलेल्या बहुसंख्य साइट्समध्ये एक API आहे ज्याने आम्हाला आवश्यक असलेले मेट्रिक प्रदान केले. ज्या प्रकरणांमध्ये एपीआय नव्हते किंवा त्यात आवश्यक डेटा नसतो, आम्ही डेटा लोड करण्यासाठी आमच्या ऑफिस ईमेलवर दररोज पाठवलेले अहवाल वापरतो (काही सिस्टीममध्ये असे अहवाल कॉन्फिगर करणे शक्य आहे, तर इतरांमध्ये आम्ही याच्या विकासावर सहमती दर्शवली आहे. आमच्यासाठी असे अहवाल).

वेगवेगळ्या साइट्सवरील डेटाचे विश्लेषण करताना, आम्हाला आढळले की घटकांची पदानुक्रम भिन्न प्रणालींमध्ये समान नाही. शिवाय, माहिती वेगवेगळ्या प्रणालींमधून वेगवेगळ्या तपशीलांमध्ये डाउनलोड करणे आवश्यक आहे.

या समस्येचे निराकरण करण्यासाठी, SubDANBoID संकल्पना विकसित केली गेली. SubDANBoID ची कल्पना अगदी सोपी आहे, आम्ही व्युत्पन्न केलेल्या DANBoID सह साइटवर मोहिमेची मुख्य संस्था चिन्हांकित करतो आणि आम्ही सर्व नेस्टेड संस्थांना अद्वितीय साइट आयडेंटिफायरसह अपलोड करतो आणि DANBoID तत्त्व + पहिल्या स्तराच्या आयडेंटिफायरनुसार SubDANBoID तयार करतो. नेस्टेड एंटिटी + दुसऱ्या लेव्हल नेस्टेड एंटिटीचा आयडेंटिफायर +... या पध्दतीने आम्हाला वेगवेगळ्या सिस्टीममध्ये जाहिरात मोहिमा कनेक्ट करण्याची आणि त्यावर तपशीलवार आकडेवारी डाउनलोड करण्याची परवानगी दिली.

वेगवेगळ्या प्लॅटफॉर्मवर प्रचारासाठी प्रवेशाचा प्रश्नही आम्हाला सोडवावा लागला. आम्ही वर लिहिल्याप्रमाणे, वेगळ्या तांत्रिक खात्यावर मोहिमेचा प्रवेश सोपवण्याची यंत्रणा नेहमीच लागू होत नाही. म्हणून, आम्हाला टोकन्स आणि ही टोकन्स अपडेट करण्यासाठी यंत्रणा वापरून OAuth द्वारे स्वयंचलित अधिकृततेसाठी एक पायाभूत सुविधा विकसित करावी लागली.

लेखात नंतर आम्ही सोल्यूशनच्या आर्किटेक्चर आणि अंमलबजावणीच्या तांत्रिक तपशीलांचे अधिक तपशीलवार वर्णन करण्याचा प्रयत्न करू.

सोल्यूशन आर्किटेक्चर 1.0

नवीन उत्पादनाची अंमलबजावणी सुरू करताना, आम्हाला समजले की आम्हाला ताबडतोब नवीन साइट कनेक्ट करण्याची शक्यता प्रदान करणे आवश्यक आहे, म्हणून आम्ही मायक्रोसर्व्हिस आर्किटेक्चरचा मार्ग अवलंबण्याचे ठरविले.

आर्किटेक्चरची रचना करताना, आम्ही सर्व बाह्य सिस्टीम - 1C, जाहिरात प्लॅटफॉर्म आणि जाहिरात प्रणाली - वेगळ्या सेवांमध्ये कनेक्टर विभक्त केले.
मुख्य कल्पना अशी आहे की साइटवरील सर्व कनेक्टर समान API आहेत आणि ते अडॅप्टर आहेत जे साइट API ला आमच्यासाठी सोयीस्कर इंटरफेसवर आणतात.

आमच्या उत्पादनाच्या मध्यभागी एक वेब ऍप्लिकेशन आहे, जो एक मोनोलिथ आहे जो अशा प्रकारे डिझाइन केला आहे की ते सेवांमध्ये सहजपणे वेगळे केले जाऊ शकते. हा अनुप्रयोग डाउनलोड केलेल्या डेटावर प्रक्रिया करण्यासाठी, वेगवेगळ्या सिस्टममधील आकडेवारी एकत्रित करण्यासाठी आणि सिस्टम वापरकर्त्यांसमोर सादर करण्यासाठी जबाबदार आहे.

कनेक्टर आणि वेब ऍप्लिकेशन दरम्यान संवाद साधण्यासाठी, आम्हाला एक अतिरिक्त सेवा तयार करावी लागली, ज्याला आम्ही कनेक्टर प्रॉक्सी म्हणतो. हे सर्व्हिस डिस्कव्हरी आणि टास्क शेड्युलरची कार्ये करते. ही सेवा प्रत्येक कनेक्टरसाठी प्रत्येक रात्री डेटा संकलन कार्ये चालवते. मेसेज ब्रोकरला जोडण्यापेक्षा सर्व्हिस लेयर लिहिणे सोपे होते आणि आमच्यासाठी शक्य तितक्या लवकर निकाल मिळणे महत्त्वाचे होते.

साधेपणा आणि विकासाच्या गतीसाठी, आम्ही सर्व सेवा वेब API असतील हे देखील ठरवले आहे. यामुळे त्वरीत एक पुरावा-संकल्पना एकत्रित करणे आणि संपूर्ण डिझाइन कार्य करते याची पडताळणी करणे शक्य झाले.

भिन्न खात्यांमधून डेटा गोळा करण्यासाठी प्रवेश सेट करणे हे एक वेगळे, ऐवजी जटिल कार्य होते, जे आम्ही ठरवल्याप्रमाणे, वापरकर्त्यांनी वेब इंटरफेसद्वारे केले पाहिजे. यात दोन स्वतंत्र पायऱ्यांचा समावेश आहे: प्रथम, वापरकर्ता OAuth द्वारे खात्यात प्रवेश करण्यासाठी टोकन जोडतो आणि नंतर विशिष्ट खात्यातून क्लायंटसाठी डेटाचे संकलन कॉन्फिगर करतो. OAuth द्वारे टोकन प्राप्त करणे आवश्यक आहे कारण, जसे आम्ही आधीच लिहिले आहे, साइटवर इच्छित खात्यावर प्रवेश सोपविणे नेहमीच शक्य नसते.

साइट्सवरून खाते निवडण्यासाठी एक सार्वत्रिक यंत्रणा तयार करण्यासाठी, आम्हाला कनेक्टर्स API मध्ये एक पद्धत जोडावी लागेल जी JSON स्कीमा परत करेल, जी सुधारित JSONEditor घटक वापरून फॉर्ममध्ये प्रस्तुत केली जाते. अशा प्रकारे, वापरकर्ते ज्या खात्यांमधून डेटा डाउनलोड करायचा ते निवडण्यास सक्षम होते.

साइट्सवर अस्तित्वात असलेल्या विनंती मर्यादांचे पालन करण्यासाठी, आम्ही एका टोकनमध्ये सेटिंग्जसाठी विनंत्या एकत्र करतो, परंतु आम्ही समांतरपणे भिन्न टोकन्सवर प्रक्रिया करू शकतो.

आम्ही वेब ऍप्लिकेशन आणि कनेक्टर या दोन्हीसाठी लोड केलेल्या डेटासाठी स्टोरेज म्हणून MongoDB निवडले, ज्यामुळे आम्हाला डेव्हलपमेंटच्या सुरुवातीच्या टप्प्यावर, जेव्हा ऍप्लिकेशनचे ऑब्जेक्ट मॉडेल प्रत्येक दुसऱ्या दिवशी बदलते तेव्हा डेटा स्ट्रक्चरबद्दल जास्त काळजी करू नये.

आम्हाला लवकरच कळले की मोंगोडीबीमध्ये सर्व डेटा नीट बसत नाही आणि उदाहरणार्थ, रिलेशनल डेटाबेसमध्ये दैनंदिन आकडेवारी संग्रहित करणे अधिक सोयीचे आहे. म्हणून, ज्या कनेक्टर्सची डेटा रचना रिलेशनल डेटाबेससाठी अधिक योग्य आहे, आम्ही पोस्टग्रेएसक्यूएल किंवा एमएस एसक्यूएल सर्व्हर स्टोरेज म्हणून वापरण्यास सुरुवात केली.

निवडलेल्या आर्किटेक्चर आणि तंत्रज्ञानामुळे आम्हाला D1.Digital उत्पादन तुलनेने लवकर तयार आणि लॉन्च करण्याची परवानगी मिळाली. उत्पादनाच्या विकासाच्या दोन वर्षांमध्ये, आम्ही साइट्सवर 23 कनेक्टर विकसित केले, तृतीय-पक्ष API सह काम करण्याचा अनमोल अनुभव मिळवला, वेगवेगळ्या साइट्सचे नुकसान टाळण्यास शिकलो, ज्या प्रत्येकाच्या स्वतःच्या होत्या, कमीतकमी 3 च्या API च्या विकासात योगदान दिले. साइट्स, जवळपास 15 मोहिमांवर आणि 000 पेक्षा जास्त प्लेसमेंटसाठी स्वयंचलितपणे डाउनलोड केलेली माहिती, उत्पादनाच्या ऑपरेशनवर वापरकर्त्यांकडून भरपूर फीडबॅक गोळा केले आणि या फीडबॅकच्या आधारे उत्पादनाची मुख्य प्रक्रिया अनेक वेळा बदलण्यात व्यवस्थापित केली.

सोल्यूशन आर्किटेक्चर 2.0

विकासकाम सुरू होऊन दोन वर्षे उलटली आहेत D1.डिजिटल. सिस्टमवरील लोडमध्ये सतत वाढ आणि अधिकाधिक नवीन डेटा स्त्रोतांचा उदय यामुळे विद्यमान सोल्यूशन आर्किटेक्चरमधील समस्या हळूहळू प्रकट झाल्या.

पहिली समस्या साइटवरून डाउनलोड केलेल्या डेटाच्या प्रमाणाशी संबंधित आहे. आम्हाला या वस्तुस्थितीचा सामना करावा लागला की सर्वात मोठ्या साइटवरून सर्व आवश्यक डेटा संकलित करणे आणि अद्यतनित करणे खूप वेळ घेऊ लागले. उदाहरणार्थ, AdRiver जाहिरात प्रणालीकडून डेटा संकलित करणे, ज्याद्वारे आम्ही बहुतेक प्लेसमेंटसाठी आकडेवारीचा मागोवा घेतो, सुमारे 12 तास लागतात.

या समस्येचे निराकरण करण्यासाठी, आम्ही साइट्सवरून डेटा डाउनलोड करण्यासाठी सर्व प्रकारचे अहवाल वापरण्यास सुरुवात केली, आम्ही साइट्ससह त्यांचे API विकसित करण्याचा प्रयत्न करत आहोत जेणेकरून त्याच्या ऑपरेशनचा वेग आमच्या गरजा पूर्ण करेल आणि डेटा डाउनलोडला शक्य तितके समांतर केले जाईल.

दुसरी समस्या डाउनलोड केलेल्या डेटाच्या प्रक्रियेशी संबंधित आहे. आता, नवीन प्लेसमेंट आकडेवारी आल्यावर, मेट्रिक्सची पुनर्गणना करण्याची एक बहु-स्टेज प्रक्रिया सुरू केली जाते, ज्यामध्ये कच्चा डेटा लोड करणे, प्रत्येक साइटसाठी एकत्रित मेट्रिक्सची गणना करणे, वेगवेगळ्या स्त्रोतांकडील डेटाची एकमेकांशी तुलना करणे आणि मोहिमेसाठी सारांश मेट्रिक्सची गणना करणे समाविष्ट आहे. यामुळे सर्व आकडेमोड करणाऱ्या वेब ॲप्लिकेशनवर खूप भार पडतो. अनेक वेळा, पुनर्गणना प्रक्रियेदरम्यान, अनुप्रयोगाने सर्व्हरवरील सर्व मेमरी वापरली, सुमारे 10-15 GB, ज्याचा प्रणालीसह वापरकर्त्यांच्या कार्यावर सर्वात हानिकारक प्रभाव पडला.

ओळखल्या गेलेल्या समस्या आणि उत्पादनाच्या पुढील विकासासाठी महत्त्वाकांक्षी योजनांमुळे आम्हाला ऍप्लिकेशन आर्किटेक्चरवर पुनर्विचार करण्याची गरज निर्माण झाली.

आम्ही कनेक्टरसह सुरुवात केली.
आमच्या लक्षात आले की सर्व कनेक्टर समान मॉडेलनुसार कार्य करतात, म्हणून आम्ही एक पाइपलाइन फ्रेमवर्क तयार केला आहे ज्यामध्ये कनेक्टर तयार करण्यासाठी तुम्हाला फक्त पायऱ्यांचे तर्क प्रोग्राम करावे लागतील, बाकीचे सर्वत्र आहे. कनेक्टरमध्ये सुधारणा आवश्यक असल्यास, कनेक्टरमध्ये सुधारणा होत असतानाच आम्ही ते त्वरित नवीन फ्रेमवर्कमध्ये हस्तांतरित करतो.

त्याच वेळी, आम्ही Docker आणि Kubernetes वर कनेक्टर तैनात करणे सुरू केले.
आम्ही बऱ्याच काळासाठी कुबर्नेट्समध्ये जाण्याची योजना आखली, सीआय/सीडी सेटिंग्जसह प्रयोग केले, परंतु जेव्हा एका कनेक्टरने, त्रुटीमुळे, सर्व्हरवरील 20 जीबी पेक्षा जास्त मेमरी खाण्यास सुरुवात केली तेव्हाच हलण्यास सुरुवात केली आणि व्यावहारिकरित्या इतर प्रक्रिया नष्ट केल्या. . तपासादरम्यान, कनेक्टरला कुबर्नेट्स क्लस्टरमध्ये हलविण्यात आले, जिथे त्रुटी निश्चित झाल्यानंतरही तो शेवटी राहिला.

खूप लवकर आम्हाला समजले की Kubernetes सोयीस्कर आहे, आणि सहा महिन्यांत आम्ही 7 कनेक्टर आणि कनेक्टर्स प्रॉक्सी, जे सर्वाधिक संसाधने वापरतात, उत्पादन क्लस्टरमध्ये हस्तांतरित केले.

कनेक्टर्सचे अनुसरण करून, आम्ही उर्वरित अनुप्रयोगाचे आर्किटेक्चर बदलण्याचा निर्णय घेतला.
मुख्य समस्या अशी होती की डेटा कनेक्टरकडून प्रॉक्सीमध्ये मोठ्या बॅचेसमध्ये येतो आणि नंतर DANBoID ला आदळला जातो आणि प्रक्रियेसाठी केंद्रीय वेब अनुप्रयोगाकडे पाठविला जातो. मोठ्या संख्येने मेट्रिक्स पुनर्गणनामुळे, अर्जावर मोठा भार आहे.

वैयक्तिक डेटा संकलन जॉबच्या स्थितीचे निरीक्षण करणे आणि केंद्रीय वेब अनुप्रयोगाशी कनेक्टरमध्ये झालेल्या त्रुटींचा अहवाल देणे देखील खूप कठीण आहे जेणेकरुन वापरकर्ते काय घडत आहे आणि डेटा का संकलित केला जात नाही हे पाहू शकतील.

या समस्यांचे निराकरण करण्यासाठी, आम्ही आर्किटेक्चर 2.0 विकसित केले.

आर्किटेक्चरच्या नवीन आवृत्तीमधील मुख्य फरक म्हणजे वेब API ऐवजी, आम्ही सेवांमधील संदेशांची देवाणघेवाण करण्यासाठी RabbitMQ आणि MassTransit लायब्ररी वापरतो. हे करण्यासाठी, आम्हाला कनेक्टर्स प्रॉक्सी जवळजवळ पूर्णपणे पुनर्लेखन करावे लागले, ज्यामुळे ते कनेक्टर्स हब बनले. नाव बदलण्यात आले कारण सेवेची मुख्य भूमिका यापुढे कनेक्टर्सना विनंत्या अग्रेषित करणे आणि परत करणे नाही, परंतु कनेक्टर्सकडून मेट्रिक्सचे संकलन व्यवस्थापित करणे.

सेंट्रल वेब ऍप्लिकेशनवरून, आम्ही साइट्सवरील प्लेसमेंट आणि आकडेवारीबद्दलची माहिती वेगळ्या सेवांमध्ये विभक्त केली, ज्यामुळे अनावश्यक पुनर्गणनापासून मुक्त होणे आणि प्लेसमेंट स्तरावर फक्त आधीच मोजलेली आणि एकत्रित आकडेवारी संग्रहित करणे शक्य झाले. आम्ही कच्च्या डेटावर आधारित मूलभूत आकडेवारीची गणना करण्यासाठी तर्कशास्त्र पुन्हा लिहिले आणि ऑप्टिमाइझ केले.

त्याच वेळी, आम्ही सर्व सेवा आणि ॲप्लिकेशन्स डॉकर आणि कुबर्नेट्समध्ये स्थलांतरित करत आहोत जेणेकरून उपाय स्केल करणे सोपे आणि व्यवस्थापित करणे अधिक सोयीस्कर होईल.

आता आम्ही कुठे आहोत

पुरावा-संकल्पना आर्किटेक्चर 2.0 उत्पादन D1.डिजिटल कनेक्टरच्या मर्यादित संचासह चाचणी वातावरणात तयार आणि कार्य करणे. नवीन प्लॅटफॉर्मवर आणखी 20 कनेक्टर पुन्हा लिहिणे, डेटा योग्यरित्या लोड केला आहे याची चाचणी घेणे आणि सर्व मेट्रिक्सची योग्य गणना करणे आणि संपूर्ण डिझाइन उत्पादनामध्ये रोल आउट करणे एवढेच बाकी आहे.

खरं तर, ही प्रक्रिया हळूहळू होईल आणि सर्वकाही कार्य करत राहण्यासाठी आम्हाला जुन्या API सह मागास अनुकूलता सोडावी लागेल.

आमच्या तात्काळ योजनांमध्ये नवीन कनेक्टरचा विकास, नवीन सिस्टमसह एकत्रीकरण आणि कनेक्ट केलेल्या साइट्सवरून डाउनलोड केलेल्या डेटाच्या सेटमध्ये अतिरिक्त मेट्रिक्स जोडणे आणि जाहिरात प्रणाली समाविष्ट आहेत.

आम्ही केंद्रीय वेब ऍप्लिकेशनसह सर्व ऍप्लिकेशन्स डॉकर आणि कुबर्नेट्समध्ये हस्तांतरित करण्याची योजना आखत आहोत. नवीन आर्किटेक्चरसह एकत्रित, हे उपभोगलेल्या संसाधनांचे उपयोजन, देखरेख आणि नियंत्रण लक्षणीयरीत्या सुलभ करेल.

दुसरी कल्पना म्हणजे आकडेवारी संग्रहित करण्यासाठी डेटाबेसच्या निवडीसह प्रयोग करणे, जे सध्या MongoDB मध्ये संग्रहित आहे. आम्ही यापूर्वीच अनेक नवीन कनेक्टर एसक्यूएल डेटाबेसमध्ये हस्तांतरित केले आहेत, परंतु तेथे फरक जवळजवळ लक्षात न येण्याजोगा आहे आणि दिवसागणिक एकत्रित आकडेवारीसाठी, ज्याला अनियंत्रित कालावधीसाठी विनंती केली जाऊ शकते, नफा खूपच गंभीर असू शकतो.

सर्वसाधारणपणे, योजना भव्य आहेत, चला पुढे जाऊया :)

लेखाचे लेखक R&D Dentsu Aegis Network रशिया: जॉर्जी ओस्टापेन्को (shmiigaa), मिखाईल कोटसिक (hitexx)

स्त्रोत: www.habr.com