ਇਸ SaaS ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਨੂੰ ਵਰਤੋਂ ਤਾਂ ਜੋ ਇਵੈਂਟ ਅਤੇ ਪ੍ਰਾਪਰਟੀਆਂ ਨੂੰ ਇੱਕਸਾਰ ਨਾਮ ਦਿੱਤੇ ਜਾਣ ਅਤੇ activation ਅਤੇ retention ਲਈ 10 ਸ਼ੁਰੂਆਤੀ ਡੈਸ਼ਬੋਰਡ ਸੈਟਅਪ ਕੀਤੇ ਜਾਣ।

ਪਹਿਲੇ SaaS ਐਪ ਦੀ ਸ਼ੁਰੂਆਤੀ ਅਨਾਲਿਟਿਕਸ ਅਕਸਰ ਉਲਝਣ ਵਾਲੀ ਲੱਗਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਕੋ ਸਮੇਂ ਦੋ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਜੂਝ ਰਹੇ ਹੁੰਦੇ ਹੋ: ਬਹੁਤ ਘੱਟ ਯੂਜ਼ਰ ਅਤੇ ਘੱਟ ਸੰਦਰਭ। ਕੁਝ ਪਾਵਰ ਯੂਜ਼ਰਾਂ ਤੁਹਾਡੇ ਚਾਰਟਾਂ ਨੂੰ ਤਰਦੀਬ ਦੇ ਸਕਦੇ ਹਨ, ਜਦਕਿ ਕੁਝ “ਟੂਰਿਸਟ” (ਜੋ ਸਾਈਨਅਪ ਕਰਦੇ ਹਨ ਅਤੇ ਛੱਡ ਦੇਂਦੇ ਹਨ) ਸਭ ਕੁਝ ਖਰਾਬ ਦਿਖਾ ਸਕਦੇ ਹਨ.
ਸਭ ਤੋਂ ਔਖਾ ਹਿੱਸਾ ਹੈ ਵਰਤੋਂ ਦੇ ਸ਼ੋਰ (noise) ਨੂੰ ਅਸਲੀ ਸੰਕੇਤ (signal) ਤੋਂ ਵੱਖ ਕਰਨਾ। ਸ਼ੋਰ ਉਹ ਕਾਰਵਾਈਆਂ ਹਨ ਜੋ ਵਿਅਸਤੀ ਦਿਖਦੀਆਂ ਹਨ ਪਰ ਅਗੇਵਧ ਨਹੀਂ ਦਿਖਾਉਂਦੀਆਂ — ਜਿਵੇਂ ਸੈਟਿੰਗਜ਼ ਵਿੱਚ ਕਲਿੱਕ ਕਰਨਾ, ਪੇਜ ਰੀਫ੍ਰੈਸ਼ ਕਰਨਾ, ਜਾਂ ਕਈ ਟੇਸਟ ਇੱਕਾਊਂਟ ਬਣਾਉਣਾ। ਸੰਕੇਤ ਉਹ ਕਾਰਵਾਈਆਂ ਹਨ ਜੋ ਮੁੱਲ ਦੀ ਭਵਿੱਖਵਾਣੀ ਕਰਦੀਆਂ ਹਨ — ਜਿਵੇਂ ਔਨਬੋਰਡਿੰਗ ਮੁਕੰਮਲ ਕਰਨਾ, ਟੀਮਮੇਟ ਨੂੰ ਨਿਯੋਤਾ ਭੇਜਣਾ, ਜਾਂ ਪਹਿਲਾ ਸਫਲ ਵਰਕਫਲੋ ਮੁਕੰਮਲ ਕਰਨਾ।
ਇਕ ਚੰਗੀ SaaS ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਤੁਹਾਡੇ ਨੂੰ ਪਹਿਲੇ 30 ਦਿਨਾਂ ਵਿੱਚ ਕੁਝ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ, ਬਿਨਾ ਕਿਸੇ ਡਾਟਾ ਟੀਮ ਦੀ ਲੋੜ ਦੇ।
ਜੇ ਤੁਹਾਡੀ ਟਰੈਕਿੰਗ ਇਹ ਸਵਾਲ ਹਲ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਠੀਕ ਜਗ੍ਹਾ ਤੇ ਹੋ:
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: activation ਉਹ ਪਲ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਸੱਚੀ ਫਾਇਦਾ ਮਿਲਦੀ ਹੈ। retention ਇਹ ਹੈ ਕਿ ਉਹ ਫਿਰ ਉਸ ਫਾਇਦੇ ਲਈ ਵਾਪਸ ਆਉਂਦੇ ਹਨ ਕਿ ਨਹੀਂ। ਦਿਨ ਇੱਕ ਤੇ ਤੁਹਾਨੂੰ ਪਰਫੈਕਟ ਪਰਿਭਾਸ਼ਾ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ ਅਨੁਮਾਨ ਅਤੇ ਮੈਜਰ ਕਰਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, Koder.ai ਵਰਗੀ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਨਵੇਂ ਫਲੋ ਦਿਨਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ), ਤਾੰ ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਸਾਰਾ ਕੁਝ ਇੰਸਟਰੂਮੈਂਟ ਕਰ ਦਿਓ। ਵੱਧ ਇਵੈਂਟ ਦੇ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਵੱਧ ਗੁੰਝਲ। ਛੋਟੇ ਕਾਰਵਾਈ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ "ਪਹਿਲੀ ਜਿੱਤ" ਅਤੇ "ਦੋਹਰਾਈ ਜਿੱਤ" ਨਾਲ ਨਕਸ਼ਾ ਮਿਲਦੇ ਹੋਣ, ਫਿਰ ਜਦੋਂ ਕੋਈ ਫੈਸਲਾ ਲੋੜ ਹੋਵੇ ਤਾਂ ਹੀ ਵਧਾਓ।
ਐਕਟੀਵੇਸ਼ਨ ਉਹ ਪਲ ਹੈ ਜਦੋਂ ਨਵਾਂ ਯੂਜ਼ਰ ਪਹਿਲੀ ਵਾਰ ਅਸਲ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਰਿਟੇਨਸ਼ਨ ਇਸ ਗੱਲ ਦੀ ਪਰਖ ਹੈ ਕਿ ਉਹ ਸਮੇਂ ਦੇ ਨਾਲ ਮੁੱਲ ਲੈਣਾ ਜਾਰੀ ਰੱਖਦੇ ਹਨ ਕਿ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਦੋਨਾਂ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਨਹੀਂ ਬਿਆਨ ਕਰ ਸਕਦੇ ਤਾਂ ਤੁਹਾਡੀ ਟਰੈਕਿੰਗ ਇਵੈਂਟਾਂ ਦਾ ਢੇਰ ਬਣ ਕੇ ਰਹਿ ਜਾਏਗੀ ਜੋ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।
ਸ਼ੁਰੂ ਕਰੋ ਦੋ “ਲੋਕ” ਨੂੰ ਉਤਾਰ ਕੇ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਹਨ:
ਬਹੁਤ ਸਾਰੇ SaaS ਐਪ ਟੀਮਾਂ ਦੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ account ਵਿੱਚ ਕਈ ਯੂਜ਼ਰ ਹੋ ਸਕਦੇ ਹਨ। ਇਸੀ ਲਈ ਤੁਹਾਡੀ ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾਏ ਕਿ ਤੁਸੀਂ ਯੂਜ਼ਰ ਬਿਹੇਵਿਯਰ, ਇੱਕਾਊਂਟ ਹੇਲਥ, ਜਾਂ ਦੋਹਾਂ ਨੂੰ ਮਾਪ ਰਹੇ ਹੋ।
ਐਕਟੀਵੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਨਤੀਜਾ ਹੋਵੇ। ਚੰਗੇ ਐਕਟੀਵੇਸ਼ਨ ਪਲ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੇ ਹਨ: “ਮੈਂ X ਕੀਤਾ ਅਤੇ Y ਮਿਲਿਆ।”
ਉਦਾਹਰਨ: “ਇੱਕ ਯੂਜ਼ਰ ਆਪਣਾ ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।” (ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਟੂਲ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ “ਪਹਿਲੀ ਸਫਲ ਡਿਪਲੋਯ” ਜਾਂ “ਪਹਿਲਾ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ” ਹੋ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਵਾਅਦੇ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ।)
ਉਸ ਵਾਕ ਨੂੰ ਮਾਪਯੋਗ ਬਣਾਉਣ ਲਈ, ਉਹ ਕੁਝ ਕਦਮ ਲਿਖੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੀ ਵੈਲਯੂ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੇ ਹਨ। ਛੋਟਾ ਰੱਖੋ ਅਤੇ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਉਸ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਰਿਟੇਨਸ਼ਨ ਇਹ ਹੈ ਕਿ ਉਹ ਕਿਸ ਸ਼ਡਿਊਲ ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ।
ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਰੋਜ਼ਾਨਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਰੋਜ਼ਾਨਾ ਰਿਟੇਨਸ਼ਨ ਵੇਖੋ। ਜੇ ਇਹ ਹਫ਼ਤੇ ਵਿੱਚ ਕੁਝ ਵਾਰੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਹਫ਼ਤਾਵਾਰ ਰਿਟੇਨਸ਼ਨ ਵਰਤੋਂ। ਜੇ ਇਹ ਮਹੀਨਾਵਾਰ ਵਰਕਫਲੋ (ਜਿਵੇਂ ਬਿਲਿੰਗ, ਰਿਪੋਰਟਿੰਗ) ਹੈ ਤਾਂ ਮਹੀਨਾਵਾਰ ਰਿਟੇਨਸ਼ਨ ਵਰਤੋਂ। ਸਭ ਤੋਂ ਚੰਗੀ ਚੋਣ ਉਹ ਹੈ ਜਿੱਥੇ "ਵਾਪਸ ਆਉਣਾ" ਅਸਲ ਮੁੱਲ ਦਾ ਸੰਕੇਤ ਹੋਵੇ, ਨਾ ਕਿ ਦੋਸ਼-ਅਧਾਰਿਤ ਲੌਗਇਨ।
ਇਕ SaaS ਲਈ ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਸਭ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਇੱਕ ਸਧਾਰਨ ਕਹਾਣੀ ਪਿੱਛੇ ਚਲਦੀ ਹੈ: ਨਵਾਂ ਵਿਅਕਤੀ ਸਾਈਨਅਪ ਤੋਂ ਆਪਣੇ ਪਹਿਲੇ ਅਸਲ ਫਾਇਦੇ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ।
ਸਭ ਤੋਂ ਛੋਟਾ ਔਨਬੋਰਡਿੰਗ ਰਸਤਾ ਲਿਖੋ ਜੋ ਮੁੱਲ ਬਣਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ: Signup -> verify email -> create workspace -> invite teammate (optional) -> connect data (or set up project) -> complete first key action -> see result.
ਹੁਣ ਉਹ ਮੋੜ ਨਿਸ਼ਾਨ ਲਗਾਓ ਜਿਥੇ ਕੋਈ ਡ੍ਰੌਪ ਆ ਸਕਦਾ ਹੈ ਜਾਂ ਫਸ ਸਕਦਾ ਹੈ। ਉਹ ਮੋੜ ਪਹਿਲੇ ਇਵੈਂਟ ਹੋ ਜਾਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰੋगे।
ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ 8-15 ਇਵੈਂਟ ਚਾਹੀਦੇ ਹੁੰਦੇ ਹਨ, 80 ਨਹੀਂ। ਉਸ ਤਰ੍ਹਾਂ ਦੇ ਇਵੈਂਟਾਂ ਨੂੰ ਟਾਰਗੇਟ ਕਰੋ ਜੋ ਉੱਤਰ ਦਿੰਦੇ ਹਨ: ਕੀ ਉਹ ਸ਼ੁਰੂ ਹੋਏ? ਕੀ ਉਹ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਪਹੁੰਚੇ? ਕੀ ਉਹ ਵਾਪਸ ਆਏ?
ਇਕ ਵਰਤੋਂਯੋਗ ਨਿਰਮਾਣ ਕ੍ਰਮ:
ਇਵੈਂਟ ਸਪੀਸ ਲਈ, ਇੱਕ ਸਧਾਰਨ ਟੇਬਲ ਕਾਗਜ਼ 'ਤੇ ਕਾਫੀ ਹੈ। ਸ਼ਾਮਲ ਕਰੋ: event name, trigger (ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ), who can trigger it, ਅਤੇ ਉਹ properties ਜੋ ਹਮੇਸ਼ਾ ਭੇਜੀਆਂ ਜਾਣ।
ਦੋ IDs ਜ਼ਿਆਦਾਤਰ ਸ਼ੁਰੂਆਤੀ ਗੁੰਝਲ ਨੂੰ ਰੋਕਦੇ ਹਨ: ਇੱਕ unique user ID (ਵਿਅਕਤੀ) ਅਤੇ ਇੱਕ account ਜਾਂ workspace ID (ਉਹ ਜਗ੍ਹਾ ਜਿੱਥੇ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ)। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਨਿੱਜੀ ਵਰਤੋਂ ਨੂੰ ਟੀਮ ਅਪਣਾਉਣ ਅਤੇ ਅਪਗਰੇਡ ਤੋਂ ਵੱਖ ਕਰ ਸਕਦੇ ਹੋ।
ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ “fresh user” ਟੈਸਟ ਕਰੋ: ਨਵੀਂ ਅਕਾਉਂਟ ਬਣਾਓ, ਔਨਬੋਰਡਿੰਗ ਪੂਰੀ ਕਰੋ, ਫਿਰ ਚੈੱਕ ਕਰੋ ਕਿ ਹਰ ਇਵੈਂਟ ਇੱਕ ਵਾਰੀ ਫਾਇਰ ਹੋਵੇ (ਨਾ ਕਿ ਜ਼ੀਰੋ, ਨਾ ਕਿ ਪੰਜ ਵਾਰੀ), ਸਹੀ IDs ਅਤੇ timestamps ਨਾਲ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਟੈਸਟ ਆਪਣੇ ਪ੍ਰੀ-ਰੀਲੀਜ਼ ਚੈੱਕ ਵਿੱਚ ਸ਼ਾਮِل ਕਰੋ ਤਾਂ ਜੋ ਐਪ ਬਦਲਦਿਆਂ ਟ੍ਰੈਕਿੰਗ ਸਹੀ ਰਹੇ।
ਨਾਮकरण ਨਿਯਮ “ਸਹੀ” ਹੋਣ بارے ਨਹੀਂ, ਸੰਤੁਲਿਤ ਹੋਣ ਲਈ ਹੈ ਤਾਂ ਜੋ ਉਤਪਾਦ ਬਦਲਣ 'ਤੇ ਵੀ ਤੁਹਾਡੇ ਚਾਰਟ ਟੁੱਟਣ ਨਾ।
ਅਕਸਰ ਚੰਗਾ ਨਿਯਮ ਹੈ verb_noun ਫਾਰਮੈਟ ਵਿੱਚ snake_case। ਕਿਰਿਆ (verb) ਸਪੱਸ਼ਟ ਰੱਖੋ ਅਤੇ ਨਾਂ (noun) ਵਿਸ਼ੇਸ਼।
ਨਮੂਨੇ ਜੋ ਤੁਸੀਂ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ:
created_project, invited_teammate, uploaded_file, scheduled_demosubmitted_form (ਭੂਤ ਕਾਲ ਲਿਖਣ ਨਾਲ ਕੰਮ ਮੁਕੰਮਲ ਹੋਣ ਵਾਲੀ ਕਾਰਵਾਈ ਦਰਸਦੀ ਹੈ)connected_integration, enabled_feature, exported_reportਜੋ ਹਾਲਤ “ਇਹ ਹੋਇਆ” ਦਿਖਾਉਂਦੀ ਹੈ, ਉਨ੍ਹਾਂ ਲਈ ਭੂਤ ਕਾਲ ਪਸੰਦ ਕਰੋ। ਇਹ ਗਲਬਾ ਦੂਰ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, started_checkout ਵਰਗੀ ਵੱਲ-ਵਾਲੀ ਨਾਂ ਉਪਯੋਗੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ revenue ਅਤੇ retention ਲਈ completed_checkout ਹੀ ਚਾਹੀਦਾ ਹੈ।
UI-ਖਾਸ ਨਾਂਵਾਂ ਜਿਵੇਂ clicked_blue_button ਜਾਂ pressed_save_icon ਤੋਂ ਬਚੋ। ਬਟਨ ਅਤੇ layout ਬਦਲਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ ਟ੍ਰੈਕਿੰਗ ਪੁਰਾਣੇ ਸਕਰੀਨਾਂ ਦੀ ਇਤਿਹਾਸ ਬਣ ਕੇ ਰਹਿ ਜਾਂਦੀ ਹੈ। ਨਿਮਤਾਂ ਦੇ ਇरਾਦ ਨੂੰ ਨਾਂ ਦਿਓ: saved_settings ਜਾਂ updated_profile ਵਰਗੇ।
ਨਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖੋ ਭਾਵੇਂ UI ਬਦਲੇ। ਜੇ ਤੁਸੀਂ created_workspace ਨੂੰ ਬਾਅਦ ਵਿੱਚ created_team ਬਣਾਓਗੇ, ਤਾਂ ਤੁਹਾਡਾ “activation” ਚਾਰਟ ਵੱਖ-ਵੱਖ ਲਾਈਨਾਂ 'ਚ ਵੰਡ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ continuity ਖੋ ਸਕਦੇ ਹੋ। ਜੇ ਨਾਂ ਬਦਲਣੀ ਲਾਜ਼ਮੀ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਾਂਗ ਸੰਭਾਲੋ: ਪੁਰਾਣੇ ਤੋਂ ਨਵੇਂ ਦਾ ਮੇਪ ਬਣਾਓ ਅਤੇ ਫੈਸਲੇ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਰੱਖੋ।
ਛੋਟਾ ਪ੍ਰੀਫਿਕਸ ਸੈੱਟ ਇਵੈਂਟ ਲਿਸਟ ਨੂੰ ਸਾਫ਼ ਅਤੇ ਸਕੈਨ ਕਰਨ ਯੋਗ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਕੁਝ ਚੁਣੋ ਅਤੇ ਨਿਰੰਤਰਤਾ ਨਾਲ ਰੱਖੋ।
ਉਦਾਹਰਨ ਲਈ:
auth_ (signup, login, logout)onboarding_ (ਉਹ ਕਦਮ ਜੋ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਲੈ ਜਾਂਦੇ ਹਨ)billing_ (trial, checkout, invoices)admin_ (roles, permissions, org settings)ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ chat-driven builder ਵਿੱਚ SaaS ਬਣਾ ਰਹੇ ਹੋ, ਇਹ ਸੰਪਰਦਾਇ ਬਰਕਰਾਰ ਰਹਿੰਦੀ ਹੈ। ਅੱਜ ਬਣੀ ਫੀਚਰ ਕੱਲ੍ਹ redesign ਹੋ ਸਕਦੀ ਹੈ, ਪਰ created_project ਹਰ UI iteration 'ਚ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ।
ਅੱਚੇ ਇਵੈਂਟ ਨਾਂ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਹੋਇਆ। ਪ੍ਰਾਪਰਟੀਆਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕਿਸਨੇ ਕੀਤਾ, ਕਿੱਥੇ ਹੋਇਆ, ਅਤੇ ਨਤੀਜਾ ਕੀ ਸੀ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ, ਪੇਸ਼ਗੋਈਯੋਗ ਸੈੱਟ ਰੱਖਦੇ ਹੋ ਤਾਂ ਤੁਹਾਡੀ ਟਰੈਕਿੰਗ ਪੜ੍ਹਨ ਯੋਗ ਰਹੇਗੀ ਜਦੋਂ ਤੁਸੀਂ ਹੋਰ ਫੀਚਰ ਜੋੜੋਗੇ।
ਉਹ ਕੁਝ ਪ੍ਰਾਪਰਟੀਆਂ ਚੁਣੋ ਜੋ ਲਗਭਗ ਹਰ ਇਵੈਂਟ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ। ਇਹ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ customers ਦੇ ਕਿਸਮ ਅਨੁਸਾਰ charts ਨੂੰ ਸਲਾਈਸ ਕਰਨ ਦਿੰਦੇ ਹਨ ਬਿਨਾ ਡੈਸ਼ਬੋਰਡ ਮੁੜ ਬਣਾਉਣ ਦੇ।
ਕਾਰਗਰ ਕੋਰ ਸੈੱਟ:
ਫਿਰ_CONTEXT ਜਦੋਂ ਇਹ ਮਾਮਲੇ ਦਾ ਅਰਥ ਬਦਲ ਦੇਵੇ ਤਾਂ ਹੀ ਜੋੜੋ। ਉਦਾਹਰਨ ਲਈ, “Project Created” ਅਗਰ project_type ਜਾਂ template_id ਨਾਲ ਹੋਵੇ ਤਾਂ ਇਹ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹੈ, ਅਤੇ “Invite Sent” seats_count ਨਾਲ ਕਾਰਗਰ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਵੀ ਕਾਰਵਾਈ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ, ਇੱਕ ਸਪਸ਼ਟ ਨਤੀਜਾ ਸ਼ਾਮਲ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ success: true/false ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਫੇਲ ਹੋਵੇ ਤਾਂ ਇੱਕ ਛੋਟਾ error_code (ਜਿਵੇਂ "billing_declined" ਜਾਂ "invalid_domain") ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰ ਸਕੋ ਬਿਨਾ ਰਾਊ ਲੋਗ ਪੜ੍ਹਨ ਦੇ।
ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: Koder.ai 'ਚ, “Deploy Started” ਬਿਨਾਂ outcome ਡੇਟਾ ਦੇ ਅਸਪਸ਼ਟ ਹੈ। success ਅਤੇ error_code ਜੋੜੋ, ਅਤੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਨਵੇਂ ਯੂਜ਼ਰ ਮਿਸਿੰਗ domain setup, ਕਰੈਡਿਟ ਸੀਮਾਵਾਂ, ਜਾਂ ਰੀਜਨ ਸੈਟਿੰਗ ਕਾਰਨ ਫੇਲ ਹੋ ਰਹੇ ਹਨ।
ਨਾਂ, type, ਅਤੇ ਮਾਇਨਾ ਇੱਕ ਵਾਰੀ ਨਿਰਧਾਰਤ ਕਰੋ, ਫਿਰ ਉਸ ਦੇ ਨਾਲ ਰਹੋ। ਜੇ plan_tier ਇੱਕ ਇਵੈਂਟ 'ਤੇ string ਹੈ, ਤਾਂ ਕਿਸੇ ਹੋਰ ਇਵੈਂਟ 'ਤੇ ਉਸਨੂੰ number ਵਜੋਂ ਨਾ ਭੇਜੋ। synonyms (account_id vs workspace_id) ਤੋਂ ਬਚੋ, ਅਤੇ ਕਿਸੇ property ਦਾ ਅਰਥ ਕਦੇ ਬਦਲੋ ਨਾ।
ਜੇ ਤੁਹਾਨੂੰ ਵਧੀਆ ਵਰਜਨ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਨਵਾਂ property ਨਾਮ ਬਣਾਓ ਅਤੇ ਪੁਰਾਣੇ ਨੂੰ ਰੱਖੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਡੈਸ਼ਬੋਰਡ ਮਾਈਗ੍ਰੇਟ ਨਾ ਕਰ ਲਓ।
ਸਾਫ਼ ਟ੍ਰੈਕਿੰਗ ਡਾਟਾ ਮੁੱਖ ਤੌਰ 'ਤੇ ਦੋ ਆਦਤਾਂ ਬਾਰੇ ਹੈ: ਜੋ ਚਾਹੀਦਾ ਹੈ ਸਿਰਫ਼ ਉਹੀ ਭੇਜੋ, ਅਤੇ ਗਲਤੀਆਂ ਠੀਕ ਕਰਨਾ ਆਸਾਨ ਰੱਖੋ।
ਸ਼ੁਰੂ ਵਿੱਚ ਅਨਾਲਿਟਿਕਸ ਨੂੰ ਕਾਰਵਾਈਆਂ ਦੀ ਲੌਗ ਸਮਝੋ, ਨਾਂ ਕਿ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਰੱਖਣ ਦੀ ਜਗ੍ਹਾ। ਰਾ_email, ਪੂਰੇ ਨਾਂ, ਫੋਨ ਨੰਬਰ, ਜਾਂ ਕੋਈ ਵੀ ਮੁਫ਼ਤ-ਟੈਕਸਟ ਫੀਲਡ (support notes, feedback boxes, chat messages) ਨਾ ਭੇਜੋ। ਮੁਫ਼ਤ ਟੈਕਸਟ ਅਕਸਰ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਰੱਖਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਸੋਚ ਨਹੀਂ ਕੀਤੀ।
ਆਪਣੇ ਇੰਟਰਨਲ IDs ਵਰਤੋ। user_id, account_id, ਅਤੇ workspace_id ਟਰੈਕ ਕਰੋ, ਅਤੇ ਨਿੱਜੀ ਡੇਟਾ ਦਾ ਮੈਪ ਆਪਣੀ ਡੇਟਾਬੇਸ ਜਾਂ CRM ਵਿੱਚ ਰੱਖੋ। ਜੇ ਕਿਸੇ ਟੀਮਮੈਂਬਰ ਨੂੰ ਕਿਸੇ ਇਵੈਂਟ ਨਾਲ ਵਿਅਕਤੀ ਜੋੜਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਵੇ, ਤਾਂ ਇਹ ਅੰਦਰੂਨੀ ਟੂਲਾਂ ਰਾਹੀਂ ਕਰੋ, ਨਾਂ ਕਿ PII ਨੂੰ analytics ਵਿੱਚ ਕਾਪੀ ਕਰਕੇ।
IP addresses ਅਤੇ location ਡਾਟਾ ਬਾਰੇ ਪਹਿਲਾਂ ਇੱਕ ਫੈਸਲਾ ਕਰੋ। ਬਹੁਤ ਸਾਰੇ ਟੂਲ IP ਡਿਫਾਲਟ ਨਾਲ ਕੈਪਚਰ ਕਰਦੇ ਹਨ, ਅਤੇ “city/country” ਨਰਮ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਫਿਰ ਵੀ ਨਿੱਜੀ ਡੇਟਾ ਹੋ ਸਕਦੀ ਹੈ। ਇਕ ਰਵੱਈਆ ਚੁਣੋ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ: ਕੁਝ ਵੀ ਸਰਵ ਕਰਨਾ ਨਹੀਂ, ਸਿਰਫ਼ ਮੁੱਢਲਾ location (country/region) ਸੈਵ ਕਰਨਾ, ਜਾਂ ਸੁਰੱਖਿਆ ਲਈ IP ਅਸਥਾਈ ਰੂਪ ਵਿੱਚ ਰੱਖਣਾ ਅਤੇ ਫਿਰ ਹਟਾ ਦੇਣਾ।
ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ ਹাইজੀਨ ਚੈੱਕਲਿਸਟ ਹੈ ਜੋ ਤੁਹਾਡੇ ਪਹਿਲੇ ਡੈਸ਼ਬੋਰਡ ਨਾਲ ਭੇਜਣ ਲਈ ਉਪਯੋਗੀ ਰਹੇਗੀ:
user_id ਅਤੇ account_id ਨਾਲ)ਜੇ ਤੁਸੀਂ ਆਪਣੀ SaaS Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹੀ ਨਿਯਮ ਸਿਸਟਮ ਲੌਗਸ ਅਤੇ snapshots 'ਤੇ ਲਾਗੂ ਕਰੋ: identifiers ਨੂੰ ਨਿਰੰਤਰ ਰੱਖੋ, PII ਨੂੰ event payloads ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਅਤੇ ਦਰਸਾਓ ਕਿ ਕੌਣ কি ਵੇਖ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਉਂ।
ਇਕ ਚੰਗੀ SaaS ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਕੱਚੇ ਕਲਿੱਕਾਂ ਨੂੰ ਉਹਨਾਂ ਉੱਤਰਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਤੇ ਤੁਸੀਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਡੈਸ਼ਬੋਰਡ ਦੋ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਨ: ਲੋਕ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦੇ ਹਨ, ਅਤੇ ਕੀ ਉਹ ਵਾਪਸ ਆਉਂਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ B2B SaaS ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿਸ ਵਿੱਚ 14-ਦਿਨ ਦੀ free trial ਹੈ। ਇੱਕ ਵਿਅਕਤੀ ਸਾਈਨਅਪ ਕਰਦਾ ਹੈ, ਆਪਣੀ ਟੀਮ ਲਈ workspace ਬਣਾਉਂਦਾ ਹੈ, ਪ੍ਰੋਡੱਕਟ ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਅਤੇ (ਆਦਰਸ਼ ਰੂਪ ਵਿੱਚ) ਇੱਕ teammate ਨੂੰ invite ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਲਕੜੀ ਦਾ ਲਕੜੀ ਇਹ ਜ਼ਲਦੀ ਸਿੱਖਨਾ ਹੈ ਕਿ ਲੋਕ ਕਿੱਥੇ ਫਸਦੇ ਹਨ।
“ਪਹਿਲੀ ਵੈਲਯੂ” ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਯੂਜ਼ਰ ਇੱਕ workspace ਬਣਾਉਂਦਾ ਅਤੇ ਇੱਕ core task ਪੂਰਾ ਕਰਦਾ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਤਪਾਦ ਉਨ੍ਹਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, “CSV ਇੰਪੋਰਟ ਕਰਕੇ ਪਹਿਲਾ ਰਿਪੋਰਟ ਜਨਰੇਟ ਕਰੋ”). ਤੁਹਾਡੀ ਸ਼ੁਰੂਆਤੀ ਟ੍ਰੈਕਿੰਗ ਦਾ ਸਾਰ ਇਸ ਪਲ ਵੱਲ ਵਾਪਸ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਥੇ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਇਵੈਂਟ ਸੈੱਟ ਹੈ ਜੋ ਤੁਸੀਂ ਦਿਨ ਪਹਿਲੇ ਹੀ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ (ਨਾਂ ਸਧਾਰਨ verbs ਵਿੱਚ ਭੂਤ ਕਾਲ ਨਾਲ, ਸਪਸ਼ਟ objects):
created_workspacecompleted_core_taskinvited_teammateਹਰ ਇਵੈਂਟ ਲਈ, ਥੋੜ੍ਹੀਆਂ ਹੀ ਪ੍ਰਾਪਰਟੀਜ਼ ਜੋ ਇਹ ਦੱਸਣ ਲਈ ਕਾਫ਼ੀ ਹਨ ਕਿ ਕਿਉਂ ਇਹ ਹੋਇਆ (ਜਾਂ ਨਹੀਂ ਹੋਇਆ)। ਚੰਗੀਆਂ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਾਪਰਟੀਆਂ ਹਨ:
ਹੁਣ ਆਪਣੇ ਡੈਸ਼ਬੋਰਡ ਦੀ ਸੋਚੋ। ਤੁਹਾਡਾ activation funnel ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ: signed_up -> created_workspace -> completed_core_task. ਜੇ workspace ਬਣਾਉਣ ਅਤੇ core task ਵਿਚ ਵੱਡਾ ਡ੍ਰੌਪ ਹੈ, ਤਾਂ template_id ਅਤੇ success ਦੇ ਨਾਲ ਸੈਗਮੈਂਟ ਕਰੋ। ਤੁਸੀਂ ਸਿੱਖ ਸਕਦੇ ਹੋ ਕਿ ਇਕ template ਬਹੁਤ ਸਾਰੀਆਂ failed runs (success=false) ਦੇ ਕਾਰਣ ਹੈ, ਜਾਂ ਕੁਝ signup_source ਤੋਂ ਆਏ ਯੂਜ਼ਰ ਗਲਤ template ਚੁਣਦੇ ਹਨ ਅਤੇ ਕਦੇ value ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ।
ਫਿਰ ਤੁਹਾਡਾ “team expansion” view (completed_core_task -> invited_teammate) ਦਿਖਾਏਗਾ ਕਿ ਲੋਕ ਸਿਰਫ਼ ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਦੂਜੇ ਨੂੰ invite ਕਰਦੇ ਹਨ ਜਾਂ invite ਜਲਦੀ ਹੋ ਜਾਂਦੇ ਹਨ ਪਰ invite ਕੀਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ core task ਪੂਰਾ ਨਹੀਂ ਹੁੰਦਾ।
ਇਹੀ SaaS ਲਈ ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਬਣਾਉਣ ਦਾ ਮਕਸਦ ਹੈ: ਸਭ ਕੁਝ ਇਕੱਠਾ ਕਰਨ ਲਈ ਨਹੀਂ, ਪਰ ਇੱਕ ਸਭ ਤੋਂ ਵੱਡਾ ਰੁਕਾਵਟ ਲੱਭਣ ਲਈ ਜੋ ਤੁਸੀਂ ਅਗਲੇ ਹਫਤੇ ਠੀਕ ਕਰ ਸਕੋ।
ਜ਼ਿਆਦਾਤਰ ਟਰੈਕਿੰਗ ਫੇਲਿਉਰ ਟੂਲਾਂ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਉਸ ਵੇਲੇ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਟਰੈਕਿੰਗ ਦੱਸਦੀ ਹੈ ਕਿ ਲੋਕ ਕੀ ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ। ਜੇ ਤੁਹਾਡਾ ਡਾਟਾ ਸਵਾਲ "ਕੀ ਯੂਜ਼ਰ ਵੈਲਯੂ ਤੱਕ ਪਹੁੰਚਿਆ?" ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ ਤਾਂ ਤੁਹਾਡੀ SaaS ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਵਿਅਸਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਅਨੁਮਾਨ ਲਾਉਣਾ ਪਵੇਗਾ।
ਕਲਿੱਕ ਟਰੈਕ ਕਰਨਾ ਆਸਾਨ ਹੈ ਅਤੇ ਗਲਤ ਪੜ੍ਹਿਆ ਵੀ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਯੂਜ਼ਰ "Create project" ਤੇ ਤਿੰਨ ਵਾਰੀ ਕਲਿੱਕ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਫੇਲ ਰਹਿ ਸਕਦਾ। ਉਹ ਇਵੈਂਟ ਪਸੰਦ ਕਰੋ ਜੋ ਪ੍ਰਗਟਤਾ ਦਰਸਾਉਂਦੇ ਹਨ: created a workspace, invited a teammate, connected data, published, sent first invoice, completed first run.
ਜੇ ਤੁਸੀਂ ਨਾਂਵਾਂ UI ਦੇ ਨਵੇਂ ਲੇਖ ਦੇ ਅਨੁਸਾਰ ਬਦਲਦੇ ਰਹੋਗੇ, ਤੁਹਾਡੇ trends ਟੁੱਟ ਜਾਂਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਹਫਤੇ-ਵਾ-ਹਫਤੇ context ਗੁਆ ਬੈਠੋਗੇ। ਇੱਕ ਸਥਿਰ ਇਵੈਂਟ ਨਾਮ ਚੁਣੋ, ਫਿਰ properties ਰਾਹੀਂ ਮਾਇਨਾ ਵਿਕਸਤ ਕਰੋ (ਉਦਾਹਰਨ: project_created ਰੱਖੋ, ਤੇ ਜੇ ਨਵਾਂ entry point ਜੋੜਿਆ ਤਾਂ creation_source ਸ਼ਾਮਲ ਕਰੋ)।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ user_id ਭੇਜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ account ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ: ਕਿਹੜੀਆਂ ਟੀਮਾਂ activated ਹਨ, ਕਿਹੜੀਆਂ accounts churn ਹੋ ਰਹੀਆਂ ਹਨ, ਕਿਸ account ਵਿੱਚ power users ਕੌਣ ਹਨ। ਹਮੇਸ਼ਾ account_id ਸ਼ਾਮਲ ਕਰੋ (ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ role ਜਾਂ seat_type) ਤਾਂ ਕਿ ਤੁਸੀਂ user ਅਤੇ account ਦੋਹਾਂ retention ਵੇਖ ਸਕੋ।
ਜਿਆਦਾ ਹੋਣਾ ਵਧੀਆ ਨਹੀਂ। ਇੱਕ ਵੱਡਾ, inconsistent property ਸੈੱਟ ਖਾਲੀ ਮੁੱਲ, ਅਜੀਬ spelling variants, ਅਤੇ ਅਜਿਹਾ ਡੈਸ਼ਬੋਰਡ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਕੋਈ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ। ਇਕ ਛੋਟੀ "ਹਮੇਸ਼ਾ ਮੌਜੂਦ" ਸੈੱਟ ਰੱਖੋ, ਅਤੇ ਵਾਧੂ ਪ੍ਰਾਪਰਟੀਆਂ ਸਿਰਫ਼ ਉਹ ਸਮੇਂ ਜੋੜੋ ਜਦੋਂ ਉਹ ਕਿਸੇ ਖਾਸ ਸਵਾਲ ਨੂੰ support ਕਰਦੀਆਂ ਹਨ।
ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ:
user_id, ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ account_id)ਜੇ ਤੁਸੀਂ ਆਪਣੀ SaaS Koder.ai ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਟ੍ਰੈਕਿੰਗ ਨੂੰ ਕਿਸੇ ਹੋਰ ਫੀਚਰ ਵਾਂਗ ਹੀ ਟ੍ਰੀਟ ਕਰੋ: ਉਮੀਦਵੀ eventsdefine ਕਰੋ, ਪੂਰੀ ਯੂਜ਼ਰ ਯਾਤਰਾ ਚਲਾਓ, ਅਤੇ ਫਿਰ ਹੀ ਸ਼ਿਪ ਕਰੋ।
ਟ੍ਰੈਕਿੰਗ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਯਕੀਨ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਟ੍ਰੈਕਿੰਗ ਉਹ ਸਵਾਲ ਹਲ ਕਰੇਗੀ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹਫ਼ਤੇ 1 ਵਿੱਚ ਹਨ: ਕੀ ਲੋਕ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਪਹੁੰਚ ਰਹੇ ਹਨ, ਅਤੇ ਕੀ ਉਹ ਵਾਪਸ ਆ ਰਹੇ ਹਨ।
ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਪ੍ਰੀ-ਸ਼ਿਪ ਚੈੱਕ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸ਼ੁਰੂਆਤੀ ਗਲਤੀਆਂ ਫੈਡ ਕਰਦਾ ਹੈ:
ਇੱਕ ਸਧਾਰਨ QA trick: ਇੱਕ ਪੂਰੀ ਯਾਤਰਾ ਦੋ ਵਾਰੀ ਕਰੋ। ਪਹਿਲਾ ਰਨ activation ਜਾਂਚਦਾ ਹੈ। ਦੂਜਾ ਰਨ (ਲੌਗ ਆਊਟ ਅਤੇ ਵਾਪਸ ਲੌਗਇਨ ਕਰਕੇ, ਜਾਂ ਅਗਲੇ ਦਿਨ ਵਾਪਸ ਆ ਕੇ) retention signals ਜਾਂਚਦਾ ਹੈ ਅਤੇ double-firing ਬੱਗਾਂ ਰੋਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਇੱਕ snapshot/rollback ਜਾਂ code export ਤੋਂ ਬਾਅਦ ਵੀ ਇਹੀ QA ਕਰੋ, ਤਾਂ ਜੋ ਟ੍ਰੈਕਿੰਗ ਜਿਵੇਂ-ਜਿਵੇਂ ਐਪ ਬਦਲਦੀ ਹੈ ਸਹੀ ਰਹੇ।
ਆਪਣੀ ਪਹਿਲੀ ਟ੍ਰੈਕਿੰਗ ਸੈਟਅਪ ਛੋٽي ਮਹਿਸੂਸ honi ਚਾਹੀਦੀ ਹੈ। ਜੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਹਫਤੇ ਲੱਗ ਜਾਂ, ਤੁਸੀਂ ਬਦਲਾਅ ਤੱਕ ਫਿਰ ਨਹੀਂ ਜਾਵੋਗੇ, ਅਤੇ ਡੇਟਾ ਉਤਪਾਦ ਤੋਂ ਪਿੱਛੇ ਰਹਿ ਜਾਵੇਗਾ।
ਸਪੱਸ਼ਟ ਹਫਤਾਵਾਰ routine ਚੁਣੋ: ਇੱਕੋ ਡੈਸ਼ਬੋਰਡ ਵੇਖੋ, 3 takeaways ਲਿਖੋ ਅਤੇ 1 follow-up ਸਵਾਲ, ਅਤੇ ਟਰੈਕਿੰਗ ਤਦ ਹੀ ਬਦਲੋ ਜਦੋਂ ਉਹ ਸਵਾਲ ਅਨਲੌਕ ਕਰੇ। ਲਕਸ more events ਨਹੀਂ, ਪਰ ਚੰਗੇ ਜਵਾਬ ਹਨ।
ਵਧਾਉਣ ਲਈ ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਇੱਕ-ਦੋ events ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਜੋੜੋ, ਹਰ ਇਕ ਨਵੇਂ event ਨਾਲ ਇੱਕ ਆਸਲ ਸਵਾਲ ਹਲ ਹੋਵੇ। ਉਦਾਹਰਨ: “ਕੀ ਜੋ ਯੂਜ਼ਰ teammate ਨੂੰ invite ਕਰਦੇ ਹਨ ਉਹ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ activate ਹੁੰਦੇ ਹਨ?” ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ invite_sent ਟਰੈਕ ਕਰਦੇ ਹੋ ਪਰ invite_accepted ਨਹੀਂ, ਤਾਂ ਸਿਰਫ਼ ਉਹ ਹਿ missing event ਅਤੇ ਇੱਕ property ਜੋ segmentation ਲਈ ਲੋੜੀਂਦੀ ਹੈ (ਜਿਵੇਂ plan tier) ਜੋੜੋ। ਸ਼ਿਪ ਕਰੋ, ਇੱਕ ਹਫ਼ਤਾ ਡੈਸ਼ਬੋਰਡ ਵੇਖੋ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ।
ਛੋਟਾ cadence ਜੋ ਸ਼ੁਰੂਆਤੀ ਟੀਮਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ:
ਟ੍ਰੈਕਿੰਗ ਅਪਡੇਟ ਲਈ ਇੱਕ ਛੋਟੀ changelog ਰੱਖੋ ਤਾਂ ਸਭ ਕਿਸੇ ਤੇ ਗਿਣਤੀ ਭਰੋਸਾ ਕਰਨ। ਇਹ doc ਜਾਂ repo ਨੋਟ ਵਿੱਚ ਰਹਿ ਸਕਦੀ ਹੈ। ਸ਼ਾਮਲ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਪਹਿਲਾ ਐਪ ਬਣਾ ਰਹੇ ਹੋ, ਪਹਿਲਾਂ ਫਲੋ ਪਲਾਨ ਕਰੋ ਫਿਰ ਕੁਝ ਲਾਗੂ ਕਰੋ। Koder.ai ਵਿੱਚ, Planning Mode onboarding steps outline ਕਰਨ ਅਤੇ ਹਰ ਕਦਮ 'ਤੇ ਲੋੜੀਂਦੇ events ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਲਈ ਵਿਹੰਗਮ ਤਰੀਕਾ ਹੈ, ਫਿਰ ਕੋਡ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ।
ਜਦੋਂ ਤੁਸੀਂ onboarding 'ਤੇ iteration ਕਰੋ, ਆਪਣੀ ਟ੍ਰੈਕਿੰਗ consistency ਦੀ ਰੱਖਿਆ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai snapshots ਅਤੇ rollback ਵਰਤਦੇ ਹੋ, ਤੁਸੀਂ ਸਕਰੀਨਾਂ ਅਤੇ ਕਦਮਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਪਰ ਇਸਦੀਆਂ ਟ੍ਰੈਕਿੰਗ ਦਾ ਰਿਕਾਰਡ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਕਿ activation ਵਿੱਚ ਅਚਾਨਕ ਬਦਲਾਅ ਆਸਾਨੀ ਨਾਲ ਸਮਝ ਆ ਸਕੇ।