presseportale/dev/2026-09-01/roadmap-2026.md

# Roadmap Nutzergewinnung und Rückgewinnung

**Stand:** 01.09.2026
**Gültig für:** presseecho.de, businessportal24.com, Hub pressekonto.com
**Zweck:** Reihenfolge, Abhängigkeiten und Abbruchbedingungen für den Ausbau nach dem Relaunch

---

## Ausgangsbefund

Das Portal hat Traffic, aber der Traffic besteht überwiegend aus Lesern fremder Meldungen. Zwischen "Meldung wird gelesen" und "jemand bucht" existiert keine Strecke. Alles, was den Trichter oben verbreitert, wirkt erst, wenn er unten geschlossen ist.

Der größte ungenutzte Bestand liegt bereits im System: Firmen, deren Meldungen über connektar eingehen und die kein Konto haben (openPR ist kein zweiter Kanal, sondern der Presse-API-Verteiler von connektar — derselbe Zulauf). Sie sind erfasst, ihre Kontaktadresse liegt vor, sie werden bereits transaktional benachrichtigt, und die Magic-Link-Verifikation dieser Adresse ist gebaut.

**Grundsatz für die Reihenfolge:** erst messen, dann den Trichter unten schließen, dann oben verbreitern, dann Partner.

---

## Aufwandsskala

| Kürzel | Bedeutung |
|---|---|
| S | ein Abend bis ein Tag |
| M | mehrere Tage, in Etappen lieferbar |
| L | mehrere Wochen oder abhängig von Dritten |

---

## Block 0 — Messbarkeit

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 | Basiswert Aufrufzahlen: Median und Verteilung je Portal über die letzten drei Monate | S | keine |
| 0.2 | Basiswert Ablehnungsquote je Quelle (API-Client, 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 |

### 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.

---

## Block 1 — Konversion aus Bestand

Der Kern. Wandelt vorhandenen Zulauf in Konten und Kunden, ohne neuen Traffic zu benötigen.

### 1a Newsroom-Konsolidierung

| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 1a.1 | Trockenlauf-Bericht: wie viele Firmen fallen bei Zusammenführung über die Firmen-E-Mail zusammen, welche Adressen tragen mehrere Firmennamen | S | keine |
| 1a.2 | Sammeladressen-Erkennung: Adresse mit mehr als [Schwellwert] abweichenden Firmennamen wird markiert und von der automatischen Zusammenführung ausgenommen | S | 1a.1 |
| 1a.3 | Zusammenführung im Bestand mit gespeicherter Ursprungszuordnung, rückabwickelbar | M | 1a.2 |
| 1a.4 | Laufende Zuordnung neuer API-Meldungen zu bestehendem Newsroom über die Firmen-E-Mail | M | 1a.2 |

**Regelwerk Zusammenführung**

| Signal | Folge |
|---|---|
| Gleiche E-Mail, gleicher oder ähnlicher Firmenname | automatisch zusammenführen |
| Gleiche E-Mail, deutlich abweichende Firmennamen | nicht zusammenführen, als Sammeladresse markieren |
| Abweichende E-Mail, gleicher Firmenname und Ort | Vorschlag im Admin, keine automatische Aktion |

Schlüssel ist die **Firmen-E-Mail**, nicht die Pressekontaktadresse. Der Pressekontakt ist der Firma untergeordnet und wechselt; die Firmenidentität darf nicht an einer Person hängen. Der Magic Link kann trotzdem an beide gehen, das ist eine Berechtigungs- und keine Identitätsfrage.

Für selbst angelegte Firmendaten trägt der Nutzer die Verantwortung. Für die rückwirkende Zusammenführung im Altbestand trägt sie das Portal, weil dort nicht angelegt, sondern verschmolzen wird. Deshalb 1a.1 vor 1a.3.

### 1b Newsroom als Produkt

| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 1b.1 | Sichtbarkeitsregel: Newsroom öffentlich erst ab der ersten veröffentlichten Meldung, sonst nur Datensatz | S | keine |
| 1b.2 | Verwaltungszugang über Magic Link, unabhängig von der öffentlichen Sichtbarkeit | M | 1a.4 |
| 1b.3 | Kostenlose Profilpflege: Beschreibung, Logo, Bilder, Pressekontakte | M | 1b.2 |
| 1b.4 | Hinweis "Diesen Newsroom verwalten" auf der Profilseite und in der Veröffentlichungsmail | S | 1b.2 |
| 1b.5 | Rückbau: fällt ein Newsroom durch Löschung oder Depublizierung auf null Meldungen, verschwindet die öffentliche Seite mit | S | 1b.1 |
| 1b.6 | Nicht erreichbare Newsrooms aus der Bounce-Suppression im Admin markieren, nicht beanspruchbar, aus allen Mailstrecken ausgenommen | S | Bounce-Suppression live |

**Leitplanken Profilpflege**

- Externe Links im Profiltext werden systemseitig gesetzt wie in Meldungen, nicht kundenseitig wählbar. Sonst wird das Profil ein Backlink-Automat.
- Beschreibungstext läuft mindestens durch die Rot-Ebene der bestehenden Prüfung.
- Bilder im Newsroom unterliegen derselben KI-Deklaration und demselben Audit-Log wie Bilder in Meldungen. Logos sind unkritisch, fotorealistische Motive nicht.
- Verwaltungszugang öffnet Profildaten. Veröffentlichte Meldungen bleiben in den bestehenden Änderungspfaden. Kein Bearbeitungszugriff auf Meldungen über den Umweg Profilverwaltung.

### 1c Sichtbarkeit belegen

| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 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 |

### 1d Infoseite und Prüfwerkzeug

| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 1d.1 | Hilfeseite ohne kommerziellen Anteil: was eine gute Pressemitteilung ausmacht, wie geprüft wird, was sich verbessern lässt, Abschnitt zu Pressebildern | S | keine |
| 1d.2 | Textbaustein in die Ablehnungsmail, Verlinkung auf 1d.1 | S | 1d.1 |
| 1d.3 | Abmeldemöglichkeit für Benachrichtigungen, Status in der Suppression-Logik geführt | S | Bounce-Suppression live |
| 1d.4 | Prüfwerkzeug: eingefügter Text wird bewertet, Ausgabe als benannte Stufe mit konkreten Hebeln | M | 1d.1 |
| 1d.5 | Bewertung einer bestehenden Meldung über Magic Link | S | 1d.4, 1b.2 |
| 1d.6 | Partnerbereich am Seitenende, vorerst als "BALD" ohne Namen und Logos | S | 1d.1 |

**Offenlegungsgrenze**

| Ebene | Nach außen | Begründung |
|---|---|---|
| Rot-Kriterien | nur als Kategorie, ohne Detail | wer weiß, wie er durchrutscht, rutscht durch |
| Content-Dimensionen (Aufbau, Konkretheit, Anlass, Zitat, Substanz) | offen erklärbar | Optimierung auf diese Dimensionen ist tatsächliche Verbesserung |
| Gewichtung, Schwellen, Kalibrierung | nie | Rekonstruierbarkeit des Gates |

**Qualitätsstufen statt Punktzahl**

| Stufe | Bedeutung für den Autor |
|---|---|
| Nicht veröffentlichbar | verletzt eine Grundbedingung, muss neu geschrieben werden |
| Veröffentlichbar, schwach | erscheint, wird kaum wirken, Hauptschwäche wird benannt |
| Solide | erfüllt die Anforderungen, zwei bis drei konkrete Hebel |
| Stark | trägt von selbst |

Die Stufe sieht der Autor, nicht der Leser der Meldung. Kein öffentliches Qualitätssiegel auf Meldungen, weil es die Meldungen zahlender Kunden entwertet, sobald eine davon nur "solide" ist. Die portalseitige Konsequenz aus der Qualität besteht bereits über Boost-Fähigkeit und Platzierung.

**Kostenmodell Prüfwerkzeug:** [Anzahl] kostenlose Prüfung je Meldung und [Zeitraum], danach über Credits. Der kostenlose Weg muss echt und ausreichend sein. Die Prüfung ist vom Veröffentlichungsvorgang entkoppelt, verbraucht keinen Slot und ändert keinen Status; die Entscheidung gegen einen Re-Check-Loop in Phase 2 bleibt davon unberührt.

**Nebeneffekt:** Prüfläufe erzeugen Divergenzdaten für `scoring:divergence-report` und schärfen die Rubrik.

**Abbruchbedingung Block 1:** Wenn nach [Zeitraum] weniger als [Schwellwert] Newsrooms beansprucht wurden und keine Wiedereinreichung nach Ablehnung messbar ist, trägt die Konversion aus dem Bestand nicht. Dann Block 1 einfrieren und Gewicht auf Block 3 verlagern.

---

## Block 2 — Organische Sichtbarkeit

Verbreitert den Trichter oben. Sinnvoll erst, wenn Block 1 unten geschlossen ist.

| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 2.1 | NewsArticle-Schema auf allen Meldungen, Organization-Schema auf Newsrooms | M | 1b.1 |
| 2.2 | Aufnahme in Google News und Publisher Center prüfen und beantragen | M | 2.1 |
| 2.3 | Branchen- und Kategorie-Landingpages aus dem Archivbestand | M | keine |
| 2.4 | Transparenzseiten: Preisvergleich, ohne Abo veröffentlichen, ohne Mindestlaufzeit | S | keine |
| 2.5 | Konsolidierung der bestehenden Ratgeberseiten unter `/de/presse/` gegen 1d.1 und 2.4 prüfen | S | 1d.1 |
| 2.6 | Outreach an Betreiber von Presseportal-Listen und Vergleichsartikeln | M | 2.4 |
| 2.7 | Auffindbarkeit für KI-Systeme: strukturierte Daten, klare Entitätszuordnung, `llms.txt` | M | 2.1 |

**Formulierungsgrenze bei 2.7:** Die technischen Voraussetzungen zu beschreiben ist haltbar. Eine Nennung in KI-Antworten zu versprechen ist es nicht. Vor Veröffentlichung auf einer Preisseite sauber formulieren.

**Abbruchbedingung Block 2:** Wenn nach [Zeitraum] die Transparenzseiten und der Listen-Outreach keine messbaren Registrierungen erzeugen, bleibt Block 2 auf dem technischen Teil (2.1 bis 2.3) beschränkt und der Marketing-Teil wird nicht weiter ausgebaut.

---

## Block 3 — Reichweite und Partner

Braucht Betreuungszeit und ist teilweise von Dritten abhängig.

| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 3.1 | RSS-Feeds je Branche | S | 2.3 |
| 3.2 | Opt-in E-Mail-Digest je Branche, Double-Opt-in | M | 3.1, Bounce-Suppression live |
| 3.3 | Agenturmodell: mehrere Firmen unter einem Konto, aus den Sammeladressen aus 1a.2 abgeleitet | L | 1a.2 |
| 3.4 | Gezielte Ansprache kleiner PR-Agenturen und freier Texter | L | 3.3 |
| 3.5 | Syndikationsvertrag als Standarddokument fertigstellen | M | Anwaltstermin |
| 3.6 | IMKIS: Pilot nach Treffen am 01.10., Partnerplatzierung erst nach ausgehandelter Gegenleistung | L | 1d.6 |

**Zur Reihenfolge von 3.3:** Der Trockenlauf 1a.1 sagt, wie viele Sammeladressen im Bestand liegen. Ist die Zahl hoch, rückt das Agenturmodell nach vorn, weil es dann kein Zukunftsfeature ist, sondern ein vorhandenes Datenproblem.

**Abbruchbedingung Block 3:** Wenn der Leser-Layer nach [Zeitraum] unter [Schwellwert] Abonnenten je Branche bleibt, wird er nicht als Verkaufsargument verwendet und nicht weiter ausgebaut.

---

## Feste Abhängigkeiten außerhalb der Blöcke

| Vorgang | Blockiert | Grund |
|---|---|---|
| Bounce-Suppression produktiv | 1b.6, 1d.3, 3.2, jede weitere Mailwelle | Zustellbarkeit; ein beschädigter Absenderruf trifft zuerst die Magic Links |
| connektar `ai_declaration` verpflichtend, ~Oktober 2026 | nichts direkt | Termin steht, gehört in die Planung |
| Anwaltstermin, Fünf-Punkte-Agenda | 3.5 | Syndikationsvertrag und Art. 50 Abs. 4 |

---

## Offene Entscheidungen

| Nr. | Frage | Betrifft |
|---|---|---|
| ~~E1~~ | **Entschieden 11.09.2026: 3** (drei Live-Läufe, siehe `basiswerte-block0.md` und `umsetzung-protokoll.md` Teil 3). Konfiguriert in `config/newsroom.php`. | 1a.2 |
| ~~E2~~ | **Empfehlung 01.09.2026: Rohzahlen** — kein Bodensatz, Verteilung symmetrisch, Einordnung gegen den Schnitt wäre wegen der Wachstumskurve falsch (siehe `basiswerte-block0.md`). | 1c.1 |
| E3 | Anzahl kostenloser Prüfläufe und Preis der weiteren in Credits | 1d.4 |
| E4 | Trägt die Veröffentlichungsmail den Magic-Link-Hinweis oder den Link auf die Infoseite; ein Element pro Mail | 1b.4, 1d.2 |
| E5 | Werden die bestehenden Ratgeberseiten konsolidiert oder ergänzt | 2.5 |
| E6 | Bleibt die Ablehnungsstrecke dauerhaft frei von kommerziellen Angeboten | 1d.1, 1d.6 |

---

## Leitplanken, die für alle Blöcke gelten

- Benachrichtigungen bleiben transaktional. Der Charakter der Mail wird rückwirkend von der Zielseite bestimmt: wird die Seite überwiegend Angebot, wird die Mail zur Anbahnung.
- Kein kostenpflichtiges Angebot im Moment der Ablehnung.
- Kostenpflichtige Inhaltsänderung nicht für syndizierte Meldungen, solange connektar write-once bleibt und kein kostenfreier Alternativweg existiert.
- Kein Verweis auf connektar als kostenfreier Änderungsweg.
- Bewertungslogik: Kategorien erklären, Gewichtungen und Schwellen nie.
- Noch nicht verfügbare Angebote werden als "BALD" gekennzeichnet, nicht weggelassen.
- Jede Maßnahme wird gegen die sieben Anti-Zombie-Zusagen geprüft, bevor sie live geht.