20 नव॰ 2025·8 मिनट
पार्टनर राजस्व एट्रिब्यूशन के लिए वेब ऐप कैसे बनाएं
पार्टनर क्लिक, कन्वर्ज़न और राजस्व ट्रैक करने वाला वेब ऐप डिजाइन और बनाना सीखें। डेटा मॉडल, ट्रैकिंग, रिपोर्टिंग, पेआउट और प्राइवेसी को शामिल किया गया है।
पार्टनर क्लिक, कन्वर्ज़न और राजस्व ट्रैक करने वाला वेब ऐप डिजाइन और बनाना सीखें। डेटा मॉडल, ट्रैकिंग, रिपोर्टिंग, पेआउट और प्राइवेसी को शामिल किया गया है।
पार्टनर राजस्व एट्रिब्यूशन वह सिस्टम है जो एक सरल सवाल का जवाब देता है: किस पार्टनर को किसी राजस्व इवेंट का क्रेडिट (और कितना) मिलना चाहिए? वेब ऐप में इसका मतलब यह है कि आप सिर्फ क्लिक गिन नहीं रहे—आप किसी पार्टनर के रेफ़रल को बाद की किसी कन्वर्ज़न से जोड़ रहे हैं, उसे एक स्पष्ट राजस्व संख्या में बदल रहे हैं, और उसे ऑडिट करने योग्य बना रहे हैं।
शुरू में एक वाक्य की परिभाषा लिखें जिसमें शामिल हो (1) क्या एट्रिब्यूट होता है, (2) किसे, और (3) किन नियमों के तहत। उदाहरण के लिए:
यह परिभाषा आपके आवश्यकताओं, डेटा मॉडल और बाद में होंगे विवादों के लिए एंकर बन जाती है।
“पार्टनर” अक्सर कई समूहों को शामिल करता है जिनकी अपेक्षाएँ और वर्कफ़्लो अलग-अलग होते हैं:
बहुत जल्दी सभी को एक ही वर्कफ़्लो में जबरदस्ती मत डालें। आप अभी भी एक यूनिफ़ायड सिस्टम (partners, programs, contracts) इस्तेमाल कर सकते हैं जबकि कई रेफ़रल मेथड्स (लिंक, कोड, मैन्युअल डील्स) को सपोर्ट करते हैं।
एक व्यावहारिक पार्टनर राजस्व एट्रिब्यूशन वेब ऐप को भरोसेमंद तरीके से चार परिणाम देने चाहिए:
इन में से कोई भी कमजोर होगा तो पार्टनर्स नंबरों पर भरोसा नहीं करेंगे—भले ही गणित सही हो।
एक कार्यक करने योग्य बिल्ड गाइड के लिए लक्ष्य ये नहीं है कि एट्रिब्यूशन फिलॉसफी पर बहस हो—बल्कि एक काम करने वाला सिस्टम शिप करना है। एक वास्तविकवादी पहला वर्जन होना चाहिए:
आप उन्नत फीचर्स (मल्टी-टच एट्रिब्यूशन, क्रॉस-डिवाइस स्टिचिंग, जटिल फ्रॉड स्कोरिंग) बाद में जोड़ सकते हैं जब बेसिक्स भरोसेमंद और टेस्टेबल हों।
किसी एट्रिब्यूशन मॉडल या डेटाबेस डिजाइन चुनने से पहले यह स्पष्ट कर लें कि ऐप को बिज़नेस के लिए क्या साबित करना है। पार्टनर राजस्व एट्रिब्यूशन अंततः उन उत्तरों का सेट है जिनपर लोग पैसे देने के लिए भरोसा करते हैं।
ज़्यादातर टीमें शुरुआत में “पार्टनर्स” के लिए बनाती हैं और बाद में पाती हैं कि फ़ाइनेंस या सपोर्ट कुछ भी वेरिफ़ाई नहीं कर पा रहे। अपने प्राथमिक उपयोगकर्ताओं और उनके निर्णयों की सूची बनाएं:
इनको सामान्य भाषा में लिखें ताकि आपका UI और रिपोर्ट्स इन्हें सपोर्ट करें:
कम से कम, योजना बनाएं: click, lead, trial start, purchase, renewal, और refund/chargeback। तय करें कौन-से “commissionable” हैं और कौन-से समर्थन साक्ष्य के रूप में हैं।
एक स्पष्ट नियम सेट के साथ शुरू करें—आम तौर पर last-touch को एक कॉन्फ़िगर करने योग्य विंडो में प्राथमिक रखें—और मल्टी-टच तब जोड़ें जब रिपोर्टिंग ज़रूरतें और साफ़ डेटा हो। पहले वर्जन को समझाने और ऑडिट करने में आसान रखें।
कोड लिखने से पहले तय करें कि “किसे क्रेडिट मिलता है” और वह क्रेडिट कब समाप्त होता है। यदि आप upfront नियम नहीं रखेंगे तो हर payout पर एजेड केसों पर बहस होगी (और पार्टनर शिकायतें)।
Last click कन्वर्ज़न से पहले सबसे हालिया पार्टनर क्लिक को 100% क्रेडिट देता है। यह सरल और व्यापक रूप से समझा जाता है, पर देर के कूपन ट्रैफ़िक को ज़्यादा रिवॉर्ड कर सकता है।
First click ग्राहक को पहली बार जो पार्टनर लाया उसे 100% क्रेडिट देता है। यह डिस्कवरी पार्टनर्स को फ़ेवर करता है, पर उन पार्टनर्स को कम रिवॉर्ड कर सकता है जो डील क्लोज करने में मदद करते हैं।
Linear विंडो में सभी योग्य पार्टनर टचेस के बीच क्रेडिट समान रूप से बाँट देता है। यह “न्यायसंगत” लग सकता है, पर समझाने में मुश्किल और प्रोत्साहन को dilute कर सकता है।
Time-decay कन्वर्ज़न के करीब के टचेस को अधिक क्रेडिट देता है जबकि पहले के प्रभाव को भी मानता है। यह समझौता है, पर ज़्यादा गणित और स्पष्ट रिपोर्टिंग मांगता है।
अधिकांश कन्वर्ज़न्स के लिए एक डिफ़ॉल्ट मॉडल चुनें (कई ऐप्स last click से शुरू करते हैं क्योंकि यह समझाने और reconcile करने में आसान है)। फिर स्पष्ट रूप से अपवाद दस्तावेज़ करें ताकि सपोर्ट और फ़ाइनेंस उन्हें सुसंगत रूप से लागू कर सकें:
7 / 30 / 90 दिनों जैसी एक या अधिक विंडो सेट करें। एक व्यावहारिक दृष्टिकोण एक स्टैंडर्ड विंडो (उदा., 30 दिन) और जरूरत होने पर कूपन पार्टनर्स के लिए छोटी विंडो रखना है।
री-एंगेजमेंट नियम भी परिभाषित करें: यदि ग्राहक विंडो के भीतर किसी अन्य पार्टनर लिंक पर क्लिक करता है, क्या आप तुरंत क्रेडिट स्विच करेंगे (last click), क्रेडिट स्प्लिट करेंगे, या मूल पार्टनर को तब तक रखें जब तक नया क्लिक “close window” (उदा., 24 घंटे) के भीतर न हो?
तय करें आप क्या एट्रिब्यूट करते हैं: प्रांरभिक खरीद केवल, या समय के साथ नेट राजस्व।
इन नियमों को एक छोटे “Attribution Policy” डॉक्यूमेंट में लिखें और अपने पार्टनर पोर्टल में लिंक करें ताकि सिस्टम व्यवहार पार्टनर अपेक्षाओं से मेल खाए।
एक साफ़ डेटा मॉडल के साथ ही आप कह सकते हैं “हमें लगता है कि इस पार्टनर ने सेल की” नहीं—बल्कि आप साबित कर सकते हैं, reconcile कर सकते हैं, और सही भुगतान कर सकते हैं। छोटे सेट की मुख्य एंटिटीज़ से शुरू करें और immutable IDs के माध्यम से रिश्तों को स्पष्ट रखें।
partner_id, स्थिति, payout शर्तें, डिफ़ॉल्ट मुद्रा।campaign_id, start/end dates।link_id, जो partner_id और वैकल्पिक रूप से campaign_id से संबंधित है।click_id, जो link_id और partner_id को रेफ़रेंस करता है।visitor_id (अक्सर फर्स्ट-पार्टी कुकी ID से निकला)।conversion_id, जो click_id (यदि उपलब्ध हो) और visitor_id को रेफ़रेंस करता है।order_id, जो customer_id को रेफ़रेंस करता है और conversion_id से लिंक होता है।payout_id, जो partner_id को रेफ़रेंस करता है और योग्य ऑर्डर्स को एग्रीगेट करता है।आपका गोल्डन पाथ है:
partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_id
customer_id को order_id के साथ रखें ताकि रिपीट खरीदें आपकी नीतियों (उदा., “पहली खरीद केवल” बनाम “लाइफ़टाइम”) के अनुसार फॉलो कर सकें। अपने आंतरिक IDs और बाह्य IDs (उदा., shopify_order_id) दोनों को रेकॉन्सिलिएशन के लिए स्टोर करें।
ऑर्डर्स बदलते हैं। इसे स्पष्ट रूप से मॉडल करें:
gross_amount, tax_amount, shipping_amount, fee_amount, discount_amount.currency_code के साथ एक fx_rate_to_payout_currency जोड़ें (और उस रेट का timestamp/source)।order_id से जुड़े adjustment rows (उदा., order_adjustment_id, type = partial_refund) के रूप में दर्शाएँ। इससे ऑडिट योग्य इतिहास बना रहता है और टोटल्स को फिर से लिखने से बचता है।हर जगह ऑडिट फ़ील्ड जोड़ें: created_at, updated_at, ingested_at, source (web, server-to-server, import), और immutable identifiers।
फ्रॉड विश्लेषण के लिए बिना कच्चे पर्सनल डेटा स्टोर किए, hashed फ़ील्ड्स जैसे ip_hash और user_agent_hash स्टोर करें। अंत में, एक हल्का change log रखें (entity, entity_id, old/new values, actor) ताकि पेआउट फैसलों की व्याख्या बाद में की जा सके।
क्लिक ट्रैकिंग पार्टनर राजस्व एट्रिब्यूशन की नींव है: हर पार्टनर लिंक को एक टिकाऊ “click record” बनाना चाहिए जिसे आप बाद में कन्वर्ज़न से जोड़ सकें।
एक सिंगल कैनोनिकल लिंक फॉर्मेट का उपयोग करें जिसे पार्टनर कहीं भी कॉपी/पेस्ट कर सकें। अधिकांश सिस्टम में, पार्टनर-फेसिंग लिंक में click_id नहीं होना चाहिए—आपका सर्वर वह जनरेट करता है।
एक साफ़ पैटर्न है:
/r/{partner_id}?campaign_id=...&utm_source=...&utm_medium=partner&utm_campaign=...
प्रायोगिक पैरामीटर मार्गदर्शन:
सभी पार्टनर ट्रैफ़िक को एक redirect endpoint (/r/{partner_id} जैसे) के माध्यम से रूट करें:
यह क्लिक क्रिएशन को सुसंगत बनाता है, पार्टनर्स को click IDs स्पूफ करने से रोकता है, और नियम लागू करने को केंद्रीकृत करता है।
अधिकांश टीमें कुकी को प्राथमिक रूप में, localStorage को fallback के रूप में, और सर्वर-साइड सेशन्स को केवल अल्पकालिक फ्लो के लिए इस्तेमाल करती हैं।
मोबाइल वेब के लिए, कुकीज़ कम भरोसेमंद हो सकती हैं, इसलिए redirect endpoint का उपयोग करें और click_id को कुकी + localStorage दोनों में स्टोर करें।
ऐप-टू-वेब के लिए, सपोर्ट करें:
click_id के लिए एक्सचेंज किया जा सके।अपने पार्टनर पोर्टल में सटीक लिंक नियम दस्तावेज करें (देखें /blog/partner-links) ताकि पार्टनर पैरामीटर्स के साथ “क्रिएटिव” न हों।
कन्वर्ज़न ट्रैकिंग वह जगह है जहाँ एट्रिब्यूशन सिस्टम भरोसा कमाते हैं—या चुपचाप खो देते हैं। आपका लक्ष्य है एक सिंगल, कैनोनिकल “कन्वर्ज़न” इवेंट प्रति वास्तविक खरीद (या साइनअप) रिकॉर्ड करना, इतना संदर्भ के साथ कि इसे पार्टनर क्लिक से जोड़ा जा सके।
अधिकांश प्रोडक्ट्स कन्वर्ज़न्स को कई जगहों से देख सकते हैं:
सिफारिश: अपने बैकएंड ऑर्डर सर्विस को कैनोनिकल कन्वर्ज़न रिकॉर्डर मानें, और वैकल्पिक रूप से पेमेंट वेबहुक्स को कन्फ़र्मेशन/अपडेट संकेत के रूप में उपयोग करें (उदा., ऑर्डर को pending से paid पर ले जाना)। क्लाइंट-साइड इवेंट्स को डिबग या फ़नल एनालिटिक्स के लिए रखें, payout-ग्रेड एट्रिब्यूशन के लिए नहीं।
बाद में राजस्व को एट्रिब्यूट करने के लिए, कन्वर्ज़न इवेंट को एक स्थिर identifier और क्लिक से लिंक करने का तरीका चाहिए।
सामान्य विधि:
click_id को संलग्न करे (उदा., सेशन स्टेट से, कस्टमर रिकॉर्ड से, या क्लाइंट द्वारा भेजे गए साइन किए गए टोकन से)।आपका प्राथमिक जॉइन होना चाहिए conversion.click_id → click.id। यदि click_id गायब है, तो स्पष्ट fallback नियम परिभाषित करें, जैसे:
इन fallbacks को admin टूलिंग में दिखाएँ ताकि सपोर्ट बिना अनुमान के परिणाम समझा सके।
वेबहुक्स और क्लाइंट कॉल्स रीट्राइ कर सकते हैं। आपको एक ही कन्वर्ज़न कई बार प्राप्त करने पर डबल-काउंटिंग से बचना चाहिए।
idempotency keys लागू करें, जैसे:
order_id (सबसे अच्छा अगर ग्लोबली यूनिक हो)payment_provider_charge_idयह key कन्वर्ज़न रिकॉर्ड पर स्टोर करें और एक यूनिक कॉन्स्ट्रेंट लागू करें। रीट्राइ पर, सफलता लौटाएँ और दूसरा कन्वर्ज़न न बनाएं। यह सबसे आम “फ़ैंटम राजस्व” payout बग्स को रोकता है।
यह वह बिंदु है जहाँ ट्रैकिंग पैसे में बदलती है। आपका ऐप ट्रैक किए गए इवेंट से उस राशि तक एक स्पष्ट, ऑडिटेबल पथ चाहिए जो आप दे सकें—और फ़ाइनेंस जो मापता है उसके साथ aligned रहना चाहिए।
एक व्यावहारिक लाइफ़साइकल ऐसा दिखता है:
प्रत्येक स्टेट बदलने के लिए टाइमस्टैम्प रखें ताकि आप बता सकें कब और क्यों कोई कन्वर्ज़न payable बन गया।
क्या “राजस्व” आपके सिस्टम में क्या मतलब रखता है, स्पष्ट रूप से स्टोर करें:
बिना सख्त पॉलिसी हार्डकोड किए आप सामान्य संरचनाएँ सपोर्ट कर सकते हैं:
फ़ाइनेंस टीम्स को डेटा चाहिए जिसे वे reconcile कर सकें:
आपका पार्टनर प्रोग्राम भरोसे पर जीवित रहता है या मर जाता है। आपका पोर्टल वह जगह है जहाँ पार्टनर्स यह वेरिफ़ाई करते हैं कि क्लिक्स कन्वर्ज़न्स में बदल गए और कन्वर्ज़न्स पैसे में। आपका एडमिन डैशबोर्ड वह जगह है जहाँ आपकी टीम प्रोग्राम को साफ़, उत्तरदायी और निष्पक्ष रखती है।
एक छोटा सेट स्क्रीन से शुरू करें जो हर दिन पार्टनर्स के प्रश्नों का उत्तर देता है:
कन्वर्ज़न लिस्ट के लिए उन कॉलम्स को शामिल करें जो सपोर्ट टिकट कम करते हैं: कन्वर्ज़न टाइम, ऑर्डर ID (या मास्क्ड ID), एट्रिब्यूटेड राशि, कमीशन दर, स्टेटस (pending/approved/rejected/paid), और reject होने पर एक छोटा “reason” फ़ील्ड।
पार्टनर्स और एडमिन दोनों को बिना स्प्रैडशीट के परिणाम काटने की त्वरित तरीके चाहिए। प्राथमिकता दें:
यदि आप कई प्रॉडक्ट्स या प्लान ट्रैक करते हैं, तो एक प्रॉडक्ट फ़िल्टर जोड़ें—पर सिर्फ़ तब जब बेसिक्स स्टेबल हों।
एडमिन टूलिंग गति और जवाबदेही पर केंद्रित होनी चाहिए:
मैनुअल कंट्रोल सीमित रखें: आप चाहते हैं कि एडमिन अपवादों को सही करें, इतिहास को casually rewrite न करें।
डे-वन से RBAC लागू करें:
API स्तर पर permission checks लागू करें (सिर्फ UI पर नहीं), और पेआउट एक्सपोर्ट जैसे संवेदनशील व्यूज़ के एक्सेस को लॉग करें।
पार्टनर राजस्व एट्रिब्यूशन ऐप सामान्यतः “write-heavy” होता है: बहुत सारे क्लिक, बहुत सारे कन्वर्ज़न इवेंट्स, और समय-समय पर पढ़ने वाले रिपोर्ट। पहले हाई-वॉल्यूम ingestion के लिए डिजाइन करें, फिर aggregation के साथ रिपोर्टिंग को तेज़ बनाएं।
एक काम करने लायक बेसलाइन है Postgres + एक API + मॉडर्न फ्रंटेंड:
ट्रैकिंग एंडपॉइंट्स को stateless रखें ताकि आप उन्हें लोड बैलेंसर के पीछे हॉरिज़ॉन्टली स्केल कर सकें।
यदि आप स्पेक से वर्किंग इंटरनल टूलिंग तक जल्दी जाना चाहते हैं, तो Koder.ai मदद कर सकता है प्रोटोटाइप बनाने में—यह वर्कफ़्लो (tracking → attribution → payouts) को outline करने, React frontend और Go + PostgreSQL backend generate करने में सहायक हो सकता है, और जब आप प्रोडक्शन के लिए तैयार हों तो सोर्स कोड export करने की क्षमता देता है।
Request/response साइकिल में महंगा काम न करें। क्यू (SQS/RabbitMQ/Redis queues) और वर्कर्स का प्रयोग करें:
वर्कर्स idempotent होने चाहिए: अगर कोई जॉब दो बार चले तो परिणाम सही रहें।
क्लिक टेबल्स तेज़ी से बढ़ते हैं। शुरुआत में रिटेंशन की योजना बनाएं:
Postgres में, क्लिक्स के लिए time-based partitioning (उदा., मासिक पार्टिशन) और (occurred_at, partner_id) जैसे इंडेक्स पर विचार करें। पार्टिशनिंग vacuum/index मेंटेनेंस को बेहतर बनाती है और पुरानी पार्टिशन ड्रॉप करके रिटेंशन आसान करती है।
ट्रैकिंग फेल्योर अक्सर मूक रहते हैं जब तक आप उन्हें नहीं मापते। जोड़ें:
कंसिस्टेंट correlation ID (उदा., click_id/conversion_id) के साथ लॉग करें ताकि सपोर्ट किसी पार्टनर के दावा को end-to-end ट्रेस कर सके।
फ्रॉड नियंत्रण सिर्फ बुरे अभिनेताओं को पकड़ने के लिए नहीं—वे ईमानदार पार्टनर्स को शोर-भरे डेटा के कारण कम भुगतान होने से भी बचाते हैं। एक अच्छा दृष्टिकोण स्वचालित सुरक्षात्मक उपाय (तेज़, सुसंगत) और मानव समीक्षा (लचीला, संदर्भ-आधारित) का संयोजन है।
Self-referrals तब होते हैं जब पार्टनर्स अपने ही खरीद/साइनअप पर कमीशन कमाने की कोशिश करते हैं (आमतौर पर भुगतान फ़िंगरप्रिंट्स, ईमेल, या डिवाइस संकेतों से पता चलता है)।
Cookie stuffing और click spam यूज़र्स को बिना असली इरादे के “क्लेम” करने की कोशिश करते हैं—उदा., invisible iframes, ज़बरन redirects, या near-zero engagement के साथ उच्च क्लिक वॉल्यूम।
Fake leads वे कम-गुणवत्ता फॉर्म सबमिशन हैं जो CPA पेआउट ट्रिगर करने का उद्देश्य रखते हैं। कूपन लीक वो है जब निजी कोड सार्वजनिक हो जाता है और attribution असली स्रोत से हटकर फैल जाता है।
क्लिक्स और कन्वर्ज़न प्रति पार्टनर, प्रति IP रेंज, और प्रति यूज़र/सेशन पर rate limits से शुरू करें। इसे बॉट डिटेक्शन संकेतों के साथ जोड़ें: user-agent अनोमलीज़, missing JavaScript execution संकेत, संदिग्ध समय-समिति, डाटा-सेन्टर IPs, और बार-बार डिवाइस फ़िंगरप्रिंट।
अनॉमली अलर्ट जोड़ें। उन्नत ML की ज़रूरत नहीं है: साधारण थ्रेशोल्ड्स जैसे “कन्वर्ज़न रेट 5× वीक-ओवर-वीक spike” या “अन्य metadata के साथ कई समान कन्वर्ज़न्स” अधिकांश मुद्दों को पकड़ लेते हैं। अलर्ट्स को एडमिन डैशबोर्ड के ड्रिल-डाउन व्यू (उदा., /admin/partners/:id/attribution) से लिंक करें।
डेटा गुणवत्ता के लिए, ingestion पर इनपुट वैलिडेट करें। जहाँ लागू हो click IDs या signed partner tokens की मांग करें, malformed UTMs को रिजेक्ट करें, और देश/मुद्रा फ़ील्ड्स को सामान्यीकृत करें। कई जांचें इसलिए अटक जाती हैं क्योंकि लॉग्स अपूर्ण या जॉइंस ambiguous होते हैं।
ऑपरेटर्स को एक स्पष्ट क्यू दें: flags (कारण + गंभीरता), नोट्स, और संबंधित क्लिक और कन्वर्ज़न्स की टाइमलाइन।
संदिग्ध इवेंट्स को तुरंत पेआउट में न भेजकर conversion holds (“pending”) समर्थन करें। पार्टनर चेतावनियाँ और एस्केलेशन (अस्थायी पेआउट देरी, ट्रैफ़िक प्रतिबंध, या प्रोग्राम से हटाना) लागू करें, और कार्रवाइयों को टेम्पलेट्स के माध्यम से सुसंगत बनाएं।
एक अपरिवर्तनीय ऑडिट ट्रेल रखें:
यह पार्टनर विवादों, फ़ाइनेंस रेकॉन्सिलिएशन, और आंतरिक जवाबदेही के लिए आवश्यक है—विशेषकर जब कई लोग नियम और पेआउट बदल सकें।
पार्टनर राजस्व एट्रिब्यूशन ट्रैकिंग, पहचान, और भुगतान को छूता है—ये तीन क्षेत्र हैं जहाँ छोटी गलतियाँ बड़े जोखिम बना सकती हैं। लक्ष्य यह है कि रेफ़रल मापें और पेआउट कैलकुलेट करें, लेकिन जितना संभव हो उतना कम पर्सनल डेटा इकट्ठा करें और जो स्टोर करें उसे सुरक्षित रखें।
एक न्यूनतम डेटासेट से शुरू करें जो एट्रिब्यूट और रेकॉन्सिल करने के लिए आवश्यक हो:
partner_id, campaign_id, और जनरेटेड click_id.click_time और conversion_time.order_id (या internal transaction_id), मुद्रा, नेट राजस्व, और refund स्थिति।वह डेटा ना रखें जो आवश्यक नहीं है:
यदि आप कुकीज़ या समान पहचानकर्ताओं पर निर्भर हैं, तो क्षेत्र अनुसार कंसेंट की आवश्यकता हो सकती है।
एक व्यावहारिक तरीका यह है कि पार्टनर्स जो कर सकते हैं उनके लिए सर्वर-साइड ट्रैकिंग (postbacks) सपोर्ट करें, और ग्राहक-साइड कुकीज़ को केवल तब उपयोग करें जब अनुमति हो और ज़रूरत हो।
एट्रिब्यूशन और पेआउट डेटा को संवेदनशील व्यावसायिक डेटा मानें, और मानक नियंत्रण लागू करें:
डेटा रिटेंशन पर भी विचार करें: कच्चे इवेंट-लेवल रिकॉर्ड केवल जितना आवश्यक हो उतनी देर रखें, फिर aggregate करें या delete करें।
लॉग्स अक्सर अनजाने में डेटा लीक बन जाते हैं। लॉगिंग नियम स्पष्ट रखें:
एक स्पष्ट प्राइवेसी नोटिस प्रकाशित करें और अपने डेटा फ्लो का दस्तावेज बनाएं। जब पार्टनर्स पूछें कि ट्रैकिंग कैसे काम करती है, आप इसे सहजता से—और सुरक्षित रूप से—समझा सकेंगे।
एक पार्टनर एट्रिब्यूशन सिस्टम तभी उपयोगी है जब पार्टनर्स उस पर भरोसा करें और फ़ाइनेंस उसे reconcile कर सके। टेस्टिंग और लॉन्च को प्रोडक्ट का हिस्सा मानें: आप बिज़नेस नियमों, डेटा इंटीग्रिटी, और ऑपरेशनल वर्कफ़्लो को सत्यापित कर रहे हैं—सिर्फ़ कोड नहीं।
छोटे सेट के “गोल्डन” किरेक्टेरों के साथ शुरू करें जिन्हें आप end-to-end replay कर सकें:
एट्रिब्यूशन नियम बदलने से ऐतिहासिक नंबर बदल जाएंगे—इसके लिए स्पष्ट योजना रखें। कच्चे इवेंट्स (क्लिक्स, कन्वर्ज़न्स, रिफंड्स) अपरिवर्तनीय रखें, फिर attribution को versioned tables में पुन: गणना करें (उदा., attribution_results_v1, v2)। बड़े इतिहास के लिए, बैचों (दिन/सप्ताह द्वारा) में बैकफिल करें और एक dry-run मोड रखें जो फ़ाइनेंस के लिए diff रिपोर्ट बनाता है।
एक छोटे समूह के पार्टनर्स (5–10) के साथ पायलट करें। पायलट के दौरान:
फीचर फ़्लैग्स के पीछे बदलाव शिप करें, पोर्टल में नियम वर्ज़न को दस्तावेज़ करें, और किसी भी बदलाव की घोषणा करें जो कमाई को प्रभावित कर सकता है।
ऑपरेशनल रूप से, रिपोर्टिंग और पेआउट लॉजिक के लिए तेज़ रोलबैक उपयोगी होता है। यदि आप जल्दी से बना रहे हैं (उदाहरण के लिए Koder.ai के साथ), snapshots और rollback फ़ीचर्स नियम कोड और डैशबोर्ड बदलावों पर सुरक्षित रूप से इटरेट करने में मदद कर सकते हैं जबकि एक जाना-पहचाना-ठीक वर्ज़न तैयार रखें।
यदि आप बाद में पैकेजिंग और ऑनबोर्डिंग का अन्वेषण करना चाहते हैं, तो देखें /pricing, या संबंधित गाइड्स के लिए /blog ब्राउज़ करें।
पार्टनर राजस्व एट्रिब्यूशन उन नियमों और डेटा का सेट है जो तय करते हैं कि किस पार्टनर को किसी राजस्व इवेंट का क्रेडिट मिलेगा (और कितना), ऐसे सबूतों के आधार पर जैसे क्लिक ID, कूपन कोड, और समय सीमा।
एक उपयोगी परिभाषा में शामिल हों:
एक वाक्य की नीति लिखकर शुरुआत करें, फिर छूटों (exceptions) को सूचीबद्ध करें।
एक ठोस V1 नीति अक्सर ऐसी होती है:
click_id और इसे सर्वर-साइड पर ऑर्डर से जोड़ा जानाफिर कूपन प्राथमिकता, रिन्यूअल्स, और क्या डायरेक्ट ट्रैफ़िक attribution तोड़ता है—इन जैसे अपवादों का दस्तावेज़ बनाएं।
कम से कम निम्नलिखित ट्रैक करें:
भले ही आप बाद में लीड या ट्रायल जोड़ें, ये तीन चीज़ें आपको ट्रैफ़िक → राजस्व → वापसी (reversals) को payout-सुरक्षित तरीके से जोड़ने की क्षमता देती हैं।
एक redirect endpoint का उपयोग करें (उदा., /r/{partner_id}) जो:
यह पार्टनर्स को click IDs spoof करने से रोकेगा और ट्रैकिंग को लगातार बनाए रखेगा।
आम तौर पर सर्वर-साइड ऑर्डर क्रिएशन को कैननिकल कन्वर्ज़न स्रोत मानें।
व्यवहारिक रूप से:
click_id (या attribution टोकन) को ऑर्डर बनते समय संलग्न करेंयह डबल-फायरिंग को कम करता है और फ़ाइनेंस समेकन को आसान बनाता है।
रीट्राइज़ डुप्लीकेट्स से बचने के लिए idempotency keys का प्रयोग करें।
सामान्य कुंजियाँ:
order_id (यदि ग्लोबली यूनिक हो तो सर्वोत्तम)payment_provider_charge_idडेटाबेस में यूनिक कॉन्स्ट्रेंट लागू करें। रिपीट में, सफलता लौटाएं लेकिन दूसरा कन्वर्ज़न या कमीशन लाइन आइटम न बनाएं।
एक ऐसे चेन की कोशिश करें जिसे आप एंड-टू-एंड साबित कर सकें:
partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_idआंतरिक और बाह्य दोनों IDs (जैसे shopify_order_id) संग्रहीत करें और created_at, ingested_at जैसे टाइमस्टैम्प रखें ताकि आप विवादों को ट्रेस कर सकें और बिलिंग सिस्टम के साथ reconcile कर सकें।
पैसे और ऑडिटेबिलिटी को ध्यान में रखते हुए मॉडल करें:
currency_code रखेंदिन एक पर ऐसा सेट शुरू करें जो सपोर्ट टिकट कम करे:
प्रत्येक कन्वर्ज़न को प्रमाण के साथ समझाने योग्य बनाएं: क्लिक टाइम, ऑर्डर ID (मास्क्ड), और लागू नियम जैसे फ़ील्ड दिखाएँ।
हल्के, सुसंगत सुरक्षा उपाय अपनाएँ:
प्राइवेसी के लिए, न्यूनतम आवश्यक डेटा रखें (pseudonymous IDs), संवेदनशील संकेतों को हैश करें जब संभव हो, और सीक्रेट्स या पेमेंट डेटा को लॉग में न रखें।
यह इतिहास को संरक्षित करता है और यदि आवश्यक हो तो अगले payout चक्र में नकारात्मक लाइन आइटम बनाने देता है।