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:
parent
ac4b9596da
commit
c497628af3
6 changed files with 819 additions and 7 deletions
|
|
@ -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 |
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue