SaaS ਅਤੇ ਉਤਪਾਦ ਟੀਮਾਂ
ਤੁਹਾਡਾ ਉਤਪਾਦ ਅਜਿਹੀਆਂ ਗੱਲਾਂ ਜਾਣਦਾ ਹੈ ਜਿਹਨਾਂ ਨੂੰ ਕੋਈ ਮਾਰਕੀਟਿੰਗ ਟੂਲ ਨਹੀਂ ਵੇਖ ਸਕਦਾ
ਕਿਸ ਨੇ ਆਨਬੋਰਡਿੰਗ ਪੂਰੀ ਕੀਤੀ ਅਤੇ ਕਿਸ ਨੇ ਤੀਜੇ ਕਦਮ 'ਤੇ ਰੁਕ ਗਏ। ਕਿਸ ਨੇ ਸਹਿਕਰਮੀ ਸੱਦਿਆ। ਕਿਸ ਨੇ ਇਸ ਹਫ਼ਤੇ ਦੋ ਵਾਰ ਸੀਮਾ ਨੂੰ ਛੂਹਿਆ। ਕਿਸ ਨੇ ਪੰਦਰਾਂ ਦਿਨਾਂ ਤੋਂ ਚੀਜ਼ ਨਹੀਂ ਖੋਲ੍ਹੀ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ, ਈਮੇਲ ਖੁੱਲ੍ਹਣ ਤੋਂ ਲਏ ਕਿਸੇ ਵੀ ਟ੍ਰਿੱਗਰ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ, ਅਤੇ ਇਹ ਸਾਰੇ ਦੋ ਲਾਈਨਾਂ ਦੇ ਕੋਡ ਦੀ ਦੂਰੀ 'ਤੇ ਹਨ।
ਇਵੈਂਟ ਹੀ ਪੂਰਾ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਹਨ
ਆਪਣੇ ਟੋਕਨ ਨਾਲ POST /v1/events: ਤੁਹਾਡੇ ਚੁਣਿਆ ਨਾਂ, ਇੱਕ ਸੰਪਰਕ, ਇੱਕ ਪੇਲੋਡ, ਇੱਕ ਆਈਡੈਂਪੋਟੈਂਸੀ ਕੁੰਜੀ। ਇਹੀ ਪੂਰਾ ਕਨੈਕਸ਼ਨ ਹੈ। ਕੋਈ SDK ਨਹੀਂ ਜੋ ਤਾਜ਼ਾ ਰੱਖਣਾ ਪਏ, ਕੋਈ ਮੈਪਿੰਗ ਸਕਰੀਨ ਨਹੀਂ, ਅਤੇ ਸਾਡੀ ਕੋਈ ਸ਼ਬਦਾਵਲੀ ਨਹੀਂ ਜਿਸ ਵਿੱਚ ਤੁਹਾਨੂੰ ਆਪਣਾ ਉਤਪਾਦ ਅਨੁਵਾਦ ਕਰਨਾ ਪਵੇ।
ਹਰ ਇਵੈਂਟ ਸੰਪਰਕ ਦੇ ਸਿਰਫ਼-ਜੋੜਨਯੋਗ ਲੌਗ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਉੱਥੋਂ ਇਹ ਇੱਕੋ ਵੇਲੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਹੈ। ਇੱਕ ਟ੍ਰਿੱਗਰ, ਤਾਂ ਜੋ ਇਸਦੇ ਆਉਣ 'ਤੇ ਫਨਲ ਸ਼ੁਰੂ ਹੋਵੇ। ਇੱਕ ਸ਼ਰਤ, ਤਾਂ ਜੋ ਕੋਈ ਸੈਗਮੈਂਟ ਕਹਿ ਸਕੇ "ਪਿਛਲੇ ਚੌਦਾਂ ਦਿਨਾਂ ਵਿੱਚ ਇਹ ਕੀਤਾ" ਜਾਂ, ਹੋਰ ਲਾਭਦਾਇਕ ਤੌਰ 'ਤੇ, "ਨਹੀਂ ਕੀਤਾ"। ਅਤੇ ਇੱਕ ਟੀਚਾ, ਤਾਂ ਜੋ ਲੜੀ ਉਸ ਪਲ ਖਤਮ ਹੋ ਜਾਵੇ ਜਦੋਂ ਕੋਈ ਉਹ ਕੰਮ ਕਰ ਲਵੇ ਜਿਸ ਵੱਲ ਉਸਨੂੰ ਧੱਕਾ ਦਿੱਤਾ ਜਾ ਰਿਹਾ ਸੀ।
ਇਹ ਤੀਜੀ ਚੀਜ਼ ਹੀ ਲਾਈਫ਼ਸਾਈਕਲ ਸੁਨੇਹਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਆਪਣਾ ਖਾਤਾ ਪੂਰਾ ਕਰਨ ਦਾ ਧੱਕਾ ਉਸ ਪਲ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਰਹਿਣਾ ਚਾਹੀਦਾ ਜਦੋਂ ਖਾਤਾ ਬਣ ਜਾਵੇ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਟੂਲਾਂ ਵਿੱਚ ਇਹ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਲੜੀ ਅਤੇ ਉਤਪਾਦ ਆਪਸ ਵਿੱਚ ਗੱਲ ਨਹੀਂ ਕਰਦੇ।
- ⚡ਟ੍ਰਿਗਰ
api_event—signup.completed, ਪਲਾਨfree। - 2ਈਮੇਲ ਭੇਜੋਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਰਨ ਵਾਲੀ ਇੱਕੋ ਚੀਜ਼। ਗਿਆਰਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਦੌਰਾ ਨਹੀਂ।
- 32 ਦਿਨ ਉਡੀਕਰਨ 'ਤੇ
wake_at। ਕੁਝ ਕਤਾਰ ਵਿੱਚ ਨਹੀਂ, ਕੁਝ ਨਹੀਂ ਜੋ ਕੱਲ੍ਹ ਇਸਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ 'ਤੇ ਖੋਲ੍ਹਣਾ ਪਵੇ। - ?ਸ਼ਰਤਕੀ
project.createdਆ ਗਿਆ? ਨਹੀਂ → ਮਦਦ ਸ਼ਾਖਾ। ਹਾਂ → ਹੇਠਾਂ ਦਾ ਟੀਚਾ। - 4ਮਦਦ ਸ਼ਾਖਾਇੱਕ ਸੁਨੇਹਾ, ਜੋ ਉਹ ਖਾਸ ਚੀਜ਼ ਪੇਸ਼ ਕਰੇ ਜੋ ਉਹਨਾਂ ਨੇ ਨਹੀਂ ਕੀਤੀ। ਫਿਰ ਇੱਕ ਹੋਰ ਉਡੀਕ।
- 5ਟੀਚਾ
project.createdਆ ਜਾਂਦਾ ਹੈ। ਰਨ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿਅਕਤੀ ਲਈ ਹੁਣ ਕਦੇ ਵੀ ਕੋਈ ਹੋਰ ਆਨਬੋਰਡਿੰਗ ਮੇਲ ਨਹੀਂ ਜਾਂਦੀ।
ਤੁਹਾਡੇ ਇਵੈਂਟ ਨਾਮਐਕਟੀਵੇਟਿਡ ਦੀ ਤੁਹਾਡੀ ਪਰਿਭਾਸ਼ਾ
ਪੰਜ ਫਨਲ
ਜੀਵਨ-ਚੱਕਰ, ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਿਸ ਵਿੱਚ ਇਹ ਅਸਲ ਵਿੱਚ ਵਾਪਰਦਾ ਹੈ
1 · ਐਕਟੀਵੇਸ਼ਨ
ਟ੍ਰਿੱਗਰ: ਸਾਈਨ-ਅੱਪ। ਦੋ ਜਾਂ ਤਿੰਨ ਸੁਨੇਹੇ, ਹਰ ਇੱਕ ਇੱਕ ਕਾਰਜ ਬਾਰੇ, ਹਰ ਇੱਕ ਦਾ ਇੱਕ ਟੀਚਾ ਜੋ ਉਸ ਕਾਰਜ ਦੇ ਵਾਪਰਨ 'ਤੇ ਲੜੀ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਕੀਮਤੀ ਫਨਲ ਹੈ ਜੋ ਤੁਸੀਂ ਬਣਾਓਗੇ, ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਤਿੰਨ ਵਾਰ ਦੁਬਾਰਾ ਲਿਖਣ ਯੋਗ ਵੀ ਇਹੀ ਹੈ।
2 · ਰੁਕਾਵਟ
ਟ੍ਰਿੱਗਰ: segment_enter — ਸਾਈਨ ਅੱਪ ਕੀਤਾ, ਸੱਤ ਦਿਨਾਂ ਵਿੱਚ ਕੋਈ ਅਰਥਪੂਰਨ ਇਵੈਂਟ ਨਹੀਂ। ਇੱਕ ਸੁਨੇਹਾ ਜੋ ਦੱਸਣ ਦੀ ਬਜਾਏ ਪੁੱਛਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਜੋ ਕੋਈ ਖਾਸ ਚੀਜ਼ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਫਿਰ ਰੁਕ ਜਾਓ। ਜਿਸ ਵਿਅਕਤੀ ਨੇ ਤਿੰਨ ਸੁਨੇਹਿਆਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ ਹੈ ਉਸਨੂੰ ਚੌਥਾ ਸੁਨੇਹਾ ਕਿਸੇ ਨੂੰ ਵੀ ਨਹੀਂ ਪਹੁੰਚਦਾ।
3 · ਵਿਸਤਾਰ ਦਾ ਪਲ
ਟ੍ਰਿੱਗਰ: ਕੋਈ ਇਵੈਂਟ ਜੋ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਮੁੱਲ ਲੈ ਰਹੇ ਹਨ — ਸੀਮਾ 'ਤੇ ਪਹੁੰਚੇ, ਤੀਜੇ ਸਾਥੀ ਨੂੰ ਸੱਦਾ ਭੇਜਿਆ, ਦੂਜੀ ਵਾਰ ਐਕਸਪੋਰਟ ਕੀਤਾ। ਇਹੀ ਇਕਲੌਤਾ ਪਲ ਹੈ ਜਦੋਂ ਅੱਪਗ੍ਰੇਡ ਸੁਨੇਹਾ ਸਵੀਕਾਰਯੋਗ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਪਲ ਹੈ ਜਿਸਦਾ ਨਾਮ ਤੁਹਾਡਾ ਉਤਪਾਦ ਸਹੀ-ਸਹੀ ਦੱਸ ਸਕਦਾ ਹੈ।
4 · ਨਵਿਆਉਣਾ ਅਤੇ ਡਨਿੰਗ
ਟ੍ਰਿੱਗਰ: ਨਵਿਆਉਣੇ ਤੋਂ ਪਹਿਲਾਂ date_field, ਜਾਂ ਕੋਈ ਭੁਗਤਾਨ ਇਵੈਂਟ। ਸੂਚਨਾ, ਰਿਮਾਈਂਡਰ, ਅਤੇ — ਜੇ ਭੁਗਤਾਨ ਅਸਫਲ ਹੁੰਦਾ ਹੈ — ਇੱਕ ਛੋਟੀ ਲੜੀ ਜੋ ਸਫਲ ਹੁੰਦੇ ਹੀ ਉਸੀ ਪਲ ਰੁਕ ਜਾਂਦੀ ਹੈ। ਡਨਿੰਗ ਵਿੱਚ ਟੀਚਾ ਨੋਡ ਵਿਕਲਪਿਕ ਨਹੀਂ ਹੁੰਦੇ; ਇਹੀ ਫ਼ਰਕ ਹੈ ਰਿਮਾਈਂਡਰ ਅਤੇ ਪਰੇਸ਼ਾਨੀ ਵਿੱਚ।
5 · ਵਾਪਸ ਲਿਆਉਣਾ
ਟ੍ਰਿੱਗਰ: segment_enter — ਰੱਦ ਕੀਤਾ ਜਾਂ ਸੱਠ ਦਿਨਾਂ ਤੋਂ ਨਿਸ਼ਕਿਰਿਆ। ਦੋ ਸੁਨੇਹੇ, ਇਮਾਨਦਾਰ ਵਾਲੇ, ਫਿਰ ਇੱਕ ਟੈਗ ਅਤੇ ਚੁੱਪ। ਉਨ੍ਹਾਂ ਦੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਕੀ ਬਦਲਿਆ ਹੈ — ਇਹ ਸੁਨੇਹਾ ਛੂਟ ਤੋਂ ਬਿਹਤਰ ਹੈ।
ਅਤੇ ਅੰਦਰੂਨੀ ਵਾਲਾ
notify_team ਕਿਸੇ ਇਨਸਾਨ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਅਜਿਹਾ ਖਾਤਾ, ਜਿਸ ਵਿੱਚ ਇਨਸਾਨੀ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ, ਕਿਸੇ ਰੇਖਾ ਨੂੰ ਪਾਰ ਕਰ ਜਾਂਦਾ ਹੈ। ਫਨਲ ਦਾ ਅੰਤ ਗਾਹਕ ਨੂੰ ਈਮੇਲ ਨਾਲ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ; ਕਈ ਵਾਰ ਸਹੀ ਕਾਰਵਾਈ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਪਾਸੇ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਦੱਸਿਆ ਜਾਵੇ ਕਿ ਫ਼ੋਨ ਚੁੱਕਣਾ ਹੈ।
ਕੋਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਛੱਡਦਾ ਨਹੀਂ। ਉਹ ਬੱਸ ਇਸਨੂੰ ਖੋਲ੍ਹਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ।
ਇੱਕ ਡਿਵੈਲਪਰ ਨੂੰ ਇਹ ਅਸਲ ਵਿੱਚ ਕਿਉਂ ਪਸੰਦ ਆ ਸਕਦਾ ਹੈ
ਉਹ ਹਿੱਸੇ ਜੋ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ ਜਦੋਂ ਇੰਟੀਗ੍ਰੇਟ ਕਰਨ ਵਾਲਾ ਤੁਸੀਂ ਖੁਦ ਹੋ
ਕੋਈ ਪ੍ਰਾਈਵੇਟ ਐਂਡਪੁਆਇੰਟ ਨਹੀਂ
ਹਰ ਸਕਰੀਨ ਪਬਲਿਕ API ਤੋਂ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਕੋਈ ਹੋਰ ਕਿਸਮ ਹੈ ਹੀ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਐਡਮਿਨ ਵਿੱਚ ਕੈਂਪੇਨ ਰਿਪੋਰਟ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਰਾਹ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਅਤੇ ਕੁਝ ਵੀ ਰਿਵਰਸ-ਇੰਜੀਨੀਅਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ।
ਹਰ ਥਾਂ ਆਈਡੈਂਪੋਟੈਂਸੀ ਕੁੰਜੀਆਂ
ਹਰ ਬਦਲਾਵ ਕਰਨ ਵਾਲੇ ਰੂਟ 'ਤੇ। ਤੁਹਾਡਾ ਰੀਟ੍ਰਾਈ ਲੌਜਿਕ, ਤੁਹਾਡੀ at-least-once ਕਤਾਰ ਅਤੇ ਤੁਹਾਡਾ ਅਸਥਿਰ ਨੈੱਟਵਰਕ ਸਭ ਕਿਸੇ ਹੋਰ ਦੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੇ ਹਨ — ਖਾਸ ਤੌਰ 'ਤੇ, ਇੱਕ ਵਿਲੱਖਣ ਇੰਡੈਕਸ ਦੀ ਸਮੱਸਿਆ।
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਿਮੂਲੇਟ ਕਰੋ
POST /v1/simulate ਇੱਕ ਸੰਪਰਕ ਨੂੰ ਫਨਲ ਵਿੱਚੋਂ ਡ੍ਰਾਈ-ਰਨ ਕਰਦਾ ਹੈ ਅਤੇ ਰਾਹ ਤੇ ਹਰ ਉਹ ਸੁਨੇਹਾ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜੋ ਇਹ ਭੇਜਦਾ। ਚਾਹੋ ਤਾਂ ਇਸਨੂੰ CI ਵਿੱਚ ਪਾ ਦਿਓ: ਫਨਲ ਇੱਕ ਗ੍ਰਾਫ਼ ਹੈ, ਅਤੇ ਗ੍ਰਾਫ਼ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਇੱਕ MCP ਸਰਵਰ
ਕਿਸੇ ਏਜੰਟ ਨੂੰ /mcp 'ਤੇ ਇਸ਼ਾਰਾ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਫਨਲ ਲਿਖਣ ਤੇ ਜਾਂਚਣ ਦਿਓ। ਭੇਜਣ ਦੀ ਸਮਰੱਥਾ ਵਾਲੇ ਟੂਲਾਂ ਲਈ ਸਪਸ਼ਟ ਪੁਸ਼ਟੀਕਰਨ ਲੋੜੀਂਦਾ ਹੈ ਅਤੇ ਉਹ ਕੋਟੇ ਦੇ ਅਧੀਨ ਹਨ, ਤਾਂ ਜੋ ਗਲਤ ਪੜ੍ਹਿਆ ਪ੍ਰੌਂਪਟ ਪੰਜਾਹ ਹਜ਼ਾਰ ਈਮੇਲਾਂ ਵਿੱਚ ਨਾ ਬਦਲ ਜਾਵੇ।
ਵੈੱਬਹੁੱਕ ਬਾਹਰ
ਸਾਈਨ ਕੀਤਾ, ਬੈਕਆਫ਼ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤਾ, ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ। ਉਹੀ ਇਵੈਂਟ ਸ਼ਬਦਾਵਲੀ ਜੋ ਰਿਪੋਰਟਾਂ ਵਰਤਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਵੇਅਰਹਾਊਸ ਅਤੇ ਤੁਹਾਡਾ ਡੈਸ਼ਬੋਰਡ "delivered" ਦੇ ਅਰਥ 'ਤੇ ਇਕਮਤ ਰਹਿਣ।
ਮਿਟਾਉਣਾ ਜੋ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚਦਾ ਹੈ
ਮਿਟਾਉਣ ਦੀ ਬੇਨਤੀ ਸੰਪਰਕ ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਸੁਨੇਹਾ ਇਤਿਹਾਸ ਇੱਥੋਂ ਹਟਾਉਂਦੀ ਹੈ ਅਤੇ ਹਰ ਉਸ ਭਰਾ ਸੇਵਾ ਤੱਕ ਫੈਲਦੀ ਹੈ ਜਿਸ ਕੋਲ ਨਕਲ ਸੀ। ਇੱਕ ਬੇਨਤੀ, ਇੱਕ ਨਤੀਜਾ, ਅਤੇ ਕੁਝ ਜਿਸ 'ਤੇ ਪੁੱਛੇ ਜਾਣ 'ਤੇ ਤੁਸੀਂ ਇਸ਼ਾਰਾ ਕਰ ਸਕੋ।
ਸੀਮਾ ਕਿੱਥੇ ਹੈ
ClickSomo ਕੋਲ ਇੱਕ ਮੇਲਿੰਗ ਲਿਸਟ ਅਤੇ ਉਸ ਲਿਸਟ ਦਾ ਕੀਤਾ ਕੰਮ ਹੁੰਦਾ ਹੈ। ਇਹ ਤੁਹਾਡਾ ਯੂਜ਼ਰ ਡੇਟਾਬੇਸ ਨਹੀਂ ਹੈ ਅਤੇ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਨਹੀਂ ਕਰਦਾ: ਸੰਪਰਕ ਕਦੇ ਕੋਈ ਪ੍ਰਮਾਣ ਨਹੀਂ ਰੱਖਦਾ, ਕਦੇ ਸਾਈਨ ਇਨ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਕਦੇ ਖਾਤਾ ਨਹੀਂ ਬਣਦਾ। ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ; ਸੰਪਰਕ ਇੱਥੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਇੱਕ ਈਮੇਲ ਪਤੇ ਅਤੇ ਉਨ੍ਹਾਂ ਇਵੈਂਟਾਂ ਨਾਲ ਜੁੜਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਭੇਜਣ ਦੀ ਚੋਣ ਕਰਦੇ ਹੋ।
ਇਹ ਵੱਖਰਤਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈ ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਸਹਿਮਤੀ ਮਾਡਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਲਈ ਡੇਟਾ ਕੰਟਰੋਲਰ ਤੁਸੀਂ ਹੋ; ਅਸੀਂ ਤੁਹਾਡੀ ਤਰਫ਼ੋਂ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਾਂ। ਅਜਿਹਾ ਡਿਜ਼ਾਇਨ ਜਿੱਥੇ ਮਾਰਕੀਟਿੰਗ ਟੂਲ ਚੁੱਪਚਾਪ ਪਛਾਣ ਸਟੋਰ ਬਣ ਜਾਵੇ, ਉਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਖੋਲ੍ਹਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਅਤੇ ਇਹੀ ਉਹ ਅਸਫਲਤਾ ਹੈ ਜਿਸਤੋਂ ਬਚਣ ਲਈ ਇਹ ਬਣਾਇਆ ਗਿਆ ਹੈ।
ਵਿਹਾਰਕ ਰੂਪ: ਇਵੈਂਟ ਭੇਜੋ, ਉਹ ਗੁਣ ਭੇਜੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਸੈਗਮੈਂਟ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਉੱਥੇ ਹੀ ਰਹਿਣ ਦਿਓ। ਜੇ ਤੁਸੀਂ ਪਾਉਂਦੇ ਹੋ ਕਿ ਆਪਣੀ ਪੂਰੀ ਸਕੀਮਾ ਇੱਥੇ ਧੱਕ ਰਹੇ ਹੋ, ਤਾਂ ਜਿਹੜਾ ਸੈਗਮੈਂਟ ਤੁਸੀਂ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ, ਸੰਭਵ ਹੈ ਉਹ ਤੁਹਾਡੇ ਆਪਣੇ ਡੇਟਾਬੇਸ ਦੀ ਇੱਕ ਕਿਊਰੀ ਹੈ ਜੋ ਇੱਕ ਬੂਲੀਅਨ ਗੁਣ ਵਜੋਂ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ।