लाइफसायकल (सर्व्हरवर)

1. ब्राउझर ब्रिजसोबत हा का

पृष्ठावरील SDK मध्ये लिहिणारा लाइफसायकल ब्रिज आधीच आहे — Klaviyo, Braze, Customer.io आणि इतर सहा. हाच प्रकार सर्व्हरवरून; दोन मोठ्या प्लॅटफॉर्मवर ब्राउझर मार्ग उपलब्धच नाही:

ActiveCampaign कडे घटनांसाठी ब्राउझर API नाही. त्याचे vgo() खाते आणि ईमेल ठरवून मागोवा सुरू करू शकते, घटना पाठवू शकत नाही. घटना वेगळ्या event key सह Event Tracking API मधून फक्त सर्व्हरवरून जातात.
Mailchimp कडे आहे, पण ठरावीक शब्दसंच. साइट ट्रॅकिंग पिक्सेल स्वीकारतो: PAGE_VIEWED, PRODUCT_VIEWED, PURCHASED आणि काही इतर निश्चित नावे. सानुकूल घटनेची जागा नाही; आमचा डेटा पुढीलमध्ये कोंबणे: PAGE_VIEWED म्हणजे स्वतःच्या डेटा मॉडेलमध्ये खोटे सांगणे.

Iterable आणि Klaviyo साठी सर्व्हर मार्ग अधिक विश्वासार्ह: जाहिरात ब्लॉकर नाही, लोड झाला नसेल असा SDK नाही, टॅब आधी बंद होण्याचा प्रश्न नाही.

2. काय आवश्यक

तीन फील्ड; कोणते भरायचे ते प्लॅटफॉर्मनुसार.

प्लॅटफॉर्म	खाते फील्ड	की
ActiveCampaign	`actid`	वेबसाइट → साइट ट्रॅकिंग, event key जवळ
Mailchimp	प्रेक्षकसमूह ID	API की — तिचा पुढीलसारखा शेवट ठेवा: `-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

सर्व्हर मार्गावरील आणखी तीन प्लॅटफॉर्म. दोघांना इतरांपेक्षा वेगळे ठिकाण लागते.

	तुम्ही देता	ओळखीचा आधार
Braze	REST एंडपॉइंट आणि 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 : गंभीर समस्या संदेशात, सहन केलेली फील्ड गळती फक्त errors मध्ये. एकच वाचल्यास कोणत्या ना कोणत्या दिशेने चूक होते.

सर्व ट्रेडमार्क संबंधित मालकांचे आहेत. MousePlayer चे या प्रदात्यांशी व्यावसायिक संबंध नाहीत.

आम्ही कशी मदत करू शकतो?