ज़्यादातर टीम्स यह जानना चाहती हैं कि कौन-सा कैंपेन असल में पैसे कमा रहा है। इसमें सबसे बड़ी रुकावट है attribution: purchase data अलग-अलग सिस्टम्स में, अलग-अलग फॉर्मैट में पड़ा रहता है, तो यह पता लगाना कि किस मैसेज ने वो purchase drive किया — यह खुद में एक अलग प्रोजेक्ट बन जाता है। इसलिए टीम्स वापस opens और clicks पर आ जाती हैं, क्योंकि वो नंबर्स पहले से ही dashboard में मौजूद होते हैं।
फिक्स है: रेवेन्यू को अपने messaging platform में उस शेप में लाना, जिसे वो actually इस्तेमाल कर सके। Pushwoosh में यह ऐसे होता है।
रेवेन्यू डेटा आपके messaging platform तक क्यों नहीं पहुंच पाता 💰
वजह है फॉर्मैट: रेवेन्यू कभी भी 1 शेप में नहीं आता।
जैसे, आपका SDK एक in-app purchase event फायर करता है जब कोई gems खरीदता है। आपका backend एक कस्टम OrderPlaced भेजता है। Stripe, Razorpay और Shopify अपने subscription और store orders के लिए अपने-अपने webhook events भेजते हैं। हर एक में अलग field names, अलग structure, और “amount” का अलग मतलब होता है।
इस सबका मिलाकर revenue पर report करने के लिए, किसी को हर source के लिए custom logic लिखना होगा और उसे sync में रखना होगा। ज़्यादातर टीम्स ऐसा नहीं करतीं क्योंकि quarter-end review तक यह priority ही नहीं बनता। और तब तक data होता ही नहीं। तो revenue tracking टलता रहता है, और team opens ही report करती रहती है क्योंकि वो standard metrics पहले से ही wired-up हैं।
और यह fix होने में देर नहीं लगती: पूरी बात इतनी है कि revenue को 1 consistent format में लाना है।
आपके पूरे रेवेन्यू के लिए 1 event
Pushwoosh इस format problem को 1 built-in event से solve करता है: PW_Conversion. ओरिजिनल source चाहे जो भी हो, revenue 1 normalized record में एक fixed set of fields के साथ आता है:
- value — transaction amount
- currency — जैसे INR, USD या EUR
- transaction_id और product_id — optional identifiers
बस इतना ही। एक subscription renewal, एक in-app purchase, एक Shopify order — यह सब same तरह के event बन जाते हैं। जैसे ही revenue PW_Conversion के रूप में आता है, downstream की हर चीज़ same data पढ़ती है: RFM segmentation, Customer Journeys, dashboards, और ManyMoney AI।
Tracking शुरू करने के 2 तरीके
आप conversion events को per application सेटअप करते हैं, और इसके लिए 2 रास्ते हैं। वो चुनें जो आपके existing purchase data flow से मैच करता हो।
- किसी existing event को map करें — कोई कोड नहीं चाहिए। अगर purchase data पहले से ही किसी दूसरे event के ज़रिए Pushwoosh में आ रहा है, तो बस Pushwoosh को उस event पर point कर दें। Source event चुनें और उसके fields map करें: कौन-सा attribute price रखता है, कौन-सा currency। इसके बाद Pushwoosh हर बार वो event fire होने पर अपने-आप एक PW_Conversion record generate कर देगा, आपकी app की एक भी लाइन बदले बिना। आप एक साथ कई sources map कर सकते हैं — जैसे एक custom purchase_completed event, साथ में Stripe या Razorpay का webhook भी।
- अपने code से PW_Conversion सीधे भेजें। अगर आप revenue को explicitly भेजना चाहते हैं, तो जहां भी आपकी app या backend में कोई purchase complete होता है, वहां एक postEvent call add करें। इस रास्ते के लिए आपकी dev team की मदद चाहिए होगी, लेकिन यह एक छोटी, one-time integration है।
कौन-से events को आप revenue बना सकते हैं (और कौन-से नहीं)
Mapping वाला रास्ता किसी भी ऐसे event के साथ काम करता है जो monetary amount carry करता हो:
- Custom events — आपके अपने purchase_completed, subscription_renewed, order_placed।
- Default events — जहां वो एक paid action represent करते हों।
- Inbound-webhook events — Stripe, Razorpay, Shopify, और आपके connect किए गए बाकी payment sources।
आप जो map नहीं कर सकते वो है ऐसा event जिसमें पढ़ने के लिए कोई amount ही न हो। App_open, screen_view, या push_opened सिर्फ यह track करते हैं कि user ने क्या किया। बिना किसी amount के, convert करने के लिए कुछ है ही नहीं।
एक बार revenue आ जाए तो आप क्या measure कर सकते हैं
यही असली payoff है। Revenue normalized होते ही, 3 चीज़ें जो पहले custom work मांगती थीं, अब built-in बन जाती हैं:
- Spend के हिसाब से segment करें। RFM segmentation सीधे PW_Conversion पढ़ता है, तो आपके सबसे बड़े spenders अपने-आप Champions segment में आ जाते हैं, loyalty offer के लिए target करने के लिए बिल्कुल तैयार।
- यह prove करें कि कौन-सी journeys purchases drive करती हैं। किसी भी Customer Journey में PW_Conversion को Conversion Goal की तरह set करें। journey run होने के बाद, goal stats दिखाते हैं कि कितने users ने actually खरीदा, सिर्फ कितनों ने खोला यह नहीं। “क्या यह flow वाकई काम आया?” — इस सवाल का जवाब अब canvas पर ही मिल जाता है।
- Dashboards में revenue report करें, बाकी उन mobile app metrics के साथ जो really matter करते हैं, बिना हर purchase event के लिए custom logic बनाए।
अपनी app यहां ढूंढें
यही setup adapt हो जाता है इस हिसाब से कि आपकी app actually पैसे कैसे कमाती है। वो row ढूंढें जो आपकी app जैसी लगे:
| App type | Events जो आप map या send करेंगे | आप आखिर में क्या देखेंगे |
|---|---|---|
| E-commerce (Flipkart/Amazon sale season जैसा) | order_placed map करें + Shopify या Stripe webhook | कौन-से cart-recovery flows असली orders दिलाते हैं; spend के हिसाब से RFM ताकि repeat buyers मिलें |
| Gaming | code से iap_completed, battle_pass_bought भेजें | क्या post-level offer convert होता है, सिर्फ open नहीं होता; high-value players के लिए spend-based segments |
| Subscription (media, streaming) | subscription_renewed, plan_upgraded map करें (Stripe, App Store) | क्या win-back journeys असली re-subscriptions दिलाती हैं; renewal recency से RFM |
| FinTech (UPI/PhonePe/Paytm जैसा) | premium_subscribed, first_trade, या payment webhook map करें | कौन-से onboarding nudges funded accounts तक ले जाते हैं; transaction volume से segments |
| Food delivery | आपके backend से order_placed map करें | कौन-से re-engagement pushes reorders drive करते हैं; last order के हिसाब से RFM |
| Travel / booking | booking_confirmed + seat_upgraded जैसी ancillaries map करें | कौन-से price-drop flows bookings में convert होते हैं; trip value से segments |
order_placed map करें + Shopify या Stripe webhookiap_completed, battle_pass_bought भेजेंsubscription_renewed, plan_upgraded map करें (Stripe, App Store)premium_subscribed, first_trade, या payment webhook map करेंorder_placed map करेंbooking_confirmed + seat_upgraded जैसी ancillaries map करेंRevenue वहीं दिखाएं जहां marketers पहले से काम करते हैं
Conversion events, Pushwoosh की एक बड़ी direction का 1 हिस्सा हैं: revenue को वहीं visible बनाना जहां marketers already काम करते हैं, ना कि किसी report में जिसे उन्हें अलग से जाकर fetch करना पड़े।
आप already decide करते हैं कि क्या भेजना है, किसे भेजना है, और कितनी बार। अभी वो calls opens और clicks पर चलते हैं, क्योंकि हम आपको सिर्फ यही वापस दे पाते हैं। PW_Conversion भेजिए, और वही decisions अब money पर होंगे: कौन-सा campaign रखना है, कौन-सा बंद करना है, कौन-से segments ज़्यादा sends deserve करते हैं — और कौन-से सिर्फ unsubscribes दे रहे हैं, बिना किसी फायदे के।
एक बार revenue flow होने लगे, तो एक compounding payoff भी मिलता है:
Pushwoosh में revenue tracking को काम पर लगाएं
जो रास्ता कम काम मांगे, वहीं से शुरू करें: कोई event map करें जो आप already भेज रहे हैं, या अपनी dev team को postEvent sample दे दें। अपनी अगली journey में PW_Conversion को Conversion goal की तरह set करें, और देखिए कैसे revenue, opens और clicks के बगल में दिखने लगता है।
