जैसा कि हमने एंटी-क्लिक प्रोटेक्शन सिस्टम लिखा था

हमारी कंपनी ऑनलाइन विज्ञापन के क्षेत्र में काम करती है। लगभग 2 साल पहले, हम अंततः सामग्री नेटवर्क में निर्मित एंटी-क्लिक प्रोटेक्शन सिस्टम से मोहभंग हो गए और आंतरिक उपयोग के लिए उस समय भी अपना खुद का बनाने का फैसला किया।

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

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

दूसरा कार्य हमारे सर्वर पर सभी उपयोगकर्ता डेटा का स्थानांतरण है।
सबसे पूर्ण डेटा प्राप्त करने के लिए, हम 2 स्क्रिप्ट्स का उपयोग करते हैं: सर्वर-साइड (PHP / Python / ASP.NET) और क्लाइंट-साइड JS। इस प्रकार, हम उन उपयोगकर्ताओं के बारे में भी जानकारी प्राप्त करने में सक्षम हैं, जिन्होंने पूर्ण डाउनलोड की प्रतीक्षा किए बिना पृष्ठ को बंद कर दिया है और तदनुसार, क्लाइंट जेएस का विकास। टीज़र विज्ञापन पर ऐसे क्लिक आमतौर पर 30% से कम नहीं होते हैं, और हमें अन्य सिस्टम नहीं मिले हैं जो उन्हें ध्यान में रखते हैं। इसलिए, हमें जेएस काउंटरों के साथ एक ही मीट्रिक, एनालिटिक्स और अन्य सभी सांख्यिकी प्रणालियों की तुलना में काफी अधिक डेटा मिलता है।
क्रॉस-डोमेन AJAX के माध्यम से डेटा हमारे सर्वर को भेजा जाता है, और अगर ब्राउज़र iframe के माध्यम से इसका समर्थन नहीं करता है। पृष्ठ लोडिंग पर भेजा जाता है, साथ ही कई जेएस घटनाओं के लिए भी। यह हमें साइट पर उपयोगकर्ताओं के व्यवहार का विश्लेषण करने और साइट पर व्यवहार के पैटर्न द्वारा वास्तविक उपयोगकर्ताओं से बॉट को अलग करने की अनुमति देता है, साथ ही कुछ जावास्क्रिप्ट घटनाओं की अपूर्ण नकल भी करता है। उदाहरण के लिए, कई बॉट ऑनक्लिक ईवेंट का अनुकरण करते हैं, लेकिन ऑनमाउन्डडाउन, ओनमाउसअप ... ईवेंट्स उत्पन्न नहीं करते हैं।

तो हम सुचारू रूप से और तीसरे कार्य से संपर्क किया - लोहे की पसंद।
वास्तुकला में, इस समय प्रणाली में 4 खंड शामिल हैं:

• दृश्यपटल
• डेटा संग्रह और प्रसंस्करण
• लैंडिंग पृष्ठ अनुक्रमण
• तृतीय-पक्ष सेवाओं के लिए उपयोगकर्ता नाम / पासवर्ड का संग्रहण

सभी डोमेन को ttl 60 सेकंड के साथ अमेज़न रूट 53 के साथ बांधा गया है, ताकि सर्वरों के साथ किसी भी संभावित समस्या के मामले में, वे जल्दी से बैकअप वाले लोगों की ओर पलायन कर सकें।
सामने वाले के बारे में कहने के लिए कुछ खास नहीं। इस पर लोड छोटा है - लगभग कोई भी वीपीएस इसे संभाल सकता है।
डेटा के संग्रह और प्रसंस्करण के साथ, सब कुछ कुछ अधिक जटिल है, क्योंकि डेटा के बड़े संस्करणों के साथ काम करना आवश्यक है। आज, हम प्रत्येक सेकंड में लगभग 200 अनुरोधों को संसाधित करते हैं।
हार्डवेयर और सॉफ्टवेयर की सही प्रारंभिक पसंद के लिए धन्यवाद, एक सर्वर इस मात्रा के साथ पूरी तरह से मुकाबला करता है।
हार्डवेयर के लिए - एसएएस डिस्क से 8-कोर एएमडी, RAID10, 16 जीबी रैम।
डेटा संग्रह nginx + php-fpm + mysql के ट्यून किए गए झुंड द्वारा किया जाता है, प्रसंस्करण + ++ लिपियों द्वारा किया जाता है।
सबसे पहले, हमने डेटा संग्रह स्क्रिप्ट द्वारा गहन सीपीयू संसाधन खपत की समस्या का सामना किया। समाधान पूरी तरह से अप्रत्याशित था। सभी ereg_ php फ़ंक्शंस को उनके preg_ analogues के साथ बदलने पर, हमने CPU की खपत को लगभग 8 गुना कम कर दिया, जो बहुत ही आश्चर्यजनक था।
वर्तमान सर्वर के साथ समस्याओं या स्केलिंग की आवश्यकता के मामले में, एक और डीसी में, एक समान कॉन्फ़िगरेशन के दूसरे सर्वर को एक घंटे के भीतर ऑपरेशन में डालने की संभावना के साथ पंखों में इंतजार कर रहा है।
लैंडिंग पृष्ठों को एक समर्पित आईपी ब्लॉक के साथ एक अलग सर्वर द्वारा अनुक्रमित किया जाता है, जो सीपीयू और रैम में काफी प्रचंड है, हालांकि, यह डिस्क सबसिस्टम पर बिल्कुल मांग नहीं है। पायथन में लिखे गए "खोज बॉट" द्वारा अनुक्रमण किया जाता है।
यह नोड हमारे साथ डुप्लिकेट नहीं है, हालांकि, इसके प्रतिस्थापन या विस्तार में एक दिन से भी कम समय लगता है, और यह सीधे यातायात विश्लेषण की गुणवत्ता को प्रभावित नहीं करता है, सबसे खराब स्थिति में, कई विज्ञापन अभियान बंद नहीं होंगे यदि ग्राहक साइट पर लेट जाता है या हमारा कोड साइट से गायब हो जाता है।
तृतीय-पक्ष सेवाओं के लिए उपयोगकर्ता नाम / पासवर्ड का भंडार एक विशिष्ट बात है और सामान्य तौर पर, सुरक्षा के दृष्टिकोण से, अच्छा नहीं है।
हालांकि, अधिकांश विज्ञापन नेटवर्क के लिए, एपीआई सभी आवश्यक कार्यक्षमता प्रदान नहीं करता है और आपको उनके वेब इंटरफ़ेस को पार्स करना होगा, जो पासवर्ड के बिना करना मुश्किल है। उदाहरण के लिए, Google ऐडवर्ड्स में, आईपी पते पर प्रतिबंध लगाना केवल वेब इंटरफेस के माध्यम से संभव है। एक बोनस के रूप में, उपयोगकर्ताओं को एक क्लिक के साथ हमारे सिस्टम के इंटरफ़ेस से विज्ञापन नेटवर्क के अपने खातों में जाने का अवसर मिलता है।
यह चौथा कार्य है - डेटा सुरक्षा सुनिश्चित करना जब उन्हें स्पष्ट में संग्रहीत करना।
सबसे सुरक्षित डेटा संग्रहण के लिए, हमने निम्नलिखित योजना बनाई:

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

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

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

नीचे की रेखा, इस समय, हमारे सिस्टम में वास्तविक प्रतियोगी नहीं हैं जो क्षमताओं में समान हैं और सबसे महत्वपूर्ण बात यह है कि निम्न-गुणवत्ता वाले यातायात का पता लगाने की गुणवत्ता में तुलनीय है। कुछ मामलों में, हम अन्य विश्लेषणात्मक प्रणालियों की तुलना में 40-45% अधिक यातायात देखते हैं।
ट्रैफ़िक ऑडिट की लागत औसतन, खरीदे गए विज्ञापन की लागत से लगभग 100 गुना कम है, और व्यक्तिगत विज्ञापन प्रणालियों के लिए सेवा पूरी तरह से मुफ्त है। इसी समय, विज्ञापन बजट के 10 से 50% तक बचत होती है, और कभी-कभी 90% तक भी।
वर्तमान में, सिस्टम पूरी तरह से स्वचालित मोड में काम करता है जिसमें Yandex.Direct, Google AdWords, Begun और MarketGuide हैं। किसी भी अन्य विज्ञापन प्रणाली के साथ, सेवा ट्रैफ़िक ऑडिट मोड में काम करती है और बाद में कपटपूर्ण आईपी के मैन्युअल जोड़ के साथ और उनकी ब्लैकलिस्ट के लिए साइटें।

अब सम्मिलित हों!