Prelumen Analytics
Deine Conversions. Dein Server. Deine Daten.
Eine Conversion API, die dir gehört – sende Conversion Events aus deinem eigenen Backend, statt sie Plattform-Pixeln zu überlassen.
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 Prelumen Analytics 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.
Prelumen Analytics 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 Prelumen Analytics | 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 Prelumen Analytics 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 |
Ausgewählte Conversion Events können zunächst im Analytics-Kontext bleiben und nur dann nach außen geliefert werden, wenn Ziel, Mapping und Consent-Gates explizit passen. CAPI ist kontrollierte Delivery, keine Verhaltenserfassung.
Kundeneigene Ziele
CAPI-Ziele sind kundeneigene Endpunkte. Prelumen Analytics 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 Prelumen Analytics 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. Prelumen Analytics 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. Prelumen Analytics 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 Prelumen Analytics 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.