4-ਪੱਧਰੀ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਥਕਾਵਟ ਮਾਡਲ

ਯੂਜ਼ਰ ਨੂੰ ਗੁਆਉਣ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਹਨ। ਦਿਨ ਵਿੱਚ 1 ਪੁਸ਼ ਨਾਲ ਰੀਟੈਨਸ਼ਨ ਕਰਵ ਠੀਕ ਲੱਗਦਾ ਹੈ - Localytics ਅਤੇ Urban Airship ਤੋਂ ਮਿਲੇ ਉਦਯੋਗ ਅੰਕੜੇ 88 ਫ਼ੀਸਦ ਤਿੰਨ-ਮਹੀਨੇ ਦੀ ਰੀਟੈਨਸ਼ਨ ਦੇ ਆਸਪਾਸ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ। ਦਿਨ ਵਿੱਚ 3 ਪੁਸ਼ 'ਤੇ ਕਰਵ 17 ਫ਼ੀਸਦ ਅੰਕ ਡਿੱਗ ਜਾਂਦਾ ਹੈ। ਦਿਨ ਵਿੱਚ 5 ਪੁਸ਼ 'ਤੇ ਇਹ 34 ਨਾਲ ਡਿੱਗਦਾ ਹੈ। ਇਸ ਦੀ ਸ਼ਕਲ ਤਿੱਖੀ ਅਤੇ ਨਾ-ਬਦਲਣਯੋਗ ਹੈ: ਜਦੋਂ ਕੋਈ ਐਪ ਯੂਜ਼ਰਾਂ ਨੂੰ ਹਫ਼ਤੇ ਵਿੱਚ 2 ਤੋਂ 5 ਅਜਿਹੇ ਪੁਸ਼ ਭੇਜਦੀ ਹੈ ਜੋ ਉਹ ਨਹੀਂ ਚਾਹੁੰਦੇ, ਤਾਂ 46 ਫ਼ੀਸਦ ਯੂਜ਼ਰ ਪੁਸ਼ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਹਰ ਹੋ ਜਾਂਦੇ ਹਨ।

Soulwise ਦਾ ਜਵਾਬ ਇੱਕ 4-ਪੱਧਰੀ ਥਕਾਵਟ ਮਾਡਲ ਹੈ। ਇਹ ਇੱਕ ਰੋਲਿੰਗ 14-ਦਿਨਾ ਵਿੰਡੋ ਵਿੱਚ ਓਪਨ-ਰੇਟ ਘਟਣ ਨੂੰ ਪਛਾਣਦਾ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਵੱਲੋਂ ਪੱਕੇ ਤੌਰ 'ਤੇ ਬਾਹਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੌਲੀ-ਹੌਲੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦੀ ਗਿਣਤੀ ਘਟਾ ਦਿੰਦਾ ਹੈ।

ਇਹ ਪੋਸਟ ਡਿਜ਼ਾਈਨ, ਥ੍ਰੈਸ਼ਹੋਲਡਾਂ, ਅਤੇ ਰਿਕਵਰੀ ਲੌਜਿਕ ਬਾਰੇ ਦੱਸਦੀ ਹੈ।

ਸੰਖੇਪ ਵਿੱਚ

• Soulwise ਦਾ 4-ਪੱਧਰੀ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਥਕਾਵਟ ਮਾਡਲ 14-ਦਿਨਾਂ ਦੀ ਚੱਲਦੀ ਓਪਨ-ਰੇਟ ਵਿੰਡੋ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਜੋ ਘਟਦੀ ਦਿਲਚਸਪੀ ਨੂੰ ਪਛਾਣ ਕੇ ਯੂਜ਼ਰਾਂ ਦੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦੀ ਗਿਣਤੀ ਘਟਾਈ ਜਾ ਸਕੇ।
• ਪੱਧਰ 0 (ਸਿਹਤਮੰਦ) ਪੂਰਾ ਸ਼ਡਿਊਲ ਹੈ।
• ਪੱਧਰ 1 (ਘਟਾਇਆ ਗਿਆ) ਦੁਪਹਿਰ ਤੋਂ ਪਹਿਲਾਂ ਵਾਲਾ ਪੁਸ਼ ਹਟਾ ਦਿੰਦਾ ਹੈ।
• ਪੱਧਰ 2 (ਸਿਰਫ਼-ਐਂਕਰ) ਸਵੇਰ ਦੀ ਰਸਮ ਵਾਲਾ ਪ੍ਰੌਂਪਟ ਅਤੇ ਐਤਵਾਰ ਦਾ ਰਿਟ੍ਰੋਸਪੈਕਟਿਵ ਰੱਖਦਾ ਹੈ।
• ਪੱਧਰ 3 (ਸਿਰਫ਼-ਹਫ਼ਤਾਵਾਰੀ) ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਪੁਸ਼ ਤੱਕ ਘਟਾ ਦਿੰਦਾ ਹੈ।

