স্ট্যাকে ওয়ালেট যোগ করবেন, নাকি প্ল্যাটফর্ম বদলাবেন?

আপনার কাস্টমার এনগেজমেন্ট প্ল্যাটফর্মে যদি নেটিভ ওয়ালেট পাস না থাকে, আপনার সামনে 2টি পথ। একটি পাস টুল জুড়ে 2টি সিস্টেম sync রাখতে পারেন, অথবা এমন প্ল্যাটফর্মে যেতে পারেন যা একই কাস্টমার প্রোফাইলে Apple ও Google Wallet পাস ইস্যু করে। প্রথম পথে শুরু করা দ্রুত। ওয়ালেট যখন আপনার জার্নির অংশ হয়ে যায়, তখন দ্বিতীয় পথে চালানো সহজ।

ওয়ালেট পাস কী, সহজ ভাষায়? ফোনের Google Wallet বা Apple Wallet-এ সেভ থাকা একটি ডিজিটাল কার্ড: লয়্যালটি কার্ড, কুপন বা টিকিট। আর “নেটিভ” মানে প্ল্যাটফর্ম নিজেই পাস ইস্যু করে, মাঝখানে কোনো পার্টনার টুল ছাড়া।

লেখাটি সেই টিমগুলোর জন্য, যারা Braze, OneSignal বা CleverTap-এর মতো প্ল্যাটফর্মে আছেন আর সবকিছু ভেঙে না ফেলে ওয়ালেট পাস চান। ভেন্ডর ধরে তুলনা দেখতে Wallet passes তুলনা পেজটি দেখুন।

আপনি কোথা থেকে শুরু করছেন

এনগেজমেন্ট প্ল্যাটফর্মভেদে ওয়ালেট সাপোর্ট অনেক আলাদা। Braze পার্টনারের মাধ্যমে ওয়ালেট যোগ করে, যেমন PassKit। OneSignal-এ নেটিভ ওয়ালেট পাস নেই। পরিকল্পনার আগে নিজের প্ল্যাটফর্মের বর্তমান ডকুমেন্টেশন দেখে নিন, কারণ এটা বদলায়।

নেটিভ সাপোর্ট না থাকলে পাস থাকে 1টি সিস্টেমে আর কাস্টমার আরেকটিতে। আপনি যে পাসই ইস্যু, আপডেট বা টার্গেট করুন, দুই জায়গার ডেটাই লাগে।

বাংলাদেশ ও পশ্চিমবঙ্গে অনেক Android টিম শুরু করে Firebase (FCM) দিয়ে, কারণ এটাই সবচেয়ে পরিচিত পুশ টুল। এখানে প্রশ্নটা আরও গোড়ার: FCM শুধু মেসেজ ডেলিভারি করে, সেগমেন্টেশন, জার্নি বা অ্যানালিটিক্স দেয় না। তাই FCM-এর পাশে পাস টুল জুড়লে আপনার 2টি নয়, কার্যত 3টি অংশ মেলাতে হয়: ডেলিভারি, পাস, আর তাদের মাঝের কাস্টমার ডেটা।

পথ A: বর্তমান CEP রাখুন, সাথে পাস টুল যোগ করুন

পুশ, ইমেইল আর সেগমেন্টের জন্য আপনি বর্তমান প্ল্যাটফর্মই রাখেন, আর Apple ও Google Wallet-এর জন্য একটি স্ট্যান্ডঅ্যালোন পাস টুল জোড়েন।

সাধারণত এভাবে কাজ করে। আপনার CEP বা backend পাস টুলের API কল করে পাস ইস্যু করে, প্রায়ই webhook দিয়ে। পাস টুল যদি ইভেন্ট দেয়, সেগুলো আপনার CEP-তে ফিরে আসে, যাতে আপনি পাসধারীদের সেগমেন্ট করতে পারেন।

সুবিধাটা সত্যিকারের। কিছুই মাইগ্রেট করতে হয় না। টিম নিজের টুল আর জার্নি রাখে, আর আপনি 1টি ইউজ কেস দিয়ে শুরু করতে পারেন, যেমন একটি লয়্যালটি কার্ড।

অসুবিধা জমে সময়ের সাথে। sync রাখার জন্য 2টি ডেটাবেস, 2টি সাবস্ক্রিপশন, 2টি সিকিউরিটি ও GDPR রিভিউ। যে সিনারিওতে পাস আপডেট আর মেসেজ একসাথে লাগে, যেমন “আপনার পয়েন্টের মেয়াদ শিগগির শেষ হবে”, সেটা বানাতে হয় 2টি টুল জুড়ে।

পথ B: নেটিভ ওয়ালেটসহ প্ল্যাটফর্মে যান

আপনি মেসেজিং সরিয়ে নেন এমন প্ল্যাটফর্মে, যা পুশ, ইন-অ্যাপ, ইমেইল ও SMS-এর একই প্রোফাইলে নেটিভভাবে ওয়ালেট পাস ইস্যু করে।

পাস ইস্যু হয় প্ল্যাটফর্মের ভেতরেই, User ID ধরে। সেগমেন্ট, জার্নি আর চ্যানেল সবাই পাসধারীকে 1 জন কাস্টমার হিসেবে দেখে। জার্নির 1টি ধাপ পাস ইস্যু করে, পরের ধাপ লিংক পাঠায়।

আপনি পান 1টি প্রোফাইল, 1টি জার্নি আর 1টি চুক্তি। পাস আপডেট আর মেসেজ আসে একই ট্রিগার থেকে, আর পাহারা দেওয়ার মতো কোনো sync লেয়ার থাকে না।

খরচটা মাইগ্রেশনেই: SDK বদল, ডেটা ইমপোর্ট, জার্নি আর টেমপ্লেট নতুন করে বানানো। এটা লাভজনক হয় যখন ওয়ালেট দীর্ঘমেয়াদি চ্যানেল, একবারের ক্যাম্পেইন নয়।

সিদ্ধান্ত নেওয়ার কাঠামো

4টি প্রশ্নে নিজেকে নম্বর দিন।

আপনার 2টি বা তার বেশি উত্তর যদি হয় “দীর্ঘমেয়াদি”, “অনেক”, “ডেভেলপার নেই” বা “কম প্রসেসর”, তাহলে পথ B গুরুত্ব দিয়ে ভাবুন। একটিও না হলে পথ A একদম ঠিক পছন্দ, আর 1 বছর পরে আবার ভাবতে পারেন।

পরিধির প্রশ্নটা বাংলাদেশ ও পশ্চিমবঙ্গের ক্যালেন্ডার ধরে ভাবুন। আপনার ওয়ালেট পরিকল্পনা যদি শুধু ঈদ বা পহেলা বৈশাখের 1টি কুপন হয়, সেটা একবারের ক্যাম্পেইন। কিন্তু যদি সারা বছর পাস চলে, এপ্রিলে পহেলা বৈশাখ, জুন-জুলাইয়ে ঈদ, সেপ্টেম্বর-অক্টোবরে দুর্গাপূজা আর নভেম্বরে ১১.১১ সেল, তাহলে ওয়ালেট আসলে একটি চ্যানেল, আর প্রতিটি সিজনে 2টি টুলে একই জার্নি বানানোর খরচ জমতে থাকে।

টিমের প্রশ্নে স্টার্টআপ আর ক্রমবর্ধমান কোম্পানির জন্য আরেকটি বিষয় আছে। এখানে বেশিরভাগ কাস্টমার Android ব্যবহার করেন, তাই আপনার প্রোগ্রামে Google Wallet পাসই বেশি হবে। পাস টুল বাছার আগে দেখে নিন Google পাস সেখানে নেটিভভাবে ইস্যু হয় কিনা, কারণ বিল আর কাজের বড় অংশ ওই দিকেই।

2টি টুলের খরচ হিসাব

প্রথম দিনে পথ A সস্তা মনে হয়, কারণ কিছুই সরাতে হয় না। 1 বছরের হিসাবে সেই অংশগুলো যোগ করুন, যা পাস ভেন্ডরের ইনভয়েসে কখনো দেখা যায় না: ইন্টিগ্রেশন বানানো, sync রক্ষণাবেক্ষণ, জার্নির দ্বিগুণ কাজ আর দ্বিতীয় ভেন্ডর রিভিউ।

পথ B-তে খরচ শুরুতেই বেশি: মাইগ্রেশনের কাজ, তারপর 1টি প্ল্যাটফর্ম ফি। দুটোকে 12 থেকে 24 মাস ধরে তুলনা করুন, 1 মাস ধরে নয়।

মাইগ্রেশন চেকলিস্ট

পথ B বাছলে পরিকল্পনা করুন কাস্টমারকে ঘিরে, টুলকে ঘিরে নয়।

• কী পাঠান তার তালিকা করুন। যে পুশ, ইমেইল, SMS ও ইন-অ্যাপ ক্যাম্পেইন, জার্নি আর সেগমেন্ট সরাতে হবে, সেগুলো লিখে ফেলুন।
• ডেটা ম্যাপ করুন। User ID, ট্যাগ, ইভেন্ট আর কনসেন্ট রেকর্ড। User ID-ই পাসকে কাস্টমারের সাথে বাঁধে।
• ওয়ালেট 1 বার সেটআপ করুন। একটি Apple Pass Type ID সার্টিফিকেট (Apple Developer অ্যাকাউন্ট, বছরে $99) আর একটি Google Issuer ID, যেখানে আপনার issuer-এ Pushwoosh service account invite করা থাকবে।
• SDK ইন্টিগ্রেট করুন। অ্যাপে পুরনো SDK বদলান আর ট্রাফিক সরানোর আগে পুশ টেস্ট করুন।
• আগে মূল জার্নিগুলো বানান। Welcome, abandoned cart, win-back, তারপর নতুন ওয়ালেট সিনারিও।
• পাস লঞ্চের পরিকল্পনা করুন। জার্নির ধাপ থেকে পাস ইস্যু করুন আর লিংক পাঠান ইমেইল, SMS বা পুশে।
• অল্প সময় দুটো একসাথে চালান। পুরনো প্ল্যাটফর্ম অল্প কিছুদিন রাখুন, তারপর বন্ধ করুন।

সরানোর সময়টায় নিজের backend থেকে পাস ইস্যু করতে API ব্যবহার করুন।

Pushwoosh দিয়ে আপনার স্ট্যাক সহজ করুন

Pushwoosh নেটিভ Apple ও Google Wallet পাস ইস্যু করে পুশ, ইন-অ্যাপ, ইমেইল, SMS ও WhatsApp-এর একই User ID, সেগমেন্ট আর জার্নিতে। এটা 1টি প্ল্যাটফর্ম, জার্মানি ও US-এ নিজস্ব ইনফ্রাস্ট্রাকচারে হোস্ট করা, GDPR সম্মত এবং SOC 2 Type 2 সার্টিফাইড। দেখুন ওয়ালেটের অপশনগুলোর মধ্যে Pushwoosh কোথায় মানায়।

ওয়ালেট যোগ করা মানে আরও 1টি টুল জুড়ে দেওয়া হওয়া উচিত নয়। এর মানে হওয়া উচিত 1টি কাস্টমার প্রোফাইল, যার উপর প্রতিটি চ্যানেল কাজ করতে পারে।

FAQ