SaaS ਲਈ ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ: ਨਾਮ, ਪ੍ਰਾਪਰਟੀਆਂ, 10 ਡੈਸ਼ਬੋਰਡ

ਸ਼ੁਰੂ ’ਚ ਤੁਹਾਨੂੰ ਕੀ ਸਮਝਣਾ ਲੋੜੀਂਦਾ ਹੈ (ਅਤੇ ਕਿਉਂ ਇਹ ਮੁਸ਼ਕਲ ਹੈ)

ਪਹਿਲੇ SaaS ਐਪ ਦੀ ਸ਼ੁਰੂਆਤੀ ਅਨਾਲਿਟਿਕਸ ਅਕਸਰ ਉਲਝਣ ਵਾਲੀ ਲੱਗਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਕੋ ਸਮੇਂ ਦੋ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਜੂਝ ਰਹੇ ਹੁੰਦੇ ਹੋ: ਬਹੁਤ ਘੱਟ ਯੂਜ਼ਰ ਅਤੇ ਘੱਟ ਸੰਦਰਭ। ਕੁਝ ਪਾਵਰ ਯੂਜ਼ਰਾਂ ਤੁਹਾਡੇ ਚਾਰਟਾਂ ਨੂੰ ਤਰਦੀਬ ਦੇ ਸਕਦੇ ਹਨ, ਜਦਕਿ ਕੁਝ “ਟੂਰਿਸਟ” (ਜੋ ਸਾਈਨਅਪ ਕਰਦੇ ਹਨ ਅਤੇ ਛੱਡ ਦੇਂਦੇ ਹਨ) ਸਭ ਕੁਝ ਖਰਾਬ ਦਿਖਾ ਸਕਦੇ ਹਨ.

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

ਇਕ ਚੰਗੀ SaaS ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਤੁਹਾਡੇ ਨੂੰ ਪਹਿਲੇ 30 ਦਿਨਾਂ ਵਿੱਚ ਕੁਝ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ, ਬਿਨਾ ਕਿਸੇ ਡਾਟਾ ਟੀਮ ਦੀ ਲੋੜ ਦੇ।

ਉਹ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਦੇ ਜਵਾਬ ਤੁਹਾਨੂੰ ਫੁਰਤੀਆਂ ਮਿਲਣੇ ਚਾਹੀਦੇ ਹਨ

ਜੇ ਤੁਹਾਡੀ ਟਰੈਕਿੰਗ ਇਹ ਸਵਾਲ ਹਲ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਠੀਕ ਜਗ੍ਹਾ ਤੇ ਹੋ:

• ਨਵੇਂ ਸਾਈਨਅਪਸ ਕਿਸ ਥਾਂ ਛੱਡਦੇ ਹਨ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ?
• ਕਿੰਨੇ ਯੂਜ਼ਰ 24 ਘੰਟਿਆਂ ਅਤੇ 7 ਦਿਨਾਂ ਵਿੱਚ “ਪਹਿਲੀ ਵੈਲਯੂ” ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ?
• ਕਿਹੜੀਆਂ ਫੀਚਰਾਂ ਉਹ ਲੋਕ ਵਰਤਦੇ ਹਨ ਜੋ ਅਗਲੇ ਹਫਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਨ?
• ਸਫਲਤਾ ਦਾ ਸਭ ਤੋਂ ਆਮ ਰਸਤਾ ਕਿਹੜਾ ਹੈ (ਅਤੇ ਸਭ ਤੋਂ ਆਮ ਫੇਲ ਰਸਤਾ)?
• ਵਾਪਸ ਆਉਣ ਵਾਲੇ ਯੂਜ਼ਰ ਉਸੇ ਕੰਮ ਲਈ ਵਾਪਸ ਆ ਰਹੇ ਹਨ ਜਾਂ ਸਿਰਫ਼ ਆਸ-ਪਾਸ ਵੇਖ ਰਹੇ ਹਨ?

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

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, Koder.ai ਵਰਗੀ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਨਵੇਂ ਫਲੋ ਦਿਨਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ), ਤਾੰ ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਸਾਰਾ ਕੁਝ ਇੰਸਟਰੂਮੈਂਟ ਕਰ ਦਿਓ। ਵੱਧ ਇਵੈਂਟ ਦੇ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਵੱਧ ਗੁੰਝਲ। ਛੋਟੇ ਕਾਰਵਾਈ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ "ਪਹਿਲੀ ਜਿੱਤ" ਅਤੇ "ਦੋਹਰਾਈ ਜਿੱਤ" ਨਾਲ ਨਕਸ਼ਾ ਮਿਲਦੇ ਹੋਣ, ਫਿਰ ਜਦੋਂ ਕੋਈ ਫੈਸਲਾ ਲੋੜ ਹੋਵੇ ਤਾਂ ਹੀ ਵਧਾਓ।

ਐਕਟੀਵੇਸ਼ਨ ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

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

ਸ਼ੁਰੂ ਕਰੋ ਦੋ “ਲੋਕ” ਨੂੰ ਉਤਾਰ ਕੇ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਹਨ:

• Core user: ਕੰਮ ਕਰਨ ਵਾਲਾ ਵਿਅਕਤੀ (ਜੋ ਕਲਿੱਕ ਕਰਦਾ, ਅਪਲੋਡ ਕਰਦਾ, ਭੇਜਦਾ, ਬਣਾਉਂਦਾ ਹੈ)।
• Account: ਗਾਹਕ ਜੋ ਭੁਗਤਾਨ ਅਤੇ ਬਿਲਿੰਗ ਰੱਖਦਾ ਹੈ (ਵਿਅਕਤੀ ਜਾਂ ਕੰਪਨੀ)।

ਬਹੁਤ ਸਾਰੇ SaaS ਐਪ ਟੀਮਾਂ ਦੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ account ਵਿੱਚ ਕਈ ਯੂਜ਼ਰ ਹੋ ਸਕਦੇ ਹਨ। ਇਸੀ ਲਈ ਤੁਹਾਡੀ ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾਏ ਕਿ ਤੁਸੀਂ ਯੂਜ਼ਰ ਬਿਹੇਵਿਯਰ, ਇੱਕਾਊਂਟ ਹੇਲਥ, ਜਾਂ ਦੋਹਾਂ ਨੂੰ ਮਾਪ ਰਹੇ ਹੋ।

ਐਕਟੀਵੇਸ਼ਨ ਇੱਕ ਵਾਕ ਵਿੱਚ

ਐਕਟੀਵੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਨਤੀਜਾ ਹੋਵੇ। ਚੰਗੇ ਐਕਟੀਵੇਸ਼ਨ ਪਲ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੇ ਹਨ: “ਮੈਂ X ਕੀਤਾ ਅਤੇ Y ਮਿਲਿਆ।”

ਉਦਾਹਰਨ: “ਇੱਕ ਯੂਜ਼ਰ ਆਪਣਾ ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।” (ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਟੂਲ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ “ਪਹਿਲੀ ਸਫਲ ਡਿਪਲੋਯ” ਜਾਂ “ਪਹਿਲਾ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ” ਹੋ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਵਾਅਦੇ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ।)

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

• Sign up
• Create the first workspace/project
• Add the key input (data, content, integration, or settings)
• Run the core action (send, publish, generate, invite)
• Reach a success state (completed, delivered, deployed)

ਤੁਹਾਡੇ ਲਈ ਰਿਟੇਨਸ਼ਨ ਦਾ ਮਤਲਬ

ਰਿਟੇਨਸ਼ਨ ਇਹ ਹੈ ਕਿ ਉਹ ਕਿਸ ਸ਼ਡਿਊਲ ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ।

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

ਕਦਮ-ਦਰ-ਕਦਮ: ਆਪਣੀ ਪਹਿਲੀ ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਬਣਾਓ

ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਦੇ ਰਸਤੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਇਕ SaaS ਲਈ ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਸਭ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਇੱਕ ਸਧਾਰਨ ਕਹਾਣੀ ਪਿੱਛੇ ਚਲਦੀ ਹੈ: ਨਵਾਂ ਵਿਅਕਤੀ ਸਾਈਨਅਪ ਤੋਂ ਆਪਣੇ ਪਹਿਲੇ ਅਸਲ ਫਾਇਦੇ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ।

ਸਭ ਤੋਂ ਛੋਟਾ ਔਨਬੋਰਡਿੰਗ ਰਸਤਾ ਲਿਖੋ ਜੋ ਮੁੱਲ ਬਣਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ: Signup -> verify email -> create workspace -> invite teammate (optional) -> connect data (or set up project) -> complete first key action -> see result.

ਹੁਣ ਉਹ ਮੋੜ ਨਿਸ਼ਾਨ ਲਗਾਓ ਜਿਥੇ ਕੋਈ ਡ੍ਰੌਪ ਆ ਸਕਦਾ ਹੈ ਜਾਂ ਫਸ ਸਕਦਾ ਹੈ। ਉਹ ਮੋੜ ਪਹਿਲੇ ਇਵੈਂਟ ਹੋ ਜਾਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰੋगे।

ਘੱਟੋ-ਘੱਟ ਸੈੱਟ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਟੈਸਟ ਕਰੋ

ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ 8-15 ਇਵੈਂਟ ਚਾਹੀਦੇ ਹੁੰਦੇ ਹਨ, 80 ਨਹੀਂ। ਉਸ ਤਰ੍ਹਾਂ ਦੇ ਇਵੈਂਟਾਂ ਨੂੰ ਟਾਰਗੇਟ ਕਰੋ ਜੋ ਉੱਤਰ ਦਿੰਦੇ ਹਨ: ਕੀ ਉਹ ਸ਼ੁਰੂ ਹੋਏ? ਕੀ ਉਹ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਪਹੁੰਚੇ? ਕੀ ਉਹ ਵਾਪਸ ਆਏ?

ਇਕ ਵਰਤੋਂਯੋਗ ਨਿਰਮਾਣ ਕ੍ਰਮ:

• Onboarding ਅਤੇ first-value ਰਸਤਾ ਨਕਸ਼ਾ ਬਣਾਓ (ਇੱਕ ਪੰਨਾ, ਕੋਈ ਵਿਚਾਰ ਨਹੀਂ)
• ਹਰ ਕਦਮ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੀ ਛੋਟੀ ਇਵੈਂਟ ਸੂਚੀ ਚੁਣੋ
• ਹਰ ਇਵੈਂਟ ਨੂੰ ਇੱਕ ਛੋਟੀ ਸਪੀਕ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਨਾਮ, ਕਦੋਂ ਫਾਇਰ ਹੁੰਦਾ ਹੈ, ਕੀ.properties)
• ਹਰ ਇਵੈਂਟ ਨਾਲ ਇੱਕ ਸਥਿਰ user ID ਅਤੇ ਇੱਕ account/workspace ID ਜੋੜੋ
• ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲੀ ਫਲੋ ਚਲਾ ਕੇ ਇਵੈਂਟ ਟੈਸਟ ਕਰੋ

ਇਵੈਂਟ ਸਪੀਸ ਲਈ, ਇੱਕ ਸਧਾਰਨ ਟੇਬਲ ਕਾਗਜ਼ 'ਤੇ ਕਾਫੀ ਹੈ। ਸ਼ਾਮਲ ਕਰੋ: 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_demo
• submitted_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 ਨੂੰ ਸਲਾਈਸ ਕਰਨ ਦਿੰਦੇ ਹਨ ਬਿਨਾ ਡੈਸ਼ਬੋਰਡ ਮੁੜ ਬਣਾਉਣ ਦੇ।

ਕਾਰਗਰ ਕੋਰ ਸੈੱਟ:

• user_id ਅਤੇ account_id (ਕਿਸਨੇ ਕੀਤਾ ਅਤੇ ਕਿਹੜੀ ਵਰਕਸਪੇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ)
• plan_tier (free, pro, business, enterprise)
• timestamp (ਕਦੋਂ ਹੋਇਆ, ਸੰਭਵ ਹੋਏ ਤਾਂ ਸਰਵਰ ਤੋਂ)
• app_version (ਰੀਲੀਜ਼ਾਂ ਤੋਂ ਬਾਅਦ ਬਦਲਾਅ ਨੋਟ ਕਰਨ ਲਈ)
• signup_source (ਯੂਜ਼ਰ ਕਿੱਥੋਂ ਆਇਆ, ਜਿਵੇਂ ads, referral, ਜਾਂ organic)

ਫਿਰ_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 ਅਸਥਾਈ ਰੂਪ ਵਿੱਚ ਰੱਖਣਾ ਅਤੇ ਫਿਰ ਹਟਾ ਦੇਣਾ।

ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ ਹাইজੀਨ ਚੈੱਕਲਿਸਟ ਹੈ ਜੋ ਤੁਹਾਡੇ ਪਹਿਲੇ ਡੈਸ਼ਬੋਰਡ ਨਾਲ ਭੇਜਣ ਲਈ ਉਪਯੋਗੀ ਰਹੇਗੀ:

• ਭੇਜਣ ਲਈ ਇੱਕ allow-list ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਬਾਕੀ ਸਾਰੇ ਬਲਾਕ)
• ਯੂਜ਼ਰ ਦੇ ਡੇਟਾ ਨੂੰ ਮੰਗ 'ਤੇ ਮਿਟਾਉਣ ਦਾ ਤਰੀਕਾ ਸ਼ਾਮਲ ਕਰੋ (user_id ਅਤੇ account_id ਨਾਲ)
• ਪਹੁੰਚ ਸੀਮਿਤ ਕਰੋ: ਕੌਣ raw events ਦੇਖ ਸਕਦਾ ਹੈ, ਕੌਣ export ਕਰ ਸਕਦਾ ਹੈ, ਤੇ ਕੌਣ ਟ੍ਰੈਕਿੰਗ ਬਦਲ ਸਕਦਾ ਹੈ
• ਇੱਕ ਛੋਟੀ ਟਰੈਕਿੰਗ ਡੌਕ ਰੱਖੋ ਜਿਸ ਵਿੱਚ “safe” vs “not safe” ప్రਾਪర్టੀਜ਼ ਦੇ ਉਦਾਹਰਨ ਹੋਣ

ਜੇ ਤੁਸੀਂ ਆਪਣੀ SaaS Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹੀ ਨਿਯਮ ਸਿਸਟਮ ਲੌਗਸ ਅਤੇ snapshots 'ਤੇ ਲਾਗੂ ਕਰੋ: identifiers ਨੂੰ ਨਿਰੰਤਰ ਰੱਖੋ, PII ਨੂੰ event payloads ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਅਤੇ ਦਰਸਾਓ ਕਿ ਕੌਣ কি ਵੇਖ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਉਂ।

ਸ਼ੁਰੂਆਤੀ ਐਕਟੀਵੇਸ਼ਨ ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਲਈ 10 ਲਾਜ਼ਮੀ ਡੈਸ਼ਬੋਰਡ

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

ਐਕਟੀਵੇਸ਼ਨ ਨੂੰ ਸਮਝਾਉਂਦੇ ਡੈਸ਼ਬੋਰਡ

• 1) ਨਵੇਂ ਯੂਜ਼ਰ ਟਰੇਂਡ (ਦੈਨਿਕ/ਹਫਤਾਵਾਰ) + signup_source: ਨਵੀਆਂ ਅਕਾਊਂਟਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਆਉਣ ਦੇ ਜਗ੍ਹਾ ਅਨੁਸਾਰ ਵੰਡ (ads, organic, referral, invite). ਉਹ spike ਦੇਖੋ ਜੋ ਬਾਅਦ ਵਿੱਚ activate ਨਹੀਂ ਹੁੰਦੇ।
• 2) Activation funnel with drop-offs: ਇੱਕ ਸਧਾਰਨ ਫਨਲ ਜਿਵੇਂ Signup -> Email verified -> Project created -> First value action. ਸਭ ਤੋਂ ਵੱਡਾ drop ਵਾਲਾ ਕਦਮ highlight ਕਰੋ ਅਤੇ sessions ਦੀ ਜਾਂਚ ਕਰੋ।
• 3) Time to first value (median, p75): ਇਹ ਮਾਪੋ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਤੁਹਾਡੀ first value ਇਵੈਂਟ ਤੱਕ ਪਹੁੰਚਣ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। median ਆਮ ਰਸਤਾ ਦਿਖਾਉਂਦਾ ਹੈ; p75 ਦਿਖਾਉਂਦਾ ਹੈ ਕੌਣ ਸੰਘਰਸ਼ ਕਰ ਰਿਹਾ ਹੈ।
• 4) Feature adoption (top 5 value actions): ਉਹ ਕੁਝ ਕਾਰਵਾਈਆਂ ਟਰੈਕ ਕਰੋ ਜੋ ਅਸਲ ਵਰਤੋਂ ਦਰਸਾਉਂਦੀਆਂ ਹਨ (settings ਕਲਿੱਕ ਨਹੀਂ)। ਸਿਰਫ top 5 ਰੱਖੋ ਤਾਂ ਜੋ ਪੜ੍ਹਨਾ ਆਸਾਨ ਰਹੇ।
• 5) Activation rate by signup_source: ਇਕੋ activation ਪਰਿਭਾਸ਼ਾ ਨੂੰ source ਦੇ ਅਨੁਸਾਰ ਵੰਡੋ। ਇਕ ਚੈਨਲ ਸ਼ੌਕੀਨ ਵਿਜ਼ਟਰ ਲਿਆਉਂਦਾ ਹੈ, ਹੋਰ ਖਰੀਦਦਾਰ।

ਰਿਟੇਨਸ਼ਨ ਨੂੰ ਸਮਝਾਉਂਦੇ ਡੈਸ਼ਬੋਰਡ

• 6) Retention cohorts (week 1, week 4): signup ਹਫਤੇ ਦੇ ਅਨੁਸਾਰ cohorts, retention ਨੂੰ ਇੱਕ key action ਨਾਲ ਮਾਪਿਆ। ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਮੇਂ ਦੇ ਨਾਲ ਪ੍ਰੋਡક્ટ ਵੱਧ sticky ਹੋ ਰਿਹਾ ਹੈ ਕਿ ਨਹੀਂ।
• 7) Returning users trend (WAU): ਹਫਤਾਵਾਰ ਸਰਗਰਮ ਯੂਜ਼ਰ (ਕਿਸੇ key action ਦੇ ਆਧਾਰ ਤੇ) ਤਾਂ ਜੋ “ਲੌਗਿਨ” ਅਤੇ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਫਰਕ ਹੋਵੇ।
• 8) Repeat value frequency: ਹਫਤੇ ਵਿੱਚ ਕਿੰਨੇ ਦਿਨ ਯੂਜ਼ਰ core action ਕਰਦੇ ਹਨ। ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ habit-forming workflow ਰੱਖਦੇ ਹੋ ਕਿ ਨਹੀਂ।
• 9) Re-activation funnel: Inactive -> Returned -> Did key action. ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ reminders ਅਤੇ ਨਵੀਆਂ ਫੀਚਰਾਂ ਲੋਕਾਂ ਨੂੰ ਮੁੜ ਲਿਆਉਂਦੀਆਂ ਹਨ ਕਿ ਨਹੀਂ।
• 10) Friction dashboard (errors and failed actions): “error_shown”, “payment_failed”, ਜਾਂ “integration_failed” ਜਿਹੇ ਘਟਨਾਵਾਂ ਟਰੈਕ ਕਰੋ। ਇਥੇ spikes activation ਅਤੇ retention ਨੂੰ ਚੁੱਪਕੇ ਨਾਲ ਮਾਰ ਦਿੰਦੇ ਹਨ।

ਉਦਾਹਰਨ ਮਾਮਲਾ: signup ਤੋਂ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਇੱਕ ਨਵੇਂ SaaS ਦੀ ਟ੍ਰੈਕਿੰਗ

ਇੱਕ ਸਧਾਰਨ B2B SaaS ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿਸ ਵਿੱਚ 14-ਦਿਨ ਦੀ free trial ਹੈ। ਇੱਕ ਵਿਅਕਤੀ ਸਾਈਨਅਪ ਕਰਦਾ ਹੈ, ਆਪਣੀ ਟੀਮ ਲਈ workspace ਬਣਾਉਂਦਾ ਹੈ, ਪ੍ਰੋਡੱਕਟ ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਅਤੇ (ਆਦਰਸ਼ ਰੂਪ ਵਿੱਚ) ਇੱਕ teammate ਨੂੰ invite ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਲਕੜੀ ਦਾ ਲਕੜੀ ਇਹ ਜ਼ਲਦੀ ਸਿੱਖਨਾ ਹੈ ਕਿ ਲੋਕ ਕਿੱਥੇ ਫਸਦੇ ਹਨ।

“ਪਹਿਲੀ ਵੈਲਯੂ” ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਯੂਜ਼ਰ ਇੱਕ workspace ਬਣਾਉਂਦਾ ਅਤੇ ਇੱਕ core task ਪੂਰਾ ਕਰਦਾ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਤਪਾਦ ਉਨ੍ਹਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, “CSV ਇੰਪੋਰਟ ਕਰਕੇ ਪਹਿਲਾ ਰਿਪੋਰਟ ਜਨਰੇਟ ਕਰੋ”). ਤੁਹਾਡੀ ਸ਼ੁਰੂਆਤੀ ਟ੍ਰੈਕਿੰਗ ਦਾ ਸਾਰ ਇਸ ਪਲ ਵੱਲ ਵਾਪਸ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਥੇ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਇਵੈਂਟ ਸੈੱਟ ਹੈ ਜੋ ਤੁਸੀਂ ਦਿਨ ਪਹਿਲੇ ਹੀ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ (ਨਾਂ ਸਧਾਰਨ verbs ਵਿੱਚ ਭੂਤ ਕਾਲ ਨਾਲ, ਸਪਸ਼ਟ objects):

• created_workspace
• completed_core_task
• invited_teammate

ਹਰ ਇਵੈਂਟ ਲਈ, ਥੋੜ੍ਹੀਆਂ ਹੀ ਪ੍ਰਾਪਰਟੀਜ਼ ਜੋ ਇਹ ਦੱਸਣ ਲਈ ਕਾਫ਼ੀ ਹਨ ਕਿ ਕਿਉਂ ਇਹ ਹੋਇਆ (ਜਾਂ ਨਹੀਂ ਹੋਇਆ)। ਚੰਗੀਆਂ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਾਪਰਟੀਆਂ ਹਨ:

• signup_source (google_ads, referral, founder_linkedin, ਆਦਿ)
• template_id (ਕਿਹੜਾ starting setup ਉਹ ਨੇ ਚੁਣਿਆ)
• seats_count (ਖ਼ਾਸ ਕਰਕੇ ਟੀਮ invites ਲਈ)
• success (true/false) ਅਤੇ ਜੇ success=false ਤਾਂ ਇੱਕ ਛੋਟਾ error_code

ਹੁਣ ਆਪਣੇ ਡੈਸ਼ਬੋਰਡ ਦੀ ਸੋਚੋ। ਤੁਹਾਡਾ 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 ਇਵੈਂਟ ਟ੍ਰੈਕਿੰਗ ਯੋਜਨਾ ਵਿਅਸਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਅਨੁਮਾਨ ਲਾਉਣਾ ਪਵੇਗਾ।

ਗਲਤੀ 1: ਆਉਟਕਮ ਦੀ ਥਾਂ ਕਲਿੱਕ ਮਾਪਨਾ

ਕਲਿੱਕ ਟਰੈਕ ਕਰਨਾ ਆਸਾਨ ਹੈ ਅਤੇ ਗਲਤ ਪੜ੍ਹਿਆ ਵੀ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਯੂਜ਼ਰ "Create project" ਤੇ ਤਿੰਨ ਵਾਰੀ ਕਲਿੱਕ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਫੇਲ ਰਹਿ ਸਕਦਾ। ਉਹ ਇਵੈਂਟ ਪਸੰਦ ਕਰੋ ਜੋ ਪ੍ਰਗਟਤਾ ਦਰਸਾਉਂਦੇ ਹਨ: created a workspace, invited a teammate, connected data, published, sent first invoice, completed first run.

ਗਲਤੀ 2: ਹਰ ਸਪ੍ਰਿੰਟ 'ਚ ਇਵੈਂਟ ਨਾਮ ਬਦਲਣਾ

ਜੇ ਤੁਸੀਂ ਨਾਂਵਾਂ UI ਦੇ ਨਵੇਂ ਲੇਖ ਦੇ ਅਨੁਸਾਰ ਬਦਲਦੇ ਰਹੋਗੇ, ਤੁਹਾਡੇ trends ਟੁੱਟ ਜਾਂਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਹਫਤੇ-ਵਾ-ਹਫਤੇ context ਗੁਆ ਬੈਠੋਗੇ। ਇੱਕ ਸਥਿਰ ਇਵੈਂਟ ਨਾਮ ਚੁਣੋ, ਫਿਰ properties ਰਾਹੀਂ ਮਾਇਨਾ ਵਿਕਸਤ ਕਰੋ (ਉਦਾਹਰਨ: project_created ਰੱਖੋ, ਤੇ ਜੇ ਨਵਾਂ entry point ਜੋੜਿਆ ਤਾਂ creation_source ਸ਼ਾਮਲ ਕਰੋ)।

ਗਲਤੀ 3: B2B identifiers ਭੁੱਲ ਜਾਣਾ

ਜੇ ਤੁਸੀਂ ਸਿਰਫ user_id ਭੇਜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ account ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ: ਕਿਹੜੀਆਂ ਟੀਮਾਂ activated ਹਨ, ਕਿਹੜੀਆਂ accounts churn ਹੋ ਰਹੀਆਂ ਹਨ, ਕਿਸ account ਵਿੱਚ power users ਕੌਣ ਹਨ। ਹਮੇਸ਼ਾ account_id ਸ਼ਾਮਲ ਕਰੋ (ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ role ਜਾਂ seat_type) ਤਾਂ ਕਿ ਤੁਸੀਂ user ਅਤੇ account ਦੋਹਾਂ retention ਵੇਖ ਸਕੋ।

ਗਲਤੀ 4: ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਾਪਰਟੀਆਂ ਭੇਜਣਾ

ਜਿਆਦਾ ਹੋਣਾ ਵਧੀਆ ਨਹੀਂ। ਇੱਕ ਵੱਡਾ, inconsistent property ਸੈੱਟ ਖਾਲੀ ਮੁੱਲ, ਅਜੀਬ spelling variants, ਅਤੇ ਅਜਿਹਾ ਡੈਸ਼ਬੋਰਡ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਕੋਈ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ। ਇਕ ਛੋਟੀ "ਹਮੇਸ਼ਾ ਮੌਜੂਦ" ਸੈੱਟ ਰੱਖੋ, ਅਤੇ ਵਾਧੂ ਪ੍ਰਾਪਰਟੀਆਂ ਸਿਰਫ਼ ਉਹ ਸਮੇਂ ਜੋੜੋ ਜਦੋਂ ਉਹ ਕਿਸੇ ਖਾਸ ਸਵਾਲ ਨੂੰ support ਕਰਦੀਆਂ ਹਨ।

ਗਲਤੀ 5: ਅਖੀਰ ਤੱਕ end-to-end ਟੈਸਟ ਨਾ ਕਰਨਾ

ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ:

• Events ਇੱਕ ਵਾਰੀ ਫਾਇਰ ਹੁੰਦੇ ਹਨ (ਦੋ ਵਾਰੀ ਨਹੀਂ) ਅਤੇ ਸਹੀ ਸਮੇਂ ਤੇ
• ਲਾਜ਼ਮੀ IDs ਮੌਜੂਦ ਹਨ (user_id, ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ account_id)
• Property values ਤਹਿ ਕੀਤੇ ਸੂਚੀ ਦੇ ਅਨੁਸਾਰ ਹਨ (ਕੋਈ ਅਚਾਨਕ strings ਨਹੀਂ)
• ਡੈਸ਼ਬੋਰਡ ਅਸਲੀ ਫਲੋਜ਼ ਤੋਂ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ, ਸਿਰਫ ਟੈਸਟ ਡੇਟਾ ਤੋਂ ਨਹੀਂ
• ਤੁਸੀਂ ਯੂਜ਼ਰ ਯਾਤਰਾ ਨੂੰ ਕ੍ਰਮਵਾਰ replay ਕਰ ਸਕਦੇ ਹੋ

