Integration · Destination
Generic webhook
Signierte JSON-Webhooks an deine eigenen Systeme mit Allowlist-Feldern.
So erreichen Events Webhook
Jeder Pfad endet an derselben Stelle: Die Policy-Engine prüft den Consent-Zweck, den diese Destination benötigt, entfernt, was nicht hinaus darf, und der Worker stellt mit der gemeinsamen Event-ID zu.
- Server-API — vom Worker zugestellt, mit Retries, Health-Checks, Fehlerklassifikation und geschwärzter Payload-Vorschau für jeden Versuch.
Was gesendet wird
Nur, was du im Event-Mapping konfigurierst — und erst, nachdem die Policy-Engine das Event für diese Destination freigegeben hat.
- Eventname und Zeitstempel, von Tracks Standard-Events auf die Eventnamen der Plattform abgebildet.
- Die gemeinsame Event-ID im Feld id der Plattform, damit Browser- und Serverzustellung nur einmal zählen.
- Keine Anbieter-Click-IDs — diese Destination ist dein eigenes System, die Attribution bleibt bei dir.
- Bestellnummer, Wert, Währung und Positionen bei Kauf-Events.
- SHA-256-gehashte Kennungen (E-Mail, Telefon, externe ID) für das Matching — nur mit dem nötigen Consent und nur, wenn erfasst.
- Der Consent-Zustand, unter dem das Event erfasst wurde, sofern die Plattform Consent-Signale annimmt.
Nie gesendet
- E-Mail-Adressen, Telefonnummern oder Namen im Klartext — Kennungen werden beim Ingest gehasht.
- Abgeleitete Werte: Unbekannt bleibt unbekannt, nichts wird geraten.
- Events, die ohne den von dieser Destination benötigten Zweck erfasst wurden.
- Geheimnisse: Tokens liegen im verschlüsselten Tresor und erreichen nie Browser, Assistent oder Log.
Technische Fakten
- Deduplizierungsfeld
id— event id- Click-IDs
- keine
- Consent-Zweck
- Notwendig
- Gepinnte API-Version
1- Umsetzungsstatus
- Umgesetzt · gegen die Anbieter-Dokumentation verifiziert · verifiziert am 2026-09-02
- Anbieter-Dokumentation
- Track-Dokumentation
Was du brauchst
Öffentliche Kennungen kannst du im Chat oder Assistenten eingeben; Geheimnisse gehen über die sichere Zugangsdaten-Karte oder OAuth und werden verschlüsselt gespeichert.
Öffentliche Kennungen
- url
- Endpunkt-URL (https)
Zugangsdaten
- Signatur-Secret (von Track erzeugt)
signing_secret— im verschlüsselten Tresor gespeichert
Consent
Läuft unter dem Zweck Notwendig, weil das Ziel deine eigenen Systeme sind (Verarbeitung auf Verantwortlichenseite). Kennungen werden trotzdem ohne Analytics-Consent entfernt, Click-IDs ohne Marketing-Consent.
Einrichtung in wenigen Schritten
Die detaillierten Prüfungen übernimmt der Assistent. Du siehst die Meilensteine, die eine Entscheidung von dir brauchen.
Kennungen eingeben
Die öffentlichen IDs der Plattform hinzufügen. Formate werden gegen die Anbieter-Dokumentation validiert, bevor etwas gespeichert wird.
Zugangsdaten verbinden
Token in die sichere Karte einfügen oder das Konto per OAuth verbinden. Geheimnisse wandern direkt in den verschlüsselten Tresor.
Mappen und testen
Standard-Events sind auf die Eventnamen der Plattform vorgemappt. Ein markierter Testevent läuft durch die echte Pipeline und zeigt die Antwort des Anbieters.
Veröffentlichen
Diff prüfen, freigeben, signierte Konfigurationsversion veröffentlichen. Bei Bedarf Rollback per Klick.
Aus Tracking Knowledge
Noch kein eigener Artikel — der Tracking-Knowledge-Hub behandelt Server-Side Tracking, Deduplizierung und Consent allgemein.
Fragen
Kann ich nur serverseitig senden?
Ja. Wähle im Assistenten den Servermodus; das Anbieter-Skript wird nie geladen und das Matching stützt sich auf gehashte Kennungen und vom Tracker erfasste Click-IDs.
Wie werden Duplikate vermieden?
Browser-Tag und Server-Request tragen dieselbe Event-ID, Käufe zusätzlich die Bestellnummer. Der Worker dedupliziert wiederholte Quell-Events zudem vor der Zustellung.
Was, wenn sich die Anbieter-API ändert?
API-Versionen sind zentral mit Prüfdatum gepinnt; Sunset-Warnungen erscheinen im Destination-Zustand lange bevor ein Endpunkt abgeschaltet wird.
Webhook verbinden
Mit dem geführten Assistenten einrichten oder den Chat-Assistenten machen lassen.