Prodantix

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

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

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

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

इवेंट

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

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

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

निर्णय

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

कार्रवाई

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

देखें Prodantix: prodantix.com