ਚਾਰ ਪੱਧਰ

ਇਹ ਸਟੇਟ ਮਸ਼ੀਨ ਛੋਟੀ ਹੈ। ਹਰ ਯੂਜ਼ਰ ਇੱਕ ਸਮੇਂ ਠੀਕ ਇੱਕ ਪੱਧਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

• T0 - ਸਿਹਤਮੰਦ। ਪੂਰਾ ਸ਼ਡਿਊਲ। ਸਵੇਰ ਦੀ ਰੀਤ ਦਾ ਪ੍ਰੌਂਪਟ, ਦੁਪਹਿਰ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਪ੍ਰਸੰਗ-ਅਧਾਰਤ ਇਸ਼ਾਰਾ, ਸ਼ਾਮ ਦਾ ਚਿੰਤਨ, ਨਾਲ ਹੀ ਘਟਨਾ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟ।
• T1 - ਘਟਾਇਆ ਗਿਆ। ਦੁਪਹਿਰ ਤੋਂ ਪਹਿਲਾਂ ਵਾਲਾ ਪ੍ਰਸੰਗ-ਅਧਾਰਤ ਇਸ਼ਾਰਾ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਬਾਕੀ ਸਭ ਕੁਝ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ।
• T2 - ਸਿਰਫ਼-ਐਂਕਰ। ਸਿਰਫ਼ ਸਵੇਰ ਦੀ ਰੀਤ ਦਾ ਪ੍ਰੌਂਪਟ ਅਤੇ ਐਤਵਾਰ ਦੀ ਸਮੀਖਿਆ ਬਚਦੇ ਹਨ। ਸਾਰੇ ਮਰਜ਼ੀ-ਅਧਾਰਤ ਪੁਸ਼ ਰੋਕ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।
• T3 - ਸਿਰਫ਼-ਹਫ਼ਤਾਵਾਰ। ਇੱਕੋ ਹਫ਼ਤਾਵਾਰ ਪੁਸ਼ ਬਚਦਾ ਹੈ। ਰੋਜ਼ਾਨਾ ਤਾਲ ਮੁਅੱਤਲ ਹੋ ਜਾਂਦੀ ਹੈ।

ਤਰਤੀਬ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਦੁਪਹਿਰ ਤੋਂ ਪਹਿਲਾਂ ਵਾਲਾ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਦਾ ਘਟਨਾ-ਭਾਰ ਸਭ ਤੋਂ ਘੱਟ ਹੁੰਦਾ ਹੈ: ਇਹ ਇੱਕ ਪ੍ਰਸੰਗ-ਅਧਾਰਤ ਇਸ਼ਾਰਾ ਹੈ, ਰੋਜ਼ਾਨਾ ਰੀਤ ਦਾ ਖ਼ੁਦ ਹਿੱਸਾ ਨਹੀਂ। ਸਵੇਰ ਦਾ ਪ੍ਰੌਂਪਟ ਸਭ ਤੋਂ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਸਾਂਭਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਘਟਨਾ-ਅਧਾਰਤ ਰੋਜ਼ਾਨਾ ਪੁਸ਼ ਆਮ ਪੁਸ਼ਾਂ ਨਾਲੋਂ ਲਗਭਗ 2.85x ਜ਼ਿਆਦਾ ਰੀਟੈਂਸ਼ਨ ਪੈਦਾ ਕਰਦੇ ਹਨ; ਇਸ ਨੂੰ ਖ਼ਤਮ ਕਰਨਾ app ਨੂੰ ਖ਼ਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।

