ਰੱਦਾਂ ਦੀ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਟੈਸਟ ਕਰਨ ਲਈ ਵੈੱਬ ਐਪ ਬਣਾਓ

ਤੁਸੀਂ ਕੀ ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਰੱਦ ਕਰਨਾ(subscription cancellations) ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਬਿਜ਼ਨਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਸੂਚਕਤਾ ਵਾਲੇ ਸਮਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਇੱਕ ਗਾਹਕ ਸਾਫ਼ ਸੂਚਾ ਦੇ ਰਿਹਾ ਹੁੰਦਾ ਹੈ: “ਇਹ ਹੁਣ ਲਾਭਕਾਰੀ ਨਹੀਂ ਰਹਿ ਗਿਆ,” ਅਕਸਰ ਉਸ ਸਮੇਂ ਜਦੋਂ ਉਹ ਕਿਸੇ friction, ਨਿਰਾਸ਼ਾ, ਜਾਂ ਕੀਮਤ/ਮੂਲ-ਮੈਚ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਰੱਦ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਥਿਤੀ ਬਦਲਾਅ ਸਮਝ ਕੇ ਪੇਸ਼ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਕਿੰਮਤੀ ਮੌਕਾ ਗੁਆਉਂਦੇ ਹੋ ਕਿ ਇਹ ਪਤਾ ਲਗੇ ਕਿ ਕੀ ਟੁੱਟ ਰਿਹਾ ਹੈ—ਅਤੇ ਇਸ ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾਵੇ।

ਤੁਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ حل ਕਰ ਰਹੇ ਹੋ

ਅਕਸਰ ਟੀਮਾਂ ਚਰਨ ਨੂੰ ਸਿਰਫ਼ ਮਹੀਨਾਵਾਰ ਨੰਬਰ ਵਜੋਂ ਵੇਖਦੀਆਂ ਹਨ। ਇਹ ਕਹਾਣੀ ਨੂੰ ਛੁਪਾ ਦਿੰਦਾ ਹੈ:

• ਕੌਣ ਰੱਦ ਕਰ ਰਿਹਾ ਹੈ (ਨਵੇਂ ਯੂਜ਼ਰ ਵਿਰੁੱਧ ਲੰਬੇ ਸਮੇਂ ਦੇ ਗਾਹਕ, ਪਲਾਨ ਦੀ ਕਿਸਮ, ਸੈਗਮੈਂਟ)
• ਕਦੋਂ ਉਹ ਰੱਦ ਕਰਦੇ ਹਨ (ਦਿਨ 1, ਟ੍ਰਾਇਲ ਤੋਂ ਬਾਅਦ, ਕੀਮਤ ਵਧਣ ਤੋਂ ਬਾਅਦ, ਅਸਫਲ ਭੁਗਤਾਨ ਦੇ ਬਾਅਦ)
• ਕਿਉਂ ਉਹ ਰੱਦ ਕਰਦੇ ਹਨ (ਬਹੁਤ ਮਹਿੰਗਾ, ਲੋੜੀਂਦੇ ਫੀਚਰ ਨਹੀਂ, ਬੱਗ, ਮੁਕਾਬਲੇ ਵਲ ਜਾਣਾ, “ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਰਿਹਾ”)

ਇਹੀ ਅਸਲ ਵਿੱਚ subscription cancellation analysis ਦਾ ਮਤਲਬ ਹੈ: ਇੱਕ ਰੱਦ ਕਰਨ ਦੇ ਕਲਿੱਕ ਨੂੰ ਢਾਂਚਾਬੱਧ ਡੇਟਾ ਵਿੱਚ ਬਦਲਨਾ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕੋ ਅਤੇ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਤੋੜ-ਮਰੋੜ ਸਕੋ।

“ਰਿਟੇਨਸ਼ਨ ਪ੍ਰਯੋਗ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ ਪੈਟਰਨ ਵੇਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਏ ਬਿਨਾਂ ਹੀ churn ਘਟਾਉਣ ਲਈ ਪਰਿਵਰਤਨ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ। ਰਿਟੇਨਸ਼ਨ ਪ੍ਰਯੋਗ ਉਤਪਾਦ, ਕੀਮਤ, ਜਾਂ ਸੰਦੇਸ਼ੀकरण ਵਿੱਚ ਬਦਲਾਅ ਹੋ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ:

• ਰੱਦ ਫਲੋ ਨੂੰ ਸੁਧਾਰਨਾ (ਸਪਸ਼ਟ ਵਿਕਲਪ, ਬਿਹਤਰ ਡਾਊਨਗਰੇਡ ਰਸਤੇ)
• “ਸਹੀ ਸੈਗਮੈਂਟ” ਨੂੰ ਇੱਕ ਰੋਕਣ ਯੋਜਨਾ ਜਾਂ ਛੂਟ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨਾ
• ਸ਼ੁਰੂਆਤੀ ਰੱਦਾਂ ਨਾਲ ਸੰਬੰਧਤ onboarding ਗੈਪ ਨੂੰ ਠੀਕ ਕਰਨਾ

ਮੁੱਖ ਗੱਲ ਹੈ ਪ੍ਰਭਾਵ ਦੀ ਮਾਪ-ਤੋਲ ਸਾਫ਼, ਤੁਲਨੀਯੋਗ ਡੇਟਾ ਨਾਲ ਕਰਨੀ (ਉਦਾਹਰਨ ਲਈ A/B ਟੈਸਟ)।

ਇਸ ਗਾਈਡ ਵਿੱਚ ਤੁਸੀਂ ਕੀ ਬਣਾਉਗੇ

ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਸਿਸਟਮ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਜੁੜੇ ਹਿੱਸੇ ਹੋਣਗੇ:

1. ਟ੍ਰੈਕਿੰਗ: ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲਾਈਫਸਾਇਕਲ ਅਤੇ cancellation ਫਲੋ ਦੇ ਆਸਪਾਸ ਇਵੈਂਟਸ, ਕਾਰਨਾਂ ਸਮੇਤ।
2. ਡੈਸ਼ਬੋਰਡ: ਫਨਲ, ਕੋਹੋਰਟ, ਅਤੇ ਸੈਗਮੈਂਟ ਜੋ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ churn ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈ।
3. ਪ੍ਰਯੋਗ ਚੱਕਰ: ਨਿਸ਼ਚਿਤ ਟੈਸਟ ਚਲਾਉਣ ਦੀ ਸਮਰੱਥਾ ਅਤੇ ਦੇਖਣਾ ਕਿ churn ਹਕੀਕਤ ਵਿੱਚ ਘਟਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਅਖੀਰ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵਰਕਫਲੋ ਹੋਵੇਗਾ ਜੋ “ਸਾਡੇ ਕੋਲ ਜ਼ਿਆਦਾ ਰੱਦ ਆਏ” ਤੋਂ ਲੈ ਕੇ “ਇਸ ਖਾਸ ਸੈਗਮੈਂਟ ਨੇ ਹਫਤੇ 2 ਤੋਂ ਬਾਅਦ X ਕਾਰਨ ਨਾਲ ਰੱਦ ਕੀਤਾ—ਅਤੇ ਇਸ ਬਦਲਾਅ ਨਾਲ churn Y% ਘਟਿਆ” ਵੱਲ ਜਾਂਦਾ ਹੈ।

ਸਫਲਤਾ ਕੀ ਦਿਸਦੀ ਹੈ

ਸਫਲਤਾ ਇੱਕ ਖੂਬਸੂਰਤ ਚਾਰਟ ਨਹੀਂ—ਇਹ ਗਤੀ ਅਤੇ ਭਰੋਸਾ ਹੈ:

• ਤੇਜ਼ ਸੂਝ (ਦਿਨਾਂ ਵਿੱਚ, ਮਹੀਨਿਆਂ ਨਹੀਂ)
• ਨਪਤਿਆ ਜਾ ਸਕਣ ਵਾਲਾ churn ਘਟਾਉਣਾ ਜੋ ਖਾਸ ਬਦਲਾਅ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ
• ਦੋਹਰਾਈ ਜਾਂ ਸਕਣ ਵਾਲੀ ਸਿੱਖ: ਹਰ ਰੱਦ ਤੁਹਾਨੂੰ ਕੁਝ ਸਿਖਾਉਂਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ

MVP ਲਈ ਲਕਸ਼, ਮੈਟਰਿਕਸ, ਅਤੇ ਸਕੋਪ ਨਿਰਧਾਰਤ ਕਰੋ

ਸਕਰੀਨ, ਟ੍ਰੈਕਿੰਗ, ਜਾਂ ਡੈਸ਼ਬੋਰਡ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਬਹੁਤ ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਇਹ MVP ਕਿਸ ਫੈਸਲਿਆਂ ਨੂੰ ਸੰਜੋਣ ਯੋਗ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ cancellation analytics ਐਪ ਤਦ ਹੀ ਕਾਮਯਾਬ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਕੁਝ ਉੱਚ-ਮੁੱਲ ਦੇ ਸਵਾਲਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦਿੰਦੀ ਹੈ—ਨਾਹ ਕਿ ਹਰ ਚੀਜ਼ ਮਾਪਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇ।

ਉਨ੍ਹਾਂ ਸਵਾਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਕਾਰਵਾਈ ਚਲਾਉਂਦੀਆਂ ਹਨ

ਉਨ੍ਹਾਂ ਸਵਾਲਾਂ ਨੂੰ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਵਿੱਚ ਜਵਾਬ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਚੰਗੇ MVP ਸਵਾਲ ਖਾਸ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸਪੱਸ਼ਟ ਅਗਲੇ ਕਦਮ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ:

• ਸਭ ਤੋਂ ਮੁੱਖ ਰੱਦ ਕਰਨ ਦੇ ਕਾਰਨ ਕੀ ਹਨ, ਅਤੇ ਇਹ ਪਲਾਨ, ਖੇਤਰ, ਜਾਂ ਸਾਇਨਅੱਪ ਚੈਨਲ ਦੇ ਨਾਲ ਕਿਵੇਂ ਵੱਖ-ਵੱਖ ਹੋਦੇ ਹਨ?
• ਗਾਹਕਾਂ ਨੂੰ ਰੱਦ ਕਰਨ ਵਿੱਚ ਲੱਗਦਾ ਸਮਾਂ ਕਿੰਨਾ ਹੈ (time-to-cancel), ਅਤੇ ਪਹਿਲੇ 7/30/90 ਦਿਨਾਂ ਵਿੱਚ ਕਿਹੜੇ pattern ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ?
• ਕਿਹੜੇ ਪਲਾਨ (ਜਾਂ ਬਿੱਲਿੰਗ ਸਰਗਰਮੀ) ਵਿੱਚ ਸਭ ਤੋਂ ਉੱਚਾ cancel ਰੇਟ ਹੈ, ਅਤੇ ਕੀ ਉਪਭੋਗੀ ਰੱਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਾਉਨਗਰੇਡ ਕਰ ਰਹੇ ਹਨ?

ਜੇ ਕਿਸੇ ਸਵਾਲ ਦਾ ਪ੍ਰਭਾਵ ਉਤਪਾਦੀ ਬਦਲਾਅ, ਸਪੋਰਟ ਪਲੇਬੁੱਕ, ਜਾਂ ਪ੍ਰਯੋਗ 'ਤੇ ਨਹੀਂ ਪੈਂਦਾ, ਤਾਂ ਉਸਨੂੰ ਬਾਅਦ ਲਈ ਰੱਖੋ।

3–5 “ਨੌਰਥ ਸਟਾਰ” MVP ਮੈਟਰਿਕਸ ਚੁਣੋ

ਹਫਤਾਵਾਰੀ ਸਮੀਖਿਆ ਲਈ ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਚੁਣੋ। ਪਰਿਭਾਸ਼ਾਵਾਂ ਅਸਪੱਸ਼ਟ ਨਾ ਰਹਿਣ—ਤਾਂ ਜੋ ਉਤਪਾਦ, ਸਪੋਰਟ, ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਸਭ ਇੱਕੋ ਨੰਬਰਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ।

ਆਮ ਸ਼ੁਰੂਆਤੀ ਮੈਟਰਿਕਸ:

• Cancel rate (ਇਕ ਨਿਰਧਾਰਿਤ ਅਵਧੀ ਵਿੱਚ, ਜਿਵੇਂ ਸਾਪਤਾਹਿਕ/ਮਾਸਿਕ)
• Save rate (ਰੱਦ ਦੀ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚੋਂ ਕਿੰਨੇ ਰਿਟੇਨ ਹੋ ਗਏ)
• Reactivation rate (ਜੋ ਗਾਹਕ ਰੱਦ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦੇ ਹਨ)
• Time-to-cancel (ਸ਼ੁਰੂ ਤੋਂ ਰੱਦ ਤੱਕ ਮੀਡਿਆਨ ਦਿਨ)
• Reason distribution (ਮੁੱਖ ਕਾਰਨ ਵਾਲੀ ਵਿਥਾਰ, ਹਵਾਲੇ ਤੋਂ ਆਮਦਨ ਪ੍ਰਭਾਵ ਨਾਲ)

ਹਰ ਮੈਟਰਿਕ ਲਈ ਸੁਧਾਰਤ ਫਾਰਮੂਲਾ, ਸਮੇਂ ਦੀ ਖਿੜਕੀ, ਅਤੇ ਬਾਹਰ ਰੱਖੇ ਜਾਣ ਵਾਲੇ ਕੇਸ (ਟ੍ਰਾਇਲ, ਰਿਫੰਡ, ਅਸਫਲ ਭੁਗਤਾਨ) ਲਿਖੋ।

ਮਲਿਕ ਅਤੇ ਪਾਬੰਦੀਆਂ ਨਾਮੋਨਿਸ਼ਾਨ ਕਰੋ

ਕੌਣ ਇਸ ਸਿਸਟਮ ਨੂੰ ਵਰਤੇਗਾ ਅਤੇ ਬਣਾਈ ਰੱਖੇਗਾ ਇਹ ਪਛਾਣੋ: ਉਤਪਾਦ (ਫੈਸਲੇ), ਸਪੋਰਟ/ਸਕਸ (ਕਾਰਨ ਦੀ ਗੁਣਵੱਤਾ ਅਤੇ ਫਾਲੋ-ਅਪ), ਡੇਟਾ (ਪਰਿਭਾਸ਼ਾਵਾਂ ਅਤੇ ਵੈਧਤਾ), ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ (ਇੰਸਟ੍ਰੂਮੇੰਟੇਸ਼ਨ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ)।

ਫਿਰ ਅੱਗੇ ਪਾਬੰਦੀਆਂ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ: ਪਰਾਈਵੇਸੀ ਲੋੜਾਂ (PII ਘਟਾਓ, ਰੱਖ-ਰਖਾਅ ਦੀਆਂ ਸੀਮਾਵਾਂ), ਲਾਜ਼ਮੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (ਬਿੱਲਿੰਗ ਪ੍ਰੋਵਾਇਡਰ, CRM, ਸਪੋਰਟ ਟੂਲ), ਟਾਈਮਲਾਈਨ, ਅਤੇ ਬਜਟ।

ਫੀਚਰ ਕ੍ਰਿਪ ਨੂੰ ਰੋਕਣ ਲਈ ਇਕ ਪੰਨਾ ਸਕੋਪ ਲਿਖੋ

ਇਹ ਛੋਟਾ ਰੱਖੋ: ਲਕਸ਼, ਮੁੱਖ ਉਪਭੋਗੀ, 3–5 ਮੈਟਰਿਕਸ, “ਜ਼ਰੂਰੀ-ਹੋਣਾ” ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਗੈਰ-ਲਕਸ਼ ਸੂਚੀ (ਜਿਵੇਂ, “v1 ਵਿੱਚ ਕੋਈ ਪੂਰਾ BI ਸੂਟ ਨਹੀਂ”, “v1 ਵਿੱਚ multi-touch attribution ਨਹੀਂ”)। ਜਦੋਂ ਨਵੇਂ ਬੇਨਤੀ ਆਉਂਦੀਆਂ ਹਨ, ਇਹ ਇਕ ਪੰਨਾ ਤੁਹਾਡੇ MVP ਦਾ ਕਾਂਟਰੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ।

ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਲਾਈਫਸਾਇਕਲ ਇਵੈਂਟਸ ਦੀ ਮਾਡਲਿੰਗ ਕਰੋ

ਰੱਦਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ ਜੋ ਦਰਸਾਏ ਕਿ ਗਾਹਕ ਹਕੀਕਤ ਵਿੱਚ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਕਿਵੇਂ ਲੰਘਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਡੇਟਾ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਥਿਤੀ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਸਮੇਂ ਮੁਸ਼ਕਲ ਆਏਗੀ, ਜਿਵੇਂ “ਉਹ ਰੱਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿੰਨਾ ਸਮਾਂ ਸਰਗਰਮ ਰਹੇ?” ਜਾਂ “ਕੀ ਡਾਊਨਗਰੇਡਸ churn ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦੇ ਸਨ?”

ਤੁਸੀਂ ਜੋ ਮਾਪੋਗੇ ਉਸ ਲਾਈਫਸਾਇਕਲ ਨੂੰ ਨਕਸ਼ਾ ਬਨਾਓ

ਸਧਾਰਣ, ਸਪਸ਼ਟ ਲਾਈਫਸਾਇਕਲ ਨਕਸ਼ਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ 'ਤੇ ਸਾਰੀ ਟੀਮ ਸਹਿਮਤ ਹੋਵੇ:

Trial → Active → Downgrade → Cancel → Win-back

ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਸਥਿਤੀਆਂ ਜੋੜ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਮੂਲ ਲੜੀ ਇਹ ਜ਼ੁਰੂਰੀ ਪਕਾ ਕਰਦੀ ਹੈ ਕਿ “active” ਕੀ ਮੰਨਿਆ ਜਾਵੇ (ਭੁਗਤਾਨ ਕੀਤਾ? grace period ਵਿੱਚ?) ਅਤੇ “win-back” ਕੀ ਹੈ (30 ਦਿਨਾਂ ਵਿੱਚ ਰੀਐਕਟਿਵੇਟ ਕੀਤਾ? ਕਿਸੇ ਵੀ ਸਮੇਂ?)।

ਕੋਰ ਐਂਟਿਟੀਜ਼ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਘੱਟੋ ਘੱਟ ਇਹ ਐਂਟਿਟੀਜ਼ ਮਾਡਲ ਕਰੋ ਤਾਂ ਜੋ ਇਵੈਂਟਸ ਅਤੇ ਪੈਸਾ ਇਕਸਾਰ ਢੰਗ ਨਾਲ ਜੁੜ ਸਕੇ:

• User: ਐਪ ਵਰਤਣ ਵਾਲਾ ਵਿਅਕਤੀ (ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ)
• Account: ਬਿਲਿੰਗ/ਗਾਹਕ ਕੰਟੇਨਰ (ਅਕਸਰ churn ਲਈ ਸਹੀ ਯੂਨਿਟ)
• Subscription: ਉਹ ਸਹਿਮਤੀ ਜੋ ਸ਼ੁਰੂ, ਨਵੀਨੀਕਰਨ, ਸਵਿੱਚ, ਜਾਂ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ
• Plan: ਉਤਪਾਦ ਟੀਅਰ (ਨਾਮ, ਕੀਮਤ, ਬਿੱਲਿੰਗ ਅੰਤਰਾਲ)
• Invoice: ਜੋ ਚਾਰਜ ਕੀਤਾ ਗਿਆ, ਕਦੋਂ, ਅਤੇ ਭੁਗਤਾਨ/ਰਿਫੰਡ ਦੀ ਸਥਿਤੀ
• Cancel event: ਰੱਦ ਦੀ ਬੇਨਤੀ ਕਦੋਂ ਕੀਤੀ ਗਈ ਅਤੇ ਕਦੋਂ ਪ੍ਰਭਾਵੀ ਹੋਈ

ਸਥਿਰ ਪਹਚਾਨਾਂ ਚੁਣੋ (account_id বনਾਮ user_id)

ਚਰਨ ਐਨਾਲਿਟਿਕਸ ਲਈ, account_id ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਪ੍ਰਾਈਮਰੀ ਪਹਚਾਨ ਹੈ ਕਿਉਂਕਿ ਯੂਜ਼ਰ ਬਦਲ ਸਕਦੇ ਹਨ (ਕਰਮਚਾਰੀ ਛੱਡਣ, ਐਡਮਿਨ ਬਦਲਣਾ)। ਤੁਸੀਂ ਕਾਰਵਾਈਆਂ ਨੂੰ user_id ਨਾਲ attribution ਕਰ ਸਕਦੇ ਹੋ, ਪਰ retention ਅਤੇ cancellations ਨੂੰ account ਲੈਵਲ 'ਤੇ ਜੋੜੋ ਜੇ ਤੁਸੀਂ ਸਚਮੁਚ ਵਿਅਕਤਿਗਤ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਵੇਚ ਰਹੇ।

ਸਿਰਫ਼ ਸਥਿਤੀ ਨਹੀਂ, ਸਥਿਤੀ ਇਤਿਹਾਸ ਸਟੋਰ ਕਰੋ

ਇੱਕ status history (effective_from/effective_to) ਲਾਗੂ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਪਿਛਲੇ ਰਾਜਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਵਾਖ਼ੀ ਕਰ ਸਕੋ। ਇਹ ਕੋਹੋਰਟ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਪ੍ਰੀ-ਰੱਦ ਵਿਵਹਾਰ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ।

ਐਡਜ ਕੇਸਾਂ ਲਈ ਪਹਿਲਾਂ ਹੀ ਯੋਜਨਾ ਬਣਾਓ

ਇਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਮਾਡਲ ਕਰੋ ਤਾਂ ਜੋ ਇਹ churn ਨੰਬਰਾਂ ਨੂੰ ਗੰਦਲਾ ਨਾ ਕਰਨ:

• Pauses (ਅਸਥਾਈ ਬੰਦ, ਰੱਦ ਵਜੋਂ ਨਹੀਂ)
• Refunds/chargebacks (ਭੁਗਤਾਨ ਵਾਪਸੀ ਵਿਰੁੱਧ ਸਵੈਚ ਛੁਟਨਾ)
• Plan switches (ਅਪਗ੍ਰੇਡ/ਡਾਊਨਗਰੇਡ ਇਵੈਂਟਸ ਵਜੋਂ, “ਨਵੀਂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ” ਨਹੀਂ)
• Grace periods (ਅਸਫਲ ਭੁਗਤਾਨ ਵਿਰੁੱਧ ਅਸਲ ਰੱਦ)

Cancellation ਫਲੋ ਨੂੰ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ (ਇਵੈਂਟਸ ਅਤੇ ਕਾਰਨਾਂ)

ਜੇ ਤੁਸੀਂ churn ਸਮਝਣਾ (ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਸੁਧਾਰਨਾ) ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ cancellation flow ਤੁਹਾਡੀ ਸਭ ਤੋਂ ਕੀਮਤੀ “ਸਚਾਈ ਦਾ ਲਹਜ਼ਾ” ਹੈ। ਇਸਨੂੰ ਇੱਕ ਉਤਪਾਦ ਸਤਹ ਵਾਂਗ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ, ਨਾ ਕਿ ਇੱਕ ਫਾਰਮ—ਹਰ ਕਦਮ ਸਾਫ਼, ਤੁਲਨੀਯੋਗ ਇਵੈਂਟ ਉਤਪੰਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਮੁੱਖ ਕਦਮ ਟ੍ਰੈਕ ਕਰੋ (ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਛੱਡਣਾ ਨਾ ਦਿਓ)

ਘੱਟੋ-ਘੱਟ, ਇੱਕ ਸਾਫ਼ ਲੜੀ ਕੈਪਚਰ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਫਨਲ ਬਣਾ ਸਕੋ:

• cancel_started — ਯੂਜ਼ਰ cancel ਅਨੁਭਵ ਖੋਲਦਾ ਹੈ
• offer_shown — ਕੋਈ ਵੀ save offer, pause ਵਿਕਲਪ, downgrade ਰਾਹ, ਜਾਂ “ਸਹਾਇਤਾ ਨਾਲ ਗੱਲ” CTA ਦਿੱਖਾਇਆ ਗਿਆ
• offer_accepted — ਯੂਜ਼ਰ ਕਿਸੇ ਪੇਸ਼ਕਸ਼ (pause, discount, downgrade) ਨੂੰ ਅੰਗੀਕਾਰ ਕਰਦਾ ਹੈ
• cancel_submitted — ਰੱਦ ਦੀ ਪੁਸ਼ਟੀ ਹੋਈ

ਇਹ ਇਵੈਂਟ ਨਾਂ web/mobile 'ਤੇ ਇਕਸਾਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਸਥਿਰ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ payload ਨੂੰ ਵਿਕਸਤ ਕਰਦੇ ਹੋ, ਤਾਂ schema ਵਰਜ਼ਨ ਵਧਾਓ (ਉਦਾਹਰਨ ਲਈ, schema_version: 2) ਬਜਾਏ ਕਿ ਮਾਇਨਿੰਗ ਨੂੰ ਬਿਨਾਂ ਚੀਨ੍ਹੇ ਬਦਲ ਦਿਓ।

ਸੰਦਰਭ ਕੈਪਚਰ ਕਰੋ ਜੋ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ਕਿ ਕਿਉਂ ਇਹ ਹੋਇਆ

ਹਰ cancellation-ਸੰਬੰਧੀ ਇਵੈਂਟ ਵਿੱਚ ਉਸੇ ਕੋਰ ਸੰਦਰਭ ਫੀਲਡ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਸੈਗਮੈਂਟ ਕਰ ਸਕੋ:

• plan, tenure, price
• country, device
• acquisition channel

ਇन्हਾਂ ਨੂੰ ਇਵੈਂਟ ਦੀਆਂ propeties 'ਤੇ ਰੱਖੋ (ਬਾਅਦ ਵਿੱਚ ਨਿਰਧਾਰਤ ਨਾ ਕਰੋ) ਤਾਂ ਕਿ ਜਦੋਂ ਹੋਰ ਸਿਸਟਮ ਬਦਲਣ, attribution ਟੁੱਟਕੇ ਨਾ ਰਹਿ ਜਾਏ।

ਉਹ ਚਰਨ ਕਾਰਨ ਇਕੱਠੇ ਕਰੋ ਜੋ ਤੁਸੀਂ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਪੜ੍ਹ ਸਕੋ

ਚਾਰਟਾਂ ਲਈ ਇੱਕ ਪ੍ਰੀ-ਨਿਰਧਾਰਤ ਕਾਰਨ ਸੂਚੀ ਵਰਤੋਂ ਨਾਲ ਨਾਲ ਵਿਕਲਪਿਕ ਫ੍ਰੀ-ਟੈਕਸਟ ਰੱਖੋ (ਨੁਆਂਸ ਲਈ)।

• cancel_reason_code (ਉਦਾਹਰਨ: too_expensive, missing_feature, switched_competitor)
• cancel_reason_text (ਵਿਕਲਪਿਕ)

ਕਾਰਨ ਨੂੰ cancel_submitted 'ਤੇ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਸੋਚੋ ਕਿ ਪਹਿਲੀ ਵਾਰੀ ਚੁਣਨ ਤੇ ਵੀ ਲੌਗ ਕਰੋ (ਇਹ ਅਨਿਸ਼ਚਿਤਤਾ ਜਾਂ ਵਾਪਸੀ-ਵਿਰੋਧੀ ਵਰਤਾਰਾ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ)।

ਸਿਰਫ਼ ਰੱਦ 'ਤੇ ਹੀ ਰੁਕੋ ਨਾ: ਨਤੀਜੇ ਵੀ ਟ੍ਰੈਕ ਕਰੋ

ਰਿਟੇਨਸ਼ਨ ਹਸਤੀ ਦੇ ਨਾਪ-ਤੋਲ ਲਈ, ਨੀਚੇ ਦੇ ਨਤੀਜੇ ਲਾਗ ਕਰੋ:

• reactivated
• downgraded
• support_ticket_opened

ਇਹਨਾਂ ਇਵੈਂਟਸ ਨਾਲ, ਤੁਸੀਂ cancellation ਇਰਾਦੇ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ—ਅਤੇ ਪ੍ਰਯੋਗ ਚਲਾਉਣ ਵਿੱਚ ਡੇਟਾ ਬਾਰੇ ਤਰਕ-ਵਿਤਰਕ ਨਹੀਂ ਹੋਣਾ ਪਏਗਾ।

ਆਪਣਾ ਡੇਟਾ ਪਾਇਪਲਾਈਨ ਅਤੇ ਸਟੋਰੇਜ ਡਿਜ਼ਾਈਨ ਕਰੋ

ਚੰਗੀ churn ਐਨਾਲਿਟਿਕਸ ਨਿਰਣਾਯਕ ਹੈ: ਇਵੈਂਟਸ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ, ਉਹ ਕਿਵੇਂ ਸਾਫ਼ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਭ ਕੋਈ ਇਹ ਤੇ ਅਨੁਮਾਨ 'ਤੇ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ ਕਿ “ਰੱਦ” ਦਾ ਕੀ ਅਰਥ ਹੈ।

ਸਟੋਰੇਜ ਚੁਣੋ: OLTP + (ਵਿਕਲਪਿਕ) ਵੇਅਰਹਾਊਸ

ਜ਼ਿਆਦਾਤਰ MVP ਲਈ, ਕੱਚਾ ਟਰੈਕਿੰਗ ਡੇਟਾ ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਐਪ ਡੇਟਾਬੇਸ (OLTP) ਵਿੱਚ ਪਹਿਲਾਂ ਸਟੋਰ ਕਰੋ। ਇਹ ਸਧਾਰਣ, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ, ਅਤੇ ਡਿਬੱਗਿੰਗ ਲਈ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਉੱਚ ਵੋਲਯੂਮ ਜਾਂ ਭਾਰੀ ਰਿਪੋਰਟਿੰਗ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਇੱਕ analytics warehouse ਜੁੜੋ (Postgres read replica, BigQuery, Snowflake, ClickHouse)। ਆਮ ਪੈਟਰਨ ਹੈ: OLTP ਜ਼ਰਾ ਹੀ ‘ਸੋਰਸ ਆਫ਼ ਟਰਥ’ + ਡੈਸ਼ਬੋਰਡ ਲਈ ਵੇਅਰਹਾਊਸ।

ਕੋਰ ਟੇਬਲਾਂ ਜੋ ਤੁਸੀਂ ਚਾਹੋਗੇ

“ਕੀ ਹੋਇਆ” ਦੇ ਆਲੇ-ਦੁਆਲੇ ਟੇਬਲਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਨਾ ਕਿ “ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਤੁਸੀਂ ਕੀ ਚਾਹੀਦਾ”। ਘੱਟੋ ਘੱਟ ਸੈੱਟ:

• events: ਹਰ ਟਰੈਕਡ ਇਵੈਂਟ ਲਈ ਇੱਕ ਪੰਕਤੀ (cancel_started, offer_shown, cancel_submitted) ਨਾਲ user_id, subscription_id, timestamps, ਅਤੇ JSON properties।
• cancellation_reasons: ਕਾਰਨ ਚੋਣਾਂ ਲਈ ਸਧਾਰਿਤ ਪੰਕਤੀਆਂ, ਵਿਕਲਪਿਕ ਫ੍ਰੀ-ਟੈਕਸਟ ਫੀਲਡ ਸਮੇਤ।
• experiment_exposures: ਕਿਸਨੇ ਕਿਹੜਾ variant ਦੇਖਿਆ, ਕਦੋਂ, ਅਤੇ ਕਿਸ ਪ੍ਰਸੰਗ ਵਿੱਚ (ਫੀਚਰ ਫਲੈਗ / ਟੈਸਟ ਨਾਂ)।

ਇਹ ਵੱਖਰਾ-ਪ੍ਰਸਤਾਵ ਤੁਹਾਡੇ analytics ਨੂੰ ਲਚਕੀਲਾ ਰੱਖਦਾ ਹੈ: ਤੁਸੀਂ ਕਾਰਨਾਂ ਅਤੇ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਰੱਦਾਂ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਡੇਟਾ ਨਕਲ ਕੀਤੇ।

ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੇ ਇਵੈਂਟਸ, ਨਕਲੀਆਂ, ਅਤੇ idempotency

Cancellation ਫਲੋ retries ਪੈਦਾ ਕਰਦੇ ਹਨ (ਪਿਛਲੇ ਬਟਨ, ਨੈਟਵਰਕ ਮੁੱਦੇ, ਰਿਫਰੇਸ਼)। idempotency_key (ਜਾਂ event_id) ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਇਕਸਾਨਤਾ ਲਾਗੂ ਕਰੋ ਤਾਂ ਕਿ ਇੱਕੋ ਇਵੈਂਟ ਦੋ ਵਾਰ ਨਹੀਂ ਗਿਣਿਆ ਜਾਏ।

ਮੋਬਾਈਲ/ਆਫਲਾਈਨ ਲਈ ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੇ ਇਵੈਂਟਸ ਲਈ ਨੀਤੀ ਨਿਰਧਾਰਤ ਕਰੋ: ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਕਬੂਲ ਕਰੋ, ਪਰ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਇਵੈਂਟ ਦੇ ਅਸਲੀ timestamp ਨੂੰ ਵਰਤੋਂ ਅਤੇ ingestion ਸਮੇਂ ਨੂੰ ਡਿਬੱਗਿੰਗ ਲਈ ਰੱਖੋ।

ਰਿਪੋਰਟਿੰਗ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ETL/ELT

ਭਾਵੇਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪੂਰਾ ਵੇਅਰਹਾਊਸ ਨਾ ਹੋਵੇ, ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਨੌਕਰੀ ਬਣਾਓ ਜੋ “ਰਿਪੋਰਟਿੰਗ ਟੇਬਲ” (ਦੈਨੀਕ aggregates, funnel steps, cohort snapshots) ਤਿਆਰ ਕਰੇ। ਇਸ ਨਾਲ ਡੈਸ਼ਬੋਰਡ ਤੇਜ਼ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਕੱਚੇ ਇਵੈਂਟਸ 'ਤੇ ਮਹਿੰਗੀਆਂ ਜੋਇਨ ਘਟਦੀਆਂ ਹਨ।

ਪਰਿਭਾਸ਼ਾਵਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਕਿ ਮੈਟਰਿਕਸ ਮੇਲ ਖਾਂ

ਇੱਕ ਛੋਟੀ ਡੇਟਾ ਡਿਕਸ਼ਨਰੀ ਲਿਖੋ: ਇਵੈਂਟ ਨਾਂ, ਲਾਜ਼ਮੀ properties, ਅਤੇ ਮੈਟਰਿਕ ਫਾਰਮੂਲੇ (ਉਦਾਹਰਨ: “churn rate cancel_effective_at ਵਰਤਦਾ ਹੈ”)। ਇਸਨੂੰ ਆਪਣੇ ਰੈਪੋ ਜਾਂ ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਉਤਪਾਦ, ਡੇਟਾ, ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਚਾਰਟਾਂ ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਸਮਝਣ।

ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ: Funnels, Cohorts, ਅਤੇ Segments

ਚੰਗਾ ਡੈਸ਼ਬੋਰਡ ਹਰ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ—ਇਹ ਤੁਹਾਨੂੰ “ਕੁਝ ਗਲਤ ਲੱਗ ਰਿਹਾ ਹੈ” ਤੋਂ “ਇਹ ਠੀਕ ਉਸ ਸਮੂਹ ਅਤੇ ਕਦਮ ਵਿੱਚ ਹੈ” ਵਿੱਚ ਕੁਝ ਹੀ ਕਲਿੱਕਾਂ 'ਚ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ।

ਮੁੱਖ ਵਿਊਜ਼ ਜੋ ਤੁਸੀਂ ਹਫ਼ਤੇ ਵਿੱਚ ਵਰਤੋਂਗੇ

ਤਿੰਨ ਵਿਊਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ churn ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਤਰੀਕਾ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:

• Cancellation funnel: cancel_started → ਕਾਰਨ ਚੁਣਿਆ ਗਿਆ → offer_shown → offer_accepted ਜਾਂ cancel_submitted. ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਲੋਕ ਕਿੱਥੇ ਬਾਹਰ ਨਿਕਲ ਰਹੇ ਹਨ ਅਤੇ ਤੁਹਾਡਾ save flow ਕਿੱਥੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ।
• Reasons distribution: ਚੁਣੇ ਗਏ ਰੱਦ ਕਰਨ ਵਾਲੇ ਕਾਰਨਾਂ ਦਾ ਵਿਭਾਜਨ, “Other (free text)” ਬਕੇਟ ਨਾਲ ਜੋ ਨਮੂਨਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਗਿਣਤੀਆਂ ਅਤੇ % ਦੋਹਾਂ ਦਿਖਾਓ ਤਾਂ ਕਿ spike ਸਪਸ਼ਟ ਹੋਵੇ।
• Cohorts by start month: ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸ਼ੁਰੂ ਮਹੀਨੇ ਦੁਆਰਾ ਰਿਟੇਨਸ਼ਨ ਜਾਂ ਰੱਦ ਦਰ। ਕੋਹੋਰਟਸ ਮੌਸਮੀ ਪ੍ਰਭਾਵ ਜਾਂ ਅਧਿਗ੍ਰਹਣ ਮਿਕਸ ਬਦਲਾਅ ਨਾਲ ਭੁੱਲਣਾ ਔਖਾ ਕਰਦੇ ਹਨ।

ਉਹ ਸੈਗਮੈਂਟ ਜਿਹੜੇ ਸੂਝ ਬਣਾਉਂਦੇ ਹਨ

ਹਰ ਚਾਰਟ ਨੂੰ ਉਹ attributes ਨਾਲ ਫਿਲਟਰ ਕਰਨ ਜੋ churn ਅਤੇ save acceptance 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦੇ ਹਨ:

• Plan ਜਾਂ tier
• Tenure (ਜਿਵੇਂ 0–7 ਦਿਨ, 8–30, 31–90, 90+)
• ਖੇਤਰ/ਦੇਸ਼
• acquisition source (organic, paid, partner, sales)
• ਭੁਗਤਾਨ ਤਰੀਕਾ (card, invoice, PayPal, ਆਦਿ)

ਡਿਫਾਲਟ ਵਿਊ “ਸਾਰੇ ਗਾਹਕ” ਰੱਖੋ, ਪਰ ਯਾਦ ਰੱਖੋ: ਲਕਸ਼ ਹੈ ਇਹ ਲੱਭਣਾ ਕਿ ਕਿਹੜਾ ਟੁਕੜਾ ਬਦਲ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ churn ਵਧਿਆ ਜਾਂ ਘਟਿਆ।

ਸਮੇਂ ਦੇ ਨਿਯੰਤਰਣ ਅਤੇ “save flow” ਪ੍ਰਦਰਸ਼ਨ

ਤੇਜ਼ ਤਾਰੀਖ ਪ੍ਰੀਸੈਟਸ (ਪਿਛਲੇ 7/30/90 ਦਿਨ) ਅਤੇ ਕਸਟਮ ਰੇਂਜ ਸ਼ਾਮਲ ਕਰੋ। ਇਕੋ ਸਮੇਂ ਨਿਯੰਤਰਣ ਹਰ ਵਿਊ ਵਿੱਚ ਵਰਤੋਂ ਤਾਂ ਜੋ ਗਲਤ ਤੁਲਨਾਵਾਂ ਤੋਂ ਬਚਿਆ ਜਾਵੇ।

ਰਿਟੇਨਸ਼ਨ ਕੰਮ ਲਈ, save flow ਨੂੰ ਇੱਕ ਛੋਟੇ ਫਨਲ ਵਜੋਂ ਨਾਪੋ ਜਿਸ ਦਾ ਵਪਾਰਕ ਪ੍ਰਭਾਵ ਹੋ:

• Offer views
• Offer acceptance rate
• Net retained MRR (ਛੂਟ, ਕਰੈਡਿਟ, ਜਾਂ ਡਾਊਨਗਰੇਡ ਬਾਅਦ ਰੱਖਿਆ ਗਿਆ MRR)

ਡ੍ਰਿੱਲ-ਡਾਉਨ ਬਿਨਾਂ ਭਰੋਸਾ ਟੁੱਟੇ

ਹਰ aggregated ਚਾਰਟ ਨੂੰ ਪ੍ਰਭਾਵਤ account ਦੀ ਸੂਚੀ 'ਤੇ ਡ੍ਰਿੱਲ-ਡਾਉਨ ਸਮਰੱਥਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਉਦਾਹਰਨ: “’Too expensive’ ਚੁਣਕੇ 14 ਦਿਨਾਂ ਵਿੱਚ ਰੱਦ ਕਰਨ ਵਾਲੇ ਗ੍ਰਾਹਕ”)। ਸਤੰਭਾਂ ਵਿੱਚ plan, tenure, ਅਤੇ ਆਖਰੀ invoice ਸ਼ਾਮਲ ਕਰੋ।

ਡ੍ਰਿੱਲ-ਡਾਉਨ ਨੂੰ ਪਰਮੀਸ਼ਨਸ (ਰੋਲ-ਅਧਾਰਿਤ 접근) ਦੇ ਪਿੱਛੇ ਰੱਖੋ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡਜ਼ ਨੂੰ ਮੁੱਲ-ਮੁੱਲ ਕਰਕੇ ਛੁਪਾਉਣ ਤੇ ਵਿਚਾਰ ਕਰੋ। ਡੈਸ਼ਬੋਰਡ ਜਾਂਚ ਕਰਨ ਲਈ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹੋਏ ਪ੍ਰਾਈਵੇਸੀ ਅਤੇ ਅੰਦਰੂਨੀ 접근 ਨੀਤੀਆਂ ਦਾ ਆਦਰ ਕਰੋ।

ਇੱਕ ਪ੍ਰਯੋਗ ਫਰੇਮਵਰਕ ਜੋੜੋ (A/B ਟੈਸਟ ਅਤੇ ਟਾਰਗੇਟਿੰਗ)

ਜੇ ਤੁਸੀਂ ਰੱਦ ਘਟਾਉਣ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਬਿਨਾਂ ਤਰਕ-ਵਿਤਰਕ ਤੋਂ ਬਿਨਾਂ ਬਦਲਾਅ ਟੈਸਟ ਕਰਨ ਦਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਲਾਜ਼ਮੀ ਹੈ। ਇੱਕ ਪ੍ਰਯੋਗ ਫਰੇਮਵਰਕ ਉਹ “ਟ੍ਰੈਫਿਕ ਕਾਪ” ਹੈ ਜੋ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸਨੇ ਕੀ ਦੇਖਿਆ, ਇਸਨੂੰ ਲਾਗ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਕਿਸ variant ਨਾਲ ਜੋੜਦਾ ਹੈ।

1) ਪ੍ਰਯੋਗ ਯੂਨਿਟ ਨਿਰਧਾਰਤ ਕਰੋ (ਕ੍ਰਾਸ-ਕੰਟੈਮੀਨੇਸ਼ਨ ਤੋਂ ਬਚੋ)

ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਅਸਾਈਨਮੈਂਟ account ਲੈਵਲ ਤੇ ਹੋਵੇ ਜਾਂ user ਲੈਵਲ ਤੇ।

• Account-level ਆਮ ਤੌਰ 'ਤੇ SaaS ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ: ਇੱਕੋ ਵਰਕਸਪੇਸ ਵਿੱਚ ਸਾਰੇ ਲੋਕ ਇੱਕੋ variant ਵੇਖਦੇ ਹਨ, ਮਿਲੇ-ਜੁਲੇ ਸੁਨੇਹੇ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਗਲਤ ਨਹੀਂ ਕਰਦੇ।
• User-level ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸਾਂਝੇ ਡਿਵਾਈਸ, ਕਈ ਲੌਗਿਨ, ਜਾਂ ਟੀਮ ਖਾਤਿਆਂ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ।

ਇਸ ਚੋਣ ਨੂੰ ਹਰ ਪ੍ਰਯੋਗ ਲਈ ਲਿਖ ਕੇ ਰੱਖੋ ਤਾਂ ਕਿ ਵਿਸ਼ਲੇਸ਼ਣ ਸੰਗਤ ਰਹੇ।

2) ਇਕ ਅਸਾਈਨਮੈਂਟ ਤਰੀਕਾ ਚੁਣੋ

ਕੁਝ ਟਾਰਗੇਟਿੰਗ ਮੋਡ ਸਮਰਥਨ ਕਰੋ:

• Random (ਪ੍ਰਚਲਿਤ A/B): ਆਮ ਡਿਫ਼ਾਲਟ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ।
• Weighted (ਜਿਵੇਂ 90/10): ਨਰਮ ਰੋਲਆਊਟ ਲਈ ਲਾਭਦਾਇਕ।
• Rules-based targeting: ਕੇਵਲ ਖਾਸ ਸੈਗਮੈਂਟ (ਪਲਾਨ ਟੀਅਰ, ਦੇਸ਼, tenure, “ਰੱਦ ਕਰਨ ਵਾਲੇ” ਸਥਿਤੀ) ਨੂੰ variant ਦਿਖਾਓ। ਨਿਯਮ ਸਧੇ ਸਧੇ ਅਤੇ ਵਰਜ਼ਨ ਕੀਤੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

3) ਜਿੱਥੇ ਅਸਲੀ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ, ਉੱਥੇ exposure ਲਾਗ ਕਰੋ

“assigned” ਨੂੰ “exposed” ਨਾ ਗਿਣੋ। exposure ਉਸ ਵੇਲੇ ਲਾਗ ਕਰੋ ਜਦ ਯੂਜ਼ਰ ਵਾਕਈ variant ਨੂੰ ਵੇਖਦਾ ਹੈ (ਉਦਾਹਰਨ: cancellation ਸਕਰੀਨ ਰੇੰਡਰ ਹੋਈ, offer modal ਖੁਲਿਆ)। ਸਟੋਰ ਕਰੋ: experiment_id, variant_id, ਯੂਨਿਟ id (account/user), timestamp, ਅਤੇ ਸੰਬੰਧਤ ਸੰਦਰਭ (plan, seat count)।

4) ਮੈਟਰਿਕ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਪ੍ਰਾਇਮਰੀ + ਗਾਰਡਰੇਲ

ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਸਫਲਤਾ ਮੈਟਰਿਕ ਚੁਣੋ, ਜਿਵੇਂ save rate (cancel_started → retained outcome)। ਗੈਰ-ਹਾਨਿਕਾਰਕ ਜਿੱਤਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਗਾਰਡਰੇਲ ਸ਼ਾਮਲ ਕਰੋ: ਸਪੋਰਟ ਸੰਪਰਕ, ਰਿਫੰਡ ਦੀਆਂ ਬੇਨਤੀਆਂ, ਸ਼ਿਕਾਇਤ ਦਰ, time-to-cancel, ਜਾਂ ਡਾਊਨਗਰੇਡ churn।

5) ਅਵਧੀ ਅਤੇ ਸੈਂਪਲ ਸਾਈਜ਼ ਧਾਰਨਾਵਾਂ ਯੋਜਨਾ ਕਰੋ

ਲਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ:

• ਘੱਟੋ-ਘੱਟ ਚਲਣ ਸਮਾਂ (ਅਕਸਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਵਿਵਹਾਰ ਲਈ 1–2 ਬਿੱਲਿੰਗ ਚਕਰ)
• ਮੌਜੂਦਾ save rate ਅਤੇ ਸਭ ਤੋਂ ਛੋਟੀ ਚੜ੍ਹਾਈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਪਰवाह ਕਰਦੇ ਹੋ ਦੇ ਆਧਾਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਨਮੂਨਾ ਆਕਾਰ

ਇਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਸ਼ੋਰ ਵਾਲੇ ਡੇਟਾ ਤੇ ਅਚਾਨਕ ਰੋਕਣ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ ਅਤੇ ਡੈਸ਼ਬੋਰਡ “ਹਾਲੇ ਸਿੱਖ ਰਹੇ” ਵਿਰੁੱਧ “ਆਧਾਰਕ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ” ਵਿਖਾ ਸਕਦਾ ਹੈ।

ਰਿਟੇਨਸ਼ਨ مਦਖਲਾਂ (Interventions) ਦੀ ਡਿਜ਼ਾਈਨ ਕਰੋ

ਰਿਟੇਨਸ਼ਨ ਮਦਖਲ ਉਹ “ਚੀਜ਼ਾਂ” ਹਨ ਜੋ ਤੁਸੀਂ ਰੱਦ ਕਰਨ ਵੇਲੇ ਦਿਖਾਉਂਦੇ ਹੋ ਜੋ ਕਿਸੇ ਦੀ ਸੋਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ—ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਧੋਖਾ ਮਹਿਸੂਸ ਕਰਵਾਏ। ਲਕਸ਼ ਸਿੱਖਣਾ ਹੈ ਕਿ ਕਿਹੜੇ ਵਿਕਲਪ churn ਘਟਾਉਂਦੇ ਹਨ ਜਦੋਂ ਕਿ ਭਰੋਸਾ ਉੱਚਾ ਰਹੇ।

ਆਮ ਇੰਟਰਵੈਂਸ਼ਨ ਵੈਰੀਅੰਟ ਜੋ ਅਜ਼ਮਾਏ ਜਾ ਸਕਦੇ ਹਨ

ਛੋਟੇ ਮੀਨੂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਮਿਲਾ-ਮਿਲਾ ਸਕਦੇ ਹੋ:

• Alternative offers: ਸੀਮਿਤ ਸਮੇਂ ਦੀ ਛੂਟ, ਇੱਕ ਮੁਫ਼ਤ ਮਹੀਨਾ, ਜਾਂ ਵਧਾਇਆ ਟ੍ਰਾਇਲ
• Pause option: ਯੂਜ਼ਰਾਂ ਨੂੰ 1–3 ਮਹੀਨਿਆਂ ਲਈ ਬਿੱਲਿੰਗ ਰੋਕਣ ਦਿਓ (ਅਤੇ ਰੀਐਕਟਿਵੇਸ਼ਨ ਦੀ ਉਮ਼ੀਦ ਦਿਖਾਓ)
• Plan downgrade: ਪੂਰੇ ਰੱਦ ਦੀ ਬਜਾਏ ਸਸਤਾ ਟੀਅਰ ਜਾਂ ਘੱਟ ਸੀਟਾਂ 'ਤੇ ਸਵਿੱਚ
• Message copy: ਸਪਸ਼ਟ, ਖਾਸ ਕਾਪੀ ਜੋ ਮੁੱਲ ਯਾਦ ਦਿਵਾਉਂਦੀ ਹੈ (“ਤੁਸੀਂ ਆਪਣਾ ਡਾਟਾ ਕਦੇ ਵੀ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ”) ਵਿਰੁੱਧ ਸਧਾਰਨ ਕਾਪੀ (“ਸਾਨੂੰ ਬੁਰਾ ਲੱਗਿਆ”)

ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਫਸਾਉਣ ਵਾਲੇ ਪੇਸ਼ਕਸ਼ ਨਾ ਬਣਾਓ

ਹਰ ਚੋਣ ਦਾ ਸਪਸ਼ਟ ਅਤੇ ਉਲਟਣਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ। “Cancel” ਰਸਤਾ ਦਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਖੋਜ-ਖੋਜ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਜੇ ਤੁਸੀਂ ਛੂਟ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ, ਤਾਂ ਸਾਫ਼ ਦੱਸੋ ਕਿ ਇਹ ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਹੈ ਅਤੇ ਬਾਅਦ ਕੀ ਕੀਮਤ ਵਾਪਸ ਆਏਗੀ। ਜੇ ਤੁਸੀਂ pause ਦਿੰਦੇ ਹੋ, ਤਾਂ ਦਿਖਾਓ ਕਿ ਐਕਸੈਸ ਅਤੇ ਬਿੱਲਿੰਗ ਤਾਰੀਖਾਂ ਨਾਲ ਕੀ ਹੋਵੇਗਾ।

ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਦੱਸ ਸਕੇ ਕਿ ਉਸਨੇ ਕੀ ਚੁਣਿਆ।

ਪ੍ਰੋਗਰੇਸਿਵ ਡਿਸਕਲੋਜ਼ਰ ਵਰਤੋਂ

ਫਲੋ ਨੂੰ ਹਲਕਾ ਰੱਖੋ:

1. ਇੱਕ ਕਾਰਨ ਪੁੱਛੋ (ਇੱਕ ਟੈਪ)

2. ਇੱਕ ਨਿੱਜੀ ਜਵਾਬ ਦਿਖਾਓ (“ਬਹੁਤ ਮਹਿੰਗਾ” ਲਈ pause, “ਕੰਮ ਨਹੀਂ ਆ ਰਿਹਾ” ਲਈ downgrade, “ਬੱਗ” ਲਈ ਸਪੋਰਟ)

3. ਆਖਰੀ ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ (pause/downgrade/cancel)

ਇਸ ਨਾਲ friction ਘਟਦੀ ਹੈ ਪਰ ਅਨੁਭਵ ਸੰਬੰਧਿਤ ਰਹਿੰਦਾ ਹੈ।

ਨਤੀਜੇ ਪੇਜ ਅਤੇ ਚੈਨਜਲੌਗ ਸ਼ਾਮਲ ਕਰੋ

ਇੱਕ ਅੰਦਰੂਨੀ ਪ੍ਰਯੋਗ ਨਤੀਜੇ ਪੇਜ ਬਣਾਓ ਜੋ ਦਿਖਾਵੇ: “saved” outcome ਵਿੱਚ ਲੀਡਰੀ, churn rate, lift vs. control, ਅਤੇ confidence interval ਜਾਂ ਸਧਾਰਨ ਫੈਸਲਾ ਨਿਯਮ (ਉਦਾਹਰਨ: “ship ਕਰੋ ਜੇ lift ≥ 3% ਅਤੇ sample ≥ 500”)।

ਇੱਕ ਚੈਨਜਲੌਗ ਰੱਖੋ ਕਿ ਕੀ ਟੇਸਟ ਕੀਤਾ ਗਿਆ ਅਤੇ ਕੀ ਸ਼ਿਪ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਜੋ ਭਵਿੱਖ ਦੇ ਟੈਸਟ ਉਹੀ ਵਿਚਾਰ ਦੁਹਰਾਉਣ ਨ ਕਰਣ ਅਤੇ ਤੁਸੀਂ ਰਿਟੇਨਸ਼ਨ ਪਹਿਰਾਵਾਂ ਨੂੰ ਖਾਸ ਬਦਲਾਵਾਂ ਨਾਲ ਜੋੜ ਸਕੋ।

ਪਰਾਈਵੇਸੀ, ਸੁਰੱਖਿਆ, ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ

Cancellation ਡੇਟਾ ਸਭ ਤੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਉਤਪਾਦ ਡੇਟਾ ਵਿੱਚੋਂ ਇੱਕ ਹੈ: ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਬਿੱਲਿੰਗ ਸੰਦਰਭ, ਪਹਚਾਨਾਂ, ਅਤੇ ਫ੍ਰੀ-ਟੈਕਸਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਵਿਅਕਤੀਗਤ ਵੇਰਵੇ ਰੱਖ ਸਕਦੇ ਹਨ। ਪਰਾਈਵੇਸੀ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਉਤਪਾਦ ਲੋੜ ਵਾਂਗ ਸਮਝੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ।

ਪ੍ਰਮਾਣਿਕਕਰਨ ਅਤੇ ਰੋਲ

ਸ਼ੁਰੂਆਤ ਕਰਦੇ ਸਮੇਂ authenticated 접근 ਰੱਖੋ (ਜੇ ਮਿਲ ਸਕੇ ਤਾਂ SSO)। ਫਿਰ ਸਧਾਰਨ, ਸਪਸ਼ਟ ਰੋਲ ਸ਼ਾਮਲ ਕਰੋ:

• Admin: settings, data retention, user access, ਅਤੇ exports ਪ੍ਰਬੰਧਾ ਕਰਨ ਦੀ ਸਮਰੱਥਾ।
• Analyst: ਡੈਸ਼ਬੋਰਡ ਵੇਖਣਾ, segments ਬਣਾਉਣਾ, experiments ਚਲਾਉਣਾ।
• Support: ਗਾਹਕ-ਜ਼ਰੀਏ ਇਤਿਹਾਸ ਦੇਖਣਾ ਜਿਸ ਨਾਲ ਮਦਦ ਕਰਨੀ ਹੈ (ਸੀਮਿਤ ਫੀਲਡ)।
• Read-only: aggregate ਡੈਸ਼ਬੋਰਡ ਵੇਖਣਾ ਬਿਨਾਂ ਡ੍ਰਿੱਲ-ਡਾਉਨ ਦੇ।

ਰੋਲ ਜਾਂਚ ਸਰਵਰ-ਸਾਈਡ ਤੇ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ UI ਵਿੱਚ।

ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦੀ ਪ੍ਰਦਰਸ਼ਨ ਘਟਾਓ

ਜੋ ਲੋਕ ਗਾਹਕ-ਲੈਵਲ ਰਿਕਾਰਡ ਵੇਖ ਸਕਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰੋ। ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ aggregates ਤਰਜੀਹ ਦਿਓ, ਅਤੇ ਡ੍ਰਿੱਲ-ਡਾਉਨ ਨੂੰ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪਰਮੀਸ਼ਨ ਦੇ ਪਿੱਛੇ ਰੱਖੋ।

• UI ਵਿੱਚ ਪਹਚਾਨ ਢਾਂਕੋ (email, customer ID) ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ।
• joins ਅਤੇ deduping ਲਈ identifiers ਨੂੰ hash ਕਰੋ (ਉਦਾਹਰਨ: ਸਿਕ੍ਰੇਟ ਸਾਲਟ ਨਾਲ SHA-256) ਤਾਂ ਕਿ ਵਿਸ਼ਲੇਸ਼ਕ raak PII ਦੇਖਦੇ ਬਿਨਾਂ ਸੈਗਮੈਂਟ ਕਰ ਸਕਣ।
• ਬਿਲਿੰਗ/ਪਹਚਾਣ ਵਾਲੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਇਵੈਂਟ analytics ਟੇਬਲਾਂ ਤੋਂ ਵੱਖ ਰੱਖੋ, hashed key ਰਾਹੀਂ ਜੋੜੋ।

ਡੇਟਾ ਰੱਖ-ਰਖਾਅ ਨੀਤੀਆਂ

ਅੱਗੇ ਹੀ retention ਨਿਰਧਾਰਤ ਕਰੋ:

• ਇਵੈਂਟ ਡੇਟਾ ਉਹੀ ਸਮਾਂ ਰੱਖੋ ਜਿੰਨਾ ਕੋਹੋਰਟ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਚਾਹੀਦਾ (ਉਦਾਹਰਨ: 13–18 ਮਹੀਨੇ)।
• ਫ੍ਰੀ-ਟੈਕਸਟ cancellation ਕਾਰਨ ਲਈ ਛੋਟੀ ਰੱਖ-ਰਖਾਅ ਜਾਂ redaction ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਅਕਸਰ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ।
• ਯੂਜ਼ਰ ਦੀ ਬੇਨਤੀ ਅਤੇ ਅੰਦਰੂਨੀ ਨੀਤੀਆਂ ਨੂੰ ਮੰਨਣ ਲਈ ਮਿਟਾਉਣ ਵਰਕਫਲੋ ਦਿਓ।

ਆਡਿਟ ਲਾਗ

ਡੈਸ਼ਬੋਰਡ ਐਕਸੇਸ ਅਤੇ exports ਲੌਗ ਕਰੋ:

• ਕਿਸਨੇ ਗਾਹਕ-ਲੈਵਲ ਪੰਨ੍ਹੇ ਵੇਖੇ
• ਕਿਸਨੇ ਡੇਟਾ ਐਕਸਪੋਰਟ ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਕਿਹੜੇ ਫਿਲਟਰ ਵਰਤੇ ਗਏ
• retention ਅਤੇ permissions 'ਚ admin ਵਿਕਲਪਾਂ ਦੀ ਬਦਲੀ

ਲਾਂਚ ਸੁਰੱਖਿਆ ਚੈੱਕਲਿਸਟ

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੂਲ ਚੀਜ਼ਾਂ ਕਵਰ ਕਰੋ: OWASP ਟਾਪ ਰਿਸਕ (XSS/CSRF/injection), TLS ਹਰ ਥਾਂ, least-privilege DB accounts, secrets management (ਕੋਡ ਵਿੱਚ ਕੋਈ ਕੀ ਨਹੀਂ), auth endpoints 'ਤੇ rate limiting, ਅਤੇ ਬੈਕਅੱਪ/ਰੀਸਟੋਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਟੈਸਟਿੰਗ।

ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਬਲੂਪ੍ਰਿੰਟ (Frontend, Backend, ਅਤੇ ਟੈਸਟਿੰਗ)

ਇਹ ਭਾਗ ਤਿੰਨ ਹਿੱਸਿਆਂ—ਬੈਕਐਂਡ, ਫਰੰਟਐਂਡ, ਅਤੇ ਗੁਣਵੱਤਾ—ਵਿੱਚ ਨਿਰਮਾਣ ਨੂੰ ਮੈਪ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੱਕ MVP ਸ਼ਿਪ ਕਰ ਸਕੋ ਜੋ ਕਨਸਿਸਟੈਂਟ, ਪਰਯਾਪਤ ਤੇਜ਼, ਅਤੇ ਵਿਕਸਤ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਵੇ।

Backend: subscriptions, events, ਅਤੇ experiments

ਸਧਾਰਨ API ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ subscriptions ਲਈ CRUD (create, update status, pause/resume, cancel) ਸਹਾਇਕ ਹੋਵੇ ਅਤੇ ਮੁੱਖ ਲਾਈਫਸਾਇਕਲ ਤिथੀਆਂ ਸਟੋਰ ਕਰੇ। ਲਿਖਣ ਵਾਲੇ ਰਾਹ ਸਧਾਰਨ ਅਤੇ ਵੈਧਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਫਿਰ ਇੱਕ event ingestion endpoint ਸ਼ਾਮਲ ਕਰੋ ਟ੍ਰੈਕਿੰਗ ਕਾਰਵਾਈਆਂ ਲਈ ਜਿਵੇਂ “opened cancellation page,” “selected reason,” ਅਤੇ “confirmed cancel.” ਜਿਆਦਾ ਭਰੋਸੇਯੋਗੀ ਲਈ server-side ingestion ਪ੍ਰాధਾਨ ਕਰੋ ਤਾਂ ਕਿ ad blockers ਅਤੇ ਚੇਤਾਵਨੀ ਘਟ ਸਕੇ। ਜੇ client events ਲੈਣੇ ਹੀ ਪੈਣ, ਤਾਂ request sign ਕਰੋ ਅਤੇ rate-limit ਲਗਾਓ।

ਰਿਟੇਨਸ਼ਨ ਪ੍ਰਯੋਗਾਂ ਲਈ, experiment assignment server-side ਲਾਗੂ ਕਰੋ ਤਾਂ ਕਿ ਇਕੋ account ਹਮੇਸ਼ਾ ਇਕੋ variant ਪਾਏ। ਆਮ ਪੈਟਰਨ: eligible experiments ਫੈਚ ਕਰੋ → hash (account_id, experiment_id) → variant ਅਸਾਈਨ ਕਰੋ → ਅਸਾਈਨਮੈਂਟ ਸਟੋਰ ਕਰੋ।

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤਿਆਰੀਆਂ ਦੇ ਸਕਦਾ ਹੈ (React ਡੈਸ਼ਬੋਰਡ, Go ਬੈਕਐਂਡ, PostgreSQL schema) ਇੱਕ ਛੋਟੀ spec ਤੋਂ—ਫਿਰ ਤੁਸੀਂ ਸੋর্স ਕੋਡ ਨਿਰਯਾਤ ਕਰਕੇ ਡੇਟਾ ਮਾਡਲ, ਇਵੈਂਟ ਠੇਕਿਆਂ, ਅਤੇ ਪਰਮੀਸ਼ਨਸ ਅਨੁਸਾਰ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹੋ।

Frontend: ਡੈਸ਼ਬੋਰਡ, ਫਿਲਟਰ, ਅਤੇ ਐਕਸਪੋਰਟ

ਕੁਝ ਡੈਸ਼ਬੋਰਡ ਪੰਨਿਆਂ ਦਾ ਨਿਰਮਾਣ ਕਰੋ: funnels (cancel_started → offer_shown → cancel_submitted), ਕੋਹੋਰਟਸ (signup ਮਹੀਨੇ ਮੁਤਾਬਕ), ਅਤੇ ਸੈਗਮੈਂਟ (plan, country, acquisition channel)। ਹਰ ਪੰਨੇ 'ਤੇ ਫਿਲਟਰ consistent ਰੱਖੋ।

ਨियੰਤਰਿਤ ਸਾਂਝਾ ਕਰਨ ਲਈ CSV export ਦਿਓ: ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਕੇਵਲ aggregated ਨਤੀਜੇ ਐਕਸਪੋਰਟ ਕਰੋ, row-level exports ਲਈ ਉਚੇਰ ਪਰਮੀਸ਼ਨ ਦੀ ਮੰਗ ਕਰੋ, ਅਤੇ exports ਨੂੰ audit ਲਈ ਲੌਗ ਕਰੋ।

ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਖ ਗੱਲਾਂ

ਇਵੈਂਟ ਲਿਸਟਾਂ ਲਈ pagination ਵਰਤੋਂ, ਆਮ ਫਿਲਟਰਾਂ (ਤਾਰੀਖ, subscription_id, plan) 'ਤੇ ਇੰਡੈਕਸ ਕਰੋ, ਅਤੇ ਭਾਰੀ ਚਾਰਟਾਂ ਲਈ pre-aggregations (ਦੈਨੀਕ ਗਿਣਤੀਆਂ, cohort tables) ਜੋੜੋ। “ਪਿਛਲੇ 30 ਦਿਨ” ਸੰਖੇਪਾਂ ਨੂੰ ਛੋਟਾ TTL ਨਾਲ cache ਕਰੋ।

ਟੈਸਟਿੰਗ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ

Metric definitions (ਉਦਾਹਰਨ: “cancellation started” ਕੀ ਗਿਣਿਆ ਜਾਂਦਾ) ਅਤੇ assignment consistency (ਉਹੀ account ਹਮੇਸ਼ਾ ਇਕੋ variant ਵਿੱਚ) ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਲਿਖੋ।

ਇੰਚੇਪਸ਼ਨ ਫੇਲਿਓਂ ਲਈ retries ਅਤੇ ਇੱਕ dead-letter queue ਲਾਗੂ ਕਰੋ ਤਾਂ ਕਿ ਖਾਮੋਸ਼ੀ ਨਾਲ ਡੇਟਾ ਖੋਇਆ ਨਾ ਜਾਵੇ। ਐਰਰਾਂ ਨੂੰ ਲੌਗਾਂ ਵਿੱਚ ਅਤੇ ਇੱਕ admin ਪੰਨੇ 'ਤੇ ਦਿਖਾਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਮੁੱਦਿਆਂ ਨੂੰ ਨੰਬਰਾਂ ਨੂੰ ਵਿਗਾੜਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰ ਸਕੋ।

ਡਿਪਲੋਏ, ਮਾਨੀਟਰ, ਅਤੇ ਡੇਟਾ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖੋ

ਤੁਹਾਡੀ cancellation analytics ਐਪ ਛਿਪ ਕਰਨ ਦੇ ਬਾਅਦ ਵੀ ਕੰਮ ਪੂਰਾ ਨਹੀਂ ਹੁੰਦਾ। ਦੂਜਾ ਅੱਧਾ ਇਹ ਹੈ ਕਿ ਇਸ ਨੂੰ ਸਹੀ ਰੱਖਣਾ ਜਦ ਕਿ ਤੁਹਾਡਾ ਉਤਪਾਦ ਅਤੇ ਪ੍ਰਯੋਗ ਹਫ਼ਤੇ-ਹਫ਼ਤੇ ਬਦਲਦੇ ਹਨ।

ਡਿਪਲੋਏਮੈਂਟ ਦਾ ਤਰੀਕਾ ਚੁਣੋ

ਆਪਣੀ ਟੀਮ ਦੇ ਓਪਰੇਟਿੰਗ ਅੰਦਾਜ਼ ਨਾਲ ਸਭ ਤੋਂ ਸਧਾਰਣ ਵਿਕਲਪ ਚੁਣੋ:

• Managed hosting (PaaS): ਜੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ।
• Containers (Docker + orchestrator): ਜਦੋਂ ਤੁਹਾਨੂੰ ਨਿਰੰਤਰ ਬਿਲਡ ਅਤੇ ਡੀਪੈਂਡੈਂਸੀ 'ਤੇ ਹੋਰ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋਵੇ।
• Serverless: spike-ਭਰੇ ਲੋਡ ਲਈ ਵਧੀਆ (ਇਵੈਂਟ ingestion, scheduled validation jobs), ਪਰ cold starts ਅਤੇ vendor-ਨਿਰਧਾਰਤ ਸੀਮਾਵਾਂ ਦਾ ਧਿਆਨ ਰਖੋ।

ਜੋ ਵੀ ਤੁਸੀਂ ਚੁਣੋ, analytics ਐਪ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਵਾਂਗ ਦੱਸੋ: ਵਰਜ਼ਨਿੰਗ, ਡਿਪਲੋਯਮੈਂਟ ਆਟੋਮੇਸ਼ਨ, ਅਤੇ config environment variables ਵਿੱਚ ਰੱਖੋ।

ਜੇ ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਪੂਰਾ ਪਾਈਪਲਾਈਨ ਸੰਭਾਲਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਤਾਂ Koder.ai ਡਿਪਲੋਏਮੈਂਟ ਅਤੇ ਹੋਸਟਿੰਗ (ਕਸਟਮ ਡੋਮੇਨ ਸਮੇਤ) ਵੀ ਸੰਭਾਲ ਸਕਦਾ ਹੈ — ਇਹ ਸੰਵੇਦਨਸ਼ੀਲ cancellation ਫਲੋ 'ਤੇ ਤੇਜ਼ iteration ਲਈ snapshots ਅਤੇ rollback ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ।

ਵੱਖਰੇ ਵਾਤਾਵਰਣ (ਅਤੇ ਡੇਟਾ)

dev, staging, ਅਤੇ production ਵਾਤਾਵਰਣ ਬਣਾਓ:

• ਟੈਸਟ ਇਵੈਂਟਸ metrics ਨੂੰ ਗਦਲਾ ਨਾ ਕਰਨ ਲਈ ਵੱਖਰੇ ਡੇਟਾਬੇਸ ਅਤੇ ਸਟੋਰੇਜ ਬਕੈਟ।
• ਇੱਕ ਸਮਰੂਪ staging ਵਾਤਾਵਰਣ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ schema ਅਤੇ routing ਨੂੰ ਨਕਲ ਕਰਦਾ ਹੋਵੇ।
• non-prod ਵਿੱਚ experiment IDs 'ਤੇ prefix ਜਿਹੇ ਵੱਖਰੇ experiment namespaces ताकि “ਝੂਠੇ variants” ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਨਜ਼ਰ ਨਾ ਆਉਣ।

ਨਿਗਰਾਨੀ ਜੋ ਫੈਸਲੇ ਦੀ ਰੱਖਿਆ ਕਰੇ

ਤੁਸੀਂ ਸਿਰਫ਼ uptime ਨਹੀਂ ਨਿਗਰਾਨੀ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਸੱਚਾਈ ਦੀ ਵੀ ਰਖਿਆ ਕਰ ਰਹੇ ਹੋ:

