👦🏽 🤘🏼 👩🏿‍💼 एक गतिशील सिफारिश के उदाहरण का उपयोग करके एक ऑनलाइन स्टोर को निजीकृत करने का अनुभव 👲 👆🏿 👨🏾‍🏫

नमस्कार, हेब्र!

मैं अपने अनुभव साझा करूँगा कि कैसे हम एक संभावित खरीदार के बारे में "ज्ञान" के आधार पर अपनी निजीकरण प्रणाली को एक साथ रखते हैं।

हमारे समाधान और शास्त्रीय लोगों के बीच एकमात्र अंतर कई समाधानों के संयुक्त बंडल का उपयोग था और आवश्यकताओं की सूची को संतुष्ट करता था:

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

यह अधिक विस्तृत है :) और रेक के बारे में जिसने हमें बेहतर के लिए स्टैक को बदलने में मदद की।

प्रागितिहास

एक ही विषय की साइटों का एक समूह है, जिनके दर्शक समान हैं - एक होल्डिंग की साइटें। सामग्री अलग है, एक नियम के रूप में, प्रत्येक साइट उस सामान के बारे में जानकारी प्रकाशित करती है जो होल्डिंग कंपनी बनाती है। इन "सामग्री" साइटों के अलावा, इसका अपना ऑनलाइन स्टोर भी है जिसमें ये उत्पाद बेचे जाते हैं।

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

कोई भी विश्लेषक सही निर्णय लेगा, अधिक डेटा के साथ हाथ में होगा। इस अच्छे उद्देश्य के लिए, उन्होंने काउंटर का अपना संस्करण विकसित किया।

Google Analytics क्यों नहीं?

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

मुझे तुरंत कहना होगा कि मैंने पहिया को फिर से बनाना शुरू नहीं किया और अपने आप को एक मामूली कार्यात्मक तक सीमित कर दिया, जिसके कार्य थे:

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

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

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

तकनीकी क्षण:

MongoDB का उपयोग एकीकृत भंडारण प्रणाली के रूप में किया गया था
जावास्क्रिप्ट-आधारित वास्तविक समय डेटा संग्रह
rabbitmq पर आधारित साइटों के बीच डेटा का स्थानीय विनिमय

जबकि सब कुछ, सभी की तरह ... लेकिन फिर यह शुरू हुआ

इस तथ्य को देखते हुए कि खरीदारों और उत्पादों के बारे में ज्ञान पर्याप्त रूप से जमा हुआ है, हमने ऑनलाइन स्टोर के लिए अपनी खुद की सिफारिश प्रणाली बनाने का फैसला किया।

सब कुछ बढ़िया निकला। हमने हर चीज का विश्लेषण किया, लेकिन कट्टरता के बिना। मॉडल आकार में वृद्धि हुई और, जैसा कि आमतौर पर होता है, वह समय आया जब मैं अधिक चाहता था।

तकनीकी पल 2:

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

कुछ महीने बाद, एपीआई की गुणवत्ता "गुणवत्ता" की सभी समझदार सीमाओं को पार कर गई है। उपयोगकर्ताओं के लिए, प्रतिक्रिया की गति 400ms के निशान से अधिक है। कंटेंट ब्लॉक धीरे-धीरे इकट्ठा हुए, साइट काफ़ी सुस्त होने लगी। MongoDB संग्रह ने कुल दसियों लाख रिकॉर्ड बनाए ...

यह समय कुछ बदलने का है

लगभग सभी उपकरणों को संचालन के स्तर पर लॉग किया गया था, प्रत्येक छींक को मापा गया था।

किस चीज के लिए क्या बदला:

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

मीट्रिक एपीआई क्यों नहीं?

सबसे पहले, मैं सिर्फ यैंडेक्स से तैयार समाधान की दिशा में देख रहा था, लेकिन यह लंबे समय तक नहीं था। यह अच्छा है जब एक साइट संचालन में है। और जब n होते हैं, और आप डेटा को तुरंत संसाधित करना चाहते हैं, तो टैम्बोरिन के साथ नृत्य करने का कोई समय नहीं है।

