ਉਹ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਜੋ ਲੋਕ ਬੰਦ ਨਹੀਂ ਕਰਦੇ: ਟਾਇਮਿੰਗ ਅਤੇ ਡਿਜ਼ਾਇਨ

ਲੋਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਿਉਂ ਬੰਦ ਕਰਦੇ ਹਨ

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

ਜ਼ਿਆਦਾਤਰ opt-out ਸਧਾਰਣ ਕਾਰਨਾਂ ਕਰਕੇ ਹੁੰਦੇ ਹਨ। ਸੁਨੇਹੇ ਬਹੁਤ ਵਾਰੀ ਆਉਂਦੇ ਹਨ, ਉਹ ਸੰਗਤ ਨਹੀਂ ਹੁੰਦੇ, ਜਾਂ ਗਲਤ ਸਮੇਂ ਆਉਂਦੇ ਹਨ (ਰਾਤ ਨੂੰ, ਕੰਮ ਵਕਤ, ਜਾਂ ਓਦੋ ਜਦ ਯੂਜ਼ਰ ਨੇ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰ ਲਿਆ ਹੋਵੇ)। ਕਈ ਵਾਰੀ ਸਮੱਗਰੀ ਧੁੰਦਲੀ ਜਾਂ ਕਲਿਕਬੇਟੀ ਹੋ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਯੂਜ਼ਰ ਉਸ 'ਤੇ ਭਰੋਸਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਤੇ ਜੇ ਪਹਿਲੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਉਸ ਵੇਲੇ ਆ ਜਾਂਦੀ ਹੈ ਜਦ ਯੂਜ਼ਰ ਐਪ ਦੀ ਵੈਲਿਊ ਸਮਝਦਾ ਹੀ ਨਹੀਂ, ਤਾਂ ਇਹ ਲੱਗਦਾ ਹੈ: “ਤੁਸੀਂ ਮੈਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਜਾਣਦੇ, ਪਰ ਮੈਂਲોક-ਸਕ੍ਰੀਨ ਦੀ ਪਹੁੰਚ ਚਾਹੁੰਦੇ ਹੋ।”

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

ਅਸਲ ਮਕਸਦ ਇੱਕ ਵਾਰੀ ਆਗਿਆ ਜਿੱਤਣਾ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਹੈ ਮਹੀਨਿਆਂ ਤੱਕ ਆਗਿਆ ਬਰਕਰਾਰ ਰੱਖਣਾ, ਕਿਉਂਕਿ ਹਰ ਸੁਨੇਹਾ ਆਪਣੀ ਜਗ੍ਹਾ ਕਮਾਉਂਦਾ ਹੈ।

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

ਜਿਹੜੇ ਪੈਟਰਨ ਆਮ ਤੌਰ 'ਤੇ opt-out ਨੂੰ ਤਰੱਕੀ ਦਿੰਦੇ ਹਨ ਉਹ ਭਵਿਸ਼ਯਵਾਣੀਯੋਗ ਹਨ: ਪਹਿਲੀ ਲਾਂਚ 'ਤੇ ਬਿਨਾਂ ਵਾਜੇ ਪੁੱਛਣਾ, ਨਿੱਜੀ ਮੁੱਲ ਬਿਨਾਂ "We miss you" ਜਿਹੇ ਸੁਨੇਹੇ ਭੇਜਣਾ, ਇੱਕੋ ਹੀ ਰੀਮਾਈਂਡਰ ਨੂੰ ਦੋ ਵਾਰੀ ਇਗਨੋਰ ਕਰਨ ਦੇ ਬਾਅਦ ਦੁਹਰਾਉਣਾ, ਰੋਟੀਨ ਅਪਡੇਟਾਂ ਲਈ ਤਤਕਾਲਤਾ ਵਾਲੇ ਸ਼ਬਦ ਵਰਤਣਾ, ਅਤੇ ਮਾਰਕੀਟਿੰਗ ਬਲਾਸਟਸ ਨੂੰ ਜ਼ਰੂਰੀ ਅਲਰਟਾਂ ਨਾਲ ਮਿਲਾਉਣਾ।

ਜਦ ਤੁਸੀਂ ਪੁਸ਼ ਨੂੰ ਇੱਕ ਸਨਮਾਨ ਵਾਂਗ ਸਮਝਦੇ ਹੋ, ਯੂਜ਼ਰ ਇਸ ਨੂੰ ਇੱਕ ਫ਼ਾਇਦਾ ਵਾਂਗ ਸਮਝਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਮੁਫ਼ਤ ਵਿਗਿਆਪਨ ਸਪੇਸ ਵਾਂਗ ਦਰਸਾਉਂਦੇ ਹੋ, ਯੂਜ਼ਰ ਇਸ ਨੂੰ ਸਪੈਮ ਵਾਂਗ ਸਮਝਦੇ ਹਨ।

ਕੋਈ ਕਿਸੇ ਨੂੰ opt-in ਕਰਨ ਲਈ ਕੀ ਕਰਦਾ ਹੈ

ਲੋਕ “Allow” ਟੈਪ ਕਰਦੇ ਹਨ ਜਦ ਉਹ ਮੰਨਦੇ ਹਨ ਕਿ ਨੋਟੀਫਿਕੇਸ਼ਨ ਉਹਨਾਂ ਦੀ ਮਦਦ ਕਰਨਗੇ, ਐਪ ਦੀ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਆਗਿਆ ਨੂੰ ਇੱਕ ਮੁੱਲ ਦੇ ਲੈਣ-ਦੇਣ ਵਜੋਂ ਪੇਸ਼ ਕਰੋ: ਤੁਸੀਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵਾਅਦਾ ਕਰੋ, ਫਿਰ ਇਸਨੂੰ ਲਗਾਤਾਰ ਪੂਰਾ ਕਰੋ।

ਪ੍ਰਸ਼ਨ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ, ਵਾਅਦਾ ਸੌਖੇ ਬੋਲ ਵਿੱਚ ਦੱਸੋ। ਓਹਲੇ ਜਿਹੇ ਬੋਲਾਂ ਤੋਂ ਬਚੋ ਜਿਵੇਂ “Stay up to date.” ਇਸਦੀ ਥਾਂ ਇਹ ਦੱਸੋ ਕਿ ਕੀ ਆਵੇਗਾ, ਕਿਉਂ ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਯੂਜ਼ਰ ਇਸ ਨੂੰ ਕਿਵੇਂ ਕੰਟਰੋਲ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਚੰਗੀ ਪ੍ਰੀ-ਪਰਮੀਸ਼ਨ ਸਕ੍ਰੀਨ ਤਿੰਨ ਗੱਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਤੁਸੀਂ ਕੀ ਭੇਜੋ ਗੇ (ਆਰਡਰ ਸਟੇਟਸ, ਰਿਮਾਈਂਡਰ, ਕੀਮਤ ਘਟਣਾ, ਸੁਰੱਖਿਆ ਅਲਰਟ), ਇਹ ਕਿੰਨੀ ਵਾਰ ਹੋਵੇਗਾ (ਅਤੇ “ਸਿਰਫ ਕਦੇ-ਕਦੇ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ), ਅਤੇ ਉਹ ਬਾਅਦ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲ ਸਕਦੇ ਹਨ (ਪਸੰਦਾਂ, ਮਿੂਟ, ਖਾਮੋਸ਼ ਘੰਟੇ)।

ਜਦ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਿਸੇ ਅਸਲ ਲਕੜੀ ਲਕੜੀ ਹੇਠਾਂ ਆਉਂਦੇ ਹਨ ਜਿਹੜਾ ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਹੀ ਚਾਹੁੰਦਾ ਹੈ, ਤਦ opt-ins ਵਧਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਦੇ ਘੱਟ-ਵਿਕਲਪਾਂ ਵਿੱਚ ਸੋਚੋ: ਉਹ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਨਾ ਕਿ ਤੁਸੀਂ ਕੀ ਪ੍ਰਚਾਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਲੋਕ ਬਹੁਤ ਵਧੇਰੇ ਸੰਭਾਵਨਾ ਰੱਖਦੇ ਹਨ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਈ ਜਦੋਂ ਇਹ ਸਪਸ਼ਟ ਫਾਇਦਾ ਹੋਵੇ: ਬਚਤ ("Price dropped"), ਯਾਦ ਦਿਵਾਣਾ ("ਤੁਹਾਡੀ ਅਪੌਇੰਟਮੈਂਟ 2 ਘੰਟੇ ਵਿੱਚ ਹੈ"), ਅਪਡੇਟ ("ਤੁਹਾਡੀ ਡਿਲੀਵਰੀ 10 ਮਿੰਟ ਵਿੱਚ ਆ ਰਿਹਾ ਹੈ"), ਸੁਰੱਖਿਆ ("ਨਵਾਂ ਸਾਈਨ-ਇਨ"), ਜਾਂ ਪ੍ਰਗਤੀ ("ਤੁਸੀਂ ਆਪਣਾ ਹਫਤਾਵਾਰੀ ਲਕੜਾ ਪੂਰਾ ਕੀਤਾ").

ਆਗਿਆ ਦੇਣ ਦੀ ਉਮੀਦ ਸਵੇਰੇ ਦਸੋ, ਭਾਵੇਂ ਇਹ ਘੱਟ "ਸੇਲਜ਼ੀ" ਲੱਗੇ। ਜੇ ਤੁਸੀਂ ਹਫਤੇ ਵਿੱਚ 5 ਸੁਨੇਹੇ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਦੱਸੋ। ਜੇ ਇਹ ਸਿਰਫ ਟ੍ਰਿਗਰ-ਅਧਾਰਤ ਹੈ (ਜਿਵੇਂ ਸ਼ਿਪਿੰਗ ਅਪਡੇਟ), ਉਹ ਵੀ ਦੱਸੋ। ਹੈਰਾਨੀਆਂ ਅਣਭਰੋਸਾ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਅਣਭਰੋਸਾ opt-outs ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।

ਸਿਸਟਮ ਪ੍ਰੰਪਟ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਛੋਟਾ ਨਮੂਨਾ ਦਿਖਾਓ। ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ ਇੱਕ ਪੈਰਾ ਕਾਪੀ ਨਾਲੋਂ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ালী ਹੋ ਸਕਦੀ ਹੈ:

"ਨਮੂਨਾ ਨੋਟੀਫਿਕੇਸ਼ਨ: ਤੁਹਾਡਾ ਪੈਕੇਜ ਡਿਲਿਵਰੀ ਲਈ ਨਿਕਲ ਚੁੱਕਾ ਹੈ - ਪਹੁੰਚ 3:10 ਅਤੇ 3:40 PM ਦਰਮਿਆਨ।"

ਇਹ ਇਕ ਲਾਈਨ ਲੋਕਾਂ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਉਹਨਾਂ ਦਾ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਪੈਮ ਨਹੀਂ ਭੇਜਣਗੇ।

ਉਹ ਸਮਾਂ ਜਦ ਪੁੱਛਣਾ ਕੁਦਰਤੀ ਲੱਗੇ

ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਨਫ਼ਰਤ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਬਿਨਾਂ ਸਮੇਂ ਮੰਗਣ ਵਾਲੇ ਬੋਰੀਏ ਹੋਏ ਹਨ। ਪਰਮੀਸ਼ਨ ਦਾ ਸਮਾਂ ਅਕਸਰ ਫਰਕ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲੋਕ ਬੰਦ ਨਹੀਂ ਕਰਦੇ ਜਾਂ ਪੱਕਾ ਕਰ ਕੇ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ।

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

ਇੱਕ ਭਰੋਸੇਮੰਦ ਪੈਟਰਨ ਹੈ: ਸਿਸਟਮ ਅਨੁਮਤੀ ਪ੍ਰੰਪਟ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸੌਫਟ-ਅਸਕ ਸਕ੍ਰੀਨ। ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ: ਉਹ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਗੇ, ਕਿੰਨੀ ਵਾਰ, ਅਤੇ ਕਿਉਂ ਇਹ ਮਦਦਗਾਰ ਹੈ। ਫਿਰ ਦੋ ਸਪਸ਼ਟ ਬਟਨ ਦਿਖਾਓ: "Allow notifications" ਅਤੇ "Not now." ਸਿਰਫ ਜਦ ਉਹ "Allow" ਚੁਣਦੇ ਹਨ ਤਦ ਸਿਸਟਮ ਪ੍ਰੰਪਟ ਦਿਖਾਓ। ਇਹ ਹੈਰਾਨੀ ਦੂਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰਦਾ ਹੈ।

ਪੁੱਛਣ ਦੇ ਚੰਗੇ ਮੋਹਰਿਆਂ ਵਿੱਚ ਉਹ ਘਟਨਾਵਾਂ ਸ਼ਾਮਲ ਹਨ ਜੋ ਜਿੱਤ ਤੋਂ ਬਾਅਦ ਹੁੰਦੀਆਂ ਹਨ (ਆਰਡਰ ਰੱਖਿਆ ਗਿਆ, ਲਕੜੀ ਪੂਰੀ ਹੋਈ), ਕਿਸੇ ਨੂੰ ਫਾਲੋ ਜਾਂ ਸਬਸਕ੍ਰਾਈਬ ਕਰਨ ਦੇ ਬਾਅਦ, ਸੇਵ/ਬੁੱਕਮਾਰਕ ਕਰਨ ਦੇ ਬਾਅਦ, ਰਿਮਾਈਂਡਰ ਸੈੱਟ ਕਰਨ ਜਾਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਬਾਅਦ, ਜਾਂ ਓਸ ਫੀਚਰ ਨੂੰ ਚਾਲੂ ਕਰਨ ਦੇ ਬਾਅਦ ਜਿਸਨੂੰ ਅਪਡੇਟ ਚਾਹੀਦੇ ਹਨ।

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

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

