Wallet को अपने stack में जोड़ें या platform बदलें?

अगर आपके कस्टमर एंगेजमेंट प्लेटफॉर्म में native wallet passes नहीं हैं, तो आपके पास 2 रास्ते हैं। एक pass tool जोड़ें और 2 systems को sync रखें, या ऐसे platform पर जाएं जो Apple और Google Wallet passes उसी customer profile पर issue करता है। पहला रास्ता शुरू करने में तेज़ है। दूसरा तब चलाने में आसान है, जब wallet आपकी journeys का हिस्सा बन जाए।

यह guide Braze, OneSignal या CleverTap जैसे platforms पर काम करने वाली उन teams के लिए है जो सब कुछ उखाड़े बिना wallet passes चाहती हैं। Vendor-level तुलना के लिए Wallet passes comparison देखें।

आप कहां से शुरू कर रहे हैं

Engagement platforms में wallet support बहुत अलग-अलग है। Braze PassKit जैसे partners के ज़रिए wallet जोड़ता है। OneSignal में native wallet passes नहीं हैं। Plan करने से पहले अपने platform के current docs check करें, क्योंकि यह बदलता रहता है।

Native support के बिना pass 1 system में रहता है और customer दूसरे में। आप जो भी pass issue, update या target करते हैं, उसे दोनों का data चाहिए।

भारत में Android का share 95%+ है, इसलिए ज़्यादातर Indian apps के लिए असली सवाल Google Wallet का है। आप कोई भी रास्ता चुनें, पहले यह देखें कि Google Wallet passes का flow कितनी आसानी से आपके customer data से जुड़ता है। iOS users कम हैं, लेकिन cross-platform program में Apple Wallet भी साथ चाहिए।

Route A: अपना CEP रखें और pass tool जोड़ें

आप push, email और segments के लिए अपना current platform रखते हैं और Apple और Google Wallet के लिए एक standalone pass tool जोड़ते हैं।

आमतौर पर यह ऐसे काम करता है। आपका CEP या backend passes issue करने के लिए pass tool की API call करता है, अक्सर webhooks के ज़रिए। अगर pass tool events देता है, तो वे वापस आपके CEP में आते हैं, ताकि आप holders को segment कर सकें।

इसका फ़ायदा असली है। कुछ भी migrate नहीं होता। आपकी team अपने tools और journeys रखती है, और आप 1 use case से शुरू कर सकते हैं, जैसे loyalty card।

नुकसान समय के साथ बढ़ता है। Sync करने के लिए 2 databases, 2 subscriptions, 2 security और GDPR reviews। हर scenario जो pass update को message के साथ जोड़ता है, जैसे “आपके points जल्द expire होंगे”, 2 tools में बनता है।

Route B: native wallet वाले platform पर जाएं

आप messaging को ऐसे platform पर ले जाते हैं जो wallet passes natively issue करता है, उसी profile पर जिस पर push, in-app, email और SMS हैं।

Passes platform के अंदर User ID से issue होते हैं। Segments, journeys और channels सभी pass holder को 1 customer के रूप में देखते हैं। 1 journey step pass issue करता है, और अगला step link भेजता है।

आपको मिलता है 1 profile, 1 journey और 1 contract। Pass updates और messages एक ही trigger से आते हैं, और संभालने के लिए कोई sync layer नहीं।

इसकी कीमत खुद migration है: SDK changes, data import, journeys और templates को फिर से बनाना। यह तब फ़ायदेमंद है जब wallet एक long-term channel हो, one-off campaign नहीं।

Decision framework

4 सवालों पर खुद को score करें।

अगर आपके 2 या ज़्यादा जवाब “long-term”, “ज़्यादा”, “developers नहीं” या “कम processors” हैं, तो Route B को गंभीरता से देखें। अगर एक भी नहीं, तो Route A बिल्कुल ठीक choice है, और आप एक साल बाद इस पर फिर सोच सकते हैं।

Timing भी मायने रखती है। Indian e-commerce के लिए अक्टूबर–नवम्बर में Diwali, Big Billion Days और Great Indian Festival का peak होता है। अगर आप Route B चुनते हैं, तो migration को इस sale season से पहले पूरा करने या उसके बाद शुरू करने का plan बनाएं, ताकि सबसे busy हफ़्तों में आपकी journeys दो platforms के बीच न अटकें।

2 tools की cost गिनना

पहले दिन Route A सस्ता दिखता है, क्योंकि कुछ भी move नहीं होता। एक साल में वो हिस्से जोड़ें जो pass vendor के invoice पर कभी नहीं दिखते: integration बनाना, sync maintain करना, journeys का दोहरा काम और दूसरा vendor review।

Route B cost को शुरुआत में लाता है: migration का काम, फिर 1 platform fee। दोनों की तुलना 12 से 24 महीनों पर करें, 1 पर नहीं।

Migration checklist

अगर आप Route B चुनते हैं, तो move को tool के आसपास नहीं, customer के आसपास plan करें।

• जो भेजते हैं, उसका audit करें। Push, email, SMS और in-app campaigns, journeys और segments की list बनाएं जिन्हें move होना है।
• अपना data map करें। User IDs, tags, events और consent records। User ID ही pass को customer से जोड़ता है।
• Wallet एक बार set up करें। Apple Pass Type ID certificate (Apple Developer account, $99 सालाना) और Google Issuer ID, जिसमें Pushwoosh service account आपके issuer में invited हो।
• SDK integrate करें। अपने app में पुराना SDK बदलें और traffic move करने से पहले push test करें।
• पहले मुख्य journeys फिर से बनाएं। Welcome, abandoned cart, win-back, फिर नए wallet scenarios।
• Pass launch plan करें। Journey step से passes issue करें और link email, SMS या push से भेजें।
• थोड़े समय parallel चलाएं। पुराने platform को छोटे overlap के लिए रखें, फिर बंद करें।

Move के दौरान, अपने backend से passes issue करने के लिए API इस्तेमाल करें।

FinTech और EdTech apps के लिए checklist में एक line और जोड़ें: transactional flows। UPI या payment alerts और course reminders जैसे messages users रोज़ देखते हैं, इसलिए इन्हें marketing journeys से पहले नए platform पर test करें और parallel run के दौरान दोनों तरफ़ से duplicate न जाने दें।

Pushwoosh के साथ अपना stack आसान बनाएं

Pushwoosh native Apple और Google Wallet passes उसी User ID, segments और journeys पर issue करता है जिन पर push, in-app, email, SMS और WhatsApp हैं। यह 1 platform है, Germany और US में अपने infrastructure पर hosted, GDPR compliance और SOC 2 Type 2 के साथ। देखें कि wallet options में Pushwoosh कहां fit होता है।

Wallet जोड़ने का मतलब 1 और tool जोड़ना नहीं होना चाहिए। इसका मतलब होना चाहिए 1 customer profile, जिस पर हर channel काम कर सके।

FAQ