24 ਮਾਰਚ 2025·8 ਮਿੰਟ
ਐਡੋਕੇਸੀ ਅਤੇ ਰੈਫਰਲ ਟ੍ਰੈਕਿੰਗ ਲਈ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਜਾਣੋ ਕਿ ਕਿਵੇਂ ਇੱਕ ਵੈੱਬ ਐਪ ਬਣਾਈਏ ਜੋ advocates, referrals ਅਤੇ ਇਨਾਮ ਟਰੈਕ ਕਰੇ — MVP ਫੀਚਰ, ਡੇਟਾ ਮਾਡਲ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਐਨਾਲਿਟਿਕਸ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸਮੇਤ।
ਜਾਣੋ ਕਿ ਕਿਵੇਂ ਇੱਕ ਵੈੱਬ ਐਪ ਬਣਾਈਏ ਜੋ advocates, referrals ਅਤੇ ਇਨਾਮ ਟਰੈਕ ਕਰੇ — MVP ਫੀਚਰ, ਡੇਟਾ ਮਾਡਲ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਐਨਾਲਿਟਿਕਸ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸਮੇਤ।
ਬਿਲਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਵਿੱਚ “ਐਡੋਕੇਸੀ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਕੁਝ ਟੀਮਾਂ ਐਡਵੋਕੇਸੀ ਨੂੰ ਸਿਰਫ਼ ਰੈਫਰਲ ਦੇ ਤੌਰ 'ਤੇ ਦੇਖਦੀਆਂ ਹਨ। ਹੋਰਾਂ ਵਿੱਚ ਉਤਪਾਦ ਸਮੀਖਿਆਵਾਂ, ਸੋਸ਼ਲ ਜਿਕਰ, ਟੈਸਟਿਮੋਨੀਅਲ ਕੋਟਸ, ਕੇਸ ਅਧਿਐਨ, ਕਮਿਊਨਿਟੀ ਭਾਗੀਦਾਰੀ ਜਾਂ ਇਵੇਂਟ ਵਿੱਚ ਬੋਲਣ ਨੂੰ ਵੀ ਟਰੈਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡੇ ਵੈੱਬ ਐਪ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਕਿ ਹਰ ਕੋਈ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਇੱਕੋ ਕਾਰਵਾਈ ਦਰਜ ਕਰੇ।
ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਵੱਖ-ਵੱਖ ਮਕਸਦ ਸੇਵਾ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਹਾਦਫ਼ ਮਿਲਾ ਦੇਣ ਨਾਲ ਰਿਪੋਰਟਿੰਗ ਧੁੰਦਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਜਾਂ ਦੋ ਪ੍ਰਧਾਨ ਨਤੀਜੇ ਚੁਣੋ, ਜਿਵੇਂ:
ਇੱਕ ਲਾਭਕਾਰੀ ਟੈਸਟ: ਜੇ ਤੁਹਾਨੂੰ CEO ਨੂੰ ਮਹੀਨਾਵਾਰ ਇੱਕ ਚਾਰਟ ਦਿਖਾਣਾ ਹੋਵੇ ਤਾਂ ਉਹ ਕਿਹੜਾ ਹੋਵੇਗਾ?
ਜਦੋਂ ਹਾਦਫ਼ ਨਿਰਧਾਰਿਤ ਹੋ ਜਾਣ, ਉਹ ਅੰਕ ਜੋ ਤੁਹਾਡਾ ਰੈਫਰਲ ਟ੍ਰੈਕਿੰਗ ਸਿਸਟਮ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਗਣਨਾ ਕਰੇਗਾ, ਉਹ ਲਿਖੋ। ਆਮ ਮੈਟਰਿਕ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਪਰਿਭਾਸ਼ਾਵਾਂ ਸਪਸ਼ਟ ਰੱਖੋ (ਉਦਾਹਰਨ ਲਈ, “30 ਦਿਨਾਂ ਦੇ ਅੰਦਰ ਕਨਵਰਸ਼ਨ”; “ਪੇਡ” ਵਿੱਚ ਰਿਫੰਡ ਸ਼ਾਮਲ ਨਹੀਂ)।
ਗਾਹਕ ਐਡਵੋਕੇਸੀ ਟ੍ਰੈਕਿੰਗ ਕਈ ਟੀਮਾਂ ਨੂੰ ਛੂਹਦੀ ਹੈ। ਤੈਅ ਕਰੋ ਕਿ ਕੌਣ ਨਿਯਮ ਮਨਜ਼ੂਰ ਕਰੇਗਾ ਅਤੇ ਕੌਣ ਨੂੰ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੈ:
ਇਹ ਫੈਸਲੇ ਇੱਕ ਛੋਟੀ_SPEC ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਇਸ ਨਾਲ ਸਕ੍ਰੀਨਾਂ ਅਤੇ attribution ਲਾਜਿਕ ਬਣਾਉਂਦੇ ਵੇਲੇ ਦੁਬਾਰਾ ਕੰਮ ਘਟੇਗਾ।
ਔਜ਼ਾਰ ਜਾਂ ਡੇਟਾਬੇਸ ਟੇਬਲ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਲੋਕ ਨਕਸ਼ਾ ਕਰੋ ਜੋ ਸਿਸਟਮ ਨੂੰ ਛੂਹਣਗੇ ਅਤੇ ਉਹ “ਹੈਪੀ ਪਾਥ” ਜੋ ਉਹ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਇੱਕ ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਵੈੱਬ ਐਪ ਉਸ ਵੇਲੇ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਅਡਵੋਕੇਟਾਂ ਲਈ ਸਪਸ਼ਟ ਅਤੇ ਕਾਰੋਬਾਰ ਲਈ ਨਿਯੰਤਰਣਯੋਗ ਲੱਗੇ।
Advocates (ਗਾਹਕ, ਭਾਗੀਦਾਰ, ਕਰਮਚਾਰੀ): ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਲਿੰਕ ਬਾਂਟਣ ਜਾਂ ਨਿਯੋਤਾ ਭੇਜਣ ਲਈ, ਰੈਫਰਲ ਸਥਿਤੀ ਦੇਖਣ ਅਤੇ ਜਾਣਣ ਲਈ ਕਿ ਇਨਾਮ ਕਦੋਂ ਮਿਲਦੇ ਹਨ।
Internal admins (marketing, customer success, ops): ਕੌਣ ਐਡਵੋਕੇਟ ਕਰ ਰਿਹਾ ਹੈ, ਕਿਹੜੀਆਂ ਰੈਫਰਲ ਵੈਧ ਹਨ, ਅਤੇ ਕੀ ਕਾਰਵਾਈ ਕਰਨੀਆਂ ਨੇ (ਮਨਜ਼ੂਰ ਕਰੋ, ਰੱਦ ਕਰੋ, ਸੁਨੇਹੇ ਦੁਬਾਰਾ ਭੇਜੋ) ਇਸ ਵਿੱਚ ਵਿਜ਼ੀਬਿਲਟੀ।
Finance / rewards approvers: ਪੇਆਊਟ ਲਈ ਸਪਸ਼ਟ ਸਬੂਤ, ਆਡਿਟ ਟਰੇਲ ਅਤੇ ਮੁਲਾਂਕਣ ਲਈ ਐਕਸਪੋਰਟ ਕਰਨਯੋਗ ਸਮਰੀ।
Invite → signup → attribution → reward
ਇੱਕ ਅਡਵੋਕੇਟ ਲਿੰਕ ਜਾਂ ਨਿਯੋਤਾ ਸਾਂਝਾ ਕਰਦਾ ਹੈ। ਇੱਕ ਦੋਸਤ ਸਾਈਨਅਪ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਰੈਫਰਲ ਟ੍ਰੈਕਿੰਗ ਸਿਸਟਮ ਕਨਵਰਜ਼ਨ ਨੂੰ ਅਡਵੋਕੇਟ ਨੂੰ attribution ਕਰਦਾ ਹੈ। ਇਨਾਮ ਟਰਿੱਗਰ ਹੁੰਦਾ ਹੈ (ਜਾਂ ਮਨਜ਼ੂਰੀ ਲਈ ਕਤਾਰ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ)।
Advocate onboarding → sharing options → status tracking
ਅਡਵੋਕੇਟ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ (consent, ਬੁਨਿਆਦੀ ਪ੍ਰੋਫਾਈਲ)। ਉਹ ਚੁਣਦਾ ਹੈ ਕਿ ਕਿਸ ਤਰੀਕੇ ਨਾਲ ਸਾਂਝਾ ਕਰਨਾ ਹੈ (ਲਿੰਕ, ਈਮੇਲ, ਕੋਡ)। ਉਹ ਸਹਾਇਤਾ ਨੂੰ ਬਿਨਾਂ ਸੰਪਰਕ ਕੀਤੇ ਪ੍ਰਗਟੀ ਦਰਸਾਉਂਦਾ ਹੈ।
Admin review → exception handling → payout confirmation
ਇੱਕ ਐਡਮਿਨ ਫਲੈਗ ਕੀਤੀਆਂ ਰੈਫਰਲਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ (ਡੁਪਲਿਕੇਟ, ਰਿਫੰਡ, self-referrals)। Finance ਪੇਆਊਟ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ। ਅਡਵੋਕੇਟ ਨੂੰ ਪੁਸ਼ਟੀ ਸੁਨੇਹਾ ਮਿਲਦਾ ਹੈ।
ਇੱਕ standalone portal ਤੇਜ਼ੀ ਨਾਲ ਲਾਂਚ ਹੁੰਦਾ ਹੈ ਅਤੇ ਬਾਹਰਲੇ ਲੋਕਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਇੱਕ embedded experience ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਦੇ ਅੰਦਰ friction ਘਟਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਹੀ authenticate ਹਨ। ਬਹੁਤ ਟੀਮਾਂ standalone ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ ਐਂਬੈਡ ਕਰ ਲੈਂਦੀਆਂ ਹਨ।
ਐਕ MVP ਲਈ ਸਕ੍ਰੀਨ ਘੱਟ ਰੱਖੋ:
ਇਹ ਸਕ੍ਰੀਨ ਅਡਵੋਕੇਟ ਪ੍ਰਬੰਧਨ ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਰੈਫਰਲ ਐਨਾਲਿਟਿਕਸ ਜੋੜਨਾ ਆਸਾਨ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕ ਐਡਵੋਕੇਸੀ ਤੇ ਰੈਫਰਲ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਵੱਡਾ ਉਤਪਾਦ ਬਣ ਸਕਦਾ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਇੱਕ ਐਸਾ MVP ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਹੈ ਜੋ ਕੋਰ ਲੂਪ ਨੂੰ ਸਾਬਤ ਕਰੇ: ਅਡਵੋਕੇਟ ਸਾਂਝਾ ਕਰਦਾ ਹੈ, ਦੋਸਤ ਕਨਵਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਸਹੀ ਵਿਅਕਤੀ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਕ੍ਰੈਡਿਟ ਕਰ ਸਕਦੇ ਹੋ।
ਤੁਹਾਡਾ MVP ਇਕ ਅਸਲ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਏ ਬਿਨਾਂ ਬਹੁਤ ਹਥਿਆਰਕ ਕਾਰਵਾਈ ਦੇ। ਇਕ ਕਾਰਗਰ ਬੇਸਲਾਈਨ ਸ਼ਾਮਲ ਹੈ:
ਜੇ ਤੁਹਾਡਾ MVP ਛੋਟੀ ਪਾਇਲਟ ਨੂੰ spreadsheets ਤੋਂ ਬਿਨਾਂ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ “done” ਹੈ।
ਹੇਠਾਂ ਕੁਝ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਕੀਮਤੀ ਹਨ ਪਰ ਅਕਸਰ ਡਿਲਿਵਰੀ ਸੁਸਥੀ ਕਰਦੀਆਂ ਹਨ:
ਟਾਈਮਲਾਈਨ, ਟੀਮ ਸਕਿਲਜ਼, ਬਜਟ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਜ਼ਰੂਰਤਾਂ (ਟੈਕਸ, ਪ੍ਰਾਈਵੇਸੀ, ਪੇਆਊਟ ਨਿਯਮ) ਲਿਖੋ। ਜਦੋਂ ਤਿਆਗ-ਬਦਲ੍ਹੇ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਟ੍ਰੈਕਿੰਗ ਦੀ ਸ਼ੁੱਧਤਾ ਅਤੇ ਇੱਕ ਸਾਫ਼ ਐਡਮਿਨ ਵਰਕਫਲੋ ਨੂੰ ਪਹਿਲ ਦੇਵੋ—ਇਹਨਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਨਾ ਸਭ ਤੋਂ ਔਖਾ ਹੁੰਦਾ ਹੈ।
ਰੈਫਰਲ ਐਪ ਆਪਣੀ ਡੇਟਾ ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਐਨਟੀਟੀਆਂ ਅਤੇ ਸਥਿਤੀਆਂ ਸ਼ੁਰੂ ਤੋਂ ਠੀਕ ਰੱਖੋ, ਤਾਂ ਬਾਕੀ ਸਭ ਕੁਝ—ਰਿਪੋਰਟਿੰਗ, ਪੇਆਊਟ, ਫਰੌਡ ਚੈਕ—ਸਾਮਾਨ ਬਣ ਜਾਂਦੇ ਹਨ।
ਘੱਟੋ-ਘੱਟ ਇਹਨਾਂ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਮਾਡਲ ਕਰੋ:
ਹਰ ਰਿਕਾਰਡ ਨੂੰ ਵਿਲੱਖਣ ਪਹਿਚਾਣ-ਕਰਤਾ (UUID ਵਰਗਾ) ਅਤੇ timestamps (created_at, updated_at) ਦਿਓ। ਉਹ ਸਥਿਤੀਆਂ ਜੋ ਕੰਮ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ, ਜਿਵੇਂ pending → approved → paid ਰੱਖੋ, ਅਤੇ ਸੋਰਸ ਚੈਨਲ (email, link share, QR, in-app, partner) ਸਟੋਰ ਕਰੋ।
ਇੱਕ ਕਾਰਗਰ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ Referral/Reward 'ਤੇ “ਮੌਜੂਦਾ ਸਥਿਤੀ” ਫਿਲਡ ਰੱਖੋ ਅਤੇ ਪੂਰਾ ਇਤਿਹਾਸ Events ਵਜੋਂ ਰੱਖੋ।
ਰੈਫਰਲ ਅਕਸਰ ਇਕ ਕਦਮ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ ਕ੍ਰਮ ਰਿਕਾਰਡ ਕਰੋ:
click → signup → purchase → refund
ਇਸ ਨਾਲ attribution ਵਜੀਹ ਬਣਦੀ ਹੈ ("14 ਦਿਨਾਂ ਵਿੱਚ purchase ਹੋਇਆ") ਅਤੇ chargebacks, cancellations, ਅਤੇ ਆਧੇ-ਵਸੂਲ ਰੋਕਥਾਮ ਵਰਗੀਆਂ ਐਜ਼ ਕੇਸਾਂ ਨੂੰ ਸਮਰਥਨ ਮਿਲਦਾ ਹੈ।
ਪ੍ਰੋਡਕਟ ਅਤੇ ਭੁਗਤਾਨ ਇਵੈਂਟ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਡੁੱਪਲੀਕੇਟ ਤੋਂ ਬਚਣ ਲਈ, Event ਲਿਖਤ idempotent ਬਣਾਓ ਅਤੇ external_event_id (ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ, ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸਰ, ਜਾਂ CRM ਤੋਂ) ਨੂੰ ਸਟੋਰ ਕਰੋ ਅਤੇ (source_system, external_event_id) 'ਤੇ uniqueness ਲਗਾਓ। ਜੇ ਉਹੀ ਇਵੈਂਟ ਦੋ ਵਾਰੀ ਆ ਜਾਵੇ, ਤੁਹਾਡੀ ਸਿਸਟਮ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ “already processed” ਵਾਪਸ ਕਰੇ ਅਤੇ totals ਸਹੀ ਰੱਖੇ।
Attribution ਉਹ “ਸਰੋਤ-ਅਸਲ” ਹੈ ਜਿਸ 'ਤੇ ਰੈਫਰਲ ਦਾ ਕ੍ਰੈਡਿਟ ਜਾਂਦਾ ਹੈ—ਅਤੇ ਇਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਵੈੱਬ ਐਪ ਨਿਆਂਸੂਚਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਜਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਬਣਦੇ ਹਨ। ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀਆਂ ਵਰਤਾਰਾਂ ਨੂੰ ਮੰਨੋਗੇ, ਫਿਰ ਐਸੇ ਨਿਯਮ ਲਿਖੋ ਜੋ ਹਕੀਕਤ ਵਿੱਚ ਗੰਦਗੀ ਆਉਣ 'ਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵਰਤੋਂ ਕਰਨ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਸ਼ੁਰੂ ਵਿੱਚ 2–3 ਵਿਧੀਆਂ ਨਾਲ ਸਫਲ ਹੁੰਦੀਆਂ ਹਨ:
ਯੂਜ਼ਰ ਕਈ ਲਿੰਕਾਂ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਡਿਵਾਈਸ ਬਦਲਦੇ ਹਨ, cookies ਸਾਫ਼ ਕਰਦੇ ਹਨ ਅਤੇ ਦਿਨਾਂ ਬਾਅਦ ਕਨਵਰਟ ਹੁੰਦੇ ਹਨ। ਤੁਹਾਡਾ ਰੈਫਰਲ ਟ੍ਰੈਕਿੰਗ ਸਿਸਟਮ ਨਿਰਧਾਰਿਤ ਕਰੇ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ:
ਇੱਕ ਪ੍ਰਯੋਗੀ MVP ਨਿਯਮ: ਇੱਕ conversion window ਸੈੱਟ ਕਰੋ, ਉਸ ਵਿੰਡੋ ਵਿੱਚ ਸਭ ਤੋਂ ਹਾਲੀਆ ਵੈਧ ਰੈਫਰਲ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਐਡਮਿਨ ਟੂਲ ਵਿੱਚ ਮੈਨੂਅਲ ਓਵਰਰਾਈਡ ਦੀ ਆਗਿਆ ਦਿਓ।
ਵੈੱਬ ਐਪ MVP ਲਈ, last-touch ਜਾਂ first-touch ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਸਪਲਿੱਟ ਕ੍ਰੈਡਿਟ ਆਕਰਸ਼ਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ reward automation ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਜ਼ਿਆਦਾ ਜਟਿਲਤਾ ਵਧਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਰੈਫਰਲ ਨੂੰ ਕ੍ਰੈਡਿਟ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਆਡਿਟ ਟੇਲ ਰੱਖੋ (ਉਦਾਹਰਨ: click ID, timestamp, landing page, coupon ਵਰਤਿਆ, invite email ID, user agent, ਅਤੇ ਕੋਈ ਵੀ claim-form ਇਨਪੁਟ)। ਇਸ ਨਾਲ advocate ਪ੍ਰਬੰਧਨ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਫਰੌਡ ਸਮੀਖਿਆ ਸਮਰਥਿਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਵਿਵਾਦ ਤੇਜ਼ੀ ਨਾਲ ਹੱਲ ਹੋ ਸਕਦੇ ਹਨ।
ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਨਹੀਂ, ਪਰ ਦੈਨੀਕ ਚਲਾਉਣ-ਯੋਗ ਬਣਾਉਣ ਲਈ ਕਿਸੇ ਨੂੰ ਇਸ ਨੂੰ ਚਲਾਉਣਾ ਆਣਾ ਚਾਹੀਦਾ ਹੈ। ਐਡਮਿਨ ਇਲਾਕਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਕੱਚੇ ਰੈਫਰਲ ਇਵੈਂਟਾਂ ਨੂੰ ਨਿਰਣਯ 'ਤੇ ਬਦਲਦੇ ਹੋ: ਕੌਣ ਇਨਾਮ ਪਾਉਂਦਾ, ਕੀ ਫਾਲੋ-ਅਪ ਚਾਹੀਦਾ, ਅਤੇ ਨੰਬਰ ਸਿਹਤਮੰਦ ਹਨ ਕਿ ਨਹੀਂ।
ਇੱਕ ਸਧਾਰਨ ਡੈਸ਼ਬੋਰਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰ ਸਵੇਰੇ ਇੱਕ ਓਪਰੇਟਰ ਦੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:
ਚਾਰਟਸ ਹਲਕੇ ਰੱਖੋ—ਸਪਸ਼ਟਤਾ ਜੇਗਾ-ਹੇਠਾਂ complexity ਨੂੰ।
ਹਰ ਰੈਫਰਲ ਲਈ ਇੱਕ ਡ੍ਰਿਲ-ਡਾਊਨ ਪੰਨਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ:
clicked → signed up → qualified → rewarded)ਇਸ ਨਾਲ ਸਪੋਰਟ ਟਿਕਟਾਂ ਦਾ ਹੱਲ ਆਸਾਨ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਲੋਗਜ਼ ਵਿੱਚ ਖੰਗਾਲ ਬਿਨਾਂ ਨਤੀਜੇ ਸਮਝਾ ਸਕਦੇ ਹੋ।
ਹਰ advocate ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਸੰਪਰਕ ਜਾਣਕਾਰੀ, ਉਹਨਾਂ ਦੀ ਰੈਫਰਲ ਲਿੰਕ/ਕੋਡ, ਪੂਰਾ ਇਤਿਹਾਸ, ਅਤੇ ਨੋਟਸ ਤੇ ਟੈਗਸ (ਜਿਵੇਂ “VIP”, “needs outreach”, “partner”) ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਓਥੇ ਹੀ ਹੈ ਜਿੱਥੇ ਮੈਨੂਅਲ ਸਮਰਥਨ/ਸੰਸ਼ੋਧਨ ਅਤੇ ਸੰਚਾਰ ਟ੍ਰੈਕਿੰਗ ਲਈ ਠੀਕ ਜਗ੍ਹਾ ਹੁੰਦੀ ਹੈ।
Advocates, referrals, ਅਤੇ rewards ਲਈ ਬੁਨਿਆਦੀ CSV ਐਕਸਪੋਰਟ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਟੀਮਾਂ ਰਿਪੋਰਟ ਜਾਂ reconciliation ਲਈ ਵਰਤ ਸਕਣ।
ਰੋਲ-ਆਧਾਰਿਤ ਪੁੱਜ ਲਾਗੂ ਕਰੋ: admin (edit, approve, pay out) ਅਤੇ read-only (view, export)। ਇਸ ਨਾਲ ਗਲਤੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਸਹੀ ਲੋਕਾਂ ਤੱਕ ਹੀ ਸੀਮਤ ਰਹਿੰਦੀ ਹੈ।
ਇਨਾਮ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਅਡਵੋਕੇਟਾਂ ਲਈ “ਅਸਲ” ਬਣਦਾ ਹੈ—ਅਤੇ ਜਿੱਥੇ ਆਪਰੇਸ਼ਨਲ ਗਲਤੀਆਂ ਮਹਿੰਗੀਆਂ ਪੈ ਸਕਦੀਆਂ ਹਨ। ਇਨਾਮਾਂ ਨੂੰ ਪਹਿਲੇ-ਸ਼੍ਰੇਣੀ ਫੀਚਰ ਵਜੋਂ ਸਲੋਕੋ, ਨਾ ਕਿ ਕੁਝ ਖੇਤਰੀ ਫੀਲਡਾਂ ਨੂੰ ਜੋੜਕੇ।
ਆਮ ਚੋਣਾਂ ਵਿੱਚ ਡਿਸਕਾਰੰਟ, ਗਿਫਟ ਕਾਰਡ, ਅਕਾਊਂਟ ਕਰੈਡਿਟ, ਅਤੇ (ਜਿੱਥੇ ਲਾਗੂ) ਨਕਦ ਸ਼ਾਮਲ ਹਨ। ਹਰ ਕਿਸਮ ਦੇ ਇੱਕੋ ਵਿਭਿੰਨ ਫੁਲਫਿਲਮੈਂਟ ਕਦਮ ਅਤੇ ਰਿਸਕ ਹੁੰਦੇ ਹਨ:
ਇੱਕ ਸਾਂਝਾ state machine ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਕਿ ਹਰ ਕੋਈ (ਦਰਅਸਲ ਤੁਹਾਡੀ ਕੋਡ ਵੀ) ਸਮਝਦਾ ਹੋਵੇ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ:
eligible → pending verification → approved → fulfilled → paid
ਹਰ ਇਨਾਮ ਨੂੰ ਹਰ ਕਦਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ, ਪਰ ਤੁਹਾਨੂੰ ਉਨਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਡਿਸਕਾਰੰਟ ਤੁਰੰਤ approved → fulfilled ਹੋ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਨਕਦ ਲਈ fulfilled → paid ਤੋਂ ਬਾਅਦ ਪੇਆਊਟ ਪੁਸ਼ਟੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਇਨਾਮ ਨੂੰ ਤੇਜ਼ ਰੱਖਣ ਲਈ ਆਟੋਮੈਟਿਕ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸੈੱਟ ਕਰੋ (ਉਦਾਹਰਨ: ਇੱਕ ਨਿਰਧਾਰਿਤ ਮੁੱਲ ਤੋਂ ਹੇਠਾਂ ਆਟੋ-ਅਪ੍ਰੂਵ). ਉੱਚ ਮੁੱਲ, ਅਸਧਾਰਨ ਗਤੀਵਿਧੀ, ਜਾਂ enterprise ਖਾਤਿਆਂ ਲਈ ਮੈਨੂਅਲ ਸਮੀਖਿਆ ਰੱਖੋ।
ਪਿਆਸਲ ਅਪ੍ਰੋਚ: “ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਆਟੋ-ਅਪ੍ਰੂਵ, ਨਿਯਮਾਂ ਦੁਆਰਾ ਐਸਕਲੇਟ ਕਰੋ।” ਇਹ ਅਡਵੋਕੇਟਾਂ ਨੂੰ ਖੁਸ਼ ਰੱਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਬਜਟ ਦੀ ਰੱਖਿਆ ਵੀ ਕਰਦਾ ਹੈ।
ਹਰ ਮਨਜ਼ੂਰੀ, ਸੋਧ, ਰਿਵਰਸਲ ਜਾਂ ਫੁਲਫਿਲਮੈਂਟ ਕਾਰਵਾਈ ਇੱਕ ਆਡਿਟ ਇਵੈਂਟ ਲਿਖੇ: ਕਿਸ ਨੇ ਇਸ ਨੂੰ ਬਦਲਿਆ, ਕੀ ਬਦਲਿਆ, ਅਤੇ ਕਦੋਂ। ਆਡਿਟ ਲੋਗ ਵਿਵਾਦ ਹਲ ਕਰਨ ਵਿੱਚ ਆਸਾਨੀ ਪੈਦਾ ਕਰਦੇ ਹਨ ਅਤੇ duplicated payouts ਜਾਂ ਗਲਤ ਨਿਯਮਾਂ ਦੀ ਡੀਬੱਗਿੰਗ ਵਿੱਚ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ।
ਇਹ ਆਡਿਟ ਟਰੇਲ récompense detail ਸਕ੍ਰੀਨ ਨਾਲ ਲਿੰਕ ਕਰੋ ਤਾਂ ਕਿ ਸਪੋਰਟ ਨਿਰਿਆਤਾਂ ਬਿਨਾਂ engineering ਦੀ ਮਦਦ ਦੇ ਸਮਾਧਾਨ ਦੇ ਸਕੇ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਤੁਹਾਡੇ ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਵੈੱਬ ਐਪ ਨੂੰ “ਹੋਰ ਇੱਕ ਉਪਕਰਨ” ਤੋਂ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਲਕੜੀ-ਮਕਸਦ ਸਾਦਾ ਹੈ: ਅਸਲ ਉਤਪਾਦ ਕਾਰਵਾਈਆਂ ਨੂੰ ਕੈਪਚਰ ਕਰੋ, ਗਾਹਕ ਰਿਕਾਰਡ ਸਹੀ ਰੱਖੋ, ਅਤੇ ਜੋ ਹੋ ਰਿਹਾ ਹੈ ਉਸ ਬਾਰੇ ਆਪੋ-ਆਪ ਸੁਨੇਹੇ ਭੇਜੋ—ਬਿਨਾਂ ਮੈਨੂਅਲ ਨਕਲ-ਪੇਸਟ ਦੇ।
ਸ਼ੁਰੂਆਤ ਉਹਨਾਂ ਇਵੈਂਟਾਂ ਨਾਲ ਕਰੋ ਜੋ ਵਾਕਈ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਦੀ ਸਫਲਤਾ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ: account created, subscription started, order paid)। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇਹ webhook ਜਾਂ ਇਵੈਂਟ-ਟ੍ਰੈਕਿੰਗ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਕਰਦੀਆਂ ਹਨ।
ਇਵੈਂਟ ਸੰਧਿ ਛੋਟੀ ਰੱਖੋ: ਇਕ external user/customer ID, event name, timestamp, ਅਤੇ ਕੋਈ ਸਬੰਧਤ ਮੁੱਲ (plan, revenue, currency)। ਇਹ attribution ਅਤੇ reward eligibility ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਟਰਿੱਗਰ ਕਰਨ ਲਈ ਕਾਫੀ ਹੁੰਦਾ ਹੈ।
{
"event": "purchase_completed",
"user_id": "usr_123",
"occurred_at": "2025-12-26T10:12:00Z",
"value": 99,
"currency": "USD"
}
ਜੇ ਤੁਸੀਂ CRM ਵਰਤਦੇ ਹੋ, ਤਾਂ ਲੋਕਾਂ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਪਛਾਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਫਿਲਡ ਸਿੰਕ ਕਰੋ (contact ID, email, company, deal stage, revenue)। ਪਹਿਲੇ ਦਿਨ ਹਰ custom property ਨੂੰ ਮੈਪ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ।
ਆਪਣੀ field mapping ਨੂੰ ਇੱਕ ਥਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਐਕ ਸੌਦਾ ਸਮਝੋ: ਕਿਹੜਾ ਸਿਸਟਮ email ਦਾ “source of truth” ਹੈ, ਕੰਪਨੀ ਦਾ ਨਾਮ ਕੌਣ ਰੱਖਦਾ ਹੈ, duplicates ਕਿਵੇਂ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ contact merge ਹੋਣ ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।
ਉਹ ਸੁਨੇਹੇ ਆਟੋਮੇਟ ਕਰੋ ਜੋ ਸਪੋਰਟ ਟਿਕਟ ਘਟਾਉਂਦੇ ਅਤੇ ਭਰੋਸਾ ਵਧਾਉਂਦੇ ਹਨ:
ਖਿੱਚ-ਬਿੰਦੂਆਂ ਨਾਲ templates ਵਰਤੋ (first name, referral link, reward amount) ਤਾਂ ਕਿ ਟੋਨ ਚੈਨਲਾਂ ਵਿੱਚ ਸਥਿਰ ਰਹੇ।
ਜੇ ਤੁਸੀਂ pre-built connectors ਜਾਂ managed plans ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਪੜਚੋਲ ਸਹਾਇਕ ਹੁੰਦੀ ਹੈ ਕਿ /integrations ਅਤੇ /pricing ਵਰਗੇ ਪ੍ਰੋਡਕਟ ਪੰਨਿਆਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਵੇ—ਬੱਸ ਤੇ linking ਨਾ ਜੋੜੋ, ਕੇਵਲ ਦਿੱਖਾਨੁਮਾ ਲਿਖਤ ਰੱਖੋ।
ਐਨਾਲਿਟਿਕਸ ਨੂੰ ਇਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: “ਕੀ ਪ੍ਰੋਗਰਾਮ ਵਧੀਆ ਢੰਗ ਨਾਲ ਇੰਕ੍ਰੀਮੈਂਟਲ ਰੇਵਨਿਊ ਬਣਾਉਂਦਾ ਹੈ?” ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪੂਰੇ ਫਨਲ ਨੂੰ ਟਰੈਕ ਕਰੋ, ਸਿਰਫ਼ shares ਜਾਂ clicks ਨਹੀਂ।
ਉਹ ਮੈਟਰਿਕ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ ਜੋ ਅਸਲ ਨਤੀਜੇ ਨਕਸ਼ੇ ਕਰਦੇ ਹਨ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ referrals ਕਿੱਥੇ ਰੁਕਦੇ ਹਨ (ਉਦਾਹਰਨ: ਜ਼ਿਆਦਾ clicks ਪਰ ਘੱਟ qualified leads ਆਮ ਤੌਰ ਤੇ ਟਾਰਗੇਟਿੰਗ ਜਾਂ ਓਫਰ ਅਨੁਕੂਲਤਾ ਦੀ ਸਮੱਸਿਆ ਦਿਖਾਉਂਦਾ ਹੈ)। ਹਰ ਕਦਮ ਦੀ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਉਦਾਹਰਨ: “qualified” ਕੀ ਗਿਣੀ ਜਾਂਦੀ ਹੈ, ਕਿਹੜੀ ਵਿੰਡੋ purchase ਨੂੰ ਯੋਗ ਮੰਨਦੀ ਹੈ)।
ਹਰ ਕੋਰ ਚਾਰਟ ਵਿੱਚ ਸੈਗਮੈਂਟੇਸ਼ਨ ਬਣਾਉ ਤਾਂ ਜੋ ਸਟੇਕਹੋਲਡਰ ਪੈਟਰਨ ਤੇਜ਼ੀ ਨਾਲ ਦੇਖ ਸਕਣ:
ਸੈਗਮੈਂਟ ਇਹ ਬਦਲ ਦਿੰਦੇ ਹਨ ਕਿ “ਪ੍ਰੋਗਰਾਮ ਡਾਊਨ ਹੈ” ਤੋਂ “ਸੋਸ਼ਲ referrals ਚੰਗੇ ਰੂਪ ਵਿੱਚ convert ਕਰਦੇ ਹਨ ਪਰ ਘੱਟ ਰਿਟੈਨਸ਼ਨ ਰੱਖਦੇ ਹਨ,” ਜੋ ਕਾਰਵਾਈਯੋਗ ਹੈ।
“ਕੁੱਲ shares” ਵਰਗੇ ਵੈਨਿਟੀ ਨੰਬਰਾਂ ਤੋਂ ਪਰਹੇਜ਼ ਕਰੋ ਜਦ ਤੱਕ ਉਹ ਰੇਵਨਿਊ ਨਾਲ ਜੁੜੇ ਨਾ ਹੋਣ। ਚੰਗੇ ਡੈਸ਼ਬੋਰਡ ਸਵਾਲ ਹਨ:
ਸਰਲ ROI ਵੇਖੋ: attributed revenue, reward cost, operational cost (ਵਿਕਲਪਕ), ਅਤੇ net value।
ਆਟੋਮੇਟਿਕ ਅੱਪਡੇਟ ਬਣਾਓ ਤਾਂ ਕਿ ਪ੍ਰੋਗਰਾਮ ਬਿਨਾਂ ਮੈਨੂਅਲ ਕੰਮ ਦੇ ਦ੍ਰਸ਼ਯਮਾਨ ਰਹੇ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਕ ਰਿਪੋਰਟਿੰਗ ਹੱਬ ਹੈ, ਤਾਂ admin ਖੇਤਰ ਤੋਂ ਉਸਦਾ ਰਫਰੈਂਸ (ਜਿਵੇਂ /reports) ਦਿਖਾਓ ਤਾਂ ਟੀਮਾਂ ਖੁਦ-ਸੇਵਾ ਕਰ ਸਕਣ।
ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਮਾਨਦਾਰ advocates ਮਹਿਸੂਸ ਕਰਨ ਕਿ ਉਹ “gaming” ਤੋਂ ਬਚਾਏ ਗਏ ਹਨ। ਫਰੌਡ ਕੰਟਰੋਲਜ਼ ਨੂੰ ਜ਼ਿਆਦਾ ਕਠੋਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ—ਉਹਨਾਂ ਨੂੰ ਸੂਥਰੇ ਤਰੀਕੇ ਨਾਲ ਸਪੱਸ਼ਟ ਦੁਰੁਪਯੋਗ ਨੂੰ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਕਿ ਜਾਇਜ਼ referrals ਆਸਾਨੀ ਨਾਲ ਬਹਿ ਰਹੇ ਹਨ।
ਅਕਸਰ ਜੋ ਮੁੱਦੇ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
ਸਧਾਰਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਜਿੱਥੇ ਅਸਲ ਦੁਰੁਪਯੋਗ ਦੇਖੋ ਉਦੋਂ ਕਆਈ ਕਨ سخت ਕਰੋ।
ਐਡਮਿਨ ਇਲਾਕੇ ਵਿੱਚ ਮੈਨੂਅਲ ਫਲੈਗਸ ਦਿੱਤੀਆਂ ਜਾਣ ਤਾਂ ਕਿ support engineering ਦੀ ਮਦਦ ਬਿਨਾਂ ਕਾਰਵਾਈ ਕਰ ਸਕੇ।
“Trust, but verify” ਦਾ ਸਾਫ਼ ਅਪ੍ਰੋਚ ਲਗਾਉ:
ਜਦੋਂ ਕੁਝ ਸ਼ੱਕਜਨਕ ਲੱਗੇ, ਉਸ ਨੂੰ auto-reject ਕਰਨ ਦੀ ਥਾਂ review queue ਵੱਲ ਭੇਜੋ। ਇਸ ਨਾਲ ਸਾਂਝੇ ਘਰ, ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕ ਜਾਂ ਵਾਜਬ ਏਜਕੇਸ ਕਾਰਨਾਂ ਕਰਕੇ ਸਹੀ ਅਡਵੋਕੇਟਾਂ ਨੂੰ ਸਜ਼ਾ ਹੋਣ ਤੋਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ।
ਰੈਫਰਲ ਟਰੈਕਿੰਗ ਨਿੱਜੀ ਤਰੀਕੇ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਅਡਵੋਕੇਟ ਨੂੰ ਉਸਨੇ ਨਿਯੋਤਾ ਦਿੱਤੇ ਵਿਅਕਤੀ ਨਾਲ ਜੋੜ ਰਹੇ ਹੋ। ਪ੍ਰਾਈਵੇਸੀ ਨੂੰ ਇਕ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਸਮਝੋ, ਕੇਵਲ ਕਾਨੂੰਨੀ ਮਾਮਲਾ ਨਾਂ ਬਣਾਓ।
ਸ਼ੁਰੂ ਵਿੱਚ ਉਹ ਘੱਟੋ-ਘੱਟ ਫੀਲਡ ਲਿਸਟ ਕਰੋ ਜੋ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦੇ ਹਨ (ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ)। ਬਹੁਤ ਟੀਮਾਂ ਇਹਨਾਂ ਨਾਲ ਚਲ ਸਕਦੀਆਂ ਹਨ: advocate ID/email, referral link ਜਾਂ code, referred user identifier, timestamps, ਅਤੇ reward status।
Retention ਪੀਰੀਅਡ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਰਵਾਇਤ ਹੋ ਸਕਦੀ ਹੈ:
ਸਹਿਮਤੀ ਚੈਕਬਾਕਸ ਉਚਿਤ ਪਲਾਂ 'ਤੇ ਸ਼ਾਮਲ ਕਰੋ:
termsReadable ਅਤੇ ਨੇੜੇ ਉਪਰ ਲਿੰਕ ਰੱਖੋ (ਜਿਵੇਂ /terms ਅਤੇ /privacy), ਅਤੇ eligibility, reward caps, ਜਾਂ approval delays ਵਰਗੀਆਂ ਮੁੱਖ ਸ਼ਰਤਾਂ ਨੂੰ ਛੁਪਾਓ ਨਾ।
ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕਿਹੜੇ ਰੋਲ advocate ਅਤੇ referred-user ਵੇਰਵੇ ਵੇਖ ਸਕਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਰੋਲ-ਆਧਾਰਿਤ ਪੁੱਜ ਲਾਭਦਾਇਕ ਹੈ:
ਐਕਸਪੋਰਟ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਪਹੁੰਚ ਲਾਗਜ਼ ਕਰੋ।
Privacy rights request (GDPR/UK GDPR, CCPA/CPRA, ਅਤੇ ਸਥਾਨਕ ਨਿਯਮਾਂ) ਲਈ ਸਧਾਰਨ ਪ੍ਰਕਿਰਿਆ ਬਣਾਓ: ਪਹਿਚਾਣ ਸਾਬਤ ਕਰੋ, ਨਿੱਜੀ ਪਛਾਣ-ਕਰਤਾ ਹਟਾਓ, ਅਤੇ ਸਿਰਫ਼ ਉਹ ਰੱਖੋ ਜੋ ਅਕਾਉਂਟਿੰਗ ਜਾਂ ਫਰੌਡ ਰੋਕਥਾਮ ਲਈ ਜਰੂਰੀ ਹੋ—ਸਾਫ਼ ਨਿਸ਼ਾਨ ਲਾ ਕੇ ਅਤੇ ਸਮੇਂ-ਸੀਮਿਤ ਰੱਖੋ।
ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਵੈੱਬ ਐਪ ਨੂੰ ਕਿਸੇ ਅਜੀਬੋ-ਗਰੀਬ ਸਟੈਕ ਦੀ ਲੋੜ ਨਹੀਂ। ਮਨੋਰਥ predictable development, ਆਸਾਨ ਹੋਸਟੀੰਗ, ਅਤੇ ਘੱਟ ਮੂਵੇਂਗ ਪਾਰਟਸ ਹਨ।
ਜੇ ਤੁਸੀਂ ਛੋਟੀ ਟੀਮ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ vibe-coding ਪਲੈਟਫ਼ਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ (ਅਡਮਿਨ ਡੈਸ਼ਬੋਰਡ, ਕੋਰ ਵਰਕਫਲੋ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਲਈ ਚੈਟ-ਚਲਤ ਵਿਸ਼ੇਸ਼ਤਾ), ਫਿਰ ਵੀ ਅਸਲੀ ਉਤਪਾਦ ਕੋਡ (React frontend, Go + PostgreSQL backend) ਨਿਰਯਾਤ ਕਰਨ ਦੀ ਸਮਰਥਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਡਿਪਲੌਏਮੈਂਟ/ਹੋਸਟਿੰਗ ਅਤੇ snapshots ਦੁਆਰਾ rollback ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ।
Frontend ਉਹ ਹੈ ਜੋ admins ਅਤੇ advocates ਵੇਖਦੇ ਹਨ: ਫਾਰਮ, ਡੈਸ਼ਬੋਰਡ, ਰੈਫਰਲ ਲਿੰਕ ਅਤੇ ਸਥਿਤੀ ਪੰਨੇ।
Backend ਨਿਯਮਾਂ ਅਤੇ ਰਿਕਾਰਡ-ਕੀਪਰ ਹੈ: ਇਹ advocates ਅਤੇ referrals ਸਟੋਰ ਕਰਦਾ, attribution ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ, ਇਵੈਂਟ ਸਤਿ�ਮਿਤ ਕਰਦਾ, ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਕਿ ਕਦੋਂ ਇਨਾਮ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਚੰਗੀ ਤਰ੍ਹਾਂ customer advocacy ਟ੍ਰੈਕਿੰਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ “ਸਚ” backend 'ਤੇ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
Authentication (ਤੁਸੀਂ ਕੌਣ ਹੋ?), authorization (ਤੁਸੀਂ ਕੀ ਕਰਨ ਯੋਗ ਹੋ?), ਅਤੇ encryption in transit (HTTPS ਹਰ ਜਗ੍ਹਾ) ਲਾਜ਼ਮੀ ਰੱਖੋ।
ਸਿਕ੍ਰੇਟਸ (API ਕੁੰਜੀਆਂ, webhook signing secrets) proper secrets manager ਜਾਂ host ਦੇ encrypted env vars ਵਿੱਚ ਰੱਖੋ—ਕਦੇ ਵੀ ਕੋਡ ਜਾਂ client-side ਫਾਈਲਾਂ ਵਿੱਚ ਨਾ ਰੱਖੋ।
Attribution logic ਲਈ unit tests ਲਿਖੋ (ਉਦਾਹਰਨ: last-touch vs first-touch, self-referrals blocked)। ਕੋਰ referral flow ਲਈ end-to-end tests ਸ਼ਾਮਲ ਕਰੋ: create advocate → share link → signup/purchase → reward eligibility → admin approval/denial।
ਇਸ ਨਾਲ ਤੁਸੀਂ ਆਪਣਾ ਵਧਾਉਂਦੇ ਸਮੇਂ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਰੱਖ ਸਕਦੇ ਹੋ।
ਇੱਕ ਰੈਫਰਲ ਪ੍ਰੋਗਰਾਮ ਵੈੱਬ ਐਪ ਪਹਿਲੇ ਦਿਨ 'ਤੇ ਪਰਫੈਕਟ ਨਹੀਂ ਹੁੰਦਾ। ਸਬ ਤੋਂ ਵਧੀਆ ਅਭਿਗਮ ਨਿਯੰਤਰਿਤ ਕਦਮਾਂ ਵਿੱਚ ਲਾਂਚ ਕਰਨਾ, ਅਸਲ ਵਰਤੋਂ ਦੇ ਸਿਗਨਲ ਇਕੱਠੇ ਕਰਨਾ, ਅਤੇ ਛੋਟੇ ਸੁਧਾਰ ਭੇਜਣਾ ਹੈ ਜੋ ਦੋਹਾਂ ਲਈ ਟਰੈਕਿੰਗ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ: advocates ਅਤੇ admins।
ਬੁਨਿਆਦੀ ਹਾਲਤਾਂ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ ਟੈਸਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: referral links, attribution, reward automation, ਅਤੇ admin ਕਾਰਵਾਈਆਂ। ਫਿਰ 20–50 ਭਰੋਸੇਯੋਗ ਗਾਹਕਾਂ ਦੀ ਛੋਟੀ cohort ਵਿੱਚ ਜਾਓ ਪਹਿਲਾਂ ਫਿਰ ਫੁੱਲ ਲਾਂਚ।
ਹਰ ਪੜਾਅ ਵਿੱਚ ਇੱਕ “go/no-go” ਚੈੱਕਲਿਸਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਕੀ referrals ਸਹੀ ਰਿਕਾਰਡ ਹੋ ਰਹੇ ਹਨ, ਕਿਆ ਇਨਾਮ ਜ਼ੋੜੇ ਜਾ ਰਹੇ ਹਨ ਜਿਵੇਂ ਉਮੀਦ ਸੀ, ਅਤੇ ਕੀ support ਆਸਾਨੀ ਨਾਲ ਐਜ਼ਕੇਸ ਹੱਲ ਕਰ ਰਿਹਾ ਹੈ? ਇਸ ਨਾਲ ਤੁਹਾਡਾ ਰੈਫਰਲ ਟ੍ਰੈਕਿੰਗ ਸਿਸਟਮ ਇਸਤੋਂ ਬਾਅਦ ਵੀ ਸਥਿਰ ਰਹੇਗਾ ਜਦੋਂ ਵਰਤੋਂ ਵਧੇਗੀ।
ਸਿਰਫ਼ gut ਮੈਸੂਸ ਨਾ ਕਰੋ। ਸਿੱਖਣ ਲਈ ਸੰਗਠਿਤ ਤਰੀਕੇ ਬਣਾਓ:
ਫਿਰ ਇਨ੍ਹਾਂ ਨੂੰ ਹਫਤਾਵਾਰ referral analytics ਨਾਲ ਰਿਵਿਊ ਕਰੋ ਤਾਂ ਕਿ ਫੀਡਬੈਕ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲੇ।
ਜਦੋਂ MVP ਮਜ਼ਬੂਤ ਹੋ ਜਾਵੇ, ਤਾਂ ਉਹ ਫੀਚਰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ ਜੋ ਮੈਨੂਅਲ ਕੰਮ ਘੱਟ ਕਰਨ ਅਤੇ ਭਾਗੀਦਾਰੀ ਵਧਾਉਣ। ਆਮ ਅਗਲੇ ਕਦਮਾਂ ਵਿੱਚ ਟਾਇਰਡ ਇਨਾਮ, ਬਹੁ-ਭਾਸ਼ਾ ਸਹਾਇਤਾ, ਹੋਰ-ਸੁਪੂਰਨ ਸੈਲਫ-ਸਰਵ ਪੋਰਟਲ, ਅਤੇ CRM ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਲਈ API ਰਾਹ ਹੋ ਸਕਦੇ ਹਨ।
Phase 2 ਫੀਚਰਾਂ ਨੂੰ feature flags ਦੇ ਪਿੱਛੇ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਚੁਣੀਂਦਾ ਸਮੂਹ ਤੇ ਪਰੀਖਣ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕੋ।
ਜੇ ਤੁਸੀਂ ਪਬਲਿਕ ਤੌਰ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਅਪਣੀ ਅਪਣਾ ਪ੍ਰਚਾਰ ਕਰਨ ਅਤੇ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਪ੍ਰੋਸਾਹਨ ਦੇਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ: ਉਦਾਹਰਨ ਲਈ, Koder.ai ਇੱਕ “earn credits” ਪ੍ਰੋਗਰਾਮ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਸਮੱਗਰੀ ਬਣਾਉਣ ਜਾਂ ਇੱਕ ਰੈਫਰਲ ਲਿੰਕ ਰਾਹੀਂ ਇਨਾਮ ਮਿਲਦੇ ਹਨ—ਇਹੀ ਤਰ੍ਹਾਂ ਦੇ ਅਡਵੋਕੇਟ-ਪ੍ਰਬੰਧਨ ਨਿਯਮਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਐਪ ਵਿੱਚ ਲਾਗੂ ਕਰ ਰਹੇ ਹੋ।
ਵਹ ਫਲ-ਨਤੀਜਿਆਂ ਨੂੰ ਟਰੈਕ ਕਰੋ ਜੋ ROI ਦਰਸਾਉਂਦੇ ਹਨ, ਸਿਰਫ਼ ਸਰਗਰਮੀ ਨਹੀਂ: source ਅਨੁਸਾਰ conversion rate, time-to-first-referral, cost per acquired customer, ਅਤੇ reward cost ਤੋਂ revenue ਦਾ ਪ੍ਰਤੀਸ਼ਤ।
ਜੇ ਪ੍ਰਦਰਸ਼ਨ ਬਲਦਾਰ ਹੈ, ਤਾਂ ਗਾਹਕਾਂ ਤੋਂ ਬਾਹਰ ਭਾਗੀਦਾਰਾਂ ਜਾਂ affiliates ਤੱਕ ਵਧਾਉਣ ਬਾਰੇ ਸੋਚੋ—ਪਰ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਤੱਕ ਜਦੋਂ ਤੁਸੀਂ ਪੱਕਾ ਕਰ ਲਓ ਕਿ attribution, fraud prevention referrals, ਅਤੇ privacy and consent ਸੰਭਾਲਵਾਲੇ ਤੰਗੀਆਂ ਸਾਫ਼ ਅਤੇ ਸਕੇਲ ਕਰਨਯੋਗ ਹਨ।
ਆਪਣੇ ਕਾਰੋਬਾਰ ਲਈ “ਐਡੋਕੇਸੀ” ਵਿੱਚ ਕੀ-ਕੀ ਸ਼ਾਮਲ ਹੈ (ਸਿਰਫ਼ ਰੈਫਰਲ ਹੀ ਜਾਂ ਸਮੀਖਿਆਵਾਂ, ਟੈਸਟਿਮੋਨੀਅਲ, ਕਮਿਊਨਿਟੀ ਭਾਗੀਦਾਰੀ, ਸਮਾਰੋਹ ਵਿਚ ਬੋਲਣਾ ਆਦਿ) ਨੂੰ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਫਿਰ 1–2 ਮੁੱਖ ਲਕੜੀ-ਨਤੀਜੇ ਚੁਣੋ (ਉਦਾਹਰਨ ਲਈ, ਯੋਗ ਰਾਹੀਂ ਲੀਡ, ਘਟਿਆ CAC, ਉੱਚ ਰਿਟੈਨਸ਼ਨ) ਅਤੇ ਮੈਟਰਿਕ ਪਰਿਭਾਸ਼ਾਵਾਂ ਜਲਦੀ ਲਾਕ ਕਰ ਦਿਓ (ਕਨਵਰਸ਼ਨ ਵਿੰਡੋ, ਰਿਫੰਡ ਹੈਂਡਲਿੰਗ, “ਪੇਡ” ਦੀ ਪਰਿਭਾਸ਼ਾ)।
ਉਹ ਮੈਟਰਿਕ ਸਿਲੈਕਟ ਕਰੋ ਜੋ ਐਪ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਹੀ ਗਿਣ ਸਕਦੀ ਹੈ:
(total rewards + fees) / new customers acquiredਸਪਸ਼ਟ ਹੁਨਰਾਂ ਨਾਲ ਨਿਯਮ ਲਿਖੋ, ਜਿਵੇਂ “30 ਦਿਨਾਂ ਵਿੱਚ ਕਨਵਰਟ” ਜਾਂ “ਪੇਡ ਵਿੱਚ ਰਿਫੰਡ/ਚਾਰਜਬੈਕ ਸ਼ਾਮਿਲ ਨਹੀਂ।”
ਤਿੰਨ ਮੁੱਖ ਭੂਮਿਕਾਵਾਂ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ:
ਇਸ ਨਾਲ ਇੱਕ ਐਪ ਬਣਦੀ ਹੈ ਜੋ ਸਿਰਫ਼ ਸੋਹਣਾ ਹੀ ਨਹੀਂ, ਪਰ ਦਿਨ-ਦਰ-ਦਿਨ ਚਲਾਉਣਯੋਗ ਵੀ ਹੁੰਦੀ ਹੈ।
v1 ਵਿੱਚ ਸਿਰਫ਼ ਉਹੀ ਚੀਜ਼ਾਂ ਲਿਆਓ ਜੋ ਕੋਰ ਲੂਪ ਨੂੰ ਸੰਚਾਲਿਤ ਕਰਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ ਪਿਲਟ ਨੂੰ spreadsheets ਤੋਂ ਬਿਨਾਂ ਚਲਾ ਸਕਦੇ ਹੋ ਤਾਂ ਤੁਹਾਡਾ MVP ਮੁਕੰਮਲ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਪੋਰਟਲ ਤੇਜ਼ੀ ਨਾਲ ਲਾਂਚ ਕਰਨ ਲਈ ਚੰਗਾ ਹੈ ਅਤੇ ਬਾਹਰਲੇ ਲੋਕਾਂ ਨਾਲ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਲੌਗਇਨ ਹਨ, ਤਾਂ ਐਂਬੈਡਡ ਅਨੁਭਵ friction ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਟ੍ਰੈਕਿੰਗ ਵਿੱਚ ਸੁਧਾਰ ਲਿਆਉਂਦਾ ਹੈ। ਬਹੁਤ ਟੀਮਾਂ ਪਹਿਲਾਂ standalone ਲਾਂਚ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ ਐਂਬੈਡ ਕਰਦੀਆਂ ਹਨ।
ਕੋਰ ਐਨਟਿਟੀਜ਼ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਮਾਡਲ ਕਰੋ:
“ਮੌਜੂਦਾ ਸਥਿਤੀ” ਫਿਲਡ ਰੱਖੋ (ਜਿਵੇਂ pending → approved → paid) ਅਤੇ ਪੂਰੀ ਇਤਿਹਾਸ Events ਵਜੋਂ ਸਟੋਰ ਕਰੋ। ਹਰ ਰਿਕਾਰਡ ਨੂੰ UUID ਅਤੇ timestamps ਦਿਓ ਤਾਂ ਜੋ ਆਡੀਟ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਆਸਾਨ ਹੋਵੇ।
ਕਿਉਂਕਿ ਰੈਫਰਲ ਇੱਕ ਟਾਈਮਲਾਈਨ ਹੁੰਦਾ ਹੈ, ਇਕ ਸਿੰਗਲ ਮੋਮੈਂਟ ਨਹੀਂ। ਉਦਾਹਰਨ ਲਈ ਇਵੈਂਟ ਕ੍ਰਮ:
click → signup → purchase → refundਇਸ ਨਾਲ attribution ਵਜੀਹ ਬਣਦੀ ਹੈ (ਜਿਵੇਂ “14 ਦਿਨਾਂ ਵਿੱਚ purchase ਹੋਈ”) ਅਤੇ ਕੈਂਸਲੇਸ਼ਨ, ਚਾਰਜਬੈਕ ਜਾਂ ਦੇਰ ਨਾਲ ਹੋਣ ਵਾਲੀਆਂ ਕਨਵਰਸ਼ਨਾਂ ਵਰਗੀਆਂ_EDGE_CASES ਨੂੰ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇਵੈਂਟ ਇੰਗੈਸ਼ਨ ਨੂੰ idempotent ਬਣਾਓ ਤਾਂ ਜੋ ਦੁਹਰਾਏ ਗਏ webhooks ਦੂਜਾ ਵਾਰੀ ਗਿਣਤੀ ਨਾ ਕਰਣ:
external_event_id ਅਤੇ source_system ਸਟੋਰ ਕਰੋ(source_system, external_event_id) 'ਤੇ uniqueness ਲਾਗੂ ਕਰੋਇਸ ਨਾਲ attribution totals ਅਤੇ duplicate rewards ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।
MVP ਲਈ attribution ਵਿਧੀਆਂ ਸਿਰਫ਼ 2–3 ਰੱਖੋ:
ਕਈ ਡਿਵਾਈਸ, ਕਈ ਕਲਿਕ ਅਤੇ ਦੇਰ ਨਾਲ ਹੋਣ ਵਾਲੀਆਂ ਕਨਵਰਸ਼ਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ—ਇੱਕ ਪ੍ਰਯੋਗੀ ਨਿਯਮ ਹੋ ਸਕਦਾ ਹੈ: conversion window ਸੈੱਟ ਕਰੋ, ਉਸ ਵਿੰਡੋ ਵਿੱਚ ਕਿਸੇ ਵੀ ਮਿਆਦ ਦੇ ਅੰਦਰ ਨਾਲੋਂ ਸਭ ਤੋਂ ਹਾਲੀਆ ਵੈਧ ਰੈਫਰਲ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਐਡਮਿਨ ਓਵਰਰਾਈਡ ਦੀ ਆਗਿਆ ਦਿਓ।
ਸਧਾਰਨ ਨਿਯੰਤਰਣ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਰੋਕਦੇ ਨਹੀਂ:
ਸ਼ਕ ਵਾਲੇ ਕੇਸਾਂ ਨੂੰ ਆਟੋ-ਰਿਜੈਕਟ ਕਰਨ ਦੀ ਥਾਂ review queue ਵਿੱਚ ਭੇਜੋ ਤਾਂ ਕਿ ਸਹੀ ਅਡਵੋਕੇਟਾਂ ਸਜ਼ਾ ਨਾ ਪਾਉਣ।