presseportale/docs/konzept/Konzept-Update 3 – Multi-Brand-Architektur (Hub & Spoke).md

Stand: Mai 2026 Zweck: Festlegung der Plattform-Architektur mit zentralem Hub (presseportale.com) und mehreren öffentlichen Brand-Portalen. Dokumentation der strategischen, technischen und Branding-Entscheidungen für die Entwicklung.

---

Architektur-Entscheidung

Die Plattform folgt einem Hub-and-Spoke-Modell:

• Ein zentraler Hub für alle Verwaltungs-, Veröffentlichungs- und Abrechnungs-Funktionen
• Mehrere öffentliche Brand-Portale, die unabhängige redaktionelle Marken mit eigener Zielgruppe und eigener Editorial-Anmutung darstellen
• Eine gemeinsame Codebase und Datenbank im Hintergrund

Das Modell entspricht der Architektur, mit der etablierte Verlagsgruppen (Axel Springer, Hubert Burda Media) ihre Markenportfolios technisch organisieren: ein zentrales Redaktions- und Tool-System, viele Frontend-Marken.

Strategische Vorteile

• Effiziente Entwicklung: Eine Codebase für alle Portale, Updates an Tools/Editor/Credit-System wirken portal-übergreifend
• Multi-Portal-Publishing: Publisher können Pressemitteilungen mit einem Klick auf mehreren Portalen veröffentlichen (verkaufbares Premium-Feature)
• Datenkonsistenz: Ein Account, ein Credit-Stand, eine Statistik-Aggregation über alle Portale
• Skalierbarkeit: Weitere Portale (z.B. branchenspezifisch) können als reine Frontend- und Konfigurations-Erweiterung hinzugefügt werden
• Saubere Trennung Marke vs. Funktion: Brand-Portale optimieren für Editorial-Glaubwürdigkeit, Hub für Funktion und Effizienz

---

Domain- und Verantwortungs-Aufteilung

presseportale.com – Hub (Publisher Hub)

Marke: Publisher Hub (mit Subline "Mein Pressekonto")

Funktion:

• User-Panel: Editor, Dashboard, Statistiken, Credit-Verwaltung, Newsroom-Konfiguration
• Admin-Panel: Review-Queue, Moderation, Inventory-Verwaltung, Editorial-Picks, User-Verwaltung
• Magic-Link-Bereich für Pressekontakte
• Account-Setup und Tarif-Auswahl (zentraler Veröffentlichungs-Funnel)
• Stripe-Integration, Rechnungen, Buchhaltung
• Alle KI-Tools (Lektorat, Pressetext-Optimierung, Bildgenerierung, etc.)

Branding: Neutrale, eigenständige Marke. Sauberes Tool-Design (aktuell Flux UI). Funktionsfokussiert. Brand-Kontext der Portale wird über Banner/Hinweise vermittelt, nicht über Farbadaption.

Zielgruppe: Publisher (Unternehmen, PR-Agenturen, Pressekontakte), Admins.

---

businessportal24.com – Brand-Portal

Marke: businessportal24

Funktion:

• Öffentliche Pressemitteilungs-Plattform
• Editorial-Anmutung mit Fokus auf Wirtschaft, B2B, Branchen-Tiefe
• Kein eigener User-Login-Bereich
• Reichweiten-Generierung über Newsletter, SEO, Branchenseiten

Branding: Eigenständige Editorial-Identität (Anthrazit + Orange-Akzent). Wirkt wie ein Wirtschaftsmedium, nicht wie ein Pressedienst.

Zielgruppe: Wirtschaftsjournalisten, Mediaplaner, B2B-Entscheider, Branchen-Experten.

---

presseecho.de – Brand-Portal

Marke: presseecho

Funktion: Wie businessportal24, aber mit anderer Markenidentität und potentiell anderer Zielgruppen-Ausrichtung. Konzeption folgt in eigener Iteration.

Branding: Eigenständig, klar unterscheidbar von businessportal24 (eigener Akzentton, eventuell anderer Editorial-Schwerpunkt).

Zielgruppe: noch zu definieren / komplementär zu businessportal24.

---

Login- und Session-Mechanik

Grundregel

Alle Authentifizierung läuft ausschließlich über presseportale.com. Brand-Portale haben keine eigenen Login-Formulare oder Auth-Bereiche.

Verhalten in den Brand-Portalen

• "Anmelden"-Button im Header eines Brand-Portals → Redirect auf presseportale.com (Login-Seite mit Rück-Redirect nach erfolgreicher Anmeldung)
• "Veröffentlichen"-Button → kurzer Brand-spezifischer Landing-Inhalt, dann Übergang auf presseportale.com für Account-Setup und Veröffentlichungs-Funnel
• Wenn der User über die Brand-Domain eingeloggt erkannt wird (über Cross-Domain-Mechanismus, siehe unten), erscheint im Header ein "Mein Account"-Element, das auf presseportale.com führt

Cross-Domain-Session

Da die Brand-Portale und der Hub auf unterschiedlichen Top-Level-Domains laufen (.com / .de), ist Cookie-basiertes Session-Sharing nicht möglich. Notwendige Lösung:

Variante A (empfohlen): Token-basierter Auth-Mechanismus über Laravel Sanctum

• Hub gibt nach Login ein API-Token aus
• Brand-Portale prüfen über API gegen den Hub den Login-Status
• Vorteil: sauber, standardkonform, skalierbar

Variante B: Lightweight-Cookie-Sync über Cross-Domain-Redirect bei Pageload (analog zu wie Single-Sign-On-Lösungen es machen)

• Komplexer, fehleranfälliger
• Nur zu empfehlen, falls Variante A nicht umsetzbar

Empfehlung: Variante A, da sie zum Laravel-Stack ohnehin passt und auch für die API-Anbindung von Distribution-Partnern (connektar etc.) wiederverwendbar ist.

Magic-Link-Flow

Magic-Links für Pressekontakte zeigen immer auf presseportale.com mit Brand-Kontext-Hinweis:

„Sie verwalten eine Pressemitteilung, die auf businessportal24 veröffentlicht wurde."

Brand-Logo und -Name werden im Hub-Header angezeigt, damit der Pressekontakt versteht, wo seine PM erscheint. Funktional bleibt der Flow zentral.

---

E-Mail-Strategie

Saubere Trennung nach Funktion:

System-Mails (von presseportale.com)

• Login, Password-Reset, Account-Bestätigung
• Magic-Link für Pressekontakte
• Stripe-Zahlungs-Bestätigungen, Rechnungen
• Credit-Aufladung-Bestätigungen, Auto-Refill-Hinweise
• Wartungs-/System-Benachrichtigungen

Absender: noreply@presseportale.com oder support@presseportale.com

Editorial- und Brand-Mails (von der jeweiligen Brand-Domain)

• "Ihre Pressemitteilung wurde auf businessportal24 veröffentlicht"
• Branchen-Newsletter (Tageszusammenfassung, Wochenrückblick, Branchen-Alerts)
• Newsroom-Update-Benachrichtigungen
• Reichweiten-Statistiken pro PM

Absender: redaktion@businessportal24.com, newsletter@businessportal24.com, analog für presseecho.de

Begründung

Diese Trennung stärkt das Branding der Portale (Editorial-Mails kommen "vom Magazin"), während Verwaltungs-Funktionen klar dem zentralen Hub zugeordnet bleiben. Funktional sind beide Domains technisch identisch hinterlegt (gleicher Mail-Service, gleiche Templates), nur die Absender-Konfiguration unterscheidet sich.

---

Datenmodell-Implikationen

Die Hub-and-Spoke-Architektur erfordert eine zentrale Tabelle für die Brand-/Portal-Zugehörigkeit:

brands (oder portals)
  - id, slug, name, domain
  - primary_color, accent_color
  - logo_url
  - editorial_email, newsletter_email
  - is_active, created_at

press_releases (Ergänzung)
  - + brand_id (FK auf brands)
  - + cross_published_to (JSON array of brand_ids, für Multi-Portal-Veröffentlichung)

placements (Ergänzung)
  - + brand_id (FK auf brands)
  - Placements gelten pro Portal, da Inventory portal-spezifisch ist

newsletters (Ergänzung)
  - + brand_id

accounts
  - Bleiben portal-übergreifend
  - Eine Person hat einen Account, kann auf allen Portalen veröffentlichen
  - Sub-Berechtigungen pro Brand möglich (für Agency-Tarif: Marke X nur auf Portal Y)

