Der Lebenszyklus in Events
| Moment im Lebenszyklus | Event | Ursprung | Properties |
|---|---|---|---|
| Konto erstellt | sign_up | Browser (hybrid) | method |
| Trial gestartet | start_trial | Server (Billing-Webhook) | plan, trial_days |
| Erstes bezahltes Abonnement | subscribe | Server (Billing-Webhook) | plan, interval, value, currency, transaction_id |
| Verlängerungsrechnung bezahlt | purchase mit props.renewal: true | Server | value, currency, transaction_id |
| Upgrade / Expansion | purchase mit props.expansion: true | Server | Delta-value |
| Kündigung oder Erstattung | refund | Server | ursprüngliche transaction_id, negativer value |
| Login | login | Browser | — |
Das Billing-System ist die Autorität für alles, worin Geld steckt. Der Browser zeigt vielleicht eine „Abonnement bestätigt“-Seite, aber das Event, das Werbeplattformen erreicht, kommt aus dem Webhook mit den IDs des Billing-Systems.
Warum Verlängerungen kein subscribe sein dürfen
Werbeplattformen optimieren auf die Conversion, die du sendest. Kommt jede monatliche Verlängerung als neues Abonnement mit Wert an, lernt die Plattform, dass Bestandskunden gut konvertieren, und bietet darauf, sie erneut zu erreichen. Halte das Akquisitions-Event (subscribe, einmal pro Kunde) getrennt von Retention (purchase mit Verlängerungs-Flag) und mappe nur das Akquisitions-Event auf Werbe-Conversion-Aktionen. Verlängerungen fließen weiterhin in Analytics und dein eigenes Reporting.
Werte für Werbeplattformen
subscribe: Der erste Rechnungsbetrag ist vertretbar und einfach. Eine Lifetime-Value-Schätzung ist nur als dokumentierte Konstante je Plan im Destination-Mapping erlaubt, im Audit-Log sichtbar; nie eine Schätzung je Nutzer.start_trial: kein Wert oder ein dokumentierter Erwartungswert je Plan.- Expansion: das Delta, nicht die neue Summe.
refund: negativer Wert des erstatteten Betrags; GA4 verarbeitet Erstattungen über die Transaktions-ID, Google Ads über Conversion-Anpassungen, die meisten anderen ignorieren sie — der Connector wendet an, was der Anbieter unterstützt.
Identität über Geräte hinweg
Ein SaaS-Kunde registriert sich am Desktop, bezahlt mobil, loggt sich überall ein. Rufe identify mit deiner Nutzer-ID und, unter Marketing-Consent, der gehashten E-Mail auf; die Server-Events tragen dieselbe Nutzer-ID und denselben Hash. Das lässt Plattformen ein serverseitiges subscribe dem Anzeigenklick zuordnen, der Tage zuvor auf einem anderen Gerät stattfand — innerhalb ihrer Fenster.
Trials und Consent
Der Billing-Webhook trägt den Consent-Stand, den dein System bei der Registrierung erfasst hat, zusammen mit der Nutzer-ID. Der Router wendet diesen Stand an: Ein Nutzer, der Marketing bei der Registrierung abgelehnt hat, erzeugt nur Analytics-Events, und ein Webhook ohne Consent-Information erreicht gar keine Werbe-Destination. Leite Consent nicht daraus ab, dass jemand Kunde wurde; Kunde zu sein ist keine Einwilligung in Werbemessung.
Dedup über Billing-Wiederholungen
Billing-Systeme wiederholen Webhooks. Nutze die Rechnungs- oder Abonnement-ID als transaction_id; die Ingest-Stufe markiert ein zweites subscribe oder purchase mit derselben Transaktions-ID als doppelte Conversion, und Plattformen, die über die Bestellnummer deduplizieren, führen zusammen, was durchgekommen ist.
Reporting, das ehrlich bleibt
- Akquisition:
subscribe-Anzahl und -Wert je Kampagne, aus den Werbeplattformen und aus deinen eigenen Events. - Trial-Conversion:
start_trial→subscribeje Plan, nur aus deinen eigenen Events. - Nettoumsatz:
purchase(alle Flags) minusrefund, aus dem Billing, monatlich gegen die Events abgestimmt.
Weichen diese drei Zahlen je von den Berichten des Billing-Systems ab, zeigt die Aufschlüsselung nach Quelle auf der Events-Seite, welcher Weg was vermissen lässt.