Prodantix

Prodantix उन लोगों के लिए बना है जो सॉफ़्टवेयर बनाते हैं। हर प्रोडक्ट टीम वही तीन सवाल पूछती रहती है: लोग हमारे ऐप में असल में कर क्या रहे हैं, किसे कौन सा हिस्सा दिखना चाहिए, और उनसे कुछ कहने का सही वक़्त कब है।

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

यह इंजन किस तरह बना है

इंजन चार बुनियादी इकाइयों से बना है, और बाकी सब कुछ उन्हीं पर टिका है। इन्हें क्रम से समझना ठीक रहता है, क्योंकि हर एक अगली को आगे बढ़ाती है। कॉन्सेप्ट रेफ़रेंस इन्हें पूरा कवर करता है।

इवेंट

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

उपयोगकर्ता स्थिति

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

निर्णय

उपयोगकर्ता स्थिति के आधार पर आँका जाने वाला नियम: कौन किसी कोहॉर्ट में आता है, किसे फ़्लैग मिलता है, कौन किसी संदेश के योग्य है। चूँकि निर्णय उसी क्षण की जीवंत स्थिति पढ़ता है जब वह पूछा जाता है, वह किसी पुरानी तस्वीर से जवाब नहीं दे सकता।

कार्रवाई

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

एनालिटिक्स यानी स्थिति को पढ़ना

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

वह सवाल सहेजना जो आप दोबारा पूछेंगे

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

जब कोई आँकड़ा अपने आप हिल जाए

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

वे लोग जिनके बारे में यह स्टेट है

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

एक व्यक्ति, कई आईडी

कोई आगंतुक आपके यह जानने से पहले ही आ जाता है कि वह कौन है। SDK उसे एक आईडी देता है, वह तीन पेज पढ़ता है, और उसके बाद ही साइन अप करता है। जब तक कोई इंजन को यह न बता दे कि वह कौन है, प्रोफ़ाइल पर कोई नाम होता ही नहीं, और डायरेक्टरी अनुमान लगाने के बजाय यही कहती है। जब साइन अप होता है, तब आईडी एक शृंखला में जुड़ जाती हैं जो एक ही प्रामाणिक पहचान तक पहुँचती है, इसलिए बिना नाम वाला रास्ता दूसरा प्रोफ़ाइल खोलने के बजाय नामवाले खाते में समा जाता है। हर पंक्ति दिखाती है कि कितनी आईडी उस तक पहुँचती हैं, और प्रोफ़ाइल उन्हें गिना देती है। जहाँ इंजन खुद तय नहीं कर पाता, वहाँ आप दो प्रोफ़ाइल हाथ से जोड़ सकते हैं: कौन-सी पहचान बचेगी यह आप चुनते हैं, टकराव में उसी की प्रॉपर्टी जीतती है, और गिनतियाँ जुड़ जाती हैं। वह फिर अलग नहीं होता। जुड़ने से पहले प्रोफ़ाइल जैसी थी वैसी ऑडिट रिकॉर्ड में रहती है, इसलिए वह क्या कहती थी यह वापस मिल सकता है, पर एक बार जुड़ जाने के बाद दोनों व्यक्ति अलग नहीं किए जा सकते।

एक सेशन को दोबारा देखना

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

रिकॉर्डिंग को क्या रखने की अनुमति है

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

अलग-अलग लोगों को अलग-अलग चीज़ें दिखाना

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

ऐसे संदेश जो तब पहुँचें जब वे काम के हों

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

जब वे जवाब लिखते हैं

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

क्रम को खुद जोड़ना

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

AI ऑर्केस्ट्रेशन, और चक्र कैसे पूरा होता है

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

प्रस्ताव किसी व्यक्ति की राह देखता है

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

इवेंट भीतर लाना

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

कुंजियाँ और एनवायरनमेंट

हर SDK कॉल एक प्रोजेक्ट कुंजी लेकर चलती है, जो कंसोल से आती है। प्रोजेक्ट बनाते ही दो एनवायरनमेंट बनते हैं, live और test, हर एक की अपनी कुंजी: test से बनाइए, live से भेजिए। दोनों कुंजियाँ बनने के ठीक बाद केवल एक बार दिखती हैं, क्योंकि सर्वर सिर्फ़ हैश रखता है और कोई स्क्रीन उन्हें दोबारा नहीं दिखा सकती। रोटेशन आपके चुने एनवायरनमेंट के लिए नई कुंजी बनाता है, और पुरानी तुरंत बंद हो या रियायत अवधि के बाद, यह आप तय करते हैं।

इससे बात करने के चार रास्ते

REST तीन होस्ट पर फैला है: एक फ़्लैग और मैसेजिंग के लिए, एक इवेंट इनजेशन के लिए, एक सेशन रीप्ले के लिए, और हर एक /openapi.json पर अपना OpenAPI दस्तावेज़ देता है। इनजेशन 202 लौटाता है, यानी इवेंट प्रोसेसिंग के लिए स्वीकार हुआ है, संग्रहीत नहीं: ख़राब इवेंट आगे पाइपलाइन में भी हटाया जा सकता है। GraphQL पूरे एप्लिकेशन मॉडल को कवर करता है, जिसमें प्रोजेक्ट, फ़्लैग, वर्कफ़्लो, एनालिटिक्स, मैसेजिंग, कोहॉर्ट और बिलिंग शामिल हैं। रियल-टाइम सरफ़ेस फ़्लैग बदलाव, संदेश और वर्कफ़्लो रन प्रसारित करता है, और अप्रमाणित कनेक्शन तुरंत काट देता है। MCP सरफ़ेस एजेंटों को टूल कॉल से पढ़ने-लिखने देता है; यह मशीन-से-मशीन है और ब्राउज़र अनुरोध अस्वीकार करता है।

डेटा आपका ही रहता है

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

यह किसके लिए है

Prodantix उन टीमों के लिए ठीक है जो इस काम के लिए दो-तीन अलग टूल चला रही हैं और उनके आपस में न मिलने से तंग आ चुकी हैं। यह तब सबसे काम आता है जब ग्राहक इतने हो जाएँ कि पूछ-ताछ करके यह जानना मुमकिन न रहे कि वे कर क्या रहे हैं।

देखें Prodantix: prodantix.com