+Analytics Pro
Customer-Owned Conversion API (CAPI)
Manche Conversion-Signale müssen das Analytics-Dashboard verlassen und kundeneigene Kampagnenziele erreichen. +Analytics Pro unterstützt diesen Weg, ohne Werbenetzwerk-Weitergabe zum Standard zu machen: Conversion Delivery wird explizit konfiguriert, bewusst gemappt und vom Kunden kontrolliert.
Was das ist
Customer-Owned CAPI ist eine optionale serverseitige Routing-Schicht für ausgewählte Conversion-Signale.
Sie ist für Teams gedacht, die Kampagnen-Feedback-Loops benötigen und das Standardmodell der Analytics sauber halten wollen. Nichts wird an Meta oder Google gesendet, nur weil +Analytics Pro installiert ist. Delivery erfordert ein aktives Ziel, ein unterstütztes Event-Mapping, User-Choice- und Consent-Eignung, unterstützte Identifier und gültige Provider-Zugangsdaten.
Was das nicht ist
Customer-Owned CAPI ist keine versteckte Ad-Tech-Pipeline.
Es ist auch keine vollständige Customer-Data-Plattform, kein Ersatz für Tag Management und kein Versprechen, dass jede Kampagnenplattform jedes Event akzeptiert. Es ist ein kontrollierter Delivery-Pfad für Conversion-Signale in konkreten Use Cases.
+Analytics Pro hält Analytics standardmäßig datenschutzfreundlich und erlaubt Kunden danach, ausgewählte Conversion-Signale zu aktivieren, wenn der Kampagnenworkflow es erfordert und das Setup es zulässt.
Standard- und optionale Logik
| Ebene | Standardverhalten | Optionales Verhalten |
|---|---|---|
| Analytics-Messung | Bleibt in +Analytics Pro | Kann mit konfigurierten Modi angereichert werden |
| Conversion Events | Bleiben im Analytics-Kontext | Können für Delivery gemappt werden |
| Werbenetzwerk-Ziele | Nicht standardmäßig aktiv | Kundeneigene Ziele können konfiguriert werden |
| Serverseitige Delivery | Keine automatische Delivery | Läuft nur, wenn konfigurierte Gates passieren |
Aktivierungsfluss
Conversion Delivery ist ein gegateter Prozess, kein automatischer Nebenkanal.
| Schritt | Was passiert | Kontrollpunkt |
|---|---|---|
| 1. Signal erfassen | Ein unterstütztes Conversion- oder Custom Event wird erfasst | Event muss in +Analytics Pro existieren |
| 2. Mapping abgleichen | Der Event-Name wird einem konfigurierten Provider-Event zugeordnet | Explizites Kunden-Mapping erforderlich |
| 3. User Choice prüfen | DNT/GPC und konfigurierte Eligibility-Regeln werden ausgewertet | Fail closed, wenn das Signal nicht geliefert werden darf |
| 4. Consent-Modell prüfen | Jurisdiktion und Kunden-Setup bestimmen, ob Delivery fortfahren darf | Der Kunde bleibt für das rechtliche Setup verantwortlich |
| 5. Identifier prüfen | Nur unterstützte Identifier-Pfade werden berücksichtigt | Rohe unsichere Felder werden nicht verwendet |
| 6. Deduplizieren | Browser/server-Deduplication nutzt die explizite event_id, wenn vorhanden | Derselbe Token muss Browser und Server vorliegen |
| 7. Liefern | Das Event wird an das kundeneigene Ziel gesendet | Aktive Zugangsdaten erforderlich |
| 8. Diagnostizieren | Delivery-Status und Provider-Diagnostik werden gespeichert | Teams können Delivery Health prüfen |
Kundeneigene Ziele
CAPI-Ziele sind kundeneigene Endpunkte. +Analytics Pro erstellt keine Werbeziele automatisch und liefert keine Analytics-Daten an Meta oder Google, nur weil das Tracking-Script installiert ist. Ein Ziel wird nur genutzt, wenn Zugangsdaten, Event-Mapping, User-Choice-Prüfung, Identifier-Regeln und Provider-Anforderungen zusammenpassen.
- Meta Conversions API Endpoint
- Google Enhanced Conversions oder Data Manager Ziel
Delivery-Gates
Bevor ein Signal +Analytics Pro verlässt, muss es Delivery-Gates passieren. Diese Gates trennen Analytics-Metadaten, Werbe-Identifier, Consent-Status und Provider-Delivery, statt jede Event-Property als Aktivierungsdatum zu behandeln.
- Aktives Kundenziel
- Explizites Event-Mapping
- DNT/GPC- und Consent-Eignung
- Unterstützte Identifier-Felder
- Gültige Provider-Zugangsdaten
Deduplication mit event_id
Wenn dieselbe Conversion im Browser beobachtet und serverseitig geliefert werden kann, ist Deduplication wichtig. +Analytics Pro nutzt eine explizite event_id für Browser/server-Deduplication. Derselbe Token muss auf beiden Seiten vorhanden sein, damit Provider-Deduplication zuverlässig funktioniert.
Delivery-Diagnostik
Conversion Delivery braucht sichtbare Fehlerzustände. +Analytics Pro sollte zeigen, ob ein gemapptes Event eligible war, wohin es gesendet wurde und warum Delivery übersprungen oder abgelehnt wurde.
- Delivery-Status
- Provider
- Source Event
- Deduplication Event ID
- User-Choice- oder Consent-Grund
- Identifier-Status
- Versuche und Fehler
- Provider-Diagnostik
Häufig gestellte Fragen
- Sendet +Analytics Pro Daten standardmäßig an Meta oder Google?
Nein. Delivery erfordert ein konfiguriertes Kundenziel, ein explizites Event-Mapping, bestandene User-Choice- und Consent-Prüfungen, unterstützte Identifier und gültige Zugangsdaten.
- Was ändert sich, wenn Customer-Owned CAPI aktiviert wird?
Ausgewählte Conversion Events können serverseitig an konfigurierte Kundenziele geliefert werden. Das normale Analytics-Reporting bleibt davon getrennt.
- Entfernt serverseitige Delivery Consent-Anforderungen?
Nein. Sie verändert den Delivery-Pfad, nicht die Verantwortung des Kunden für Consent, Datenschutzhinweise, DNT/GPC-Handling und jurisdiktionsspezifische Regeln.
- Was passiert, wenn ein Delivery-Gate fehlschlägt?
Das Event kann in Analytics bleiben, wird aber nicht an das Ziel geliefert. Der Grund sollte in der Diagnostik sichtbar sein.
- Ist das ein Server-GTM-Ersatz?
Nein. Es ist eine schmale Conversion-Delivery-Schicht für ausgewählte gemappte Signale, kein allgemeines Tag-Management- oder Server-GTM-Hosting-Produkt.