ਠੋਸ ਉਦਾਹਰਨ: ਇੱਕ ਰੀਸੇਲ ਐਪ ਯੂਜ਼ਰਾਂ ਨੂੰ "ਆਕਾਰ 8 ਬੂਟ" ਲਈ ਸੇਰਚ ਸੇਵ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਜਦ ਉਹ "Save search" ਤੇ ਟੈਪ ਕਰਦੇ ਹਨ, ਤੁਰੰਤ ਇਕ ਸਕ੍ਰੀਨ ਆਉਂਦੀ ਹੈ: "ਚਾਹੁੰਦੇ ਹੋ ਨਵੀਆਂ ਮਿਲਣ ਵਾਲੀਆਂ ਨੂੰ ਅਲਰਟ ਮਿਲਣ? ਅਸੀਂ ਇੱਕ ਦਿਨ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ 1 ਭੇਜਾਂਗੇ।" ਇਹ ਬੇਨਤੀ ਉਚਿਤ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਸ ਚੀਜ਼ ਨਾਲ ਜੁੜੀ ਹੈ ਜੋ ਯੂਜ਼ਰ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਮੰਗੀ।

ਨੋਟੀਫਿਕੇਸ਼ਨ ਪ੍ਰੇਫਰੰਸ ਸੈਂਟਰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ

ਇੱਕ ਚੰਗਾ ਪ੍ਰੇਫਰੰਸ ਸੈਂਟਰ ਤੁਹਾਡਾ ਸੁਰੱਖਿਆ ਵਾਲਵ ਹੈ। ਇਹ ਲੋਕਾਂ ਨੂੰ ਸਿਸਟਮ-ਸਤਰ 'ਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਚੀਜ਼ਾਂ ਨੂੰ ਉਤਰ ਜਾਂ ਵਧਾ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਫੰਸੇ ਹੋਏ ਮਹਿਸੂਸ ਕੀਤੇ।

ਸ਼ੁਰੂ ਕਰੋ ਉਹ ਤਿੰਨ ਨਿਯੰਤਰਣਾਂ ਨਾਲ ਜੋ ਜਿਆਦਾਤਰ ਲੋਕ ਤੁਰੰਤ ਸਮਝ ਲੈਂਦੇ ਹਨ: ਟਾਪਿਕਸ, ਫ੍ਰਿਕਵੈਂਸੀ, ਅਤੇ ਖਾਮੋਸ਼ ਘੰਟੇ। ਟਾਪਿਕਸ ਉਨ੍ਹਾਂ ਨੂੰ ਉਹ ਚੁਣਨ ਦਿੰਦੇ ਹਨ ਜੋ ਉਹ ਅਸਲ ਵਿੱਚ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਫ੍ਰਿਕਵੈਂਸੀ ਉਹ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜੋ ਕਈ opt-outs ਦੇ ਪਿੱਛੇ ਹੁੰਦਾ ਹੈ: "ਤੁਸੀਂ ਮੈਨੂੰ ਇੰਨਾ ਕਿਉਂ ਭੇਜ ਰਹੇ ਹੋ?" ਖਾਮੋਸ਼ ਘੰਟੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਰੋਕਦੇ ਹਨ ਜਿੱਥੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ: ਗਲਤ ਸਮੇਂ ਇੱਕ ਵਾਈਬਰੇਸ਼ਨ।

ਸ਼ਾਮਿਲ ਕਰਨ ਲਈ ਨਿਯੰਤਰਣ (ਤੇ ਕਿਵੇਂ ਲੇਬਲ ਕਰੋ)

ਚੋਣਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸਿੱਧਾ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ 20 ਟੌਗਲ ਦਿੰਦੇ ਹੋ, ਲੋਕ ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਕਰਨਗੇ, ਉਹ ਤੁਹਾਨੂੰ ਬੰਦ ਕਰ ਦੇਣਗੇ।

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

ਡਿਫਾਲਟਾਂ ਮਹੱਤਵਪੂਰਣ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਮਦਦਗਾਰ ਪਰ ਅਤਿਆਕਰਸ਼ਕ ਨਾ ਰੱਖੋ। ਕਈ ਉਤਪਾਦਾਂ ਵਿੱਚ ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹੁੰਦਾ ਹੈ: ਅਹਮ ਅਲਰਟ ऑन (ਸੁਰੱਖਿਆ ਜਾਂ ਲੈਣ-ਦੇਣ ਸਥਿਤੀ), ਮਾਰਕੀਟਿੰਗ-ਸ਼ੈਲੀ ਅਪਡੇਟ ਬੰਦ, ਅਤੇ ਜੇ ਮਾਇਨੇ ਹੋਵੇ ਤਾਂ ਫ੍ਰਿਕਵੈਂਸੀ ਡਾਈਜੈਸਟ 'ਤੇ। ਜੇ ਹਰ ਚੀਜ਼ ਪਹਿਲਾਂ ਤੋਂ ਓਨ ਹੈ, ਤੁਸੀਂ ਦਿਨ ਇੱਕ 'ਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਥਕਾਵਟ ਪੈਦਾ ਕਰ ਰਹੇ ਹੋ।

ਇਸਨੂੰ ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ

ਪਸੰਦਾਂ ਨੂੰ ਕੇਵਲ ਡੂੰਘੀਆਂ ਸੈਟਿੰਗ ਮੇਨੂਜ਼ ਵਿੱਚ ਨਾ ਛੁਪਾਓ। ਉਹਨਾਂ ਨੂੰ ਓਥੇ ਰੱਖੋ ਜਿੱਥੇ ਲੋਕ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵੇਖਦੇ ਹਨ ਜਦੋਂ ਉਹ ਪਰਵਾਹ ਕਰਦੇ ਹਨ।

ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਤੋਂ ਬਾਅਦ ਇੱਕ ਛੋਟੀ ਪ੍ਰੰਪਟ ਦੇਵੋ ਜਿਵੇਂ: "Want updates about this?" ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿੱਧਾ ਟਾਪਿਕ ਅਤੇ ਫ੍ਰਿਕਵੈਂਸੀ ਚੋਣਾਂ 'ਤੇ ਭੇਜੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਕਿਸੇ ਨੇ ਆਰਡਰ ਦਿੱਤਾ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ "Order status" ਪੁਸ਼ ਚਾਲੂ ਕਰਨ ਦਿਓ ਪਰ "Promos" ਬੰਦ ਰਹਿਣ ਦਿਓ।

ਇਸਨੂੰ ਅਕਾਉਂਟ/ਸੈਟਿੰਗਜ਼ ਵਿੱਚ ਵੀ ਅਸਾਨੀ ਨਾਲ ਮਿਲਣਯੋਗ ਰੱਖੋ, ਅਤੇ ਜਿੱਥੇ ਵੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਉਥੇ (ਉਦਾਹਰਣ ਲਈ, ਇਕ in-app ਇਨਬੌਕਸ ਨੇੜੇ "Manage notifications")। ਜੇ ਕੋਈ ਉਪਸ਼ਕ ਹੋਇਆ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਉਹ 10 ਸੈਕੰਡ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ "pause" ਜਾਂ "less often" ਦਾ ਵਿਕਲਪ ਲੱਭ ਦੇਵੇ, ਨਾ ਕਿ ਸਿਸਟਮ ਟੌਗਲ ਦੇਖਣ ਲਈ ਭੱਜੇ।

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਉਤਪਾਦ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੇਫਰੰਸ ਸੈਂਟਰ ਨੂੰ ਪਹਿਲੀ-ਵਰਗੀ ਵਿਸ਼ੇਸਤਾ ਵਾਂਗ ਟਰੇਟ ਕਰੋ, ਪੈਰੋਕਾ ਨਹੀਂ। ਇੱਕ opt-in ਜਿੱਤਣਾ ਰੱਖਣ ਨਾਲ ਉਸਨੂੰ ਮੁੜ ਜਿੱਤਣ ਤੋਂ ਸਸਤਾ ਪੈਂਦਾ ਹੈ।

