reports: Basiswerte für die Konversionsmessung (Roadmap 0.1 und 0.2)

Beide Werte müssen gemessen sein, bevor die erste Maßnahme aus Block 1 live
geht — ohne Vergleichspunkt wäre jede spätere Bewertung eine Vermutung.

press-releases:view-distribution gibt die Verteilung der Aufrufzahlen je Portal
aus: Median, Quartile, P10/P90 und eine Häufigkeitsverteilung. Ein Mittelwert
allein trägt hier nicht — eine Handvoll Ausreißer zieht ihn nach oben, während
der typische Absender darunter liegt. Genau davor soll E2 schützen, deshalb
wird die Schiefe (Mittelwert gegen Median) ausdrücklich mit ausgewiesen.

Altbestand und seit dem Relaunch eingegangene Meldungen stehen getrennt: Ihre
Zähler haben unterschiedliche Vorgeschichten, und eine Einordnung, die beide
vermischt, vergleicht Äpfel mit Birnen. Mit 410 entfernte Meldungen zählen
nicht mit, eine Meldung auf beiden Portalen bei beiden.

press-releases:rejection-rate gibt die Ablehnungsquote je Einreichungsquelle
aus. Gezählt wird je EINREICHUNG, nicht je Meldung: Ein Übergang nach `review`
eröffnet eine Einreichung, die nächste Entscheidung schließt sie. Eine
überarbeitete und erneut eingereichte Meldung ist damit ein zweiter Vorgang mit
eigenem Ausgang — und genau das ist die Größe, die die Infoseite (1d) später
verändern soll. Gruppiert wird nach dem Einreichenden, nicht nach dem
Entscheider; letzterer ist immer die KI-Prüfung und als Gruppierung wertlos.
Jeder API-Client bekommt eine eigene Zeile, Einreichungen aus dem Kundenbereich
fallen zu "direkt" zusammen.

Noch offene Prüfungen zählen nicht in den Nenner, sonst sänke die Quote allein
dadurch, dass der Zeitraum bis heute reicht. Entscheidungen zu Einreichungen
von vor dem Zeitraum werden gemeldet statt verschluckt — ein zu kurz gewählter
Zeitraum sähe sonst wie eine niedrige Quote aus.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Kevin Adametz 2026-09-01 11:57:25 +00:00
parent ac4b9596da
commit c497628af3
6 changed files with 819 additions and 7 deletions

View file

@ -28,16 +28,58 @@ Der größte ungenutzte Bestand liegt bereits im System: Firmen, deren Meldungen
## Block 0 — Messbarkeit
Ohne definierte Konversionspunkte ist keiner der folgenden Blöcke bewertbar.
Ohne definierte Konversionspunkte ist keiner der folgenden Blöcke bewertbar. Die Messung läuft nicht über Umami, sondern über eigene Ereignisdaten. Grund: Die zu messende Strecke führt über zwei Domains und einen Magic Link, und ein cookiefreies Analytics-Tool verliert die Sitzung genau an der Stelle, an der die Konversion passiert. Claim, Registrierung und Buchung sind außerdem keine Seitenaufrufe, sondern Zustandsänderungen in der Datenbank, bei denen die Identität ohnehin bekannt ist.
**Rollenteilung:** Ereignistabelle für den Konversionstrichter (Block 1). Umami für Seitenaufrufe, Suchbegriffe und Herkunft aus der Suche (Block 2). Keine Vermischung.
### Arbeitspakete
| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 0.1 | Konversionspunkte festlegen: Claim eines Newsrooms, Registrierung, erste Buchung, Wiedereinreichung nach Ablehnung | S | keine |
| 0.2 | Umami-Ziele einrichten, getrennt nach Herkunft (Veröffentlichungsmail, Ablehnungsmail, organisch) | S | 0.1 |
| 0.3 | Bestandsaufnahme Aufrufzahlen: Median und Verteilung der letzten drei Monate je Portal | S | keine |
| 0.4 | Ablehnungsquote je Quelle (connektar, openPR, direkt) als wiederkehrende Auswertung | S | keine |
| 0.1 | Basiswert Aufrufzahlen: Median und Verteilung je Portal über die letzten drei Monate | S | keine |
| 0.2 | Basiswert Ablehnungsquote je Quelle (connektar, openPR, direkt), als wiederkehrende Auswertung angelegt | S | keine |
| 0.3 | Tabelle `conversion_events` anlegen: Ereignistyp, Firmen-ID, Meldungs-ID, Quelle, Zeitstempel | S | keine |
| 0.4 | Herkunftsparameter in allen Mail-Links, gespeichert **auf dem Magic-Link-Token**, nicht in der Session | S | 0.3 |
| 0.5 | Ereignisse an den bestehenden Zustandsänderungen mitschreiben | M | 0.3, 0.4 |
| 0.6 | Auswertung als Artisan-Befehl: Trichter je Quelle und Zeitraum | S | 0.5 |
| 0.7 | Aufbewahrungsfrist für Ereignisdaten festlegen und in der Datenschutzerklärung führen | S | 0.3 |
**Warum 0.3 vor Block 1 steht:** Die Sichtbarkeitsansicht macht öffentlich, was bisher nicht belegt werden musste. Fällt die Verteilung schwach aus, werden Rohzahlen zum Nachteil und es braucht eine Einordnung gegen den Portaldurchschnitt. Diese Entscheidung muss vor dem Bau fallen.
### Konversionsleiter
Fünf Stufen statt einer Liste gleichrangiger Punkte. Nur so ist erkennbar, an welcher Stelle es hakt.
| Stufe | Ereignis | Was ein Abbruch hier bedeutet |
|---|---|---|
| 1 | Mail-Link geklickt | Betreff oder Anlass trägt nicht |
| 2 | Magic Link eingelöst | Der Verwaltungszugang wird nicht verstanden |
| 3 | Newsroom bearbeitet | Kein Anreiz, das Profil zu pflegen |
| 4 | Konto angelegt | Der Nutzen des Kontos ist nicht erkennbar |
| 5 | Erste Buchung | Preis oder Angebot passt nicht |
Die Wiedereinreichung nach Ablehnung gehört nicht in diese Leiter. Sie misst, ob die Infoseite wirkt, und wird gegen den Basiswert aus 0.2 separat geführt.
### Quellen
Jeder Mail-Link trägt einen Herkunftswert, der auf dem Token gespeichert wird und damit Domainwechsel, Mailclient und Weiterleitung überlebt.
| Wert | Herkunft |
|---|---|
| `mail_publish` | Veröffentlichungsbenachrichtigung |
| `mail_reject` | Ablehnungsbenachrichtigung |
| `profile_claim` | Hinweis auf der Newsroom-Seite |
| `organic` | keine zugeordnete Herkunft |
### Reihenfolge
**Sofort, ohne Vorarbeit:** 0.1 und 0.2. Beides sind Datenbankabfragen. Die Verteilung der Aufrufe entscheidet E2, also ob die Absenderansicht Rohzahlen oder eine Einordnung zeigt. Die Ablehnungsquote je Quelle wird ohnehin für das connektar-Gespräch gebraucht.
**Vor der ersten Maßnahme aus Block 1:** 0.3 bis 0.5. Herkunftsdaten lassen sich nicht rückwirkend erzeugen. Wer hier zu spät anfängt, sieht später Buchungen, aber nicht ihren Ursprung.
**Basiswerte müssen vor dem Livegang von Block 1 stehen.** Ohne Vergleichspunkt wird jede spätere Bewertung eine Vermutung.
### Datensparsamkeit
Die Ereignistabelle referenziert Firmen- und Meldungs-IDs, keine Personen und keine Klartextadressen. Damit bleibt sie interne Statistik. Die Aufbewahrungsfrist wird in 0.7 gleich mitdefiniert und nicht nachgetragen.
**Abbruchbedingung:** keine. Block 0 ist Voraussetzung, nicht Wette.
@ -90,7 +132,7 @@ Für selbst angelegte Firmendaten trägt der Nutzer die Verantwortung. Für die
| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 1c.1 | Absenderansicht je Meldung: Aufrufe im Verlauf, Indexierungsstatus, Einordnung gegen Portaldurchschnitt | M | 0.3 |
| 1c.1 | Absenderansicht je Meldung: Aufrufe im Verlauf, Indexierungsstatus, Einordnung gegen Portaldurchschnitt | M | 0.1 |
| 1c.2 | Zugang zur Ansicht über Magic Link, auch ohne Konto | S | 1b.2 |
| 1c.3 | Newsroom-Übersicht mit allen Meldungen der Firma und Summenwerten | M | 1a.3, 1c.1 |