दोनों सेगमेंट बेहतर हुए, फिर भी कन्वर्ज़न गिरा: पेमेंट फ़नल का विश्लेषण

चेकआउट कन्वर्ज़न हर सेगमेंट में बेहतर हो सकता है, और फिर भी कुल प्रतिशत खराब दिख सकता है। रिट्राई जोड़कर अलग-अलग अटेम्प्ट की सफलता दर घटाई जा सकती है, जबकि उसी समय ज़्यादा ऑर्डर पूरे हो जाते हैं। रूटिंग और इंटरफ़ेस बदलने से पहले माप की इकाई, ग्राहकों का मिक्स और वह समय जाँचें जो आपने पेमेंट पूरे होने के लिए दिया था।

जब कुल प्रतिशत एक बेकसूर इंटीग्रेशन पर दोष डालता है

एक अलग, सीखने वाला उदाहरण लें। पहली अवधि में सेगमेंट A से 900 ऑर्डर आए और कन्वर्ज़न 90% रहा, सेगमेंट B से 100 ऑर्डर आए और कन्वर्ज़न 60% रहा। कुल 810 + 60 = 870 सफल ऑर्डर, यानी 1 000 में से 87%।

दूसरी अवधि में A सुधरकर 92% पर पहुँचा, लेकिन अब उसमें सिर्फ़ 200 ऑर्डर हैं। B सुधरकर 65% पर पहुँचा और उसमें 800 ऑर्डर हैं। सफल ऑर्डर 184 + 520 = 704 रहे, कुल कन्वर्ज़न 70,4%। दोनों सेगमेंट बढ़े, लेकिन ट्रैफ़िक मिक्स बदलने से कुल नतीजा 16,6 प्रतिशत अंक नीचे आ गया।

जाँच के लिए दोनों अवधियों की तुलना सेगमेंट के एक जैसे वेट पर करें। पुराने हिस्से 90% और 10% के साथ नया नतीजा 89,3% होता: 0,9 × 92% + 0,1 × 65%। यह विश्लेषण के लिए किया गया दोबारा हिसाब है, दूसरी अवधि का असली कन्वर्ज़न नहीं। दोनों आँकड़े लेबल के साथ दिखाएँ: असली कुल नतीजा बिज़नेस के लिए ज़रूरी है, और तुलनीय मिक्स से प्रोसेस में आए बदलाव को परखने में मदद मिलती है।

एक उदाहरण, चार नतीजे

मान लीजिए एक काल्पनिक स्टोर में 1 000 यूनिक ऑर्डर पेमेंट स्क्रीन तक पहुँचे। इनमें से 800 ऑर्डर के लिए ग्राहकों ने कम से कम एक अटेम्प्ट भेजा। दोहराए गए कदमों से कुल 940 अटेम्प्ट हुए, जिनमें से 680 सफल ऑथराइज़ेशन पर खत्म हुए और 680 अलग-अलग ऑर्डर से जुड़े थे। चुनी गई विंडो के अंत तक 660 ऑर्डर में capture का चरण पूरा हुआ: मर्चेंट ने पहले ऑथराइज़ की गई रकम की वसूली की पुष्टि कर दी।

• पेमेंट अटेम्प्ट तक पहुँचना: 800 / 1 000 = 80%।
• अटेम्प्ट करने वाले ऑर्डर में सफल ऑथराइज़ेशन: 680 / 800 = 85%।
• अलग-अलग अटेम्प्ट की सफलता दर: 680 / 940 ≈ 72,3%।
• पेमेंट स्क्रीन खोलने वाले ऑर्डर में पूरा capture: 660 / 1 000 = 66%।

ये संकेतक अलग-अलग सवालों के जवाब देते हैं। पहला इंटरफ़ेस और पेमेंट मेथड की उपलब्धता को समझने में मदद करता है। दूसरा अनुमत रिट्राई के बाद ऑर्डर का नतीजा दिखाता है। तीसरा अटेम्प्ट की प्रकृति बताता है, चौथा चुने गए कमर्शियल नतीजे को दर्शाता है। अगर पैसा अलग capture चरण के बिना कटता है या बैंक ट्रांसफ़र इस्तेमाल होता है, तो उस मेथड के लिए उपयुक्त पुष्ट नतीजा तय करें।

ऑर्डर, अटेम्प्ट और इवेंट को अलग रखें

डेटा मॉडल में ऑर्डर की स्थिर पहचान, अटेम्प्ट की अलग पहचान और इवेंट की पहचान होनी चाहिए। एक अटेम्प्ट से कई नोटिफ़िकेशन बन सकते हैं, और एक ऑर्डर में कई अटेम्प्ट हो सकते हैं। इन्हें मिलाने से ग्राहकों का असली व्यवहार बदले बिना अंश या हर बढ़ जाता है। P2P प्रोसेस में ऑर्डर की जगह कोई खास रिक्वेस्ट हो सकती है, लेकिन उसकी सीमाएँ पहले से तय करनी होंगी।

Stripe सलाह देता है कि उसी पेमेंट फ़्लो को दोबारा शुरू करते समय PaymentIntent को फिर से इस्तेमाल करें। ऐसा ऑब्जेक्ट असफल अटेम्प्ट को एक ही कार्ट या सेशन से जोड़ने में मदद करता है। यह बिज़नेस ऑब्जेक्ट को पेमेंट प्रोसेस से जोड़ने का एक उदाहरण है, सभी प्रोवाइडर के लिए एक सार्वभौमिक ढाँचा नहीं। स्रोत: Stripe, Payment Intents।

इवेंट का न्यूनतम नक्शा

पेमेंट स्क्रीन खुलना, मेथड चुनना, अटेम्प्ट भेजना, अतिरिक्त कार्रवाई की ज़रूरत, उस कार्रवाई का पूरा होना और पुष्ट नतीजा दर्ज करें। हर इवेंट के लिए होने और मिलने का समय, पहचान, रकम, करेंसी, मेथड और इंटीग्रेशन वर्ज़न सहेजें। एनालिटिक्स फ़ील्ड में कार्ड डिटेल या ज़रूरत से ज़्यादा निजी डेटा रखने की ज़रूरत नहीं है।

नतीजे के लिए इंटीग्रेशन में दिया गया सत्यापित सर्वर-साइड कन्फ़र्मेशन इस्तेमाल करें। यूज़र का सक्सेस पेज पर लौटना इंटरफ़ेस को आँकने में उपयोगी है, लेकिन अपने आप में पेमेंट का सबूत नहीं है। उलटे, ब्राउज़र बंद होना यह साबित नहीं करता कि ट्रांज़ैक्शन फ़ेल हुआ। ये दोनों स्थितियाँ एनालिटिक्स के टेस्ट सिनेरियो में शामिल होनी चाहिए।

Stripe चेतावनी देता है कि webhook इवेंट दोबारा डिलीवर हो सकते हैं और उनका क्रम गारंटीड नहीं है। हैंडलर को डुप्लिकेट का ध्यान रखना चाहिए और मिलने के क्रम से स्वतंत्र होकर स्थिति अपडेट करनी चाहिए। स्रोत: Stripe, Webhooks।

पूरे हो चुके कोहोर्ट की तुलना करें

ग्रुप बनाने का एक नियम चुनें, जैसे वे ऑर्डर जिन्होंने किसी दिन पहली बार पेमेंट खोला, और सबको एक जैसी ऑब्ज़र्वेशन विंडो दें। उसकी लंबाई खास मेथड और खरीद चक्र के हिसाब से तय करें। जब तक विंडो बंद न हो, अस्थायी नतीजा और पेंडिंग ट्रांज़ैक्शन का हिस्सा दिखाएँ। देर से कन्फ़र्म हुए पेमेंट को मूल कोहोर्ट अपडेट करना चाहिए, किसी भी रैंडम दिन में नया सफल अटेम्प्ट नहीं बनाना चाहिए।

सेगमेंट में बाँटने के लिए भी अनुशासन चाहिए। मिलते-जुलते मेथड, डिवाइस, करेंसी और ग्राहकों के प्रकार की तुलना करें। कुल प्रतिशत सिर्फ़ इसलिए गिर सकता है कि ज़्यादा मुश्किल सेगमेंट का हिस्सा बढ़ गया। नए इंटीग्रेशन वर्ज़न को दोष देने से पहले ट्रैफ़िक मिक्स में बदलाव और ऑब्ज़र्वेशन की पर्याप्तता जाँचें।

Adyen की Received payment details report में ऑथराइज़ और डिक्लाइन हुए पेमेंट, प्रोसेसिंग में शामिल पक्षों के इंटरैक्शन और जवाबों का डेटा होता है। यह रिपोर्ट फ़नल के सर्वर-साइड हिस्से के रिकंसिलिएशन में काम आती है, लेकिन उन विज़िटर के बारे में नहीं बताती जिन्होंने पेमेंट भेजा ही नहीं। स्रोत: Adyen, Received payment details report।

अधूरे ट्रांज़ैक्शन के लिए अलग जगह रखें

अस्थायी नतीजों को ज़बरदस्ती सफल और असफल में बाँटने की ज़रूरत नहीं है। पेंडिंग या अज्ञात नतीजे वाले ट्रांज़ैक्शन अलग रखें। अगर आज ऐसे ज़्यादा हैं, तो कन्वर्ज़न में गिरावट ग्राहकों के अंतिम नुकसान के बजाय कन्फ़र्मेशन में देरी को दिखा सकती है। फ़ैसले के लिए इंतज़ार की उम्र और एक जैसी ऑब्ज़र्वेशन विंडो के बाद के नतीजे चाहिए।

एक्सपेरिमेंट से पहले लिख लें कि ठीक-ठीक क्या बदल रहा है, तुलना में कौन शामिल है और किसे पूरा माना जाएगा। जाँचें कि रिट्राई के दौरान एक ऑर्डर एक ग्रुप से दूसरे में न कूदे। हर, ऑब्ज़र्वेशन विंडो और इंटरफ़ेस को एक साथ न बदलें: वरना असली बढ़त को भी समझाना मुश्किल होगा।

अंतिम विश्लेषण में अतिरिक्त पूरे हुए ऑर्डर की संख्या के साथ प्रोसेसिंग लागत, रिफ़ंड और डबल डेबिट की शिकायतें भी रखें। ये संकेतक पहले पेमेंट के बाद सामने आ सकते हैं, इसलिए शुरुआती सकारात्मक नतीजा तय की गई क्वालिटी जाँच तक अस्थायी रहता है। ज़रूरी सुधार को यह जाँच पार करनी चाहिए, सिर्फ़ लॉन्च वाले दिन अच्छा दिखना काफ़ी नहीं।