ਸੁਨੇਹਾ ਡਿਜ਼ਾਇਨ ਜੋ ਯੂਜ਼ਰਾਂ ਦਾ ਭਰੋਸਾ ਕਮਾਉਂਦਾ ਹੈ

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

ਇੱਕ ਮਨੁੱਖ ਵਾਂਗ ਲਿਖੋ। ਛੋਟੇ, ਸਧਾਰਨ ਸ਼ਬਦ ਵਰਤੋਂ, ਅਤੇ ਮੁੱਖ ਜਾਣਕਾਰੀ ਪਹਿਲਾਂ ਰੱਖੋ। "Your report is ready" ਬਹੁਤ ਵਧੀਆ ਹੈ ਬਨਾਮ "New update available." ਵਿਸ਼ੇਸ਼ਤਾ cleverness ਤੋਂ ਵਧੀਕ ਪ੍ਰਭਾਵਸ਼ালী ਹੈ।

ਇੱਕ ਸੁਨੇਹਾ ਇੱਕ ਹੀ ਮਕਸਦ ਲਈ ਰੱਖੋ। ਜੇ ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦੋ ਚੀਜ਼ਾਂ ਇੱਕੋ ਵਾਰੀ ਕਰਦਾ ਹੈ (ਨਿਊਜ਼ + ਪ੍ਰੋਮੋ + ਰੀਮਾਈਂਡਰ), ਇਹ ਐਡ ਵਾਂਗ ਸੁੰਞਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਤੁਹਾਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਦੀ ਆਦਤ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜੇ ਹੋਰ ਕਹਿਣਾ ਹੋਵੇ, ਘੱਟ ਸੁਨੇਹੇ ਭੇਜੋ ਅਤੇ ਬਾਕੀ ਕੰਮ ਐਪ ਵਿੱਚ ਛੱਡੋ।

ਪرسਨਲਾਈਜੇਸ਼ਨ ਕਮਾਈ ਕੇ ਬਾਅਦ ਹੀ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਉਸ ਗੱਲ 'ਤੇ ਆਧਾਰਿਤ ਹੋਵੇ ਜੋ ਯੂਜ਼ਰ ਨੇ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਕੀਤਾ ਹੈ, ਨਾ ਕਿ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਂਦੇ ਹੋ।

ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਕਿਸੇ ਨੇ ਕੱਲ੍ਹ ਸੋਰਸ ਕੋਡ ਨਿਕਸਿਆ (export) ਕੀਤਾ, ਤਾਂ "Export finished. Your ZIP is ready" ਵੇਖਣ ਯੋਗ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਨੂੰ ਭੇਜਦੇ ਹੋ "Build a mobile app today?" ਜਿਸਨੇ ਕਦੇ ਮੋਬਾਈਲ ਲਈ ਨਹੀਂ ਪੁੱਛਿਆ, ਇਹ ਬੇਸਹੂਦਾ ਅਤੇ ਅਜੀਬ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

ਤਤਕਾਲਤਾ ਠੀਕ ਹੈ। ਦਬਾਅ ਨਹੀਂ। ਅਸਲ ਤਤਕਾਲਤਾ ਨਤੀਜੇ ਬਿਨਾਂ ਹਾਇਪਰ ਡਰਾਮਾ ਦੇ ਵਜ੍ਹਾਂ ਬਿਆਨ ਕਰਦੀ ਹੈ:

• ਚੰਗਾ: "Payment failed. Update your card to avoid losing access tomorrow."
• ਮਾੜਾ: "Last chance! Act now!"

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

ਇੱਕ ਸਧਾਰਣ ਟੈਮਪਲੇਟ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ

ਇੱਕ ਲਗਾਤਾਰ ਢਾਂਚਾ ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੁਹਾਡੇ ਸਟਾਈਲ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਸਿਖਾਉਂਦਾ ਹੈ:

• ਕੀ ਵਾਪਰਿਆ (1 ਛੋਟੀ ਵਾਕ)
• ਕਿਉਂ ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ (ਆਵਸ਼ਕ ਹੋਏ ਤਾਂ, 1 ਛੋਟਾ ਵਾਕ)
• ਕੀ ਕਰਨਾ ਹੈ (ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ)

Koder.ai ਵਰਗੇ ਉਤਪਾਦ ਲਈ ਉਦਾਹਰਨ: "Deployment failed. Check logs to retry." ਇਹ ਸਿੱਧਾ ਹੈ, ਇਹ ਯੂਜ਼ਰ ਦੇ ਕੀਤੇ ਕੰਮ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਤਤਕਾਲ ਨਹੀਂ ਦਿਖਾਉਂਦਾ।

ਜਦ ਸੁਨੇਹੇ ਵਿਸ਼ੇਸ਼, ਉਮੀਦ-ਯੋਗ ਅਤੇ ਸਮੇਂਦੇ ਹੋਂਦੇ ਹਨ, ਯੂਜ਼ਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਸਮਝਦੇ ਹਨ, ਨਾ ਕਿ ਸ਼ੋਰ।

ਕਦਮ-ਬਾਇ-ਕਦਮ: ਆਪਣੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਿਸਟਮ ਦੀ ਯੋਜਨਾ

ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਲੋਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਨਾ ਕਰਨ, ਤਾਂ ਯੋਜਨਾ ਬਣਾਉਣਾ ਕਾਪੀ-ਜਿੰਦਾ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਇੱਕ ਛੋਟੀ ਯੋਜਨਾ ਤੁਹਾਨੂੰ "ਜੋ ਵੀ ਲੱਗੇ ਭੇਜ ਦੇ" ਤੋਂ ਰੋਕਦੀ ਹੈ ਅਤੇ ਅਣਜਾਣੇ ਥਕਾਵਟ ਬਣਾਉਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।

1) ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਨਵੈਂਟਰੀ ਬਣਾਓ

ਹਰ ਇੱਕ ਪੁਸ਼ ਸੁਨੇਹਾ ਜੋ ਤੁਸੀਂ ਭੇਜ ਸਕਦੇ ਹੋ ਉਸ ਦੀ ਸੂਚੀ ਬਣਾਓ — ਜਿਹੜੇ ਸਪਸ਼ਟ ਹਨ (ਆਰਡਰ ਅਪਡੇਟ, ਰਿਮਾਈਂਡਰ) ਅਤੇ ਜਿਹੜੇ "ਸ਼ਾਇਦ ਬਾਅਦ" ਵਾਲੇ ਹਨ (ਡਾਈਜੈਸਟ, ਪ੍ਰੋਮੋ)। ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ ਕਾਰਯ-ਨਾਮ ਦਿਓ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਪਸ਼ਟ ਗੱਲ ਕਰ ਸਕੋ।

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