ਟੀਅਰ ਬਦਲਾਅ ਕਿਸ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

ਹਰ ਯੂਜ਼ਰ ਲਈ ਓਪਨ-ਰੇਟ ਡੇਟਾ ਦੀ 14-ਦਿਨਾਂ ਦੀ ਰੋਲਿੰਗ ਵਿੰਡੋ। ਹਰ ਦਿਨ ਮਾਡਲ ਪਿਛਲੇ 14 ਦਿਨਾਂ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਉਸ ਵਿੰਡੋ ਦੌਰਾਨ ਭੇਜੀਆਂ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਲਈ ਯੂਜ਼ਰ ਦਾ ਓਪਨ ਰੇਟ ਕੱਢਦਾ ਹੈ।

Soulwise ਦੀ ਹੱਦ ਯੂਜ਼ਰ ਦੀ ਆਪਣੀ ਬੇਸਲਾਈਨ ਤੋਂ 30 ਫ਼ੀਸਦੀ ਓਪਨ-ਰੇਟ ਘਾਟ ਹੈ। ਜੇ ਕੋਈ ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ 60 ਫ਼ੀਸਦੀ ਪੁਸ਼ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਰੋਲਿੰਗ ਵਿੰਡੋ 42 ਫ਼ੀਸਦੀ ਜਾਂ ਇਸ ਤੋਂ ਹੇਠਾਂ ਡਿੱਗ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਮਾਡਲ ਉਸ ਨੂੰ ਇੱਕ ਟੀਅਰ ਹੇਠਾਂ ਕਰ ਦਿੰਦਾ ਹੈ। ਕਿਸੇ ਇੱਕ ਬੁਰੇ ਹਫ਼ਤੇ (ਛੁੱਟੀ, ਬਿਮਾਰੀ, ਕੰਮ ਦਾ ਭਾਰੀ ਹਫ਼ਤਾ) ਉੱਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਤੋਂ ਬਚਣ ਲਈ ਇਹ ਘਾਟ ਘੱਟੋ-ਘੱਟ 3 ਦਿਨ ਬਣੀ ਰਹਿਣੀ ਜ਼ਰੂਰੀ ਹੈ।

ਤਰੱਕੀ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਹੁੰਦੀ ਹੈ। ਜੇ ਕੋਈ ਯੂਜ਼ਰ T2 'ਤੇ ਹੈ ਅਤੇ ਉਸ ਦਾ ਓਪਨ ਰੇਟ 3 ਲਗਾਤਾਰ ਦਿਨਾਂ ਲਈ ਆਪਣੀ ਬੇਸਲਾਈਨ ਤੋਂ 30 ਫ਼ੀਸਦੀ ਹੱਦ ਘਟਾ ਕੇ ਉਸ ਤੋਂ ਉੱਪਰ ਚੜ੍ਹ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ T1 'ਤੇ ਉੱਪਰ ਚਲਾ ਜਾਂਦਾ ਹੈ। T0 ਤੱਕ ਮੁੜ ਆਉਣ ਲਈ ਵੀ ਇਹੀ ਕਦਮ ਲੱਗਦਾ ਹੈ।

ਘਟਨਾ-ਅਧਾਰਿਤ ਪੁਸ਼ ਸਭ ਤੋਂ ਲੰਮਾ ਕਿਉਂ ਟਿਕਦੇ ਹਨ

Localytics / Urban Airship ਦਾ ਉਹ ਡਾਟਾ ਪੁਆਇੰਟ ਜੋ ਇਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ: ਘਟਨਾ-ਅਧਾਰਿਤ ਰੋਜ਼ਾਨਾ ਪੁਸ਼ ਆਮ ਰੋਜ਼ਾਨਾ ਪੁਸ਼ ਨਾਲੋਂ ਲਗਭਗ 2.85x ਰਿਟੈਨਸ਼ਨ ਪੈਦਾ ਕਰਦੇ ਹਨ। 9 ਵਜੇ ਆਉਂਦਾ ਆਮ "check in with us!" ਭੁੱਲ ਜਾਣ ਵਾਲਾ ਹੁੰਦਾ ਹੈ। ਪਰ ਅੱਜ ਦੀ ਅਸਲ ਚੱਕਰ-ਅਵਸਥਾ ਨਾਲ ਜੁੜਿਆ ਸਵੇਰ ਦਾ ਸੁਨੇਹਾ ("ਨਰਮ ਸ਼ੁਰੂਆਤ। ਅੱਜ ਤੁਹਾਡੇ ਅੱਗੇ ਕੀ ਹੈ?") ਘਟਨਾ-ਅਧਾਰਿਤ ਹੁੰਦਾ ਹੈ - ਇਸ ਵਿੱਚ ਨਵੀਂ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ।

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

ਥਕਾਵਟ-ਬੈਨਰ UX

ਜਦੋਂ ਕਿਸੇ ਯੂਜ਼ਰ ਨੂੰ ਡਿਮੋਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਗਲੀ ਵਾਰ ਜਦੋਂ ਉਹ app ਖੋਲ੍ਹਦੇ ਹਨ ਤਾਂ app ਅੰਦਰ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਬੈਨਰ ਦਿਖਾਉਂਦੀ ਹੈ:

"ਅਸੀਂ 7 ਦਿਨਾਂ ਲਈ ਥੋੜ੍ਹਾ ਘਟਾ ਦਿੱਤਾ ਹੈ - ਮੁੜ ਵਧਾਉਣਾ ਹੈ?"

ਇਹ ਵਾਕ ਤਿੰਨ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ ਬਦਲਾਅ ਨੂੰ ਮੰਨਦਾ ਹੈ, ਇਸ ਨੂੰ app ਦੇ ਵਿਹਾਰ ਨਾਲ ਜੋੜਦਾ ਹੈ (ਯੂਜ਼ਰ ਦੀ ਨਾਕਾਮੀ ਨਾਲ ਨਹੀਂ), ਅਤੇ ਚੋਣ ਦਿੰਦਾ ਹੈ। ਜੇ ਯੂਜ਼ਰ ਚਾਹੇ ਤਾਂ ਇੱਕੋ ਟੈਪ ਨਾਲ ਡਿਮੋਟ ਨੂੰ ਬਦਲ ਕੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਾਪਸ ਲਿਆ ਸਕਦਾ ਹੈ।

ਇਹ ਇਸ ਲਈ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਚੁੱਪ-ਚਾਪ ਕੀਤੀ ਡਿਮੋਟ ਇੰਝ ਲੱਗਦੀ ਹੈ ਜਿਵੇਂ app ਯੂਜ਼ਰ ਨੂੰ ਛੱਡ ਰਹੀ ਹੋਵੇ। ਖੁੱਲ੍ਹ ਕੇ ਦੱਸੀ ਗਈ ਡਿਮੋਟ ਇੰਝ ਲੱਗਦੀ ਹੈ ਜਿਵੇਂ app ਪਰਵਾਹ ਕਰ ਰਹੀ ਹੋਵੇ। ਉਹੀ ਕੰਮ, ਪਰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਪੇਸ਼।

ਉਹ ਐਂਟੀ-ਪੈਟਰਨ ਜੋ ਅਸੀਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਨਹੀਂ ਬਣਾਏ

ਪ੍ਰੋਡਕਟ ਸਪੈੱਕ ਸਾਫ਼-ਸਾਫ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ-ਕੀ ਮਨ੍ਹਾਂ ਹੈ:

• ਕੋਈ "ਆਪਣੀ ਸਟ੍ਰੀਕ ਨਾ ਤੋੜੋ" ਵਾਲਾ ਦੋਸ਼-ਪ੍ਰੇਰਿਤ ਪੁਸ਼ ਨਹੀਂ। ਸਟ੍ਰੀਕਸ ਨੁਕਸਾਨ ਤੋਂ ਡਰਾ ਕੇ ਸ਼ਰਮਿੰਦਾ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹਨ। ਥਕਾਵਟ ਮਾਡਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਹੇਠਾਂ ਲੈ ਆਉਂਦਾ ਹੈ; ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ਰਮਿੰਦਾ ਨਹੀਂ ਕਰਦਾ।
• T3 ਦੇ ਅੰਤ 'ਤੇ ਕੋਈ "ਅਸੀਂ ਤੁਹਾਨੂੰ ਯਾਦ ਕਰਦੇ ਹਾਂ" ਵਾਲਾ ਮੁੜ-ਸਰਗਰਮੀ ਪੁਸ਼ ਨਹੀਂ। T3 'ਤੇ ਮੌਜੂਦ ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਹੀ app ਨੂੰ ਕੁਝ ਦੱਸ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਹੋਰ ਪੁਸ਼ ਜੋੜਨਾ ਗਲਤ ਜਵਾਬ ਹੈ।
• ਪੁਸ਼ ਦੇ ਮੁੱਖ ਭਾਗ ਵਿੱਚ ਕੋਈ ਨਕਲੀ ਕਾਊਂਟਰ ਜਾਂ ਕਮੀ ਦਾ ਡਰਾਵਾ ਨਹੀਂ। "X ਲੋਕਾਂ ਨੇ ਹੁਣੇ ਸਾਈਨ ਅੱਪ ਕੀਤਾ" ਇੱਕ ਡਾਰਕ-ਪੈਟਰਨ ਨਾਟਕ ਹੈ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਨਹੀਂ।
• ਪੁਸ਼ ਦੇ ਟਾਈਟਲ ਜਾਂ ਮੁੱਖ ਭਾਗ ਵਿੱਚ ਕੋਈ ਮਾਹਵਾਰੀ ਜਾਂ ਜੋਤਿਸ਼ ਸਮੱਗਰੀ ਨਹੀਂ। ਪੁਸ਼ ਇੱਕ CI lint ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਜੋ ਮਨ੍ਹਾਂ ਪੈਟਰਨਾਂ ਵਾਲੇ ਬਿਲਡ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ; ਥਕਾਵਟ ਮਾਡਲ ਇਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਟਾਲਦਾ।

ਸਿਸਟਮ ਦੇ ਅੰਦਰਲਾ ਡਾਟਾ ਅਸਲ ਵਿੱਚ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ

ਮਾਡਲ ਹਰ ਯੂਜ਼ਰ ਦੀ ਸਥਿਤੀ ਤਿੰਨ ਫੀਲਡਾਂ ਨਾਲ ਸੰਭਾਲ ਕੇ ਰੱਖਦਾ ਹੈ:

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 to 1.0
baseline_open_rate: 0.0 to 1.0 (computed from first 30 days)
last_tier_change_at: timestamp

ਬੱਸ ਇਹੀ ਪੂਰੀ ਥਕਾਵਟ ਸਥਿਤੀ ਹੈ। ਨਾ ਕੋਈ ਬ੍ਰਾਊਜ਼ਿੰਗ ਹਿਸਟਰੀ, ਨਾ ਓਪਨ ਰੇਟ ਤੋਂ ਅੱਗੇ ਕੋਈ ਐਂਗੇਜਮੈਂਟ ਸਕੋਰਿੰਗ, ਨਾ ਯੂਜ਼ਰ ਉੱਤੇ ਟ੍ਰੇਨ ਕੀਤਾ ਕੋਈ ਮਸ਼ੀਨ-ਲਰਨਿੰਗ ਮਾਡਲ। ਇਹ ਸਾਦਗੀ ਹੀ ਅਸਲ ਗੱਲ ਹੈ: ਨਿਯਮ ਜਾਂਚਣਯੋਗ ਹਨ, ਥ੍ਰੈਸ਼ਹੋਲਡ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਦਰਜ ਹਨ, ਅਤੇ UX ਉੱਤੇ ਪੈਣ ਵਾਲੇ ਅਸਰ ਪਹਿਲਾਂ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਯੋਗ ਹਨ।

ਇਹ ਕੀ ਨਹੀਂ ਹੈ

ਦਾਇਰੇ ਬਾਰੇ ਇੱਕ ਨੋਟ।