ਜੇ ਤੁਸੀਂ ਆਪਣੀ SaaS Koder.ai ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਟ੍ਰੈਕਿੰਗ ਨੂੰ ਕਿਸੇ ਹੋਰ ਫੀਚਰ ਵਾਂਗ ਹੀ ਟ੍ਰੀਟ ਕਰੋ: ਉਮੀਦਵੀ eventsdefine ਕਰੋ, ਪੂਰੀ ਯੂਜ਼ਰ ਯਾਤਰਾ ਚਲਾਓ, ਅਤੇ ਫਿਰ ਹੀ ਸ਼ਿਪ ਕਰੋ।

ਟ੍ਰੈਕਿੰਗ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈਕਲਿਸਟ

ਟ੍ਰੈਕਿੰਗ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਯਕੀਨ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਟ੍ਰੈਕਿੰਗ ਉਹ ਸਵਾਲ ਹਲ ਕਰੇਗੀ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹਫ਼ਤੇ 1 ਵਿੱਚ ਹਨ: ਕੀ ਲੋਕ ਪਹਿਲੀ ਵੈਲਯੂ ਤੱਕ ਪਹੁੰਚ ਰਹੇ ਹਨ, ਅਤੇ ਕੀ ਉਹ ਵਾਪਸ ਆ ਰਹੇ ਹਨ।

• ਆਪਣੇ ਮੁੱਖ ਫਲੋਜ਼ (signup, onboarding, first value, returning use) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਹਰ ਫਲੋ ਲਈ 1-3 outcome events ਚੁਣੋ ਜੋ ਪ੍ਰਗਟਤਾ ਸਾਬਤ ਕਰਦੇ ਹਨ।
• ਜੇ ਤੁਸੀਂ ਹਰ ਕਲਿੱਕ ਨੂੰ ਟ੍ਰੈਕ ਕਰੋਂਗੇ, ਤੁਸੀਂ ਸ਼ੋਰ ਵਿੱਚ ਡूब ਜਾਉਗੇ ਅਤੇ ਤੱਥ ਭੀ ਗੁਆ ਦਿਓਗੇ।
• ਇੱਕ ਨਾਂकरण ਕਨਵੇਂਸ਼ਨ ਸਭ ਥਾਂ ਵਰਤੋ ਅਤੇ ਇਸਨੂੰ ਸਾਦੇ ਡੌਕ ਵਿੱਚ ਲਿਖੋ। ਲਕਸ਼ ਇਹ ਹੈ ਕਿ ਦੋ ਲੋਕ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਇੱਕੋ ਇਵੈਂਟ ਦਾ ਨਾਮ ਰੱਖ ਕੇ ਇੱਕੋ ਨਤੀਜੇ 'ਤੇ ਪਹੁੰਚ ਜਾਣ।

ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਪ੍ਰੀ-ਸ਼ਿਪ ਚੈੱਕ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸ਼ੁਰੂਆਤੀ ਗਲਤੀਆਂ ਫੈਡ ਕਰਦਾ ਹੈ:

• Outcome first: ਹਰ ਮੁੱਖ ਫਲੋ ਵਿੱਚ outcome events ਹੋਣ, UI click events ਨਹੀਂ
• Names are consistent: events verb+noun ਅਨੁਸਾਰ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਮਾਇਨਾ ਇਕ ਜਗ੍ਹਾ ਤੇ ਦਸਤਾਵੇਜ਼ ਹੈ
• Properties are typed: ਆਵਸ਼્યਕ properties ਹਰ event 'ਚ ਇਕੋ type ਰੱਖੀਆਂ ਗਈਆਂ ਹਨ (ਜਿਵੇਂ plan ਸਦਾ string, seat_count ਸਦਾ number)
• Dashboards match definitions: activation dashboard ਤੁਹਾਡੇ activation event ਨੂੰ ਵਰਤਦਾ ਹੈ, retention dashboard ਤੁਹਾਡੇ retention event ਨੂੰ (ਕੋਈ ਬੇਤਰਤੀਬ proxy ਨਹੀਂ)
• QA once like a user: ਐਪ ਚਲਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ events ਇੱਕ ਵਾਰੀ, ਸਹੀ ਸਮੇਂ, ਸਹੀ properties ਨਾਲ ਫਾਇਰ ਹੁੰਦੇ ਹਨ

ਇੱਕ ਸਧਾਰਨ QA trick: ਇੱਕ ਪੂਰੀ ਯਾਤਰਾ ਦੋ ਵਾਰੀ ਕਰੋ। ਪਹਿਲਾ ਰਨ activation ਜਾਂਚਦਾ ਹੈ। ਦੂਜਾ ਰਨ (ਲੌਗ ਆਊਟ ਅਤੇ ਵਾਪਸ ਲੌਗਇਨ ਕਰਕੇ, ਜਾਂ ਅਗਲੇ ਦਿਨ ਵਾਪਸ ਆ ਕੇ) retention signals ਜਾਂਚਦਾ ਹੈ ਅਤੇ double-firing ਬੱਗਾਂ ਰੋਕਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਇੱਕ snapshot/rollback ਜਾਂ code export ਤੋਂ ਬਾਅਦ ਵੀ ਇਹੀ QA ਕਰੋ, ਤਾਂ ਜੋ ਟ੍ਰੈਕਿੰਗ ਜਿਵੇਂ-ਜਿਵੇਂ ਐਪ ਬਦਲਦੀ ਹੈ ਸਹੀ ਰਹੇ।

ਅਗਲੇ ਕਦਮ: ਹਲਕਾ ਰੱਖੋ ਅਤੇ_itration ਕਰੋ

ਆਪਣੀ ਪਹਿਲੀ ਟ੍ਰੈਕਿੰਗ ਸੈਟਅਪ ਛੋٽي ਮਹਿਸੂਸ 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 ਜੋ ਸ਼ੁਰੂਆਤੀ ਟੀਮਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ:

• Activation ਅਤੇ retention ਡੈਸ਼ਬੋਰਡ ਹਰ ਹਫ਼ਤੇ ਇੱਕੋ ਦਿਨ ਤੇ ਵੇਖੋ
• 3 takeaways ਅਤੇ 1 follow-up ਸਵਾਲ ਲਿਖੋ
• ਟਰੈਕਿੰਗ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਜੋੜੋ/ਸਮਨਵਿਤ ਕਰੋ ਜਦੋਂ ਇਹ ਸਵਾਲ ਖੋਲ੍ਹੇ
• Event names ਸਥਿਰ ਰੱਖੋ; ਨਵੇਂ events ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ properties ਜੋੜੋ
• ਕੁਝ ਵੀ ਹਟਾਓ ਨਹੀਂ ਜਦ ਤੱਕ ਤੁਸੀਂ ਯਕੀਨ ਨਾ ਕਰ ਲੋ ਕਿ ਉਹ ਅਣਉਪਯੋਗ ਹੈ (ਹਟਾਉਣਾ trends ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ)

ਟ੍ਰੈਕਿੰਗ ਅਪਡੇਟ ਲਈ ਇੱਕ ਛੋਟੀ changelog ਰੱਖੋ ਤਾਂ ਸਭ ਕਿਸੇ ਤੇ ਗਿਣਤੀ ਭਰੋਸਾ ਕਰਨ। ਇਹ doc ਜਾਂ repo ਨੋਟ ਵਿੱਚ ਰਹਿ ਸਕਦੀ ਹੈ। ਸ਼ਾਮਲ ਕਰੋ:

• ਤਾਰੀਖ ਅਤੇ ਮਾਲਕ
• ਕੀ ਬਦਲਿਆ (event/property ਨਾਮ)
• ਕਿਉਂ ਬਦਲਿਆ (ਸਵਾਲ)
• ਉਮੀਦ ਕੀਤੀ ਪ੍ਰਭਾਵ (ਕਿਹੜੇ ਡੈਸ਼ਬੋਰਡ ਪ੍ਰਭਾਵਿਤ ਹੋਣ)

ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਪਹਿਲਾ ਐਪ ਬਣਾ ਰਹੇ ਹੋ, ਪਹਿਲਾਂ ਫਲੋ ਪਲਾਨ ਕਰੋ ਫਿਰ ਕੁਝ ਲਾਗੂ ਕਰੋ। Koder.ai ਵਿੱਚ, Planning Mode onboarding steps outline ਕਰਨ ਅਤੇ ਹਰ ਕਦਮ 'ਤੇ ਲੋੜੀਂਦੇ events ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਲਈ ਵਿਹੰਗਮ ਤਰੀਕਾ ਹੈ, ਫਿਰ ਕੋਡ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ।

ਜਦੋਂ ਤੁਸੀਂ onboarding 'ਤੇ iteration ਕਰੋ, ਆਪਣੀ ਟ੍ਰੈਕਿੰਗ consistency ਦੀ ਰੱਖਿਆ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai snapshots ਅਤੇ rollback ਵਰਤਦੇ ਹੋ, ਤੁਸੀਂ ਸਕਰੀਨਾਂ ਅਤੇ ਕਦਮਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਪਰ ਇਸਦੀਆਂ ਟ੍ਰੈਕਿੰਗ ਦਾ ਰਿਕਾਰਡ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਕਿ activation ਵਿੱਚ ਅਚਾਨਕ ਬਦਲਾਅ ਆਸਾਨੀ ਨਾਲ ਸਮਝ ਆ ਸਕੇ।