Skip to main content

​
Erste CDP-Aktivierung, End-to-End

Das CDP kennt vier Phasen — Ingest, Identity-Auflösung, Segmentierung, Aktivierung — und jede hat ein eigenes Guide, das tief in die jeweilige Oberfläche einsteigt. Was keines davon allein leistet, ist ein durchgehender Durchgang: ein Event senden, zusehen, wie es einer Person zugenäht wird, über diese Historie eine Audience bauen und die Audience an eine Destination schieben, gegen die Sie Budget ausgeben können. Dieses Tutorial macht genau diesen einen Durchgang, von Anfang bis Ende, in einer Sitzung. Machen Sie diesen Durchgang zuerst. Sobald die Schleife einmal live ist, werden die Phasen-Guides zu Ihren Vertiefungsreferenzen:

​
Warum ein einzelner End-to-End-Durchgang zählt

Jedes Phasen-Guide setzt die anderen voraus. Allein gelesen lassen sie Ihnen das Zusammennähen der Schleife selbst übrig: das Source-Guide erklärt, wie Events angenommen werden, aber nicht, was nach dem Laden passiert; das Segmente-Guide setzt aufgelöste Profile und saubere Events voraus; das Aktivierungs-Guide setzt ein Segment voraus, das die Veröffentlichung wert ist. Neue CDP-Workspaces scheitern in den Lücken zwischen den Guides — Events, die ingestet, aber nie zugenäht wurden; Segmente über ungelösten Duplikaten; Aktivierungen, die dünne Memberships veröffentlichen, die niemand upstream diagnostiziert hat. Fahren Sie diesen einen Durchgang gegen eine Test-Source und eine Test-Destination, bevor Sie echten Verkehr einschalten. Wenn später etwas aus der Reihe schlägt, steigen Sie wieder in das Phasen-Guide der betroffenen Phase ein — aber Sie steigen ein mit dem Wissen, welche Phase defekt ist, weil Sie die ganze Schleife einmal gesund gesehen haben.

​
1. Voraussetzungen

Bringen Sie alle drei mit, bevor das erste Event fliegt:
  1. Ein veröffentlichter Tracking-Plan. Deklarieren Sie die Events, die Ihre App sendet, und die Property-Form je Event auf der Tracking-Plan-Oberfläche im Enforcement-Modus soft. Soft protokolliert Verstöße, ohne Events abzulehnen — ein neuer Producer kann im Iterieren nie an einem Mismatch stehen bleiben. Später auf strict anziehen.
  2. Eine verbundene Source. Ein Ingest-Secret, ausgestellt unter Integrations → CDP → Source (inbound) und in Ihrer App deployed — das Source-und-Destinations-Guide führt durch Ausstellung und Rotation. Ihre App postet signierte Events an https://api.orbit.devotel.io/cdp/v1/<ingest_id>/track.
  3. Eine Destination mit Credentials. Ein Werbenetzwerk-Audience, erreicht über eine OAuth-Verbindung, oder ein HTTPS-Webhook-Sink, den Sie kontrollieren. Verdrahten Sie die Credentials, bevor Sie sie brauchen — die Aktivierungsphase mappt ein Segment nur auf eine Destination, die bereits authentifiziert.
Halten Sie außerdem einen API-Key mit der Rolle owner, admin oder developer bereit. Jede Mutation in diesem Durchgang (Regeln, Segmente, Aktivierungen) ist auf diese Rollen gegated; Lesezugriffe akzeptieren mehr.

​
2. Eine Source ingesten

Wählen Sie auf Integrations → CDP eine Source-Art — Segment, RudderStack, ein generischer Webhook oder Ihr eigenes SDK, das direkt postet. Stellen Sie das Ingest-Secret im Tab Source (inbound) aus, deployen Sie es in die App und signieren Sie jede Anfrage gemäß dem Ingest-Signing-Guide: die drei Header X-Orbit-CDP-Timestamp, X-Orbit-CDP-Nonce und X-Orbit-CDP-Signature über <timestamp>.<nonce>.<raw body>, geschlüsselt mit dem Secret-Plaintext. Feuern Sie ein track-Event aus der App. Bestätigen Sie dann, dass es gelandet ist — nehmen Sie es nie an:
  1. Öffnen Sie Integrations → CDP → Event debugger.
  2. Filtern Sie auf Type = track und gleichen Sie Ihren Event-Namen ab.
  3. Klappen Sie die Zeile aus und lesen Sie exakt die properties und context, die das Gateway gespeichert hat.