ਥਕਾਵਟ ਮਾਡਲ ਹਰ ਯੂਜ਼ਰ ਲਈ ਵੱਖਰਾ ਹੈ, ਕਿਸੇ ਸਮੂਹ ਲਈ ਨਹੀਂ। ਅਸੀਂ "ਤੁਹਾਡੇ ਵਰਗੇ ਯੂਜ਼ਰ" ਨੂੰ ਨਹੀਂ ਵੇਖਦੇ ਅਤੇ ਨਾ ਹੀ ਅਜਿਹੇ ਪ੍ਰਯੋਗ ਕਰਦੇ ਹਾਂ ਜੋ ਰਿਟੈਂਸ਼ਨ ਬਾਰੇ ਸਿੱਖਣ ਲਈ ਯੂਜ਼ਰਾਂ ਨੂੰ ਘਟਾ ਦੇਣ। ਇਹ ਮਾਡਲ ਹਰ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ।

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

ਇਹ ਬਾਕੀ app ਲਈ ਕਿਉਂ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ

Push notifications ਹੀ ਉਹ ਤਰੀਕਾ ਹਨ ਜਿਸ ਨਾਲ ਰੋਜ਼ਾਨਾ ਦੀ ਰੀਤ ਰੋਜ਼ਾਨਾ ਬਣੀ ਰਹਿੰਦੀ ਹੈ। ਜਿਹੜੀ check-in app ਆਪਣੇ push ਦੇ ਹੱਕ ਗੁਆ ਬੈਠਦੀ ਹੈ, ਉਹ ਆਪਣਾ ਮੁੱਖ retention loop ਗੁਆ ਦਿੰਦੀ ਹੈ। 4-tier ਮਾਡਲ ਇਸੇ ਲਈ ਹੈ ਤਾਂ ਜੋ app ਇਸ ਹੱਕ ਦੀ ਦੁਰਵਰਤੋਂ ਨਾ ਕਰੇ ਅਤੇ ਇਸ ਨੂੰ ਹੌਲੀ ਤਰੀਕੇ ਨਾਲ ਨਾ ਗੁਆਏ - ਬੱਸ ਥੋੜ੍ਹਾ ਜਿਹਾ ਤੰਗ ਕਰਦੇ ਰਹਿ ਕੇ, ਉਨ੍ਹਾਂ ਚਿਰ ਤੱਕ ਕਿ ਗੱਲ ਵਿਗੜ ਜਾਏ।

ਰੋਜ਼ਾਨਾ ਦੀ ਰੀਤ ਦਾ ਪੂਰਾ ਪ੍ਰਸੰਗ Soulwise hub ਉੱਤੇ ਹੈ। Fatigue ਮਾਡਲ ਇਸ ਗੱਲ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ ਕਿ ਇਹ ਰੀਤ ਜ਼ਿੱਦੀ ਮੰਗਣ ਵਾਲੀ ਬਣਨ ਦੀ ਬਜਾਏ ਆਪਸੀ ਕਿਉਂ ਬਣੀ ਰਹਿੰਦੀ ਹੈ।

ਛੋਟੀ ਜਿਹੀ ਗੱਲ: pushes ਦੀ ਸਹੀ ਗਿਣਤੀ ਉਹ ਸਭ ਤੋਂ ਵੱਡੀ ਗਿਣਤੀ ਹੈ ਜੋ opt-out ਦਾ ਕਾਰਨ ਨਾ ਬਣੇ। Fatigue ਮਾਡਲ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ app ਹਰ ਵਰਤੋਂਕਾਰ ਲਈ, ਹਰ 14 ਦਿਨਾਂ ਬਾਅਦ, ਉਹ ਗਿਣਤੀ ਲੱਭਦੀ ਹੈ।

ਆਮ ਸਵਾਲ

ਰਿਟੈਨਸ਼ਨ ਲਈ ਪੁਸ਼ ਦੀ ਮਾਤਰਾ ਇੰਨੀ ਜ਼ਰੂਰੀ ਕਿਉਂ ਹੈ?

