ಲೈಫ್‌ಸೈಕಲ್ (ಸರ್ವರ್ ಭಾಗದಲ್ಲಿ)

ಸೆಷನ್‌ಗೆ ನಿಮ್ಮ ಸ್ವಂತ ಗ್ರಾಹಕರ ID ಸಿಕ್ಕ ಕ್ಷಣವೇ ನಮ್ಮ ಸರ್ವರ್‌ನಿಂದ ActiveCampaign, Mailchimp, Iterable ಅಥವಾ Klaviyo ಗೆ ಮರುಪ್ಲೇ ಲಿಂಕ್ ಕಳುಹಿಸಿ.

1. ಬ್ರೌಸರ್ ಬ್ರಿಡ್ಜ್ ಜೊತೆಗೆ ಇದು ಏಕೆ ಇದೆ

ನಿಮ್ಮ ಪುಟದ SDK ಗೆ ಬರೆಯುವ ಲೈಫ್‌ಸೈಕಲ್ ಬ್ರಿಡ್ಜ್ MousePlayer ನಲ್ಲಿ ಈಗಾಗಲೇ ಇದೆ — 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(), ನಮ್ಮ ವಿಶ್ಲೇಷಣಾ ಬ್ರಿಡ್ಜ್ ವಿಶಿಷ್ಟ 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 ಈ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ವ್ಯಾಪಾರ ಸಂಬಂಧ ಹೊಂದಿಲ್ಲ.