2) ਸੁਨੇਹਿਆਂ ਨੂੰ ਮਕਸਦ

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

ਇਹ ਗਰੁੱਪ ਤੁਹਾਡੇ ਪ੍ਰੇਫਰੰਸ ਸੈਂਟਰ UX ਦੇ ਅਧਾਰ ਬਣਦੇ ਹਨ। ਯੂਜ਼ਰ 25 ਟੌਗਲ ਨਹੀਂ ਚਾਹੁੰਦੇ; ਉਹ 3-6 ਚੋਣਾਂ ਚਾਹੁੰਦੇ ਹਨ ਜੋ ਵਾਜਬੀ ਮਹਿਸੂਸ ਹੋਣ।

3) ਟ੍ਰਿਗਰ ਅਤੇ ਸੀਮਾਵਾਂ ਤੈਅ ਕਰੋ

ਹਰ ਸੁਨੇਹੇ ਲਈ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕੀ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਸੀਮਾਵਾਂ ਹਨ। ਟ੍ਰਿਗਰ ਇਹ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: "ਇਹ ਕਦੋਂ ਲਾਗੂ ਹੁੰਦਾ ਹੈ?" ਸੀਮਾਵਾਂ ਇਹ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ: "ਅਸੀਂ ਸਪੈਮ ਕਿਵੇਂ ਰੋਕਾਂਗੇ?"

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

4) ਟੈਮਪਲੇਟ ਡ੍ਰਾਫਟ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਤਪਾਦ-ਨਾਮ ਦਿੱਤੋ

ਹਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਈ ਇੱਕ ਛੋਟਾ ਟੈਮਪਲੇਟ ਬਣਾਓ: ਸਿਰਲੇਖ, ਬਾਡੀ, ਅਤੇ ਟੈਪ ਕਾਰਵਾਈ। ਇਸਨੂੰ ਉਸ ਨਾਂ ਤੇ ਰੱਖੋ ਜਿਸ ਤਰ੍ਹਾਂ ਯੂਜ਼ਰ ਇਸਨੂੰ ਵੇਰਵੇਂਗੇ, ਨਾ ਕਿ ਅੰਦਰੂਨੀ ਕੋਡ। "Delivery update" ਵਧੀਆ ਹੈ ਬਨਾਮ "SHIP_STATUS_CHANGED_V2."

ਇਹ ਨਾਂਕਰਨ ਅਨੁਸ਼ਾਸਨ ਫਾਇਦਾ ਪਹੁੰਚਾਵੇਗਾ ਜਦ ਤੁਸੀਂ opt-in ਸੁਨੇਹੇ ਅਤੇ ਸੈਟਿੰਗਜ਼ ਬਣਾਉਂਦੇ ਹੋ, ਅਤੇ ਜਦ ਸਹਾਇਤਾ (support) ਨੂੰ ਸਮਝਾਉਣਾ ਪਵੇ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਮਿਲਿਆ।

5) ਅਸਲੀ ਸਥਿਤੀਆਂ ਨਾਲ QA ਕਰੋ

ਆਪਣੀ ਯੋਜਨਾ ਨੂੰ ਅਲੱਗ-ਅਲੱਗ ਯਾਤਰਾਵਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਨਾ ਕਿ ਇਕੋ ਸੁਨੇਹੇ ਨੂੰ ਇਕੱਲੇ। ਨਵਾਂ ਯੂਜ਼ਰ (ਘੱਟ ਭਰੋਸਾ), ਵਾਪਸ ਆਇਆ ਯੂਜ਼ਰ (ਘੱਟ ਹੈਰਾਨੀਆਂ), ਅਤੇ ਪਾਵਰ ਯੂਜ਼ਰ (ਜਿਆਦਾ ਵੋਲਿਊਮ, ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ) ਨੂੰ ਚਲੋ। ਇੱਕ ਕੇਸ ਸ਼ਾਮਲ ਕਰੋ ਜਿੱਥੇ ਕਿਸੇ ਨੇ ਪ੍ਰੋਮੋ ਬੰਦ ਕੀਤਾ ਪਰ ਸੁਰੱਖਿਆ ਅਲਰਟ ਰਖੇ, ਅਤੇ ਇੱਕ ਕੇਸ ਜਿੱਥੇ ਕੋਈ 30 ਦਿਨ ਲਈ ਐਕਟਿਵ ਨਹੀਂ ਰਿਹਾ।

ਜੇ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿਚ ਸੁਨੇਹਿਆਂ ਦਾ ਬਲਾਸਟ, ਗੁੰਝਲਦਾਰ ਸਮਾਂ, ਜਾਂ ਬਹੁਤ ਧਾਰਨਾ ਵਾਲੇ ਸੁਨੇਹੇ ਨਿਕਲਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਪਰਮੀਸ਼ਨ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਟ੍ਰਿਗਰ ਠੀਕ ਕਰੋ ਜਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਕੱਸੋ।

ਆਮ ਗਲਤੀਆਂ ਜੋ opt-outs ਦਾ ਕਾਰਨ ਬਣਦੀਆਂ ਹਨ

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

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

ਇਕ ਹੋਰ ਭਰੋਸਾ ਨਾਸ਼ ਕਰਨ ਵਾਲੀ ਗਲਤੀ ਹੈ ਵਾਲੀਅਮ। ਕਈ ਟੀਮਾਂ ਲੋਕਾਂ ਨੂੰ opt-in ਮਿਲਣ 'ਤੇ ਇੱਕ ਬਰਸਾਟ ਸੁਨੇਹਿਆਂ ਦੀ ਲੜੀ ਭੇਜਦੀਆਂ ਹਨ, "ਨਾਂਹੁੰਦੇ" ਨੂੰ "ਸਰਗਰਮ" ਕਰਨ ਲਈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਥਕਾਵਟ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਯੂਜ਼ਰ ਅਗਲਾ ਕਦਮ ਸਭ ਕੁਝ ਬੰਦ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂਆਤੀ ਸੁਨੇਹੇ ਭੇجਣੇ ਹੀ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਥੋੜ੍ਹੇ, ਵਿਸ਼ੇਸ਼, ਅਤੇ ਯੂਜ਼ਰ ਨੇ ਜੋ ਕੀਤਾ ਉਸ ਨਾਲ ਜੁੜੇ ਰੱਖੋ।

ਧੁੰਦਲੀ ਕਾਪੀ ਵੀ opt-outs ਚਲਾਉਂਦੀ ਹੈ। "Check this out" ਜਾਂ "Don't miss this" ਵਰਗੇ ਸੁਨੇਹੇ ਲੋਕਾਂ ਨੂੰ ਐਪ ਖੋਲ੍ਹਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਉਹ ਸਮਝ ਸਕਣ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਉਂ ਰੋਕਿਆ ਗਿਆ। ਜੇ ਮੂੱਲ ਬੇਸਿਕ ਹੈ ਤਾਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ।

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

ਆਖਰੀ ਗੱਲ: ਪਸੰਦਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਓ। ਜੇ ਮਾਤਰ ਵਿਕਲਪ "ਸਭ" ਜਾਂ "ਕੁਝ ਵੀ ਨਹੀਂ" ਹਨ, "ਕੁਝ ਵੀ ਨਹੀਂ" ਜਿੱਤਦਾ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਭਾਲਣ ਲਈ ਇੱਕ ਤਰੀਕਾ ਵੀ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਵਾਰ-ਵਾਰ ਨਾ ਲੱਭਣ।

ਉਹ ਪੈਟਰਨ ਜੋ ਜ਼ਿਆਦਾਤਰ opt-outs ਦੇ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ: ਪਰਮੀਸ਼ਨ ਪ੍ਰੰਪਟ ਬਹੁਤ ਜਲਦੀ, ਪਹਿਲੇ 24-72 ਘੰਟਿਆਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਸੁਨੇਹੇ, ਸੁਨੇਹੇ ਬਿੰਦੂ ਛੁਪਾਈ ਰੱਖਦੇ, ਭੇਜ ਸਮਾਂ ਅਨੁਕੂਲ ਨਹੀਂ, ਅਤੇ ਇਕ ਸਧਾਰਨ ਨਿਕਾਸੀ ਵਿਕਲਪ (ਪੌਜ਼, ਖਾਮੋਸ਼ ਘੰਟੇ, ਟਾਪਿਕ ਚੋਣ) ਦੀ ਘਾਟ।

ਉਦਾਹਰਨ: ਇੱਕ ਖਰੀਦਦਾਰੀ ਐਪ 7 a.m. ਤੇ ਤਿੰਨ ਦਿਨ ਲਗਾਤਾਰ "Big news!" ਭੇਜਦੀ ਹੈ, ਬਿਨਾਂ ਇਹ ਮੋਡ mute ਕਰਨ ਦਾ ਤਰੀਕਾ ਦਿੱਤੇ ਕਿ ਵੇਅਰਡਰ ਅੱਪਡੇਟਾਂ ਰੱਖੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਯੂਜ਼ਰ ਸਭ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਕਰ ਦਿੰਦਾ, ਜਿਸ ਨਾਲ ਲਾਭਦਾਇਕ ਅਲਰਟ ਵੀ ਨਹੀਂ ਆਉਂਦੇ।

ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕ

ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ 30 ਸਕਿੰਟ ਲਈ ਰੁਕੋ। ਜ਼ਿਆਦਾਤਰ opt-outs ਉਸ ਸੁਨੇਹੇ ਤੋਂ ਬਾਅਦ ਹੁੰਦੇ ਹਨ ਜੋ ਅਣਉਮੀਦ, ਅਸਪਸ਼ਟ, ਜਾਂ ਬਹੁਤ ਵਾਰ ਕੀਤਾ ਗਿਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

5-ਸਕਿੰਟ ਰਿਲੇਵੈਂਸ ਟੈਸਟ

ਇੱਕ ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਯੂਜ਼ਰ ਇਸਨੂੰ ਅਜੇ ਉਮੀਦ ਕਰ ਰਹੇ ਹੋਣਗੇ?

ਇਕ ਡਿਲਿਵਰੀ ਅਪਡੇਟ ਜਦ ਆਰਡਰ ਸ਼ਿਪ ਹੋਇਆ ਤਾਂ ਠੀਕ ਲੱਗਦਾ ਹੈ। ਇਕ ਪ੍ਰੋਮੋ ਉਸ ਸਵੇਰੇ ਜਦ ਉਨ੍ਹਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਚੀਜ਼ ਖਰੀਦੀ ਸੀ, ਠੀਕ ਨਹੀਂ। ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਵਰਤੋ:

• ਕੀ ਇਹ ਉਸ ਚੀਜ਼ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਜੋ ਯੂਜ਼ਰ ਨੇ ਹੁਣ ਹੀ ਕੀਤਾ (ਜਾਂ ਜਿਸਦੀ ਉਹ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਰਵਾਹ ਕਰਦਾ ਹੈ)?
• ਕੀ ਉਹ ਪਹਿਲੀ ਲਾਈਨ ਤੋਂ ਬਿਨਾਂ ਖੋਲ੍ਹੇ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ?
• ਕੀ ਇਹ ਯੂਜ਼ਰ ਦੇ ਸਥਾਨਕ ਸਮੇਂ ਵਿੱਚ ਸਮਰਥ ਸਮੇਂ ਤੇ ਲੱਗੇਗਾ ਅਤੇ ਖਾਮੋਸ਼ ਘੰਟਿਆਂ ਤੋਂ ਬਚੇਗਾ?
• ਕੀ ਇਸ ਕਿਸਮ ਦੇ ਸੁਨੇਹੇ ਲਈ ਕੋਈ ਸੀਮਾ ਹੈ?
• ਜੇ ਉਹ ਇਸਨੂੰ ਨਾਪਸੰਦ ਕਰਦੇ ਹਨ, ਕੀ ਉਹ ਪਸੰਦਾਂ ਵਿੱਚ ਇਸ ਸ਼੍ਰੇਣੀ ਨੂੰ ਬੰਦ ਕਰ ਸਕਦੇ ਹਨ?

ਫਿਰ ਸੁਨੇਹੇ ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਵਿਅਕਤੀ ਵਾਂਗ ਪੜ੍ਹੋ ਜੋ ਤੁਹਾਨੂੰ ਨਹੀਂ ਜਾਣਦਾ। ਜੇ ਮੁੱਲ ਤੁਰੰਤ ਸਪਸ਼ਟ ਨਹੀਂ, ਤਾਂ ਪਹਿਲੀ ਲਰੀਨ ਦੁਬਾਰਾ ਲਿਖੋ। ਜੇ ਇਸਨੂੰ ਬਹੁਤ ਵੀContexts ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਪੁਸ਼ ਲਈ ਠੀਕ ਨਹੀਂ।

ਥਕਾਵਟ ਰੋਕਣ ਲਈ ਸਮਾਂ ਅਤੇ ਨਿਯੰਤਰਣ ਚੈੱਕ

ਦੋ ਗੱਲਾਂ ਧੀਰੇ-ਧੀਰੇ ਥਕਾਵਟ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਹਨ: ਗਲਤ ਸਮਾਂ ਅਤੇ ਨਿਕਾਸੀ ਦਾ ਰਸਤਾ ਨਾ ਹੋਣਾ। ਸਥਾਨਕ ਸਮਾਂ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਉਸ ਨਾਲੋਂ ਜਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। 9 a.m. ਤੁਹਾਡੇ ਲਈ 2 a.m. ਹੋ ਸਕਦਾ ਹੈ ਉਨ੍ਹਾਂ ਲਈ, ਅਤੇ ਇੱਕ ਜਗਾਉਣ ਇੱਕ ਚੈਨਲ ਨੂੰ ਖੋ ਦੇ ਸਕਦਾ ਹੈ।

ਫ੍ਰਿਕਵੈਂਸੀ ਕੈਪ ਦੂਜਾ ਗਾਰਡਰੇਲ ਹੈ। ਹਰ ਸ਼੍ਰੇਣੀ ਲਈ ਇੱਕ ਸੀਮਾ ਤੈਅ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰੋਮੋ ਲਈ ਹਫ਼ਤੇ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ 2), ਫਿਰ ਇਸ ਤੇ ਪੱਕਾ ਰਹੋ। ਜਦ ਤੁਸੀਂ ਆਪਣੀ ਨਿਯਮ ਤੋੜਦੇ ਹੋ, ਯੂਜ਼ਰ ਸੋਚਦਾ ਹੈ ਕਿ ਇਹ ਲਗਾਤਾਰ ਹੋਵੇਗਾ।

ਆਖਿਰ ਵਿੱਚ, ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਪ੍ਰੇਫਰੰਸ ਸੈਂਟਰ ਵਿੱਚ ਇਹ ਨਿੱਜੀ ਸ਼੍ਰੇਣੀ ਸ਼ਾਮਲ ਹੈ। ਇੱਕ ਛੋਟੀ ਸਹਿਯੋਗੀ ਟੈਸਟ: ਜੇ ਉਪਭੋਗਤਾ ਸ਼ਿਕਾਇਤ ਕਰਦਾ ਹੈ, ਕੀ ਸਪੋਰਟ ਉਨ੍ਹਾਂ ਨੂੰ 10 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਬਦਲਣਾ ਹੈ? ਜੇ ਨਹੀਂ, ਤੁਸੀਂ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜ ਰਹੇ ਹੋ ਜਿਸਦਾ ਤੁਸੀਂ ਪਿੱਛਾ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ।

ਉਦਾਹਰਨ: ਜੇ ਕਿਸੇ ਨੇ ਫਲਾਇਟ ਦੇਖੇ, ਤਾਂ ਇੱਕ ਕੀਮਤ-ਘਟਾ ਅਲਰਟ ਮਦਦਗਾਰ ਹੈ। ਇੱਕ ਦਿਨ ਵਿੱਚ ਤਿੰਨ ਅਲਰਟ, ਬਿਨਾਂ "price drops" ਨੂੰ ਮਿਊਟ ਕਰਨ ਦੇ ਤਰੀਕੇ, ਸਪੈਮ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਭਾਵੇਂ ਡੀਲ ਸੱਚ ਹੋਣ।

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਬਿਨਾਂ ਨਗਿੰਗ ਦੇ opt-in ਜਿੱਤਣਾ

ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਮੀਲ-ਪਲੈਨਿੰਗ ਐਪ। ਇਹ ਪੁਸ਼ opt-ins ਚਾਹੁੰਦੀ ਹੈ, ਪਰ ਇਹ ਜਾਣਦੀ ਹੈ ਕਿ ਪਹਿਲੀ ਗਲਤ ਛਾਪ ਤੇਜ਼ੀ ਨਾਲ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਕਰਵਾ ਸਕਦੀ ਹੈ।

ਪਹਿਲੇ ਸੈਸ਼ਨ 'ਤੇ, ਐਪ ਪਹਿਲਾਂ ਯੂਜ਼ਰ ਦੀ ਮਦਦ ਕਰਦੀ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਵਿਅੰਜਨ ਲੱਭਣ, ਫੇਵਰਿਟ ਸੇਵ ਕਰਨ, ਅਤੇ ਇੱਕ ਸਿਮਪਲ ਹਫਤਾਵਾਰ ਯੋਜਨਾ ਬਣਾਉਣ ਦਿੰਦੈ। ਕੋਈ ਪਰਮੀਸ਼ਨ ਪ੍ਰੰਪਟ ਨਹੀਂ। ਇਸ ਦੀ ਥਾਂ, ਇਹ ਇੱਕ ਛੋਟੀ ਟਿਪ ਦਿਖਾਉਂਦਾ ਹੈ: "You can get reminders later if you want." ਯੂਜ਼ਰ ਟਾਸਕ 'ਤੇ ਧਿਆਨ ਰੱਖਦੇ ਹਨ, ਨਾ ਕਿ ਸਿਸਟਮ ਡਾਇਲਾਗ ਵਿੱਚ।

ਜਦ ਐਪ ਨੇ ਪਹੁੰਚ ਜਿੱਤੀ ਤਾਂ ਬੇਨਤੀ ਕਰਨ ਦਾ ਸਮਾਂ ਉਹ ਹੈ ਜੋ ਸਾਫ਼ ਕਾਰਵਾਈ ਨਾਲ ਜੁੜਿਆ ਹੈ। ਜਦ ਯੂਜ਼ਰ 3 ਰੇਸੀਪੀ ਸੇਵ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਨਰਮ ਸਕ੍ਰੀਨ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ (ਓਐਸ ਪ੍ਰੰਪਟ ਨਹੀਂ): "Want a reminder when it's time to cook? Choose what you want." ਜੇ ਯੂਜ਼ਰ "Yes" ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ ਤਾਂ ਐਪ ਪਰਮੀਸ਼ਨ ਬੇਨਤੀ ਕਰਦੀ ਹੈ। ਜੇ ਉਹ "Not now" ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ, ਐਪ ਪਿੱਛੇ ਹਟ ਜਾਂਦੀ ਹੈ ਅਤੇ ਆਮ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ।

ਅਗਲਾ ਸਕ੍ਰੀਨ ਇੱਕ ਸਧਾਰਣ ਪ੍ਰੇਫਰੰਸ ਸੈਂਟਰ ਹੈ ਜਿਸ ਵਿੱਚ ਸਧਾਰਨ ਭਾਸ਼ਾ ਅਤੇ ਸੋਹਣੇ ਡਿਫਾਲਟ ਹਨ। ਇਹ ਕੁਝ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ: meal reminders (ਯੋਜਨਾ ਕੀਤੀ ਡਿਨਰਾਂ ਲਈ), new recipes (ਹਫਤਾਵਾਰ ਡਾਈਜੈਸਟ), ਅਤੇ deals ( ਸਿਰਫ ਜੇ ਯੂਜ਼ਰ ਚਾਹੁੰਦਾ ਹੈ)। ਹਰ ਵਿਕਲਪ ਫ੍ਰਿਕਵੈਂਸੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, "Meal reminders: up to 1 per day on days you planned a meal." "New recipes: once a week." Deals by default off.

ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਨਤੀਜੇ ਆਮ "ਲਾਂਚ 'ਤੇ ਪੁੱਛੋ" ਤਰੀਕੇ ਨਾਲ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਕੁੱਲ ਮਿਲਾ ਕੇ ਘੱਟ ਲੋਕ opt-in ਕਰਦੇ ਹਨ, ਪਰ ਜਿਹੜੇ ਕਰਦੇ ਹਨ ਉਹ ਖੁਸ਼ ਹੋਂਦੇ ਹਨ। ਭੇਜ ਵਧੀਆ ਘੱਟ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਐਪ ਸਿਰਫ ਉਹਨਾਂ ਨੂੰ ਪਿੰਗ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਉਸ ਤਰ੍ਹਾਂ ਦੀ ਮੰਗ ਕੀਤੀ ਸੀ, ਉਹਨਾਂ ਦੀ ਚੁਣੀ ਗਈ ਰੁਕਾਵਟਾਂ ਅਨੁਸਾਰ। ਇਸ ਨਾਲ ਘੱਟ disables ਅਤੇ ਘੱਟ "ਸਭ ਕੁਝ ਬੰਦ ਕਰੋ" ਵਾਲੇ ਮੋਮੈਂਟ ਹੁੰਦੇ ਹਨ।

