29 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
ਉਤਪਾਦ ਮੁੱਲ ਦੇ ਤਜਰਬਿਆਂ ਲਈ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਕੀਮਤ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਵੈੱਬ ਐਪ ਯੋਜਨਾ ਬਣਾਓ, ਡਿਜ਼ਾਇਨ ਕਰੋ ਅਤੇ ਰਿਲੀਜ਼ ਕਰੋ: ਵੈਰੀਐਂਟ, ਟ੍ਰੈਫਿਕ ਸਪਲਿਟ, ਸੌਂਪਣਾ, ਮੈਟਰਿਕਸ, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੋਲਆਊਟ ਗਾਰਡਰੇਲ।
ਕੀਮਤ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਵੈੱਬ ਐਪ ਯੋਜਨਾ ਬਣਾਓ, ਡਿਜ਼ਾਇਨ ਕਰੋ ਅਤੇ ਰਿਲੀਜ਼ ਕਰੋ: ਵੈਰੀਐਂਟ, ਟ੍ਰੈਫਿਕ ਸਪਲਿਟ, ਸੌਂਪਣਾ, ਮੈਟਰਿਕਸ, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੋਲਆਊਟ ਗਾਰਡਰੇਲ।
ਕੀਮਤ ਪ੍ਰਯੋਗ ਢਾਂਚਾਬੱਧ ਟੈਸਟ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਗਾਹਕ ਗਰੁੱਪਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਕੀਮਤਾਂ (ਜਾ ਪੈਕੇਜਿੰਗ) ਦਿਖਾਉਂਦੇ ਹੋ ਅਤੇ ਵੇਖਦੇ ਹੋ ਕਿ ਕੀ ਬਦਲਦਾ ਹੈ — ਕਨਵਰਜ਼ਨ, ਅਪਗ੍ਰੇਡ, ਛੱਡਣਾ, ਪ੍ਰਤੀ-ਵਿਜ਼ਟਰ ਰੇਵੇਨਿਊ ਆਦਿ। ਇਹ A/B ਟੈਸਟ ਦਾ ਕੀਮਤ ਵਰਜਨ ਹੈ, ਪਰ ਨਾਲ ਵੱਧ ਖਤਰਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਗਲਤੀ ਗਾਹਕਾਂ ਨੂੰ ਭੁਲੇਖਾ ਕਰ ਸਕਦੀ, ਸਪੋਰਟ ਟਿਕਟ ਬਣ ਸਕਦੇ ਹਨ, ਜਾਂ ਅੰਦਰੂਨੀ ਨੀਤੀਆਂ ਦੀ ਉਲੰਘਣਾ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰਾਈਸਿੰਗ ਪ੍ਰਯੋਗ ਮੈਨੇਜਰ ਉਹ ਸਿਸਟਮ ਹੈ ਜੋ ਇਹਨਾਂ ਟੈਸਟਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ, ਨਿਰੀਖਣਯੋਗ ਅਤੇ ਵਾਪਸੀਯੋਗ ਰੱਖਦਾ ਹੈ।
ਨਿਯੰਤਰਣ: ਟੀਮਾਂ ਨੂੰ ਇਹ ਲੋੜ ਹੈ ਕਿ ਉਹ ਇਕ ਥਾਂ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਕਿ ਕੀ ਟੈਸਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਕਿੱਥੇ, ਅਤੇ ਕਿਸ ਲਈ। “ਅਸੀਂ ਕੀਮਤ ਬਦਲੀ” ਹੀ ਕੋਈ ਯੋਜਨਾ ਨਹੀਂ — ਇੱਕ ਪ੍ਰਯੋਗ ਨੂੰ ਸਪਸ਼ਟ ਹਾਈਪੋਥੇਸਿਸ, ਮਿਤੀਆਂ, ਟਾਰਗੇਟਿੰਗ ਨਿਯਮ, ਅਤੇ ਇੱਕ ਕਿਲ-ਸਵਿੱਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਟ੍ਰੈਕਿੰਗ: ਬਿਨਾਂ ਲਗਾਤਾਰ ਪਛਾਣਕਰਤਾ (ਜਿਵੇਂ experiment key, variant key, assignment timestamp) ਦੇ, ਵਿਸ਼ਲੇਸ਼ਣ ਅਨੁਮਾ'ਨ ਬਣ ਜਾਂਦਾ ਹੈ। ਮੈਨੇਜਰ ਨੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਰ exposure ਅਤੇ ਖਰੀਦ ਨੂੰ ਸਹੀ ਟੈਸਟ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕੇ।
ਇਕਸਾਰਤਾ: ਗਾਹਕਾਂ ਨੂੰ ਕੀਮਤ ਪੇਜ 'ਤੇ ਇੱਕ ਕੀਮਤ ਅਤੇ ਚੈਕਆਊਟ 'ਤੇ ਵੱਖਰੀ ਕੀਮਤ ਨਹੀਂ ਦੇਖਣੀ ਚਾਹੀਦੀ। ਮੈਨੇਜਰ ਨੂੰ ਇਹ coordinate ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਵੈਰੀਐਂਟ ਕਿਵੇਂ ਸਤਹਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਕਿ ਤਜਰਬਾ ਏਕੀਭੂਤ ਰਹੇ।
ਸੁਰੱਖਿਆ: ਕੀਮਤ ਗਲਤੀਆਂ ਮਹਿੰਗੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਤੁਹਾਨੂੰ ਟ੍ਰੈਫਿਕ ਸੀਮਾਵਾਂ, ਯੋਗਤਾ ਨਿਯਮ (ਜਿਵੇਂ ਨਵੇਂ ਗਾਹਕ ਹੀ), ਮਨਜ਼ੂਰੀ ਕਦਮ, ਅਤੇ ਆਡੀਟਯੋਗ ਵਰਗੇ ਗਾਰਡਰੇਲਾਂ ਦੀ ਲੋੜ ਹੈ।
ਇਹ ਪੋਸਟ ਇੱਕ ਅੰਦਰੂਨੀ ਵੈੱਬ ਐਪ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ ਜੋ ਪ੍ਰਯੋਗਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੀ ਹੈ: ਪ੍ਰਯੋਗ ਬਣਾਉਣਾ, ਵੈਰੀਐਂਟ ਸੌਂਪਣਾ, ਇਵੈਂਟ ਇਕੱਤਰ ਕਰਨਾ ਅਤੇ ਨਤੀਜੇ ਰਿਪੋਰਟ ਕਰਨਾ।
ਇਹ ਪੂਰਾ ਪ੍ਰਾਈਸਿੰਗ ਇੰਜਣ ਨਹੀਂ ਹੈ (ਟੈਕਸ ਗਣਨਾ, ਇਨਵੌਇਸਿੰਗ, ਬਹੁ-ਮੁਦਰਾ ਕੈਟਲੌਗ, ਪ੍ਰੋਰੇਸ਼ਨ ਆਦਿ)। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਕੰਟਰੋਲ ਪੈਨਲ ਅਤੇ ਟਰੈਕਿੰਗ ਲੇਅਰ ਹੈ ਜੋ ਕੀਮਤ ਟੈਸਟਿੰਗ ਨੂੰ ਮੁਕੱਦਮਾ ਚਲਾਉਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਾਈਸਿੰਗ ਪ੍ਰਯੋਗ ਮੈਨੇਜਰ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਇਹ ਸਪਸਟ ਹੋਵੇ ਕਿ ਇਹ ਕੀ ਕਰੇਗਾ—ਅਤੇ ਕੀ ਨਹੀਂ। ਘੱਟ ਸਕੋਪ ਉਤਪਾਦ ਨੂੰ ਚਲਾਉਣਾ ਆਸਾਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਅਸਲ ਰੇਵੇਨਿਊ ਲੜੀ ਵਿੱਚ ਹੋਵੇ।
ਘੱਟੋ-ਘੱਟ, ਤੁਹਾਡੀ ਵੈੱਬ ਐਪ ਨੂੰ ਇੱਕ ਗੈਰ-ਤਕਨੀਕੀ ਆਪਰੇਟਰ ਨੂੰ ਪ੍ਰਯੋਗ ਚਲਾਉਣ ਯੋਗ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਹੋਰ ਕੁਝ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਤਾਂ ਇਹਨਾਂ ਨੂੰ ਚੰਗी ਤਰ੍ਹਾਂ ਬਣਾ ਕੇ ਹੀ ਛੱਡੋ—ਸਾਫ ਡਿਫ਼ਾਲਟਸ ਅਤੇ ਗਾਰਡਰੇਲਸ ਦੇ ਨਾਲ।
ਉਹ ਪ੍ਰਯੋਗ ਫਾਰਮੈਟ ਜਲਦੀ ਨਿਰਧਾਰਿਤ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸਹਿਯੋਗ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਜੋ UI, ਡੇਟਾ ਮਾਡਲ, ਅਤੇ ਸੌਂਪਣਾ ਲੌਜਿਕ ਇੱਕਸਾਰ ਰਹਿਣ:
ਸਪਸ਼ਟ ਰੱਖੋ ਤਾਂ ਕਿ “ਸਕੋਪ ਕ੍ਰੀਪ” ਨਾ ਹੋ ਕੇ ਟੂਲ ਨਾਜ਼ੁਕ ਬਿਜਨੈਸ-ਕ੍ਰੀਟਿਕਲ ਸਿਸਟਮ ਨਾ ਬਣ ਜਾਏ:
ਸਫਲਤਾ ਨੂੰ ਓਪਰੇਸ਼ਨਲ ਸ਼ਬਦਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਕੇਵਲ ਅੰਕੜਿਆਂ ਨਹੀਂ:
ਇੱਕ ਕੀਮਤ ਪ੍ਰਯੋਗ ਐਪ ਆਪਣੀ ਡੇਟਾ ਮਾਡਲ 'ਤੇ ਟਿਕਦੀ ਜਾਂ ਡਿੱਗਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਉੱਤਰ ਨਹੀਂ ਦੇ ਸਕਦੇ "ਇਸ ਗਾਹਕ ਨੇ ਕਿਹੜੀ ਕੀਮਤ ਕਦੋਂ ਵੇਖੀ?", ਤੁਹਾਡੇ ਮੈਟਰਿਕ ਸ਼ੋਰ ਹੋ ਜਾਣਗੇ ਅਤੇ ਟੀਮ ਦਾ ਭਰੋਸਾ ਘੱਟ ਹੋ ਜਾਵੇਗਾ।
ਛੋਟੀ ਜਿਹੀ ਕੋਰ ਈਨਟੀਟੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਕੀਮਤ ਅਸਲ ਵਿਚ ਤੁਸੀਂ ਆਪਣੇ ਉਤਪਾਦ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹੋ:
ਸਿਸਟਮਾਂ ਵਿੱਚ ਸਥਿਰ ਪਛਾਣਕਰਤਾ ਵਰਤੋ (product_id, plan_id, customer_id)। “ਸੁੰਦਰ ਨਾਂ” ਨੂੰ ਕੁੰਜੀ ਵਜੋਂ ਵਰਤਣ ਤੋਂ ਬਚੋ—ਉਹ ਬਦਲਦੇ ਹਨ।
ਸਮੇਂ ਦੇ ਫੀਲਡ ਵੀ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹਨ:
ਨਾਮੀਨਤ ਕਰੋ effective_from / effective_to Price ਰਿਕਾਰਡਾਂ 'ਤੇ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਸਮੇਂ 'ਤੇ ਕੀਮਤ ਦੁਬਾਰਾ ਪੁਨਰ ਨਿਰਮਾਣ ਕਰ ਸਕੋ।
ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਰਿਲੇਸ਼ਨਸ਼ਿਪ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਵਾਸਤਵ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ Event ਨੂੰ customer_id, experiment_id, ਅਤੇ variant_id ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ (ਜਾਂ ਜੁੜ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ)। ਜੇ ਤੁਸੀਂ ਸਿਰਫ customer_id ਸਟੋਰ ਕਰਦੇ ਹੋ ਅਤੇ “ਬਾਅਦ ਵਿੱਚ assignment ਵੇਖ ਲਵੋ”, ਤਾਂ ਜਦੋਂ assignments ਬਦਲਦੇ ਹਨ ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਜੋਇਨ ਕਰ ਸਕਦੇ ਹੋ।
ਕੀਮਤ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਆਡੀਟ-ਫ੍ਰੈਂਡਲੀ ਇਤਿਹਾਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੁੱਖ ਰਿਕਾਰਡਾਂ ਨੂੰ ਐਪੈਂਡ-ਓਨਲੀ ਬਣਾਓ:
ਇਸ ਤਰੀਕੇ ਨਾਲ ਰਿਪੋਰਟਿੰਗ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਆਡੀਟ ਲੌਗ ਵਰਗੇ ਗਵਰਨੈਂਸ ਫੀਚਰ ਆਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਈਸਿੰਗ ਪ੍ਰਯੋਗ ਮੈਨੇਜਰ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਲਾਈਫਸਾਈਕਲ ਲਾਜ਼ਮੀ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ ਹਰ ਕੋਈ ਸਮਝੇ ਕਿ ਕੀ ਸੰਪਾਦਨ ਯੋਗ ਹੈ, ਕੀ ਲਾਕ ਹੈ, ਅਤੇ ਪ੍ਰਯੋਗ ਦੀ ਸਥਿਤੀ ਬਦਲਣ 'ਤੇ ਗਾਹਕਾਂ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ।
Draft → Scheduled → Running → Stopped → Analyzed → Archived
ਖਤਰਨਾਕ ਲਾਂਚਾਂ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ, ਪ੍ਰਯੋਗ ਦੇ ਅੱਗੇ ਵੱਧਦੇ ਕਦਮਾਂ `ਤੇ ਲਾਜ਼ਮੀ ਫੀਲਡ ਲਗਾਓ:
ਕੀਮਤ ਲਈ, Finance ਅਤੇ Legal/Compliance ਲਈ ਵਿਕਲਪਿਕ ਗੇਟ ਜੋੜੋ। ਕੇਵਲ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲੇ Scheduled → Running ਵਿੱਚ ਜਾ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਓਵਰਰਾਈਡਸ ਦੀ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ (ਉਦਾਹਰਨ: ਤਤਕਾਲ ਰੋਲਬੈਕ), ਤਾਂ ਰਿਕਾਰਡ ਕਰੋ ਕਿ ਕਿਸਨੇ ਓਵਰਰਾਈਡ ਕੀਤਾ, ਕਿਉਂ, ਅਤੇ ਕਦੋਂ ਆਡੀਟ ਲੌਗ ਵਿੱਚ।
ਜਦੋਂ ਪ੍ਰਯੋਗ Stopped ਹੋਵੇ, ਤਦ ਦੋ ਵਿਵਕਲਪਿਕ ਬਿਹੇਵੀਅਰ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
Stop ਸਮੇਂ ਇਹ ਇੱਕ ਲਾਜ਼ਮੀ ਚੋਣ ਬਣਾਓ ਤਾਂ ਕਿ ਟੀਮ ਪ੍ਰਭਾਵ ਬਿਨਾਂ ਫੈਸਲੇ ਦੇ ਪ੍ਰਯੋਗ ਨਾ ਰੋਕੇ।
ਸੌਂਪਣਾ ਸਹੀ ਹੋਣਾ ਇਕ ਭਰੋਸੇਯੋਗ ਕੀਮਤ ਟੈਸਟ ਅਤੇ ਗਲਤ-ਸ਼ੁਧ ਸ਼ਬਦਾਂ ਵਿਚਕਾਰ ਫਰਕ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕਿਸ ਨੂੰ ਕੀਮਤ ਮਿਲੇਗੀ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਅਸਾਨ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਉ ਕਿ ਉਹ ਲਗਾਤਾਰ ਉਹੀ ਵੇਖਦੇ ਰਹਿਣ।
ਇੱਕ ਗਾਹਕ ਨੂੰ ਸੈਸ਼ਨਾਂ, ਡਿਵਾਈਸ (ਜਿੱਥੇ ਸੰਭਵ), ਅਤੇ ਰੀਫਰੈਸ਼ਾਂ 'ਤੇ ਇੱਕੋ ਵੈਰੀਐਂਟ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੌਂਪਣਾ ਨਿਰਣਾਇਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਇੱਕੋ assignment key ਅਤੇ ਪ੍ਰਯੋਗ ਦੇ ਦਿੱਤੇ ਜਾਣ 'ਤੇ ਨਤੀجہ ਹਮੇਸ਼ਾ ਇੱਕੋ ਹੋਵੇ।
ਆਮ ਤਰੀਕੇ:
(experiment_id + assignment_key) ਦਾ ਹੈਸ਼ ਕੈਲਕੂਲੇਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਵੈਰੀਐਂਟ ਵਿੱਚ ਮੈਪ ਕਰੋ।ਕਈ ਟੀਮ ਹੈਸ਼-ਅਧਾਰਿਤ ਸੌਂਪਣਾ ਡਿਫ਼ਾਲਟ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤਦੀਆਂ ਹਨ ਅਤੇ ਸਿਰਫ ਜ਼ਰੂਰਤ ਹੋਣ 'ਤੇ ਸੌਂਪਣੀਆਂ ਸਟੋਰ ਕਰਦੀਆਂ ਹਨ (ਸਹਿਯੋਗ ਮਾਮਲਿਆਂ ਜਾਂ ਗਵਰਨੈਂਸ ਲਈ)।
ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕਈ ਕੀ ਹਨਡੇ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੀਮਤ ਯੂਜ਼ਰ-ਸਤਰ ਜਾਂ ਅਕਾਉਂਟ-ਸਤਰ ਹੋ ਸਕਦੀ ਹੈ:
ਉਹ ਅਪਗਰੇਡ ਰਸਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜੇ ਕੋਈ ਵਿਅਕਤੀ ਅਣਪਛਾਤੇ ਤੌਰ 'ਤੇ ਬ੍ਰਾਊਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਖਾਤਾ ਬਣਾਉਂਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਉਹਨਾਂ ਦੀ ਮੂਲ ਵੈਰੀਐਂਟ (ਕੰਟਿਨਿਊਟੀ) ਰੱਖਣੀ ਹੈ ਜਾਂ ਮੁੜ-ਸੌਂਪਣਾ ਕਰਨੀ ਹੈ (ਸਾਫ਼ ਪਛਾਣ ਨਿਯਮ)। ਇਹ ਇੱਕ ਸਪਸ਼ਟ, ਵਿਵਚਾਰਿ ਤੈਅ ਰਹਿਣ ਵਾਲੀ ਸੈਟਿੰਗ ਬਣਾਓ।
ਲਚਕੀਲਾ ਵਰਐਲੋਕੇਸ਼ਨ ਸਮਰਥਨ ਕਰੋ:
ਰੈਂਪ ਕਰਨ ਵੇਲੇ, ਸੌਂਪਣਾ ਸਟੀਕੀ ਰੱਖੋ: ਟ੍ਰੈਫਿਕ ਵਧਾਉਣ ਨਾਲ ਨਵੇਂ ਯੂਜ਼ਰ ਪ੍ਰਯੋਗ 'ਚ ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਮੌਜੂਦਾ ਨੂੰ ਰੀਸ਼ਫਲਫਲ ਨਾ ਕੀਤਾ ਜਾਵੇ।
ਸਮਕਾਲੀ ਟੈਸਟ ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਕ-ਦੂਜਿਆਂ ਨਾਲ ਟਕਰਾਅ ਕਰ ਜਾਣ। ਇਹ ਗਾਰਡਰੇਲ ਬਣਾਓ:
“Assignment preview” ਸਕ੍ਰੀਨ (ਨਮੂਨਾ ਯੂਜ਼ਰ/ਅਕਾਉਂਟ ਦੇ ਲਈ) ਨਾਨ-ਟੈਕਨੀਕਲ ਟੀਮਾਂ ਨੂੰ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਕੀਮਤ ਪ੍ਰਯੋਗ ਆਮ ਤੌਰ 'ਤੇ ਇੰਟੇਗਰੇਸ਼ਨ ਪਰਤ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ—ਨਾ ਕਿ ਪ੍ਰਯੋਗ ਲੌਜਿਕ ਗਲਤ ਹੋਣ ਕਰਕੇ, ਪਰ ਇਸ ਕਾਰਨ ਕਿ ਉਤਪਾਦ ਇੱਕ ਸਥਾਨ 'ਤੇ ਇਕ ਕੀਮਤ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਚਾਰਜ ਦੂਜੇ 'ਤੇ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡੀ ਵੈੱਬ ਐਪ ਨੂੰ "ਕੀਮਤ ਕੀ ਹੈ" ਅਤੇ "ਉਤਪਾਦ ਉਸਨੂੰ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ" ਬਹੁਤ ਸਪਸ਼ਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਕੀਮਤ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਸਰੋਤ-ਅਸਲ ਸਮਝੋ (ਵੈਰੀਐਂਟ ਦੀ ਕੀਮਤ ਨੀਤੀ, ਪ੍ਰਭਾਵ ਤਾਰੀਖਾਂ, ਮੁਦਰਾ, ਟੈਕਸ ਹੈਂਡਲਿੰਗ ਆਦਿ)। ਕੀਮਤ ਡੈਲੀਵਰੀ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਸਮਝੋ ਜੋ ਚੁਣੇ ਹੋਏ ਵੈਰੀਐਂਟ ਦੀ ਕੀਮਤ API ਐਂਡਪੌਇੰਟ ਜਾਂ SDK ਰਾਹੀਂ ਲੈ ਕੇ ਦਿੰਦਾ ਹੈ।
ਇਹ ਵੰਡ ਪਰਯੋਗ ਪ੍ਰਬੰਧਨ ਟੂਲ ਨੂੰ ਸਾਫ਼ ਰੱਖਦੀ ਹੈ: ਗੈਰ-ਤਕਨੀਕੀ ਟੀਮਾਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਸੋਧਦੀਆਂ ਹਨ, ਇੰਜੀਨੀਅਰ ਇੱਕ ਥਿਰ ਡੈਲੀਵਰੀ ਸੰਝੌਤੇ (ਜੈਵਾਂ GET /pricing?sku=...) ਨੂੰ ਇੰਟੇਗਰੇਟ ਕਰਦੇ ਹਨ।
ਦੋ ਆਮ ਪੈਟਰਨ ਹਨ:
ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਤਰੀਕਾ “ਕਲਾਇੰਟ ਤੇ ਡਿਸਪਲੇ, ਸਰਵਰ ਤੇ ਪੁਸ਼ਟੀ ਅਤੇ ਗਣਨਾ” ਹੈ, ਜੋ ਇੱਕੋ ਪ੍ਰਯੋਗ ਸੌਂਪਣਾ ਵਰਤਦਾ ਹੈ।
ਵੈਰੀਐਂਟਾਂ ਨੂੰ ਉਹੀ ਨਿਯਮ ਮਾਨਣੇ ਚਾਹੀਦੇ ਹਨ:
ਇਹ ਨਿਯਮ ਕੀਮਤ ਨਾਲ ਨਾਲ ਹੀ Price ਰਿਕਾਰਡ ਦੇ ਨਾਲ ਸੰਭਾਲੋ ਤਾਂ ਕਿ ਹਰ ਵੈਰੀਐਂਟ ਤੁਲਨਾਤਮਕ ਅਤੇ ਫਾਇਨੈਂਸ-ਮਿੱਤਰ ਹੋਵੇ।
ਜੇ ਪ੍ਰਯੋਗ ਸਰਵਿਸ ਹੌਲੀ ਜਾਂ ਡਾਊਨ ਹੋ, ਤੁਹਾਡਾ ਉਤਪਾਦ ਸੇਫ਼ ਡੀਫਾਲਟ ਕੀਮਤ (ਅਕਸਰ ਮੌਜੂਦਾ ਬੇਸਲਾਈਨ) ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਟਾਈਮਆਊਟ, ਕੈਸ਼ਿੰਗ, ਅਤੇ ਇਕ "ਫੇਲ ਕਲੋਜ਼ਡ" ਨੀਤੀ ਤਿਆਰ ਕਰੋ ਤਾਂ ਕਿ ਚੈਕਆਊਟ ਟੁੱਟੇ ਨਾ—ਅਤੇ ਫੌਲਬੈਕ ਨੋਟ ਕਰੋ ਤਾਂ ਜੋ ਪ੍ਰਭਾਵ ਮਾਪਿਆ ਜਾ ਸਕੇ।
ਕੀਮਤ ਪ੍ਰਯੋਗ ਮਾਪਣ 'ਤੇ ਹੀ ਜੀਵਤ ਜਾਂ ਮਰਨ ਹੁੰਦੇ ਹਨ। ਤੁਹਾਡੀ ਵੈੱਬ ਐਪ ਨੂੰ “ਸ਼ਿਪ ਕਰ ਦੇਖੀਏ” ਕਰਨ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਣ ਲਈ ਸਪਸ਼ਟ ਸਫਲਤਾ ਮੈਟਰਿਕ, ਸਾਫ ਇਵੈਂਟਸ, ਅਤੇ ਲਗਾਤਾਰ ਐਟ੍ਰਿਬਿਊਸ਼ਨ ਆਪਣੀ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਲਾਜ਼ਮੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਜਾਂ ਦੋ ਮੈਟਰਿਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਜਿੱਤ ਦਰ ਨਿਰਧਾਰਨ ਲਈ ਵਰਤੋਂਗੇ। ਆਮ ਚੋਣਾਂ:
ਇੱਕ ਸਹਾਇਕ ਨਿਯਮ: ਜੇ ਟੀਮ ਟੈਸਟ ਤੋਂ ਬਾਅਦ ਨਤੀਜੇ ਉੱਤੇ ਵਿਰੋਧ ਕਰਦੀ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਫੈਸਲਾ ਮੈਟਰਿਕ ਠੀਕ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕੀਤਾ।
ਗਾਰਡਰੇਲ ਖ਼ਤਰਾ ਫੜਦੇ ਹਨ ਜੋ ਉੱਚ ਕੀਮਤ ਦੇ ਨਾਲ ਹੋ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਛੋਟੇ ਸਮੇਂ ਦੀ ਆਮਦਨ ਚੰਗੀ ਲੱਗੇ:
ਤੁਹਾਡੀ ਐਪ ਗਾਰਡਰੇਲ ਲਾਗੂ ਕਰ ਸਕਦੀ ਹੈ ਦੁਆਰਾ ਤਹਿ ਕਰਨ ਵਾਲੇ ਸੀਮਾਵਾਂ ਦੀ ਲੋੜ (ਉਦਾਹਰਨ: “ਰਿਫੰਡ ਰੇਟ 0.3% ਤੋਂ ਵੱਧ ਨਾ ਵਧੇ”) ਅਤੇ ਪ੍ਰਯੋਗ ਪੰਨੇ 'ਤੇ ਉਲੰਘਣਾ ਦਰਸਾ ਸਕਦੀ ਹੈ।
ਘੱਟੋ-ਘੱਟ, ਤੁਹਾਡੇ ਟਰੈਕਿੰਗ ਵਿੱਚ ਪ੍ਰਯੋਗ ਅਤੇ ਵੈਰੀਐਂਟ ਲਈ ਸਥਿਰ ਪਛਾਣਕਰਤਾ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਹਰ ਸੰਬੰਧਿਤ ਇਵੈਂਟ ਤੇ।
{
"event": "purchase_completed",
"timestamp": "2025-01-15T12:34:56Z",
"user_id": "u_123",
"experiment_id": "exp_earlybird_2025_01",
"variant_id": "v_price_29",
"currency": "USD",
"amount": 29.00
}
ਇਹ ਪ੍ਰਾਪਰਟੀਜ਼ ਇੰਜੈਸ਼ਨ ਸਮੇਂ ਲਾਜ਼ਮੀ ਬਣਾਓ, “ਸ਼ੁਭ-ਪਰਯਾਸ” ਨਹੀਂ। ਜੇ ਕੋਈ ਇਵੈਂਟ experiment_id/variant_id ਤੋਂ ਬਿਨਾਂ ਆਵੇ, ਤਾਂ ਉਸਨੂੰ "unattributed" ਬੱਕੇਟ ਵਿੱਚ ਰੂਟ ਕਰੋ ਅਤੇ ਡੇਟਾ ਗੁਣਵੱਤਾ ਮੁੱਦੇ ਝੰਡਾ ਲਗਾਓ।
ਕੀਮਤ ਦੇ ਨਤੀਜੇ ਅਕਸਰ ਦੇਰ ਨਾਲ ਆਉਂਦੇ ਹਨ (ਪੁਨਰ-ਨਵੀਨੀਕਰਨ, ਅਪਗ੍ਰੇਡ, ਛੱਡਣਾ)। ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਇਸ ਨਾਲ ਟੀਮਾਂ ਸਮਝਦੀਆਂ ਹਨ ਕਿ ਨਤੀਜਾ ਕਦੋਂ ਭਰੋਸੇਯੋਗ ਹੋਵੇਗਾ—ਅਤੇ ਅਣਗਹਿਲੇ ਫੈਸਲਿਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਾਈਸਿੰਗ ਪ੍ਰਯੋਗ ਟੂਲ ਕੇਵਲ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਡਕਟ ਮੈਨੇਜਰ, ਮਾਰਕੀਟਿੰਗ ਅਤੇ ਫਾਇਨੈਂਸ ਉਸਨੂੰ ਬਿਨਾਂ ਹਰ ਕਲਿੱਕ ਲਈ ਇੰਜੀਨੀਅਰ ਦੀ ਲੋੜ ਤੋਂ ਚਲਾਉ ਸਕਣ। UI ਨੂੰ ਤਿੰਨ ਸਵਾਲ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ? ਗਾਹਕਾਂ ਲਈ ਕੀ ਬਦਲਣ ਵਾਲਾ ਹੈ? ਕੀ ਹੋਇਆ ਅਤੇ ਕਿਉਂ?
Experiment list ਨੂੰ ਇੱਕ ਓਪਰੇਸ਼ਨ ਡੈਸ਼ਬੋਰਡ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਓ। ਦਿਖਾਓ: ਨਾਂ, ਸਥਿਤੀ (Draft/Scheduled/Running/Paused/Ended), ਸ਼ੁਰੂ/ਅੰਤ ਮਿਤੀਆਂ, ਟ੍ਰੈਫਿਕ ਸਪਲਿਟ, ਪ੍ਰਾਇਮਰੀ ਮੈਟਰਿਕ, ਅਤੇ ਮਲਿਕ। ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ “last updated by” ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਜੋੜੋ ਤਾਂ ਕਿ ਲੋਕ ਜੋਖਮ ਤੇ ਭਰੋਸਾ ਕਰਨ।
Experiment detail ਘਰ ਦਾ ਕੇਂਦਰ ਹੈ। ਉੱਪਰ ਇੱਕ ਸੰਕੁਚਿਤ ਸਾਰ ਦੇਵੋ (ਸਥਿਤੀ, ਤਾਰਿੱਖਾਂ, ਦਰਸ਼ਕ, ਸਪਲਿਟ, ਪ੍ਰਾਇਮਰੀ ਮੈਟਰਿਕ)। ਇਸ ਤੋਂ ਹੇਠਾਂ ਟੈਬਜ਼ ਜਿਵੇਂ Variants, Targeting, Metrics, Change log, ਅਤੇ Results ਰੱਖੋ।
Variant editor ਸਪਸ਼ਟ ਅਤੇ ਅਧਿਕਾਰਪੂਰਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਹਰ ਵੈਰੀਐਂਟ ਰੋ ਵਿੱਚ ਕੀਮਤ (ਜਾਂ ਕੀਮਤ ਨਿਯਮ), ਮੁਦਰਾ, ਬਿਲਿੰਗ ਅੰਤਰਾਲ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ-ਅੰਗਰੇਜ਼ੀ ਵਰਣਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (“Annual plan: $120 → $108”)। ਲਾਈਵ ਵੈਰੀਐਂਟ ਨੂੰ ਗਲਤੀ ਨਾਲ ਸੋਧਣ ਨੂੰ ਔਖਾ ਬਣਾਓ—ਪੁਸ਼ਟੀ ਦੀ ਲੋੜ ਰੱਖੋ।
Results view ਨੂੰ ਫੈਸਲੇ ਨਾਲ ਅਗੇ ਲੈ ਕੇ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਚਾਰਟ ਨਹੀਂ: “Variant B ਨੇ ਚੈੱਕਆਊਟ ਕਨਵਰਜ਼ਨ 2.1% ਨਾਲ ਵਧਾਇਆ (95% CI …).” ਫਿਰ ਸਹਾਇਕ ਡ੍ਰਿਲ-ਡਾਊਨ ਅਤੇ ਫਿਲਟਰ ਦਿਓ।
ਲਪੇਟ ਬੈਜਾਂ ਇਕਸਾਰ ਵਰਤੋ ਅਤੇ ਮੁੱਖ ਤਾਰੀਖਾਂ ਦੀ ਟਾਈਮਲਾਈਨ ਦਿਖਾਓ। ਟ੍ਰੈਫਿਕ ਸਪਲਿਟ ਨੂੰ ਪ੍ਰਤਿਸ਼ਤ ਅਤੇ ਛੋਟੀ ਬਾਰ ਦੋਹਾਂ ਰੂਪਾਂ ਵਿੱਚ ਦਿਖਾਓ। "Who changed what" ਪੈਨਲ (ਜਾਂ ਟੈਬ) ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਵੈਰੀਐਂਟਸ, ਟਾਰਗੇਟਿੰਗ, ਅਤੇ ਮੈਟਰਿਕਸ ਦੇ ਸੋਧ ਦਿਖਾਵੇ।
Start ਦੀ ਆਗਿਆ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਲਾਜ਼ਮੀ ਬਣਾਓ: ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟਰਿਕ ਚੁਣੀ ਹੋਈ ਹੋਵੇ, ਘੱਟੋ-ਘੱਟ ਦੋ ਵੈਰੀਐਂਟ ਭਲੀ-ਭਾਂਤੀ ਕੀਮਤਾਂ ਨਾਲ, ਇੱਕ ਪਰਿਭਾਸ਼ਿਤ ਰੈਂਪ ਯੋਜਨਾ (ਵਿਕਲਪਿਕ ਪਰ ਸਿਫ਼ਾਰਸ਼ੀ), ਅਤੇ ਇੱਕ ਰੋਲਬੈਕ ਯੋਜਨਾ ਜਾਂ ਫੌਲਬੈਕ ਕੀਮਤ। ਜੇ ਕੋਈ ਚੀਜ਼ ਗੁੰਮ ਹੈ, ਤਾਂ ਕਾਰਵਾਈਯੋਗ ਤ੍ਰੁੱਟੀਆਂ ਦਿਖਾਓ (“ਨਤੀਜੇ ਯੋਗ ਬਣਾਉਣ ਲਈ ਪ੍ਰਾਇਮਰੀ ਮੈਟਰਿਕ ਜੋੜੋ”)।
ਸੁਰੱਖਿਅਤ, ਪ੍ਰਮੁੱਖ ਕਾਰਵਾਈਆਂ ਦਿਓ: Pause, Stop, Ramp up (ਉਦਾਹਰਨ: 10% → 25% → 50%), ਅਤੇ Duplicate (ਸੈਟਿੰਗਾਂ ਨੂੰ ਨਵੇਂ Draft ਵਿੱਚ ਨਕਲ ਕਰੋ)। ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀ ਜੋ ਪ੍ਰਭਾਵ ਦਾ ਸਾਰ ਸੰਖੇਪ ਕਰਦੀ ਹੋਵੇ (“Pausing assignments ਨੂੰ freeze ਕਰਦੀ ਹੈ ਅਤੇ exposure ਰੋਕਦੀ ਹੈ”)।
ਜੇ ਤੁਸੀਂ ਵਰਕਫਲੋ (Draft → Scheduled → Running) ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੇ ਬਿਲਡ ਵਿੱਚ ਨਿਵੇਸ਼ ਕੀਤੇ, ਤਾਂ Koder.ai ਵਰਗਾ vibe-coding ਪਲੈਟਫਾਰਮ ਤੁਹਾਨੂੰ ਇੱਕ ਚੈਟ-ਆਧਾਰਤ ਸਪੈੱਕ ਤੋਂ ਇੱਕ ਅੰਦਰੂਨੀ ਵੈੱਬ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਫਿਰ ਭੂਮਿਕਾ-ਅਧਾਰਿਤ ਸਕ੍ਰੀਨ, ਆਡੀਟ ਲੌਗ, ਅਤੇ ਸਧਾਰਨ ਡੈਸ਼ਬੋਰਡ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰੋ। ਇਹ ਉਨ੍ਹਾਂ ਪ੍ਰਾਰੰਭਿਕ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਲਈ ਖਾਸ ਕਰਕੇ ਲਾਭਦਾਇਕ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ React UI ਅਤੇ Go/PostgreSQL ਬੈਕਐਂਡ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਨਿਰਭਰਤਾ ਲਈ ਐਕਸਪੋਰਟ ਕੀਤਾ ਜਾ ਸਕੇ।
ਇੱਕ ਪ੍ਰਾਈਸਿੰਗ ਪ੍ਰਯੋਗ ਡੈਸ਼ਬੋਰਡ ਨੇ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: “ਕੀ ਅਸੀਂ ਇਹ ਕੀਮਤ ਰੱਖੀਏ, ਰੋਲਬੈਕ ਕਰੀਏ, ਜਾਂ ਹੋਰ ਸਿੱਖੀਏ?” ਸਭ ਤੋਂ ਵਧੀਆ ਰਿਪੋਰਟਿੰਗ ਸਭ ਤੋਂ ਸੋਧਣਯੋਗ ਨਹੀਂ—ਇਹ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਅਤੇ ਸਮਝਾਉਣ ਵਿੱਚ ਆਸਾਨ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਛੋਟੇ ਟ੍ਰੇਨਡ ਚਾਰਟ ਜੋ ਆਟੋਮੈਟਿਕ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ ਰੱਖੋ:
ਚਾਰਟਾਂ ਹੇਠਾਂ, ਇੱਕ ਵੈਰੀਐਂਟ ਤੁਲਨਾ ਟੇਬਲ ਸ਼ਾਮਲ ਕਰੋ: ਵੈਰੀਐਂਟ ਨਾਂ, ਟ੍ਰੈਫਿਕ ਹਿੱਸਾ, ਵਿਜ਼ਟਰ, ਖਰੀਦ, ਕਨਵਰਜ਼ਨ ਰੇਟ, ਰਿਵੈਨਿਊ ਪ੍ਰਤੀ ਵਿਜ਼ਟਰ, ਅਤੇ delta vs control।
ਕਾਨਫ਼ਿਡੈਂਸ ਲਈ, ਅਕਾਦਮਿਕ ਸ਼ਬਦਾਂ ਤੋਂ ਬਚੋ। ਸਾਧਾ ਲੇਬਲ ਵਰਤੋ:
ਛੋਟੀ ਟੂਲਟਿਪ ਨਾਲ ਸਮਝਾਉ ਕਿ ਕਾਨਫ਼ਿਡੈਂਸ ਸੈਂਪਲ ਸਾਈਜ਼ ਅਤੇ ਸਮੇਂ ਨਾਲ ਵੱਧਦੀ ਹੈ।
ਕੀਮਤ ਅਕਸਰ ਕੁੱਲ ਮਿਲਾਕੇ ਜਿੱਤਦੀ ਹੈ ਪਰ ਕੁੰਜੀ ਗਰੁੱਪਾਂ ਲਈ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ। ਸੈਗਮੈਂਟ ਟੈਬਜ਼ ਸੌਖੇ ਬਣਾਓ:
ਹਰ ਥਾਂ ਉਹੀ ਮੈਟਰਿਕਸ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਲਨਾ ਇਕਸਾਰ ਮਹਿਸੂਸ ਹੋਵੇ।
ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਹਲਕੇ-ਫੁਲਕੇ ਅਲਰਟ ਸ਼ਾਮਲ ਕਰੋ:
ਜਦੋਂ ਅਲਰਟ ਆਵੇ, ਤਾਂ ਸੰਭਾਵਿਤ ਖਿੱਤ ਅਤੇ ਕੱਚਾ ਇਵੈਂਟ ਸਥਿਤੀ ਲਿੰਕ ਦਿਖਾਓ।
ਰਿਪੋਰਟਿੰਗ ਨੰੂ ਪੋਰਟੇਬਲ ਬਣਾਓ: ਵਰਤਮਾਨ ਦਰਸ਼ਨ ਲਈ CSV ਡਾਊਨਲੋਡ (ਸੈਗਮੈਂਟ ਸਮੇਤ) ਅਤੇ ਪ੍ਰਯੋਗ ਰਿਪੋਰਟ ਲਈ ਸਾਂਝਾ ਅੰਦਰੂਨੀ ਲਿੰਕ। ਜੇ ਲੋੜ ਹੋਵੇ, ਇੱਕ ਛੋਟਾ ਵਿਆਖਿਆਕਾਰ ਵੀ ਲਿੰਕ ਕਰੋ ਜਿਵੇਂ /blog/metric-guide ਤਾਂ ਕਿ ਸਟੇਕਹੋਲਡਰ ਬਿਨਾਂ ਮਿਲਣ ਦੇ ਸਮਝ ਸਕਣ ਜੋ ਉਹ ਦੇਖ ਰਹੇ ਹਨ।
ਕੀਮਤ ਪ੍ਰਯੋਗ ਰੇਵੇਨਿਊ, ਗਾਹਕੀ ਭਰੋਸਾ, ਅਤੇ ਅਕਸਰ ਨਿਯਮਤ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਛੂਹਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਅਤੇ ਸਪਸ਼ਟ ਆਡੀਟ ਟਰੇਲ ਅਕਸਰ ਗਲਤ ਲਾਂਚਾਂ ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ, “ਕਿਸਨੇ ਇਹ ਬਦਲਿਆ?” ਦੀਆਂ ਚੁੱਪੀਆਂ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਛੱਡਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਰੋਲ ਆਸਾਨ ਸਮਝਣ ਯੋਗ ਅਤੇ ਗਲਤੀ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਰੱਖੋ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਉਤਪਾਦ ਜਾਂ ਖੇਤਰ ਹਨ, ਤਾਂ ਰੋਲਾਂ ਨੂੰ workspace ਦੁਆਰਾ ਸਕੋਪ ਕਰੋ ਤਾਂ ਜੋ ਇੱਕ ਖੇਤਰ ਦਾ ਐਡੀਟਰ ਦੂਸਰੇ 'ਤੇ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾ ਸਕੇ।
ਤੁਹਾਡੀ ਐਪ ਹਰ ਬਦਲਾਅ ਨੂੰ ਕਿਸਨੇ, ਕੀ, ਕਦੋਂ ਨਾਲ ਲੌਗ ਕਰੇ। ਘੱਟੋ-ਘੱਟ ਰਿਕਾਰਡ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਇਵੈਂਟ:
ਲੌਗਸ ਨੂੰ ਖੋਜਯੋਗ ਅਤੇ ਐਕਸਪੋਰਟੇਬਲ (CSV/JSON) ਬਣਾਓ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਯੋਗ ਪੰਨੇ ਨਾਲ ਸਿੱਧਾ ਜੋੜੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆਕਾਰ ਢੂਂਢਣ ਨਾ ਪੈਂ। ਇੱਕ ਨਿਰਧਾਰਤ /audit-log ਵਿਊ ਕੰਪਲਾਇੰਸ ਟੀਮਾਂ ਲਈ ਮਦਦਗਾਰ ਹੈ।
ਗਾਹਕ ਪਛਾਣਕਰਤਾ ਅਤੇ ਰੇਵੇਨਿਊ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਮੰਨੋ:
ਹਰ ਪ੍ਰਯੋਗ ਤੇ ਹਲਕੇ ਨੋਟਸ ਜੋੜੋ: ਹਾਈਪੋਥੇਸਿਸ, ਉਮੀਦ ਕੀਤੀ ਪ੍ਰਭਾਵ, ਮਨਜ਼ੂਰੀ ਤਰਕ, ਅਤੇ "ਕਿਉਂ ਰੋਕਿਆ" ਦਾ ਸਾਰ। ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਇਹ ਨੋਟਸ ਅਸਫਲ ਵਿਚਾਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਤੋਂ ਰੋਕਦੇ ਹਨ—ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ।
ਕੀਮਤ ਪ੍ਰਯੋਗ ਬਾਰੀਕ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ: 50/50 ਸਪਲਿੱਟ 62/38 ਤੇ ਵੰਞ ਜਾਂਦਾ ਹੈ, ਇਕ ਕੋਹੋਰਟ ਵੱਖਰੀ ਮੁਦਰਾ ਵੇਖਦੀ ਹੈ, ਜਾਂ ਇਵੈਂਟ ਰਿਪੋਰਟਾਂ ਵਿੱਚ ਕਦੇ ਆਉਂਦੇ ਹੀ ਨਹੀਂ। ਅਸਲੀ ਗਾਹਕਾਂ ਨੂੰ ਨਵੀਂ ਕੀਮਤ ਵੇਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰਯੋਗ ਸਿਸਟਮ ਨੂੰ ਭੁਗਤਾਨ ਫੀਚਰ ਵਾਂਗ ਟੈਸਟ ਕਰੋ—ਵਿਹਿਵਹਾਰ, ਡੇਟਾ, ਅਤੇ ਫੇਲਯਰਨ ਮੋਡਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਨਿਰਧਾਰਿਤ ਟੈਸਟ ਕੇਸਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕੋ ਕਿ ਸੌਂਪਣਾ ਲੌਜਿਕ ਸੇਵਾਵਾਂ ਅਤੇ ਰੀਲੀਜ਼ਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ 'ਚ ਸਥਿਰ ਹੈ। ਠੋਸ ਇਨਪੁਟ (customer IDs, experiment keys, salt) ਵਰਤ ਕੇ ਇਹ ਦਾਅਵਾ ਕਰੋ ਕਿ ਸੌਂਪਣਾ ਹਰ ਵਾਰੀ ਇੱਕੋ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ।
customer_id=123, experiment=pro_annual_price_v2 -> variant=B
customer_id=124, experiment=pro_annual_price_v2 -> variant=A
ਫਿਰ ਸਕੇਲ 'ਤੇ ਵੰਡ ਦੀ ਜਾਂਚ ਕਰੋ: ਉਦਾਹਰਨ ਲਈ 1M ਸਿੰਥੇਟਿਕ customer IDs ਬਣਾਓ ਅਤੇ ਦੇਖੋ ਕਿ ਨਿਰੀਕਸ਼ਿਤ ਸਪਲਿਟ ਇੱਕ ਸਖ਼ਤ tolerance ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ (ਉਦਾਹਰਨ: 50% ± 0.5%)। ਟ੍ਰੈਫਿਕ ਕੈਪ (ਕੇਵਲ 10% ਨਿਵੇਸ਼) ਅਤੇ "ਹੋਲਡਆਊਟ" ਗਰੁੱਪਾਂ ਵਰਗੇ ਐਜ ਕੇਸ ਵੀ ਵੈਰੀਫਾਈ ਕਰੋ।
“ਇਵੈਂਟ ਫਾਇਰ ਹੋਇਆ” 'ਤੇ ਹੀ ਰੁਕੋ ਨਾ। ਇੱਕ ਆਟੋਮੇਟਡ ਫ਼ਲੋ ਜੋ ਇੱਕ ਟੈਸਟ ਸੌਂਪਣਾ ਬਣਾਉਂਦਾ ਹੈ, ਖਰੀਦ ਜਾਂ ਚੈਕਆਊਟ ਇਵੈਂਟ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਪੱਕਾ ਕਰਦਾ ਹੈ ਕਿ:
ਇਸਨੂੰ ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਦੋਹਾਂ ਵਿੱਚ ਇੱਕ ਟੈਸਟ ਪ੍ਰਯੋਗ ਨਾਲ ਚਲਾਓ ਜੋ ਕੇਵਲ ਅੰਦਰੂਨੀ ਯੂਜ਼ਰਾਂ ਤੱਕ ਸੀਮਤ ਹੋਵੇ।
QA ਅਤੇ PMs ਨੂੰ ਇੱਕ ਸਧਾਰਨ “ਪ੍ਰੀਵਿਊ” ਟੂਲ ਦਿਓ: ਇੱਕ customer ID (ਜਾਂ session ID) ਦਿਓ ਅਤੇ ਵੇਖੋ ਕਿ ਉਸਨੂੰ ਕਿਹੜਾ ਵੈਰੀਐਂਟ ਅਤੇ ਅਸਲੀ ਕੀਮਤ ਕੀ ਰੇਂਡਰ ਹੋਵੇਗੀ। ਇਹ ਗਲਤ ਗੋਲ-ਗੋਲ, ਮੁਦਰਾ, ਟੈਕਸ ਡਿਸਪਲੇ, ਅਤੇ "ਗਲਤ ਪਲਾਨ" ਮੁੱਦਿਆਂ ਨੂੰ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਫੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਅੰਦਰੂਨੀ ਰਾਹ ਜਿਵੇਂ /experiments/preview 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜੋ ਅਸਲ ਸੌਂਪਣੀਆਂ ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ।
ਉਘੜੇ ਪਰੀਖਣਾਂ ਅਭਿਆਸ ਕਰੋ:
ਜੇ ਤੁਸੀਂ "ਜੇ X ਟੁੱਟੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ" ਦਾ ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਰਿਲੀਜ਼ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ।
ਇੱਕ ਪ੍ਰਾਈਸਿੰਗ ਪ੍ਰਯੋਗ ਮੈਨੇਜਰ ਰਿਲੀਜ਼ ਕਰਨਾ ਸਿਰਫ਼ "ਇਕ ਸਕ੍ਰੀਨ ਸ਼ਿਪ ਕਰਨਾ" ਨਹੀਂ—ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਤੁਸੀਂ ਬਲਾਸਟ ਰੇਡੀਅਸ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ, ਵਰਤਾਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਨਿਰੀਖਣ ਕਰ ਸਕਦੇ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਹਾਲੀ ਕਰ ਸਕਦੇ।
ਆਪਣੀ ਲਾਂਚ ਕੋਲ ਇੱਕ ਰਸਤਾ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਯਕੀਨ ਅਤੇ ਉਤਪਾਦ ਸੀਮਾਵਾਂ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ:
ਮਾਨੀਟਰਨਿੰਗ ਨੂੰ ਇੱਕ ਰਿਲੀਜ਼ ਲਾਜ਼ਮੀ ਮੰਗ ਬਣਾਓ, ਨਾ ਕਿ "ਵਧੀਆ ਹੋਵੇ"। ਅਲਰਟ ਸੈਟ ਕਰੋ:
ਆਪਰੇਸ਼ਨ ਅਤੇ on-call ਲਈ ਲਿਖਤੀ ਰਨਬੁੱਕ ਬਣਾਓ:
ਜਦੋਂ ਕੋਰ ਵਰਕਫਲੋ ਸਥਿਰ ਹੋ ਜਾਵੇ, ਤਾਂ ਅਗਲੇ ਅਪਗ੍ਰੇਡਾਂ ਨੂੰ ਪਹਿਲ ਦਿਓ ਜੋ ਬਿਹਤਰ ਫੈਸਲੇ ਖੋਲ੍ਹਣ: ਟਾਰਗੇਟਿੰਗ ਨਿਯਮ (geo, plan, customer type), ਮਜ਼ਬੂਤ ਸਟੈਟਸ ਅਤੇ ਗਾਰਡਰੇਲ, ਅਤੇ ਇੰਟੇਗਰੇਸ਼ਨ (ਡੇਟਾ ਵੇਅਰਹਾਊਸ, ਬਿਲਿੰਗ, CRM)। ਜੇ ਤੁਸੀਂ ਟੀਅਰਾਂ ਜਾਂ ਪੈਕੇਜਿੰਗ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਸੋਚੋ ਪ੍ਰਯੋਗ ਸਮਰਥਕਤਾਵਾਂ ਨੂੰ /pricing 'ਤੇ ਦਿਖਾਉਣ ਦਾ ਤਾਂ ਜੋ ਟੀਮਾਂ ਸਮਝ ਸਕਣ ਕਿ ਕੀ ਸਹਿਯੋਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਇਹ ਇੱਕ ਅੰਦਰੂਨੀ ਕੰਟਰੋਲ ਪੈਨਲ ਅਤੇ ਟ੍ਰੈਕਿੰਗ ਲੇਅਰ ਹੈ ਜੋ ਕੀਮਤ ਟੈਸਟਾਂ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਇਹ ਟੀਮਾਂ ਨੂੰ ਪ੍ਰਯੋਗ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ (ਹਾਈਪੋਥੇਸਿਸ, ਦਰਸ਼ਕ, ਵੈਰੀਐਂਟ), ਸਤਹਾਂ 'ਤੇ ਇਕਸਾਰ ਕੀਮਤ ਦਿਖਾਉਣ, ਐਟ੍ਰਿਬਿਊਸ਼ਨ-ਤਿਆਰ ਇਵੈਂਟ ਇਕੱਠੇ ਕਰਨ ਅਤੇ ਸ਼ੁਰੂ/ਰੋਕ/ਪੌਜ਼ ਕਰਨ ਸਮੇਤ ਆਡੀਟ ਯੋਗਤਾ ਦੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਇਹ ਜਾਣ-ਬੁਝ ਕੇ ਪੂਰੇ ਬਿਲਿੰਗ ਜਾਂ ਟੈਕਸ ਇੰਜਣ ਨਹੀਂ ਹੈ; ਇਹ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਪ੍ਰਾਈਸਿੰਗ/ਬਿਲਿੰਗ ਸਟੈਕ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਆਯੋਜਿਤ ਕਰਦਾ ਹੈ।
ਇਕ ਵਰਤੋਗਯ MVP ਵਿੱਚ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਹ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜੇ ਇਹ ਭਰੋਸੇਯੋਗ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਨਿਸ਼ਾਨੇਬੰਦੀ ਅਤੇ ਰਿਪੋਰਟਿੰਗ 'ਤੇ ਿਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ।
ਉਹ ਕੋਰ ਈਨਟੀਟੀਆਂ ਮਾਡਲ ਕਰੋ ਜੋ ਤਰਕੀਬਨ ਇਹ ਪਤਾ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ: “ਇਸ ਗ੍ਰਾਹਕ ਨੂੰ ਕਿਹੜੀ ਕੀਮਤ ਕਦੋਂ ਦਿੱਤੀ ਗਈ ਸੀ?” ਆਮ ਤੌਰ 'ਤੇ:
ਮੁੱਖ ਇਤਿਹਾਸਕ ਰਿਕਾਰਡਾਂ ਨੂੰ ਮੁੜ ਲਿਖਣ ਤੋਂ ਬਚੋ: ਕੀਮਤਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ ਅਤੇ assignment ਰਿਕਾਰਡਆਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਦੀ ਬਜਾਏ ਨਵੇਂ ਰਿਕਾਰਡ ਜੋੜੋ।
ਇੱਕ ਤਰਕਸ਼ੀਲ ਲਾਈਫਸਾਈਕਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜਿਵੇਂ Draft → Scheduled → Running → Stopped → Analyzed → Archived।
ਲਾਈਵ ਹੋਣ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡਾਂ ਨੂੰ ਲਾਕ ਕਰੋ (variants, targeting, split) ਅਤੇ ਰਾਜੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵੈਧਤਾ ਲਗਾਉਣ (ਮੈਟਰਿਕਸ ਚੁਣੇ ਜਾਣੇ, ਟਰੈੱਕਿੰਗ ਪੱਕੀ ਹੋਣ, ਰੋਲਬੈਕ ਯੋਜਨਾ)। ਇਹ “ਮਿੱਡ-ਟੈਸਟ ਸੋਧ” ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਨਤੀਜਿਆਂ ਨੂੰ ਅਣਠੀਕ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਗਾਹਕ ਅਸਥਿਰਤਾ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਸਟੀਕੀ ਸੌਂਪਣਾ ਵਰਤੋ ਤਾਂ ਜੋ ਇੱਕੋ ਗ੍ਰਾਹਕ ਨੂੰ ਸੈਸ਼ਨ/ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਦਾ ਇੱਕੋ ਵੈਰੀਐਂਟ ਮਿਲੇ। ਆਮ ਤਰੀਕੇ:
(experiment_id + assignment_key) ਦਾ ਹੈਸ਼ ਲਵੋ ਅਤੇ ਵੈਰੀਐਂਟ ਬੱਕੇਟ ਨਿਰਧਾਰਤ ਕਰੋਕਾਰਜਕਾਰੀ ਤੌਰ ਤੇ ਕਈ ਟੀਮ ਪਹਿਲਾਂ ਹੈਸ਼ ਵਰਤਦੀਆਂ ਹਨ ਅਤੇ ਜ਼ਰੂਰਤ ਪੋਣ 'ਤੇ ਹੀ ਸੌਂਪਣੀਆਂ ਸਟੋਰ ਕਰਦੀਆਂ ਹਨ।
ਆਪਣੇ ਉਤਪਾਦ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮੇਲ ਖਾਵੇ ਇਹ ਵਿਵਚਾਰ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਅਤਿਰਿਕਤ ਤੌਰ 'ਤੇ ਅਣਪਛਾਤੇ ਸਟਾਰਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਾਈਨਅੱਪ/ਲੌਗਿਨ 'ਤੇ identity upgrade ਨੀਤੀ ਸਪਸ਼ਟ ਰੱਖੋ (ਮੂਲ ਵੈਰੀਐਂਟ ਰੱਖਣ ਲਈ continuity ਜਾਂ ਮੁੜ ਫੈਸਲਾ ਕਰਨ ਲਈ reassign)।
“Stop” ਮੁੜ-ਕਾਰਜ ਲਈ ਦੋ ਅਲੱਗ ਫੈਸਲੇ ਹਨ:
Stop ਕਰਨ ਵੇਲੇ ਇਹ ਚੋਣ ਲਾਜ਼ਮੀ ਬਣਾਓ ਤਾਂ ਕਿ ਟੀਮ ਕਿਸੇ ਨਿਰਣੇ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਯੋਗ ਨਾ ਰੋਕ ਸਕੇ।
ਇੱਕੋ ਵੈਰੀਐਂਟ ਦਿਖਾਉਣ ਅਤੇ ਚਾਰਜ ਕਰਨ ਵਿੱਚ ਗਲਤੀ ਤੋਂ ਬਚਣ ਲਈ:
ਸੇਵਾ ਧੀਮੀ ਜਾਂ ਡਾਊਨ ਹੋਣ 'ਤੇ ਸੇਫ਼ ਡિફੌਲਟ (ਆਮ ਤੌਰ 'ਤੇ ਬੇਸਲਾਈਨ) ਨੂੰ ਵੇਖੋ ਅਤੇ ਹਰFallback ਨੂੰ ਲੌਗ ਕਰੋ ਤਾਂ ਕਿ ਪ੍ਰਭਾਵ ਮਾਪਿਆ ਜਾ ਸਕੇ।
ਹਰ ਲੈਣ-ਦੈਨ ਸਮਗਰੀ ਇਵੈਂਟ ਵਿੱਚ experiment_id ਅਤੇ variant_id ਵਰਤਣਾ ਲਾਜ਼ਮੀ ਰੱਖੋ। ਆਮ ਤੌਰ 'ਤੇ ਟਰੈਕ ਕਰੋ:
ਜੇ ਕੋਈ ਇਵੈਂਟ / ਤੋਂ ਬਿਨਾਂ ਆਉਂਦਾ ਹੈ, ਉਸਨੂੰ “unattributed” ਬੱਕੇਟ ਵਿੱਚ ਰੂਟ ਕਰੋ ਅਤੇ ਡੇਟਾ ਗੁਣਵੱਤਾ ਮਾਮਲੇ ਨੋਟੀਫਾਈ ਕਰੋ।
ਇੱਕ ਸਧਾਰਨ ਰੋਲ ਮਾਡਲ ਅਤੇ ਪੂਰਾ ਆਡੀਟ ਟਰੇਲ ਵਰਤੋ:
ਇਸ ਨਾਲ ਸੱਸੇ ਗਲਤ ਲਾਂਚਾਂ ਘਟਦੀਆਂ ਹਨ ਅਤੇ ਫਾਇਨੈਨ੍ਸ/ਕੰਪਲਾਇੰਸ ਸਮੀਖਿਆ ਆਸਾਨ ਹੁੰਦੀ ਹੈ।
experiment_idvariant_id