Lifecycle (serverseitig)

Schieben Sie den Link zur Aufzeichnung von unserem Server nach ActiveCampaign, Mailchimp, Iterable oder Klaviyo - sobald eine Sitzung Ihre eigene Kundenkennung bekommt.

1. Warum es das neben der Browser-Brücke gibt

MousePlayer hat bereits eine Lifecycle-Brücke, die in das SDK auf Ihrer eigenen Seite schreibt - Klaviyo, Braze, Customer.io und sechs weitere. Diese hier tut dasselbe von unserem Server aus, und es gibt sie, weil der Weg über den Browser bei zwei der größten Plattformen schlicht nicht existiert:

  • ActiveCampaign hat gar keine Browser-API für Ereignisse. Sein vgo() kann ein Konto und eine E-Mail-Adresse setzen und das Tracking starten - senden kann es nicht. Ereignisse laufen über die Event-Tracking-API mit einem eigenen Event Key, ausschließlich serverseitig.
  • Mailchimp hat eine, aber mit geschlossenem Vokabular. Sein Site-Tracking-Pixel nimmt PAGE_VIEWED, PRODUCT_VIEWED, PURCHASED und eine Handvoll weiterer vorgegebener Namen. Für ein eigenes Ereignis ist kein Platz vorgesehen, und unsere Daten in ein PAGE_VIEWED zu pressen wäre eine Notlüge in Ihrem eigenen Datenmodell.

Bei Iterable und Klaviyo ist der Serverweg einfach der verlässlichere: kein Adblocker, kein SDK, das geladen sein kann oder nicht, kein früh geschlossener Tab.

2. Was es braucht

Drei Felder, und welche davon Sie ausfüllen, hängt von der Plattform ab.

PlattformKonto-FeldSchlüssel
ActiveCampaignactidWebsite → Site Tracking, neben dem Event Key
MailchimpDie Listen-IDEin API-Schlüssel - behalten Sie die Endung der Art -us14, daraus lesen wir das Rechenzentrum
Iterablenicht nötig - lassen Sie es leerEin Schlüssel mit dem Recht "Allow event track calls"
Klaviyonicht nötig - lassen Sie es leerEin privater API-Schlüssel

Das dritte Feld ist der Ereignisname, unter dem das drüben erscheint. Halten Sie ihn kurz: höchstens 32 Zeichen. Das ist die Grenze der API und nicht unsere, und wir kürzen ihn beim Speichern statt beim Senden - sonst zeigte das Formular etwas anderes an, als ankommt.

Mailchimp: behalten Sie die Endung Ihres API-Schlüssels. Der Teil hinter dem letzten Bindestrich (-us14) benennt das Rechenzentrum Ihres Kontos, und daraus wird die Adresse gebaut. Ein Schlüssel ohne diese Endung wird mit einer klaren Meldung abgelehnt, statt irgendwo zu scheitern, wo Sie es nicht sehen.

3. Wann es feuert - und wann nicht

In dem Augenblick, in dem eine Sitzung erkannt wird: wenn Ihre Seite MousePlayer.setUserId() aufruft, wenn unsere Analytics-Brücke eine Kennung zurückliest, oder wenn Ihr Server den Identify-Endpunkt aufruft. Vorher wissen wir nicht, wem die Aufzeichnung gehört.

Nur mit einer E-Mail-Adresse

Alle vier Plattformen sprechen einen Kontakt über seine E-Mail an. Ist Ihre Kundenkennung eine Vertragsnummer, wird nichts gesendet - eine Aufgabe einzureihen, die nur scheitern kann, füllte bloß Ihr Protokoll.

Der Kontakt muss schon existieren. Keine dieser Plattformen legt aus einem Ereignis einen an; ActiveCampaign verwirft das Ereignis vollständig, wenn es die Adresse nicht kennt. Diese Brücke reichert Ihre vorhandenen Kontakte an - sie baut Ihre Liste nicht auf.

Jedes Ereignis trägt eine Kennung

Damit dieselbe Sitzung nicht zweimal zählt, auch wenn eine Aufgabe wiederholt wird.

4. Was drüben ankommt

Ein Ereignis, das den Link zur Aufzeichnung als Eigenschaft mouseplayer_session_url trägt. Ein Klick darauf, und Sie sind in der Aufzeichnung genau dieser Sitzung.

Alles Weitere ist die Logik Ihrer Plattform: das Ereignis als Auslöser einer Automatisierung, als Segmentbedingung, oder schlicht als Weg für Ihr Team, die Aufzeichnung vom Kontakt aus zu öffnen.

Der Schlüssel verlässt unseren Server nicht

Er wird AES-256-GCM verschlüsselt gespeichert, nach dem Speichern nie wieder angezeigt, und er wandert bewusst nicht in die interne Warteschlange, die die Aufgabe trägt - der Worker holt ihn selbst aus der Datenbank.

HTTP 200 heißt nicht zugestellt

ActiveCampaign antwortet mit Status 200 und {"success":0}, wenn es ein Ereignis ablehnt. Wir lesen den Antwortrumpf und nicht nur den Status - eine Ablehnung erscheint deshalb als Fehlschlag im Zustellprotokoll und nicht als stiller Erfolg.

5. Braze, Customer.io und Brevo

Drei weitere Plattformen auf dem serverseitigen Weg. Zwei davon brauchen etwas, das die übrigen nicht brauchen: einen Ort.

Sie hinterlegenErkannt über
BrazeREST-Endpunkt und API-SchlüsselE-Mail-Adresse
Customer.ioSite-ID, API-Schlüssel und Ihre RegionIhre eigene Kundenkennung
Brevoden Tracker-Schlüssel, sonst nichtsE-Mail-Adresse

Zwei davon leben an einem bestimmten Ort

Braze betreibt instanzgebundene REST-Endpunkte, Customer.io zwei getrennte Regionen mit verschiedenen Hosts. Keines von beidem lässt sich aus dem Schlüssel ableiten, und die falsche Wahl antwortet mit 401 - was einen beim Schlüssel suchen lässt. Allein deshalb gibt es beide Felder.

Customer.io ist das eine, das keine E-Mail braucht

Es kennt seine Leute unter derselben Kennung, die Sie vergeben; eine E-Mail-Pflicht wäre dort eine erfundene Hürde. Die anderen sechs ordnen über die E-Mail zu, und für sie ergibt eine Sitzung, die über eine Vertragsnummer identifiziert wurde, nichts - zu Recht.

Keine neuen Profile

Der Braze-Aufruf trägt _update_existing_only. Dieselbe Entscheidung wie bei der CRM-Brücke: eine Browsersitzung ist keine verlässliche Auskunft darüber, wer Ihre Kunden sind, und eine Lifecycle-Plattform, die je anonymem Besucher ein Profil bekommt, ist schlechter als gar keine Anbindung.

Brevo antwortet mit 204, Braze mit 201 und einem Haken

Brevo gibt überhaupt keinen Rumpf zurück - dort ist ein 2xx wirklich die ganze Wahrheit. Braze gibt "message": "success" zurück und kann daneben ein errors-Feld führen: Fatales steht in message, hingenommene Feldverluste nur in errors. Wer nur eines von beiden liest, irrt in die eine oder die andere Richtung.

Alle genannten Marken gehören ihren jeweiligen Inhabern. MousePlayer steht in keiner geschäftlichen Verbindung zu diesen Anbietern.