क्यों MongoDB?

उत्पाद विनिर्देश लगातार जोड़े गए थे, उनमें से कुछ, हमेशा प्रस्तुत नहीं किए गए थे।
एकत्रित प्रश्नों का उपयोग करना - टीम की स्थानीय तकनीकी शैली के प्रारूप में बहुत अच्छी तरह से फिट बैठता है। शास्त्रीय एसक्यूएल तालिकाओं का उत्पादन नहीं करना चाहता था।

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

एक नया समय आ गया है, प्रति सेकंड 2000 अनुरोध ... बशर्ते कि एक सप्ताह में नई कार्यक्षमता को रोल आउट करें और लोड और भी अधिक बढ़ जाएगा।

मशीन सीखने के दौरान, पहली बार htop में मैंने एक बार में 12 कोर का 100% लोड देखा और एक उत्पादक सर्वर पर पूर्ण स्वैप किया। ज़ैबिक्स ने सक्रिय रूप से सूचित किया कि MongoDB ने पहले ही 10 मिनट में दो बार प्रतिकृति में स्वामी बदल दिए थे। हर कोई स्थिरता और एक अनुमानित स्थिति चाहता था।

यह कुछ 2.0 को बदलने का समय है

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

आपको क्या पता कैसे करना है? हां, एनालिटिक्स + सामग्री विविधता के लिए कोई भी गैर-मानक रिपोर्ट:

उन सभी उपयोगकर्ताओं का चयन करें जो विज्ञापन अभियान A से आए थे, जो अंतिम तिमाही में थे, उनमें से उन लोगों को खोजें, जो N शीर्षक से माल में रुचि रखते थे, फिर केवल स्टॉक पर खरीदे गए लोगों को बाहर करें, टोकरी में किसी भी उत्पाद को छोड़ दें और छोड़ दिया साइट। उनके अनुसार, स्टोर की आय के अवरोही क्रम में छंटनी करें यदि ये उपयोगकर्ता अब स्टोर की वेबसाइट पर आए और Z माल खरीदा। ऐसा ही कुछ, और अन्य माँ-मोती बटन के साथ ...
आने वाले ट्रैफ़िक का विश्लेषण करने के लिए, utm टैग Y वाले उपयोगकर्ताओं के लिए एक सामग्री ऑफ़र का निर्माण करना, लेकिन पहले से ही निर्माण, उपयोगकर्ता की पहचान करना, उन लोगों को बाहर करना जो पिछले सप्ताह थे लेकिन साइट S (होल्डिंग साइटों के समूह में से एक) पर थे और उत्पाद Q में रुचि रखते थे - इस तरह के लिए x, y, z मानदंड द्वारा छांटी गई सामग्री उत्पन्न करें
यह उन लोगों को खोजने के लिए है जो अक्सर साइट ए पर जाते हैं, कभी-कभी यह साइट बी पर होता है (वे एक निश्चित खंड का दौरा करते हैं), और जिनके पास एन रूबल से अधिक के ऑनलाइन स्टोर में औसत चेक है

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

समय पर किए गए निर्णय

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

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

दैनिक क्लस्टरिंग प्रक्रिया के बाद, अगला चरण लॉन्च किया गया - मॉडल को प्रशिक्षित करना, ग्राहकों के बारे में नए डेटा और ज्ञान को ध्यान में रखना और स्टोर के अलमारियों पर दिखाई देने वाले सामानों को लेना या उन्हें हमेशा के लिए छोड़ देना।

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

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

निजीकरण के लिए पोस्टप्रोसेसिंग

हम जानते थे कि सरल उपयोगकर्ता हैं, और ऐसे लोग हैं जिनके लिए हमारे पास ज्ञान की पूरी फाइल है। यह सारा सामान टारनटूल में था और वास्तविक समय में अपडेट किया गया था।

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

हमारे अनुभव का परिणाम है

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

यह क्या अच्छा है?

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

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

एक गतिशील सिफारिश के उदाहरण का उपयोग करके एक ऑनलाइन स्टोर को निजीकृत करने का अनुभव