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