कस्टमर जर्नी बिल्डर

इवेंट होते ही जर्नी शुरू करें

यूज़र जैसे ही कुछ ज़रूरी करे — cart में add करे, payment fail हो, order place करे — journey उसी पल शुरू करें। अगले scheduled segment pull का इंतज़ार नहीं।

Customer Journey Builder में Trigger-based entry element setup screen: point name Cart recovery, event add_to_cart, और entry condition जहाँ cart_value 50 से ज़्यादा है

जिस पल कुछ होता है, journey वहीं से शुरू हो

आप चाहते हैं कि आपकी journey उसी पल शुरू हो जब कुछ होता है, ना कि जब भी अगला segment refresh आए। ये वादा करना आसान है, निभाना मुश्किल — जैसे ही एक साथ एक से ज़्यादा automations चल रहे हों: एक cart-abandonment sequence बाकी दर्जन के बीच बैठा हुआ, हर एक अपने आप में ठीक। “हमने देखा आप कुछ छोड़ गए,” जो एक nightly batch एक घंटे बाद भेजे, वो एक अलग ही message है उस message से जो व्यक्ति के फोन रखने से पहले ही चल पड़ा हो। Trigger-based entry यही gap बंद करता है — Big Billion Days जैसी sale के पीक ट्रैफिक में भी।

Trigger-based entry क्या करता है

एक event चुनें, और जो कोई भी उसे fire करे वो उसी पल journey में enter हो जाए, किसी saved segment के अगले scan का इंतज़ार किए बिना।

रियल-टाइम में react करता है

Event fire होते ही enter करता है, अगले scheduled scan का इंतज़ार नहीं।

Payload पर filter करता है

Event के अपने attributes पर optional conditions सिर्फ नाम से आगे entry qualify करती हैं।

एक साथ कई sessions चलाता है

order_id या product_id से keyed concurrency एक यूज़र को कई parallel runs रखने देती है।

Re-entry control करता है

हर element के हिसाब से repeat trigger block करें, या उसे session restart करने दें।

सेटिंगविकल्प
Event sourceSDK postEvent, REST API, default PW_* events, custom events, geozone entry या exit
Entry conditionOptional: event के अपने attributes पर filter करें (attribute, operator, value)
कौन enter करता हैजिसने event fire किया वो यूज़र, या event के payload के अंदर नामित यूज़र
Re-entryAllow ना करें (default), या allow करें और session restart करें
Concurrencyप्रति यूज़र एक active session, या कई, किसी session attribute जैसे order_id या product_id से keyed
सेटिंग
1 / 5
Event source
विकल्प
SDK postEvent, REST API, default PW_* events, custom events, geozone entry या exit
सेटिंग
2 / 5
Entry condition
विकल्प
Optional: event के अपने attributes पर filter करें (attribute, operator, value)
सेटिंग
3 / 5
कौन enter करता है
विकल्प
जिसने event fire किया वो यूज़र, या event के payload के अंदर नामित यूज़र
सेटिंग
4 / 5
Re-entry
विकल्प
Allow ना करें (default), या allow करें और session restart करें
सेटिंग
5 / 5
Concurrency
विकल्प
प्रति यूज़र एक active session, या कई, किसी session attribute जैसे order_id या product_id से keyed

Audience-based entry किसी schedule पर segment को फिर से check करता है। ये उसी पल react करता है जब event fire होता है, और प्रति यूज़र कई sessions चलने का मतलब है कि Big Billion Days जैसी sale में एक यूज़र के 3 open orders अपनी-अपनी status journey अलग-अलग drive कर सकते हैं, एक-दूसरे से टकराए बिना। किसी बाद के event को उन sessions में से सही वाले पर वापस route करना Wait for Trigger की session-scoped matching का काम है, canvas पर आगे। Conditions और re-entry control समेत पूरा element free plan पर मिलता है।

Journey builder के लिए ये क्यों मायने रखता है

कोई journey builder अपने entry points जितना ही अच्छा होता है। Audience-based entry scheduled cadence cover करता है: newsletters, win-back sweeps। इसके ऊपर एक builder को चाहिए उस पल react करने का तरीका जब payment fail हो (जैसे एक UPI transaction) या cart छूट जाए, और यही Trigger-based entry Customer Journey Builder को देता है। ये उसी event catalog से पढ़ता है जो canvas का बाकी हिस्सा पहले से segmentation और branching के लिए इस्तेमाल करता है, तो दरवाज़ा खोलने वाला signal वही होता है जो उसके बाद पूरा flow drive करता है।

आगे ये क्या hand off करता है

एक add_to_cart event fire होता है और ये एक cart-recovery journey शुरू करता है। एक Wait for Trigger element फिर खरीदार को खरीद पूरी करने के लिए 90 दिन तक का समय देता है, win-back में branch करने से पहले। कोई भी element अपने आप कुछ नहीं भेजता। दोनों एक channel block को hand off करते हैं, और entry element ने पहले ही तय कर दिया था कि flow में कौन था।

जो event एक session शुरू करता है वो वो key भी carry कर सकता है जो एक बाद वाले branch को एक order को दूसरे से अलग बताने के लिए चाहिए, सब उसी Customer Journey Builder canvas पर।

Events और journeys उसी infrastructure पर रहते हैं जिसका नाम आप बता सकते हैं

हर event जिसे Trigger-based entry element पढ़ता है, बाकी platform जैसे ही infrastructure से गुज़रता है: Pushwoosh SOC 2 Type I और ISO 27001:2022 certified है, GDPR compliant है, और US और Germany में अपने hardware पर चलता है, BDSG के तहत। पूरी detail data safety page पर है।

ISO 27001:2022 CertifiedISO 27001 CertifiedGDPR CompliantData Privacy FrameworkHIPAA CompliantSOC 2 Type I CertifiedOWASP Compliant

ये कैसे काम करता है

  1. Entry element add करें

    Canvas पर, एक Trigger-based entry element add करें और event चुनें: कोई default PW_* event, या SDK postEvent या server call से भेजा गया कोई custom event।

  2. Entry को qualify और target करें

    Entry qualify करने के लिए event के attributes पर एक condition add करें, जैसे add_to_cart जहाँ cart_value 50 से ज़्यादा हो, और चुनें कि event fire करने वाला व्यक्ति enter करेगा, या payload के अंदर नामित यूज़र।

  3. Re-entry और concurrency सेट करें

    तय करें कि journey के अंदर पहले से मौजूद कोई व्यक्ति उसे दोबारा trigger कर सकता है या नहीं, और क्या एक यूज़र एक साथ कई sessions रख सकता है, किसी attribute जैसे order_id से keyed।

इसे wire up करने से पहले जानने लायक बातें।

  • Pushwoosh event से entry तक कोई latency SLA publish नहीं करता। Product इसे real-time बताता है, कोई numbered guarantee नहीं।
  • Re-entry खुद element पर एक binary switch है: नया trigger block करें, या session restart करें। एक graduated limit (दिन में एक बार, हफ्ते में एक बार, महीने में एक बार) journey level पर होती है, इस element पर नहीं।
  • इसके पीछे एक असली event stream चाहिए: SDK postEvent, या entry event पर hardware ID या User ID carry करने वाला कोई server/API call। इसके बिना, entry scheduled या segment-based start पर fall back करती है।
  • Schedule-based start उसी canvas पर एक अलग entry element से चलती है।
  • Conditions और re-entry समेत पूरा Trigger-based entry free plan पर मिलता है, 1,000 यूज़र्स तक। Events और journeys US और Germany में Pushwoosh-owned hardware पर चलते हैं, GDPR और BDSG के तहत। SOC 2 Type I.

एक event को एक live journey में बदलें।

संबंधित उत्पाद देखें

कस्टमर जर्नी बिल्डर

एक विजुअल टूल के साथ अपनी अभियानों को मैप करें और सुव्यवस्थित करें। Pushwoosh कस्टमर जर्नी बिल्डर का उपयोग करके संवाद करें, जुड़ाव बढ़ाएं, रिटेन करें, कन्वर्ट करें, सेगमेंट करें और प्रयोग करें।

इवेंट ट्रिगर मार्केटिंग

Customer actions पर automatically campaigns launch करें। Real-time behavioral triggers से conversion, retention और engagement के perfect moments capture करें।

Wait for Trigger जर्नी एलिमेंट

90 दिन तक 3 branches में 4 events track करें, AND/OR logic और session-scoped matching के साथ — food delivery और ride-hailing journeys के लिए बना।

टाइम डिले जर्नी एलिमेंट

जर्नी को fixed span, clock time, date, weekly slot, या profile पर मौजूद date से रोकें — हर यूज़र अपने टाइम पर अगला step पाए। Android-first टीमों के लिए।

परित्यक्त कार्ट को बहाल करें

कार्ट बहाली स्वचालन के साथ परित्यक्त कार्ट को राजस्व में बदलें। समय पर याद दिलाने, व्यक्तिगत प्रस्तावों और रूपांतरण को बढ़ावा देने वाले प्रोत्साहन भेजें।

पहुंच की जांच जर्नी एलिमेंट

Push, email, SMS, WhatsApp या LINE पर यूज़र तक पहुंच है या नहीं जानें, और बंद चैनल की जगह दूसरे चैनल पर रूट करें — बिना फॉलबैक लॉजिक हाथ से लिखे।