Fehlt die Zeile, liegt der Fehler in der Signatur-Schicht (ein 401, den die App geschluckt hat) oder der Tracking-Plan lehnt den Payload ab — das Event-Debugger-und-DLQ-Guide behandelt beides, einschließlich des Lesens eines ausgespülten oder verlorenen Payload-Body. Fahren Sie nicht fort, bis hier ein echtes Event sichtbar ist.
Wo Einwilligung Ihr Ingest steuert — etwa wenn Event-Properties aus Kontaktfeldern stammen, für die eine Zweckbindung gilt — erfassen Sie die Rechtsgrundlage pro Kontakt über die Einwilligungs-API, bevor die Quelle schaltet. Orbit macht das Erfassen einfach, ersetzt aber nicht die wirksame Einwilligung selbst: Sie bleiben dafür verantwortlich, was Sie ingesten und wofür. Diese Seite ist keine Rechtsberatung.

​
3. Identität auflösen

Events treffen mit beliebiger userId ein, die Ihr SDK gesendet hat. Ob diese an einen Kontakt angenäht wird — und an welchen — entscheiden die Identity-Regeln, nicht das Event selbst. Die Standardregel löst userId nur gegen externe IDs auf; eine E-Mail- oder telefonförmige userId näht nicht an, bis Sie diese Match-Shape freischalten.
  1. Öffnen Sie Integrations → CDP → Identity resolution und prüfen Sie die Match-Shapes: External ID (ausgesät, Priorität 100) sowie opt-in Phone, Email und Anonymous ID.
  2. Tragen Ihre Events E-Mail oder Telefon als Identität, simulieren Sie zuerst auf Audience → Identity resolution — das Dashboard verweigert das Speichern einer Änderung an diesen Shapes, bis in Ihrer Session eine Simulation gelaufen ist, denn eine zu breite Shape näht falsche Personen unwiderruflich zusammen. Lesen Sie die geschätzte Merge-Zahl; over-merged sie, verengen Sie die Shape oder erhöhen Sie ihre Priorität.
  3. Speichern Sie das Regelwerk zurück auf der CDP-Seite und setzen Sie im selben Builder die Survivorship-Policy (welcher Wert bei einem Merge je Feld gewinnt).
  4. Bestätigen Sie, dass die Auflösung gelandet ist: Öffnen Sie Audience → Identity resolution und prüfen Sie, dass die Identität Ihres Test-Events auf genau einen Kontakt gefaltet wurde, nicht auf ein Review-Queue-Duplikat. Das Datenkatalog-und-Identity-Regeln-Guide behandelt Prioritäten, das Simulations-Gate und die Trennung von Policy und Review-Queue.
Überspringen Sie hier nichts: Jedes Segment unten liest aufgelöste Kontakte, also überleben ungelöste Duplikate in jede Audience-Zahl, die Sie bauen.

​
4. Das Segment über aufgelöste Events bauen

Mit landenden Events und nähter Identität bauen Sie die Audience. Ein Segment ist ein gespeicherter Filter über Kontaktattribute, Custom Fields und Verhaltens-Events; angelegt mit POST /api/v1/contacts/segments. Zwei ausgearbeitete Beispiele — ein plain Filter und ein SQL-Trait, das ihn speist.

​
Ein ausgearbeiteter Verhaltensfilter

Drei Dinge sind zu beachten. Events werden mit dem Präfix event.<name> referenziert und paaren sich mit einem Verhaltensoperator — performed_event, did_not_perform_event, event_count oder performed_sequence für geordnete Journeys. Das within-Fenster ist relativ, “letzte 14 Tage” braucht also keine Zeitstempel-Arithmetik. Und auto_refresh materialisiert die Membership in einer Kadenz — eine Aktivierung im nächsten Schritt liest genau diese materialisierte Membership, setzen Sie es also. Schätzen Sie die Größe des Filters, bevor Sie speichern. POST /api/v1/contacts/segments/preview evaluiert denselben Filter gegen Live-Daten und liefert eine Trefferzahl ohne Persistenz; eine Zahl von null oder “der ganze Tenant” bedeuten beide, dass der Filter falsch ist, nicht die Daten.

​
Ein konkretes SQL-Trait, das das Segment speist

Wenn die nötige Kennzahl bereits als Warehouse-SQL existiert — eine finance-verantwortete LTV-View, ein dbt-Modell — übernehmen Sie sie als SQL-Trait, statt sie in der Prädikats-DSL nachzubauen. Ein read-only SELECT, das (user_id, trait_value) zurückgibt, nach Ihrem Zeitplan läuft und jeden Wert in die Trait-Map des Kontakts stempelt:
Sobald das Trait materialisiert ist, ist es segmentierbar wie jedes Attribut — { "field": "traits.ltv_tier", "op": "equals", "value": "high" } kombiniert sich frei mit den Verhaltensbedingungen oben. Der vollständige Engine-Wahlbaum (DSL-Prädikat, SQL, AI) steht auf der SQL-Traits-Seite; das komplette Filtervokabular im Segmente-Guide.