credit_accounts
  - Bleiben portal-übergreifend, ein Credit-Pool für alles

Wichtige Logiken

• Pressemitteilungen sind immer einem Brand zugeordnet (brand_id), können aber zusätzlich auf andere Brands "cross-published" werden
• Branchen, Kategorien und Tags können entweder portal-spezifisch oder portal-übergreifend definiert sein – Empfehlung: portal-übergreifender Stamm, mit Möglichkeit zur portal-spezifischen Untergliederung
• Placements/Boost-Slots sind grundsätzlich portal-spezifisch (jeder Top-Slot auf businessportal24 ist ein anderer Slot als auf presseecho)
• Aggregierte Statistiken im Dashboard zeigen alle Brands eines Publishers zusammen, mit Filter-Möglichkeit pro Brand

---

Brand-übergreifende Features

Aktuell (Migrations-Phase)

Im Dashboard werden Pressemitteilungen aktuell gefiltert nach Portal angezeigt. Hintergrund: Die beiden Portale kommen aus separater Legacy-Entwicklung, eine getrennte Sicht erleichtert die Migration.

Mittelfristig

Cross-Sichtbarkeit als Standard:

• Dashboard zeigt alle PMs eines Publishers portal-übergreifend
• Filter-Möglichkeit pro Portal vorhanden, aber nicht Standard
• Statistiken aggregieren über alle Portale

Multi-Portal-Veröffentlichung als Premium-Feature:

• Beim Einreichen einer PM kann der Publisher auswählen, auf welchen Portalen sie erscheinen soll
• Standard: Hauptportal des Publishers
• Optional: Zusatz-Portale (kostet zusätzliche Credits oder ist in höheren Tarifen inkludiert)
• Wettbewerber können das nicht – starkes Verkaufsargument

Portal-übergreifender Newsroom:

• Premium-Publisher haben einen Newsroom auf jedem Portal, gepflegt aus einem zentralen Profil im Hub
• Logo, Beschreibung, Kontakt einmal pflegen – auf allen Portalen aktuell

---

Implikationen für die Veröffentlichen-Landingpage

Aus der Architektur folgt die Aufteilung der Veröffentlichen-Seite in zwei Ebenen:

Auf businessportal24.com/veroeffentlichen (Brand-Landing)

• Hero mit brand-spezifischem Wertversprechen (Wirtschafts-Fokus, B2B-Reichweite, Branchen-Tiefe)
• Konkrete Reichweiten-Zahlen für businessportal24 (Newsletter-Abos, Branchen-Traffic, ISIN-Coverage)
• Differenzierungs-Punkte speziell für dieses Portal
• Tarif-Teaser ("Ab 19 € pro Pressemitteilung", mit Link auf volle Übersicht)
• Soziale Beweise (Logos von Publishern, die businessportal24 nutzen)
• Direkter CTA "Jetzt veröffentlichen →" → zur zentralen Plattform auf presseportale.com

Auf presseportale.com/veroeffentlichen (Zentrale Funnel-Seite)

• Volle Tarif-Tabelle (Einzel / Starter / Business / Pro / Agency)
• Tool-Showcase (Lektorat, KI-Bilder, etc.)
• Erklärung des Multi-Portal-Konzepts ("Ein Account, mehrere Portale")
• Portal-Auswahl im Anmelde-Prozess ("Auf welchen Portalen möchten Sie veröffentlichen? businessportal24 / presseecho / beide")
• FAQ
• Account-Setup-Funnel

Analoge Struktur für presseecho.de

presseecho.de/veroeffentlichen folgt demselben Pattern, mit brand-spezifischem Inhalt und Übergang zum zentralen Funnel.

---

Footer-Verlinkung zwischen Hub und Brand-Portalen

Auf Brand-Portalen (Footer)

Im Footer-Bereich von businessportal24 und presseecho ein dezenter Link:

Für Publisher → Publisher Hub | Pressemitteilung einreichen | Tarife & Pakete

Bestehende Kunden steigen so direkt in den Hub ein, ohne sich die Hub-Domain merken zu müssen.

Auf dem Hub (Footer)

Im Footer von presseportale.com Verlinkung auf alle Brand-Portale:

Unsere Portale → businessportal24 (Wirtschaft & Branchen) | presseecho (...)

Schafft Transparenz und Vertrauen – sichtbar, dass es eine Plattform-Familie ist.

---

Branding-Strategie pro Bereich

Bereich	Primärfarbe	Anmutung	Charakter
presseportale.com	neutral (z.B. Anthrazit + zurückhaltender Akzent)	Tool / SaaS	sachlich, funktional, effizient
businessportal24.com	Anthrazit + Orange	Editorial / Wirtschaftsmedium	seriös, datendicht, B2B
presseecho.de	eigene Palette (z.B. Anthrazit + Blau oder Bordeaux)	Editorial / anderer Schwerpunkt	klar differenziert von businessportal24

Wichtig: Die Brand-Portale müssen optisch klar unterscheidbar sein, damit Leser nicht den Eindruck gewinnen, es sei "dasselbe in zwei Versionen". Empfehlung: gemeinsame typografische Sprache (Editorial-Serif für Headlines, gleiche Sans für UI), aber klar unterschiedliche Akzentfarben und sekundäre visuelle Elemente.

Der Hub bekommt eine eigene visuelle Sprache, die sich von beiden Brand-Portalen abhebt. Tendenziell: weniger Farbe, mehr Whitespace, Tool-orientierte Komponenten (Tabellen, Dashboards, Form-Bausteine). Aktuell auf Flux UI basierend – soll noch eigene Identität bekommen, ohne den Funktions-Charakter zu verlieren.

---

Migration und Roadmap

Phase 1 (laufend)

• Backend-Migration zu Laravel
• Zentrale brands-Tabelle als Grundlage anlegen
• Bestehende PMs der beiden Portale werden mit brand_id versehen
• Dashboard zeigt portal-getrennt (Migrations-Komfort)

Phase 2

• Hub auf presseportale.com mit User-Panel produktiv
• Magic-Link-Flow zentral aufgesetzt
• Erste Brand-Portal-Iteration (businessportal24) im neuen Design live
• Cross-Domain-Auth über Sanctum

Phase 3

• Zweites Brand-Portal (presseecho) im neuen Design live
• Cross-Sichtbarkeit im Dashboard
• Multi-Portal-Veröffentlichung als Feature aktiv

Phase 4 (mittelfristig)

• Aggregierte Statistiken portal-übergreifend
• Portal-übergreifender Newsroom
• Vorbereitung für drittes Portal (falls relevant)

---

Skalierungs-Argument

Die Architektur ist explizit auf Wachstum ausgelegt. Wenn in 12–24 Monaten ein drittes Portal sinnvoll wird (z.B. ein branchenspezifisches wie "energieportal.com" oder ein regional fokussiertes wie "presseportal-bayern.de"), bedeutet das technisch:

• Keine neue Codebase
• Keine neue Datenbank
• Kein neuer Auth-Mechanismus
• Kein neues Credit-System
• Nur: Frontend, Konfiguration in brands-Tabelle, Editorial-Setup

Damit wird die Investition in den Hub heute strukturell verteidigt – jede Stunde, die in den Hub investiert wird, zahlt auf jedes zukünftige Portal mit ein.

---

Offene Punkte / nächste Entscheidungen

• Cross-Domain-Auth final festlegen: Sanctum-Implementierung details, Token-Lebensdauer, Refresh-Strategie
• presseecho-Konzept: Markenidentität, Zielgruppe, Differenzierung zu businessportal24 klären
• Multi-Portal-Veröffentlichung – Pricing: wie wird Cross-Publishing verrechnet? Pro zusätzlichem Portal X Credits? In höheren Tarifen inkludiert? Wie sehen die Tier-Grenzen aus?
• Hub-Design eigenständig schärfen: aktuelles Flux-UI-Setup soll mehr Eigenständigkeit bekommen, ohne den funktionalen Charakter zu verlieren – eigenes Mini-Briefing nötig
• Footer-Verlinkungen zwischen den Portalen: konkrete Texte und Platzierungen finalisieren
• Übergang in den Brand-Portalen markieren: wenn ein User von businessportal24 auf den Hub springt – sichtbarer Übergangs-Indikator (Banner oben "Sie sind im Publisher Hub" mit Rück-Link)? Oder unauffällig? UX-Entscheidung steht aus