• API, background workers, ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਦੀ uptime/health
• Ingestion lag (event time vs. processed time) ਨਾਲ alerts ਜਦੋਂ ਇਹ ਟਰੈਂਡ ਤੋੜੇ
• Experiment assignment errors: “unassigned units” ਵਿੱਚ ਅਚਾਨਕ spike, variant imbalance, ਜਾਂ ਇੱਕੋ account ਲਈ assignment ਬਦਲਣਾ

automated data validation jobs

ਹਲਕੇ checks ਸ਼ੈਡਮੀਟ ਕਰੋ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਹੋਣ:

• ਲੋੜੀਂਦੇ ਕੁੰਜੀ ਇਵੈਂਟ ਮਿਸ (ਉਦਾਹਰਨ: ਉਮੀਦ ਅਨੁਸਾਰ cancel_started ਬਿਨਾਂ cancel_submitted)
• schema changes (ਨਵੇਂ/ਹਟਾਏ ਗੁਣ, ਟਾਈਪ ਚੇਨਜ, ਅਣਪੇक्षित enums)
• ਵਾਅਲਿਊਮ anomalies (ਕਿਸੇ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਇਵੈਂਟ ਲਗਭਗ-ਜ਼ੀਰੋ ਹੋ ਜਾਣ)

ਪ੍ਰਯੋਗ UI ਬਦਲਾਵਾਂ ਲਈ ਰੋਲਬੈਕ ਯੋਜਨਾ

ਕਿਸੇ ਵੀ ਪ੍ਰਯੋਗ ਲਈ ਜੋ cancellation фਲੋ 'ਤੇ ਛੂਹ ਕਰਦਾ ਹੈ, ਪਹਿਲਾਂ ਹੀ rollback ਦੀ ਯੋਜਨਾ ਬਣਾਓ:

• variants ਨੂੰ ਤੁਰੰਤ ਬੰਦ ਕਰਨ ਲਈ feature flags
• ਆਖਰੀ known-good build ਨੂੰ ਫਿਰ ਤੋਂ ਡਿਪਲੋਏ ਕਰਨ ਦਾ ਤੇਜ਼ ਰਸਤਾ
• ਡੈਸ਼ਬੋਰਡ 'ਚ rollback ਵਿੰਡੋ ਨੋਟ ਜੋ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਨੂੰ ਡੇਟਾ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਨਾ ਪੜ੍ਹਨ ਦੇਵੇ

ਸਿਸਟਮ ਚਲਾਉ: ਸੂਝ ਤੋਂ ਲੈ ਕੇ ਚਲਦੀਆਂ ਪ੍ਰਯੋਗਾਂ ਤੱਕ

ਇੱਕ cancellation analytics ਐਪ ਤਦ ਹੀ ਫਾਇਦੇਮੰਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਇੱਕ ਆਦਤ ਬਣ ਜਾਵੇ, ਨਾ ਕਿ ਇੱਕ ਵਾਰੀ ਦੀ ਰਿਪੋਰਟ। ਲਕਸ਼ ਇਹ ਹੈ ਕਿ “ਅਸੀਂ churn ਦੇਖਿਆ” ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਚੱਕਰ ਵਿੱਚ ਬਦਲਣਾ: ਸੂਝ → ਹਿਪੋਥੇਸਿਸ → ਟੈਸਟ → ਫੈਸਲਾ।

ਸਧਾਰਨ ਹਫਤਾਵਾਰੀ ਰਿੱਥਮ ਚਲਾਓ

ਹਰ ਹਫਤੇ ਇੱਕ ਹੀ ਸਮਾਂ (30–45 ਮਿੰਟ) ਚੁਣੋ ਅਤੇ ਰੀਟੂਅਲ ਨੂੰ ਹਲਕਾ ਰੱਖੋ:

• ਮੁੱਖ ਮੈਟਰਿਕਸ (ਕੁੱਲ churn, ਪਲਾਨ ਅਨੁਸਾਰ churn, tenure ਅਨੁਸਾਰ churn, ਅਤੇ ਮੁੱਖ ਰੱਦ ਕਾਰਨ) ਲਈ ਡੈਸ਼ਬੋਰਡ ਦੀ ਸਮੀਖਿਆ ਕਰੋ।
• ਇੱਕ ਐਨੋਮਲੀ ਨਿਸ਼ਾਨ ਲਗਾਓ ਜੋ ਜਾਂਚ ਯੋਗ ਹੋ (ਉਦਾਹਰਨ: ਸਾਲਾਨਾ ਨਵੀਨੀਕਰਨਾਂ ਵਿੱਚ churn spike, ਜਾਂ ਇੱਕ ਕਾਰਨ ਜੋ ਅਚਾਨਕ #1 ਰੈਂਕ ਕਰਦਾ ਹੈ)।
• ਅਗਲੇ ਹਫਤੇ ਲਈ ਬਿਲਕੁਲ ਇੱਕ ਹਿਪੋਥੇਸਿਸ ਟੈਸਟ ਕਰਨ ਦੀ ਚੋਣ ਕਰੋ।

ਇੱਕ ਹਿਪੋਥੇਸਿਸ ਨੂੰ ਇੱਕ ਹੀ ਰੱਖਣ ਨਾਲ ਸਪਸ਼ਟਤਾ ਆਉਂਦੀ ਹੈ: ਅਸੀਂ ਕੀ ਸੋਚਦੇ ਹਾਂ ਕਿ ਹੋ ਰਿਹਾ ਹੈ, ਕੌਣ ਪ੍ਰਭਾਵਤ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਕਾਰਵਾਈ ਨਤੀਜੇ ਬਦਲ ਸਕਦੀ ਹੈ।

ਪ੍ਰਯੋਗਾਂ ਦੀ ਪ੍ਰਾਥਮਿਕਤਾ (ਪ੍ਰਭਾਵ × ਕੋਸ਼ਿਸ਼)

ਇੱਕੋ ਸਮੇਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਟੈਸਟ ਨਾ ਚਲਾਓ—ਖਾਸ ਕਰਕੇ cancellation ਫਲੋ ਵਿੱਚ—ਕਿਉਂਕਿ ਵੱਖ-ਵੱਖ ਬਦਲਾਅ ਦੇ ਨਤੀਜੇ ਆਪਸ ਵਿੱਚ ਮਿਲ ਮਿੜ ਕੇ ਭਰੋਸੇਯੋਗ ਨਤੀਜੇ ਰੋਕ ਸਕਦੇ ਹਨ।

ਸਧਾਰਨ ਗ੍ਰਿਡ ਵਰਤੋ:

• ਉੱਚ ਪ੍ਰਭਾਵ / ਘੱਟ ਕੋਸ਼ਿਸ਼: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਰੋ (ਕਾਪੀ ਬਦਲਾਵ, ਸਪੋਰਟ ਨੂੰ ਰੂਟਿੰਗ, ਸਾਲਾਨਾ ਸਵਿੱਚ ਦੀ ਪੇਸ਼ਕਸ਼)
• ਉੱਚ ਪ੍ਰਭਾਵ / ਉੱਚ ਕੋਸ਼ਿਸ਼: ਯੋਜਨਾ ਬਣਾਓ (ਬਿੱਲਿੰਗ ਲਚਕੀਲਾਪਣ, ਉਤਪਾਦ ਸੁਧਾਰ)
• ਘੱਟ ਪ੍ਰਭਾਵ: ਬਾਅਦ ਰੱਖੋ

ਜੇ ਤੁਸੀਂ experimentation ਵਿੱਚ ਨਵੇਂ ਹੋ, ਤਾਂ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੁਨਿਆਦੀ ਨਿਯਮ ਅਤੇ ਫੈਸਲਾ ਨੀਤੀਆਂ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ: ab-testing-basics.

ਗੁਣਾਤਮਕ ਇਨਪੁੱਟ ਨਾਲ ਲੂਪ ਬੰਦ ਕਰੋ

ਅੰਕੜੇ ਤੁਹਾਨੂੰ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਦਸਦੇ ਹਨ; ਸਪੋਰਟ ਨੋਟ ਅਤੇ cancellation टिप्पਣੀਆਂ ਅਕਸਰ ਕਿਉਂ ਦੱਸਦੀਆਂ ਹਨ। ਹਰ ਹਫਤੇ, ਪ੍ਰਤੀ ਸੈਗਮੈਂਟ ਕੁਝ ਹਾਲੀਆ ਰੱਦਾਂ ਦਾ ਨਮੂਨਾ ਲਓ ਅਤੇ ਥੀਮਾਂ ਸੰਖੇਪ ਕਰੋ। ਫਿਰ ਥੀਮਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨ ਯੋਗ ਇੰਟਰਵੈਂਸ਼ਨਾਂ ਨਾਲ ਜੋੜੋ।

“ਜਿੱਤਣ ਵਾਲੀਆਂ ਇੰਟਰਵੈਂਸ਼ਨਾਂ” playbook ਬਣਾਓ

ਸਮੇਂ ਨਾਲ ਸਿੱਖਿਆਵਾਂ ਦਾ ਟ੍ਰੈਕ ਰੱਖੋ: ਕੀ ਕੰਮ ਕੀਤਾ, ਕਿਸ ਲਈ, ਅਤੇ ਕਿਸ ਹਾਲਤ ਵਿੱਚ। ਛੋਟੇ ਐਂਟਰੀਆਂ ਰੱਖੋ:

• ਸੈਗਮੈਂਟ ਦੀ ਪਰਿਭਾਸ਼ਾ (plan, tenure, ਵਰਤੋਂ)
• ਹਿਪੋਥੇਸਿਸ ਅਤੇ ਕੀਤਾ ਗਿਆ ਬਦਲਾਅ
• ਨਤੀਜਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ
• ਫਾਲੋ-ਅਪ ਕਾਰਵਾਈ (roll out, iterate, ਜਾਂ revert)

ਜਦੋਂ ਤੁਸੀਂ ਪੇਸ਼ਕਸ਼ਾਂ ਦੀ ਸਥਿਰਤਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ (ਅਤੇ ad-hoc discounts ਨੂੰ ਰੋਕਣਾ), ਆਪਣੀ playbook ਨੂੰ ਆਪਣੇ packaging ਅਤੇ limits ਨਾਲ ਜੋੜੋ: pricing.