23 KiB
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 |
|---|---|---|---|
Basiswert Aufrufzahlen — abgeschlossen 21.09.2026: Kohorte „28–55 Tage" am Stichtag 21.09. = Median 122 (Presseecho, n 703) / 314 (Businessportal24, n 727); Fensterverteilung vom 01.09. und 21.09. in basiswerte-block0.md |
S | keine | |
Basiswert Ablehnungsquote je Quelle — erhoben 01.09.2026 (2,4 %, press-releases:rejection-rate, basiswerte-block0.md) |
S | keine | |
Tabelle conversion_events — gebaut, live seit 17.09.2026 (Protokoll Teil 2) |
S | keine | |
Herkunft auf dem Magic-Link-Token — gebaut (ConversionSource, Protokoll Teil 2) |
S | 0.3 | |
| Schreibstellen an den Zustandsänderungen — gebaut, letzte Stelle mit Block 1b (Protokoll Teil 2 und 3) | M | 0.3, 0.4 | |
Trichter je Quelle und Zeitraum — gebaut (conversion:funnel) |
S | 0.5 | |
| Aufbewahrungsfrist für Ereignisdaten festlegen und in der Datenschutzerklärung führen — 395 Tage seit 01.09.2026; Datenschutz-Abschnitt 5a am 21.09.2026 eingebaut (gilt für Aufrufe, Crawler- und Feed-Abrufe, Konversionsschritte) | 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 |
|---|---|---|---|
Trockenlauf-Bericht: wie viele Firmen fallen bei Zusammenführung über die Firmen-E-Mail zusammen, welche Adressen tragen mehrere Firmennamen — live 11.09.2026 (companies:merge-report) |
S | keine | |
Sammeladressen-Erkennung: Adresse mit mehr als [Schwellwert] abweichenden Firmennamen wird markiert und von der automatischen Zusammenführung ausgenommen — live 11.09.2026 (companies:classify-addresses, company_email_groups, E1 = 3) |
S | 1a.1 | |
Zusammenführung im Bestand mit gespeicherter Ursprungszuordnung, rückabwickelbar — live 15.09.2026: ~14 450 Adressen, ~18 100 Firmen aufgegangen, 13 236 Firmen both; 6 Slug-Kollisionen offen (companies:merge, companies:unmerge, companies:merges) |
M | 1a.2 | |
Laufende Zuordnung neuer API-Meldungen zu bestehendem Newsroom über die Firmen-E-Mail — gebaut 15.09.2026 (ApiNewsroomAssignment), Wirkung nach Deploy über companies:classify-addresses messen |
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.
Entschieden 15.09.2026 (1a.3): Es bleibt die Firma mit den meisten jemals veröffentlichten Meldungen, bei Gleichstand die ältere; leere Stammdaten werden aufgefüllt. Meldungen, Kontakte und Verknüpfungen wandern per company_id, jede Bewegung protokolliert (company_merges/company_merge_moves), rückabwickelbar mit companies:unmerge. Die wegfallende Firma wird soft-deleted, ihr Slug führt per 301 weiter. Der Überlebende wird both, wenn die Hälften auf verschiedenen Portalen lagen — das ist bei 77 % der Gruppen der Fall (Altsystem: eine Firma je Portal). Slug-Kollisionen werden übersprungen, nicht umbenannt. Details in umsetzung-protokoll.md Teil 3.
Entschieden 15.09.2026 (1a.4): Die Zuordnung greift im Alt-Vertrag POST /service/users/me/companies — connektar bekommt bei gleicher Firmen-E-Mail und gleichem Namen (Namensregel der Klassifizierung) die ID der bestehenden Firma zurück, der Vertrag (201 + Location) bleibt. Abweichende Namen unter einer Adresse bekommen wie bisher eine neue Firma (Agentur, neuer Kunde); nie-veröffentlicht-Adressen werden nie zugeordnet; bei Firma auf dem anderen Portal wird sie both, bei fremd belegtem Slug bleibt es beim alten Verhalten. Der API-Nutzer wird member der Firma. Nebenbefund: status = rejected im Altbestand heißt „offline genommen", nicht „abgelehnt" (83 000 davon mit Aufrufen) — Auswertungen dürfen das nicht als Ablehnung lesen.
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 |
|---|---|---|---|
| Sichtbarkeitsregel: Newsroom öffentlich erst ab der ersten veröffentlichten Meldung, sonst nur Datensatz — bestand; 15.09.2026 Rückbau im Cache vervollständigt | S | keine | |
Verwaltungszugang über Magic Link, unabhängig von der öffentlichen Sichtbarkeit — gebaut 15.09.2026: /newsroom/{slug}/verwalten, Link an die hinterlegte Firmen-E-Mail (maskiert), Herkunft profile_claim, Landung auf der Firmenseite; noch unverlinkt (→ 1b.4) |
M | 1a.4 | |
| Kostenlose Profilpflege: Beschreibung, Logo, Bilder, Pressekontakte — 15.09.2026: Beschreibung durch die Rot-Ebene, reiner Text ohne Links, Stufe 3 der Leiter wird hier geschrieben; Bilder zurückgestellt (BALD-Platzhalter) bis die Bild-Kennzeichnung angepasst ist | M | 1b.2 | |
Hinweis "Diesen Newsroom verwalten" auf der Profilseite und in der Veröffentlichungsmail — gebaut 15.09.2026 (E4: Hinweis unten in der Mail; Herkunft mail_publish läuft bis auf das Token durch) |
S | 1b.2 | |
| Rückbau: fällt ein Newsroom durch Löschung oder Depublizierung auf null Meldungen, verschwindet die öffentliche Seite mit — 15.09.2026: alle Admin-Wege (archivieren, Status ändern, löschen) leeren jetzt den Seiten-Cache | S | 1b.1 | |
Nicht erreichbare Newsrooms aus der Bounce-Suppression im Admin markieren, nicht beanspruchbar, aus allen Mailstrecken ausgenommen — gebaut 15.09.2026 inkl. der Suppression selbst: zentrale Sperrliste, Versand-Gate, SMTP-Pfad + Circuit Breaker, IMAP-Abholung mit DSN-Parser, Admin ▸ Mail-Sperrliste. Live, sobald bounce@pressekonto.com angelegt und in der .env eingetragen ist |
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
Abschnitt durch Anhang 1 (roadmap-anhang1-2026.md, 17.09.2026) ersetzt: 1c.0 Crawler-Protokoll, Stufe 1 ohne Google-Link, 1c.4 Search Console intern, 1c.6 KI-Abrufe. Stand dort.
| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| Absenderansicht je Meldung: Aufrufe im Verlauf, Indexierungsstatus, Einordnung gegen Portaldurchschnitt — gebaut 16.09.2026: Panel „Sichtbarkeit" auf der Meldungsseite, Tagesbalken 30/90 Tage (Ereignisse seit 17.07.2026, davor „keine Messung"), Rohzahlen nach E2; Indexierung in Variante B („in der Sitemap seit", Link auf die Google-Suche) — Search-Console-Abgleich (Variante A) bewusst ans Ende geschoben | M | 0.1 | |
Zugang zur Ansicht über Magic Link, auch ohne Konto — 16.09.2026: der Claim-Weg aus 1b.2 trägt jetzt die Meldung (pr) bis auf das Token, der Login landet auf ihr; Mail-Hinweis um „Aufrufe einsehen" erweitert, bleibt ein Element (E4) |
S | 1b.2 | |
| Newsroom-Übersicht mit allen Meldungen der Firma und Summenwerten — 16.09.2026: Firmenseite zeigt alle Meldungen der Firma (vorher nur eigene — Beansprucher sahen eine leere Liste), Aufrufe je Meldung und 30 Tage, Statistik-Panel echt | M | 1a.3, 1c.1 |
1d Infoseite und Prüfwerkzeug
| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
Hilfeseite ohne kommerziellen Anteil — gebaut 16.09.2026: /{edition}/gute-pressemitteilung (DE/EN), Anlass, Aufbau, Sprache, Prüfablauf, sieben Qualitätsdimensionen offen, Pressebilder; Sitemap + Hilfe-Center |
S | keine | |
Textbaustein in die Ablehnungsmail — 16.09.2026: Link auf dem Portal der Meldung, Herkunft mail_reject, nichts Kommerzielles (E6) |
S | 1d.1 | |
Abmeldemöglichkeit für Benachrichtigungen — 16.09.2026: für Empfänger ohne Konto (Pressekontakt, Firmen-E-Mail) adressbezogener Abmeldelink, Zustand als Unsubscribed in der Sperrliste; selbst angeforderte Anmeldelinks gehen weiter durch. Vorher zeigte der Link in API-Benachrichtigungen auf das Konto des Einlieferers |
S | Bounce-Suppression live | |
Prüfwerkzeug — E3 entschieden 16.09.2026: kein eigenständiges Werkzeug. Prüfung nur beim Freigeben, Ergebnis am Entwurf; „Zur Prüfung freigeben" mit Erklärung, was danach passiert; automatische Prüfung je Meldung max_automatic_attempts (3), danach geblockt in die Admin-Queue („Prüfung nötig"), Freischalten oder Kommentar, Automatik für die Meldung ab dann aus; Autor erhält beim Block die Mail „wird persönlich geprüft" (Nachtrag 16.09.) |
M | 1d.1 | |
| Bewertung einer bestehenden Meldung über Magic Link — mit 1c.2 erledigt: der Beansprucher sieht Ablehnungsgrund, KI-Stufe und Content-Score auf der Meldungsseite | S | 1d.4, 1b.2 | |
| Partnerbereich am Seitenende als BALD — 16.09.2026 am Ende von 1d.1 | 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 |
|---|---|---|---|
NewsArticle-Schema auf allen Meldungen, Organization-Schema auf Newsrooms — Grundgerüst seit Juli (379688f), 17.09.2026 ergänzt: gemeinsame @id zwischen NewsArticle.author und Newsroom-Organization, Publisher mit @id und Logo (App\Support\StructuredData) |
M | 1b.1 | |
| 2.2 | Aufnahme in Google News und Publisher Center prüfen und beantragen — technischer Teil 17.09.2026: News-Sitemap /sitemap-news.xml je Spoke (48 h, ≤ 1.000), in robots.txt; Publisher-Center-Anmeldung liegt beim Betreiber (Protokoll Teil 7) |
M | 2.1 |
Branchen- und Kategorie-Landingpages aus dem Archivbestand — 17.09.2026: Jahresarchiv je Branche /category/{slug}/archiv/{jahr} (34.600 Meldungen intern verlinkt, in der Sitemap), Jahresleiste auf der Branchenseite, Beschreibungen für alle 14 Kategorien (categories:seed-descriptions), Portalname im Titel |
M | keine | |
Transparenzseiten — 17.09.2026 nach Briefing, drei Seiten: was-kostet-eine-pressemitteilung (Modellvergleich ohne Namen, Prüfliste Folgekosten, eigene Zusagen, Rechenbeispiel mit gemischtem Ausgang), pressemitteilung-veroeffentlichen-ohne-abo, pressemitteilung-loeschen-oder-aendern-lassen (Meldeverfahren + Absatz für fremde Portale); keine fremden Zahlen |
S | keine — Nachtrag 17.09.2026 (Anhang 1): vierte Seite „kostenlos veröffentlichen" | |
Konsolidierung der Ratgeberseiten unter /de/presse/ — geschlossen 17.09.2026: Strecke existiert seit R3.2 nicht mehr, 301 auf /faq bleibt; Hilfe-Center trägt die Inhalte, jetzt auch in der Topleiste neben FAQ |
S | 1d.1 | |
| 2.6 | Outreach an Betreiber von Presseportal-Listen und Vergleichsartikeln — extern, in Arbeit (Betreiber, Stand 18.09.2026); Arbeitsregel, Ziele und Mustertext in Anhang 1, Abschnitt 5; nicht Teil der Umsetzung | M | 2.4 |
Auffindbarkeit für KI-Systeme: strukturierte Daten, klare Entitätszuordnung, llms.txt — 17.09.2026: /llms.txt je Host (Hub verweist auf beide Portale), Entitätszuordnung über 2.1 |
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 |
|---|---|---|---|
RSS-Feeds je Branche — gebaut 18.09.2026: /{edition}/feed und /{edition}/category/{slug}/feed (RSS 2.0, jüngste 50, inkl. Unterkategorien), Autodiscovery auf Start-, Branchen- und Archivseiten, Link in der Archiv-Leiste, Block im Panel „Auslieferung", Hub leitet aufs Portal; 21.09.2026: Feed je Newsroom (/newsroom/{slug}/feed), Übersichtsseite /rss (Was ist RSS, wie abonnieren, alle Feeds), „RSS" in der Topleiste; Abruf-Protokoll feed_fetches (Reader-Dienst, gemeldete Abonnenten, keine IP) mit Block im Admin-Bericht und Abrufzahl im Panel (Protokoll Teil 11) |
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 — Code fertig 15.09.2026, produktiv mit Postfach bounce@pressekonto.com + MAIL_RETURN_PATH + BOUNCE_IMAP_* |
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 |
|---|---|---|
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 | |
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 | |
Entschieden 16.09.2026: keine Credits. Prüfung ist Teil der Freigabe, nicht ein Werkzeug; N automatische Läufe je Meldung (einstellbar, 3), danach Mensch, Automatik für die Meldung aus. Gelb geht weiter automatisch online, yellow_to_manual_queue bleibt als Schalter (Vorgabe aus). |
1d.4 | |
| Entschieden 15.09.2026: der Magic-Link-Hinweis, am Ende der Mail, als Hinweis, nicht als Angebot. Umgesetzt in 1b.4. Der Link auf die Infoseite (1d.2) bekommt damit keinen Platz in der Veröffentlichungsmail — ein Element pro Mail. | 1b.4, 1d.2 | |
Geschlossen 17.09.2026: bleibt bei FAQ, kein Slug-Mapping. Werden die bestehenden Ratgeberseiten konsolidiert oder ergänzt — Befund 17.09.2026: /de/presse/* leitet seit R3.2 auf /faq; offen ist nur, ob Schreib-Slugs stattdessen auf /gute-pressemitteilung zeigen sollen (Protokoll Teil 7) |
2.5 | |
| Entschieden (umgesetzt 16.09.2026, abgehakt 18.09.2026): ja, dauerhaft. Hilfeseite und Ablehnungsmail ohne kommerziellen Anteil; Partnerbereich nur als BALD am Seitenende. | 1d.1, 1d.6 | |
| Entschieden 17.09.2026 (Anhang 1): keine kostenfreie Einreichung, dauerhaft | 2.4, 2.6 | |
| E8 | Kundenansicht des Indexierungsstatus — gebaut, zu (GSC_CUSTOMER_VISIBLE); Prüfung läuft seit 17.09.2026 täglich, Entscheidung, sobald die Verteilung belastbar ist (Anhang 1) |
1c.5 |
| Entschieden 18.09.2026: Zuordnung je Kategorie wie vorgeschlagen, Mechanismus aktiv (Anhang 2, Protokoll Teil 10) | 1c.8 | |
| Entschieden 18.09.2026: Portale führen (presseecho), API-Doku beim Hub, Rechtstexte je Host (Anhang 2, Protokoll Teil 10) | 2.4 |
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.