Localytics ਅਤੇ Urban Airship ਦੇ ਉਦਯੋਗ ਅੰਕੜੇ: ਦਿਨ ਵਿੱਚ ਇੱਕ ਪੁਸ਼ ਦਾ ਸੰਬੰਧ ਲਗਭਗ 88% ਤਿੰਨ-ਮਹੀਨਿਆਂ ਦੀ ਰਿਟੈਨਸ਼ਨ ਨਾਲ ਹੈ। ਦਿਨ ਵਿੱਚ ਤਿੰਨ ਪੁਸ਼ ਇਸਨੂੰ 17 ਫ਼ੀਸਦੀ ਅੰਕ ਘਟਾ ਦਿੰਦੇ ਹਨ। ਦਿਨ ਵਿੱਚ ਪੰਜ ਪੁਸ਼ ਇਸਨੂੰ 34 ਫ਼ੀਸਦੀ ਅੰਕ ਘਟਾ ਦਿੰਦੇ ਹਨ। ਇਹ ਢਲਾਣ ਬਹੁਤ ਤਿੱਖੀ ਹੈ।

ਇੱਥੇ "ਰੋਲਿੰਗ 14-ਦਿਨਾਂ ਦੀ ਵਿੰਡੋ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ?

ਹਰ ਦਿਨ ਮਾਡਲ ਪਿਛਲੇ 14 ਦਿਨਾਂ ਦੌਰਾਨ ਯੂਜ਼ਰ ਦੀ ਓਪਨ ਰੇਟ ਮੁੜ ਗਿਣਦਾ ਹੈ। ਵਿੰਡੋ ਅੱਗੇ ਖਿਸਕਦੀ ਜਾਂਦੀ ਹੈ; ਪੁਰਾਣਾ ਡੇਟਾ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਹਾਲੀਆ ਘਟਦੀ ਰੁਚੀ ਤੇਜ਼ੀ ਨਾਲ ਫੜੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਇੱਕ ਮਾੜੇ ਹਫ਼ਤੇ 'ਤੇ ਹੱਦੋਂ ਵੱਧ ਪ੍ਰਤੀਕਿਰਿਆ ਨਹੀਂ ਹੁੰਦੀ।

ਕੀ ਕੋਈ ਯੂਜ਼ਰ ਹੇਠਲੇ ਟੀਅਰ ਤੋਂ ਉੱਪਰ ਆ ਸਕਦਾ ਹੈ?

ਹਾਂ। ਜੇ ਓਪਨ ਰੇਟ ਰੋਲਿੰਗ ਵਿੰਡੋ ਅੰਦਰ ਮੁੜ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਉੱਪਰ ਚੜ੍ਹ ਜਾਵੇ, ਤਾਂ ਯੂਜ਼ਰ ਮੁੜ ਉੱਪਰ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਮਾਡਲ ਸਮਮਿਤ ਹੈ। ਘਾਟਾ ਹੇਠਾਂ ਲਿਆਉਂਦਾ ਹੈ, ਸੁਧਾਰ ਉੱਪਰ ਲੈ ਜਾਂਦਾ ਹੈ।

ਇਸ ਫ਼ੀਚਰ ਦਾ ਸਭ ਤੋਂ ਬੁਰਾ ਰੂਪ ਕੀ ਹੈ?

ਇੱਕ ਅਜਿਹਾ ਨਾਸਮਝ ਪੁਸ਼ ਸਿਸਟਮ ਜੋ ਰੁਚੀ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਮਾਤਰਾ ਭੇਜਦਾ ਹੈ। ਉਦਯੋਗ ਅੰਕੜੇ ਦੱਸਦੇ ਹਨ ਕਿ 46% ਯੂਜ਼ਰ ਪੁਸ਼ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਅਜਿਹੀ ਐਪ ਤੋਂ ਹਫ਼ਤੇ ਵਿੱਚ 2 ਤੋਂ 5 ਪੁਸ਼ ਮਿਲਦੇ ਹਨ ਜਿਸਨੂੰ ਉਹ ਸਰਗਰਮੀ ਨਾਲ ਨਹੀਂ ਚਾਹੁੰਦੇ। ਫ਼ੈਟੀਗ ਮਾਡਲ ਇਸੇ ਲਈ ਮੌਜੂਦ ਹੈ ਤਾਂ ਜੋ ਇਹ ਓਪਟ-ਆਊਟ ਕਦੇ ਨਾ ਹੋਵੇ।