Kundlivscykel (serversida)
Skicka uppspelningslänken till ActiveCampaign, Mailchimp, Iterable eller Klaviyo från vår server så snart en session får ditt eget kund-ID.
1. Varför den finns utöver webbläsarbryggan
MousePlayer har redan en kundlivscykelbrygga som skriver till SDK:t på din egen sida: Klaviyo, Braze, Customer.io och sex andra. Den här gör samma sak från vår server i stället. Den behövs eftersom webbläsarvägen helt enkelt saknas för två av de största plattformarna:
- ActiveCampaign saknar helt webbläsar-API för händelser. Dess
vgo()kan ange ett konto och en e-postadress och starta spårning, men kan inte skicka en händelse. Händelser går via Event Tracking API med en separat händelsenyckel, enbart på serversidan. - Mailchimp har ett sådant API, men med en låst uppsättning namn. Dess webbplatspixel accepterar
PAGE_VIEWED,PRODUCT_VIEWED,PURCHASEDoch några andra fördefinierade namn. Det finns ingen plats för en anpassad händelse. Att pressa in våra data i enPAGE_VIEWEDskulle göra din egen datamodell missvisande.
För Iterable och Klaviyo är servervägen helt enkelt mer tillförlitlig: ingen annonsblockerare, inget SDK som kanske har laddats och ingen flik som stängs för tidigt.
2. Vad som behövs
Tre fält. Vilka du fyller i beror på plattformen.
| Plattform | Kontofält | Nyckel |
|---|---|---|
| ActiveCampaign | actid | Webbplats → Webbplatsspårning, bredvid händelsenyckeln |
| Mailchimp | Målgruppens ID | En API-nyckel. Behåll suffixet av typen -us14, eftersom det anger datacentret |
| Iterable | behövs inte, lämna tomt | En nyckel med behörigheten ”Tillåt anrop för händelsespårning” |
| Klaviyo | behövs inte, lämna tomt | En privat API-nyckel |
Det tredje fältet är händelsenamnet som ska visas. Håll det kort: högst 32 tecken. Det är API-gränsen, inte vår. Vi kortar namnet när du sparar, inte när vi skickar. Annars skulle formuläret visa något annat än det som kommer fram.
Mailchimp: behåll API-nyckelns suffix. Delen efter det sista bindestrecket (-us14) anger datacentret där kontot finns och används för att bygga adressen. En nyckel utan den avvisas med ett tydligt meddelande i stället för att misslyckas någonstans där du inte ser det.
3. När den utlöses och när den inte gör det
När en session identifieras: när webbplatsen anropar MousePlayer.setUserId(), när vår analysbrygga läser tillbaka ett unikt ID eller när din server anropar identify-slutpunkten. Innan dess vet vi inte vem inspelningen tillhör.
Bara med en e-postadress
Alla fyra plattformar identifierar kontakter via e-postadress. Om ditt kund-ID är ett avtalsnummer skickas inget. Att köa ett uppdrag som bara kan misslyckas skulle enbart fylla loggen med brus.
Kontakten måste redan finnas. Ingen av plattformarna skapar en kontakt från en händelse. ActiveCampaign kastar hela händelsen om adressen inte känns igen. Bryggan berikar dina befintliga kontakter, den bygger inte din lista.
Varje händelse har ett ID
Därför kan samma session inte räknas två gånger, även om ett uppdrag görs om.
4. Vad som kommer fram
En händelse med uppspelningslänken i en egenskap som heter mouseplayer_session_url. Öppna den så kommer du till inspelningen av exakt den sessionen.
Därefter tar plattformens egen logik över: använd händelsen som automationsutlösare eller segmentvillkor eller låt helt enkelt teamet öppna inspelningen från kontakten.
Nyckeln lämnar aldrig vår server
Den lagras krypterad med AES-256-GCM, visas aldrig igen efter att den sparats och läggs avsiktligt inte i den interna kön som bär uppdraget. Arbetarprocessen hämtar den själv från databasen.
HTTP 200 betyder inte levererat
ActiveCampaign svarar med status 200 och {"success":0} när en händelse avvisas. Vi läser svarskroppen, inte bara statusen. Därför visas ett avvisande som ett fel i leveransloggen och inte som en tyst framgång.
5. Braze, Customer.io och Brevo
Ytterligare tre plattformar på serversidan. Två av dem behöver något som de andra inte kräver: en plats.
| Du anger | Identifieras med | |
|---|---|---|
| Braze | REST-slutpunkt och API-nyckel | e-postadress |
| Customer.io | webbplats-ID, API-nyckel och din region | ditt eget kund-ID |
| Brevo | enbart spårningsnyckeln | e-postadress |
Två av dem finns på en specifik plats
Braze använder instansbundna REST-slutpunkter. Customer.io har två separata regioner med olika värdar. Ingendera kan utläsas ur nyckeln, och fel val ger 401, vilket får dig att felsöka nyckeln. Fälten finns enbart av det skälet.
Customer.io behöver ingen e-postadress
Plattformen känner personerna via samma ID som du tilldelar dem. Ett krav på e-postadress skulle därför vara ett påhittat hinder. De andra sex matchar däremot via e-post. För dem ger en session identifierad med avtalsnummer ingenting, precis som den ska.
Inga nya profiler
Braze-anropet innehåller _update_existing_only. Samma beslut som för CRM-bryggan: en webbläsarsession är ingen tillförlitlig källa till vilka dina kunder är. En kundlivscykelplattform som skapar en profil per anonym besökare är sämre än ingen integration alls.
Brevo svarar 204, Braze svarar 201 med en hake
Brevo returnerar inget innehåll alls. Där är en 2xx-status verkligen hela sanningen. Braze returnerar "message": "success" och kan ha listan errors bredvid: allvarliga problem visas i meddelandet och tolererade förluster av fält bara i errors. Att bara läsa den ena ger fel åt ena eller andra hållet.
Alla nämnda varumärken tillhör respektive ägare. MousePlayer har ingen affärsrelation med leverantörerna.