ਜੀਵਨ-ਚੱਕਰ (ਸਰਵਰ ਪਾਸੇ)

ਸੈਸ਼ਨ ਨੂੰ ਆਪਣੀ ਗਾਹਕ ID ਮਿਲਦਿਆਂ ਹੀ ਸਾਡੇ ਸਰਵਰ ਤੋਂ ਰਿਕਾਰਡਿੰਗ ਲਿੰਕ ActiveCampaign, Mailchimp, Iterable ਜਾਂ Klaviyo ਵਿੱਚ ਭੇਜੋ।

1. ਬ੍ਰਾਊਜ਼ਰ ਪੁਲ ਦੇ ਨਾਲ ਇਹ ਕਿਉਂ ਹੈ

MousePlayer ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਸਫ਼ੇ ਦੇ SDK ਵਿੱਚ ਲਿਖਣ ਵਾਲਾ ਜੀਵਨ-ਚੱਕਰ ਪੁਲ ਹੈ — Klaviyo, Braze, Customer.io ਅਤੇ ਹੋਰ ਛੇ। ਇਹ ਉਹੀ ਕੰਮ ਸਾਡੇ ਸਰਵਰ ਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਦੋ ਸਭ ਤੋਂ ਵੱਡੇ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਰਸਤਾ ਹੈ ਹੀ ਨਹੀਂ:

  • ActiveCampaign ਕੋਲ ਇਵੈਂਟਾਂ ਲਈ ਬ੍ਰਾਊਜ਼ਰ API ਹੀ ਨਹੀਂ। ਉਸ ਦਾ vgo() ਖਾਤਾ ਅਤੇ ਈਮੇਲ ਪਤਾ ਸੈੱਟ ਕਰਕੇ ਟਰੈਕਿੰਗ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ — ਇਵੈਂਟ ਨਹੀਂ ਭੇਜ ਸਕਦਾ। ਇਵੈਂਟ ਵੱਖਰੀ ਇਵੈਂਟ ਕੁੰਜੀ ਵਾਲੇ Event Tracking API ਰਾਹੀਂ ਜਾਂਦੇ ਹਨ, ਸਿਰਫ਼ ਸਰਵਰ ਪਾਸੇ।
  • Mailchimp ਕੋਲ ਹੈ, ਪਰ ਸੀਮਿਤ ਸ਼ਬਦਾਵਲੀ ਨਾਲ। ਉਸ ਦਾ ਸਾਈਟ ਟਰੈਕਿੰਗ ਪਿਕਸਲ ਇਹ ਮੰਨਦਾ ਹੈ: PAGE_VIEWED, PRODUCT_VIEWED, PURCHASED ਅਤੇ ਕੁਝ ਹੋਰ ਪਹਿਲਾਂ ਤੈਅ ਨਾਮ। ਆਪਣੇ ਇਵੈਂਟ ਲਈ ਥਾਂ ਨਹੀਂ ਅਤੇ ਸਾਡਾ ਡਾਟਾ ਇਸ ਵਿੱਚ ਜ਼ਬਰਦਸਤੀ ਪਾਉਣਾ, PAGE_VIEWED ਤੁਹਾਡੇ ਆਪਣੇ ਡਾਟਾ ਮਾਡਲ ਵਿੱਚ ਝੂਠ ਹੋਵੇਗਾ।

Iterable ਅਤੇ Klaviyo ਲਈ ਸਰਵਰ ਰਸਤਾ ਸਿਰਫ਼ ਵੱਧ ਭਰੋਸੇਯੋਗ ਹੈ: ਨਾ ਇਸ਼ਤਿਹਾਰ ਬਲੌਕਰ, ਨਾ ਸ਼ਾਇਦ ਲੋਡ ਹੋਇਆ SDK, ਨਾ ਟੈਬ ਜਲਦੀ ਬੰਦ ਹੋਣਾ।

2. ਕੀ ਚਾਹੀਦਾ ਹੈ

ਤਿੰਨ ਖੇਤਰ ਅਤੇ ਕਿਹੜੇ ਭਰਣੇ ਹਨ ਇਹ ਪਲੇਟਫਾਰਮ ਉੱਤੇ ਨਿਰਭਰ ਹੈ।

ਪਲੇਟਫਾਰਮਖਾਤਾ ਖੇਤਰਕੁੰਜੀ
ActiveCampaignactidWebsite → Site Tracking, ਇਵੈਂਟ ਕੁੰਜੀ ਦੇ ਨਾਲ
Mailchimpਔਡੀਅੰਸ IDAPI ਕੁੰਜੀ — ਇਸ ਦਾ ਪਿਛੇਤਰ ਰੱਖੋ, -us14 ਇਸ ਕਿਸਮ ਦਾ; ਡਾਟਾ ਸੈਂਟਰ ਇਸ ਤੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ
Iterableਲੋੜ ਨਹੀਂ — ਖਾਲੀ ਛੱਡੋ“Allow event track calls” ਇਜਾਜ਼ਤ ਵਾਲੀ ਕੁੰਜੀ
Klaviyoਲੋੜ ਨਹੀਂ — ਖਾਲੀ ਛੱਡੋਇੱਕ ਨਿੱਜੀ API ਕੁੰਜੀ

ਤੀਜਾ ਖੇਤਰ ਉਹ ਇਵੈਂਟ ਨਾਮ ਹੈ ਜਿਸ ਹੇਠ ਇਹ ਦਿਸੇਗਾ। ਛੋਟਾ ਰੱਖੋ: ਵੱਧ ਤੋਂ ਵੱਧ 32 ਅੱਖਰ। ਇਹ API ਦੀ ਹੱਦ ਹੈ, ਸਾਡੀ ਨਹੀਂ ਅਤੇ ਅਸੀਂ ਭੇਜਣ ਵੇਲੇ ਦੀ ਥਾਂ ਸੰਭਾਲਣ ਵੇਲੇ ਛੋਟਾ ਕਰਦੇ ਹਾਂ — ਨਹੀਂ ਤਾਂ ਫਾਰਮ ਪਹੁੰਚਦੇ ਮੁੱਲ ਤੋਂ ਵੱਖਰਾ ਦਿਖਾਏਗਾ।

Mailchimp: API ਕੁੰਜੀ ਦਾ ਪਿਛੇਤਰ ਰੱਖੋ। ਆਖ਼ਰੀ ਡੈਸ਼ ਤੋਂ ਬਾਅਦਲਾ ਹਿੱਸਾ (-us14) ਖਾਤੇ ਦੇ ਡਾਟਾ ਸੈਂਟਰ ਦਾ ਨਾਮ ਹੈ ਅਤੇ ਪਤਾ ਇਸ ਤੋਂ ਬਣਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਕੁੰਜੀ ਅਜਿਹੀ ਥਾਂ ਨਾਕਾਮ ਹੋਣ ਦੀ ਥਾਂ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਨਾਲ ਰੱਦ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਨਾ ਵੇਖ ਸਕੋ।

3. ਕਦੋਂ ਚੱਲਦਾ ਹੈ — ਅਤੇ ਕਦੋਂ ਨਹੀਂ

ਸੈਸ਼ਨ ਦੀ ਪਛਾਣ ਹੋਣ ਵੇਲੇ: ਜਦੋਂ ਸਾਈਟ ਇਹ ਕਾਲ ਕਰਦੀ ਹੈ: MousePlayer.setUserId(), ਜਦੋਂ ਸਾਡਾ ਵਿਸ਼ਲੇਸ਼ਣ ਪੁਲ distinct ID ਵਾਪਸ ਪੜ੍ਹਦਾ ਹੈ ਜਾਂ ਜਦੋਂ ਤੁਹਾਡਾ ਸਰਵਰ identify ਐਂਡਪੁਆਇੰਟ ਕਾਲ ਕਰਦਾ ਹੈ। ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਸਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਰਿਕਾਰਡਿੰਗ ਕਿਸ ਦੀ ਹੈ।

ਸਿਰਫ਼ ਈਮੇਲ ਪਤੇ ਨਾਲ

ਚਾਰੇ ਪਲੇਟਫਾਰਮ ਸੰਪਰਕ ਨੂੰ ਈਮੇਲ ਨਾਲ ਲੱਭਦੇ ਹਨ। ਗਾਹਕ ID ਇਕਰਾਰਨਾਮਾ ਨੰਬਰ ਹੋਵੇ ਤਾਂ ਕੁਝ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ — ਸਿਰਫ਼ ਨਾਕਾਮ ਹੋ ਸਕਣ ਵਾਲਾ ਕੰਮ ਕਤਾਰ ਵਿੱਚ ਪਾਉਣਾ ਲੌਗ ਵਿੱਚ ਸ਼ੋਰ ਹੀ ਭਰੇਗਾ।

ਸੰਪਰਕ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਈ ਪਲੇਟਫਾਰਮ ਇਵੈਂਟ ਤੋਂ ਸੰਪਰਕ ਨਹੀਂ ਬਣਾਉਂਦਾ; ActiveCampaign ਪਤਾ ਨਾ ਪਛਾਣੇ ਤਾਂ ਇਵੈਂਟ ਪੂਰਾ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਇਹ ਪੁਲ ਮੌਜੂਦਾ ਸੰਪਰਕ ਸੰਮ੍ਰਿੱਧ ਕਰਦਾ ਹੈ — ਤੁਹਾਡੀ ਸੂਚੀ ਨਹੀਂ ਬਣਾਉਂਦਾ।

ਹਰ ਇਵੈਂਟ ਕੋਲ ID ਹੁੰਦੀ ਹੈ

ਤਾਂ ਜੋ ਕੰਮ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਹੋਣ ਉੱਤੇ ਵੀ ਉਹੀ ਸੈਸ਼ਨ ਦੋ ਵਾਰ ਨਾ ਗਿਣਿਆ ਜਾਵੇ।

4. ਦੂਜੇ ਪਾਸੇ ਕੀ ਪਹੁੰਚਦਾ ਹੈ

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

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

ਕੁੰਜੀ ਸਾਡੇ ਸਰਵਰ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦੀ

AES-256-GCM ਨਾਲ ਇਨਕ੍ਰਿਪਟ ਸੰਭਾਲੀ ਜਾਂਦੀ ਹੈ, ਸੰਭਾਲਣ ਤੋਂ ਬਾਅਦ ਕਦੇ ਮੁੜ ਨਹੀਂ ਦਿਸਦੀ ਅਤੇ ਕੰਮ ਲੈ ਜਾਣ ਵਾਲੀ ਅੰਦਰੂਨੀ ਕਤਾਰ ਵਿੱਚ ਜਾਣਬੁੱਝ ਕੇ ਨਹੀਂ ਪਾਈ ਜਾਂਦੀ — ਵਰਕਰ ਖੁਦ ਡਾਟਾਬੇਸ ਤੋਂ ਲੈਂਦਾ ਹੈ।

HTTP 200 ਦਾ ਮਤਲਬ ਪਹੁੰਚਿਆ ਨਹੀਂ

ActiveCampaign ਇਵੈਂਟ ਰੱਦ ਕਰੇ ਤਾਂ 200 ਸਥਿਤੀ ਅਤੇ ਇਹ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: {"success":0} । ਅਸੀਂ ਸਿਰਫ਼ ਸਥਿਤੀ ਨਹੀਂ, ਮੁੱਖ ਜਵਾਬ ਪੜ੍ਹਦੇ ਹਾਂ, ਇਸ ਲਈ ਇਨਕਾਰ ਡਿਲਿਵਰੀ ਲੌਗ ਵਿੱਚ ਨਾਕਾਮੀ ਵਜੋਂ ਆਉਂਦਾ ਹੈ, ਚੁੱਪ ਸਫਲਤਾ ਨਹੀਂ।

5. Braze, Customer.io ਅਤੇ Brevo

ਸਰਵਰ ਪਾਸੇ ਦੇ ਰਸਤੇ ਉੱਤੇ ਤਿੰਨ ਹੋਰ ਪਲੇਟਫਾਰਮ। ਦੋ ਨੂੰ ਕੁਝ ਅਜਿਹਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਹੋਰਾਂ ਨੂੰ ਨਹੀਂ: ਇੱਕ ਥਾਂ।

ਤੁਸੀਂ ਦਿੰਦੇ ਹੋਇਸ ਨਾਲ ਪਛਾਣ
BrazeREST ਐਂਡਪੁਆਇੰਟ ਅਤੇ API ਕੁੰਜੀਈਮੇਲ ਪਤਾ
Customer.ioਸਾਈਟ ID, API ਕੁੰਜੀ ਅਤੇ ਤੁਹਾਡਾ ਖੇਤਰਤੁਹਾਡੀ ਆਪਣੀ ਗਾਹਕ ID
Brevoਸਿਰਫ਼ ਟਰੈਕਰ ਕੁੰਜੀ, ਹੋਰ ਕੁਝ ਨਹੀਂਈਮੇਲ ਪਤਾ

ਦੋ ਖ਼ਾਸ ਥਾਂ ਉੱਤੇ ਰਹਿੰਦੇ ਹਨ

Braze ਇੰਸਟੈਂਸ ਨਾਲ ਬੱਝੇ REST ਐਂਡਪੁਆਇੰਟ ਚਲਾਉਂਦਾ ਹੈ; Customer.io ਵੱਖਰੇ ਹੋਸਟਾਂ ਵਾਲੇ ਦੋ ਖੇਤਰ ਚਲਾਉਂਦਾ ਹੈ। ਕੋਈ ਵੀ ਕੁੰਜੀ ਤੋਂ ਨਹੀਂ ਨਿਕਲਦਾ ਅਤੇ ਗਲਤ ਵਾਲਾ 401 ਦਿੰਦਾ ਹੈ — ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਕੁੰਜੀ ਜਾਂਚਣ ਲੱਗਦੇ ਹੋ। ਦੋਵੇਂ ਖੇਤਰ ਸਿਰਫ਼ ਇਸੇ ਕਾਰਨ ਹਨ।

Customer.io ਨੂੰ ਈਮੇਲ ਨਹੀਂ ਚਾਹੀਦੀ

ਇਹ ਲੋਕਾਂ ਨੂੰ ਤੁਹਾਡੀ ਦਿੱਤੀ ਉਸੇ ID ਨਾਲ ਜਾਣਦਾ ਹੈ, ਇਸ ਲਈ ਈਮੇਲ ਲਾਜ਼ਮੀ ਕਰਨਾ ਘੜੀ ਰੁਕਾਵਟ ਹੋਵੇਗੀ। ਬਾਕੀ ਛੇ ਈਮੇਲ ਨਾਲ ਮੇਲ ਕਰਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਲਈ ਇਕਰਾਰਨਾਮਾ ਨੰਬਰ ਨਾਲ ਪਛਾਣਿਆ ਸੈਸ਼ਨ ਕੁਝ ਨਹੀਂ ਬਣਾਉਂਦਾ — ਸਹੀ ਤਰ੍ਹਾਂ।

ਨਵੀਆਂ ਪ੍ਰੋਫਾਈਲਾਂ ਨਹੀਂ

Braze ਕਾਲ ਇਹ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ: _update_existing_only। CRM ਪੁਲ ਵਾਲਾ ਉਹੀ ਫ਼ੈਸਲਾ: ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਤੁਹਾਡੇ ਗਾਹਕ ਕੌਣ ਹਨ ਇਸ ਦਾ ਭਰੋਸੇਯੋਗ ਬਿਆਨ ਨਹੀਂ ਅਤੇ ਹਰ ਅਗਿਆਤ ਵਿਜ਼ਟਰ ਲਈ ਪ੍ਰੋਫਾਈਲ ਵਧਾਉਂਦਾ ਜੀਵਨ-ਚੱਕਰ ਪਲੇਟਫਾਰਮ ਬਿਨਾਂ ਏਕੀਕਰਨ ਨਾਲੋਂ ਮਾੜਾ ਹੈ।

Brevo 204 ਦਿੰਦਾ ਹੈ, Braze 201 ਪਰ ਇੱਕ ਪੇਚ ਨਾਲ

Brevo ਕੋਈ ਮੁੱਖ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ — ਉੱਥੇ 2xx ਹੀ ਪੂਰੀ ਸੱਚਾਈ ਹੈ। Braze ਇਹ ਦਿੰਦਾ ਹੈ: "message": "success" ਅਤੇ ਨਾਲ ਇਹ ਐਰੇ ਹੋ ਸਕਦਾ ਹੈ: errors : ਘਾਤਕ ਸਮੱਸਿਆਵਾਂ message ਵਿੱਚ, ਬਰਦਾਸ਼ਤ ਕੀਤੀਆਂ ਖੇਤਰ ਘਾਟਾਂ ਸਿਰਫ਼ errors ਵਿੱਚ। ਇਕੱਲਾ ਕੋਈ ਇੱਕ ਪੜ੍ਹਨਾ ਕਿਸੇ ਨਾ ਕਿਸੇ ਪਾਸੇ ਗਲਤ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ।

ਇੱਥੇ ਦੱਸੇ ਸਾਰੇ ਟ੍ਰੇਡਮਾਰਕ ਆਪਣੇ ਮਾਲਕਾਂ ਦੇ ਹਨ। MousePlayer ਦਾ ਇਨ੍ਹਾਂ ਪ੍ਰਦਾਤਾਵਾਂ ਨਾਲ ਕੋਈ ਵਪਾਰਕ ਸੰਬੰਧ ਨਹੀਂ ਹੈ।