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