20 ਨਵੰ 2025·8 ਮਿੰਟ
ਸਾਥੀ ਰੈਵਨਿਊ attribution ਲਈ ਵੈਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ?
ਸਿਖੋ ਕਿ ਕਿਵੇਂ ਇੱਕ ਵੈਬ ਐਪ ਡਿਜ਼ਾਈਨ ਅਤੇ ਤਿਆਰ ਕਰਨੀ ਹੈ ਜੋ partner clicks, conversions ਅਤੇ revenue track ਕਰੇ। ਡਾਟਾ ਮਾਡਲ, tracking, reporting, payouts ਅਤੇ privacy ਨੂੰ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ।
ਸਿਖੋ ਕਿ ਕਿਵੇਂ ਇੱਕ ਵੈਬ ਐਪ ਡਿਜ਼ਾਈਨ ਅਤੇ ਤਿਆਰ ਕਰਨੀ ਹੈ ਜੋ partner clicks, conversions ਅਤੇ revenue track ਕਰੇ। ਡਾਟਾ ਮਾਡਲ, tracking, reporting, payouts ਅਤੇ privacy ਨੂੰ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ।
Partner revenue attribution ਉਹ ਸਿਸਟਮ ਹੈ ਜੋ ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕਿਹੜੇ ਸਾਥੀ ਨੂੰ ਕਿਸ ਰਵਾਇਤੀ ਘਟਨਾ ਲਈ ਕ੍ਰੈਡਿਟ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ (ਅਤੇ ਕਿੰਨੀ)? ਇੱਕ ਵੈਬ ਐਪ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਸਿਰਫ clicks ਗਿਣਨਾ ਨਹੀਂ—ਤੁਸੀਂ ਇੱਕ ਸਾਥੀ ਦੀ referral ਨੂੰ ਬਾਅਦ ਦੀ conversion ਨਾਲ ਜੋੜਦੇ ਹੋ, ਉਸnu ਇੱਕ ਸਾਫ਼ revenue ਨੰਬਰ ਵਿੱਚ ਬਦਲਦੇ ਹੋ, ਅਤੇ ਇਸਨੂੰ auditable ਬਣਾਉਂਦੇ ਹੋ.
ਇੱਕ ਵਾਕ ਦੀ ਪਰਿਭਾਸ਼ਾ ਲਿਖੋ ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੇ (1) ਕੀ attribute ਕੀਤਾ ਜਾਂਦਾ ਹੈ, (2) ਕਿਸ ਨੂੰ, ਅਤੇ (3) ਕਿਸ ਨਿਯਮਾਂ ਦੇ ਤਹਿਤ। ਉਦਾਹਰਨ ਲਈ:
ਇਹ ਪਰਿਭਾਸ਼ਾ ਤੁਹਾਡੇ requirements, data model, ਅਤੇ ਉਹਨਾਂ disputes ਲਈ anchor ਬਣ ਜਾਵੇਗੀ ਜੋ ਬਾਅਦ ਵਿੱਚ ਉਠ ਸਕਦੀਆਂ ਹਨ।
“Partner” ਅਕਸਰ ਕਈ ਗਰੁੱਪਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਉਮੀਦਾਂ ਅਤੇ workflows ਵੱਖ-ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ:
ਸਭ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਇੱਕ workflow ਵਿੱਚ ਜੋੜਨ ਤੋਂ ਬਚੋ। ਤੁਸੀਂ ਫਿਰ ਵੀ ਇੱਕ ਇਕੱਠਾ ਸਿਸਟਮ ਵਰਤ ਸਕਦੇ ਹੋ (partners, programs, contracts) ਜਦੋਂ ਕਿ ਕਈ referral methods (links, codes, manual deals) ਨੂੰ ਸਹਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ practical partner revenue attribution web app ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚਾਰ ਨਤੀਜੇ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਮਜ਼ੋਰ ਹੋਵੇ ਤਾਂ partners numbers 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਨਗੇ—ਭਾਵੇਂ ਗਣਿਤ ਸਹੀ ਹੋਵੇ।
ਇੱਕ actionable build guide ਦਾ ਉਦੇਸ਼ attribution ਫ਼ਲਸਫ਼ੇ 'ਤੇ ਤਰਕ ਕਰਨ ਨਹੀਂ—ਸਗੋਂ ਇੱਕ ਕੰਮ ਕਰਨਯੋਗ ਸਿਸਟਮ ship ਕਰਨਾ ਹੈ। ਇੱਕ ਹਕੀਕੀ ਪਹਿਲਾ ਵਰਜ਼ਨ:
ਤੁਸੀਂ advanced ਫੀਚਰ ਬਾਅਦ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹੋ (multi-touch attribution, cross-device stitching, complex fraud scoring) ਜਦੋਂ ਬੇਸਿਕਸ dependable ਅਤੇ testable ਹੋ ਜਾਣ।
ਕੋਈ attribution model ਚੁਣਣ ਜਾਂ database design ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਾਫ਼ ਕਰੋ ਕਿ ਐਪธุਸਟ ਨੂੰ ਬਿਜ਼ਨਸ ਨੂੰ ਕੀ ਸਾਬਤ ਕਰਨਾ ਹੈ। Partner revenue attribution ਆਖਰਕਾਰ ਉਹ ਜਵਾਬਾਂ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਲੋਕ ਪੈਸਾ ਦੇਣ ਲਈ ਭਰੋਸਾ ਕਰਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਪਹਿਲਾਂ “partners” ਲਈ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ finance ਜਾਂ support verify ਨਹੀਂ ਕਰ ਸਕਦੇ। ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਉਪਭੋਗਤਿਆਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਫ਼ੈਸਲੇ ਦੀ ਸੂਚੀ ਬਣਾਓ:
ਆਪਣੇ UI ਅਤੇ reports ਲਈ plain-language queries ਲਿਖੋ:
click_id, coupon, referral code, ਆਦਿ)ਘੱਟੋ-ਘੱਟ, ਯੋਜਨਾ ਬਣਾਓ: click, lead, trial start, purchase, renewal, ਅਤੇ refund/chargeback। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿਹੜੇ “commissionable” ਹਨ ਅਤੇ ਕਿਹੜੇ supporting evidence ਵਜੋਂ ਹਨ।
ਇੱਕ ਸਪਸ਼ਟ ਨਿਯਮ-ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ—ਅਕਸਰ last-touch ਇੱਕ configurable window ਦੇ ਅੰਦਰ—ਫਿਰ multi-touch ਸਿਰਫ਼ ਤਦੋਂ ਜੋੜੋ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ strong reporting needs ਅਤੇ clean data ਹੋਵੇ। ਪਹਿਲਾ ਵਰਜ਼ਨ ਆਸਾਨ ਸਮਝਣਯੋਗ ਅਤੇ auditable ਰੱਖੋ।
ਕੋਈ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ “ਕਿਸ ਨੂੰ credit ਮਿਲਦਾ ਹੈ” ਅਤੇ ਉਹ credit ਕਦੋਂ expire ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ rules upfront ਨਹੀਂ ਰੱਖਦੇ, ਤਾਂ ਤੁਸੀਂ ਹਰ payout 'ਤੇ edge cases (ਅਤੇ partner complaints) ਬਾਰੇ बहਸ ਕਰਦੇ ਰਹੋਗੇ।
Last click conversion ਤੋਂ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਨਵੇਂ partner click ਨੂੰ 100% credit ਦੇਂਦਾ ਹੈ। ਇਹ ਸਧਾਰਨ ਅਤੇ ਵਿਸ਼ਵਾਸਯੋਗ ਹੈ, ਪਰ late-stage coupon traffic ਨੂੰ ਜ਼ਿਆਦਾ reward ਕਰ ਸਕਦਾ ਹੈ।
First click ਪਹਿਲੇ partner ਨੂੰ 100% credit ਦਿੰਦਾ ਹੈ ਜਿਸਨੇ customer ਨੂੰ ਪਹਿਲਾਂ ਮਿਲਾਇਆ। ਇਹ discovery partners ਨੂੰ ਯਥਾਰਥ ਤੌਰ 'ਤੇ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ partners ਨੂੰ ਘੱਟ reward ਕਰ ਸਕਦਾ ਹੈ ਜੋ deal close ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
Linear qualifying touches ਵਿੱਚ credit ਬਰਾਬਰ ਵੰਡਦਾ ਹੈ। ਇਹ “ਇਨਸਾਫ਼” ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਸਮਝਾਉਣਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ incentives dilute ਹੋ ਸਕਦੇ ਹਨ।
Time-decay touches ਨੂੰ conversion ਦੇ ਨੇੜੇ ਵਾਲੇ ਸਮਿਆਂ 'ਤੇ ਵੱਧ credit ਦਿੰਦਾ ਹੈ ਪਰ ਪਹਿਲਾਂ ਵਾਲੀ ਪ੍ਰਭਾਵ ਨੂੰ ਵੀ ਮਾਨਤਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ compromise ਹੈ, ਪਰ ਵਧੇਰੇ ਗਣਿਤ ਅਤੇ ਸਾਫ਼ reporting ਲੋੜੀਂਦੀ ਹੁੰਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ systems ਇੱਕ default model ਚੁਣਦੇ ਹਨ (ਅਕਸਰ last click) ਕਿਉਂਕਿ ਇਹ ਸਮਝਾਉਣਾ ਅਤੇ reconcile ਕਰਨਾ ਆਸਾਨ ਹੈ। ਫਿਰ exceptions ਨੂੰ ਵਿਸਥਾਰ ਨਾਲ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਕਿ support ਅਤੇ finance ਉਹਨਾਂ ਨੂੰ ਨਿਰਪੱਖ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰ ਸਕਣ:
7 / 30 / 90 ਦਿਨਾਂ ਵਰਗੇ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ windows ਸੈੱਟ ਕਰੋ। ਇੱਕ practical approach ਇੱਕ standard window (ਉਦਾਹਰਨ ਲਈ 30 ਦਿਨ) + coupons ਲਈ ਛੋਟੇ windows ਰੱਖੋ ਜੇ ਲੋੜ ਹੋਵੇ।
ਫਿਰ re-engagement rules define ਕਰੋ: ਜੇ customer window ਦੇ ਅੰਦਰ ਕਿਸੇ ਹੋਰ partner link 'ਤੇ click ਕਰਦਾ ਹੈ, ਤਾਂ ਕੀ ਤੁਸੀਂ credit ਤੁਰੰਤ switch ਕਰੋਗੇ (last click), credit split ਕਰੋਗੇ, ਜਾਂ original partner ਨੂੰ ਰੱਖੋ ਜੇ ਨਵਾਂ click “close window” (ਉਦਾਹਰਨ ਲਈ 24 ਘੰਟੇ) ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ?
ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ attribute ਕਰਦੇ ਹੋ: initial purchase ਹੀ, ਜਾਂ ਸਮੇਂ ਦੇ ਨਾਲ net revenue।
ਇਹ ਨਿਯਮ ਇੱਕ ਛੋਟੀ “Attribution Policy” doc ਵਿੱਚ ਲਿਖੋ ਅਤੇ partner portal ਵਿੱਚ ਦਰਜ ਕਰੋ ਤਾਂ ਕਿ system behavior partner expectations ਨਾਲ ਮਿਲੇ।
ਇੱਕ ਸਾਫ਼ data model “ਸਾਨੂੰ ਲੱਗਦਾ ਹੈ” ਤੋਂ ਵੱਖਰਾ ਕਰਦਾ ਹੈ “ਅਸੀਂ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹਾਂ, reconcile ਕਰ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਸahi ਅੰਦਾਜ਼ੇ ਨਾਲ pay ਕਰ ਸਕਦੇ ਹਾਂ।” ਇੱਕ ਛੋਟੇ core entities ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ relationships immutable IDs ਰਾਹੀਂ explicit ਬਣਾਓ।
partner_id, status, payout terms, default currency store ਕਰੋ।campaign_id, start/end dates।link_id, ਇਹ partner_id ਨਾਲ تعلق ਰੱਖਦਾ ਹੈ ਅਤੇ optional campaign_id।click_id, link_id ਅਤੇ partner_id ਨੂੰ reference ਕਰਦਾ ਹੈ।visitor_id (ਅਕਸਰ first-party cookie ID ਤੋਂ ਆਉਂਦਾ)।conversion_id, click_id (ਜਦੋਂ ਉਪਲਬਧ ਹੋਵੇ) ਅਤੇ visitor_id ਨੂੰ reference ਕਰਦਾ ਹੈ।order_id, customer_id ਨੂੰ reference ਕਰਦਾ ਹੈ ਅਤੇ conversion_id ਨਾਲ linked ਹੁੰਦਾ ਹੈ।payout_id, partner_id ਨੂੰ reference ਕਰਦਾ ਹੈ ਅਤੇ eligible orders aggregate ਕਰਦਾ ਹੈ।ਤੁਹਾਡਾ golden path:
partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_id
customer_id ਨੂੰ order_id ਦੇ ਨਾਲ ਕੋਈੜੋ ਤਾਂ repeat purchases ਤੁਹਾਡੇ rules follow ਕਰ ਸਕਣ (ਜਿਵੇਂ “first purchase only” vs “lifetime”)। ਆਪਣੇ internal IDs ਅਤੇ ਬਾਹਰੀ IDs (ਜਿਵੇਂ shopify_order_id) ਦੋਹਾਂ store ਕਰੋ reconciliation ਲਈ।
Orders ਬਦਲਦੇ ਹਨ। ਇਸਨੂੰ explicit model ਕਰੋ:
gross_amount, tax_amount, shipping_amount, fee_amount, discount_amount।currency_code ਅਤੇ fx_rate_to_payout_currency ਰੱਖੋ (ਅਤੇ ਉਸ rate ਦੀ timestamp/source)।order_id ਨਾਲ tie ਕੀਤਾ ਹੋਇਆ adjustment rows ਵਜੋਂ ਦਰਜ ਕਰੋ (ਉਦਾਹਰਨ: order_adjustment_id, type = partial_refund)। ਇਹ auditable history ਬਣਾਂਦਾ ਹੈ ਅਤੇ totals ਨੂੰ rewrite ਕਰਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।ਹਰੇਕ ਜਗ੍ਹਾ audit fields ਜਿਵੇਂ: created_at, updated_at, ingested_at, source (web, server-to-server, import), ਅਤੇ immutable identifiers ਰੱਖੋ।
fraud analysis ਲਈ ਬਿਨਾਂ raw personal data store ਕੀਤੇ, hashed fields ਵਰਗੇ ip_hash ਅਤੇ user_agent_hash ਰੱਖੋ। ਆਖਿਰ 'ਚ ਇੱਕ हलਕਾ change log (entity, entity_id, old/new values, actor) ਰੱਖੋ ਤਾਂ ਕਿ payout decisions explain ਕੀਤੀਆਂ ਜਾ ਸਕਣ।
Click tracking partner revenue attribution ਦੀ ਬੁਨਿਆਦ ਹੈ: ਹਰ partner link ਨੂੰ ਇੱਕ durable “click record” ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ ਬਾਅਦ ਵਿੱਚ conversion ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕੇ।
ਇੱਕ single canonical link format ਵਰਤੋ ਜੋ partners copy/paste ਕਰ ਸਕਣ। ਜ਼ਿਆਦਾਤਰ systems ਵਿੱਚ partner-facing link ਵਿੱਚ click_id ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ—ਤੁਹਾਡੀ server ਉਹ ਜੇਨੇਰੇਟ ਕਰਦੀ ਹੈ।
ਇੱਕ ਸਾਫ਼ pattern ਹੈ:
/r/{partner_id}?campaign_id=...&utm_source=...&utm_medium=partner&utm_campaign=...
ਪ੍ਰਯੋਗਕ parameter guidance:
###.redirect endpoint ਰਾਹੀਂ server-side tracking ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ
ਸਾਰੀ partner traffic ਨੂੰ ਇੱਕ redirect endpoint (ਉਦਾਹਰਨ: /r/{partner_id}) ਰਾਹੀਂ route ਕਰੋ:
partner_id, campaign_id, user agent, IP hash, timestamp, landing URL)।click_id set ਕਰੋ।ਇਸ ਨਾਲ click creation consistent ਹੁੰਦੀ ਹੈ, partners ਨੂੰ click IDs spoof ਕਰਨ ਤੋਂ ਰੋਕ ਮਿਲਦੀ ਹੈ, ਅਤੇ rule enforcement centralized ਹੁੰਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ cookie as primary, localStorage as fallback, ਅਤੇ server-side sessions only for short-lived flows ਵਰਤਦੀਆਂ ਹਨ।
Mobile web ਲਈ cookies ਘੱਟ ਭਰੋਸੇਯੋਗ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ redirect endpoint ਵਰਤੋ ਅਤੇ click_id ਨੂੰ cookie + localStorage ਦੋਹਾਂ ਵਿੱਚ store ਕਰੋ।
App-to-web ਲਈ support ਕਰੋ:
click_id ਨਾਲ exchange ਕਰ ਸਕੇ।ਪਾਰਟਨਰ portal ਵਿੱਚ link rules ਨੂੰ ਦਰਜ ਕਰੋ ਤਾਂ ਕਿ partners parameters ਨਾਲ “creative” ਨਾ ਹੋਣ।
(ਜਦੋਂ source ਵਿੱਚ ਕੋਈ ਪਾਠ/ਲਿੰਕ ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਉਹਨਾਂ ਨੂੰ ਸਰਲ ਵਰਣਨ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ—ਉਦਾਹਰਨ ਲਈ partner links, pricing, admin paths ਆਦਿ ਨੂੰ plain text ਰੱਖਿਆ ਗਿਆ ਹੈ)
Conversion tracking ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ attribution systems ਭਰੋਸਾ ਜਿੱਤਦੇ ਹਨ—ਜਾਂ ਗੁਆ ਦਿੰਦੇ ਹਨ। ਤੁਹਾਡੇ ਦਾ ਲਕੜੀ ਇੱਕ canonical “conversion” event ਨੂੰ per real purchase ਨਾਲ record ਕਰਨਾ ਹੈ, ਕਾਫੀ context ਨਾਲ ਜੋ ਇਸਨੂੰ ਇੱਕ partner click ਨਾਲ ਜੋੜੇ।
ਅਕਸਰ products conversions ਨੂੰ ਕਈ ਥਾਵਾਂ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹਨ:
ਸਿਫਾਰਸ਼: ਤੁਹਾਡਾ backend order service canonical conversion recorder ਹੋਵੇ, ਅਤੇ payment webhooks ਨੂੰ confirmation/update signal ਵਜੋਂ ਵਰਤੋਂ (ਉਦਾਹਰਨ: order ਨੂੰ pending ਤੋਂ paid ਵਿੱਚ move ਕਰਨਾ)। Client-side events debugging ਜਾਂ funnel analytics ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ, payout-grade attribution ਲਈ ਨਹੀਂ।
Revenue attribute ਕਰਨ ਲਈ, conversion event ਨੂੰ ਇੱਕ stable identifier ਅਤੇ click ਨਾਲ link ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਆਮ ਲਹਿੰਦਾ ਤਰੀਕਾ:
click_id generate/store ਕਰੋ।click_id attach ਕਰੋ (ਉਦਾਹਰਨ: session state, customer record, ਜਾਂ client ਤੋਂ bheje ਗਏ signed token ਤੋਂ)।ਤੁਹਾਡੀ primary join ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ conversion.click_id → click.id। ਜੇ click_id missing ਹੋਵੇ, ਤਾਂ explicit fallback rules ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
ਇਹ fallbacks admin tooling ਵਿੱਚ ਵਿਖਾਓ ਤਾਂ support outcomes explain ਕਰ ਸਕੇ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ।
Webhooks ਅਤੇ client calls retry ਕਰਨਗੇ। ਤੁਹਾਨੂੰ ਇੱਕੋ conversion multiple times ਪ੍ਰਾਪਤ ਕਰਨ 'ਤੇ double-counting ਤੋਂ ਬਚਣਾ ਹੋਵੇਗਾ।
Idempotency keys ਲਾਗੂ ਕਰੋ ਜੋ ਇੱਕ stable unique value ਹੋਵੇ, ਜਿਵੇਂ:
order_id (ਜਾਣ-ਪਛਾਣ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ)payment_provider_charge_idਇਸ key ਨੂੰ conversion record ਤੇ store ਕਰੋ ਅਤੇ unique constraint ਰੱਖੋ। Retry 'ਤੇ success ਰਿਟਰਨ ਕਰੋ ਅਤੇ ਇਕ ਹੋਰ conversion ਨਾ ਬਣਾਓ। ਇਹ ਪਹੁੰਚ ਸਭ ਤੋਂ ਆਮ “phantom revenue” payout bugs ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ tracking ਪੈਸੇ ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਨੂੰ tracked event ਤੋਂ ਉਹ amount ਤੱਕ ਇੱਕ ਸਾਫ਼, auditable path ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ pay ਕਰ ਸਕੋ—ਅਤੇ finance ਜੋ revenue measure ਕਰਦੀ ਹੈ ਉਸ ਨਾਲ aligned ਹੋਵੇ।
ਇੱਕ practical lifecycle ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:
ਹਰੇਕ state change ਲਈ timestamps ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ explain ਕਰ ਸਕੋ ਕਦੋਂ ਅਤੇ ਕਿਉਂ conversion payable ਬਣੀ।
ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ “revenue” ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਅਤੇ ਇਸਨੂੰ explicit store ਕਰੋ:
ਆਮ structures ਜੋ ਤੁਸੀਂ support ਕਰ ਸਕਦੇ ਹੋ:
Finance teams ਨੂੰ data ਚਾਹੀਦਾ ਹੈ ਜੋ ਉਹ reconcile ਕਰ ਸਕਣ:
Partner program trust 'ਤੇ ਟਿਕਦਾ ਹੈ। ਤੁਹਾਡਾ portal ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ partners verify ਕਰਦੇ ਹਨ ਕਿ clicks conversions ਬਣੇ ਅਤੇ conversions ਪੈਸੇ ਵਿੱਚ ਬਦਲੇ। ਤੁਹਾਡਾ admin dashboard ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਟੀਮ program ਨੂੰ clean, responsive, ਅਤੇ fair ਰੱਖਦੀ ਹੈ।
ਸਲਾਹ: ਛੋਟੇ screens ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ partners ਦੇ ਦਿਨ ਦੀਆਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਂਦੇ ਹਨ:
Conversion list ਵਿੱਚ ਉਹ ਕਾਲਮ ਸ਼ਾਮਲ ਕਰੋ ਜੋ support tickets ਘੱਟ ਕਰਦੇ ਹਨ: conversion time, order ID (ਵਾਇਕ ਕੀਤਾ/masked), attributed amount, commission rate, status (pending/approved/rejected/paid), ਅਤੇ rejected ਹੋਣ 'ਤੇ ਇੱਕ ਛੋਟਾ “reason” ਫੀਲਡ।
Partners ਅਤੇ admins ਨੂੰ results ਨੂੰ быстро slice ਕਰਨ ਲਈ quick filters ਚਾਹੀਦੇ ਹਨ। ਪਹਿਲਾ ਪ੍ਰਭਾਵ ਵਾਲੇ:
ਜੇ ਤੁਸੀਂ multiple products ਜਾਂ plans track ਕਰਦੇ ਹੋ, ਤਾਂ product filter add ਕਰੋ—ਪਰ ਸਿਰਫ਼ ਬੇਸਿਕਸ stable ਹੋਣ 'ਤੇ।
Admin tooling speed ਅਤੇ accountability 'ਤੇ focus ਕਰੇ:
Manual controls limited ਰੱਖੋ: admins exceptions correct ਕਰਨ ਲਈ ਹੋਣ, history casually rewrite ਕਰਨ ਲਈ ਨਹੀਂ।
Day one ਤੋਂ RBAC enforce ਕਰੋ:
Permissions API level 'ਤੇ enforce ਕਰੋ (UI ਹੀ ਨਹੀਂ), ਅਤੇ payout exports ਵਰਗੀਆਂ sensitive views ਲਈ access log ਕਰੋ।
Partner revenue attribution app ਅਕਸਰ "write-heavy" ਹੁੰਦਾ ਹੈ: ਬਹੁਤ clicks, ਬਹੁਤ conversions events, ਅਤੇ ਸਮੇਂ-ਸਮੇਂ ਤੇ read-heavy reporting। ਪਹਿਲਾਂ high-volume ingestion ਲਈ design ਕਰੋ, ਫਿਰ aggregation ਨਾਲ reporting ਤੇਜ਼ ਬਣਾੋ।
ਇੱਕ workable baseline: Postgres + API + modern frontend:
Tracking endpoints stateless ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ horizontally scale ਕਰ ਸਕੋ ਬੈਕਲੋਡ ਬਾਲੈਂਸਰ ਦੇ ਪਿੱਛੇ।
ਜੇ ਤੁਸੀਂ spec ਤੋਂ working internal tooling ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ prototype ਬਣਾਉਣ ਵਿੱਚ—admin dashboard, partner portal, ਅਤੇ core APIs chat-driven “vibe-coding” ਨਾਲ। Planning Mode flows outline ਕਰਨ, React frontend ਨਾਲ Go + PostgreSQL backend generate ਕਰਨ ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ productionize ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ source code export ਕਰਨ ਦੇ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ।
Request/response cycle ਵਿੱਚ expensive work ਨਾ ਕਰੋ। queue (SQS/RabbitMQ/Redis) ਅਤੇ workers ਵਰਤੋ:
Workers idempotent ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: job ਦੋ ਵਾਰ ਚੱਲੇ ਤਾਂ ਵੀ results ਸਹੀ ਰਹਿਣ।
Click tables ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦੇ ਨੇ। retention upfront plan ਕਰੋ:
Postgres ਵਿੱਚ clicks ਲਈ time-based partitioning (ਮਾਸਿਕ partitions) ਤੇ ਵਿਚਾਰ ਕਰੋ ਅਤੇ index (occurred_at, partner_id) ਅਤੇ lookup keys ਜਿਵੇਂ click_id ਉੱਤੇ ਬਣਾਓ। Partitioning vacuum/index maintenance ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੀਆਂ partitions ਡ੍ਰਾਪ ਕਰਕੇ retention ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ।
Tracking failures ਅਕਸਰ silent ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਤਕ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ measure ਨਹੀਂ ਕਰਦੇ। ਜੋੜੋ:
Correlation ID (ਉਦਾਹਰਨ: click_id/conversion_id) ਨਾਲ consistent logging ਕਰੋ ਤਾਂ support end-to-end trace ਕਰ ਸਕੇ।
Fraud controls ਸਿਰਫ਼ ਬੁਰੇ actors ਨੂੰ ਪਕੜਨ ਲਈ ਨਹੀਂ—ਇਹ ਸਚੇ partners ਨੂੰ noisy data ਨਾਲ underpaid ਹੋਣ ਤੋਂ ਵੀ ਬਚਾਉਂਦੇ ਹਨ। ਇੱਕ ਵਧੀਆ ਮਿਸ਼ਰਣ automatic safeguards (ਤੇਜ਼, consistent) ਅਤੇ human review (ਲਚਕੀਲਾ, ਸੰਦਰਭੀ) ਦਾ ਹੁੰਦਾ ਹੈ।
Self-referrals ਜਿਸ ਵਿੱਚ partners ਆਪਣੀਆਂ purchases/ sign-ups ਤੇ commission ਲੈਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ (ਬਾਰ-ਬਾਰ payment fingerprints, emails, ਜਾਂ device signals ਤੋਂ detect ਹੋ ਸਕਦਾ ਹੈ)।
Cookie stuffing ਅਤੇ click spam users “claim” ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ ਬਿਨਾਂ real intent ਦੇ—ਉਦਾਹਰਨ: invisible iframes, forced redirects, ਜਾਂ high click volume with near-zero engagement।
Fake leads low-quality form submissions ਹੁੰਦੇ ਹਨ ਜੋ CPA payouts trigger ਕਰਨ ਲਈ ਬਣਾਏ ਜਾਂਦੇ ਹਨ। Coupon leakage ਹੋਣ 'ਤੇ private code publicly share ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ attribution real source ਤੋਂ shift ਹੋ ਜਾਂਦੀ ਹੈ।
Partners/IP range/ user-session ਅਨੁਸਾਰ clicks ਅਤੇ conversions 'ਤੇ rate limits ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਸਨੂੰ bot detection signals ਨਾਲ ਜੋੜੋ: user-agent anomalies, missing JavaScript execution signals, suspicious timing, data-center IPs, ਅਤੇ repeated device fingerprints।
anomaly alerts add ਕਰੋ। advanced ML ਦੀ ਲੋੜ ਨਹੀਂ—ਸਰਲ thresholds ਜਿਵੇਂ “conversion rate spike 5× week-over-week” ਜਾਂ “bahut ਸਾਰੇ conversions identical metadata ਨਾਲ” ਅਕਸਰ issues ਕੈਚ ਕਰ ਲੈਂਦੇ ਹਨ। Alerts admin drill-down view ਨਾਲ link ਕਰੋ (admin partner attribution page ਦਾ plain text reference ਦਰਜ ਕੀਤਾ ਗਿਆ ਹੈ)।
Data quality ਲਈ ingestion 'ਤੇ validation ਕਰੋ। ਜਿੱਥੇ ਲਾਜ਼ਮੀ ਹੋਵੇ click IDs ਜਾਂ signed partner tokens ਦੀ ਮੰਗ ਕਰੋ, malformed UTMs reject ਕਰੋ, ਅਤੇ country/currency fields normalize ਕਰੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਜਾਂਚਾਂ incomplete logs ਜਾਂ ambiguous joins ਕਰਕੇ investigation fail ਹੋ ਜਾਂਦੀ ਹੈ।
Operators ਲਈ ਇੱਕ clear queue ਦਿਓ: flags (reason + severity), notes, ਅਤੇ related clicks ਅਤੇ conversions ਦੀ timeline।
conversion holds (“pending”) support ਕਰੋ ਤਾਂ suspicious events turant payouts ਵਿੱਚ ਨਾ ਆਉਣ। partner warnings ਅਤੇ escalation (temporary payout delays, traffic restrictions, ਜਾਂ program removal) ਨਾਲ consistent actions templates ਰਾਹੀਂ ਕਰੋ।
Immutable audit trail ਰੱਖੋ:
ਇਹ partner disputes, finance reconciliation, ਅਤੇ internal accountability ਲਈ ਜਰੂਰੀ ਹੈ—ਖਾਸ ਕਰ ਕੇ ਜਦੋਂ ਕਈ ਲੋਕ rules ਅਤੇ payouts change ਕਰ ਸਕਦੇ ਹਨ।
Partner revenue attribution tracking, identity, ਅਤੇ payments ਨੂੰ ਛੂਹਦਾ ਹੈ—ਇਹ ਤਿੰਨ ਖੇਤਰ ਹਨ ਜਿੱਥੇ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਵੱਡਾ ਖ਼ਤਰਾ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਉਦੇਸ਼ referrals measure ਕਰਨਾ ਅਤੇ payouts calculate ਕਰਨਾ ਹੈ, ਜਦੋਂ ਕਿ ਘੱਟ ਤੋਂ ਘੱਟ personal data collect ਕਰਨ ਤੇ ਜੋ ਕੁਝ store ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਉਸਨੂੰ protected ਰੱਖਣਾ।
ਆਰੰਭ ਕਰੋ ਉਸ ਘੱਟੋ-ਘੱਟ ਡਾਟਾਸੇਟ ਤੋਂ ਜੋ attribution ਅਤੇ reconciliation ਲਈ ਜ਼ਰੂਰੀ ਹੈ:
partner_id, campaign_id, Generated click_id।click_time ਅਤੇ conversion_time।order_id (ਜਾਂ internal transaction_id), currency, net revenue, ਅਤੇ refund status।ਜੋ ਲੋੜੀਦਾ ਨਹੀਂ ਉਹ collect ਕਰਨ ਤੋਂ ਬਚੋ:
click_id, internal customer_id) ਨੂੰ personal identifiers ਦੇ ਮੂੰਹਗੇ ਵਰਗੇ ਪਸੰਦ ਕਰੋ।ਜੇ ਤੁਸੀਂ cookies ਜਾਂ ਸਮਾਨ identifiers 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ region ਅਨੁਸਾਰ consent ਦੀ ਲੋੜ ਪੈਂ ਸਕਦੀ ਹੈ।
Practical approach server-side tracking (postbacks) support ਕਰਨ ਦੀ ਹੈ ਜਿਨ੍ਹਾਂ partners ਇਸਨੂੰ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ client-side cookies ਨੂੰ ਸਿਰਫ਼ ਜਿੱਥੇ allowed ਅਤੇ necessary ਹੋ, ਉਹਥੇ ਵਰਤੋ।
Attribution ਅਤੇ payout data ਨੂੰ sensitive business data ਸਮਝੋ ਅਤੇ standard controls ਲਾਗੂ ਕਰੋ:
Data retention ਬਾਰੇ ਵੀ ਸੋਚੋ: raw event-level records ਉਸ ਸਮੇਂ ਤੱਕ ਰੱਖੋ ਜਿੰਨੇ ਲੋੜੀਆਂ ਹਨ reconciliation ਅਤੇ disputes ਲਈ, ਫਿਰ aggregate ਜਾਂ delete ਕਰੋ।
Logs ਅਕਸਰ ਅਕਸਮਾਤਿਕ data leak ਬਣ ਜਾਂਦੇ ਹਨ। logging rules explicit ਰੱਖੋ:
ਸਪੱਸ਼ਟ privacy notice publish ਕਰੋ ਅਤੇ ਆਪਣੇ data flows document ਕਰੋ। ਜਦੋਂ partners ਪੁੱਛਦੇ ਹਨ ਕਿ tracking ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾ ਸਕੋਗੇ।
Partner attribution system ਤਦ ਤੱਕ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹੈ ਜਦ ਤਕ partners ਇਸ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ ਅਤੇ finance reconcile ਨਹੀਂ ਕਰ ਸਕਦੀ। Testing ਅਤੇ launch ਨੂੰ product ਜਿਵੇਂ treat ਕਰੋ: ਤੁਸੀਂ business rules, data integrity, ਅਤੇ operational workflows validate ਕਰ ਰਹੇ ਹੋ—ਸਿਰਫ਼ code ਨਹੀਂ।
“Golden” scenarios ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ end-to-end replay ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ:
Attribution rules change ਹੋਣ ਨਾਲ historical numbers ਬਦਲ ਸਕਦੇ ਹਨ—ਇਸ ਲਈ explicit planning ਕਰੋ। Raw events (clicks, conversions, refunds) immutable ਰੱਖੋ, ਫਿਰ attribution ਨੂੰ versioned tables ਵਿੱਚ recompute ਕਰੋ (e.g., attribution_results_v1, v2)। ਵੱਡੀ history ਲਈ backfill batches (day/week) ਵਿੱਚ ਕਰੋ ਅਤੇ dry-run mode ਵਿੱਚ diff report finance ਨੂੰ ਦਿਖਾਓ।
Pilot ਇੱਕ ਛੋਟੇ group of partners (5–10) ਨਾਲ ਕਰੋ। Pilot ਦੌਰਾਨ:
Feature flags ਦੇ ਪਿੱਛੇ changes ship ਕਰੋ, portal ਵਿੱਚ rule versions document ਕਰੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਦੀ ਜਾਣਕਾਰੀ ਜਾਰੀ ਕਰੋ ਜੋ earnings ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ।
Operationally, reporting ਅਤੇ payout logic ਲਈ fast rollback ਹੋਣਾ ਮਦਦਗਾਰ ਹੈ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ snapshots ਅਤੇ rollback ਵਰਗੇ ਟੂਲ ਸਹਾਇਕ ਹੋ ਸਕਦੇ ਹਨ rule code ਅਤੇ dashboard changes ਨੂੰ safely iterate ਕਰਨ ਲਈ ਜਦੋਂ ਕਿ known-good version ਤਿਆਰ ਰੱਖਣਾ।
(ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ packaging ਅਤੇ onboarding explore ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ pricing ਅਤੇ ਹੋਰ guides blog ਵਿੱਚ ਵੇਖੋ.)
Partner revenue attribution ਉਹ ਨਿਯਮ ਅਤੇ ਡਾਟਾ ਹੈ ਜੋ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿਹੜੇ ਸਾਥੀ ਨੂੰ ਕਿਸ ਰਵਾਇਤੀ ਘਟਨਾ ਲਈ ਖ਼ਰੇਦਾਪੜਤ ਦਾ ਕ੍ਰੈਡਿਟ ਮਿਲਦਾ ਹੈ (ਅਤੇ ਕਿੰਨਾ), ਜਿਸ ਵਿੱਚ ਸਬੂਤ ਵਜੋਂ click_id, coupon codes ਅਤੇ timing windows ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ.
ਇਕ ਵਰਤੋਂਯੋਗ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇੱਕ ਵਾਕ ਦੀ ਪਾਲਿਸੀ ਲਿਖੋ, ਫਿਰ ਇਤਰੇਕੋ ਐਕਸਪਸ਼ਨ ਦੀ ਸੂਚੀ ਬਣਾਓ।
ਇੱਕ ਮਜ਼ਬੂਤ V1 ਨੀਤੀ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੁੰਦੀ ਹੈ:
click_id ਅਤੇ order ਦੇ ਨਾਲ server-side ਜੋੜਨਾਫਿਰ coupon precedence, renewals ਅਤੇ direct traffic ਸੰਬੰਧੀ ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਘੱਟੋ-ਘੱਟ, ਇਹਨਾਂ ਨੂੰ track ਕਰੋ:
ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ leads ਜਾਂ trials ਜੋੜਾਂ, ਇਹ ਤਿੰਨ ਤੁਹਾਨੂੰ traffic → revenue → reversals ਨੂੰ payout-safe ਢੰਗ ਨਾਲ ਜੋੜਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ redirect endpoint ਵਰਤੋ (ਉਦਾਹਰਨ: /r/{partner_id}) ਜੋ ਕਿ:
ਇਸ ਨਾਲ partners ਵੱਲੋਂ click IDs spoof ਕਰਨ ਤੋਂ ਰੋਕ ਮਿਲਦੀ ਹੈ ਅਤੇ tracking consistent ਬਣਦੀ ਹੈ।
ਆਪਣੇ backend order creation ਨੂੰ canonical conversion source ਮਨੋ.
ਅਮਲੀ ਤੌਰ 'ਤੇ:
click_id (ਜਾਂ attribution token) ਨੂੰ order creation ਸਮੇਂ attach ਕਰੋਇਸ ਨਾਲ double-fires ਘੱਟ ਹੁੰਦੀਆਂ ਅਤੇ finance reconciliation ਆਸਾਨ ਹੁੰਦੀ ਹੈ।
ਟ੍ਰਾਇਆਂ/ਰੀਂਟੈਸ ਲਈ idempotency keys ਵਰਤੋ ਤਾਂ ਕਿ retries duplicate conversions ਨਾ ਬਣਣ.
ਆਮ keys:
order_id (अगर globally unique ਹੋਵੇ ਤਾਂ ਸਭ ਤੋਂ ਵਧੀਆ)payment_provider_charge_idਡਾਟਾਬੇਸ 'ਚ uniqueness enforce ਕਰੋ (unique constraint)। ਦੁਹਰਾਏ ਜਾਣ 'ਤੇ success ਰਿਟਰਨ ਕਰੋ ਪਰ ਦੂਜਾ conversion ਨਾ ਬਣਾਓ।
ਇੱਕ chain ਜੋ ਤੁਸੀਂ end-to-end ਸਾਬਤ ਕਰ ਸਕੋ:
partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_idਅੰਦਰੂਨੀ ਅਤੇ ਬਾਹਰੀ ਦੋਹਾਂ IDs (ਜਿਵੇਂ shopify_order_id) ਰੱਖੋ ਅਤੇ timestamps (created_at, ingested_at) ਸੰਜਮਿਤ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ disputes trace ਅਤੇ billing ਨਾਲ reconcile ਕਰ ਸਕੋ।
ਪੈਸਾ audit-friendly ਅਤੇ reversals ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਕੇ model ਕਰੋ:
currency_code ਰੱਖੋDay-one portal screens ਜੋ support tickets ਘੱਟ ਕਰਦੇ ਹਨ:
ਹਰ conversion ਨੂੰ explain ਕਰਨਯੋਗ ਬਣਾਓ: click time, masked order ID ਅਤੇ applied rule ਵਰਗੀਆਂ evidence fields ਦਿਖਾਓ।
ਹਲਕੇ, consistent safeguards ਵਰਤੋ:
Privacy ਲਈ, minimum data ਰੱਖੋ (pseudonymous IDs), sensitive signals (ਜਿਵੇਂ IP) ਨੂੰ hash ਕਰੋ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਅਤੇ payment/personal data ਨੂੰ logs ਵਿੱਚ ਨਾ ਰੱਖੋ।
ਇਸ ਨਾਲ history preserve ਹੁੰਦੀ ਹੈ ਅਤੇ ਜਰੂਰਤ 'ਤੇ ਅਗਲੇ payout cycle ਵਿੱਚ negative line items ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ।