ਜਾਣੋ ਕਿ Marissa Mayer ਦੇ ਉਤਪਾਦ-ਮੈਟ੍ਰਿਕਸ ਦਾ ਸੋਚ ਕਿਵੇਂ UX ਫ੍ਰਿਕਸ਼ਨ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜਦਾ ਹੈ, A/B ਟੈਸਟਿੰਗ ਅਨੁਸ਼ਾਸਨ ਲਗਾਉਂਦਾ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਿਨਾਂ ਹੰਗਾਮੇ ਦੇ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਛੋਟੀ UX ਫ੍ਰਿਕਸ਼ਨ ਉਹ ਨਿਛੋਟੀਆਂ ਘਟਨਾਵਾਂ ਹਨ ਜੋ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਪਰ ਅਕਸਰ ਢੰਗ ਨਾਲ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰਦੇ। ਇਹ ਹੋ ਸਕਦਾ ਹੈ: ਫਾਰਮ ਵਿੱਚ ਇੱਕ ਹੋਰ ਕਦਮ, ਇੱਕ ਬਟਨ ਲੇਬਲ ਜੋ ਲੋਕਾਂ ਨੂੰ ਦੇਰ ਕਰਵਾ ਦੇਂਦਾ ਹੈ, ਇੱਕ ਪੇਜ ਜੋ ਇੱਕ ਸਕਿੰਟ ਦੇ ਲਈ ਸੌਣ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਐਰਰ ਸੁਨੇਹਾ ਜੋ ਦੱਸਦਾ ਹੀ ਨਹੀਂ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ।
ਲਾਗਤ ਤੁਹਾਡੇ ਸਕੇਲ ਵਿੱਚ ਛੁਪੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਇਕੱਲਾ ਉਲਝਣ ਦਾ ਪਲ ਸਿਰਫ ਇਕ ਵਰਤੋਂਕਾਰ ਨੂੰ ਇਕ ਵਾਰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ; ਇਹ ਹਰ ਦਿਨ ਹਰ ਵਿਟਰ ਤੇ ਦੁਹਰਦਾ ਹੈ। ਹਰ ਕਦਮ 'ਤੇ 1% ਦੀ ਗਿਰਾਵਟ ਸਾਈਨਅਪ, ਖਰੀਦਾਂ, ਜਾਂ ਪ੍ਰਯੋਗਕਾਰੀ ਮੁੜ ਵਰਤੋਂ ਵਿੱਚ ਅਰਥਪੂਰਨ ਘਾਟੀ ਵਿੱਚ ਬਣ ਜਾਂਦੀ ਹੈ।
ਕੁਝ ਫ੍ਰਿਕਸ਼ਨ ਪੈਟਰਨ ਡਿਜ਼ਾਈਨ ਰਿਵਿਊ ਵਿੱਚ ਨਿਰਦੋਸ਼ ਲੱਗਦੇ ਹਨ ਪਰ ਨਤੀਜਿਆਂ ਨੂੰ ਚੁਪਕੇ ਨਾਲ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ:
ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ: ਜੇ 100,000 ਲੋਕ ਮਹੀਨੇ ਵਿੱਚ ਸਾਈਨਅਪ ਫਲੋ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਦੇਰੀ ਜਾਂ ਉਲਝਣ ਵਾਲਾ ਲੇਬਲ ਪੂਰਨਤਾ 30% ਤੋਂ 28% ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ 2,000 ਸਾਈਨਅਪ ਖੋ ਬੈਠੇ ਹੋ। ਇਹ ਉਸ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਐਕਟੀਵੇਸ਼ਨ ਅਤੇ ਰੀਟੇਨਸ਼ਨ ਦੇ ਅਸਰ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋ, ਜਿੱਥੇ ਫ਼ਰਕ ਅਕਸਰ ਵੱਧ ਜਾਂਦਾ ਹੈ।
ਇਸੇ ਲਈ ਰਾਇਆਂ ਕਾਫੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਮਜ਼ਬੂਤ ਉਤਪਾਦ ਟੀਮਾਂ “ਇਹ ਤਕਲੀਫ਼ਦੇਹ ਲੱਗਦਾ ਹੈ” ਨੂੰ ਮਾਪਯੋਗ ਸਵਾਲ ਵਿੱਚ ਬਦਲਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਅਨੁਸ਼ਾਸਿਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਬਾਰ-ਬਾਰ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਉਤਪਾਤ ਦੇ, ਪਰ ਇਹੋ ਜਦੋਂ ਸੰਭਵ ਹੈ ਜਦੋਂ ਰਫ਼ਤਾਰ ਸਬੂਤ ਨਾਲ ਜੁੜੀ ਹੋਵੇ।
ਜਦੋਂ ਲੋਕ “Marissa Mayer ਸਟਾਈਲ” ਉਤਪਾਦ ਨੇਤ੍ਰਿਤਵ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ ’ਤੇ ਇਕ ਵਿਸ਼ੇਸ਼ ਆਦਤ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ: ਉਤਪਾਦੀ ਫੈਸਲਿਆਂ ਨੂੰ ਵਿਚਾਰ-ਵਿਵਾਦ ਬਜਾਏ ਟੈਸਟ ਕਰਨ ਯੋਗ ਪ੍ਰਸ਼ਨਾਂ ਵਾਂਗੋਂ ਦੇਖੋ। ਇਸਦਾ ਸਾਰ ਅਰਥ ਹੈ Marissa Mayer product metrics—ਇਹ ਵਿਚਾਰ ਕਿ ਛੋਟੀਆਂ UX ਚੋਣਾਂ ਨੂੰ ਵੀ ਮਾਪਿਆ ਜਾਣਾ ਚਾਹੀਦਾ, ਤੁਲਨਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਅਤੇ ਜਦੋਂ ਵਰਤੋਂਕਾਰ ਸੰਕਟ ਵਿੱਚ ਦਿਖਣ ਤਾਂ ਦੁਬਾਰਾ ਦੇਖੀ ਜਾਣੀ ਚਾਹੀਦੀ।
ਇੱਥੇ ਲਾਭਦੀ ਗੱਲ ਨਿੱਜੀਅਤ ਜਾਂ ਕਹਾਣੀ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਵਾਦੀ ਵਿਚਾਰਧਾਰਾ ਹੈ: ਕੁਝ ਸੰਕੇਤ ਚੁਣੋ ਜੋ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਸਾਫ਼ ਪ੍ਰਯੋਗ ਚਲਾਓ, ਅਤੇ ਸਿੱਖਣ ਦੇ ਚੱਕਰ ਛੋਟੇ ਰੱਖੋ।
ਮਾਪਯੋਗ UX ਦਾ ਮਤਲਬ ਹੈ “ਇਹ ਫਲੋ ਨਿਰਾਸ਼ਾਜਨਕ ਹੈ” ਜਿਹੇ ਅਹਿਸਾਸ ਨੂੰ ਨਿਗਰਾਨੀਯੋਗ ਬਣਾਉਣਾ। ਜੇ ਕੋਈ ਸਕਰੀਨ ਉਲਝਣ ਵਾਲੀ ਹੈ ਤਾਂ ਇਹ ਵਰਤਾਰ ਵਿੱਚ ਦਿੱਖਦੀ ਹੈ: ਘੱਟ ਲੋਕ ਪੂਰਾ ਕਰਦੇ ਹਨ, ਜ਼ਿਆਦਾ ਲੋਕ ਵਾਪਸ ਚਲੇ ਜਾਂਦੇ ਹਨ, ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਵੱਧਦੀ ਹੈ, ਜਾਂ ਕਿਸੇ ਕਾਰਜ ਨੂੰ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
ਰਫ਼ਤਾਰ ਦੀ ਇੱਕ ਵਪਾਰਕ ਟ੍ਰੇਡ-ਆਫ ਹੁੰਦੀ ਹੈ। ਬਿਨਾਂ ਨਿਯਮਾਂ ਦੇ ਰਫ਼ਤਾਰ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀ ਹੈ। ਟੀਮਾਂ ਲਗਾਤਾਰ ਸ਼ਿਪ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ, ਨਤੀਜੇ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਡਾਟਾ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ। ਇਹ “ਸਟਾਈਲ” ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਟਰੇਸ਼ਨ ਦੀ ਰਫ਼ਤਾਰ ਨਿਰੰਤਰ ਮਾਪ ਨਾਲ ਜੁੜੀ ਹੋਵੇ।
ਸਧਾਰਨ ਅਨੁਸ਼ਾਸਨ ਇਹ ਹੁੰਦੀ ਹੈ: ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਸਫਲਤਾ ਕੀ ਹੋਵੇਗੀ, ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਗਲਤੀਆਂ ਬਦਲੋ, ਅਤੇ ਟੈਸਟ ਮਿਆਦ ਐਨੀ ਲੰਮੀ ਰੱਖੋ ਕਿ ਯਾਦ੍ਰਚਿਕ ਉਚਾਲਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।
ਚੰਗੇ ਮੈਟ੍ਰਿਕਸ ਉਹ ਹਨ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਵਰਤੋਂਕਾਰ ਵਾਕਈ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਕੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦਾ ਹੈ। Marissa Mayer product metrics ਦਾ ਆਧਾਰ ਸਧਾਰਨ ਹੈ: ਕੁਝ ਭਰੋਸੇਯੋਗ ਅੰਕ ਚੁਣੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਅਕਸਰ ਵੇਖੋ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਫੈਸਲਿਆਂ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਦਿਓ।
ਆਪਣੇ ਕੋਰ ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਲੋਕ ਮੁੱਲ ਕਿਵੇਂ ਲੈ ਰਹੇ ਹਨ ਅਤੇ ਵਾਪਸ ਆ ਰਹੇ ਹਨ:
ਫਿਰ ਇੱਕ ਜਾਂ ਦੋ UX ਹੈਲਥ ਮੈਟ੍ਰਿਕਸ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਮੁੱਖ ਫਲੋਜ਼ ਵਿੱਚ ਫ੍ਰਿਕਸ਼ਨ ਦਰਸਾਉਂਦੇ ਹਨ। ਟਾਸਕ ਸੈਕਸੈਸ ਰੇਟ ਇੱਕ ਚੰਗਾ ਡੀਫਾਲਟ ਹੈ। ਇਸਨੂੰ Error rate ਜਾਂ Time on task ਦੇ ਨਾਲ ਜੋੜੋ।
ਟੈਨੋ ਸੋਚੋ ਕਿ ਲੀਡਿੰਗ ਅਤੇ ਲੈਗਿੰਗ ਸੰਕੇਤਕਾਂ ਵਿੱਚ ਵੰਡ ਕਰੋ।
ਲੀਡਿੰਗ ਸੰਕੇਤਕ ਤੇਜ਼ ਹਿਲਦੇ ਹਨ ਅਤੇ ਅੱਗੇ ਦਾ ਸੂਚਨ ਦਿੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਾਈਨਅਪ ਸਧਾਰਨ ਕਰਦੇ ਹੋ ਅਤੇ ਅਗਲੇ ਦਿਨ ਟਾਸਕ ਸਫਲਤਾ 72% ਤੋਂ 85% ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਫਲੋ ਸੁਧਾਰਿਆ।
ਲੈਗਿੰਗ ਸੰਕੇਤਕ ਲੰਮੇ ਸਮੇਂ ਦਾ ਪ੍ਰਭਾਵ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਹਫ਼ਤੇ-4 ਰੀਟੇਨਸ਼ਨ। ਇਹ ਤੁਰੰਤ ਨਹੀਂ ਦਿੱਖਦਾ, ਪਰ ਅਕਸਰ ਅਸਲ ਮੁੱਲ ਇੱਥੇ ਹੀ ਨਿਕਲਦਾ ਹੈ।
ਵੈਨੀਟੀ ਮੈਟ੍ਰਿਕਸ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ। ਕੁੱਲ ਸਾਈਨਅਪ, ਪੇਜ਼-ਵਿਊਜ਼, ਅਤੇ ਰਾ ਸੈਸ਼ਨ ਗਿਣਤੀ ਵਧ ਸਕਦੀ ਹੈ ਪਰ ਅਸਲ ਤਰੱਕੀ ਫਲੈੱਟ ਰਹਿ ਸਕਦੀ ਹੈ। ਜੇ ਕੋਈ ਮੈਟ੍ਰਿਕ ਤੁਹਾਨੂੰ ਅਗਲੀ ਵਾਰ ਕੀ ਬਣਾਉਣਾ ਹੈ ਇਹ ਨਹੀਂ ਦੱਸਦੀ, ਤਾਂ ਉਹ ਸ਼ਾਇਦ ਸ਼ੋਰ ਹੈ।
UX ਸ਼ਿਕਾਇਤਾਂ ਅਕਸਰ ਅਧੂਰੀਆਂ ਭਾਵਨਾਵਾਂ ਵਜੋਂ ਆਉਂਦੀਆਂ ਹਨ: “ਸਾਈਨਅਪ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ” ਜਾਂ “ਇਹ ਪੇਜ ਧੀਮਾ ਹੈ।” ਇਲਾਜ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਹਿਸਾਸ ਨੂੰ ਅਜਿਹਾ ਸਵਾਲ ਬਣਾ ਦਿਓ ਜੋ ਡਾਟਾ ਨਾਲ ਜਵਾਬਯੋਗ ਹੋਵੇ।
ਸਫਰ ਨੂੰ ਜਿਵੇਂ ਅਸਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਪਰੋਖੋ, ਨਾ ਕਿ ਫਲੋਚਾਰਟ ਜਿਵੇਂ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। ਓਥੇ ਵੇਖੋ ਜਿੱਥੇ ਲੋਕ ਠਹਿਰਦੇ, ਵਾਪਸ ਜਾਂ ਛੱਡਦੇ ਹਨ। ਫ੍ਰਿਕਸ਼ਨ ਅਕਸਰ ਛੋਟੇ ਵੇਰਵਿਆਂ ਵਿੱਚ ਲੁਕਿਆ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਉਲਝਣ ਭਰੀ ਲੇਬਲ, ਇੱਕ ਵਾਧੂ ਫੀਲਡ, ਇੱਕ ਲੋਡਿੰਗ ਦੇਰੀ, ਜਾਂ ਇੱਕ ਅਸਪਸ਼ਟ ਐਰਰ।
ਕਦਮ ਲਈ ਸਫਲਤਾ ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕਿਹੜੀ ਕਾਰਵਾਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ, ਅਤੇ ਕਿੰਨੀ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਨਾਲ। ਉਦਾਹਰਨ ਵਜੋਂ:
ਇਕ ਪ੍ਰਯੋਗੀ ਢੰਗ: ਇੱਕ ਕਦਮ ਚੁਣੋ ਜਿੱਥੇ ਬੱਸ-ਸਪੱਸ਼ਟ ਡ੍ਰੌਪ-ਆਫ ਹੈ, ਫਿਰ ਇੱਕ ਇੱਕਲ-ਪਰੇਖ ਵਾਕ ਬਣਾਓ: “ਕੀ ਫੀਲਡ X ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਮੋਬਾਈਲ ਉਪਭੋਗਤਿਆਂ ਦੀ ਪੂਰਨਤਾ Y% ਵੱਧਦੀ ਹੈ?”
ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਬਹੁਤ ਮਹੱਤਵਪੂਰਕ ਹੈ। ਤੁਹਾਨੂੰ ਐਸੇ ਇਵੈਂਟ ਚਾਹੀਦੇ ਹਨ ਜੋ ਕਦਮ ਨੂੰ ਪੂਰੇ ਤੌਰ ਤੇ ਵੇਰਵਾ ਦਿੰਦੇ ਹਨ, ਨਾਲ ਹੀ ਸੰਦਰਭ ਵੀ ਜੋ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਉਪਯੋਗਕ ਪ੍ਰਾਪਰਟੀਜ਼ ਵਿੱਚ device, traffic source, form length, error type, ਅਤੇ load time buckets ਸ਼ਾਮਿਲ ਹਨ।
ਸਥਿਰਤਾ ਬਾਅਦ ਵਿੱਚ ਰਿਪੋਰਟਿੰਗ ਹੰਗਾਮੇ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਨਾਂ-ਕਨਵੈਨਸ਼ਨ ਮਦਦ ਕਰਦੀ ਹੈ: events ਲਈ verb_noun ਵਰਤੋ (start_signup, submit_signup), ਇੱਕ-ਮਰੁਦਾ ਨਾਮ ਇੱਕ ਹੀ ਸੰਕਲਪ ਲਈ ਰੱਖੋ ("register" ਅਤੇ "signup" ਮਿਲਾ ਕੇ ਨਾ ਵਰਤੋ), property keys ਸਥਿਰ ਰੱਖੋ (plan, device, error_code), ਅਤੇ ਸਾਰੇ ਲਈ event ਸੂਤਰ-ਸੂਚੀ ਕਿਸੇ ਥਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹੋ, “ਸਾਈਨਅਪ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ” ਕੁਝ ਇਸ ਰੂਪ ਵਿੱਚ ਬਣ ਜਾਂਦਾ ਹੈ: “ਕਦਮ 3 ਮੋਬਾਈਲ 'ਤੇ 22% ਡ੍ਰੌਪ-ਆਫ ਕਰਵਾਂਦਾ ਹੈ ਪਾਸਵਰਡ ਐਰਰਾਂ ਕਾਰਨ।” ਇਹ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਹੈ ਜਿਸ ਨੂ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ।
A/B ਟੈਸਟਾਂ ਉਸ ਵੇਲੇ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ “ਕੁਝ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕੀ ਹੁੰਦਾ” ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ। ਸੁਧਾਰ ਸਧਾਰਨ ਹੈ: ਹਰ ਟੈਸਟ ਨੂੰ ਇੱਕ ਛੋਟੇ ਠੇਕੇ ਵਾਂਗ ਲਓ। ਇੱਕ ਬਦਲਾਅ, ਇੱਕ ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ, ਇੱਕ ਦਰਸ਼ਕ।
ਇੱਕ ਵਾਕ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਟੀਮਮੈਟ ਨੂੰ ਦੇ ਸਕੋ: “ਜੇ ਅਸੀਂ X ਬਦਲਾਂਗੇ ਤਾਂ Z ਲਈ Y ਸੁਧਰੇਗਾ, ਕਿਉਂਕਿ…” ਇਹ ਸਪਸ਼ਟਤਾ ਲਿਆਂਦਾ ਹੈ ਅਤੇ ਐਸੇ ਬਲੈੰਡਡ ਬਦਲਾਅ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਨਤੀਜਿਆਂ ਦੀ ਵਿਵੇਚਨਾ ਅਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਜੋ ਉਹ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਦਰਸਾਂਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਪਰਵਾਹ ਕਰਦੇ ਹੋ (ਸਾਈਨਅਪ ਕੰਪਲੀਟ, ਚੈਕਆਊਟ ਪੂਰਾ, ਪਹਿਲਾ ਸੁਨੇਹਾ ਭੇਜਣ ਦਾ ਸਮਾਂ)। ਕੁਝ ਗਾਰਡਰੇਲ ਜੋ ਤੁਸੀਂ ਨੁਕਸਾਨ ਤੋਂ ਬਚਾਓ: ਕਰੈਸ਼ ਰੇਟ, ਐਰਰ ਰੇਟ, ਸਪੋਰਟ ਟਿਕਟ, ਰਿਫੰਡ, ਜਾਂ ਰੀਟੇਨਸ਼ਨ।
ਮਿਆਦ ਅਤੇ ਨਮੂਨੇ ਦਾ ਆਕਾਰ ਕਾਰਗਰ ਰੱਖੋ। ਝੂਠੀ ਜਿੱਤ ਤੋਂ ਬਚਣ ਲਈ ਤੁਹਾਨੂੰ ਮਹਿੰਗੇ ਅੰਕੜੇ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਹਾਨੂੰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੱਗਭਗ ਕਾਫੀ ਟ੍ਰੈਫਿਕ ਚਾਹੀਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਨਤੀਜੇ ਸਥਿਰ ਹੋਣ ਅਤੇ ਕਦਮ-ਕਦਮ ਚੱਕਰ (ਉਦਾਹਰਣ ਲਈ ਹਫ਼ਤੇ-ਅਤੇ-ਹਫ਼ਤੇ) ਕਵਰ ਹੋ ਜਾਣ।
ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਹਰ ਨਤੀਜੇ ਨਾਲ ਕੀ ਕਰੋਗੇ। ਇਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਬਾਦ ਵਿੱਚ ਕਹਾਣੀ ਬਣਨ ਤੋਂ ਰੋਕਦੀ ਹੈ। ਸਪਸ਼ਟ ਜਿੱਤ ਤੁਰੰਤ ਰੁਲ-ਆਉਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਮਨਟਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਸਪਸ਼ਟ ਹਾਰ ਰੋਲਬੈਕ ਹੁੰਦੀ ਹੈ ਅਤੇ ਲਿਖੀ ਜਾਂਦੀ ਹੈ; ਅਸਪਸ਼ਟ ਨਤੀਜਾ ਜਾਂ ਤਾਂ ਹੋਰ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਰਫ਼ਤਾਰ ਸਿਰਫ ਰਿਲੀਜ਼-ਰਫ਼ਤਾਰ ਨਹੀਂ, ਇਹ ਫੀਡਬੈਕ-ਰਫ਼ਤਾਰ ਵੀ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਇਹ ਬਣਾਉਣਾ ਹੈ ਕਿ “ਸੁਰੱਖਿਅਤ” ਡੀਫਾਲਟ ਹੋਵੇ ਤਾਂ ਕਿ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਹਫ਼ਤੇ-ਲੰਬੀ ਐਮਰਜੈਂਸੀ ਨਾਹ ਬਣੇ।
ਗਾਰਡਰੇਲ ਸ਼ੁਰੂਆਤੀ IS: ਸੰਖਿਆਵਾਂ ਜੋ ਸੁਸਪੰਸ਼ਨ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ। ਉਹ ਸੰਕੇਤਜੋ ਅਸਲੀ ਦਰਦ ਨੂੰ ਜਲਦੀ ਫੜਨ: ਪੇਜ ਲੋਡ ਟਾਈਮ, ਕਰੈਸ਼ ਜਾਂ ਐਰਰ ਰੇਟ, ਅਤੇ ਮੂਲ ਐਕਸੈਸੀਬਿਲਟੀ ਚੈਕ। ਜੇ ਕੋਈ ਬਦਲਾਅ CTR ਵਧਾਉਂਦਾ ਹੈ ਪਰ ਪੇਜ ਹੌਲੀ ਕਰ ਦਿੰਦਾ ਹੈ ਜਾਂ ਐਰਰ ਵਧ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਜਿੱਤ ਨਹੀਂ।
ਗਾਰਡਰੇਲਾਂ ਨੂੰ ਲਿਖੋ। ਉਹ ਨਿਰੀਖਣਯੋਗ ਹੋਣ: ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਬਜਟ, ਇੱਕ ਐਕਸੈਸੀਬਿਲਟੀ ਬੇਸਲਾਈਨ, ਇੱਕ ਐਰਰ ਸੀਮਾ, ਅਤੇ ਰਿਲੀਜ਼ ਦੇ ਬਾਦ ਸਹਾਇਤਾ ਸੰਕੇਤਾਂ ਨੂੰ ਦੇਖਣ ਲਈ ਇੱਕ ਛੋਟਾ ਵਿੰਡੋ।
ਫਿਰ ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾਓ। ਫੀਚਰ ਫਲੈਗ ਅਤੇ ਸਟੇਜਡ ਰੋਲਆਉਟ ਤੁਹਾਨੂੰ ਝਟਕੇ ਤੋਂ ਪਹਿਲਾਂ ਛੋਟੇ ਗਰੁੱਪਾਂ 'ਤੇ ਪਰਖਣ ਦਿੰਦੇ ਹਨ। ਅੰਦਰੂਨੀ ਯੂਜ਼ਰ → ਛੋਟੀ ਪ੍ਰਤੀਸ਼ਤ → ਵੱਡੀ ਪ੍ਰਤੀਸ਼ਤ। ਰੋਲਬੈਕ ਇੱਕ ਬਟਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਹਲਚਲ ਨਹੀਂ।
ਇਹ ਵੀ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਸੇ ਨੇ ਕੀਤਾ-ਕੀ ਸ਼ਿਪ ਕਰ ਸਕਦਾ ਹੈ ਦੀ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਹੋਵੇ। ਘੱਟ-ਖ਼ਤਰਾ UI ਕਾਪੀ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਦਾਖਲ ਹੋ ਸਕਦੇ ਹਨ; ਉੱਚ-ਖ਼ਤਰਾ ਵਰਕਫਲੋ ਬਦਲਾਅ (ਸਾਈਨਅਪ, ਚੈੱਕਆਊਟ) ਨੂੰ ਵਾਧੂ ਸਮੀਖਿਆ ਅਤੇ ਇੱਕ ਨਿਰਧਾਰਿਤ ਮਾਲਿਕ ਚਾਹੀਦਾ ਹੈ ਜੋ ਮੈਟ੍ਰਿਕ ਡਿੱਪ ਤੇ ਫੈਸਲਾ ਕਰ ਸਕੇ।
ਤੇਜ਼ ਟੀਮਾਂ ਅਨੁਮਾਨ ਨਾਲ ਤੇਜ਼ ਨਹੀਂ ਹੁੰਦੀਆਂ; ਉਹ ਛੋਟੇ, ਨਿਰੰਤਰ ਅਤੇ ਦੁਹਰਣਯੋਗ ਲੂਪ ਨਾਲ ਤੇਜ਼ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਫਨਲ ਵਿੱਚ ਇੱਕ friction ਮੋਮੈਂਟ ਚੁਣੋ। ਉਸਨੂੰ ਗਿਰੰਟੀਬੱਧ ਚੀਜ਼ ਵਿੱਚ ਬਦਲੋ, ਜਿਵੇਂ completion rate ਜਾਂ time to finish। ਫਿਰ ਇੱਕ ਕਸਰ-ਭਰਿਆ ਹਿਪੋਥੈਸਿਸ ਲਿਖੋ: ਕੀ ਬਦਲੋ, ਕਿਹੜਾ ਨੰਬਰ ਹਿਲੇਗਾ, ਅਤੇ ਕੀ ਨਹੀਂ ਖਰਾਬ ਹੋਣਾ ਚਾਹੀਦਾ।
ਬਦਲਾਅ ਨੂੰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਛੋਟਾ ਰੱਖੋ ਪਰ ਮਾਇਨੇ ਰੱਖਣ ਵਾਲਾ। ਇੱਕ ਸਕਰੀਨ ਟਵੀਕ, ਇੱਕ ਘੱਟ ਫੀਲਡ, ਜਾਂ ਸਪਸ਼ਟ ਕਾਪੀ ਅਸਾਨੀ ਨਾਲ ਸ਼ਿਪ, ਟੈਸਟ ਅਤੇ ਰੋਲਬੈਕ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਦੁਹਰਣਯੋਗ ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:
ਆਖ਼ਰੀ ਕਦਮ ਇੱਕ ਖਾਮੋਸ਼ ਫ਼ਾਇਦਾ ਦਿੰਦਾ ਹੈ: ਉਹ ਟੀਮਾਂ ਜੋ ਯਾਦ ਰੱਖਦੀਆਂ ਹਨ ਉਹ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਦੀਆਂ ਹਨ ਬਨਿਸ਼ਪਤ ਕੀਵਿਆਂ ਤੋਂ ਤੇਜ਼ ਸ਼ਿਪ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਨਾਲੋਂ।
ਤੇਜ਼ ਸ਼ਿਪਿੰਗ ਚੰਗੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਉਹੀ ਨਹੀਂ ਜਿਵੇਂ ਯੂਜ਼ਰ ਸਫਲ ਹੋਣ। “ਅਸੀਂ ਸ਼ਿਪ ਕੀਤਾ” ਅੰਦਰੂਨੀ ਗੱਲ ਹੈ। “ਯੂਜ਼ਰ ਕੰਮ ਮੁਕੰਮਲ ਕੀਤਾ” ਹੀ ਮਹੱਤਵਪੂਰਨ ਨਤੀਜਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਰਿਲੀਜ਼ ਨੂੰ ਮਨਾਓਗੇ, ਤਾਂ ਛੋਟੀ UX ਫ੍ਰਿਕਸ਼ਨ ਆਹਿਸਤ-ਆਹਿਸਤ ਗੁਪਤ ਰਹਿ ਜਾਵੇਗੀ ਅਤੇ ਸਪੋਰਟ ਟਿਕਟਾਂ, ਚਰਨ ਅਤੇ ਡ੍ਰੌਪ-ਆਫ ਹੌਲੀ-ਹੌਲੀ ਵੱਧਦੇ ਰਹਿਣਗੇ।
ਰਫ਼ਤਾਰ ਦੀ ਇਕ ਪ੍ਰਯੋਗਿਕ ਪਰਿਭਾਸ਼ਾ: ਤੁਸੀਂ ਕੁਹੁੰਜ਼ ਸੱਚ ਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਬਦਲਦੇ ਹੋ? ਤੇਜ਼ ਬਣਾਉਣਾ ਬਿਨਾਂ ਤੇਜ਼ ਮਾਪਣ ਦੇ ਤੇਜ਼ ਅਨੁਮਾਨ ਹੀ ਹੈ।
ਇੱਕ ਢੰਗੀ ਰੁਦਿਮ ਬਦਲਾਅ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਬਣਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਜੋੜੇ:
ਨੰਬਰਾਂ ਵਿੱਚ ਅੰਧੇ ਖ਼ਾਣੇ ਹੋ ਸਕਦੇ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਮੈਟ੍ਰਿਕਸ ਠੀਕ ਲੱਗਦੇ ਹਨ ਪਰ ਯੂਜ਼ਰ ਨਿਰਾਸ਼ ਹਨ। ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਕੁੱਝ ਹਲਕੀ ਗੁਣਾਤਮਕ ਜਾਂਚਾਂ ਨਾਲ ਜੋڑੋ: ਕੁਝ ਸਪੋਰਟ ਚੈਟਾਂ ਵੇਖੋ, ਕਈ ਸੈਸ਼ਨ ਰਿਕਾਰਡਿੰਗਾਂ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਯੂਜ਼ਰ-ਕਾਲ ਖਾਸ ਇੱਕ ਫਲੋ 'ਤੇ। ਗੁਣਾਤਮਕ ਨੋਟ ਅਕਸਰ ਦੱਸਦੇ ਹਨ ਕਿ ਮੈਟ੍ਰਿਕ ਕਿਉਂ ਹਿਲਿਆ (ਜਾਂ ਕਿਉਂ ਨਹੀਂ)।
ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਭਰੋਸਾ ਖੋਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਗੰਦੇ ਪ੍ਰਯੋਗ ਚਲਾਉਣਾ ਹੈ। ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਹਿਲਦੀਆਂ ਹਨ ਪਰ ਕੁਝ ਵੀ ਨਹੀਂ ਸਿੱਖਦੀਆਂ, ਜਾਂ ਗਲਤ ਨਤੀਜੇ ਲੈਂਦੀਆਂ ਹਨ।
ਬਦਲਾਅ ਜੋੜਨਾ ਇੱਕ ਕਲਾਸਿਕ ਫੇਲURE ਹੈ। ਨਵਾਂ ਬਟਨ ਲੇਬਲ, ਲੇਆਉਟ ਸ਼ਿਫਟ, ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਕਦਮ ਇੱਕੱਠੇ ਸ਼ਿਪ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਲੁਕਾਵਟ ਲੱਗਦਾ ਹੈ। ਫਿਰ ਟੈਸਟ ਇੱਕ ਉਥਲੇ ਵਾਧੇ ਦਿਖਾਉਂਦਾ ਹੈ ਪਰ ਕੋਈ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਕਾਰਨ ਸੀ।
ਟੈਸਟ ਨੂੰ ਜਲਦੀ ਖਤਮ ਕਰਨਾ ਵੀ ਖਤਰਨਾਕ ਹੈ। ਛੋਟੀ-ਨਮੂਨਾ ਜਾਂ ਅਸਥਿਰ ਟ੍ਰੈਫਿਕ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਚਾਰਟ ਅਣਿਸ਼ਚਿਤ ਹੋ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਲਾਈਨ ਊਪਰ ਜਾਂਦੀ ਹੈ, ਉਹੀ ਸਮੇਂ ਬੰਦ ਕਰਨਾ ਤਜਰਬਾ-ਕੁਤੂਹਲ ਨੂੰ ਨસીਬ ਕਰਦਾ ਹੈ।
ਗਾਰਡਰੇਲ ਛੱਡ ਦੇਣ ਨਾਲ ਦੇਰ ਨਾਲ ਦਰਦ ਆ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਕੰਵਰਜ਼ਨ ਵਧਾ ਸਕਦੇ ਹੋ ਪਰ ਸਪੋਰਟ ਟਿਕਟ, ਰਿਫੰਡ ਜਾਂ ਪੇਜ ਸਪੀਡ ਖਰਾਬ ਹੋ ਰਹੀ ਹੋ ਸਕਦੀ ਹੈ—ਇਹ ਨੁਕਸਾਨ ਟੀਮ ਦੇ ਜਸ਼ਨ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਾਹਮਣੇ ਆ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਅਸੀਂ ਕਿਸੇ ਲੌਕਲ ਮੈਟ੍ਰਿਕ ਨੂੰ ਬੇਤਰ ਬਣਾਇਆ ਜਿਸ ਨਾਲ ਪੂਰੀ ਯਾਤਰਾ ਖ਼ਰਾਬ ਹੋ ਗਈ? ਉਦਾਹਰਣ ਲਈ, “Next” ਬਟਨ ਨੂੰ ਚਮਕਦਾਰ ਕਰਨ ਨਾਲ ਕਲਿਕ ਵadh ਸਕਦੇ ਹਨ ਪਰ ਪੂਰਨਤਾ ਘਟ ਸਕਦੀ ਹੈ ਜੇ ਯੂਜ਼ਰ ਰੂਪ ਵਿੱਚ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਕੇ ਇੱਕ ਲਾਜ਼ਮੀ ਫੀਲਡ ਮਿਸ ਕਰ ਦੇਂ।
ਡੈਸ਼ਬੋਰਡ ਸਹਾਇਕ ਹਨ ਪਰ ਉਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਲੋਕ ਕਿਉਂ ਸੰਘਰਸ਼ ਕਰ ਰਹੇ ਹਨ। ਹਰੇਕ ਗੰਭੀਰ ਮੈਟ੍ਰਿਕ ਸਮੀਖਿਆ ਨੂੰ ਕੁਝ ਹਕੀਕਤ ਨਾਲ ਜੋੜੋ: ਕੁਝ ਸਪੋਰਟ ਟਿਕਟ, ਇੱਕ ਛੋਟੀ ਕਾਲ, ਜਾਂ ਫਲੋ ਦੀਆਂ ਰਿਕਾਰਡਿੰਗਾਂ ਦੇਖੋ।
ਉਹਲੇ-ਨਾਲ-ਵਾਲੀ ਭਰਪਾਈ ਜਾਂ ਵਧੀਆ ਮੁੱਲ ਵਾਲੇ ਫਲੋ (ਸਾਈਨਅਪ, ਚੈਕਆਊਟ, ਆਨਬੋਰਡਿੰਗ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉਹਨਾਂ ਅੰਸ਼ਾਂ ‘ਤੇ ਤੱਕੋ ਜਿੱਥੇ ਯੂਜ਼ਰ ਠਹਿਰਦੇ, ਵਾਪਸ ਜਾਂ ਛੱਡਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਾਪੋ (ਕੰਪਲੀਸ਼ਨ ਰੇਟ, ਖਤਮ ਕਰਨ ਦਾ ਸਮਾਂ, ਐਰਰ ਰੇਟ)। ਇੱਕ ਉੱਚ-ਟ੍ਰੈਫਿਕ ਕਦਮ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਪੰਜ ਘੱਟ-ਟ੍ਰੈਫਿਕ ਸਕਰੀਨਾਂ ਨੂੰ ਫੈਲਾਉਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ।
ਸਧਾਰਨ ਫਨਲ ਗਣਿਤ ਵਰਤੋ:
ਚਾਹੇ ਮਾਤਰ ਇੱਕ ਜਾਂ ਦੋ ਪੌਇੰਟ ਦੀ ਘਟ ਹੋਵੇ, ਜਦੋਂ ਟਾਪ-ਆਫ-ਫਨਲ ਵੱਡਾ ਹੋਵੇ ਤਾਂ ਨਤੀਜੇ ਵੱਡੇ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਵਧੀਆ ਡੀਫਾਲਟ ਸੈੱਟ:
ਫਿਰ ਆਪਣੀ ਮੁੱਖ ਫਲੋ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ, ਜਿਵੇਂ ਟਾਸਕ ਸక్సੈਸ ਰੇਟ ਜਾਂ ਐਰਰ ਰੇਟ।
ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸ਼ਿਕਾਇਤ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਮਾਪਯੋਗ ਸਵਾਲ ਵਿੱਚ ਲਿਖੋ:
ਲਕੜੀ ਦਾ ਮਕਸਦ ਇੱਕ ਸਾਫ਼ ਅਤੇ ਨਿਰੀਖਣਯੋਗ ਵਰਤਾਰ ਨੂੰ ਪਰਖਣਾ ਹੈ, ਨਾ ਕਿ ਜਨਰਲ ਅਹਿਸਾਸ।
ਪੁੜ-ਟੂ-ਏਂਡ ਇਵੈਂਟ ਨਾਂਵਾਂ ਅਤੇ ਕੁਝ ਮਹੱਤਵਪੂਰਣ ਪ੍ਰਾਪਰਟੀਜ਼ ਨਾਲ ਫਲੋ ਟਰੈਕ ਕਰੋ।
ਘੱਟੋ-ਘੱਟ ਇਵੈਂਟਸ:
start_stepview_stepਇੱਕ ਸਧਾਰਨ ਅਨੁਸ਼ਾਸਨ:
ਇਹ ਤਰੀਕਾ “ਅਸੀਂ ਬਹੁਤ ਕੁਝ ਸ਼ਿਪ ਕੀਤਾ” ਦੀ ਗਲਤਫਹਮੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਚਰਚੇ ਦੀ ਕਮੀ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਪ੍ਰਯੋਗ 'ਤੇ ਸੱਚ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਗਤੀ:
ਜੇ ਤੁਰੰਤ ਫੈਸਲਾ ਲੈਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਨੁਕसान ਘਟਾਉਣ ਲਈ ਸਟੇਜਡ ਰੋਲਆਉਟ ਅਤੇ ਮਜ਼ਬੂਤ ਗਾਰਡਰੇਲ ਵਰਤੋ।
ਰਫ਼ਤਾਰ ਉਸ ਸਮੇਂ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਨੁਕਸਾਨ ਦੀ ਅਗਾਅਸ਼ੀ ਕਰ ਸਕੋ।
ਮੁੱਲ-ਪੂਰਨ ਗਾਰਡਰੇਲ ਨਿਰਧਾਰਿਤ ਕਰੋ: ਪੇਜ ਲੋਡ ਟਾਈਮ, ਕਰੈਸ਼/ਐਰਰ ਰੇਟ, ਅਤੇ ਬੁਨਿਆਦੀ ਐਕਸੈਸੀਬਿਲਟੀ ਚੈਕ। ਜੇ ਕੋਈ ਬਦਲਾਅ CTR ਵਧਾਉਂਦਾ ਹੈ ਪਰ ਪੇਜ ਧੀਮਾ ਕਰ ਦਿੰਦਾ ਹੈ ਜਾਂ ਐਰਰ ਵਧਦੇ ਹਨ, ਤਾਂ ਉਹ ਜਿੱਤ ਨਹੀਂ।
ਰੋਲਆਉਟ ਦੀ ਰਣਨੀਤੀ: ਫੀਚਰ ਫ਼ਲੈਗ, ਸਮੂਹ-ਵਾਰ ਰੋਲਆਉਟ (ਪਹਿਲਾਂ ਅੰਦਰੂਨੀ, ਫਿਰ ਛੋਟੀ ਪਰਸੈਂਟੇਜ, ਆਖिरਕਾਰ ਵਿਆਪਕ)। ਰੋਲਬੈਕ ਇੱਕ ਸਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਕ ਭਗਦੜ ਨਹੀਂ।
ਬੇਤਰਤੀਬੀ ਪ੍ਰਯੋਗ ਅਤੇ ਗਲਤ ਸਿੱਖਣ ਤੋਂ ਬਚਣ ਲਈ ਕੁਝ ਆਮ ਗਲਤੀਆਂ:
ਹਮੇਸ਼ਾ ਪੁੱਛੋ: ਕੀ ਅਸੀਂ ਕਿਸੇ ਸਥਾਨਕ ਮੈਟ੍ਰਿਕ ਨੂੰ ਅਾਪਟਿਮਾਈਜ਼ ਕਰਕੇ ਸਾਰੀਆਂ ਯਾਤਰਾ ਖਰਾਬ ਕਰ ਦਿੱਤੀ ਹੈ? ਡੈਸ਼ਬੋਰਡ ਵਰਗੀ ਮਿਜਾਜ਼ ਨੂੰ ਕੁਝ ਹਕੀਕਤਾਂ ਨਾਲ ਜੋੜੋ: ਸਪੋਰਟ ਟਿਕਟਾਂ, ਛੋਟੇ ਯੂਜ਼ਰ-ਕੋਲ੍ਹ, ਜਾਂ ਸਕਰੀਨ ਰਿਕਾਰਡਿੰਗ।
ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਪਰਚੀ-ਚੈੱਕਲਿਸਟ:
ਸਾਈਨਅਪ ਫਲੋ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਫੀਲਡ (ਜਿਵੇਂ “ਕੰਪਨੀ ਦਾ ਆਕਾਰ”) ਜੁੜਨਾ ਉਹ ਉਦਾਹਰਨ ਹੈ ਜੋ ਵਾਹਿਗੁਰੂ ਧਿਆਨ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਟੁੱਟਣ ਵਾਲੀ ਥਾਂ ਅਤੇ ਪ੍ਰਭਾਵ ਨਿਰਧਾਰਿਤ ਕਰੋ:
ਫਿਰ ਇੱਕ ਸਾਫ਼ A/B ਟੈਸਟ ਦਵਾਓ:
ਪਹਿਲਾਂ ਨਿਯਮ ਰੱਖੋ: ਪ੍ਰਾਇਮਰੀ ਮੈਂਟਰਿਕ ਸਾਈਨਅਪ ਕੰਪਲੀਸ਼ਨ, ਸਮਾਂ ਨਾ ਵਧੇ, ਸਪੋਰਟ ਟਿਕਟ ਨਾ ਵਧਣ। ਹਫ਼ਤੇ-ਵਾਰੀ ਵਿਵਹਾਰ ਕਵਰ ਕਰਨ ਲਈ ਪਰਯੋਗ ਲੰਬਾ ਚਲਾਓ।
ਤੇਜ਼ੀ ਵੱਲ ਜਦੋਂ ਤਕ ਨਿਯਮ ਹੋਣ ਤਾਂ ਹੀ ਅਦਾਇਗੀ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ। ਛੋਟਾ ਪ੍ਰਯੋਗ ਬੈਕਲੌਗ ਰੱਖੋ ਜਿਸ ਨੂੰ ਲੋਕ ਵਾਸਤੇ ਵਰਤ ਸਕਣ: ਇੱਕ ਫ੍ਰਿਕਸ਼ਨ ਪੌਇੰਟ, ਇੱਕ ਮੈਟ੍ਰਿਕ, ਇੱਕ ਮਾਲਿਕ, ਇੱਕ ਅਗਲਾ ਕਦਮ।
ਹਰ ਪ੍ਰਯੋਗ ਲਈ ਇੱਕ-ਪੰਨੇ ਦਾ ਟੇਮਪਲੇਟ ਵਰਤੋ: ਹਿਪੋਥੈਸਿਸ, ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ, ਗਾਰਡਰੇਲ, ਦਰਸ਼ਕ ਅਤੇ ਸਮਾਂ, ਕੀ ਬਦਲਿਆ, ਫੈਸਲੇ ਦਾ ਨਿਯਮ।
ਜੇਤੋਂ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹੋ (ਖ਼ਾਸ ਕਰ ਕੇ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ), ਇਹ ਅਨੁਸ਼ਾਸਨ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਜ਼ਿਆਦਾ ਬਦਲਾਅ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਸਹੂਲਤਾਂ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀਆਂ ਹਨ।
submit_steperror_step (ਜਿਸ ਵਿੱਚ error_code ਹੋਵੇ)complete_stepਉਪਯੋਗੀ ਪ੍ਰਾਪਰਟੀਜ਼: device, traffic_source, load_time_bucket, form_length, variant.
ਇਹ ਜਾਣਕਾਰੀ ਤੁਹਾਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਸਮੱਸਿਆ ਦੀ ਵਜ੍ਹਾ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ।
A ਜਿੱਤਦਾ ਹੈ ਤਾਂ ਫੀਲਡ ਇਸ ਵੇਲੇ ਲਾਭਕਾਰੀ ਨਹੀਂ; B ਜਿੱਤਦਾ ਹੈ ਤਾਂ ਵੈਲਯੂ ਸਕੇਲ ਕਰਨ ਵਾਲੀ ਸਿੱਖ ਹੈ: ਸਪਸ਼ਟਤਾ ਅਤੇ ਵਿਕਲਪਿਕਤਾ ਹਟਾਉਣ ਤੋਂ ਬਿਹਤਰ ਹਨ।