ਇਹੀ ਤਰੀਕ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਹਾਸਲ ਕਰਦੇ ਹੋ ਜੋ ਲੋਕ ਬੰਦ ਨਹੀਂ ਕਰਦੇ: ਪਰਮੀਸ਼ਨ ਬੇਨਤੀ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਪਹਿਲਾਂ ਹੀ ਕੀਤੇ ਜਿੱਤ ਨਾਲ ਜੋੜੋ, ਅਤੇ ਯਕੀਨੀ ਕਰੋ ਕਿ ਹਰ ਸੁਨੇਹਾ ਉਹੀ ਮਹਿਸੂਸ ਕਰਵਾਏ ਜੋ ਉਨ੍ਹਾਂ ਨੇ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਮੰਗਿਆ ਸੀ।

ਮਾਪੋ, ਸੁਧਾਰ ਕਰੋ, ਅਤੇ ਅੱਗੇ ਦੇ ਫੈਸਲੇ ਕਰੋ

ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਦੀ ਤਰ੍ਹਾਂ ਸਮਝੋ: ਜੋ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ, ਇੱਕ ਗੱਲ ਬਦਲੋ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋ।

ਸ਼ੁਰੂ ਕਰੋ ਉਹਨਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਟਰੈਕ ਕਰਕੇ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਭਰੋਸਾ ਕਮਾ ਰਹੇ ਹੋ ਜਾਂ ਖੋ ਰਹੇ ਹੋ। ਖ਼ਾਲੀ ਖੁਲਣ (opens) 'ਤੇ ਹੀ ਨਾ ਰੁਕੋ। ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਕਿ ਲਾਗਤ ਪੱਖ ਵੀ ਨੱਪੀ ਜਾਵੇ:

• ਆਪਟ-ਇਨ ਰੇਟ (ਸਕ੍ਰੀਨ, ਮੋਮੈਂਟ, ਅਤੇ ਯੂਜ਼ਰ ਸੈਗਮੈਂਟ ਵਾਰ)
• disable ਰੇਟ (ਖ਼ਾਸ ਸੁਨੇਹਿਆਂ ਤੋਂ ਬਾਅਦ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ)
• open ਰੇਟ (ਅਤੇ downstream ਕਾਰਵਾਈਆਂ, ਸਿਰਫ ਟੈਪਾਂ ਨਹੀਂ)
• churn ਸਿਗਨਲ (ਅਨਇੰਸਟਾਲ, ਘੱਟ ਸੈਸ਼ਨ, ਈਮੇਲ ਅਨਸਬਸਕ੍ਰਾਈਬ)
• ਪ੍ਰੈਫਰੰਸ ਸੋਧ (ਕਿਹੜੇ ਸ਼੍ਰੇਣੀਆਂ ਬੰਦ ਕੀਤੀਆਂ ਜਾਂ "ਸਭ ਕੁਝ" ਬੰਦ ਕੀਤਾ)

ਅਗਲਾ ਕਦਮ ਟੌਪ ਓਫੈਂਡਰ ਵੇਖੋ। ਪੈਟਰਨ ਲੱਭੋ: ਕੋਈ ਖਾਸ ਸ਼੍ਰੇਣੀ, ਇੱਕ ਸਮਾਂ ਦੀ ਖਿੜਕੀ, ਜਾਂ ਕੋਈ ਦੁਹਰਾਇਆ ਟੈਮਪਲੇਟ ਜੋ disables ਦੇ ਨਾਲ ਪਹਿਲਾ ਹੁੰਦਾ ਹੈ। ਹਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਇਕ ਸਧਾਰਨ ਕਾਰਨ ਟੈਗ ਕਰੋ (order update, reminder, promo) ਤਾਂ ਕਿ ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਸਕੋ: "ਕਿਹੜੇ ਸੁਨੇਹਿਆਂ ਨੇ ਹਰ 1,000 ਭੇਜਾਂ ਤੇ ਸਭ ਤੋਂ ਵੱਧ opt-outs ਕੀਤੇ?" ਉਹਨਾਂ ਦੀ ਪਹਿਲਾਂ ਮੁਰੰਮਤ ਕਰੋ।

ਛੋਟੇ ਟੈਸਟ ਦੌਰਿਆਂ ਚਲਾਓ ਬੜੇ ਰੀਲਾਂਚਾਂ ਦੀ ਥਾਂ। ਹਰ ਵਾਰ ਇੱਕ ਹੀ ਚੀਜ਼ ਬਦਲੋ: ਬਾਦ ਵਿੱਚ ਪੁੱਛੋ (ਕਿਸੇ ਸਪਸ਼ਟ ਸਫਲਤਾ ਮੋਹਰ ਤੋਂ ਬਾਅਦ), ਕਾਪੀ ਨੂੰ ਲਾਭ ਸਪਸ਼ਟ ਕਰਨ ਲਈ ਦੁਬਾਰਾ ਲਿਖੋ, ਹਰ ਸ਼੍ਰੇਣੀ ਲਈ ਫ੍ਰਿਕਵੈਂਸੀ ਕੈਪ ਲਗਾਓ, ਜ਼ਰੂਰੀ ਜਾਣਕਾਰੀਆਂ ਨੂੰ ਨਾਈਸ-ਟੂ-ਨੋਟ ਤੋਂ ਵੱਖ ਕਰੋ, ਅਤੇ ਸ਼ੁਰੂ ਵਿੱਚ ਘੱਟ ਸ਼੍ਰੇਣੀਆਂ ਚਾਲੂ ਰੱਖੋ।

ਪਸੰਦਾਂ ਨੂੰ ਵਿਜ਼ੀਬਲ ਅਤੇ ਸੋਧਣਯੋਗ ਰੱਖੋ। ਜੇ ਯੂਜ਼ਰ ਇਕ ਕਿਸੇ ਕਿਸਮ ਦਾ ਸੁਨੇਹਾ ਤੇਜ਼ੀ ਨਾਲ ਮਿਊਟ ਕਰ ਸਕਦਾ ਹੈ, ਉਹ ਸਭ ਕੁਝ ਬੰਦ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਸ਼੍ਰੇਣੀ ਮਿਊਟ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਹੈ। ਇਕ ਲਾਗੂ ਨਿਯਮ: ਕੋਈ ਵੀ ਨੋਟੀਫਿਕੇਸ਼ਨ 2 ਟੈਪ ਜਾਂ ਘੱਟ ਵਿੱਚ ਪ੍ਰੇਫਰੰਸ ਸੈਂਟਰ ਤੋਂ ਸੋਧਣਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਆਗੇ ਵੱਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ permission flow ਅਤੇ preference center ਨੂੰ Koder.ai (koder.ai) 'ਤੇ ਬਣਾਉਣਾ ਅਤੇ ਇਟਰੇਟ ਕਰਨਾ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਤਬਦੀਲੀਆਂ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਜਦ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ।