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

तो
वर्ष 2004 यार्ड में था। क्या हुआ था स्पोर्टमास्टर क्लब कार्यक्रम और प्रत्येक में 27 रूबल। क्या नहीं था - क्षेत्र में सामान्य इंटरनेट और दुकानों पर स्थिर संचार चैनल।
उन वर्षों में, हमने खुद एक वफादारी प्रणाली लिखी है जो सामान्य रूप से प्रत्येक उपयोगकर्ता के बोनस बिंदुओं पर नज़र रख सकती है। लेकिन चूंकि हमारे पास पहले से ही बहुत सारे स्टोर थे, इसलिए डेटा प्रोसेसिंग सुविधाओं के विपरीत, हमारा पूरा बोनस डेटाबेस एक फाइल में स्थित था, जिसे बस स्टोरों में भेजा गया था और स्थानीय स्तर पर काम किया गया था, और दिन के लिए परिवर्तन लौटाए गए थे। वैसे, यह इस तथ्य का मूल कारण था कि खरीद के बाद ही बोनस अगले दिन खर्च किया जा सकता है, न कि व्यवसाय की आवश्यकताओं और ग्राहकों की वापसी सुनिश्चित करने के लिए - दिन के दौरान यह सब बस अद्यतन होने और ठीक से समय पर नहीं होने के कारण था।
दूसरे शब्दों में, उस समय बोनस काम करना शुरू कर सकता था और सामान्य रूप से पांचवें दिन - जब तक कि नए गणना किए गए बोनस के साथ यह तालिका सभी दुकानों तक नहीं पहुंच जाती।
कार्डों ने स्वयं काफी सरलता से काम किया - प्रत्येक कार्ड में केवल एक निश्चित संख्या में बोनस होता है जो उसके मालिक खुशी से और भावना के साथ खर्च कर सकते हैं। यही है, आधार के लिए यह सरल, मोटे तौर पर बोल रहा है, एक कार्ड - एक अंक। सोने के कार्ड के साथ यह थोड़ा अधिक जटिल था - वहां, बोनस के साथ संख्या के अलावा, सेवा बिंदु भी थे। यह तब है जब आपने एक बाइक खरीदी थी, और छह महीने के बाद आप श्रृंखला को कसना चाहते थे, ब्रेक की जांच करें, घंटी ने आपकी आत्मा को गर्म करना शुरू कर दिया और राहगीरों को डरा दिया (या नए सत्र के लिए स्केट्स को तेज करें और उदाहरण के लिए स्नोबोर्ड को ठीक करें)।
उसी समय, प्राकृतिक बुद्धिमत्ता पर आधारित समाधान की शक्ति का उपयोग करके बोनस की गणना की गई - हमारे पास एक विशेष कर्मचारी था, जिसने चयन लिखा और चयन किया, फिर एक विशेष प्लेट में बोनस जोड़ा, और सिस्टम ने इस प्लेट को ऊपर खींच लिया। और हाँ, अगर इस व्यक्ति ने अचानक थोड़ा खुश करने का फैसला किया या फिर और क्या - कुछ ग्राहकों को इन कठिन दिनों में बोनस के बिना छोड़ा जा सकता है।
बेशक, यह स्थिति व्यापार के लिए काफी महंगी थी, और वास्तव में यह खतरनाक और अप्रत्याशित था, और व्यवसाय सिस्टम को सामान्य (स्वचालित) पटरियों पर स्थानांतरित करना चाहता था।
पहले हमने बाजार का अध्ययन करने का फैसला किया। हमने महसूस किया कि शानदार फीचर्स और प्राइस टैग के साथ कई बेहतरीन सिस्टम हैं जो इन फीचर्स से बेहतर हैं। इसके अलावा, ऐसी लाइसेंस प्रणाली के साथ, जिसके अनुसार यह न केवल क्षमता के उपयोग के लिए या सॉफ़्टवेयर के लिए, बल्कि इस तरह के बोनस सिस्टम में प्रत्येक सक्रिय उपयोगकर्ता के लिए रिश्वत एकत्र करना था। सिस्टम के लेखकों को इससे खुशी नहीं मिल सकती थी। लेकिन हमारा कारोबार उदास था।
दूसरी समस्या यह भी थी कि ग्राहक आधार और दुकानों की संख्या में वृद्धि के साथ, एक ऐसी स्थिति थी जहां अधिक से अधिक दुकानों में तेजी से आधार भेजा जाना था। और एक ठीक दिन, इस आधार ने मौजूदा संचार चैनलों के माध्यम से बस क्रॉल करना बंद कर दिया। एक बड़ी लकीर के साथ कम समय में सभी दुकानों पर इसकी समीक्षा की गई।
आधार के पास खरीदारी करने का समय नहीं था, इस कारण कभी-कभी स्टोर उन्हें अपडेट करना भूल जाते थे, और उन्हें फ्रैंक दलिया मिला - स्टोर में एक व्यक्ति ने कुछ उपयोगी खरीदा और एक बोनस प्राप्त किया, और कुछ दिनों के बाद बी स्टोर कर रहा है कि अभी भी उस व्यक्ति को पता नहीं चल सका है और एक नई खरीद से बोनस में कटौती।
और फिर अलेक्जेंडर अफानसेव
(अब एक अन्य कंपनी के आईटी निदेशक) ने यह सोचा कि तीसरे पक्ष के सॉफ़्टवेयर को खरीदने के बिना यह सब कैसे किया जाए। मैंने व्यापार से इस प्रणाली के लिए कई आवश्यकताओं को अपने हिस्से में एकत्र किया और नए अवसरों को पंजीकृत किया। सबसे पहले यह सिर्फ सुखद सुविधाओं के रूप में है - उदाहरण के लिए, अब बोनस केवल एक संख्या नहीं है, बल्कि एक संपूर्ण जटिल प्रणाली है। आप किसी व्यक्ति को जन्मदिन के लिए बोनस दे सकते हैं, आप अलग से केवल स्की और संबंधित उत्पाद मदों पर बोनस दे सकते हैं, आप केवल कोलंबिया ब्रांड के उत्पादों पर और निश्चित समय पर बोनस की पेशकश कर सकते हैं - और यह सब, गठबंधन, गठबंधन।
सौभाग्य से, नेटवर्क का विकास उस बिंदु तक पहुंच गया है जहां इंटरनेट लगभग हर जगह पहले से ही दिखाई दिया है, और समाधान को ऑनलाइन लाना संभव था। यही है, काम की योजना इस तरह बन गई है - एक स्थिर नेटवर्क चैनल के साथ एक स्टोर है, यह शेष के लिए डेटाबेस से संपर्क करता है (और अब डेटाबेस सभी सबसे ताज़ा और सबसे स्वादिष्ट है), डेटाबेस से बाकी बोनस लेता है और इसके साथ काम करता है। और यह सब, जबकि खरीदार खुशी से एक दोस्ताना विक्रेता के साथ संचार करता है।
तीसरी समस्या बोनस बर्निंग ऑपरेशन का प्रदर्शन था। हमारे पास एक ही बात है - आप पूरे साल शानदार तरीके से अंक अर्जित कर सकते हैं, लेकिन 1 मार्च को अगर आप उन्हें खर्च करने का प्रबंधन नहीं करते हैं, तो वे हमेशा विश्वासघात करते हैं।
सिस्टम का पहला संस्करण (जिसे सीएआरडीएस कहा जाता है) आम तौर पर उन्हें ध्यान में रख सकता है, लेकिन जब यह बोनस इंक्रींटर प्लांट मोड में बदल गया, तो समस्याएं शुरू हो गईं। आखिरकार, परिवर्तन के साथ पूरे आधार के माध्यम से जलती हुई बोनस एक पूर्ण मार्ग है। आधार के आकार को देखते हुए, इसमें 3-4 दिन लग सकते हैं। इसके अलावा, इस प्रक्रिया में वह बहुत धीमा और बेवकूफ हो गया, जिसके कारण कभी-कभी बोनस जलने में बाधा उत्पन्न होती थी, और यह पता चला कि कुछ स्टोर में, कॉमरेड पेत्रोव, जो नए पिंग-पोंग गेंदों के लिए आए थे, के पास अभी भी बोनस था, और सिदोरोव, जो के लिए चले गए थे। दुर्भाग्य से, कोई नया महान नहीं।
सिस्टम का नया संस्करण
हमने 3-4 दिनों में कहीं एक प्रोटोटाइप बनाया, फिर कुछ दिनों तक हमने इसका लाइव चेक किया। यह पता चला कि यह प्रणाली अपने लिए काफी कार्यात्मक है, और आप इसका उपयोग विभिन्न बोनस स्थितियों और संचार ग्रंथों को उत्पन्न करने के लिए कर सकते हैं।
वैसे, संचार के बारे में - बहुत शुरुआत से हमने इसे बनाया ताकि वफादारी प्रणाली ने सही समय पर ग्राहकों के साथ संचार के ग्रंथों का गठन किया, डेटाबेस से बोनस अंक निकाले, और उन्हें स्वयं ग्राहकों को भेजा। हमारे पास बहुत सारे ग्राहक थे, इसलिए हमने एसएमएस भेजने के लिए तीसरे पक्ष के प्रदाताओं का उपयोग किया।
उनके साथ बातचीत कुछ इस तरह हुई:
- प्रदाता समझ गया कि वह एक प्रमुख ग्राहक है, और आनन्दित होने लगा
- हम में से एक प्रमुख ग्राहक निर्दिष्ट करता है कि क्या प्रदाता वास्तव में इस तरह के मेलिंग को हैंडल करेगा
- प्रदाता ने कहा कि यह निश्चित रूप से मास्टर करेगा
- प्रदाता ने थोड़े समय में एक बड़ी मात्रा में एसएमएस भेजने का कार्य प्राप्त किया और आराम करने के लिए लेटने का निर्णय लिया
तो, प्रोटोटाइप के बारे में। सिद्धांत रूप में, पूरे सिस्टम को भारी पुनर्रचित करने का निर्णय लिया गया था, क्योंकि शुरू में यह केवल बोनस के लिए तेज किया गया था, और ऑनलाइन काम के लिए नहीं, इसलिए यह वापसी के साथ सामना करने की उम्मीद नहीं थी। इसके अलावा, यह निश्चित रूप से गिर गया, उच्च भार के क्षणों के दौरान। यही है, स्टोर के लिए सबसे स्वादिष्ट समय पर - नया साल, 8 मार्च, 23 फरवरी और अन्य सुखद तिथियां।
सिस्टम गिरता है -> व्यवसाय का मूड गिरता है -> हर किसी का मूड गिर जाता है।
एक सहयोगी के साथ, हम निम्नलिखित सिद्धांत के अनुसार सिस्टम को फिर से लिखते हैं।
घटक 1. प्रीप्रोसेसिंग जो दुकानों को जल्द से जल्द जवाब देता है।
घटक 2. प्रसंस्करण, एक ही जादू बॉक्स, कमोडिटी चेक पर मुश्किल और चतुराई से बोनस जमा करना।
घटक 3. विपणन, यह सब एक साथ एकत्रित करना और संचार के ग्रंथों का निर्माण करना।
साथ ही, हमने बर्निंग बोनस की समस्या को हल किया। नई प्रणाली बस उन्हें जला नहीं थी। आखिरकार, यदि आप सिस्टम को बोनस को जलाने के लिए मजबूर नहीं करते हैं - तो आपको जलते हुए बोनस के साथ कोई समस्या नहीं है।
नए संस्करण में, सिस्टम केवल डेटाबेस में प्रत्येक क्लाइंट के बोनस को संग्रहीत करता है, लेकिन कुछ समय में उन्हें सक्रिय मानने के लिए बंद हो जाता है। यही है, अब हमेशा बोनस होते हैं, लेकिन प्रत्येक गतिविधि की अपनी अवधि के साथ। जो, संयोगवश, अधिक सटीक और अधिक जरूरी प्रचार और अभियान शुरू करने की अनुमति देता है।
पुरानी प्रणाली वास्तव में इन कार्डों पर कार्ड और बोनस का रिकॉर्ड रखती थी। नई प्रणाली एक कार्ड को प्राथमिकता नहीं देती है, लेकिन एक व्यक्ति के खाते को। हम इसे फोन नंबर से पहचान सकते हैं (यह बात हमारे लिए शुरू से ही काम करती है, हम फोन नंबर द्वारा प्राधिकरण को लागू करने वाले पहले में से एक थे)।
नई प्रणाली की एक अतिरिक्त विशेषता तथाकथित उत्पाद बोनस है, यह इस तरह काम करता है:
- प्रत्येक उत्पाद में विशेषताएँ (नाम, उत्पाद श्रेणी, आकार, रंग, खेल, अन्य, अन्य, अन्य) हैं।
- सिस्टम बोनस जमा करने के लिए एक तार्किक स्थिति बनाने, इन विशेषताओं को जोड़ती है।
- जब एक चेक आता है, तो यह स्थिति हमेशा जाँची जाती है।
हमने इस प्रोटोटाइप को व्यावसायिक कार्यों में दिखाया। व्यापार ने आगे बढ़ा दिया।
हमने 1 मार्च को सिस्टम लिखना शुरू किया, इसे 27 अक्टूबर 2013 को चालू किया (हमने एक साथ लिखा, हाँ)। वास्तव में, नियोजित डिलीवरी की तारीख 1 सितंबर थी, लेकिन सिस्टम के मुख्य प्रतिपक्ष के पास समय नहीं था - खुदरा स्टोर। स्टोर्स के पास कई कारणों से समय नहीं था, साथ ही सभी ने कैश रजिस्टर सॉफ़्टवेयर को अपडेट नहीं किया (और एक बड़े नेटवर्क पर कैश रजिस्टर सॉफ़्टवेयर को अपडेट करना अभी भी एक दर्द है)। इसलिए, उन्होंने इसे स्थगित कर दिया, उनके लिए इंतजार किया और 27 अक्टूबर को शुरू किया।
सिस्टम की विचारधारा
उन्होंने मुख्य विचार रखा - न तो स्टोर, न ही कैश रजिस्टर सॉफ्टवेयर अब बोनस के तर्क के साथ काम करते हैं। स्टोर अब केवल ग्राहक की टोकरी केंद्र को भेजता है, केंद्र पूरी प्रक्रिया करता है, स्टोर को बोनस की गणना देता है।
अब बोनस इस तरह से फैलाया जाता है:
- सबसे पहले, सभी वस्तुओं के लिए बोनस समान रूप से चेक से बाहर फैलाया जाता है। यह एनालिटिक्स के लिए उपयोगी है, और माल की वापसी के मामले में मदद करता है।
- हमने प्राथमिकता बोनस की अवधारणा पेश की। बोनस कमोडिटी हैं, जन्मदिन के लिए बोनस हैं, जिनकी वैधता अवधि कम है, नियमित हैं (सबसे अधिक कठिन) हैं। इसलिए, हम पहले विशिष्ट बोनस लिखते हैं। यही है, एक व्यक्ति स्कीइंग के लिए आया था - हम मुख्य रूप से बोनस को लिखेंगे जो उसके स्की पर है। और यह पता चला कि वह स्कीइंग के लिए आया था, हमने नियमित बोनस लिखा था। एक हफ्ते बाद वह एक जैकेट के लिए आएगा, और हम उसे एक आदमी देंगे, आपके पास केवल स्कीइंग के लिए बोनस है। क्या आप स्की करना चाहते हैं? जन्मदिन की अवधि के दौरान खरीद के साथ एक ही बात, पहले उन्हें लिखो, और फिर नियमित रूप से।
- हम वापस कार्यालय के संचालन और सामने ले जाते हैं। अब, अनुरोधों के साथ आने वाले स्टोर बोनस की गणना और इसके विपरीत सेवा के कार्य और प्रदर्शन को प्रभावित नहीं करते हैं
सामान्य तौर पर, सभी पुरानी समस्याओं को रोकना संभव था, और नई समस्याओं के बजाय नई सुविधाओं को जोड़ते हैं।
बैकलॉग के बजाय, हमारे पास अलेक्जेंडर की यह नोटबुक थी।


सिस्टम का एक नया संस्करण लॉन्च करना
चूंकि नई प्रणाली न केवल तकनीकी रूप से, बल्कि वैचारिक रूप से भी पुरानी से अलग थी, इसलिए हम इसे आंशिक रूप से, दुकानों के आधे हिस्से में या किसी भी तरह से रोल नहीं कर सके। हमें बस पुराने को बंद करना था और इसके बजाय नए को चालू करना था।
यह अच्छा लगता है, लेकिन वास्तव में यह कुछ हद तक सीमित हो जाता है।
सबसे पहले, बड़ी संख्या में स्टोर (1200+) के कारण, हमें 3 घंटे में सब कुछ करने का प्रबंधन करना पड़ा। जबकि एक स्टोर एक समय क्षेत्र में आधी रात को बंद हो जाता है, दूसरे में पूरी तरह से अलग समय होता है, और फिर एक सुविधा स्टोर भी होता है। सामान्य तौर पर, पुराने सिस्टम से सभी डेटा को परिवर्तित करने के लिए, नया एक फ़ीड करें, तीन सर्वरों पर एक बार शुरू करें - 3 घंटे।
नुकसान इस तरह थे:
- सिस्टम पूरे नेटवर्क पर तुरंत कट गया था। यदि हर जगह सब कुछ अच्छा है - सब कुछ नेटवर्क पर काम करता है। यदि कुछ गिरता है, तो हाँ, यह पूरे नेटवर्क पर पड़ता है।
- जब आप नई प्रणाली को चालू करते हैं, तो इसमें वह सभी डेटा होना चाहिए जो पुराने सिस्टम में उस समय था जब स्टोर्स बंद हो गए और नवीनतम बोनस जारी किया गया। हमने 4 देशों में एक साथ लॉन्च किया। डेटाबेस एक टेराबाइट से अधिक था और सैकड़ों अरबों रिकॉर्ड संग्रहीत किया गया था।
- 23.00 बजे हमें सिस्टम बंद करना पड़ा। सब कुछ कन्वर्ट। नई व्यवस्था में डालो। सब कुछ शामिल करें। इस मामले में, सब कुछ काम करना चाहिए।
हमने लंबे समय तक प्रशिक्षित किया, सबसे अधिक लिप्त पर लिपियों को लटका दिया। लंबे परीक्षणों और सब कुछ जल्दी से जल्दी करने का प्रयास करने के बाद, हमने 9 बजे सबसे अच्छा परिणाम प्राप्त किया।
जो 3 घंटे के नियोजित आंकड़े से थोड़ा अलग था।
फिर हमने पहले प्रीप्रोसेसिंग करने का फैसला किया, जिसने अवशेषों को खुद में रखा। मुख्य सर्वर को उठाया, उसने दुकानों से संपर्क किया। उसी समय, वह नहीं जानता था कि पूरी प्रणाली अभी तक नहीं बढ़ी थी, और उस समय हम बहादुरी से सब कुछ रोल कर रहे थे।
लेकिन फिर भी, मानक मशीनों पर डेटा की इतनी मात्रा एक समय पर ढंग से नहीं की जा सकती है।
और यहाँ यह ओरेकल एक्सडाटा को नोट किया जाना चाहिए। ओरेकल के लोगों ने हार्डवेयर का एक विशेष टुकड़ा बनाया जो अपने स्वयं के डेटाबेस के साथ बहुत अच्छा काम करता है, और यहां तक कि फ्लैश ड्राइव पर भी। सामान्य तौर पर, एक्सडाटा का उपयोग करने के लिए एक मजबूत इच्छाशक्ति वाला निर्णय लिया गया था। परीक्षणों पर इसकी मदद से, हमने 9 के बजाय 2 घंटे में आपकी ज़रूरत का हर काम करने में महारत हासिल की और महसूस किया - हमें इसे लेने की आवश्यकता है।
चूँकि हम सावधानी से काम करने वाले लोग हैं, काम करने और काम करने की प्रक्रिया में, हमने बगों का एक समूह तैयार किया और एक मार्जिन के साथ ओरेकल के समर्थन को विफल कर दिया। उदाहरण के लिए, एक दिलचस्प बग था - अनुरोध के आंतरिक प्रसंस्करण में त्रुटि के कारण, ओरेकल ने टीईएमपी का गहन उपभोग करना शुरू कर दिया। हमने समय पर इस पर ध्यान दिया, और उसे TEMP'ovyh फाइलें फेंक दीं, जब वह नशे में था, तो यह बहुत दिलचस्प था। लेकिन जब से लोहे का टुकड़ा बहुत समझदार और जानकार निकला, उसने 10 मिनट के लिए भावना के साथ 3 Tb TEMP का उपयोग किया, यह महसूस किया कि वह और नहीं थी, और सेवानिवृत्त हुई। मुझे वर्कअराउंड के साथ आना पड़ा।
एक ओर, यह अच्छा था कि रूपांतरण के मामले में सब कुछ हमने 2 घंटे में किया। दूसरी ओर, स्वच्छ रूपांतरण की पूरी प्रक्रिया में, 2 घंटे, और हमने भी योजना बनाई:
- पुरानी प्रणाली के सर्वर से सभी डेटा को पुनः लोड करें, क्योंकि यह बेतहाशा तेजी से सब कुछ गिनता है।
- पुरानी संरचनाओं से डेटा को नए में बदलें।
- इस सभी को अच्छे से तीन अलग-अलग सर्वर में डालें।
उसी समय, प्रत्येक डेटाबेस में उपयोगी सेवा सूचनाओं का एक गुच्छा होता था जैसे कि वही अनुक्रमणिकाएँ जो पुनर्निर्माण के दौरान मदद कर सकती थीं, लेकिन हमने इस पर स्कोर किया और युद्ध के सर्वर पर पहले से ही सब कुछ फिर से बनाने का फैसला किया।
ट्रेनिंग
हमने और मुख्य के साथ तैयार किया। हम काम पर सो रहे थे। हमने न केवल स्क्रिप्ट के साथ, बल्कि कई मैट्रिक्स के साथ खुद को लटका दिया।
हर दिन 23.00 बजे हमने प्रक्रिया शुरू की और मैट्रिक्स पर नज़र रखी। हमने आवश्यक बदलाव किए, परिणामस्वरूप, हमने सब कुछ सेट किया ताकि कुछ भी गलत न हो।
बेशक, लॉन्च के दिन कुछ गलत हो गया।
हमारे सम्मान के लिए, कैंट हमारी तरफ नहीं था। कहीं-कहीं नेटवर्क बेधड़क उड़ गया। यही है, आप अपने आप को इस तरह से बैठते हैं, आप सब कुछ सेट करते हैं ताकि मच्छर न केवल अपनी नाक को कम कर दे, लेकिन इसके बारे में सोचने का समय भी नहीं है - और कहीं, किसी ने सिर्फ गलत केबल खींची है।
वैसे भी, हम समय पर पहला सर्वर शुरू करने में कामयाब रहे। सामान्य समय सीमा सुबह 5 बजे थी, इस समय तक सभी सर्वर हंसमुख और हंसमुख होने चाहिए, क्योंकि सुदूर पूर्व में पहला स्टोर अपने समय में 10 बजे खुला।
इसलिए आखिरी सर्वर सुबह 11 बजे शुरू हुआ। लेकिन जब से हमने सिस्टम को इस तरह से बनाया कि सब कुछ अलग-थलग हो गया, सब कुछ ठीक चला।
अभी
वर्तमान में, 14 डेवलपर्स और 8 विश्लेषक क्लब सिस्टम पर काम कर रहे हैं। उन सभी अच्छाइयों को ध्यान में रखते हुए जिन्हें हमने चारों ओर लटका दिया था, यह अब केवल एक कार्ड नहीं है जो आपको दुकानों में खर्च करने के लिए निश्चित संख्या में बोनस प्रदान करता है।
हमने बोनस को पूरी तरह से संयोजित करना शुरू किया। सिस्टम के लिए एक सफल संयोजन के लिए मुख्य मानदंड खरीदार के लिए अधिकतम लाभ है। उदाहरण के लिए कई उपयोगिताएँ और प्रचार हो सकते हैं:
- उपयोगकर्ता ने नियमित बोनस की एक अच्छी संख्या जमा की है;
- प्लस अब वह अवधि जब किसी विशेष ब्रांड पर कोई कार्रवाई होती है;
- इसके अलावा अब एक विशिष्ट उत्पाद समूह और उपसमूह पर भी छूट;
- और किसी विशेष शहर या किसी विशेष स्टोर में छूट भी हो सकती है।
हमने एक एल्गोरिथ्म लिखा था जो एक स्टोर से एक चेक प्राप्त करता है, चेक में उत्पाद की वस्तुओं पर चलता है, किसी दिए गए दिनांक और किसी दिए गए शहर में इसके लिए सभी संभावित प्रचार और छूट लागू करता है, और वह परिणाम देता है जो उपयोगकर्ता के लिए सबसे अधिक फायदेमंद है। फिर वह इसे स्टोर में वापस कर देता है। और अभी भी विकास की दिशाएं हैं:
- मेलिंग सहित जटिल मल्टी-वे मार्केटिंग अभियान शुरू करने के लिए एक तंत्र का विकास, बोनस प्रदान करना, छूट और ग्राहक के लिए ऑफ़र को निजीकृत करना
- नए संचार चैनलों का कनेक्शन, जैसे त्वरित संदेशवाहक, सामाजिक नेटवर्क, आदि।
एक आभारी ग्राहक इस क्षण को याद कर सकता है कि वह मोजे खरीदना चाहता था, और उन्हें चेक में जोड़ने के लिए कहता है। बेशक, मोज़े जोड़ना (या जो भी हो) को एक पूर्ण पुनरावृत्ति की आवश्यकता है।
लेकिन हम इससे भी निपटेंगे। और भविष्य के एक पोस्ट में हम आपको स्पोर्टमास्टर की साइट के निर्माण की कहानी बताएंगे।