Browser-Ereignisse (POST /ct)
Browser-Ereignisse sendet das SDK automatisch oder Sie selbst über scanova('track', ...). Sie stehen für Aktionen, die im Browser des Nutzers stattfinden.
Felder, die Sie senden können
Felder des Objekts
device:
Beispiel für die Nutzdaten eines Browser-Ereignisses
Server-Ereignisse (POST /server-events)
Server-Ereignisse senden Sie mit einem API-Schlüssel aus Ihrem Backend. Sie stehen für Aktionen auf Ihrem Server, etwa abgeschlossene Käufe, bestätigte Registrierungen oder im CRM angelegte Leads.
Felder, die Sie senden können
Felder des Objekts
user_identifiers (alle gehasht):
Beispiel für die Nutzdaten eines Server-Ereignisses
Konventionen für Ereignisnamen
Verwenden Sie einheitliche, sprechende Namen insnake_case. Ein klares Schema macht Berichte leichter lesbar.
Idempotenz
Browser- wie Server-Ereignisse unterstützen für die Dublettenerkennung ein Feldevent_id:
- Trifft dieselbe
event_idmehrfach ein, wird die Dublette gespeichert, aber mitis_duplicate = 1markiert - Dubletten bleiben in den Auswertungen automatisch außen vor
- Verwenden Sie beim Wiederholen eines fehlgeschlagenen Server-Ereignisses immer dieselbe
event_id
Datenschutz und DSGVO
- Senden Sie niemals E-Mail-Adressen im Klartext in
metadataoderproperties. Nutzen Sieuser_identifiersmit gehashten Werten. - Das Feld
consentsteuert, wie die Verarbeitung mit personenbezogenen Daten umgeht:granted— alle Felder werden normal gespeichertdeniedoderpending—page_url,referrer,cityundmetadatawerden vor dem Speichern entfernt- Der Wert von
consentselbst wird als Nachweis immer gespeichert
Die Einwilligung aus dem Browser senden
Das Browser-SDK hat keine eingebaute Schnittstelle für Einwilligungen. Empfohlen ist, das SDK nur bedingt zu laden — je nach Entscheidung Ihrer Einwilligungsverwaltung:Die Einwilligung vom Server senden
Bei Server-Ereignissen schicken Sie den Wertconsent in den Nutzdaten jeder Anfrage neben Ihren übrigen Feldern mit.