বেশিরভাগ টিমই জানতে চায় কোন ক্যাম্পেইন আসলে টাকা আনছে। কিন্তু যেটা তাদের আটকে রাখে, সেটা হলো attribution — অর্থাৎ কোন মেসেজের কারণে কোন purchase হলো, সেটা বের করা। কারণ purchase-এর ডেটা আলাদা আলাদা সিস্টেমে থাকে, প্রত্যেকটার ফরম্যাট আলাদা। সেই ডেটাকে সেই মেসেজের সাথে মেলানো নিজেই একটা বড় কাজ হয়ে দাঁড়ায়। তাই টিমগুলো শেষমেশ opens আর clicks নিয়েই থাকে, কারণ এই সংখ্যাগুলো তো এমনিতেই dashboard-এ থাকে।
এর সমাধান হলো, revenue-র ডেটাকে এমন একটা ফরম্যাটে messaging প্ল্যাটফর্মে আনা, যেটা প্ল্যাটফর্ম সত্যিই ব্যবহার করতে পারে। Pushwoosh-এ এটা যেভাবে করা হয়, দেখে নেওয়া যাক।
Revenue-র ডেটা কেন আপনার messaging প্ল্যাটফর্মে পৌঁছায় না 💰
কারণটা হলো ফরম্যাট: revenue কখনোই 1 রকম ফরম্যাটে আসে না।
যেমন ধরুন, কেউ গেমের ভেতরে কয়েন কিনলে আপনার SDK একটা in-app purchase event পাঠায়। আপনার backend পাঠায় নিজের বানানো OrderPlaced event। আবার Stripe আর Shopify তাদের নিজেদের মতো webhook event পাঠায় সাবস্ক্রিপশন আর স্টোর অর্ডারের জন্য। প্রতিটার field-এর নাম আলাদা, গঠন আলাদা, এমনকি “amount” মানে কী, সেটাও আলাদা।
এই সব উৎস মিলিয়ে revenue-র হিসাব বের করতে হলে, প্রতিটা উৎসের জন্য আলাদা করে কোড লিখতে হয় এবং সেটা সবসময় সিঙ্ক রাখতে হয়। বেশিরভাগ টিম এই কাজটা করেই না, কারণ quarter শেষ হওয়ার আগে এটা priority হয়ই না। আর যখন প্রয়োজন পড়ে, তখন দেখা যায় ডেটাই নেই। তাই revenue tracking পিছিয়ে যেতে থাকে, আর টিম শুধু opens রিপোর্ট করতে থাকে, কারণ এই সাধারণ মেট্রিকগুলো আগে থেকেই কানেক্ট করা থাকে।
তবে এই সমস্যাটা দ্রুতই সমাধান করা যায়: শুধু revenue-কে 1টা consistent ফরম্যাটে নিয়ে আসতে হবে।
আপনার সব revenue-র জন্য 1টি event
Pushwoosh এই ফরম্যাটের সমস্যাটা সমাধান করে 1টা built-in event দিয়ে: PW_Conversion। মূল উৎস যেটাই হোক না কেন, revenue শেষমেশ 1টা normalized রেকর্ডে জমা হয়, যেখানে field-এর সেট সবসময় একই থাকে:
- value — লেনদেনের টাকার পরিমাণ
- currency — যেমন BDT, USD বা EUR
- transaction_id এবং product_id — না দিলেও চলবে এমন identifier
এটুকুই। সাবস্ক্রিপশন renewal, in-app purchase, Shopify order — সবকিছুই একই ধরনের event হয়ে যায়। Revenue একবার PW_Conversion হিসেবে এলে, এরপরের সবকিছু একই ডেটা পড়ে: RFM সেগমেন্টেশন, Customer Journey, dashboard, এবং ManyMoney AI।
ট্র্যাকিং শুরু করার 2টা উপায়
প্রতিটা application-এর জন্য আলাদাভাবে conversion event সেট করতে হয়, আর তার জন্য 2টা রাস্তা আছে। আপনার purchase data এখন যেভাবে আসছে, তার সাথে যেটা মিলে যায়, সেটা বেছে নিন।
- আগে থেকেই থাকা event ম্যাপ করুন — কোনো কোড লিখতে হবে না। যদি purchase data আগে থেকেই অন্য কোনো event-এর মাধ্যমে Pushwoosh-এ আসতে থাকে, তাহলে শুধু Pushwoosh-কে সেই event-এর দিকে ইশারা করে দিন। উৎস event বেছে নিন, তারপর এর field ম্যাপ করুন: কোন attribute-এ price আছে, কোনটায় currency আছে। এরপর সেই event trigger হওয়ার প্রতিবার Pushwoosh নিজে থেকেই একটা PW_Conversion রেকর্ড বানিয়ে নেবে, আপনার অ্যাপের একটা লাইনও না বদলে। একসাথে একাধিক উৎসও ম্যাপ করা যায় — যেমন নিজের বানানো purchase_completed event, সাথে Stripe বা Shopify-র webhook।
- নিজের কোড থেকে সরাসরি PW_Conversion পাঠান। যদি আপনি নিজে থেকে revenue পাঠাতে চান, তাহলে আপনার অ্যাপ বা backend-এ যেখানে purchase শেষ হয়, সেখানে একটা postEvent কল যোগ করুন। এই রাস্তায় আপনার dev টিমের সাহায্য লাগবে, তবে এটা একটা ছোট, একবারই করার মতো ইন্টিগ্রেশন।
পুরো সেটআপ পাবেন Conversion events ডকুমেন্টেশনে।
কোন event revenue বানানো যায় (আর কোনটা যায় না)
Mapping-এর রাস্তাটা যেকোনো event-এর সাথেই কাজ করে, যদি তাতে টাকার পরিমাণ থাকে:
- Custom event — আপনার নিজের বানানো purchase_completed, subscription_renewed, order_placed।
- Default event — যদি সেটা কোনো পেইড অ্যাকশন বোঝায়।
- Inbound-webhook event — Stripe, Shopify, এবং আপনার কানেক্ট করা অন্যান্য পেমেন্ট উৎস।
যেটা ম্যাপ করা যায় না, সেটা হলো এমন event যাতে পড়ার মতো কোনো টাকার পরিমাণই নেই। App_open, screen_view, বা push_opened শুধু বলে ইউজার কী করেছে। টাকার পরিমাণ না থাকলে, কনভার্ট করার মতো কিছুই নেই।
Revenue এলে আপনি যা যা মাপতে পারবেন
আসল লাভ এখানেই। Revenue একবার normalize হয়ে গেলে, আগে যে 3টা কাজ আলাদা করে ডেভেলপমেন্ট লাগত, সেগুলো এখন এমনিতেই থাকে:
- খরচ অনুযায়ী সেগমেন্ট করুন। RFM সেগমেন্টেশন সরাসরি PW_Conversion পড়ে, তাই আপনার সবচেয়ে বেশি খরচ করা ইউজাররা এমনিতেই Champions সেগমেন্টে চলে আসে, লয়্যালটি অফার পাঠানোর জন্য একদম প্রস্তুত হয়ে।
- কোন journey আসলেই purchase আনছে, সেটা প্রমাণ করুন। যেকোনো Customer Journey-তে PW_Conversion-কে Conversion Goal হিসেবে সেট করুন। Journey চলে যাওয়ার পর, goal-এর পরিসংখ্যান দেখাবে কতজন ইউজার সত্যিই কিনেছে, শুধু কতজন খুলেছে তা না। “এই flow-টা আদৌ কাজে দিয়েছে কিনা”, এই প্রশ্নের উত্তর এখন canvas-এই পাওয়া যায়।
- Dashboard-এ revenue দেখান, অন্যান্য গুরুত্বপূর্ণ অ্যাপ মেট্রিকের পাশাপাশি, প্রতিটা purchase event-এর জন্য আলাদা কোড না লিখেই।
আপনার অ্যাপ এখানে খুঁজে নিন
একই সেটআপ মানিয়ে নেয় আপনার অ্যাপ আসলে কীভাবে টাকা আয় করে, তার সাথে। যে সারিটা আপনার অ্যাপের মতো লাগে, সেটা দেখুন:
| অ্যাপের ধরন | যে event ম্যাপ বা পাঠাতে হবে | শেষমেশ যা দেখবেন |
|---|---|---|
| E-commerce (Daraz-এর মতো) | order_placed ম্যাপ করুন + Shopify বা Stripe webhook | কোন cart-recovery flow সত্যিকারের অর্ডার আনছে; খরচ অনুযায়ী RFM দিয়ে বারবার কেনা কাস্টমার খুঁজে বের করা |
| Gaming | কোড থেকে iap_completed, battle_pass_bought পাঠান | লেভেল শেষে দেওয়া অফার আসলেই কনভার্ট করছে কিনা, শুধু খোলা হচ্ছে কিনা তা না; বেশি খরচ করা প্লেয়ারদের জন্য সেগমেন্ট |
| Subscription (মিডিয়া, স্ট্রিমিং) | subscription_renewed, plan_upgraded ম্যাপ করুন (Stripe, App Store) | Win-back journey সত্যিই আবার সাবস্ক্রিপশন আনছে কিনা; renewal কতদিন আগে হলো তার উপর RFM |
| FinTech (bKash/Nagad-এর মতো) | premium_subscribed, first_trade, বা payment webhook ম্যাপ করুন | কোন onboarding প্রম্পট সত্যিই টাকা জমা হওয়া অ্যাকাউন্টে নিয়ে যাচ্ছে; লেনদেনের পরিমাণ অনুযায়ী সেগমেন্ট |
| Food delivery | আপনার backend থেকে order_placed ম্যাপ করুন | কোন re-engagement push আবার অর্ডার করাচ্ছে; সবশেষ অর্ডারের সময় অনুযায়ী RFM |
| Travel / booking | booking_confirmed + seat_upgraded-এর মতো এক্সট্রা সার্ভিস ম্যাপ করুন | কোন price-drop flow বুকিংয়ে রূপ নিচ্ছে; ট্রিপের মূল্য অনুযায়ী সেগমেন্ট |
order_placed ম্যাপ করুন + Shopify বা Stripe webhookiap_completed, battle_pass_bought পাঠানsubscription_renewed, plan_upgraded ম্যাপ করুন (Stripe, App Store)premium_subscribed, first_trade, বা payment webhook ম্যাপ করুনorder_placed ম্যাপ করুনbooking_confirmed + seat_upgraded-এর মতো এক্সট্রা সার্ভিস ম্যাপ করুনমার্কেটাররা যেখানে কাজ করেন, সেখানেই revenue দেখান
Conversion event হলো Pushwoosh-এর একটা বড় লক্ষ্যের 1টা অংশ: revenue-কে সেখানেই দেখানো, যেখানে মার্কেটাররা এমনিতেই কাজ করেন, আলাদা করে রিপোর্ট খুঁজে বের করার বদলে।
আপনারা এমনিতেই ঠিক করেন কী পাঠাবেন, কাকে পাঠাবেন, আর কতবার পাঠাবেন। এখন সেই সিদ্ধান্তগুলো opens আর clicks-এর উপর নির্ভর করে, কারণ আমরা এখন পর্যন্ত সেটাই ফেরত দিতে পারি। PW_Conversion পাঠান, আর একই সিদ্ধান্তগুলো টাকার উপর ভিত্তি করে নেওয়া যাবে: কোন ক্যাম্পেইন রাখবেন, কোনটা বন্ধ করবেন, কোন সেগমেন্ট বেশি মেসেজ পাওয়ার যোগ্য — আর কোনটা শুধু আনসাবস্ক্রাইব বাড়াচ্ছে, বিনিময়ে কিছু না দিয়েই।
Revenue একবার আসা শুরু করলে, এর সাথে যোগ হয় আরও একটা সুবিধা:
Pushwoosh-এর AI মার্কেটিং কোপাইলট, ManyMoney AI, PW_Conversion-ও পড়ে — তাই আপনি সহজ ভাষায় জিজ্ঞেস করতে পারেন বিক্রি কেমন যাচ্ছে বা কোন ক্যাম্পেইন লাভ করছে, আর রিপোর্টের জন্য অপেক্ষা না করেই সরাসরি live ডেটা থেকে উত্তর পেতে পারেন। এটা নিজে থেকেও এই একই সিগন্যাল ব্যবহার করে, লাভজনক ক্যাম্পেইন বড় করে আর যেগুলো লাভ দিচ্ছে না সেগুলো থামিয়ে দেয়।
Pushwoosh-এ revenue tracking কাজে লাগান
যেটায় কম কাজ লাগবে, সেই রাস্তা দিয়ে শুরু করুন: এমন একটা event ম্যাপ করুন যেটা আপনি এমনিতেই পাঠান, অথবা আপনার dev টিমকে postEvent-এর উদাহরণ দিয়ে দিন। আপনার পরবর্তী journey-তে PW_Conversion-কে Conversion goal হিসেবে সেট করুন, আর দেখুন revenue কীভাবে opens আর clicks-এর পাশে দেখা যায়।
Conversion event একটা জিনিস বলতে পারবে না: সেই revenue আসলেই আপনার ক্যাম্পেইনের কারণে হয়েছে, নাকি ইউজাররা এমনিতেও কিনতেন। এটার জন্য আলাদা একটা measurement আছে, যাকে বলে Global control group — আপনার revenue tracking শুরু হয়ে গেলে এটাই স্বাভাবিক পরের ধাপ।
সম্পর্কিত আর্টিকেল
সব দেখুন