# PRD — Multibrokerage: Trade-CTAs an Hochintent-Surfaces > **PRD** = Product Requirements Document. Es übersetzt das Alignment-Doc *„Wette: Trade-CTAs an Hochintent-Surfaces (Logged-in-Test)"* in eine umsetzbare Spezifikation für einen **Low-Fi UX-Wireframe-Prototyp** (App & Web) und den darauf folgenden Live-Test. > Version 0.1 · Stand: 2026-06-05 · Status: **Draft (Iteration 1)** · Outcome Owner: André Reif · Stakeholder: Christian Bothe > Schwesterprojekt / Vorbild-Wireframe: `onvista-signale` (`prototype-wireframe/`). --- ## 0. Lese-Hinweis: Zwei Scopes sauber getrennt Dieses Dokument unterscheidet bewusst zwei Dinge, die im Brief vermischt erscheinen: | | **Prototyp-Scope** (dieses Dokument, Iteration 1) | **Live-Test-Scope** (die eigentliche Wette) | |---|---|---| | Zweck | UX vor dem Build validieren & Varianten vertesten | Verhaltensänderung messen, Funnel-Wissen gewinnen | | Auth-Zustände | **Eingeloggt UND ausgeloggt** (inkl. Registrierungs-Varianten) | **Nur eingeloggt** (SEO-/Brand-Risiko vermeiden) | | Surfaces | Snapshot/Chart + Musterdepot | Snapshot/Chart + Musterdepot | | Registrierungs-Flow | **In Scope** — wir wollen ihn untersuchen & vertesten | **Out of Scope** (bewusst, laut Wette) | | Output | klickbarer Wireframe + dieses PRD | A/B-Funnel-Daten, Broker-Mix, Trade-Frequenz | > **Warum der Prototyp breiter ist als die Wette:** Der ausgeloggte Pfad und der Registrierungs-Übergang sind im Live-Test bewusst ausgeklammert (Risiko), aber sie sind die wahrscheinlichste **Folge-Wette**. Wir entwerfen und vertesten sie *jetzt im risikofreien Prototyp*, damit die Folge-Wette nicht bei null startet. Der Live-Test selbst spielt nur den eingeloggten Pfad aus. --- ## 1. TL;DR Wir bauen einen graustufigen UX-Wireframe (App & Web, mit ein-/ausblendbaren UX-Notizen), der **Kaufen/Verkaufen-CTAs (V/K)** an den zwei Hochintent-Surfaces **Snapshot/Chart** und **Musterdepot** simuliert — und den kompletten **Trade-Funnel** durchspielt: `View → CTA-Click → Connect-Start → Connect-Complete → Trade-Submit → Trade-Confirmed`. Der Prototyp kann zwischen **eingeloggt** und **ausgeloggt** umschalten und stellt für den ausgeloggten Fall **zwei Registrierungs-Varianten** zur Auswahl (harte Schranke vs. „erst ausfüllen, dann beim Submit registrieren"). Ziel ist nicht Umsatz, sondern **valides Funnel-Wissen** für die transaktionale Erlösstrategie. ## 2. Problem & Motivation YTD (bis KW 21/2026) bewegen wir ~6.000 Transaktionen über die Multibrokerage-Anbindung. Stock3 schafft ~500.000 Transaktionen/Quartal — Faktor >100x. Die Lücke ist **nicht** fehlende Nachfrage, sondern **fehlende Touchpoints**: An unseren beiden Hochintent-Surfaces (Chart & Musterdepot) sind Connect- und Trade-CTAs heute **nicht integriert**. **Strategisches Risiko:** Das Geschäftsmodell 2027ff. setzt auf transaktionsbezogene Erlöse. Mit 6.000 Trades als Baseline haben wir **kein Lernfundament** — weder zu Funnel-Conversion, noch zu Broker-Mix, noch zu Payout-Ökonomie. Wir gehen blind in jede Partnerverhandlung. **Markenversprechen-Fit:** „Chancen sehen und handeln." Das Fehlen der Handelsoption an den entscheidenden Punkten ist ein **Markenwiderspruch**. ## 3. Hypothese > Wenn wir an Chart und Musterdepot V/K-Buttons für eingeloggte Nutzer ausspielen, dann steigen Connect-Rate und Trade-Frequenz in diesem Segment signifikant — weil hier echter Asset-Intent vorliegt und der Sprung „vom Informationsmoment zur Aktion" minimiert wird. Wir machen **keine** Aussage zur absoluten Skalierung. Die Wette ist ein gerichteter **Funnel-Test**, keine Umsatzprognose. ## 4. Lernziele (das eigentliche Outcome) Die Wette gilt als erfolgreich, wenn wir nach dem Test diese Fragen mit Daten beantworten können: 1. **Surface-Performance** — Wie unterscheiden sich Chart und Musterdepot in V/K-Click-Through, Connect-Start und Trade-Completion? 2. **Funnel-Drop-offs** — Wo verlieren wir User: CTA-Sichtbarkeit, Connect-Flow, Broker-Auswahl, Order-Bestätigung? 3. **Broker-Mix** — Welche angeschlossenen Broker werden von welcher Cohort bevorzugt? (Steuert künftige Verhandlungen direkt.) 4. **Segment-Profil** — Welche eingeloggten Segmente reagieren am stärksten: Musterdepot-Heavy, Watchlist-Heavy, Reine-Snapshot-Leser? 5. **Trade-Frequenz pro connectetem User** — Wieviele Trades macht ein verbundener User im Zeitraum? (Grundlage jeder LTV-Berechnung.) Diese fünf Fragen sind der **Nordstern** des Tracking-Modells (→ Epic 7). ## 5. Scope **In Scope (Prototyp, Iteration 1):** - V/K-CTAs am **Snapshot/Chart** (eingeloggt + ausgeloggt). - V/K-CTAs in den **Musterdepot-Positionszeilen** (eingeloggt + ausgeloggt). - **Auth-Umschalter** (eingeloggt / ausgeloggt) als Tool-Chrome im Wireframe. - **Broker-Connect-Flow** & **Broker-Auswahl** (Multibrokerage-Simulation, Brokerize-Logik nachgebildet). - **Order-Ticket** (V/K-Maske) inkl. Validierung, Kosten-/Order-Vorschau, Bestätigung, Risikohinweis. - **Registrierungs-Varianten** für den ausgeloggten Fall (A: harte Schranke · B: erst ausfüllen, dann beim Submit registrieren). - **Funnel-Tracking-Spec** (Event-Modell, plattformneutral) — als Spezifikation, im Prototyp als Event-Log sichtbar gemacht. - **App/Web-Umschalter** + **UX-Notizen**, graustufig (kein visuelles Design), A11y-konform. **Out of Scope (Prototyp, Iteration 1):** - Reale Broker-API-Integration / echte Orders (alles simuliert). - Watchlist und weitere Surfaces (Fokus halten). - Hi-Fi-Design / onvista-Branding (kommt nach UX-Validierung, vgl. `signale/prototype/`). - Conversion-Optimierung des Connect-Flows selbst. - Neue Broker-Verträge / -Integrationen. **Out of Scope (Live-Test, laut Wette — hier nur zur Abgrenzung):** - Ausgeloggter Zustand, Registrierungs-Funnel, Snapshot-Header, weitere Surfaces. ## 6. Die zwei Auth-Zustände Der Prototyp hat einen **Auth-Umschalter** (Tool-Chrome, nicht Teil des Produkts), analog zum App/Web-Umschalter der Signale. ``` ┌─────────────────────────────┐ Auth-Umschalter →│ Eingeloggt │ Ausgeloggt │ └───────┬───────────────┬──────┘ │ │ V/K sichtbar & V/K sichtbar, aber voll funktional beim Klick greift die (Connect → Order) getestete Registrierungs- Variante (→ Abschnitt 9) ``` - **Eingeloggt:** Identitäts-/Profilkontext vorhanden. V/K führt direkt in den Trade-Funnel (Connect ggf. nötig → Order). Dies ist der **einzige** im Live-Test ausgespielte Zustand. - **Ausgeloggt:** Öffentlicher Snapshot bzw. nicht authentifiziertes Musterdepot. V/K ist sichtbar (Markenversprechen), aber der Klick stößt den **Registrierungs-Übergang** an — Variante je nach Test-Schalter. ## 7. Die zwei Hochintent-Surfaces > **CTA-Anatomie (aus den finalen Screens gepinnt):** Die beiden Surfaces nutzen **zwei bewusst unterschiedliche Form-Faktoren**. Hi-Fi-Farbsemantik: **Verkaufen = rot**, **Kaufen = grün**. Im Low-Fi-Wireframe wird diese Bedeutung **über Label + Links/Rechts-Position + Form (Outline vs. Fill)** transportiert, nicht über Farbe (A11y, §16). ### 7.1 Snapshot / Chart (Instrument-Detailseite) Vorbild: onvista-Snapshot (App: Zalando · Web: Rheinmetall/Infineon). Heute existieren oben „Hinzufügen"/„Handeln" — die Handelsoption ist aber **nicht am Hochintent-Moment** (Preis/Chart) verankert. - **Form-Faktor:** großer **Split-Button** (zwei gleich große Hälften) **direkt unter dem Chart + den Zeitraum-Chips** (1T/1W/3M/1J/5J/10J/Max). - Links: **`[Kurs] EUR · Verkaufen`** (rot) — Preis = **Geld/Bid**. - Rechts: **`[Kurs] EUR · Kaufen`** (grün) — Preis = **Brief/Ask**. - (In den Screens steht beidseitig derselbe Demo-Kurs „186,92 EUR"; produktiv zeigt jede Seite ihren jeweiligen Geld-/Brief-Kurs.) - **App vs. Web:** App = voll-breiter Split-Button unter dem Chart, über „Handelsdaten". Web = derselbe Split-Button unter dem Chart-Modul (vor „Zur Wertpapieranalyse"). - **Kontext mitgeben:** Instrument, Notation/Börsenplatz, aktueller Kurs, Geld/Brief → an den Order-Funnel. - **Zweite Platzierung — Geld/Brief im Kopf:** Die **Geld-/Brief-Werte sind selbst V/K-Buttons** (Geld = Verkaufen, Brief = Kaufen, je mit Stückzahl) — kompakte Inline-CTA direkt am Quote, zusätzlich zum großen Split-Button am Chart. Beide triggern denselben Funnel. - **Banner-Blindheit vermeiden:** Position & Prominenz ab Woche 1 iterierbar → Prototyp hält **≥ 2 Platzierungen** bereit (Split-Button am Chart + Geld/Brief-Inline-CTA). ### 7.2 Musterdepot (Positionszeilen) Vorbild: Musterdepot App (Cards, Tabs *Übersicht · Signale · Verkäufe · Transaktionen*) und Web (Bestands-Tabelle: Name / Stück / Kaufkurs / Kaufwert / Chart / aktueller Kurs / akt. EUR / ges. EUR / Wert). - **Form-Faktor:** kompaktes **`V | K`-Micro-Toggle** pro Position — links **„V"** (Verkaufen, rot), rechts **„K"** (Kaufen, grün). - **App:** Micro-Toggle direkt **neben dem Instrumentnamen** (vor dem „⋯"-Menü), je Position-Card. - **Web:** Micro-Toggle **inline in der „aktueller Kurs"-Spalte**, je Tabellenzeile. - **Ausgeloggt = Login-Schranke:** Das Musterdepot ist eine **reine Logged-in-Surface** („Mein Depot" gibt es nur eingeloggt). Ausgeloggt zeigt es **keine Positionen und kein V/K-CTA**, sondern eine Anmelde-/Registrierungs-Wand. Die Registrierungs-Varianten (§9) werden daher am öffentlichen Snapshot getestet, nicht hier. - **Kontextsensitiv:** „V" nur bei **Bestand > 0**; „K" (Nachkaufen) immer. - **Kontext aus der Position:** Notation, Stückzahl, Einstandskurs, aktueller Kurs vorbelegt → Order-Ticket startet befüllt. - **Hypothesen-Risiko explizit:** Musterdepot-User könnten reine Lerner/Spieler ohne Trade-Intent sein. Cohort-Segmentierung pre-test; Prototyp macht das Musterdepot-CTA **separat schaltbar** (mögliche Pausierung im Live-Test). ### 7.3 Surface-Landschaft / Skalierungs-Vision (NICHT im Test-Scope) Die V/K-Bausteine lassen sich an deutlich mehr Surfaces der Snapshot-Seite verankern (siehe umfassende Referenz, z. B. Nvidia-Snapshot). Diese sind **bewusst nicht** Teil des 2-Wochen-Tests, aber als Skalierungsoptionen dokumentiert — relevant für die „Skalieren"-Entscheidung am Testende: | Surface | Form-Faktor | Status | |---|---|---| | **Chart / Kursentwicklung** | Split-Button (Verkaufen/Kaufen) | **✅ im Test** | | **Musterdepot-Positionen** | `V|K`-Micro-Toggle | **✅ im Test** | | Snapshot-Header (Geld/Brief) | kleiner V/K am Kurskopf | Vision (laut Wette out-of-scope) | | „Aktuelle Aktienkurse" (Kursquellen je Börsenplatz) | Split-Button je Zeile | Vision | | „Passende Produkte" / Derivate-Tabellen (KO, Optionsscheine) | `V|K`-Micro-Toggle je Zeile | Vision | | „Beliebte Derivate" (Cards) | `V|K` je Card | Vision | | „ETFs mit …" / Listen-/Peergroup-Module | `V|K` je Zeile/Card | Vision | > **Mess-Disziplin:** Je mehr Surfaces gleichzeitig live gehen, desto schwerer die Attribution. Der Test isoliert bewusst **zwei** Surfaces, um saubere Surface-Performance-Vergleiche (Lernziel 1) zu ermöglichen. Ausweitung erst nach validiertem Funnel. > **Im Prototyp demonstrierbar:** Diese Vision-Surfaces (Kursquellen-Tabelle „Aktuelle Aktienkurse", Knock-Out-Tabelle „Passende Produkte", Cards „Beliebte Derivate") sind im Web-Snapshot per **Toolbar-Toggle „Erweiterte Surfaces"** optional ein-/ausblendbar — Default **aus**, damit der Kern-Testview sauber bleibt. Ihre V/K-CTAs triggern denselben Funnel, tracken aber den **Produkt-Kontext (WKN)** — ein Vorgeschmack auf Produkt-Level-Lernsignale. ### 7.4 Derivate-Finder (öffentliche Surface, im Prototyp gebaut) Vorbild: onvista **/derivate/finder** („Zertifikate filtern"). Nachmodelliert mit Produktart-Dropdown, Basiswert (DAX), Long/Short, Filter-Chips (Hebel, K.O.-Schwelle, Währungsgesichert, Rückzahlungsart, Restlaufzeit, Emittenten, Broker, Merkmale), Ergebniszähler und Ergebnis-Tabelle. - **Form-Faktor:** je Zeile **Geld Kurs = Verkaufen** (Outline) und **Brief Kurs = Kaufen** (Fill) — die V/K-Ausweitung auf die Produktsuche. - **App vs. Web:** Web = breite Tabelle; **App = kompakte Cards** je Produkt (WKN, Basispreis, K.O.-Schwelle, Bewertungstag, Hebel·Spread + großer V/K-Split-Button) — bewusst **ohne Horizontal-Scroll**, da App-Nutzer nicht seitlich scrollen. - **Öffentlich** (wie der Snapshot): logged-in → Funnel; ausgeloggt → Registrierungs-Variante (A/B). - **Produkt-Tracking:** jede CTA trackt den Produkt-Kontext (**WKN**) und `surface=finder` → eigene Surface-Performance im Vergleich zu Chart/Musterdepot. - Status: gebaut als vierte Surface im Prototyp; im **2-Wochen-Live-Test bewusst nicht** (Scope-Disziplin, → §7.3). ## 8. Der Trade-Funnel (eingeloggter Pfad, End-to-End) ``` [Surface: Snapshot/Chart ODER Musterdepot-Zeile] │ V/K sichtbar ▼ (1) CTA-Click „Kaufen" / „Verkaufen" │ ▼ (2) Broker-Connect? ──nein, schon verbunden──┐ │ ja (noch kein Broker verbunden) │ ▼ │ Broker-Connect-Flow │ • Broker wählen (Multibrokerage-Liste) │ • Verbinden (simuliertes OAuth/Login) │ • Connect-Complete │ │ │ ▼◄───────────────────────────────────────┘ (3) Order-Ticket (V/K-Maske) • Instrument · Notation · Richtung (Kauf/Verkauf) • Stückzahl / Betrag · Ordertyp (Market/Limit) · Gültigkeit • Broker-Auswahl (falls mehrere verbunden) • Kosten-/Order-Vorschau · Risikohinweis │ ▼ (4) Trade-Submit → (5) Trade-Confirmed (Order-Bestätigung, Deep-Link in Order-Status) ``` **Funnel-Stufen für Tracking (identisch zur Wette):** `View → CTA-Click → Connect-Start → Connect-Complete → Trade-Submit → Trade-Confirmed` — pro Surface getrennt gemessen. ## 9. Registrierungs-Flow: die zu testenden Varianten (ausgeloggt) Die zentrale Untersuchungsfrage des Prototyps. Diese Varianten greifen am **öffentlichen Snapshot** — das Musterdepot ist ausgeloggt nicht zugänglich (Login-Schranke, → §7.2). Der ausgeloggte Klick auf V/K am Snapshot kann unterschiedlich gehandhabt werden — der Prototyp stellt die Varianten als umschaltbare Test-Modi bereit. ### Variante A — Harte Login-/Registrierungs-Schranke (Gate-First) ``` V/K-Click → [Login/Registrieren-Wand] → (Registrierung) → zurück in den Trade-Funnel ab (2) ``` - **Pro:** klare Abgrenzung, einfache Logik, kein „Leerlauf" wenn Nutzer abbricht. - **Contra:** maximale Reibung am Intent-Moment; höchster Drop-off vermutet. ### Variante B — Erst ausfüllen, beim Submit registrieren (Try-then-Register) ``` V/K-Click → Order-Ticket frei ausfüllbar (Broker, Menge, Typ …) → [Submit] → Registrierungs-Schranke → nach Registrierung Order fortsetzen ``` - **Pro:** nutzt den Intent voll aus, „Sunk-Cost"-Effekt erhöht Registrierungsbereitschaft; mehr Lernsignal über Konfigurationsverhalten. - **Contra:** Erwartungsbruch beim Submit; Daten-/State-Handover über die Registrierung hinweg muss sitzen. ### Variante C — (optional, Backlog) Vorschau-/Teaser-Gate Order-Ticket read-only sichtbar mit Overlay „Registrieren, um zu handeln". Mittelweg; nur aufnehmen, falls A/B nicht trennscharf genug. > **Mess-Idee im Prototyp/Test:** identischer Funnel, nur der Gate-Zeitpunkt unterscheidet sich → vergleichbare Drop-off-Kurven je Variante. Im Live-Test (logged-in only) ist dieser Block inaktiv; er bedient die **Folge-Wette**. ## 10. Broker-Connect & Multibrokerage (Broker-Mix) Der Broker-Mix ist ein **primäres Lernziel** — der Connect-Flow muss die Auswahl explizit sichtbar machen. - **Broker-Liste (simuliert, Brokerize-Logik):** eine Auswahl angeschlossener Broker (Platzhalter, finale Liste aus Brokerize → offener Punkt). Jeder Broker: Name, Status (verbunden / verbindbar), ggf. Hinweis. - **Connect-States:** `nicht verbunden` → `verbinde…` (simuliertes OAuth/Redirect) → `verbunden`. Fehler-/Abbruch-Pfad vorgesehen. - **Mehrfach-Verbindung:** ein User kann mehrere Broker verbinden → im Order-Ticket Broker-Auswahl. - **Default-Broker:** zuletzt/meistgenutzter Broker vorbelegt (analog Signale-Defaults), transparent & überschreibbar. - **Profil-Broker-Verwaltung (eigener View):** Im **Profil** kann der Nutzer Broker vorab verbinden/trennen und einen **Standard-Broker (★)** festlegen. Effekt im Funnel: ist ein Broker verbunden, **entfällt der Connect-Schritt** und der Standard-Broker ist im Order-Ticket **vorausgewählt** → reibungsärmere Auswahl. Der Profil-View ist (wie das Musterdepot) **Logged-in-only** (ausgeloggt → Login-Schranke); erreichbar über die Surface-Umschaltung bzw. das Profil-Icon. - **Tracking-Relevanz:** jede Broker-Auswahl & jeder Connect erzeugt ein Event mit `brokerId` (auch aus dem Profil) → liefert Broker-Verteilung je Cohort/Surface; Pre-Connect-Quote (Profil vs. im-Funnel) wird messbar. ## 11. Order-Ticket (V/K-Maske) — Spezifikation - **Kopf:** Instrument, ISIN/WKN, Notation/Börsenplatz, Richtungs-Badge (Kauf ↑ / Verkauf ↓), aktueller Kurs (Geld/Brief), Verzögerungs-Hinweis. - **Eingaben:** Stückzahl **oder** Betrag (gekoppelt), Ordertyp (Market / Limit), bei Limit: Limitpreis, Gültigkeit (Tagesgültig / bis Datum). - **Broker:** Auswahl unter verbundenen Brokern; Connect-Shortcut, falls keiner verbunden. - **Vorschau:** geschätztes Ordervolumen, simulierte Gebühren/Spesen, Gesamtbetrag. - **Validierung:** Verkauf nur ≤ Bestand (Musterdepot-Kontext); Stückzahl > 0; Limitpreis plausibel; mind. ein Broker verbunden. - **Compliance:** Standard-**Risikohinweis** + Abgrenzung „keine Anlageberatung" (Legal vor Build, Re-use bestehender Hinweise → Epic 6 / Abschnitt 19). - **Abschluss:** „Order ausführen" → Bestätigungs-State mit Order-Referenz + Deep-Link in Order-Status. ## 12. Funnel-Tracking & Event-Modell (Kern der Wette) Da **Messen** der eigentliche Zweck ist, ist das Event-Modell ein First-Class-Artefakt. Im Prototyp als sichtbares Event-Log (UX-Notiz-Panel) abbildbar. **Event-Stufen (je mit `surface`, `authState`, `instrumentId`, `timestamp`):** | Event | Pflichtfelder | Lernziel-Bezug | |---|---|---| | `surface_view` | surface, authState, instrumentId | Reach / Basis | | `cta_click` | surface, direction (BUY/SELL), instrumentId | Surface-Performance (1) | | `connect_start` | brokerId?, source-surface | Funnel-Drop-off (2) | | `connect_complete` | brokerId | Broker-Mix (3), Drop-off (2) | | `order_open` | surface, direction, instrumentId | Funnel-Drop-off (2) | | `order_submit` | brokerId, orderType, qty/amount, direction | Trade-Frequenz (5) | | `trade_confirmed` | brokerId, orderRef | Surface-Performance (1), Broker-Mix (3) | | `gate_shown` / `gate_passed` | variant (A/B/C) | Registrierungs-Varianten (Prototyp-only) | **Abgeleitete Kennzahlen:** Stufen-Conversion je Surface, Unique Trader, Broker-Verteilung, Trades/connectetem User, Variant-Vergleich (Prototyp). ## 13. Epics > Leitprinzipien (gelten für alle Epics): **(a)** Intent nicht brechen — vom Informationsmoment zur Aktion in minimalen Schritten · **(b)** Zwei Zustände, ein mentales Modell — eingeloggt/ausgeloggt teilen Flow & Begriffe · **(c)** Messbarkeit by design — jede Stufe erzeugt ein Event · **(d)** Zeig die Wahl — Broker-Mix sichtbar statt versteckt · **(e)** Low-Fi zuerst — Struktur/Flow/States vor Branding, A11y ohne Farbe-als-einzigen-Träger. ### Epic 1 — Auth-Zustände & Surface-Einstieg **Als Produktteam möchten wir den Prototyp zwischen eingeloggt und ausgeloggt umschalten, damit wir beide Erlebnisse an denselben Surfaces vergleichen können.** - Auth-Umschalter (Tool-Chrome), App/Web-Umschalter, UX-Notizen-Toggle. - Snapshot/Chart und Musterdepot als zwei einstiegsfähige Surfaces. - Eingeloggt: voller Trade-Funnel. Ausgeloggt: Registrierungs-Übergang je Variante. ### Epic 2 — V/K-CTAs am Snapshot/Chart **Als eingeloggter Nutzer möchte ich direkt am Kurs/Chart kaufen oder verkaufen können, damit ich im Informationsmoment handeln kann.** - Prominenter V/K-Block am Kurs-/Chart-Modul; ≥ 2 Platzierungs-Varianten (Banner-Blindheit). - Kontext (Instrument, Notation, Kurs, Geld/Brief) wird an den Funnel übergeben. - Erzeugt `surface_view` und `cta_click`. ### Epic 3 — V/K-CTAs im Musterdepot **Als eingeloggter Nutzer möchte ich aus meinen Positionszeilen direkt nachkaufen oder verkaufen, damit ich mein Depot ohne Umweg bewirtschafte.** - V/K je Positionszeile; „Verkaufen" nur bei Bestand > 0. - Order-Ticket startet aus Positionskontext vorbefüllt (Notation, Stück, Kurs). - Musterdepot-CTA separat schaltbar (mögliche Live-Test-Pausierung). ### Epic 4 — Registrierungs-Flow-Varianten (Untersuchung) **Als Produktteam möchten wir verschiedene Registrierungs-Übergänge vertesten, damit wir den reibungsärmsten Pfad für die Folge-Wette kennen.** - Variante A (harte Schranke) und B (erst ausfüllen, beim Submit registrieren); C optional. - State-Handover über die Registrierung hinweg (Order-Kontext überlebt). - `gate_shown` / `gate_passed` mit Variant-Markierung. ### Epic 5 — Broker-Connect & Broker-Mix (Multibrokerage) **Als Nutzer möchte ich meinen Broker verbinden und auswählen, damit ich über den von mir bevorzugten Anbieter handeln kann.** - Broker-Liste (Brokerize-Logik, simuliert), Connect-States, Mehrfach-Verbindung, Default-Broker. - Auswahl & Connect erzeugen Events mit `brokerId` → Broker-Verteilung. ### Epic 6 — Order-Ticket (V/K-Maske) **Als Nutzer möchte ich eine klare, fehlerarme Order-Maske, damit ich Käufe/Verkäufe sicher abschließe.** - Vorbelegung aus Kontext, Validierung, Kosten-/Order-Vorschau, Bestätigung. - Risikohinweis & „keine Anlageberatung"-Abgrenzung integriert. ### Epic 7 — Funnel-Tracking & Event-Modell **Als Outcome Owner möchte ich den vollständigen Funnel je Surface messen, damit ich die fünf Lernziele mit Daten beantworten kann.** - Event-Modell (Abschnitt 12) als plattformneutrale Spec; im Prototyp als sichtbares Event-Log. - Surface-getrennte Stufen-Conversion; Broker-Mix; Unique Trader; Trades/User. ### Epic 8 — Low-Fi-Wireframe-System (App/Web, Konsistenz, A11y) **Als plattformübergreifendes Team möchten wir denselben Flow in App & Web testen, ohne uns auf Design festzulegen.** - Graustufig, Status über Form/Text statt Farbe; UX-Notizen ein-/ausblendbar. - App-Idiome (Bottom-Sheet, 1-spaltig) vs. Web (Modal/Side-Panel, mehrspaltig); Inhalt/Logik identisch. - Geteiltes Token-Set & Begriffs-Glossar (Anschluss an `onvista-signale`). ## 14. User Stories Format: **Als** \ **möchte ich** \, **damit** \. Priorisierung: `[M]` Must · `[S]` Should · `[C]` Could. ### Epic 1 — Auth-Zustände & Surface-Einstieg - **US-1.1 Auth umschalten `[M]`** — Als Tester möchte ich zwischen eingeloggt/ausgeloggt wechseln, damit ich beide Erlebnisse vergleiche. - AK: Umschalter im Tool-Chrome; Wechsel ändert das V/K-Klickverhalten sofort. - AK: aktueller Zustand jederzeit erkennbar. - **US-1.2 App/Web umschalten `[M]`** — Als Tester möchte ich App- und Web-Layout sehen, damit ich plattformidiomatische Unterschiede prüfe. - AK: identischer Flow/Inhalt; App = Bottom-Sheet/1-spaltig, Web = Modal/mehrspaltig. - **US-1.3 UX-Notizen ein/aus `[S]`** — Als Tester möchte ich Erklär-Notizen am Element ein-/ausblenden, damit Stakeholder Verhalten/Defaults verstehen. - **US-1.4 Surface wählen `[M]`** — Als Tester möchte ich zwischen Snapshot und Musterdepot springen, damit ich beide Hochintent-Surfaces durchspiele. ### Epic 2 — V/K am Snapshot/Chart - **US-2.1 Kaufen/Verkaufen am Kurs `[M]`** — Als eingeloggter Nutzer möchte ich am Kurs/Chart V/K-Buttons sehen, damit ich sofort handeln kann. - AK: V/K-Block am Preis-/Chart-Modul sichtbar; Instrument-Kontext (Notation, Kurs, Geld/Brief) sichtbar. - AK: Klick öffnet den Trade-Funnel (Connect ggf. → Order). - **US-2.2 Platzierungs-Varianten `[S]`** — Als Produktteam möchte ich ≥ 2 V/K-Platzierungen vergleichen, damit wir Banner-Blindheit gegensteuern. - **US-2.3 Ausgeloggter Snapshot-Klick `[M]`** — Als ausgeloggter Nutzer möchte ich beim V/K-Klick den getesteten Registrierungs-Übergang erleben. - AK: Verhalten = aktive Variante (A/B/C); Instrument-Kontext bleibt erhalten. ### Epic 3 — V/K im Musterdepot - **US-3.1 V/K je Position `[M]`** — Als eingeloggter Nutzer möchte ich pro Positionszeile kaufen/verkaufen, damit ich mein Depot direkt bewirtschafte. - AK: „Verkaufen" nur bei Bestand > 0; „Kaufen" immer. - AK: Order-Ticket vorbefüllt aus Position (Notation, Stück, Kurs). - **US-3.2 Tabs/Kontext erhalten `[S]`** — Als Nutzer möchte ich nach Order zurück in den Bestand, damit ich den Überblick behalte. - **US-3.3 Musterdepot-CTA schaltbar `[S]`** — Als Produktteam möchte ich das Musterdepot-CTA separat (de)aktivieren, damit wir es im Live-Test ggf. pausieren. ### Epic 4 — Registrierungs-Varianten - **US-4.1 Variante A: Gate-First `[M]`** — Als ausgeloggter Nutzer treffe ich beim V/K-Klick auf eine Login/Registrieren-Wand und kann danach fortsetzen. - AK: nach Registrierung Rückkehr in den Funnel ab Connect/Order. - **US-4.2 Variante B: Try-then-Register `[M]`** — Als ausgeloggter Nutzer kann ich das Order-Ticket frei ausfüllen und werde erst beim Submit zur Registrierung geführt. - AK: ausgefüllter Order-Kontext überlebt die Registrierung und wird fortgesetzt. - **US-4.3 Variante umschalten `[S]`** — Als Tester möchte ich die aktive Variante im Tool-Chrome wählen, damit wir A/B(/C) vergleichen. - **US-4.4 Variante C: Vorschau-Gate `[C]`** — Als Produktteam möchte ich optional ein read-only-Ticket mit Register-Overlay, falls A/B nicht trennscharf sind. ### Epic 5 — Broker-Connect & Broker-Mix - **US-5.1 Broker verbinden `[M]`** — Als Nutzer möchte ich einen Broker verbinden, damit ich handeln kann. - AK: Liste verbindbarer Broker; States nicht verbunden → verbinde… → verbunden; Abbruch-/Fehlerpfad. - **US-5.2 Broker auswählen `[M]`** — Als Nutzer mit mehreren Verbindungen möchte ich den Broker je Order wählen. - AK: Default = zuletzt/meistgenutzt, überschreibbar; Auswahl erzeugt Event mit `brokerId`. - **US-5.3 Connect aus dem Funnel `[M]`** — Als Nutzer ohne Verbindung möchte ich den Connect direkt aus dem V/K-Klick starten, ohne den Kontext zu verlieren. - **US-5.4 Mehrere Broker `[S]`** — Als Nutzer möchte ich mehrere Broker verbunden haben, damit ich flexibel bin. - **US-5.5 Standard-Broker im Profil festlegen `[S]`** — Als Nutzer möchte ich im Profil meinen Standard-Broker definieren, damit der Trade-Funnel ihn vorauswählt und der Connect-Schritt entfällt. - AK: Profil-View mit Verbinden/Trennen je Broker; genau ein Broker als ★ Standard markierbar. - AK: bei verbundenem Standard-Broker startet V/K direkt im Order-Ticket (Connect übersprungen), Broker vorausgewählt. - AK: Profil ist Logged-in-only (ausgeloggt → Login-Schranke); Trennen des Standards weist den Standard neu zu. ### Epic 6 — Order-Ticket - **US-6.1 Order ausfüllen `[M]`** — Als Nutzer möchte ich Stück/Betrag, Ordertyp und Gültigkeit setzen, damit ich meine Order definiere. - AK: Stück/Betrag gekoppelt; Market/Limit; bei Limit Limitpreis & Gültigkeit. - **US-6.2 Kosten-/Order-Vorschau `[M]`** — Als Nutzer möchte ich vor dem Absenden Volumen, Gebühren und Gesamtbetrag sehen. - **US-6.3 Validierung `[M]`** — Als Nutzer möchte ich vor Fehlern bewahrt werden (Verkauf > Bestand, Stück ≤ 0, kein Broker). - **US-6.4 Risikohinweis `[M]`** — Als Nutzer sehe ich Standard-Risikohinweis & „keine Anlageberatung", bevor ich bestätige. - **US-6.5 Bestätigung & Status `[M]`** — Als Nutzer erhalte ich nach Submit eine Order-Bestätigung mit Referenz und Weg zum Order-Status. ### Epic 7 — Funnel-Tracking - **US-7.1 Funnel je Surface `[M]`** — Als Outcome Owner möchte ich die Stufen-Conversion getrennt für Snapshot und Musterdepot, damit ich Surface-Performance vergleiche. - **US-7.2 Broker-Verteilung `[M]`** — Als Outcome Owner möchte ich die Broker-Verteilung der Trades, damit ich Verhandlungen steuern kann. - **US-7.3 Unique Trader & Frequenz `[M]`** — Als Outcome Owner möchte ich Unique Trader und Trades/connectetem User, damit ich LTV abschätzen kann. - **US-7.4 Sichtbares Event-Log `[S]`** — Als Tester möchte ich im Prototyp die erzeugten Events sehen, damit Tracking-Vollständigkeit prüfbar ist. - **US-7.5 Variant-Vergleich `[S]`** — Als Produktteam möchte ich die Drop-off-Kurven je Registrierungs-Variante vergleichen (Prototyp). ### Epic 8 — Low-Fi-Wireframe-System - **US-8.1 Graustufig & A11y `[M]`** — Als Team möchte ich Status über Form/Text statt Farbe, damit der Wireframe barrierearm und designneutral ist. - **US-8.2 Geteilte Begriffe/Tokens `[S]`** — Als Team möchte ich dasselbe Glossar/Token-Set wie bei `onvista-signale`, damit Produkte konsistent bleiben. - **US-8.3 Plattform-Idiome `[S]`** — Als Team möchte ich App-/Web-Idiome bei identischer Logik, damit beide Plattformen valide getestet werden. ## 15. Datenmodell (logisch) ``` User { id authState // GUEST | LOGGED_IN segment // MUSTERDEPOT_HEAVY | WATCHLIST_HEAVY | SNAPSHOT_READER (für Cohort) brokerConnections // [BrokerConnection] defaultBrokerId } Instrument { // wiederverwendet aus signale-Logik id, name, type, isin, wkn notations [ { id, name, currency, price, bid(Geld), ask(Brief), prevClose } ] mainNotation } Position { // Musterdepot instrumentId, notationId quantity, avgBuyPrice, currentPrice, value } BrokerConnection { brokerId, name status // NOT_CONNECTED | CONNECTING | CONNECTED | ERROR connectedAt } Order { id instrumentId, notationId direction // BUY | SELL orderType // MARKET | LIMIT limitPrice?, validity quantity | amount brokerId status // DRAFT | SUBMITTED | CONFIRMED | CANCELLED surface // SNAPSHOT | MUSTERDEPOT (Herkunft für Funnel) createdAt, submittedAt, confirmedAt } FunnelEvent { type // surface_view | cta_click | connect_start | connect_complete // order_open | order_submit | trade_confirmed | gate_shown | gate_passed surface, authState, instrumentId brokerId?, direction?, orderType?, variant? timestamp } ``` ## 16. Low-Fi-Wireframe-Prinzipien (Anschluss an `onvista-signale`) - **Graustufig, kein visuelles Design** — validiert UX vor Branding. Status über **Form/Füllung/Text statt Farbe** (A11y). - **App ⇄ Web-Umschalter** — identischer Flow; App = Bottom-Sheet/1-spaltig, Web = Modal/Side-Panel/mehrspaltig. - **Auth-Umschalter** (eingeloggt/ausgeloggt) + **Variant-Umschalter** (A/B/C) als Tool-Chrome — nicht Teil des Produkts. - **UX-Notizen** ein-/ausblendbar; erklären Verhalten, Defaults, Edge-Cases am Element. - **Token-/Begriffs-Set** geteilt mit `onvista-signale` (Tokens siehe `signale/docs/03-prd.md` §12); Begriffe Kauf/Verkauf, Geld/Brief, Market/Limit, Ordertyp, Gültigkeit konsistent. - **Tech (Vorschlag, wie Signale):** vanilla HTML/CSS/JS, statischer Node-Server (`server.js`), kein Build; Landing verlinkt `prototype-wireframe/` (Low-Fi) und später `prototype/` (Hi-Fi). ## 17. Erfolgsmetriken & Anti-Metriken **Primär (Lernziel-relevant):** - Funnel-Conversion je Stufe **je Surface** (Snapshot vs. Musterdepot). - **Unique Trader** (≥ 1 Trade im Zeitraum). - **Broker-Verteilung** der entstandenen Trades. **Sekundär (direktional):** - Absolute Trade-Anzahl in 2–4 Wochen (Direction-Check vs. Baseline ~285 Trades/Woche systemweit). - Multibrokerage-Provisionserlös (Baseline-Check vs. ~1.200 €-Jahreswert). - WAU-Veränderung (Nebeneffekt, nicht der Hebel). - **Prototyp:** Usability-Erfolgsrate & Drop-off je Registrierungs-Variante. **Anti-Metriken (darf nicht passieren):** - Beschwerden/negative Feedbacks zur UI-Änderung. - Compliance-Auffälligkeiten (Risikohinweise, Anlageberatungs-Abgrenzung). ## 18. Compliance & Risiken | Risiko | Mitigation | |---|---| | Banner-Blindheit (CTAs ignoriert) | ≥ 2 Platzierungs-Varianten; Iteration nach Woche 1 | | Compliance (Risikohinweis, Anlageberatungs-Abgrenzung) | Legal **vor** Build einbinden; Standard-Risikohinweise re-use; im Ticket fest verankert | | Musterdepot-User ohne Trade-Intent | Cohort-Segmentierung pre-test; Musterdepot-CTA separat schaltbar (Pausierung möglich) | | Tech-Aufwand > Schätzung (Broker-API) | Erst Brokerize-Anbindung prüfen; kein neuer Broker-Vertrag in Scope | | State-Verlust bei Try-then-Register (Variante B) | Order-Kontext muss Registrierung überleben — explizit testen | | SEO-/Brand-Risiko (ausgeloggt) | Im **Live-Test** ausgeschlossen; ausgeloggt nur im risikofreien Prototyp | ## 19. Offene Punkte & benötigte Screens (vor/parallel zum Build) **Offene Produkt-/Entscheidungspunkte:** - Welche Registrierungs-Variante geht in die Folge-Wette? → Output dieses Prototyp-Tests. - Finale **Broker-Liste** aus Brokerize (welche Broker, welche Connect-Mechanik)? - Genaue **Compliance-Texte** (Risikohinweis, Anlageberatungs-Abgrenzung) von Legal. - Testdauer: 4 Wochen initial, Option +1–2 Wochen ohne neues Approval (Signifikanz auf Segment-Ebene knapp bei ~285 Trades/Woche). - Musterdepot-Segment-Analyse (Woche 0): Sind Musterdepot-User trade-bereit? Wer macht die Analyse (Product-Insights-Slot)? - Stock3-Benchmark (~500.000 Trades/Quartal) belastbar zitierbar? (Geschäftsbericht.) **Konkret benötigte Screens/Assets für die nächste Iteration (du kündigst sie an):** 1. **Figma-Mockups der V/K-Komponenten** (Multibrokerage-File) — finale Anatomie der Buttons/Blocks an Snapshot & Musterdepot. 2. **Element-Screenshots** des Order-Tickets (Felder, Ordertypen, Vorschau) — falls eine Zielanatomie existiert. 3. **Broker-Connect-Screens** (falls vorhanden) — wie sieht der Brokerize-Connect heute aus? 4. **Musterdepot-Detail:** Verhalten der Tabs *Bestand/Signale/Verkäufe/Transaktionen*, falls die Order dorthin zurückführt. > Sag mir, ob (1)–(4) so passen — dann baue ich die `prototype-wireframe/` exakt auf diese Anatomie statt auf Annahmen. ## 20. Rollout & nächste Schritte 1. **Analyse (Woche 0):** Musterdepot-Segment-Analyse + Funnel-Baseline (validiert größte Annahme: Trade-Bereitschaft). 2. **UX/Wireframe (Woche 1):** `prototype-wireframe/` bauen — Surfaces, Funnel, Auth-Zustände, Registrierungs-Varianten, Event-Log (auf Basis dieses PRD + Element-Screenshots). 3. **Build (Woche 2):** Dev setzt V/K-Komponenten für Chart & Musterdepot um, implementiert Tracking. 4. **Test (Woche 2–3):** Live-Schaltung (logged-in only), tägliches Funnel-Monitoring. 5. **Auswertung (Woche 6–8):** Lernziele beantworten, Entscheidung **Stop / Verlängern / Skalieren**; bei Erfolg Folge-Wette für ausgeloggte Surfaces (Registrierungs-Variante steht aus Prototyp-Test bereit). --- > Hinweis: Trade-CTAs sind Information/Zugang, keine Anlageberatung. Kurse und Orders im Prototyp sind simuliert.