29-05-2026 Optimierungen Fixes am Code
This commit is contained in:
parent
e8c47b7553
commit
4bb9094207
31 changed files with 5141 additions and 76 deletions
|
|
@ -0,0 +1,509 @@
|
|||
|
||||
|
||||
**Datum:** 12. Mai 2026 **Status:** Technisches Implementierungs-Konzept **Tech-Stack:** Laravel 12+, Livewire 4 / Volt, Tailwind CSS (v4), Alpine.js (über Livewire) **Bezug:** Konzept-Update 3 (Multi-Brand-Architektur), Konzept-Update 4 (Positionierung), Brand-Landing-Konzept businessportal24
|
||||
|
||||
> **IST-Stand 21.05.2026**: Multi-Brand-Architektur ist umgesetzt
|
||||
> (`config/domains.php`, `ThemeServiceProvider`, getrennte Vite-Builds
|
||||
> `portal` + `web`). Die Hub-Migration des User Backends ist als
|
||||
> eigene Roadmap in `dev/frontend/hub-flux/` dokumentiert (Phasen 0–7
|
||||
> abgeschlossen, Phase 8 in Planung). Der hier beschriebene Brand-Context
|
||||
> wird ueber `View::share()` global aufgeloest.
|
||||
|
||||
---
|
||||
|
||||
## 1. Leitprinzipien
|
||||
|
||||
Vier Regeln, an denen sich jede technische Entscheidung in diesem Dokument messen muss:
|
||||
|
||||
1. **Ein Codebase, viele Brands.** Kein Branch pro Portal, keine duplizierten Views. Differenzierung über Konfiguration, CSS-Variablen und gezielte View-Overrides.
|
||||
2. **Brand-Awareness zentral aufgelöst, nicht in Komponenten verteilt.** Eine Komponente fragt nicht „bin ich auf businessportal24?". Sie konsumiert eine `$brand`-Context-Variable und rendert entsprechend.
|
||||
3. **Livewire/Volt nur wo nötig.** Statische Komponenten bleiben pures Blade. Reaktivität ist ein Kostenfaktor (Server-Roundtrips, Hydration, State-Management) – sie muss verdient werden.
|
||||
4. **Solo-tauglich heißt: jede Entscheidung muss in 6 Monaten noch verständlich sein.** Lieber explizit als clever.
|
||||
|
||||
## 2. Brand-Auflösung (Multi-Tenant-Pattern)
|
||||
|
||||
### Brand-Resolution-Pipeline
|
||||
|
||||
```
|
||||
Request → Middleware → BrandResolver → Brand-Context im Container
|
||||
→ View-Pfad-Override
|
||||
→ Config-Override
|
||||
→ Layout-Auswahl
|
||||
```
|
||||
|
||||
**Schritt 1: Domain-Mapping**
|
||||
|
||||
Die `brands`-Tabelle aus Update 3 enthält pro Brand mindestens:
|
||||
|
||||
- `slug` (z.B. `businessportal24`, `presseecho`, `hub`)
|
||||
- `primary_domain` (z.B. `businessportal24.com`)
|
||||
- `theme_key` (z.B. `bp24`, `pe`) – Verweis auf CSS-Token-Set
|
||||
- `config_path` (z.B. `brands/businessportal24.php`)
|
||||
- `is_publisher_hub` (boolean)
|
||||
-ist zu prüfen, teils schon im System angelegt!
|
||||
|
||||
**Schritt 2: Middleware**
|
||||
|
||||
```php
|
||||
// app/Http/Middleware/ResolveBrand.php
|
||||
public function handle(Request $request, Closure $next): Response
|
||||
{
|
||||
$brand = Cache::rememberForever(
|
||||
"brand.domain.{$request->getHost()}",
|
||||
fn() => Brand::query()
|
||||
->where('primary_domain', $request->getHost())
|
||||
->orWhereJsonContains('aliases', $request->getHost())
|
||||
->firstOrFail()
|
||||
);
|
||||
|
||||
app()->instance(Brand::class, $brand);
|
||||
View::share('brand', $brand);
|
||||
Config::set('brand', $brand->config());
|
||||
|
||||
return $next($request);
|
||||
}
|
||||
```
|
||||
|
||||
Cache ist hier wichtig – die Domain-zu-Brand-Auflösung passiert bei jedem Request. `rememberForever` mit explizitem Cache-Bust beim Brand-Update.
|
||||
-ist zu prüfen, teils schon im System angelegt!
|
||||
|
||||
**Schritt 3: Brand im Container**
|
||||
|
||||
Jede Klasse kann via Dependency Injection auf die aktuelle Brand zugreifen:
|
||||
|
||||
```php
|
||||
public function __construct(private Brand $brand) {}
|
||||
```
|
||||
|
||||
In Blade-Templates ist `$brand` durch `View::share()` direkt verfügbar.
|
||||
|
||||
### Lokale Entwicklung
|
||||
|
||||
Lokal arbeiten mit `.test`-Domains in Docker (devserver) auf dem Server via Treafik:
|
||||
|
||||
- `businessportal24.test`
|
||||
- `presseecho.test`
|
||||
- `pressekonto.test`
|
||||
|
||||
Alle zeigen auf dieselbe Codebase, die Middleware löst per Hostname auf. Keine Subdomains, keine Port-Tricks – schmerzfreies lokales Multi-Brand-Setup.
|
||||
|
||||
## 3. Theming-System (Tailwind v4 + CSS Custom Properties)
|
||||
|
||||
### Empfehlung: Tailwind v4
|
||||
|
||||
Falls die Migration auf v4 noch offen ist: **jetzt machen**. Die `@theme`-Direktive in v4 macht Multi-Brand-Theming dramatisch einfacher als das v3-Config-Konstrukt. Native CSS-Variablen, keine PostCSS-Akrobatik mehr.
|
||||
|
||||
### Token-Architektur
|
||||
|
||||
Drei Ebenen (Beispiel ):
|
||||
|
||||
```css
|
||||
/* Ebene 1: Globale Design-Tokens (markenneutral) */
|
||||
@theme {
|
||||
--font-serif: 'Source Serif 4', Georgia, serif;
|
||||
--font-sans: 'Inter', system-ui, sans-serif;
|
||||
|
||||
--spacing-section: 5rem;
|
||||
--spacing-section-tight: 3rem;
|
||||
|
||||
--radius-card: 2px; /* fast keine Rundungen, editorial */
|
||||
}
|
||||
|
||||
/* Ebene 2: Semantische Tokens (markenneutral, aber rollenbasiert) */
|
||||
:root {
|
||||
--color-text-primary: var(--brand-text);
|
||||
--color-text-muted: var(--brand-text-muted);
|
||||
--color-surface: var(--brand-surface);
|
||||
--color-accent: var(--brand-accent);
|
||||
--color-cta-bg: var(--brand-cta-bg);
|
||||
--color-cta-fg: var(--brand-cta-fg);
|
||||
--color-hub-transition: var(--brand-hub-bg);
|
||||
}
|
||||
|
||||
/* Ebene 3: Brand-spezifische Werte */
|
||||
[data-brand="businessportal24"] {
|
||||
--brand-text: #1a1a1a;
|
||||
--brand-text-muted: #6b6b6b;
|
||||
--brand-surface: #fafaf7; /* warmer off-white */
|
||||
--brand-accent: #d94e1f; /* gedämpftes Orange */
|
||||
--brand-cta-bg: #d94e1f;
|
||||
--brand-cta-fg: #ffffff;
|
||||
--brand-hub-bg: #1a2540; /* dunkelblau, Störer */
|
||||
}
|
||||
|
||||
[data-brand="presseecho"] {
|
||||
--brand-text: #f0f0e8;
|
||||
--brand-text-muted: #a0a098;
|
||||
--brand-surface: #1f2620; /* dunkelgrün-anthrazit */
|
||||
--brand-accent: #5a8a6b; /* gedämpftes Grün */
|
||||
--brand-cta-bg: #5a8a6b;
|
||||
--brand-cta-fg: #ffffff;
|
||||
--brand-hub-bg: #1a2540; /* Hub-Farbe bleibt konstant! */
|
||||
}
|
||||
```
|
||||
|
||||
### Brand-Aktivierung im Layout
|
||||
|
||||
```blade
|
||||
{{-- resources/views/layouts/brand.blade.php --}}
|
||||
<!DOCTYPE html>
|
||||
<html lang="de" data-brand="{{ $brand->slug }}">
|
||||
<head>
|
||||
@vite(['resources/css/app.css', 'resources/js/app.js'])
|
||||
{{-- Brand-CSS wird im app.css via @import geladen, oder optional separat: --}}
|
||||
@if($brand->has_custom_css)
|
||||
<link rel="stylesheet" href="{{ asset("themes/{$brand->slug}.css") }}">
|
||||
@endif
|
||||
</head>
|
||||
<body class="bg-[var(--color-surface)] text-[var(--color-text-primary)]">
|
||||
{{ $slot }}
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
**Wichtig:** Der `data-brand`-Attribut auf `<html>` ist der einzige Hebel, der den gesamten Look umschaltet. Alle Tailwind-Utilities, die brand-spezifische Werte nutzen, greifen über CSS-Variablen darauf zu.
|
||||
|
||||
### Pragmatische Tailwind-Nutzung
|
||||
|
||||
Die Komponenten schreiben **nicht** `bg-orange-600` (das wäre brand-spezifisch im Markup festgenagelt). Stattdessen:
|
||||
|
||||
```blade
|
||||
<button class="bg-[var(--color-cta-bg)] text-[var(--color-cta-fg)] hover:opacity-90">
|
||||
Mitteilung einreichen
|
||||
</button>
|
||||
```
|
||||
|
||||
Oder noch sauberer mit eigenen Tailwind-Utility-Klassen, die in `app.css` definiert werden:
|
||||
|
||||
```css
|
||||
@layer components {
|
||||
.btn-cta {
|
||||
@apply bg-[var(--color-cta-bg)] text-[var(--color-cta-fg)]
|
||||
px-6 py-3 rounded-sm font-medium hover:opacity-90 transition;
|
||||
}
|
||||
.btn-hub {
|
||||
@apply bg-[var(--color-hub-transition)] text-white
|
||||
px-8 py-6 block;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
So bleibt das Markup brand-agnostisch und die Stilfragen zentralisiert.
|
||||
|
||||
## 4. Komponenten-Hierarchie und Engine-Wahl
|
||||
|
||||
### Drei Render-Modi, drei Anwendungsbereiche
|
||||
|
||||
|Modus|Wann verwenden|Performance|Beispiele|
|
||||
|---|---|---|---|
|
||||
|**Blade Component**|Statisches Markup, keine Interaktion|⚡⚡⚡|TopBar, Footer, PressItem, StatsRow|
|
||||
|**Volt (Single-File)**|Lokaler State, einfache Reaktivität, Lifecycle einfach|⚡⚡|AdHocTicker, HeroSlider, Search|
|
||||
|**Klassisches Livewire**|Komplexe Komponenten mit Services, Events, mehrere Methoden|⚡|PressEditor, NewsroomDashboard|
|
||||
|
||||
### Volt: konkrete Empfehlung
|
||||
|
||||
Volt ist für dieses Projekt **die richtige Wahl als Default für reaktive Komponenten** – aber nicht für statische. Die Gründe:
|
||||
|
||||
**Pro Volt:**
|
||||
|
||||
- Single-File-Komponenten: PHP-Logik + Blade-Template + Tailwind-Klassen in einer Datei. Solo-Entwickler-Freundlichkeit ist hoch.
|
||||
- Funktionale API ist deutlich weniger Boilerplate als klassische Livewire-Klassen.
|
||||
- Volt-Komponenten lassen sich genau wie Livewire-Komponenten lazy-laden (`<livewire:lazy ...>`), was für Above-the-fold-Performance wichtig ist.
|
||||
|
||||
**Kontra Volt:**
|
||||
|
||||
- Für reine Display-Komponenten ist Volt overkill. Eine `<x-press-item>` ohne State soll keine Livewire-Komponente sein – Hydration und Wire-Tracking sind unnötige Kosten.
|
||||
- Wenn eine Komponente Services injiziert, ein eigenes Test-Setup braucht oder mehr als ~150 Zeilen wächst, ist eine klassische Livewire-Klasse besser strukturierbar.
|
||||
|
||||
**Faustregel:**
|
||||
|
||||
> Renderst du HTML ohne Server-Interaktion? → Blade Component. Brauchst du `wire:model`, `wire:click`, Polling oder reaktiven State? → Volt. Wird die Komponente komplex, hat Services, eigene Tests? → Klassisches Livewire.
|
||||
|
||||
### Konkrete Komponenten-Inventur aus den Screens
|
||||
|
||||
Aufgeschlüsselt nach Engine. Das ist die direkte Übersetzung der Screens in technische Bausteine:
|
||||
|
||||
#### Blade-Komponenten (statisch, hochfrequent wiederverwendet)
|
||||
|
||||
```
|
||||
<x-brand.top-bar> -- Wirtschafts-Ticker, Sprachen, Newsletter/RSS
|
||||
<x-brand.header> -- Logo, Suche, CTAs
|
||||
<x-brand.rubriken-nav> -- Hauptnavigation (Wirtschaft, Tech, Finanzen...)
|
||||
<x-brand.footer> -- Footer mit Cross-Brand-Hinweis
|
||||
|
||||
<x-press.item> -- Standard-Listen-Eintrag mit Slots für Varianten
|
||||
<x-press.item-hero> -- Große Hero-Variante
|
||||
<x-press.item-sidebar> -- Kompakte Sidebar-Variante (mit Nummerierung)
|
||||
<x-press.byline> -- Quelle · Zeit · Lesezeit (wiederverwendbar)
|
||||
|
||||
<x-ui.section-header> -- "§ 01" + Label + H2 (das Editorial-Pattern)
|
||||
<x-ui.stats-row> -- Drei-/Vier-Spalten-Statistik
|
||||
<x-ui.button> -- CTA-Button mit Varianten (primary, secondary, hub)
|
||||
<x-ui.badge> -- Branchen-Marker, "Geprüft"-Label
|
||||
|
||||
<x-hub.transition-block> -- DER dunkelblaue Störer (siehe Briefing)
|
||||
<x-hub.cta> -- Inline Hub-CTA (Variante des Störers)
|
||||
|
||||
<x-quality.standard-footer> -- "Alle Pressemitteilungen werden geprüft..."
|
||||
```
|
||||
|
||||
#### Volt-Komponenten (reaktiv, isolierter State)
|
||||
|
||||
```
|
||||
<livewire:ad-hoc-ticker /> -- Auto-refresh alle 30s, Polling
|
||||
<livewire:hero-slider /> -- 3 Top-Meldungen, auto-rotate mit Alpine
|
||||
<livewire:press-search /> -- Suche im Header
|
||||
<livewire:press-list-filter /> -- "Alle · Heute · Diese Woche" Tabs
|
||||
<livewire:newsroom-list /> -- Newsroom-Sidebar mit "heute aktiv" Polling
|
||||
<livewire:branchen-index /> -- Live-Werte mit ± Indikatoren
|
||||
<livewire:termine-week /> -- Termine-Karussell mit Wochen-Navigation
|
||||
```
|
||||
|
||||
#### Klassisches Livewire (komplex, services)
|
||||
|
||||
```
|
||||
PressSubmissionForm -- Mehrstufige Einreichung (auf Hub)
|
||||
NewsroomManager -- Profil-Verwaltung (auf Hub)
|
||||
AdminReviewQueue -- Redaktions-Tool (auf Hub)
|
||||
```
|
||||
|
||||
Auffällig: die **Brand-Portale brauchen kaum klassisches Livewire**. Das ist konsistent zur Architektur aus Update 3 – Brand-Portale sind primär Lese-Oberflächen, der State liegt im Hub.
|
||||
|
||||
## 5. Brand-Differenzierung in Komponenten
|
||||
|
||||
Drei Mechanismen, in aufsteigender Eingriffstiefe:
|
||||
|
||||
### 5a. Konfiguration über Brand-Config
|
||||
|
||||
Der einfachste Fall: eine Komponente verhält sich anders je nach Brand-Konfiguration. (Beispiel)
|
||||
siehe: config/domains.php
|
||||
|
||||
```php
|
||||
|
||||
return [
|
||||
'name' => 'businessportal24',
|
||||
'tagline' => 'Pressemitteilungen · DACH',
|
||||
'press_item_layout' => 'timeline', // vs. 'topic'
|
||||
'show_market_ticker' => true,
|
||||
'show_branchen_index' => true,
|
||||
'hero_variant' => 'top-meldung', // vs. 'topic-cluster'
|
||||
'rubriken' => ['Wirtschaft', 'Technologie', /* ... */],
|
||||
];
|
||||
|
||||
|
||||
return [
|
||||
'name' => 'presseecho',
|
||||
'tagline' => 'Branchen-Pressearchiv',
|
||||
'press_item_layout' => 'topic',
|
||||
'show_market_ticker' => false,
|
||||
'show_branchen_index' => false,
|
||||
'hero_variant' => 'topic-cluster',
|
||||
'rubriken' => [/* andere Reihenfolge, andere Schwerpunkte */],
|
||||
];
|
||||
```
|
||||
|
||||
Komponenten lesen daraus:
|
||||
|
||||
```blade
|
||||
@if($brand->config('show_market_ticker'))
|
||||
<x-brand.market-ticker />
|
||||
@endif
|
||||
|
||||
<x-press.item :layout="$brand->config('press_item_layout')" :item="$item" />
|
||||
```
|
||||
|
||||
**Das ist die häufigste Form der Differenzierung** – und sie reicht für ~80 % aller Fälle.
|
||||
|
||||
### 5b. Slots und Defaults in Komponenten
|
||||
|
||||
Wenn eine Komponente strukturell gleich ist, aber Inhalte/Sprache abweichen:
|
||||
|
||||
```blade
|
||||
{{-- resources/views/components/hub/transition-block.blade.php --}}
|
||||
@props([
|
||||
'title' => $brand->config('hub_cta.title') ?? 'Pressemitteilung einreichen',
|
||||
'description' => $brand->config('hub_cta.description'),
|
||||
'buttonText' => $brand->config('hub_cta.button') ?? 'Zum Publisher-Bereich',
|
||||
])
|
||||
|
||||
<aside class="btn-hub flex flex-col gap-4">
|
||||
<h3 class="text-xl font-medium">{{ $title }}</h3>
|
||||
<p class="text-white/80">
|
||||
{{ $description ?? $slot }}
|
||||
</p>
|
||||
<a href="{{ route('hub.submit', ['brand' => $brand->slug]) }}"
|
||||
class="btn-cta inline-flex items-center gap-2 w-fit">
|
||||
{{ $buttonText }}
|
||||
<span aria-hidden="true">↗</span>
|
||||
</a>
|
||||
</aside>
|
||||
```
|
||||
|
||||
Brand-Texte stehen in Config, Komponente bleibt eine.
|
||||
|
||||
### 5c. View-Override pro Brand (Eskalations-Pfad)
|
||||
|
||||
Für die seltenen Fälle, in denen eine Brand wirklich ein anderes Markup braucht: Laravel kann View-Pfade brand-spezifisch erweitern.
|
||||
|
||||
```php
|
||||
// app/Providers/BrandServiceProvider.php
|
||||
public function boot(): void
|
||||
{
|
||||
$this->app['view']->prependLocation(
|
||||
resource_path("views/themes/{$brand->slug}")
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Dann sucht Laravel View-Dateien zuerst unter `resources/views/themes/presseecho/components/press/item.blade.php`, dann unter dem Standard-Pfad. **Nur** für die Komponenten, die wirklich anders sein müssen, wird eine Override-Datei angelegt.
|
||||
|
||||
> **Disziplin-Regel:** View-Overrides sind die letzte Eskalationsstufe. Erst versuchen, mit Config + Slots auszukommen. Override-Dateien verdoppeln Wartungsaufwand – jeder Bugfix muss mehrfach gemacht werden.
|
||||
|
||||
## 6. Datei-Struktur (Beispiel, siehe akutelle Struktur und optimiere falls nötig )
|
||||
|
||||
```
|
||||
app/
|
||||
├── Brand/
|
||||
│ ├── Brand.php # Eloquent Model
|
||||
│ ├── BrandManager.php # Service, im Container
|
||||
│ └── BrandResolver.php # Domain → Brand
|
||||
├── Http/
|
||||
│ └── Middleware/
|
||||
│ └── ResolveBrand.php
|
||||
├── Livewire/
|
||||
│ ├── Brand/ # Brand-Portal-spezifisch
|
||||
│ │ ├── AdHocTicker.php
|
||||
│ │ ├── HeroSlider.php
|
||||
│ │ └── PressSearch.php
|
||||
│ └── Hub/ # Hub-spezifisch
|
||||
│ ├── PressSubmissionForm.php
|
||||
│ └── NewsroomManager.php
|
||||
├── View/
|
||||
│ └── Components/
|
||||
│ ├── Brand/
|
||||
│ ├── Press/
|
||||
│ ├── Hub/
|
||||
│ ├── Ui/
|
||||
│ └── Quality/
|
||||
└── Providers/
|
||||
└── BrandServiceProvider.php
|
||||
|
||||
config/
|
||||
└── brands/
|
||||
├── businessportal24.php
|
||||
├── presseecho.php
|
||||
└── hub.php
|
||||
|
||||
resources/
|
||||
├── css/
|
||||
│ ├── app.css # Tailwind base + semantische Tokens
|
||||
│ └── themes/
|
||||
│ ├── businessportal24.css # Brand-Tokens (optional separat)
|
||||
│ └── presseecho.css
|
||||
├── js/
|
||||
│ └── app.js
|
||||
└── views/
|
||||
├── layouts/
|
||||
│ ├── brand.blade.php # Brand-Portal-Layout
|
||||
│ └── hub.blade.php # Hub-Layout
|
||||
├── components/ # Standard-Komponenten
|
||||
│ ├── brand/
|
||||
│ ├── press/
|
||||
│ ├── hub/
|
||||
│ ├── ui/
|
||||
│ └── quality/
|
||||
├── livewire/ # Volt-Komponenten
|
||||
│ ├── ad-hoc-ticker.blade.php
|
||||
│ ├── hero-slider.blade.php
|
||||
│ └── press-search.blade.php
|
||||
├── pages/ # Konkrete Seiten-Templates
|
||||
│ ├── home.blade.php
|
||||
│ └── veroeffentlichen.blade.php
|
||||
└── themes/ # NUR Brand-Overrides
|
||||
└── presseecho/
|
||||
└── components/
|
||||
└── ... # nur was wirklich anders ist
|
||||
```
|
||||
|
||||
## 7. Performance-Strategie
|
||||
|
||||
Vier konkrete Hebel, die in dieser Reihenfolge ausgeschöpft werden:
|
||||
|
||||
**1. Aggressive View-Caching für statisches Markup.** Press-Listen, Newsroom-Sidebars, Statistik-Zeilen können mit Tag-basiertem Cache gepuffert werden. Neue Mitteilung → relevante Tags invalidieren.
|
||||
|
||||
```php
|
||||
Cache::tags(['press_list', "brand.{$brand->slug}"])
|
||||
->remember('home.aktuelle-meldungen', now()->addMinutes(5), fn() => /* ... */);
|
||||
```
|
||||
|
||||
**2. Volt-Komponenten lazy laden, wo sinnvoll.** Below-the-fold-Komponenten (Branchen-Index, Termine, Newsroom-Liste) als `lazy`:
|
||||
|
||||
```blade
|
||||
<livewire:branchen-index lazy />
|
||||
```
|
||||
|
||||
Sie laden erst beim Scroll, blockieren nicht das initiale Render.
|
||||
|
||||
**3. Asset-Pipeline: ein Bundle, alle Brands.** Über die CSS-Variablen-Strategie ist kein Per-Brand-Build nötig. Ein Vite-Build, der für alle Brands gilt. Spart Komplexität und Cache-Invalidierung.
|
||||
|
||||
**4. Brand-Resolution cachen.** Die Domain-zu-Brand-Auflösung ist `rememberForever` (siehe Middleware). Cache-Bust nur beim Brand-Update über Model-Observer.
|
||||
|
||||
## 8. Migration der Bestands-Inhalte
|
||||
|
||||
Quer zu allem oben: die ~100.000 Bestandsmitteilungen sind im neuem System migriert! Drei Punkte, die das Komponenten-Design beeinflussen:
|
||||
|
||||
- **`<x-press.item>` muss tolerant gegenüber unvollständigen Daten sein.** Alte Mitteilungen haben evtl. keine Lesezeit-Schätzung, keine Branchen-Zuordnung, keine sauberen Bilder. Komponente rendert auch dann sauber.
|
||||
- **Permalink-Stabilität.** Die alte URL-Struktur muss erhalten bleiben (Strategie-Dokument: Tombstone-Modell). Das ist ein Routing-Thema, kein Komponenten-Thema – aber die Komponenten dürfen keine URLs hardcoden, sondern nur `route()`-Helpers nutzen.
|
||||
- **Brand-Zuordnung der Bestände.** Wie in Update 3 festgelegt: am Start ist jede Mitteilung beiden Brands zugewiesen. Komponenten brauchen dafür keine Sonderlogik – sie filtern nach Brand-Kontext, und der Pool ist eben (am Anfang) für beide Brands derselbe.
|
||||
|
||||
## 9. Entwicklungs-Reihenfolge (Empfehlung)
|
||||
|
||||
Konkrete Bauplan-Sequenz, die früh nutzbare Ergebnisse liefert:
|
||||
|
||||
**Sprint 1 – Fundament**
|
||||
|
||||
- Brand-Model, Middleware, Resolver
|
||||
- Theming-Setup (Tailwind v4, CSS-Variablen, zwei Brand-Themes)
|
||||
- Layout `brand.blade.php`
|
||||
- Grundlegende UI-Komponenten (`button`, `badge`, `section-header`)
|
||||
|
||||
**Sprint 2 – Statisches Markup für businessportal24**
|
||||
|
||||
- TopBar, Header, RubrikenNav, Footer
|
||||
- `<x-press.item>` und seine Varianten
|
||||
- StatsRow, QualityStandardFooter
|
||||
- Statische Version der Veröffentlichen-Landing (ohne Reaktivität)
|
||||
|
||||
**Sprint 3 – Reaktive Komponenten**
|
||||
|
||||
- AdHocTicker (Volt + Polling)
|
||||
- HeroSlider (Volt + Alpine)
|
||||
- PressList mit Filter-Tabs
|
||||
- Hub-Transition-Block mit Cross-Domain-Auth-Übergabe
|
||||
|
||||
**Sprint 4 – Hub-Anbindung**
|
||||
|
||||
- Sanctum-Setup für Cross-Domain
|
||||
- Hub-Routing für `?brand=businessportal24`-Parameter
|
||||
- Einreichungs-Flow im Hub (klassisches Livewire)
|
||||
|
||||
**Sprint 5 – Zweite Brand aufschalten**
|
||||
|
||||
- `presseecho.test` lokal
|
||||
- Brand-Config für presseecho
|
||||
- Erste Override-Komponente: `topic-cluster`-Hero
|
||||
- Testen: was funktioniert ohne Override, was braucht eines?
|
||||
|
||||
Ab Sprint 5 wird die eigentliche Stresstest-Frage beantwortet: **Hält die Architektur, wenn die zweite Brand wirklich anders aussehen soll?** Wenn an Sprint 5 viele Overrides nötig werden, ist die Config-Schicht zu dünn – dann iterieren.
|
||||
|
||||
## 10. technische Punkte
|
||||
|
||||
- **Tailwind v4:** wenn das Projekt noch nicht migriert ist, sollte das _vor_ Sprint 1 entschieden werden. v4 macht das CSS-Variablen-Setup deutlich eleganter.
|
||||
- **Sanctum-Cookie-Domain für Cross-Domain-Auth:** Detail aus Update 3, muss vor Sprint 4 final geklärt sein. Same-Site-Strategie, SPA-Mode oder klassischer Token-Flow?
|
||||
- **CDN/Asset-Hosting:** Brand-Bilder, Press-Item-Fotos – kommen vom Hub
|
||||
- **Translations:** DACH-Sprachschalter auf der Startseite –(de (ohne parameter) / de-at / de-ch / en) ist eine reine Inhalts-Filterung. Bei Mehrsprachigkeit de/en: i18n-Setup
|
||||
- **Polling-Frequenzen:** AdHocTicker, Newsroom-Liste – wie oft refreshen, ohne dass die Server-Last bei wachsendem Traffic problematisch wird? Anfangswerte: Ticker 30s, Newsroom 60s, Branchen-Index 5 min.
|
||||
|
||||
---
|
||||
|
||||
_Dieses Konzept ist die technische Brücke zwischen Architektur (Update 3), Positionierung (Update 4) und Implementation. Es legt fest, wie Komponenten strukturiert werden, damit die Brand-Differenzierung skaliert – ohne in eine Codebase-Duplikation zu kippen. Anpassungen sollten dokumentiert und mit den Update-Dokumenten abgeglichen werden._
|
||||
290
docs/konzept/Konzept Presseportal – Marktposition & Hebel.md
Normal file
290
docs/konzept/Konzept Presseportal – Marktposition & Hebel.md
Normal file
|
|
@ -0,0 +1,290 @@
|
|||
|
||||
**Stand:** Mai 2026 **Portale:** presseecho.de, businessportal24.de **Zweck:** Strategisches Leitkonzept zur Differenzierung gegenüber Wettbewerbern und zur schrittweisen Reaktivierung der beiden übernommenen Portale.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ausgangslage
|
||||
|
||||
Zwei übernommene Pressekonto, über 10 Jahre alt, mit zusammen rund 100.000 archivierten Pressemitteilungen. Frontend nicht responsive, Backend technisch veraltet. Aktive Bestandskunden vorhanden, größerer inaktiver Stamm. Aktuell ca. 50 % des Traffics über connektar.de als Distribution-Partner.
|
||||
|
||||
Relaunch in Umsetzung: Laravel-Backend mit 1:1-Datenmigration, neues Tailwind-basiertes Frontend, schrittweise Markendifferenzierung der beiden Portale.
|
||||
|
||||
**Entwicklung:** Solo, neben Hauptberuf, mit KI-gestützter Entwicklung. **Laufende Kosten:** Minimal (Hetzner-Server ~10 €/Monat). **Existenzdruck:** Keiner. Projekt ist optionales Nebeneinkommen.
|
||||
|
||||
---
|
||||
|
||||
## 2. Marktposition: bewusste Nische statt Konkurrenz
|
||||
|
||||
### Ehrliche Einschätzung des Marktes
|
||||
|
||||
Klassische Pressekonto verlieren redaktionelle Relevanz, behalten aber SEO-Funktion. Käufer buchen Pressemitteilungen heute nicht mehr für Journalistenanrufe, sondern für:
|
||||
|
||||
1. Backlinks und SEO-Substanz
|
||||
2. Google-Sichtbarkeit zu konkreten Suchbegriffen
|
||||
3. Digitale Sichtbarkeit (Investoren, Partner, Bewerber finden aktuelle PMs)
|
||||
4. Inhalte für eigene Newsroom-Seiten
|
||||
|
||||
Wettbewerber wie openPR und Pressebox kommunizieren weiterhin das alte Versprechen („Reichweite zu Journalisten") und sind in Lock-in-Modellen, Vertriebsstrukturen und Distributions-Verträgen gefangen.
|
||||
|
||||
### Eigene Positionierung
|
||||
|
||||
**„Pressemitteilungen für digitale Sichtbarkeit – ehrlich, fair, ohne Lock-in."**
|
||||
|
||||
Keine Massenabdeckung. Keine aggressive Skalierung. Eine ruhige, durchdachte Alternative, die genau die Käufer anspricht, die mit dem klassischen Modell unzufrieden sind.
|
||||
|
||||
### Strukturelle Vorteile gegenüber Wettbewerbern
|
||||
|
||||
- Niedrige Fixkosten → keine Notwendigkeit für aggressive Tarifmodelle
|
||||
- Solo-Entwicklung → schnelle, ehrliche Produktentscheidungen ohne Vertriebs-Druck
|
||||
- 100.000 PMs Archiv + gewachsene Domain-Autorität → nicht reproduzierbares Asset
|
||||
- Kein Investorendruck → kann bewusst klein, nachhaltig und langfristig wachsen
|
||||
|
||||
---
|
||||
|
||||
## 3. Realistische Erfolgsdefinition
|
||||
|
||||
**Erfolg heißt nicht:** Verdrängung der Marktführer, hohe Wachstumsraten, große Userzahlen.
|
||||
|
||||
**Erfolg heißt:**
|
||||
|
||||
- Stabiler Betrieb mit minimalen Fixkosten
|
||||
- Wachsender Stamm zufriedener Bestandskunden
|
||||
- Planbares monatliches Einkommen (mittelfristig 3.000–8.000 €)
|
||||
- Mit dem Alter: lukratives Nebeneinkommen
|
||||
- Verkaufbar, falls gewünscht
|
||||
|
||||
**Zeithorizont:** 3–5 Jahre für stabile Einkommensbasis.
|
||||
|
||||
---
|
||||
|
||||
## 4. Was wir bewusst NICHT machen
|
||||
|
||||
Diese Liste ist wichtiger als jede Feature-Roadmap. Sie schützt vor Entscheidungen in schwachen Momenten.
|
||||
|
||||
- **Keine Lock-in-Verträge** mit 12-Monats-Mindestlaufzeit
|
||||
- **Keine kostenlosen PMs** (zieht falsche Zielgruppe an)
|
||||
- **Keine Fake-Urgency** im Marketing („Nur noch 2 Plätze frei")
|
||||
- **Keine versteckten Gebühren** bei Standard-Korrekturen
|
||||
- **Keine Vermarktung als „Reichweite zu X Journalisten"** – ehrliches Versprechen statt PR-Floskeln
|
||||
- **Keine aggressiven Pop-ups** beim Verlassen
|
||||
- **Keine Newsletter-Pflichtanmeldung** im Bestellprozess versteckt
|
||||
- **Keine „Auf Anfrage"-Preisverschleierung** – klare Preise auf der Verkaufsseite
|
||||
|
||||
---
|
||||
|
||||
## 5. Differenzierungs-Hebel
|
||||
|
||||
### Hebel 1: Friction-freier Einstieg (sofort wirksam)
|
||||
|
||||
**Botschaft auf der Verkaufsseite:**
|
||||
|
||||
> „Keine Mindestlaufzeit. Monatlich kündbar. Faire Preise."
|
||||
|
||||
Direkter Konter gegen openPR (12 Monate Mindestlaufzeit, jährliche Vorauszahlung) und Pressebox (ähnliches Modell). Stärkster Hebel ohne Entwicklungsaufwand – reine Marketingbotschaft.
|
||||
|
||||
### Hebel 2: SEO-Substanz und Vertrauen herausstellen
|
||||
|
||||
Auf der Verkaufsseite kommunizieren:
|
||||
|
||||
- „Online seit 2008"
|
||||
- „Über 100.000 Pressemitteilungen archiviert"
|
||||
- Domain-Autorität als Trust-Signal
|
||||
- Echte Aufrufzahlen pro PM (statt nur „Reichweite versprochen")
|
||||
|
||||
Wirkt bei B2B-Käufern stark, weil Vertrauen signalisiert wird – etwas, das KI-Tool-Plattformen mit 2 Jahren Marktpräsenz nicht liefern können.
|
||||
|
||||
### Hebel 3: Faires Korrektur- und Änderungsmodell
|
||||
|
||||
**Was Wettbewerber machen:** openPR berechnet 10 € pro Änderung, auch bei Tippfehlern.
|
||||
|
||||
**Was wir machen:**
|
||||
|
||||
- Tippfehler / Kontaktdaten-Korrekturen: kostenfrei (Self-Service)
|
||||
- Inhaltliche Korrektur: mit transparentem Korrekturhinweis
|
||||
- Updates: als Anhang an Original
|
||||
- Tombstone bei Löschung statt Hard-Delete (SEO-Erhalt)
|
||||
- Anonymisierung bei DSGVO-Anfragen ohne Diskussion
|
||||
|
||||
Adressiert echten Schmerz von Bestandskunden anderer Portale.
|
||||
|
||||
### Hebel 4: Smarte Add-ons mit Konversionslogik
|
||||
|
||||
Credit-System ermöglicht margenstarke Zusatzumsätze nach der Erstbuchung:
|
||||
|
||||
- Highlight-Buchung im Anschluss („7 Tage prominent platziert")
|
||||
- KI-Bildgenerierung
|
||||
- Cross-Post zwischen presseecho.de und businessportal24.de
|
||||
- KI-Quality-Check / Stilverbesserung
|
||||
- Newsletter-Erwähnung (wenn Newsletter aufgebaut)
|
||||
|
||||
### Hebel 5: Distribution über die richtigen Kanäle
|
||||
|
||||
**Falsch wäre:** Eigene Social-Media-Accounts der Portale aufbauen → kostet Zeit, baut keine Reichweite auf, kann Reputation schaden.
|
||||
|
||||
**Richtig ist:**
|
||||
|
||||
- **Share-Funktionen für Kunden:** Nach Veröffentlichung vorgefertigte Share-Texte für LinkedIn, X, Facebook, WhatsApp
|
||||
- **LinkedIn priorisieren:** B2B-Distribution läuft 2026 dort, nicht auf X
|
||||
- **Open-Graph- und Twitter-Card-Tags** sauber konfigurieren, damit geteilte Links gut aussehen
|
||||
- **Optional Phase 3:** kuratierter „Best of"-Channel mit harter KI-Score-Schwelle (>85), nur wenn Zeit dafür da ist
|
||||
|
||||
### Hebel 6: Brand-Schutz absichern
|
||||
|
||||
- DPMA-Marken für presseecho.de und businessportal24.de prüfen, ggf. anmelden (~290 € pro Wortmarke)
|
||||
- Google Ads Brand-Schutz-Kampagnen für eigene Portalnamen (~20–50 €/Monat)
|
||||
- Verhindert, dass Wettbewerber bei Markensuchen oben stehen
|
||||
|
||||
---
|
||||
|
||||
## 6. Preismodell (bewusst gegen den Markt)
|
||||
|
||||
|Tier|Preis|Pressemitteilungen|Inklusive|
|
||||
|---|---|---|---|
|
||||
|**Einzel**|29 € / Stück|1|Free-Stock, KI-Quali-Check|
|
||||
|**Starter**|19 €/Mo. oder 190 €/Jahr|3/Monat, weitere à 15 €|Free-Stock, KI-Quali|
|
||||
|**Business**|59 €/Mo. oder 590 €/Jahr|10/Monat|+ 1 Highlight, 5 Premium-Stock, 10 KI-Bilder|
|
||||
|**Pro**|119 €/Mo. oder 1.190 €/Jahr|unbegrenzt (Fair Use)|+ 3 Highlights, größere Kontingente, Priority|
|
||||
|**Agency**|249 €/Mo. oder 2.490 €/Jahr|unbegrenzt für bis zu 5 Marken|alles aus Pro × Marken, je weitere Marke 39 €/Mo.|
|
||||
|
||||
**Eckpunkte:**
|
||||
|
||||
- Alle Tarife monatlich kündbar
|
||||
- Jahrespreise mit ~15 % Rabatt
|
||||
- Credit-System für flexible Add-ons
|
||||
- Mengenrabatte ab 3 PMs in 30 Tagen (z. B. 20 % auf nächste PM)
|
||||
- Reaktivierungs-Gutschein für Bestandskunden zum Relaunch (z. B. 50 % auf nächste PM)
|
||||
|
||||
**Launch-Aktion:** „Erste PM für 9 € statt 29 €" – einmalig pro Account, neue Accounts auf gleiche Firma/E-Mail werden erkannt.
|
||||
|
||||
---
|
||||
|
||||
## 7. Akquise-Strategie
|
||||
|
||||
### Phase 1: Bestandskundenreaktivierung (sofort)
|
||||
|
||||
- Persönliche Kontaktaufnahme zu aktiven Bestandskunden (20 Telefonate vor Relaunch wertvoller als jedes Marketingkonzept)
|
||||
- Reaktivierungs-Mailing an inaktiven Stamm mit konkretem Gutschein
|
||||
- Realistischer Erwartungswert: 5–15 % Reaktivierung bei persönlicher Ansprache, 1–3 % bei Massenmail
|
||||
|
||||
### Phase 2: Organische Sichtbarkeit (mittelfristig)
|
||||
|
||||
- Saubere Migration ohne SEO-Verlust (saubere Redirects, Tombstone-Modell, schnelle Ladezeiten)
|
||||
- Bestandsarchiv als Long-Tail-Magnet pflegen
|
||||
- Content-Marketing über das Portal selbst (redaktionelle Übersichten, Branchen-Specials)
|
||||
|
||||
### Phase 3: Empfehlungsmarketing (langfristig)
|
||||
|
||||
- Empfehlungs-System: Bestandskunden bekommen Rabatt für gebrachte Neukunden
|
||||
- Funktioniert in B2B-Nischen besser als bezahltes Marketing, weil Empfehlungen das Vertrauensthema lösen
|
||||
|
||||
### Bezahlte Werbung – realistisch eingesetzt
|
||||
|
||||
- **Brand-Schutz** (Pflicht): Eigene Brandnames bei Google Ads buchen (~20–50 €/Monat)
|
||||
- **Long-Tail-Branchenkeywords** (Test): „Pressemitteilung [Branche] veröffentlichen" mit kleinem Budget (200–300 €/Monat) testen
|
||||
- **Nicht** auf Hauptkeywords wie „Pressemitteilung veröffentlichen" bieten – CPCs zu hoch, ROI bei Solo-Setup nicht gegeben
|
||||
|
||||
---
|
||||
|
||||
## 8. Connektar.de als Distribution-Partner
|
||||
|
||||
50 % des aktuellen Traffics läuft über connektar.de. Risiko und Asset zugleich.
|
||||
|
||||
**Strategie:**
|
||||
|
||||
- Weiterlaufen lassen, aber Abhängigkeit transparent machen
|
||||
- Eigenständige Akquise parallel aufbauen
|
||||
- Datenmodell vorbereiten: `source: distribution_partner`, separate Statistiken
|
||||
- Qualitäts-SLA tracken (KI-Ablehnungsrate)
|
||||
- Bei Bedarf in Zukunft: eigenes Kündigungsrecht bei Qualitätsproblemen verhandeln
|
||||
|
||||
---
|
||||
|
||||
## 9. Technisches Setup
|
||||
|
||||
- **Backend:** Laravel
|
||||
- **Frontend:** Tailwind, responsive
|
||||
- **Hosting:** Hetzner (~10 €/Monat)
|
||||
- **Deployment:** Ploi
|
||||
- **Tracking:** Umami self-hosted auf separater VM (DSGVO-konform, kein Cookie-Banner, kein Adblocker-Problem)
|
||||
- **Zusätzlich:** Serverseitiger Aufruf-Counter in Laravel für verlässliche PM-Statistiken
|
||||
|
||||
---
|
||||
|
||||
## 10. Phasen-Roadmap
|
||||
|
||||
### Phase 1 – MVP / Relaunch
|
||||
|
||||
- Backend-Migration auf Laravel
|
||||
- Responsive Frontend mit Tailwind
|
||||
- 1:1-Datenmigration der Bestands-PMs
|
||||
- Magic-Link-Login für Self-Service-Änderungen
|
||||
- Korrektur- und Tombstone-Modell
|
||||
- KI-Vorprüfung neuer PMs
|
||||
- Credit-System mit Tarifstruktur
|
||||
- Share-Buttons mit Open-Graph-Tags
|
||||
- Marketingbotschaft „Keine Mindestlaufzeit" prominent
|
||||
- Brand-Schutz-Kampagnen aktivieren
|
||||
- Bestandskundenreaktivierung
|
||||
|
||||
### Phase 2 – Konsolidierung (3–6 Monate nach Launch)
|
||||
|
||||
- Cross-Post zwischen den beiden Portalen
|
||||
- Highlight-Buchungen mit eleganter UX
|
||||
- KI-Score-Anzeige für Kunden (Transparenz)
|
||||
- Statistik-Dashboard für Kunden (eigene Aufrufzahlen)
|
||||
- Empfehlungsmarketing-System
|
||||
|
||||
### Phase 3 – Differenzierung (6–12 Monate)
|
||||
|
||||
- Schärfere Markentrennung presseecho.de vs. businessportal24.de
|
||||
- LinkedIn-Auto-Post für Pro/Agency-Tier
|
||||
- Optional: kuratierter Best-of-Social-Channel mit hoher Schwelle
|
||||
- Newsletter-Aufbau, Newsletter-Erwähnung als Add-on
|
||||
|
||||
### Phase 4 – Wachstum & Optimierung (laufend)
|
||||
|
||||
- Quartals-Rhythmus für kontinuierliche Verbesserungen
|
||||
- Bestandskunden regelmäßig befragen
|
||||
- Tarifmodell datenbasiert nachschärfen
|
||||
- Bei stabiler Basis: ggf. weitere Add-ons / Premium-Features
|
||||
|
||||
---
|
||||
|
||||
## 11. Erfolgskontrollen und Stopps
|
||||
|
||||
Klare Stopps definieren, um nicht im Zombie-Modus zu landen:
|
||||
|
||||
**Nach 9 Monaten Live-Betrieb prüfen:**
|
||||
|
||||
- Wachsender Bestandskundenstamm?
|
||||
- Planbarer monatlicher Umsatz erkennbar?
|
||||
- Connektar-Anteil sinkend (Eigenakquise zieht)?
|
||||
- Reaktivierungsrate alter Kunden im Erwartungsbereich?
|
||||
|
||||
**Falls keine positive Entwicklung sichtbar:**
|
||||
|
||||
- Konsolidierung auf eine Marke prüfen
|
||||
- Verkaufsoption prüfen
|
||||
- Reines Archiv-Modell mit minimaler Pflege erwägen
|
||||
- Kein „weiter so" aus Trägheit
|
||||
|
||||
**Anti-Zombie-Regel:** Mindestens einmal pro Quartal ein halber Tag „Was muss verbessert werden". Ohne Ausnahme.
|
||||
|
||||
---
|
||||
|
||||
## 12. Strategische Leitlinien zusammengefasst
|
||||
|
||||
1. **Nische besetzen, nicht konkurrieren.**
|
||||
2. **Modernes Verständnis von Pressemitteilungen** kommunizieren – digitale Sichtbarkeit, SEO, ehrliche Versprechen.
|
||||
3. **Friction-frei sein**, wo Wettbewerber Friction aufbauen (Mindestlaufzeit, Korrekturgebühren, intransparente Preise).
|
||||
4. **100.000 PMs als Asset** kommunizieren – nicht reproduzierbar.
|
||||
5. **Empfehlungsmarketing in B2B-Nische** ist langfristig stärker als bezahltes Marketing.
|
||||
6. **Geduld als Wettbewerbsvorteil** – kein Investorendruck heißt: organisch wachsen können.
|
||||
7. **Konsistenz schlägt Spektakel** – kleine kontinuierliche Verbesserungen, alle 6–12 Monate ein nennenswertes Feature.
|
||||
8. **Erfolg = stabiles Nebeneinkommen**, nicht Marktführerschaft.
|
||||
9. **Bewusste Selbstverpflichtung** auf das, was man nicht macht.
|
||||
10. **Bei jeder Feature-Entscheidung fragen:** Passt das zu einem ruhigen, fairen, durchdachten Portal – oder zu einem aggressiven Wachstums-Tool?
|
||||
|
||||
---
|
||||
|
||||
_Diese Strategie ist ein lebendes Dokument. Sie sollte mindestens einmal jährlich überprüft und an die tatsächliche Marktentwicklung angepasst werden._
|
||||
445
docs/konzept/Konzept-Update 1 – Überarbeitete Abschnitte.md
Normal file
445
docs/konzept/Konzept-Update 1 – Überarbeitete Abschnitte.md
Normal file
|
|
@ -0,0 +1,445 @@
|
|||
|
||||
Stand: Mai 2026 Zweck: Ersatz bzw. Ergänzung der Abschnitte 8, 9, 10 sowie neue Abschnitte zur Score-Architektur, Boost-Eligibilität und zum Tool-Loop. Datenmodell-Ergänzungen am Ende.
|
||||
|
||||
> **IST-Stand 21.05.2026**: Dieses Update beschreibt Phase-2/3-Themen.
|
||||
> Aktuell ist im Code **nichts** davon umgesetzt:
|
||||
>
|
||||
> - Keine Tarif-Stufen, kein Kontingent, keine Stripe-Anbindung.
|
||||
> - Kein Score, keine Boost-Eligibilitaet, kein Tool-Loop.
|
||||
> - Kein Auto-Refill, keine Credit-Pakete.
|
||||
>
|
||||
> Phase 8 baut lediglich einen **Quota-Stub** auf `users.press_release_quota`
|
||||
> und `press_release_quota_used_this_month` als Vorbereitung fuer das
|
||||
> Veroeffentlichungs-Modal. Das echte Tarif-Modul ersetzt diese Felder
|
||||
> spaeter. Plan-Doku: `docs/PHASE-8-USER-PANEL-PLAN.md`.
|
||||
|
||||
---
|
||||
|
||||
## 8. Preismodell – Tarife (überarbeitet)
|
||||
|
||||
### Grundlogik
|
||||
|
||||
Alle Tarife enthalten ein Kontingent an Pressemitteilungen sowie monatlich ausgeschüttete Bonus-Credits für Tools und Add-ons. Bonus-Credits aus Abos verfallen monatlich, gekaufte Credits bleiben 24 Monate gültig. So bleibt das Abo aktivierungsstark, ohne dass der Nutzer eigenes Geld verliert.
|
||||
|
||||
### Tier-Struktur
|
||||
|
||||
|Tier|Preis|PMs|Bonus-Credits/Mo.|Effektiver PM-Preis|Besonderheiten|
|
||||
|---|---|---|---|---|---|
|
||||
|**Einzel**|19 € / Stück|1|4 (verfallend nach 30 T)|19,00 €|Pay-as-you-go|
|
||||
|**Starter**|19 €/Mo. (190 €/Jahr)|3|12|6,30 €|Free-Stock, KI-Quality-Check|
|
||||
|**Business**|49 €/Mo. (490 €/Jahr)|10|30|4,90 €|Erweiterte Statistiken, optionaler Newsroom|
|
||||
|**Pro**|99 €/Mo. (990 €/Jahr)|unbegrenzt (Fair Use)|60|< 2 €|Eigener Newsroom, Priority, volles Statistik-Dashboard|
|
||||
|**Agency**|199 €/Mo. (1.990 €/Jahr)|unbegrenzt für 5 Marken|120|< 1 €|Multi-Redakteur-Workflow, API-Zugang, je weitere Marke 29 €/Mo.|
|
||||
|
||||
Jahrespreise mit ca. 17 % Rabatt eingebaut. Fair Use im Pro-Tarif: Soft-Cap 50 PMs/Monat.
|
||||
|
||||
### Mehrwerte im Vergleich
|
||||
|
||||
|Feature|Einzel|Starter|Business|Pro|Agency|
|
||||
|---|---|---|---|---|---|
|
||||
|Pressemitteilungen|1|3/Mo.|10/Mo.|unbegr.|unbegr. (5 Marken)|
|
||||
|Bonus-Credits|4 einmalig|12/Mo.|30/Mo.|60/Mo.|120/Mo.|
|
||||
|Free-Stock-Bilder|✓|✓|✓|✓|✓|
|
||||
|KI-Quality-Check|✓|✓|✓|✓|✓|
|
||||
|Erweiterte Statistiken|–|–|✓|✓|✓|
|
||||
|Eigener Newsroom|–|–|optional|inkl.|inkl.|
|
||||
|Priority-Support|–|–|–|✓|✓|
|
||||
|Multi-Redakteur-Workflow|–|–|–|–|✓|
|
||||
|API-Zugang|–|–|–|–|✓|
|
||||
|
||||
### Kommunikation
|
||||
|
||||
Die inkludierten Bonus-Credits sind Teil des Pakets, nicht zusätzliche Kosten. Reicht das Kontingent nicht (z. B. weil mehrere PMs mit aufwändigem Tooling veröffentlicht werden), kauft der Nutzer Credits nach – diese bleiben 24 Monate erhalten und schaffen langfristige Bindung an die Plattform.
|
||||
|
||||
### Bestandskunden
|
||||
|
||||
Aktive Jahresabos behalten Preis bis zum nächsten Verlängerungstermin. Loyalty-Bonus 10–20 % im ersten Verlängerungsjahr. Downgrade-Pfad anbieten.
|
||||
|
||||
### Einstiegsstrategie
|
||||
|
||||
In der Anfangsphase (erste 6–12 Monate nach Relaunch) bewusst günstiger einsteigen, um User-Base aufzubauen. Preise sind kalkuliert mit Spielraum für spätere Anpassung. Wichtig: Bestandskunden behalten ihre Konditionen.
|
||||
|
||||
---
|
||||
|
||||
## 9. Credit-System (überarbeitet)
|
||||
|
||||
### Grundregel
|
||||
|
||||
**1 Credit = 1 €** als Listenpreis-Anker. Alle Service-Preise werden in ganzen Credits ausgewiesen. Wer größere Pakete kauft, zahlt effektiv weniger pro Credit (Volumenrabatt), aber der Listenpreis bleibt stabil. So entfällt jede Kopfrechen-Übung im UI.
|
||||
|
||||
### Credit-Pakete
|
||||
|
||||
|Paket|Credits|Preis|Effektiv pro Credit|Ersparnis|
|
||||
|---|---|---|---|---|
|
||||
|Test|10|10 €|1,00 €|–|
|
||||
|Standard|50|45 €|0,90 €|10 %|
|
||||
|Plus|150|120 €|0,80 €|20 %|
|
||||
|Pro|500|375 €|0,75 €|25 %|
|
||||
|Business|1.500|1.050 €|0,70 €|30 %|
|
||||
|
||||
Ganzzahlige Beträge, keine Bruchteile im UI. Intern kann auf Cent-Ebene abgerechnet werden, aber nach außen sieht der Nutzer nur ganze Credits.
|
||||
|
||||
### Auto-Refill
|
||||
|
||||
Standardmäßig nach erstem Kauf aktiviert (mit Opt-Out):
|
||||
|
||||
- Trigger: bei < 10 Credits Restguthaben
|
||||
- Aufladung: zuletzt gekauftes Paket (Default Standard, 50 Credits)
|
||||
- Eindeutige Bestätigungs-Mail nach jeder automatischen Aufladung
|
||||
|
||||
### Gültigkeit
|
||||
|
||||
- Gekaufte Credits: 24 Monate ab Kauf
|
||||
- Bonus-Credits aus Abos: monatlich verfallend
|
||||
- Willkommens-Bonus (5 Credits einmalig bei Account-Anlage): 90 Tage
|
||||
|
||||
### Mini-Checkout (kontextuell)
|
||||
|
||||
1. User klickt z. B. „KI-Bild generieren"
|
||||
2. Modal: _„Kostet 4 Credits. Du hast 2 Credits."_
|
||||
3. Optionen:
|
||||
- „Schnell aufladen: Standard-Paket (50 Credits, 45 €)" – 1-Klick mit Saved Payment Method
|
||||
- „Anderes Paket wählen"
|
||||
- „Abbrechen"
|
||||
4. Nach Aufladung wird Aktion automatisch ausgeführt
|
||||
|
||||
### Erstkauf
|
||||
|
||||
Stripe Checkout mit `setup_future_usage` für Saved Payment Method. Danach 1-Klick-Aufladung.
|
||||
|
||||
### Dashboard
|
||||
|
||||
- Credit-Stand oben rechts immer sichtbar
|
||||
- Trennung sichtbar: Bonus-Credits (verfallend) vs. gekaufte Credits (24 Monate)
|
||||
- Verlauf einsehbar (was wofür verbraucht)
|
||||
- Rechnungs-PDFs für jede Aufladung
|
||||
|
||||
### Buchhaltung & Recht
|
||||
|
||||
- Credits = Vorauszahlung, bilanziell als Verbindlichkeit
|
||||
- MwSt-Behandlung mit Steuerberater abstimmen (Kauf vs. Verbrauch)
|
||||
- Verfall in AGB sauber dokumentieren
|
||||
- Keine Auszahlung in Geld (sonst PSD2-Lizenzthema)
|
||||
- EU-Auslandskunden: Reverse-Charge bei B2B mit USt-ID
|
||||
|
||||
---
|
||||
|
||||
## 10. Preisliste in Credits (überarbeitet)
|
||||
|
||||
Alle Preise in ganzen Credits (1 Credit = 1 €). Anker-Werte für die Startphase, iterativ anpassbar.
|
||||
|
||||
### Veröffentlichung
|
||||
|
||||
|Service|Credits|
|
||||
|---|---|
|
||||
|Standard-PM (Pay-as-you-go)|19|
|
||||
|PM-Korrektur (Pfad C)|8|
|
||||
|PM-Update (Pfad D)|4 _(im ersten Jahr ggf. kostenlos)_|
|
||||
|Depublizierung (Pfad G)|19–25|
|
||||
|
||||
### Bilder
|
||||
|
||||
|Service|Credits|
|
||||
|---|---|
|
||||
|Free-Stock (Unsplash, Pexels)|0|
|
||||
|Premium-Stock (Adobe, Shutterstock)|8|
|
||||
|KI-Bild generieren|4|
|
||||
|KI-Bild Re-Generation|2|
|
||||
|
||||
### KI-Textservices
|
||||
|
||||
|Service|Credits|
|
||||
|---|---|
|
||||
|Quality-Check (Stil/Pressestil)|3|
|
||||
|Lektorat|8|
|
||||
|Pressetext-Optimierung (Headlines, SEO)|15|
|
||||
|Headline-Booster (nur Headlines)|5|
|
||||
|PM aus Stichworten generieren|25|
|
||||
|Übersetzung (DE↔EN)|12|
|
||||
|
||||
### Platzierungen
|
||||
|
||||
|Service|Credits|
|
||||
|---|---|
|
||||
|Highlight Kategorie (3 Tage)|15|
|
||||
|Highlight Kategorie (7 Tage)|30|
|
||||
|Startseite-Highlight (24 h)|39|
|
||||
|Startseite-Highlight (3 Tage)|89|
|
||||
|Top-Slot Startseite (24 h)|119|
|
||||
|Newsletter-Erwähnung|59|
|
||||
|Social-Share (offizieller Kanal)|25|
|
||||
|
||||
Voraussetzung für alle Platzierungen: Mindest-Content-Score erreicht (siehe Abschnitt „Boost-Eligibilität").
|
||||
|
||||
### Distribution
|
||||
|
||||
|Service|Credits|
|
||||
|---|---|
|
||||
|PDF-Export mit Branding|2|
|
||||
|Social-Snippet-Generierung|3|
|
||||
|Verteiler-Versand (klein, branchenspezifisch)|39|
|
||||
|Verteiler-Versand (mittel)|99|
|
||||
|Verteiler-Versand (groß, branchenübergreifend)|199|
|
||||
|
||||
### Account / Profil
|
||||
|
||||
|Service|Credits|
|
||||
|---|---|
|
||||
|Verifiziertes Firmenprofil (einmalig)|79|
|
||||
|Custom Subdomain (pro Jahr)|49|
|
||||
|Erweiterte Statistiken (pro Monat)|15|
|
||||
|
||||
### Goodies (kostenlos, fördern Aktivität)
|
||||
|
||||
- PM-Updates kostenfrei im ersten Jahr (besseres Archiv)
|
||||
- 3 Free-Stock-Bilder pro PM
|
||||
- Erster KI-Quality-Check pro PM kostenfrei
|
||||
- 5 Credits Willkommens-Bonus bei Account-Anlage (90 Tage gültig)
|
||||
- Headline-Vorschlag (1 Variante) kostenfrei pro PM
|
||||
|
||||
---
|
||||
|
||||
## NEU – Abschnitt 15: Score-Architektur
|
||||
|
||||
Die Plattform arbeitet mit drei voneinander unabhängigen Scores. Sie haben unterschiedliche Funktionen, werden unterschiedlich berechnet und an unterschiedlichen Stellen wirksam. Die Trennung ist zentral, weil sie unterschiedliche Datenmodelle und Update-Logiken betrifft.
|
||||
|
||||
### 15.1 Klassifikations-Score (Eintritts-Filter)
|
||||
|
||||
**Funktion:** Entscheidet, ob eine Pressemitteilung überhaupt veröffentlicht wird.
|
||||
|
||||
**Bereich:** Grün / Gelb / Rot (kategorial)
|
||||
|
||||
**Faktoren:**
|
||||
|
||||
- Werbung statt Pressemitteilung
|
||||
- Beleidigend / diskriminierend
|
||||
- Rechtlich heikel
|
||||
- Spam-Muster
|
||||
- Unseriöse Versprechen
|
||||
|
||||
**Auswirkung:**
|
||||
|
||||
- Grün: Direkte Veröffentlichung (optional 5–10 Min Verzögerung)
|
||||
- Gelb: Manuelle Review-Queue
|
||||
- Rot: Zurück an User mit Begründung
|
||||
|
||||
**Aktualisierung:** Einmalig bei Einreichung. Bei Änderung der PM (Pfad C/D) wird neu klassifiziert.
|
||||
|
||||
**Speicherung:** `press_releases.classification` plus vollständiges Audit-Log in `ki_audits`.
|
||||
|
||||
### 15.2 Content-Score (Qualitäts-Indikator)
|
||||
|
||||
**Funktion:** Misst die handwerkliche Qualität einer Pressemitteilung. Bestimmt organische Sichtbarkeit und Boost-Berechtigung.
|
||||
|
||||
**Bereich:** 0–100 Punkte
|
||||
|
||||
**Faktoren (Vorschlag, iterativ verfeinerbar):**
|
||||
|
||||
|Kategorie|Gewichtung|Was zählt|
|
||||
|---|---|---|
|
||||
|Pressestil|20 %|Tonalität (informativ vs. werblich), passive vs. aktive Konstruktion, Zitate vorhanden|
|
||||
|Struktur|15 %|Lead-Absatz vorhanden, sinnvolle Absatzstruktur, Pyramidaler Aufbau|
|
||||
|Lesbarkeit|10 %|Flesch-Index für Deutsch, Satzlängen, Fachsprache angemessen|
|
||||
|Vollständigkeit|15 %|Pressekontakt, Unternehmensinfo, Datum, Branche, Region|
|
||||
|Bildmaterial|10 %|Mindestens 1 Bild, Auflösung, Alt-Text, Bildunterschrift|
|
||||
|Quellen / Belege|10 %|Verlinkungen, Studien-Referenzen, Datenquellen|
|
||||
|Headline-Stärke|10 %|Länge, Keyword-Relevanz, Klarheit|
|
||||
|Originalität|10 %|Kein Boilerplate, kein Duplicate-Content, individueller Ton|
|
||||
|
||||
**Auswirkung:**
|
||||
|
||||
- **Organische Sichtbarkeit:** Listing-Position, Top-Story-Kandidat, Newsletter-Aufnahme, Trending in Branche
|
||||
- **Boost-Berechtigung:** Schwellenwerte für kostenpflichtige Slots (siehe Abschnitt 16)
|
||||
- **User-Feedback:** Sichtbar im Editor-Dashboard mit konkreten Verbesserungsvorschlägen
|
||||
|
||||
**Aktualisierung:** Bei Einreichung berechnet, bei jeder Änderung der PM neu berechnet. History pro PM in `content_scores`.
|
||||
|
||||
**Speicherung:** `press_releases.content_score` (aktueller Wert), `content_scores` (History mit Faktor-Breakdown).
|
||||
|
||||
### 15.3 Trust-Score (Reputations-Indikator)
|
||||
|
||||
**Funktion:** Bewertet die Zuverlässigkeit eines Publishers über Zeit. Reduziert Moderationslast und kann öffentliche Anerkennung bringen.
|
||||
|
||||
**Bereich:** 0–100 oder Stufen (Bronze / Silber / Gold / Verifiziert)
|
||||
|
||||
**Faktoren:**
|
||||
|
||||
- Anzahl problemfrei veröffentlichter PMs
|
||||
- Durchschnittlicher Content-Score über alle PMs
|
||||
- Beschwerderate (Reports, Korrekturen, Depublizierungen)
|
||||
- Account-Alter
|
||||
- Verifikations-Status (verifiziertes Firmenprofil)
|
||||
|
||||
**Auswirkung:**
|
||||
|
||||
- **Moderation:** Lockerung der KI-Freigabe-Schwelle (mehr „Grün" automatisch)
|
||||
- **Sichtbarkeit (optional):** öffentliches Verifizierungs-Badge auf Newsroom und PM-Seiten
|
||||
- **Bevorzugung in Branchen-Übersichten** bei gleichem Content-Score
|
||||
- **Bei Trust-Verlust:** Rückfall in strengere Moderation (auch nach Beschwerden, häufigen Korrekturen, Depublizierungen)
|
||||
|
||||
**Aktualisierung:** Rollierend, z. B. nächtlicher Cron-Job über die letzten 90 Tage Aktivität.
|
||||
|
||||
**Speicherung:** `accounts.trust_score`, `accounts.trust_tier` (Bronze/Silber/Gold/Verifiziert), History in `trust_score_log`.
|
||||
|
||||
### Offene Detail-Entscheidungen
|
||||
|
||||
- Trust auf User- oder auf Firmen-Ebene? (Empfehlung: Firmen-Ebene, weil Mitarbeiter wechseln)
|
||||
- Trust-Verlust: ab welchen Schwellen?
|
||||
- Verifizierungs-Badge: nur über kostenpflichtigen Verifizierungs-Prozess oder auch durch Trust-Score erreichbar?
|
||||
|
||||
---
|
||||
|
||||
## NEU – Abschnitt 16: Boost-Eligibilität
|
||||
|
||||
Die Verbindung zwischen Score-System und kostenpflichtigen Sichtbarkeits-Slots. Grundprinzip: **Schlechter Content kann nicht in den Top-Slot gekauft werden.** Das schützt die redaktionelle Glaubwürdigkeit der Plattform und schafft den Anreiz, in Qualität zu investieren.
|
||||
|
||||
### Schwellenwerte je Slot-Typ
|
||||
|
||||
|Slot|Klassifikation|Min. Content-Score|
|
||||
|---|---|---|
|
||||
|Highlight Kategorie|Grün|50|
|
||||
|Startseite-Highlight (24h / 3 T)|Grün|65|
|
||||
|Top-Slot Startseite|Grün|75|
|
||||
|Newsletter-Erwähnung|Grün|70|
|
||||
|Social-Share (offizieller Kanal)|Grün|70|
|
||||
|Verteiler-Versand (extern)|Grün|80|
|
||||
|
||||
PMs mit Klassifikation Gelb können nicht boostbar werden, auch nicht nach manueller Freigabe – sie bleiben in regulärer Sichtbarkeit. PMs mit Klassifikation Rot werden nicht veröffentlicht und sind damit irrelevant.
|
||||
|
||||
### UI-Logik
|
||||
|
||||
Wenn ein User einen Boost-Slot bucht, dessen Schwelle seine PM nicht erreicht, sieht er statt des Buchungsformulars:
|
||||
|
||||
> _„Diese Pressemitteilung erreicht aktuell einen Content-Score von 60/100. Für den Top-Slot Startseite empfehlen wir mindestens 75 Punkte. So kannst du deinen Score verbessern:"_
|
||||
>
|
||||
> _[Pressetext-Optimierung – 15 Credits → +15–20 Punkte]_ _[Headline-Booster – 5 Credits → +3–7 Punkte]_ _[Bild hinzufügen – 4 Credits → +5–10 Punkte]_
|
||||
|
||||
Nach Tool-Anwendung wird der Score neu berechnet, der Slot kann dann gebucht werden.
|
||||
|
||||
### Effekt
|
||||
|
||||
Drei gewollte Konsequenzen:
|
||||
|
||||
1. **Plattform-Qualität bleibt hoch:** Premium-Slots zeigen nur qualitativ hochwertige Inhalte.
|
||||
2. **Tools werden indirekt verkauft:** Wer den Slot will, muss in Qualität investieren – entweder selbst oder über kostenpflichtige Tools.
|
||||
3. **Glaubwürdigkeit für Leser bleibt erhalten:** Leser und Journalisten erkennen schnell, dass sichtbar platzierte Inhalte tatsächlich relevant sind.
|
||||
|
||||
### Sonderfall: Editorial-Pick
|
||||
|
||||
Unabhängig vom Boost-System kann die Redaktion (intern) PMs als „Empfehlung der Redaktion" hervorheben. Das ist ein redaktionelles Instrument, kein kommerzielles, und nicht buchbar. Wirkt als Vertrauensanker auf der Startseite.
|
||||
|
||||
---
|
||||
|
||||
## NEU – Abschnitt 17: Tool-zu-Algorithmus-Loop
|
||||
|
||||
Der strategische Kern der Monetarisierungslogik. Der Loop verbindet drei Plattform-Ziele in einem geschlossenen System:
|
||||
|
||||
### Die drei Ziele
|
||||
|
||||
1. **Plattform-Qualität:** Hohe durchschnittliche Inhaltsqualität, damit Leser, Journalisten und Mediaplaner die Plattform als seriös wahrnehmen.
|
||||
2. **Monetarisierung:** Umsatz aus Tools, Tarifen und Boost-Slots.
|
||||
3. **Anreiz für Publisher:** Sichtbar gute Platzierungen für gute Inhalte als motivierender Faktor.
|
||||
|
||||
### Der Loop
|
||||
|
||||
```
|
||||
Publisher schreibt PM
|
||||
↓
|
||||
Content-Score wird berechnet (z. B. 55/100)
|
||||
↓
|
||||
Publisher will Top-Slot buchen (Schwelle 75)
|
||||
↓
|
||||
System empfiehlt: Pressetext-Optimierung (15 Credits)
|
||||
↓
|
||||
Tool wird angewendet, Score steigt auf 78
|
||||
↓
|
||||
Top-Slot wird gebucht (119 Credits)
|
||||
↓
|
||||
PM erscheint prominent auf Startseite
|
||||
↓
|
||||
Hohe Reichweite, gute Statistiken
|
||||
↓
|
||||
Publisher sieht Wert, kommt wieder
|
||||
↓
|
||||
Plattform-Durchschnittsqualität steigt
|
||||
↓
|
||||
Mehr Leser, mehr Wert für nächsten Boost-Käufer
|
||||
```
|
||||
|
||||
### Voraussetzungen für Funktionieren
|
||||
|
||||
- **Tools müssen tatsächlich gut sein.** Wenn das KI-Lektorat schlechter ist als das, was der Publisher selbst zustande bringt, kollabiert der Loop. → Tool-Qualität ist Wettbewerbsvorteil, hier wird investiert.
|
||||
- **Score-Verbesserung muss spürbar und nachvollziehbar sein.** Der Publisher muss verstehen, was sein Tool-Einsatz konkret gebracht hat. → Score-Breakdown sichtbar, Vorher-Nachher-Vergleich.
|
||||
- **Reichweite muss real sein.** Ein gekaufter Top-Slot muss tatsächlich Reichweite bringen. → Leser-Seite (Newsletter, SEO, Social) muss aktiv aufgebaut werden.
|
||||
- **Boost-Schwellen dürfen nicht zu hoch sein.** Sonst wird der Loop frustrierend statt motivierend. → Schwellen iterativ kalibrieren auf Basis realer Score-Verteilung.
|
||||
|
||||
### Was das für den Build bedeutet
|
||||
|
||||
- **Tools haben strategische Priorität.** KI-Lektorat, Pressetext-Optimierung, Headline-Booster sind nicht nur Add-ons, sondern das Herzstück der Wertschöpfung.
|
||||
- **Score-Anzeige muss früh implementiert werden.** Ohne sichtbaren Score kein Loop.
|
||||
- **Statistik-Dashboard ist Pflicht für mittlere Tarife.** Ohne sichtbare Reichweiten-Daten erkennen Publisher den Wert ihres Investments nicht.
|
||||
|
||||
---
|
||||
|
||||
## 13. Datenmodell-Skizze – Ergänzungen
|
||||
|
||||
Zusätzlich zu den bestehenden Tabellen aus dem Hauptkonzept:
|
||||
|
||||
```
|
||||
content_scores
|
||||
- id, press_release_id
|
||||
- score (0-100), version (bei Neuberechnung)
|
||||
- factors (JSON: pressestil, struktur, lesbarkeit, vollstaendigkeit,
|
||||
bildmaterial, quellen, headline, originalitaet)
|
||||
- calculated_at, calculation_reason (initial/edit/tool_applied)
|
||||
|
||||
placements
|
||||
- id, press_release_id, account_id
|
||||
- slot_type (kategorie_highlight, startseite_highlight, top_slot,
|
||||
newsletter, social_share, verteiler_klein/mittel/gross)
|
||||
- starts_at, ends_at
|
||||
- credits_spent
|
||||
- status (scheduled, active, completed, cancelled)
|
||||
- eligibility_check_passed (bool, snapshot bei Buchung)
|
||||
- eligibility_score_snapshot (Content-Score zum Zeitpunkt der Buchung)
|
||||
- created_at
|
||||
|
||||
placement_inventory
|
||||
- id, slot_type
|
||||
- max_concurrent (z.B. 1 für Top-Slot, 3 für Startseite-Highlight)
|
||||
- duration_options (JSON: [24h, 72h])
|
||||
- min_content_score (75)
|
||||
- min_classification ('green')
|
||||
|
||||
trust_score_log
|
||||
- id, account_id
|
||||
- score (0-100), tier (bronze/silber/gold/verifiziert)
|
||||
- factors (JSON: pm_count, avg_content_score, complaints,
|
||||
account_age_days)
|
||||
- calculated_at
|
||||
|
||||
accounts (Ergänzungen)
|
||||
- + trust_score (int, 0-100)
|
||||
- + trust_tier (enum)
|
||||
- + verified_business_profile (bool)
|
||||
- + verified_at
|
||||
```
|
||||
|
||||
Wichtige Logiken:
|
||||
|
||||
- **placement_inventory** definiert, wie viele Slots welcher Art parallel verfügbar sind. Bei Buchung wird geprüft: ist ein Slot für das gewünschte Zeitfenster frei? Wenn nicht: nächstmöglicher Termin anbieten oder ablehnen.
|
||||
- **eligibility_score_snapshot** auf Placement-Ebene: damit nachvollziehbar bleibt, mit welchem Score eine PM zum Buchungszeitpunkt qualifiziert war. Wenn der Score später sinkt (etwa durch Korrektur), bleibt der gebuchte Slot bestehen, aber bei Verlängerung wird neu geprüft.
|
||||
- **content_scores** mit Versionierung erlaubt nachträglich Auswertung: Welche Tools haben welchen Score-Effekt gehabt? Daten für Tool-Optimierung.
|
||||
|
||||
---
|
||||
|
||||
## Offene Punkte / nächste Entscheidungen (Update)
|
||||
|
||||
Zusätzlich zu den bereits dokumentierten Punkten:
|
||||
|
||||
- **Content-Score-Faktoren feinjustieren:** Welche Gewichtung passt für deutsche Pressemitteilungen? Iterativ kalibrieren mit echten Daten.
|
||||
- **Boost-Schwellen kalibrieren:** Erst nach 100–200 echten PMs sehen, wo die Score-Verteilung liegt. Schwellen ggf. anpassen.
|
||||
- **Trust-Score: User vs. Firma:** Empfehlung Firma, aber Detail-Logik bei Mitarbeiterwechsel klären.
|
||||
- **Tool-Qualität:** KI-Prompts für Lektorat und Pressetext-Optimierung müssen sehr sauber gebaut werden. Eigene Test-Suite mit Vorher/Nachher-PMs.
|
||||
- **Slot-Inventory:** Wie viele Top-Slots parallel? Empfehlung 1 (sonst verliert er an Wert), Startseite-Highlight 3, Kategorie-Highlight 5–10 je Branche.
|
||||
- **Editorial-Picks:** Wer wählt aus? Anfangs du selbst, später ggf. Redaktions-Account mit Frontend-Tool.
|
||||
197
docs/konzept/Konzept-Update 2 – Score-Stufen-System.md
Normal file
197
docs/konzept/Konzept-Update 2 – Score-Stufen-System.md
Normal file
|
|
@ -0,0 +1,197 @@
|
|||
|
||||
|
||||
Stand: Mai 2026 Zweck: Ersetzt die Außenkommunikation des Content-Scores durch ein dreistufiges System. Aktualisiert Abschnitt 15.2 (Content-Score) und Abschnitt 16 (Boost-Eligibilität) aus dem ersten Konzept-Update.
|
||||
|
||||
> **IST-Stand 21.05.2026**: Score-System und Stufen-Anzeige sind nicht
|
||||
> implementiert. Im Code gibt es weder ein `user_score`- noch ein
|
||||
> `company_score`-Modell. Das Thema bleibt fuer Phase 3.
|
||||
|
||||
---
|
||||
|
||||
## Hintergrund
|
||||
|
||||
Der Content-Score (0–100) bleibt als plattform-internes Steuerungsinstrument bestehen. Für die Außenkommunikation gegenüber Lesern wird die konkrete Punktzahl jedoch durch ein dreistufiges Stufen-System ersetzt. Gründe:
|
||||
|
||||
- Konkrete Punktzahlen wirken meta-fetischistisch und lenken vom Inhalt ab
|
||||
- Vergleichbarkeit zwischen PMs ("warum nur 67?") erzeugt Konflikte ohne Mehrwert
|
||||
- Goodhart's Law: Publisher würden auf die Zahl optimieren statt auf Qualität
|
||||
- Stufen sind kulturell etabliert (Nutri-Score, Stiftung Warentest) und sofort verständlich
|
||||
|
||||
Die Punktzahl bleibt dort erhalten, wo sie produktiv ist: im Editor während des Schreibens, im Publisher-Dashboard und in Boost-Buchungs-Dialogen.
|
||||
|
||||
---
|
||||
|
||||
## 15.2 Content-Score (überarbeitet)
|
||||
|
||||
### Score und Stufen
|
||||
|
||||
Der Content-Score (0–100) wird Plattform-intern unverändert berechnet. Für alle nach außen gerichteten Anzeigen gilt folgendes Mapping:
|
||||
|
||||
|Stufe|Score-Bereich|Bedeutung|
|
||||
|---|---|---|
|
||||
|**Standard**|30 – 59|Mindestqualität erreicht, regulär veröffentlicht|
|
||||
|**Geprüft**|60 – 79|Solide Pressemitteilung, gute Substanz, redaktionelle Standards eingehalten|
|
||||
|**Hochwertig**|80 – 100|Top-Qualität, redaktioneller Maßstab|
|
||||
|
||||
PMs unterhalb von Score 30 werden vom Klassifikations-Score (Grün/Gelb/Rot) abgefangen und entweder in die manuelle Review-Queue gegeben oder zurück an den Autor verwiesen. Auf der öffentlichen Plattform sind ausschließlich PMs ab Stufe Standard sichtbar.
|
||||
|
||||
Schwellenwerte sind als Anker zu verstehen und werden nach 100–200 echten PMs anhand der tatsächlichen Score-Verteilung kalibriert.
|
||||
|
||||
### Sichtbarkeit pro Stufe
|
||||
|
||||
Nicht jede Stufe wird gleich behandelt. Standard wird nicht beworben – weder als Badge noch als Label. Erst ab Stufe Geprüft erscheint sichtbar ein Vertrauensindikator. So wirkt das System nicht wie ein Stigma für Standard-PMs, sondern wie eine Auszeichnung für die besseren.
|
||||
|
||||
|Stufe|Auf Detailseite|In Listen|Im Newsletter-Filter|
|
||||
|---|---|---|---|
|
||||
|Standard|nichts angezeigt|nichts angezeigt|enthalten in "alle Meldungen"|
|
||||
|Geprüft|Häkchen-Icon mit Tooltip "Geprüfte Pressemitteilung"|optional kleines Häkchen-Icon|"Geprüfte Pressemitteilungen"|
|
||||
|Hochwertig|Label "Hochwertig" mit Stern-Icon|Stern-Icon neben Headline|"Hochwertige Pressemitteilungen"|
|
||||
|
||||
### Wo die Punktzahl sichtbar bleibt
|
||||
|
||||
Die genaue Punktzahl bleibt produktiv im geschützten Bereich:
|
||||
|
||||
**Im Editor während des Schreibens:**
|
||||
|
||||
> _"Aktueller Score: 67/100 – Stufe: Geprüft. Noch 13 Punkte bis 'Hochwertig'. So verbessern Sie Ihre Pressemitteilung:_ _• Bild hinzufügen (+5–10 Punkte)_ _• Zitat einbauen (+3–5 Punkte)_ _• Lead-Absatz präziser fassen (+2–4 Punkte)"_
|
||||
|
||||
**Im Publisher-Dashboard:**
|
||||
|
||||
- Score pro PM mit Stufenanzeige
|
||||
- Durchschnittsscore über alle PMs
|
||||
- Trend über Zeit
|
||||
- Score-Breakdown nach Faktoren
|
||||
|
||||
**In Boost-Buchungs-Dialogen:**
|
||||
|
||||
> _"Der Top-Slot Startseite erfordert Stufe 'Hochwertig' (Score 80+). Ihre Pressemitteilung erreicht aktuell Stufe 'Geprüft' (Score 67). So erreichen Sie 'Hochwertig':_ _[Pressetext-Optimierung – 15 Credits, +15–20 Punkte]_ _[Headline-Booster – 5 Credits, +3–7 Punkte]"_
|
||||
|
||||
---
|
||||
|
||||
## 16. Boost-Eligibilität (überarbeitet)
|
||||
|
||||
Boost-Schwellen werden von konkreten Punktzahlen auf Stufen umgestellt. Die Schwellen werden Plattform-intern weiterhin auf Score-Ebene geprüft, kommuniziert wird gegenüber Publishern aber die Stufe.
|
||||
|
||||
### Schwellenwerte je Slot-Typ
|
||||
|
||||
|Slot|Klassifikation|Mindeststufe|Entspricht Score|
|
||||
|---|---|---|---|
|
||||
|Highlight Kategorie|Grün|Standard|≥ 30|
|
||||
|Startseite-Highlight (24h / 3T)|Grün|Geprüft|≥ 60|
|
||||
|Top-Slot Startseite|Grün|Hochwertig|≥ 80|
|
||||
|Newsletter-Erwähnung|Grün|Geprüft|≥ 60|
|
||||
|Social-Share (offizieller Kanal)|Grün|Geprüft|≥ 60|
|
||||
|Verteiler-Versand (extern)|Grün|Hochwertig|≥ 80|
|
||||
|
||||
PMs mit Klassifikation Gelb können nicht boostbar werden, auch nicht nach manueller Freigabe – sie bleiben in regulärer Sichtbarkeit. PMs mit Klassifikation Rot werden nicht veröffentlicht.
|
||||
|
||||
### UI-Logik beim Buchen
|
||||
|
||||
Wenn ein User einen Boost-Slot bucht, dessen Schwelle seine PM nicht erreicht, sieht er statt des Buchungsformulars die Tool-Empfehlungen aus dem Editor-Dialog. Der konkrete Score wird hier sichtbar, weil der Publisher die Distanz zur nächsten Stufe verstehen muss, um eine wirtschaftliche Entscheidung zu treffen (Tool kaufen oder anders boosten).
|
||||
|
||||
---
|
||||
|
||||
## Differenzierung: Hochwertig-Stufe vs. Editorial-Pick
|
||||
|
||||
Beide sind Vertrauenssignale, aber konzeptionell unterschiedlich. Sie müssen visuell und sprachlich klar unterscheidbar sein.
|
||||
|
||||
||Hochwertig-Stufe|Editorial-Pick|
|
||||
|---|---|---|
|
||||
|**Vergabe**|algorithmisch (Score ≥ 80)|manuell durch Redaktion|
|
||||
|**Voraussetzung**|Content-Score|freie redaktionelle Auswahl|
|
||||
|**Häufigkeit**|viele PMs|wenige, ausgewählte PMs|
|
||||
|**Bezeichnung**|"Hochwertig"|"Auswahl der Redaktion"|
|
||||
|**Symbol**|Stern-Icon|orange Auszeichnung (wie auf Startseite)|
|
||||
|**Funktion**|Qualitätsindikator|redaktionelle Empfehlung|
|
||||
|
||||
Eine PM kann beide Auszeichnungen gleichzeitig tragen. In der Regel werden Editorial-Picks aus dem Pool der Hochwertig-PMs gewählt, aber das ist nicht zwingend – die Redaktion hat freie Hand.
|
||||
|
||||
---
|
||||
|
||||
## Außenkommunikation – Konkrete Labels und Texte
|
||||
|
||||
Damit das System Plattform-weit konsistent kommuniziert wird, hier die verbindlichen Texte und Labels:
|
||||
|
||||
### Detailseite – Metadaten-Zeile
|
||||
|
||||
Statt bisher "Qualität: Sehr hoch (94)":
|
||||
|
||||
- **Standard:** kein Label
|
||||
- **Geprüft:** Häkchen-Icon ✓ mit Tooltip "Geprüfte Pressemitteilung – redaktionelle Standards eingehalten"
|
||||
- **Hochwertig:** Stern-Icon ★ mit Label "Hochwertig" und Tooltip "Pressemitteilung mit besonders hoher Qualität"
|
||||
|
||||
### Newsletter-Block
|
||||
|
||||
Statt "Nur Meldungen ab Content-Score 80":
|
||||
|
||||
- **Tageszusammenfassung:** "Alle wichtigen Meldungen aus DACH"
|
||||
- **Wochenrückblick:** "Die wichtigsten Meldungen der Woche"
|
||||
- **Branchen-Alerts:** "Höchstens 2 Mails pro Woche. Nur hochwertige Pressemitteilungen aus dieser Branche."
|
||||
|
||||
### Erweiterte Suche – Filter
|
||||
|
||||
Filter-Optionen:
|
||||
|
||||
- "Alle Pressemitteilungen"
|
||||
- "Nur geprüfte Pressemitteilungen"
|
||||
- "Nur hochwertige Pressemitteilungen"
|
||||
- "Nur Auswahl der Redaktion"
|
||||
|
||||
### Vertrauens-Sektion auf der Plattform
|
||||
|
||||
Eine Erklärseite (z.B. /redaktion oder /qualitaet) erläutert das System öffentlich:
|
||||
|
||||
> _"Jede Pressemitteilung auf businessportal24 wird automatisch auf Qualität geprüft. Wir unterscheiden drei Stufen:_
|
||||
>
|
||||
> _• **Standard** – erfüllt unsere Mindestanforderungen für Pressemitteilungen_ _• **Geprüft** – solide Pressemitteilung mit guter Substanz_ _• **Hochwertig** – Pressemitteilung in redaktioneller Spitzenqualität_
|
||||
>
|
||||
> _Zusätzlich vergibt unsere Redaktion das Sigel 'Auswahl der Redaktion' für Pressemitteilungen, die wir besonders empfehlen."_
|
||||
|
||||
---
|
||||
|
||||
## Auswirkungen auf das Datenmodell
|
||||
|
||||
Geringe Änderungen, da Score weiterhin intern als Zahl gespeichert wird:
|
||||
|
||||
```
|
||||
press_releases (Ergänzung)
|
||||
- + content_tier (enum: standard, gepruft, hochwertig)
|
||||
– wird automatisch aus content_score abgeleitet
|
||||
– kann als generated column oder per Trigger gepflegt werden
|
||||
- + editorial_pick (bool, default false)
|
||||
- + editorial_pick_at, editorial_pick_by (für Audit)
|
||||
```
|
||||
|
||||
Die Stufen-Schwellen werden in einer zentralen Konfiguration gepflegt (z.B. `config/scoring.php` in Laravel), damit sie bei späterer Kalibrierung an einer Stelle anpassbar sind, ohne Code-Änderungen.
|
||||
|
||||
---
|
||||
|
||||
## Was unverändert bleibt
|
||||
|
||||
- **Content-Score (0–100)** wird intern weiterhin berechnet und gespeichert
|
||||
- **Score-Faktoren und Gewichtungen** bleiben wie in Abschnitt 15.2 des ersten Updates definiert
|
||||
- **Klassifikations-Score (Grün/Gelb/Rot)** bleibt unverändert als Eintritts-Filter
|
||||
- **Trust-Score** auf Account-Ebene bleibt unverändert
|
||||
- **Tool-zu-Algorithmus-Loop** funktioniert identisch, nur mit Stufen statt Punktzahlen in der Außenkommunikation
|
||||
- **Datenmodell** für `content_scores`, `placements`, `placement_inventory` bleibt unverändert
|
||||
|
||||
---
|
||||
|
||||
## Migrationsschritt für bestehendes Mockup
|
||||
|
||||
Die Detailseite-Mockup-Version vom 7. Mai zeigt aktuell "Qualität: Sehr hoch (94)" in der Metadaten-Zeile. Anpassung:
|
||||
|
||||
- Text "Qualität: Sehr hoch (94)" entfernen
|
||||
- Stattdessen: Stern-Icon ★ + Label "Hochwertig" (für Stufe Hochwertig)
|
||||
- Tooltip beim Hover über das Label
|
||||
- Konsistenz prüfen mit Newsletter-Sidebar-Block (auch dort Score-Zahl entfernen, durch "hochwertige Pressemitteilungen" ersetzen)
|
||||
|
||||
---
|
||||
|
||||
## Offene Punkte / nächste Entscheidungen
|
||||
|
||||
- **Schwellenwerte kalibrieren:** Erst nach 100–200 echten PMs sehen, wo die Score-Verteilung liegt. Schwellen ggf. anpassen, sodass Standard ca. 40–50 %, Geprüft ca. 35–45 %, Hochwertig ca. 10–20 % der PMs umfasst (Anhaltswert).
|
||||
- **Visuelle Symbole final wählen:** Stern für Hochwertig, Häkchen für Geprüft – Alternativen prüfen (z.B. Medaille, Auszeichnungs-Symbol). Konsistenz mit bestehendem Icon-Set wahren.
|
||||
- **Editorial-Pick-Symbol final festlegen:** Orange Auszeichnung wurde auf Startseite genutzt – muss klar unterscheidbar bleiben vom Hochwertig-Symbol.
|
||||
- **Tooltip-Texte feinjustieren:** kurze, prägnante Erklärung pro Stufe, übersetzungsfähig.
|
||||
- **Erklärseite /redaktion oder /qualitaet:** als Vertrauens-Anker für Leser und Suchmaschinen erstellen.
|
||||
|
|
@ -0,0 +1,178 @@
|
|||
|
||||
|
||||
**Datum:** 12. Mai 2026 **Status:** Strategie-Dokument **Vorgänger:** Konzept-Updates 1 (Score-Architektur), 2 (Score-Stufen), 3 (Multi-Brand-Architektur) **Bezug:** Presseportal-Strategie (lebendes Strategiepapier, Mai 2026)
|
||||
|
||||
---
|
||||
|
||||
## 1. Ausgangslage
|
||||
|
||||
Die Multi-Brand-Architektur (Update 3) hat die technische Trennung von Hub und Brand-Portalen geklärt. Offen blieb die inhaltliche Frage: **Wofür stehen die beiden Marken konkret – und was dürfen sie versprechen?**
|
||||
|
||||
Frühere Positionierungs-Entwürfe haben Versprechen formuliert, die in einem Solo-Entwicklungs-Setup nicht eingehalten werden können:
|
||||
|
||||
- „Exklusive Analysen, Interviews, kuratierte Nischen-Informationen" für presseecho.de – setzt redaktionelle Arbeit voraus, die nicht geleistet wird.
|
||||
- „Breite öffentliche Wahrnehmung und Lead-Generierung" für businessportal24.com – ist ein Reichweiten-Versprechen, mit dem große Player mit ganz anderen Budgets vermarkten.
|
||||
|
||||
Beide Formulierungen folgen dem Muster „großes Presseportal kopiert" – genau das Anti-Pattern, das die übergeordnete Strategie ausschließt. Die Positionierung muss aus dem entstehen, was tatsächlich anders gemacht wird: Archiv-Stabilität, Qualitätsschwelle, faire Konditionen, Themen-Tiefe statt Timeline-Hype.
|
||||
|
||||
**Zusätzliche Einschränkung:** Beide Portale ziehen am Start aus demselben Migrations-Pool. Eine inhaltliche Differenzierung über getrennte Redaktionen oder exklusive Inhalte ist am Start nicht ehrlich darstellbar.
|
||||
|
||||
## 2. Leitidee: Differenzierung über Leseparadigma
|
||||
|
||||
Da die Inhalte zu Beginn identisch sind, wird die Differenzierung **nicht über das Was, sondern über das Wie** aufgebaut:
|
||||
|
||||
||businessportal24|presseecho|
|
||||
|---|---|---|
|
||||
|**Leitfrage**|„Was ist aktuell bei Unternehmen los?"|„Was läuft in dieser Branche / zu diesem Thema?"|
|
||||
|**Logik**|Aktualitäts-/Zeitachsen-Logik|Themen-/Cluster-/Archiv-Logik|
|
||||
|**Lesemodus**|„Was ist neu?"|„Was gibt es dazu?"|
|
||||
|**Wert für Leser**|Übersicht über aktuelle Geschehnisse|Tiefe und Kontext zu einem Thema|
|
||||
|**Wert für Publisher**|Sichtbarkeit _jetzt_|Auffindbarkeit _dauerhaft_|
|
||||
|
||||
Diese Differenzierung ist:
|
||||
|
||||
- **Solo-tauglich**: eine Codebasis, ein Inhalts-Pool, zwei Präsentations-Logiken
|
||||
- **Ehrlich**: beide Portale liefern echten Mehrwert, nur für unterschiedliche Lesebedürfnisse
|
||||
- **Selbstverstärkend**: mit der Zeit entscheiden Publisher selbst, welche Brand zu ihrem Inhalt passt – die Differenzierung wächst organisch
|
||||
|
||||
## 3. businessportal24.com – Positionierung
|
||||
|
||||
### Kern-USP
|
||||
|
||||
> _„Die Wirtschaftspresse für den deutschen Mittelstand – aktuell, transparent, ohne Reichweiten-Marketing. Was hier veröffentlicht wird, ist nach Qualität geprüft und bleibt dauerhaft auffindbar."_
|
||||
|
||||
### Zielgruppen
|
||||
|
||||
**Publisher-Seite:** Mittelständische Unternehmen, Selbstständige, kleinere PR-Agenturen, regionale Akteure. Charakteristisch: Sie suchen _eine_ zuverlässige Veröffentlichungs-Adresse, nicht zehn Streuverteiler.
|
||||
|
||||
**Leser-Seite:** Journalisten und Multiplikatoren, die wissen wollen, was bei KMU gerade passiert; Wirtschaftsinteressierte; lokale/regionale Recherche.
|
||||
|
||||
### Thematischer Schwerpunkt
|
||||
|
||||
Unternehmensmeldungen, neue Produkte, Personalia, Standorte, Aufträge, Auszeichnungen, Wirtschaftsthemen aus der Breite des Mittelstands.
|
||||
|
||||
### Tonalität
|
||||
|
||||
Aktiv, klar, wirtschaftsnah, zugänglich. Nicht hip, aber lebendig. Erwachsen, nicht laut.
|
||||
|
||||
### Farbwelt
|
||||
|
||||
Energetisches Orange/Rot als Akzent auf neutraler Basis. Passt zum Profil „aktuell, lebhaft, KMU-aktiv". Wichtig: **keine SaaS-Landingpage-Gradienten**, sondern zurückhaltend eingesetzte Akzente. Das Wirtschafts-Charakter braucht typografische Dichte, keine Lifestyle-Optik.
|
||||
|
||||
### Was hier _nicht_ versprochen wird
|
||||
|
||||
- Reichweite oder Reichweiten-Garantien
|
||||
- Lead-Generierung
|
||||
- „Virale Verbreitung"
|
||||
- SEO-Versprechen
|
||||
- Exklusive Inhalte
|
||||
|
||||
## 4. presseecho.de – Positionierung
|
||||
|
||||
### Kern-USP
|
||||
|
||||
> _„Das Branchenportal mit Themen-Gedächtnis – wo Pressemitteilungen nicht in der Timeline verschwinden, sondern dauerhaft in Themen- und Branchenkontexten zugänglich bleiben."_
|
||||
|
||||
### Zielgruppen
|
||||
|
||||
**Publisher-Seite:** Unternehmen mit fachlich-spezifischer Kommunikation, B2B-Anbieter, Branchen-Akteure. Charakteristisch: Sie wollen, dass ihre Meldung auch in zwei Jahren noch im Themen-Kontext gefunden wird – nicht nur 48 Stunden im Strom mitschwimmen.
|
||||
|
||||
**Leser-Seite:** Fachjournalisten, Branchenrecherche, Analysten, Studierende – alle, die zu einem Thema _in die Tiefe_ gehen wollen statt nur „was war heute?".
|
||||
|
||||
### Thematischer Schwerpunkt
|
||||
|
||||
Am Start identisch zum gemeinsamen Pool. Differenzierung über die **Präsentation**: Themen- und Branchen-Cluster, sichtbare Archivtiefe, „dazu erschien auch …", längere Lese-Pfade, Themen-Historie.
|
||||
|
||||
### Tonalität
|
||||
|
||||
Ruhig, sachlich, expertenorientiert – aber nicht steif. Eher „Fachbuchhandlung" als „Lifestyle-Magazin".
|
||||
|
||||
### Farbwelt
|
||||
|
||||
Dunkelgrün. Seriös, beständig, „Bibliotheks-Charakter". Idealer Kontrast zur aktiven Orange-Welt von businessportal24.
|
||||
|
||||
### Der ehrliche Mehrwert
|
||||
|
||||
Das ~10 Jahre alte Archiv mit knapp 100.000 Mitteilungen wird hier zum _Feature_, nicht zur Altlast. presseecho.de ist faktisch die Marke, in der die **Archivtiefe sichtbar** wird – und damit das Asset, das in der Strategie als wichtigster Differenzierungs-Vorteil identifiziert wurde.
|
||||
|
||||
### Was hier _nicht_ versprochen wird
|
||||
|
||||
- Exklusive redaktionelle Inhalte
|
||||
- Eigene Interviews oder Analysen
|
||||
- Kuratierte Auswahl durch eine Redaktion
|
||||
- Branchen-Newsletter mit Mehrwert über die Pressemitteilungen hinaus
|
||||
- Experten-Bewertungen / -Rankings
|
||||
|
||||
Wenn diese Versprechen später eingelöst werden sollen, müssen sie _vorher_ operativ verfügbar sein – nicht umgekehrt.
|
||||
|
||||
## 5. Markenarchitektur im Verhältnis zueinander
|
||||
|
||||
Die beiden Brands sind nicht Konkurrenz, sondern **komplementär**. Beim Veröffentlichen erhält der Publisher eine ehrliche Entscheidungshilfe:
|
||||
|
||||
- _„Mein Thema ist aktuell, ich will Sichtbarkeit jetzt"_ → businessportal24
|
||||
- _„Mein Thema ist fachlich, ich will dauerhafte Auffindbarkeit im Kontext"_ → presseecho
|
||||
- _„Beides"_ → Cross-Publishing (gegen Aufpreis im Credit-System)
|
||||
|
||||
Das erfüllt drei Funktionen gleichzeitig:
|
||||
|
||||
1. **Ehrliche Beratung** gegenüber dem Kunden – keine künstliche Verknappung
|
||||
2. **Verkaufslogik** für Cross-Publishing als Premium-Option
|
||||
3. **Selbstverstärkende Differenzierung** – Publisher sortieren ihre Inhalte selbst zur passenden Marke
|
||||
|
||||
## 6. Migrationspfad der Differenzierung
|
||||
|
||||
Die Differenzierung wird **nicht zum Start vollständig** geliefert. Sie wächst in drei Phasen, im Einklang mit der Anti-Zombie-Regel „nichts versprechen, was am Start nicht verfügbar ist".
|
||||
|
||||
### Phase 1 – Migration (Monate 1–6)
|
||||
|
||||
Beide Portale zeigen praktisch dieselben Inhalte. Differenzierung lebt nur über:
|
||||
|
||||
- **Marken-Identität**: Logo, Farbwelt, Tagline, Tonalität der Marketing-Texte
|
||||
- **Navigations-Logik**: Timeline-first (businessportal24) vs. Themen-first (presseecho)
|
||||
- **Landing-Page-Sprache**: unterschiedliche Wertversprechen, gleiche Backend-Mechanik
|
||||
|
||||
Mehr ist in dieser Phase nicht ehrlich darstellbar.
|
||||
|
||||
### Phase 2 – Aufbau (Monate 6–18)
|
||||
|
||||
- Cross-Publishing wird kostenpflichtig
|
||||
- Default-Publishing geht zu _einer_ Brand – Publisher entscheiden bewusst, wo es passt
|
||||
- Erste organische Inhalts-Drift entsteht (regional/aktuell → businessportal24; fachlich/dauerhaft → presseecho)
|
||||
- Brand-spezifische Navigations-Features werden ausgebaut (Themen-Cluster bei presseecho, Aktualitäts-Filter bei businessportal24)
|
||||
|
||||
### Phase 3 – Reife (ab Monat 18+)
|
||||
|
||||
- presseecho.de hat erkennbare Themenwelten mit Archivtiefe
|
||||
- businessportal24.com hat erkennbares „Was-ist-neu"-Profil
|
||||
- Eventuell brand-spezifische Kleinfeatures: Themen-Newsletter bei presseecho, Branchen-Filter bei businessportal24
|
||||
- Erst hier können erweiterte Markenversprechen formuliert werden – und nur, wenn sie operativ tatsächlich abgedeckt sind
|
||||
|
||||
## 7. Verbindung zur Gesamtstrategie
|
||||
|
||||
Diese Positionierung folgt konsequent den Leitlinien aus dem Strategiepapier:
|
||||
|
||||
- **Bewusste Nische statt Konkurrenz**: kein Wettlauf mit Pressebox/openPR um Reichweite
|
||||
- **Asset-Wert konservieren**: das Archiv wird über presseecho.de sichtbar gemacht statt versteckt
|
||||
- **Geduld als Wettbewerbsvorteil**: Differenzierung wachsen lassen, statt am Start zu erfinden
|
||||
- **Ehrliche Kommunikation**: nur versprechen, was operativ verfügbar ist
|
||||
- **Konsistenz schlägt Spektakel**: ein klarer, langsam wachsender Markencharakter pro Portal
|
||||
|
||||
## 8. Implikationen für die nächsten Schritte
|
||||
|
||||
Daraus ergeben sich konkrete Aufgaben für die kommende Arbeitsphase:
|
||||
|
||||
- **Brand-Landing businessportal24.com/veroeffentlichen** – Wertversprechen aus diesem Update, kurzer Vertriebs-Touchpoint, Übergabe in den Hub-Funnel
|
||||
- **Brand-Landing presseecho.de/veroeffentlichen** – Wertversprechen aus diesem Update, betont Archiv und Themen-Kontext
|
||||
- **Frontend-Navigationskonzept** – Timeline-first vs. Themen-first als sichtbarer Unterschied
|
||||
- **Tonalitäts-Leitfaden** für Marketing-Texte je Brand (kann später wachsen, am Start reicht eine knappe Tabelle)
|
||||
- **Cross-Publishing-Preislogik** im Credit-System (offener Punkt aus Update 3)
|
||||
|
||||
## 9. Offene Punkte
|
||||
|
||||
- Hub-Design-Sprache (offener Punkt aus Update 3) – sollte sich farblich/atmosphärisch klar von beiden Brand-Welten unterscheiden, neutral-funktional bleiben
|
||||
- Wann genau wechselt das Default-Publishing-Modell von „zu beiden Brands" auf „zu einer Brand" (Phase-1- vs. Phase-2-Übergang)
|
||||
- Soll es eine sichtbare Verbindung der beiden Marken nach außen geben (z.B. „ein Service der Pressekonto-Familie") – oder bleiben sie öffentlich strikt getrennt?
|
||||
|
||||
---
|
||||
|
||||
_Dieses Update ist Teil der Reihe lebender Konzept-Dokumente. Es legt fest, was die beiden Marken am Start versprechen dürfen – und damit gleichzeitig, was sie noch nicht versprechen. Änderungen an dieser Positionierung sollten dokumentiert und mit dem Strategiepapier abgeglichen werden._
|
||||
166
docs/konzept/Konzept-X - Brand-Landing.md
Normal file
166
docs/konzept/Konzept-X - Brand-Landing.md
Normal file
|
|
@ -0,0 +1,166 @@
|
|||
# businessportal24.com/veroeffentlichen
|
||||
|
||||
**Datum:** 12. Mai 2026 **Status:** Implementierungs-Konzept **Bezug:** Konzept-Update 3 (Multi-Brand-Architektur), Konzept-Update 4 (Positionierung & Markenversprechen)
|
||||
|
||||
---
|
||||
|
||||
## 1. Strategische Verortung
|
||||
|
||||
Diese Landing ist **kein Funnel** im klassischen SaaS-Sinn. Sie ist ein **kurzer Vertriebs-Touchpoint**, der drei Dinge leistet:
|
||||
|
||||
1. Den Markencharakter von businessportal24 vermitteln (aktuell, KMU-nah, erwachsen)
|
||||
2. Vertrauen für die Veröffentlichungs-Entscheidung aufbauen
|
||||
3. Sauber in den **Hub-Funnel** auf pressekonto.de übergeben, wo Account, Credits, Abrechnung und Tools liegen
|
||||
|
||||
Was hier _nicht_ hingehört: ausführliche Preistabellen, mehrstufige Onboarding-Flows, Account-Verwaltung, Dashboard-Vorschauen. Das ist Hub-Territorium.
|
||||
|
||||
**Tonalität:** wirtschaftsnah, klar, sachlich-lebendig. Nicht Marketing-Sprech. Nicht „SaaS-Begeisterung". Eher Tageszeitungs-Wirtschaftsteil als Stripe-Landingpage.
|
||||
|
||||
**Visuelle Linie:** typografische Dichte statt Whitespace-Verschwendung. Orange/Rot als **Akzent**, nicht als flächiger Gradient. Editorial-Anmutung: schmale Spalten, klare Hierarchie, sachliche Bildwelt (echte Pressefotos / Unternehmensfotos, keine generischen Stock-Illustrationen).
|
||||
|
||||
## 2. Seitenstruktur
|
||||
|
||||
### Above the fold
|
||||
|
||||
**Hero-Block**
|
||||
|
||||
- **H1** (eine der Varianten):
|
||||
- „Pressemitteilung veröffentlichen. Geprüft. Dauerhaft auffindbar."
|
||||
- „Die Wirtschaftspresse für den deutschen Mittelstand."
|
||||
- „Veröffentlichen, wo Mitteilungen nicht verschwinden."
|
||||
- **Sub** (USP-Kern, max. 2 Sätze): _„businessportal24 ist die Presseplattform für mittelständische Unternehmen, Selbstständige und PR-Agenturen. Jede Veröffentlichung wird auf Qualität geprüft und bleibt dauerhaft im Archiv auffindbar."_
|
||||
- **Primary CTA**: „Jetzt veröffentlichen" → führt in den Hub-Funnel (pressekonto.de), Cross-Domain-Auth via Sanctum
|
||||
- **Secondary CTA**: „So funktioniert's" → Scroll-Anker zum „Ablauf"-Abschnitt
|
||||
|
||||
**Was bewusst fehlt im Hero:**
|
||||
|
||||
- Kein „Jetzt 14 Tage kostenlos testen"
|
||||
- Kein „Reichweite für Ihre Marke"-Versprechen
|
||||
- Kein Hero-Bild mit lächelnden Stockfoto-Menschen
|
||||
- Kein riesiger orangener Gradient-Banner (die SaaS-Optik, die im aktuellen Redesign-Feedback bemängelt wurde)
|
||||
|
||||
### Trust-Block: Was uns ausmacht
|
||||
|
||||
Vier knappe Kacheln, jeweils mit Headline + 1–2 Sätzen. Keine großen Icons (oder nur sehr zurückhaltend, monochrom). Editorial-Look statt Marketing-Look.
|
||||
|
||||
1. **Geprüfte Qualität** _„Jede Mitteilung durchläuft eine Qualitätsprüfung, bevor sie online geht. Keine SEO-Spam-Texte, keine reinen Werbeanzeigen."_
|
||||
|
||||
2. **Dauerhaft auffindbar** _„Pressemitteilungen bleiben im Archiv – auch nach Jahren. Über 100.000 Mitteilungen aus mehr als einem Jahrzehnt sind weiterhin abrufbar."_
|
||||
|
||||
3. **Faire Konditionen** _„Transparente Preise, kein Abo-Zwang, keine Vertragsfallen. Sie zahlen, was Sie veröffentlichen."_
|
||||
|
||||
4. **Korrektur statt Löschung** _„Fehler in einer Mitteilung? Wir korrigieren statt zu löschen – damit Verweise und Verlinkungen bestehen bleiben."_
|
||||
|
||||
|
||||
### Ablauf: So funktioniert's
|
||||
|
||||
Drei Schritte, knapp gehalten. Bewusst entmystifiziert – keine „Magic"-Sprache.
|
||||
|
||||
1. **Konto anlegen** – mit E-Mail-Adresse. Kein Passwort nötig, Login per Magic-Link.
|
||||
2. **Mitteilung einreichen** – Text, Bild, Ansprechpartner. Eine Qualitätsprüfung läuft automatisch und durch eine kurze redaktionelle Sichtung.
|
||||
3. **Veröffentlichung** – nach Freigabe online und im Archiv. Bei Bedarf jederzeit korrigierbar.
|
||||
|
||||
Hinweis am Ende des Blocks (klein, sachlich): _„Die Veröffentlichung erfolgt über den zentralen Publisher-Bereich auf pressekonto.de."_ – das setzt die Hub-Architektur transparent.
|
||||
|
||||
### Für wen das richtig ist
|
||||
|
||||
Kurzer Abschnitt mit konkreten Anlässen statt abstrakter Zielgruppen-Beschreibung. Macht die Eignung selbst-evident.
|
||||
|
||||
_„Typische Pressemitteilungen auf businessportal24:_
|
||||
|
||||
- _Neue Produkte oder Dienstleistungen_
|
||||
- _Personalien und Geschäftsleitungs-Wechsel_
|
||||
- _Auszeichnungen und Zertifizierungen_
|
||||
- _Standort-Eröffnungen, Expansionen, Aufträge_
|
||||
- _Veranstaltungs-Ankündigungen_
|
||||
- _Studien und Marktanalysen aus Unternehmenshand"_
|
||||
|
||||
Anschließend ein Satz zur Eingrenzung – das ist wichtig für die Qualitätsschwelle:
|
||||
|
||||
_„Nicht geeignet sind reine Werbeanzeigen, SEO-Linkbuilding-Texte oder Inhalte ohne nachvollziehbaren Pressewert."_
|
||||
|
||||
### Preise (kurz, mit Verweis)
|
||||
|
||||
Hier **kein** vollständiges Preismodell. Stattdessen:
|
||||
|
||||
- Ein Satz zur Logik: _„Sie kaufen Credits, die für Veröffentlichungen eingesetzt werden. Keine Mindestlaufzeit, keine versteckten Gebühren."_
|
||||
- Ein Preis-Anker, damit der Besucher nicht ratlos bleibt: _„Eine Veröffentlichung ab X € – Mengenrabatte verfügbar."_ (Konkreter Wert nachträglich)
|
||||
- Link zum Hub: _„Vollständige Preisübersicht im Publisher-Bereich →"_
|
||||
|
||||
### Kurz-FAQ
|
||||
|
||||
Maximal 4–5 Fragen. Direkt, ohne Marketing-Worte.
|
||||
|
||||
- _„Wie schnell wird meine Mitteilung veröffentlicht?"_ – Werktags üblicherweise innerhalb von 24 Stunden nach Einreichung.
|
||||
- _„Bleibt meine Mitteilung dauerhaft online?"_ – Ja. Mitteilungen werden nicht gelöscht. Korrekturen sind jederzeit möglich.
|
||||
- _„Kann ich auch auf presseecho.de veröffentlichen?"_ – Ja, über den zentralen Publisher-Bereich. Cross-Publishing ist optional verfügbar.
|
||||
- _„Brauche ich ein Abo?"_ – Nein. Sie kaufen Credits nach Bedarf, ohne Vertragsbindung.
|
||||
- _„Was passiert bei einem Fehler in der Mitteilung?"_ – Korrektur statt Löschung: Inhalte werden aktualisiert, die URL bleibt erhalten.
|
||||
|
||||
### Final CTA
|
||||
|
||||
Schlicht. Kein „Letzte Chance"-Pathos.
|
||||
|
||||
- **H2**: „Bereit zu veröffentlichen?"
|
||||
- **Button**: „Konto anlegen" → Hub
|
||||
- **Klein darunter**: „Oder zuerst Beispiele ansehen →" (Link zur Startseite des Portals)
|
||||
|
||||
### Footer
|
||||
|
||||
Standard, aber mit zwei brand-spezifischen Elementen:
|
||||
|
||||
- Hinweis auf den Betreiber: _„businessportal24 ist ein Service der Pressekonto-Gruppe."_ (oder ähnlich – siehe offener Punkt aus Update 4)
|
||||
- Cross-Link zu presseecho.de (dezent, eine Zeile): _„Für fachlich-spezifische Themen: presseecho.de"_
|
||||
|
||||
## 3. Visuelle Leitlinien
|
||||
|
||||
### Was diese Seite tun soll
|
||||
|
||||
- **Editorial wirken**, nicht promotional. Vorbild: Wirtschaftsteil einer überregionalen Zeitung, nicht Stripe/Linear/Notion.
|
||||
- **Typografisch arbeiten**: klare Hierarchien, ausreichend Dichte, lesbare Spaltenbreiten (~65–75 Zeichen).
|
||||
- **Farben sparsam**: Orange/Rot als Akzent (Links, primärer CTA, dünne Trennlinien, gelegentliche Rubriken-Marker). Keine flächigen Gradienten, keine farbigen Cards als Hintergrund.
|
||||
- **Sachlichkeit ausstrahlen**: Pressemitteilungen sind ein seriöses Produkt. Optik muss das transportieren.
|
||||
|
||||
### Was diese Seite _nicht_ tun darf
|
||||
|
||||
- **Keine** Hero-Gradienten in Orange (siehe Feedback zum ersten Redesign-Versuch)
|
||||
- **Keine** generischen Briefkasten-/Megafon-Icons
|
||||
- **Keine** „lifestyle"-Bildwelt mit lächelnden Menschen am Laptop
|
||||
- **Kein** SaaS-Vokabular („Plattform", „Solution", „Empower your communications")
|
||||
- **Keine** Pseudo-Trust-Elemente wie „4.9 Sterne", „10.000 zufriedene Kunden" – wenn es echte Zahlen gibt, dann nüchtern darstellen
|
||||
|
||||
### Layout-Empfehlung
|
||||
|
||||
- **Maximalbreite** ~1100–1200px, zentriert, mit ausreichend Seitenrand
|
||||
- **Hero** kompakt, nicht ganzseitig hoch – Pressekontext heißt: Information schnell sichtbar
|
||||
- **Sektions-Trenner** über Typografie und schmale Linien, nicht über farbige Background-Bänder
|
||||
- **Mobile**: einspaltig, gleiche Reihenfolge, Hero noch kompakter
|
||||
|
||||
## 4. Technische Hinweise
|
||||
|
||||
- **Routing**: `businessportal24.com/veroeffentlichen` rendert eine eigene Brand-Landing-Route, die das geteilte Backend nutzt aber brand-spezifische Templates lädt
|
||||
- **CTA-Übergabe**: Klick auf „Jetzt veröffentlichen" / „Konto anlegen" leitet zum Hub (`pressekonto.de/publisher/start?brand=businessportal24`), damit der Hub weiß, welche Brand der Einstiegspunkt war (für Default-Brand-Zuordnung und ggf. Tracking)
|
||||
- **Cross-Domain-Auth**: Wie in Update 3 festgelegt via Sanctum. Wenn der Besucher bereits eingeloggt ist, springt er direkt ins Dashboard, sonst in den Onboarding-Flow
|
||||
- **Tracking**: Brand-Landing trackt eigenen Funnel-Eintritt, der Hub übernimmt ab dort. So bleibt nachvollziehbar, welche Brand-Landing welche Conversion-Rate hat
|
||||
|
||||
## 5. Copy-Hinweise zur weiteren Verwendung
|
||||
|
||||
Die Copy-Vorschläge in Abschnitt 2 sind **Ausgangsmaterial**, nicht final. Sie verkörpern aber die Tonalität, die in Update 4 festgelegt wurde:
|
||||
|
||||
- aktiv, klar, wirtschaftsnah, zugänglich
|
||||
- keine Reichweiten- oder Lead-Versprechen
|
||||
- konkrete Beispiele statt abstrakte Zielgruppen-Floskeln
|
||||
- ehrliche Eingrenzung (das „Nicht geeignet"-Statement)
|
||||
|
||||
Beim Schreiben weiterer Texte gilt: Im Zweifel **eine Aussage weniger** statt eine Aussage mehr. Pressecharakter heißt zurückhaltend, nicht prahlend.
|
||||
|
||||
## 6. Offene Punkte
|
||||
|
||||
- Konkrete Preis-Anker (X € pro Veröffentlichung) – sobald die Preislogik aus Update 3 finalisiert ist
|
||||
- Beispiel-Mitteilungen zum Anzeigen auf der Landing – sinnvoll oder unnötig? (Die Startseite tut das ohnehin)
|
||||
- Soll der Footer-Hinweis auf presseecho.de prominent oder eher unauffällig sein? Hängt an der Grundsatzentscheidung aus Update 4 (sichtbare Markenfamilie vs. strikt getrennt)
|
||||
- A/B-Test-Strategie für die drei H1-Varianten – sinnvoll erst, wenn Mindest-Traffic erreicht ist
|
||||
|
||||
---
|
||||
|
||||
_Dieses Konzept ist eine konkrete Implementierungs-Vorlage. Es schöpft die Positionierung aus Update 4 in seitenstrukturelle Form und benennt explizit, was diese Landing nicht leisten soll – um die Anti-Zombie-Regel auf operativer Ebene umzusetzen._
|
||||
Loading…
Add table
Add a link
Reference in a new issue