​
5. An eine Destination aktivieren

Aktivierung veröffentlicht das Segment dort, wo es Budget verdient — im Audience eines Werbenetzwerks oder in Ihrem Webhook-Sink — in einer Kadenz, die Sie kontrollieren. Gehen Sie es in zwei Calls durch, gemäß dem Aktivierungspipeline-Guide. Verdrahten Sie die Destination einmalig. Für ein Werbenetzwerk (Google gezeigt; Meta, TikTok, LinkedIn und der Rest des Katalogs verhalten sich gleich):
Für Ihren eigenen HTTPS-Sink stattdessen: PATCH /api/v1/cdp/audience/webhook mit target_url und signing_secret; Zustellungen treffen signiert ein als X-Orbit-Signature: t=<unix-sec>,v1=<hmac-sha256>, dasselbe Schema, das Ihr bestehender Orbit-Webhook-Verifier bereits prüft. So oder so werden Identifier vor dem Versand an Werbenetzwerke SHA-256-gehasht — Klartext-PII verlässt den Tenant nie. Fahren Sie die erste Aktivierung explizit, statt auf den Zeitplan zu warten:
Dry-runnen Sie zuerst mit POST /api/v1/cdp/audience/preflight/google, sobald das Urteil unsicher ist — dasselbe Gate, nichts wird versandt. Das Pre-Aktivierungs-Gate blockiert untergroße Audiences, niedrige Identifier-Abdeckung sowie Einwilligungs- oder Suppressions-Verstöße; die fehlgeschlagenen Check-Ids kommen in der Antwort zurück. Ist für diese Org Maker-Checker eingeschaltet, reiht sich der Run zur Freigabe durch eine zweite Person ein — einreichen, von einem Owner freigeben lassen, mit der zurückgegebenen Approval-Id erneut einreichen.

​
6. Readback und Troubleshooting

Bestätigen Sie, dass der Run gelandet ist, und lernen Sie dann das Lag-Budget kennen, damit Sie gesund von festgefahren unterscheiden. Bestätigen. GET /api/v1/cdp/audience/activations listet die Run-Historie; GET /api/v1/cdp/audience/activations/:id bohrt einen Run mit den Zählern requested / matched / skipped und Ablehnungsgründen je Member (nie PII) auf. Status ok mit matched nahe requested ist gesund; partial nennt seinen Bucket; skipped heißt, nichts hat gematcht oder beim Dispatch löste sich keine Verbindung auf. Für eine Warehouse-Destination statt eines Werbenetzwerks lesen Sie dieselben Urteile im Sync-Run-Log — je Run attempted / delivered / rejected / failed und Fehlerklassen (auth, validation, rate_limit, …), die die Retry-Schleife entscheiden. Das Lag-Budget. Jede Phase hat ihre eigene erwartete Verzögerung; eine Beschwerde wird erst dann zum Bug, wenn eine Phase ihr Budget überschreitet: Die Tabelle von oben nach unten zu lesen verwandelt “die Audience ist falsch” in einem Durchgang in “Phase N ist über Budget”. Steigen Sie dann wieder in das zuständige Phasen-Guide ein — Source und Destinations, Identity-Regeln, Segmente, Aktivierung oder Reverse ETL — mit dem Fehler bereits lokalisiert. Die vier Fehlerbilder, denen Sie tatsächlich begegnen. Ein 409 CONNECTION_NOT_CONFIGURED beim Aktivieren heißt, die Destination ist nicht vollständig verdrahtet (audience_id oder Connection-Id fehlt). Ein 422 AUDIENCE_PREFLIGHT_BLOCKED nennt seine fehlgeschlagene Gate-Prüfung — Segment vergrößern, Identifier-Abdeckung reparieren oder bewusst übersteuern. Null gematchte Member heißt, Zeilen trafen ohne starkes Identifier ein — reparieren Sie das Mapping beim Ingest, nicht bei der Aktivierung. Ein partial-Run, dessen Drilldown validation-Buckets mit “missing or empty upsert identifier” zeigt, heißt, der Upsert-Key ist ungemappt — reparieren Sie das Field-Mapping und fahren Sie erneut. Alle vier sind je Phase in den oben verlinkten Guides behandelt.

​
Siehe auch