From 911697bab4adc75b330d98cd1c0b589690b16820 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Mon, 18 May 2026 18:38:30 +0200 Subject: [PATCH] feat(marketing): Saving-Section + Landingpages + Pipeline Lessons-Learned [split-required] Marketing-Website - Neue SavingsSection auf Homepage: "Compliance entdeckt sechsstellige Einsparungen". Pitch-Position der Cookie-Audit-Cost-Optimization-Story fuer DAX-Konzern-Sales (BMW-Case-Style: 90 Vendors -> 25 nach Konsolidierung, EUR 500k-3M / Jahr). - /savings-scan: Kostenloser 5-Min-Saving-Scan-Form (URL + E-Mail). Form-Submit ist Placeholder, soll an Compliance-Backend gehaengt werden. - /savings-methodik: 4-Stufen-Erklaerung der Cookie-Tier-Inferenz + ehrliche Caveats (Listpreise != Vertragspreise, Media-Spend nicht enthalten) + Datenquellen. - Content-de + Content-en in content.ts beide um savings-Block ergaenzt und Section-Numerierung angepasst (03=Savings, 04=Deterministic). - LOC-Split: savings-Inhalte (DE+EN, ~100 LOC) in content.savings.ts ausgelagert damit content.ts unter 500-LOC-Hard-Cap bleibt. Control-Pipeline - LESSONS-LEARNED-mc-check-types.md fuer die parallele CRA-MC-Generation. Erklaert die TEXT/PROCESS/REVIEW-Klassifikation die im Compliance-Repo retrofitted wurde. Verhindert dass CRA-MCs denselben Defekt bekommen. Mapping-Heuristik fuer verification_method -> check_type, plus Backfill-Workflow fuer ~62 ambiguous Eintraege. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../LESSONS-LEARNED-mc-check-types.md | 132 +++++++++++ marketing-website/app/page.tsx | 2 + .../app/savings-methodik/page.tsx | 213 ++++++++++++++++++ marketing-website/app/savings-scan/page.tsx | 169 ++++++++++++++ .../components/sections/SavingsSection.tsx | 115 ++++++++++ marketing-website/lib/content.savings.ts | 98 ++++++++ marketing-website/lib/content.ts | 8 +- 7 files changed, 735 insertions(+), 2 deletions(-) create mode 100644 control-pipeline/LESSONS-LEARNED-mc-check-types.md create mode 100644 marketing-website/app/savings-methodik/page.tsx create mode 100644 marketing-website/app/savings-scan/page.tsx create mode 100644 marketing-website/components/sections/SavingsSection.tsx create mode 100644 marketing-website/lib/content.savings.ts diff --git a/control-pipeline/LESSONS-LEARNED-mc-check-types.md b/control-pipeline/LESSONS-LEARNED-mc-check-types.md new file mode 100644 index 0000000..02622f4 --- /dev/null +++ b/control-pipeline/LESSONS-LEARNED-mc-check-types.md @@ -0,0 +1,132 @@ +# Lessons Learned — MC `check_type` Klassifikation (KRITISCH fuer CRA + alle neuen Frameworks) + +Datum: 2026-05-17 +Auslöser: Compliance-Check BMW lieferte 0/381 Cookie-MCs, 3/75 Impressum-MCs, 43/571 DSE-MCs — alle Doc-Typen unter 20%. + +## TL;DR + +**Die heutigen Master-Controls (MCs) vermischen drei strukturell unterschiedliche Klassen von Pruefungen in einer einzigen Tabelle (`compliance.doc_check_controls`). Nur eine der drei Klassen lässt sich gegen Dokument-Text matchen. Die anderen zwei werden faelschlich als "failed" gezaehlt, weil sie ueberhaupt nicht ueber Text-Matching gepruefbar sind.** + +Bei der CRA-MC-Generierung (laeuft jetzt im Pass 0a mit Haiku) **MUSS** jeder MC ein **`check_type`-Feld** bekommen, bevor er in die Datenbank geht. Sonst wiederholt sich das Problem. + +## Die drei Klassen + +| `check_type` | Pruefungsfrage-Pattern | Beispiel | Wie pruefbar? | +|---|---|---|---| +| **`text`** | "Enthaelt das Dokument...", "Wird im X die Y benannt?", "Ist im Text aufgelistet..." | "Wird im Impressum die Aufsichtsbehoerde benannt?" | Regex / Embedding-Match gegen Doc-Text | +| **`process`** | "Ist sichergestellt...", "Ist implementiert...", "Wird durchgefuehrt..." | "Ist sichergestellt, dass Cookies erst nach Einwilligung gespeichert werden?" | Evidence/TOM-Check — kein Doc-Text vorhanden | +| **`review`** | "Sind ALLE / Werden ALLE / Stimmt X mit Y ueberein?" | "Sind alle Verarbeitungszwecke vollstaendig erfasst?" | Mensch (DSB) — Checkliste, nicht automatisch | + +## Befund aus den BMW-Daten + +| Doc-Type | TEXT (matchbar) | PROCESS | UNKLAR/REVIEW | Total | % TEXT | +|---|---|---|---|---|---| +| cookie | 30 | 49 | 302 | 381 | **8%** | +| dse | 72 | 139 | 359 | 571 | **13%** | +| impressum | 14 | 14 | 47 | 75 | **19%** | +| agb | 24 | 20 | 69 | 113 | 21% | +| widerruf | 29 | 26 | 96 | 153 | 19% | +| loeschkonzept | 38 | 39 | 232 | 309 | 12% | + +**Selbst mit perfektem Matching liegt die Obergrenze fuer doc_check bei 8-20%**, weil 80-92% der MCs nicht ueber Text-Matching pruefbar sind. Es sind keine "schlechten MCs" — sie sind in der falschen Schublade. + +## Konsequenzen fuer CRA-Generation (Pass 0a) + +### 1. Prompt-Aenderung (Hauptmassnahme) + +Der Pass-0a-Prompt fuer Haiku/Sonnet MUSS pro generiertem Control ein `check_type`-Feld erzwingen. Vorschlag: + +```jsonc +{ + "control_id": "CRA-...-A01", + "title": "...", + "check_question": "...", + "check_type": "text" | "process" | "review", // PFLICHT + "rationale_for_check_type": "..." +} +``` + +Klassifikations-Regel im Prompt: + +> Wenn deine `check_question` mit "Enthaelt", "Wird … genannt/aufgelistet/erwaehnt", "Steht im Text" beginnt -> `text`. +> Wenn sie mit "Ist sichergestellt", "Ist implementiert", "Wird durchgefuehrt", "Existiert ein Prozess" beginnt -> `process`. +> Wenn sie mit "Sind ALLE", "Werden ALLE", "Stimmt X mit Y ueberein" beginnt -> `review`. +> Im Zweifel: lieber `review` als `text`. + +### 2. Doc-Type-Zuordnung kritisch validieren + +Bei den heutigen MCs sind viele falsch zugeordnet (z.B. "Bestellbestätigung implementieren" landet im `impressum`-doc_type, gehoert aber zu AGB/Widerruf). Fuer CRA: + +- **`doc_type` darf nur Werte aus einer expliziten Liste annehmen** — pro Regulation festlegen. +- Fuer CRA z.B.: `produkt_konformitaetserklaerung`, `risiko_management_dossier`, `sbom`, `cra_dse`, `meldepflichten_doku`. +- Falsche Zuordnung im Prompt explizit verbieten: "Wenn der Control nicht eindeutig zu EINEM dieser Doc-Typen passt, setze `doc_type: 'unassigned'` und `check_type: 'review'`." + +### 3. Zwei Tabellen statt einer + +Heutige Architektur: +- `compliance.doc_check_controls` <- alle 1874 MCs (mit allem vermischt) + +Empfohlen fuer CRA + Refactor: +- `compliance.text_check_controls` <- nur `check_type='text'` +- `compliance.process_check_controls` <- nur `check_type='process'`, gepruefte via Evidence/TOM +- `compliance.review_checklist_controls` <- nur `check_type='review'`, gepruefte via DSB-Workflow + +Falls Schema-Aenderung nicht moeglich (CLAUDE.md: DB ist frozen), Sidecar-SQLite mit `mc_classification.db` oder neue Spalte als Add-only-Migration. + +### 4. Dedupe-Phase respektieren + +In Pass 0b (Dedup) muss `check_type` ein **Pflicht-Dedupe-Key** sein: +- Zwei MCs mit gleicher Aussage aber unterschiedlichem `check_type` sind **nicht** Duplikate — sie pruefen verschiedene Dinge ("ist im Text genannt" vs "ist technisch implementiert"). +- Heute werden solche faelschlich gemerged → noch mehr Vermischung. + +### 5. Matching-Engine danach umbauen + +Das eigentliche doc-check-Match-System muss nur noch `check_type='text'`-MCs verarbeiten. Andere werden in ihre eigenen Module geroutet: + +- `text` MCs -> `rag_document_checker` (Regex + spaeter Embedding) +- `process` MCs -> neuer `evidence_check_runner` (Kunde lieferte Nachweise/TOM hoch) +- `review` MCs -> neuer `review_checklist_ui` (DSB beantwortet manuell) + +## Checkliste fuer CRA-Session + +- [ ] Pass-0a-Prompt um `check_type`-Pflichtfeld erweitert (Wortlaut-Regel + Beispiele) +- [ ] Pass-0a-Prompt zwingt `doc_type` aus expliziter Whitelist +- [ ] Pass-0b-Dedup-Key enthaelt `check_type` +- [ ] Output-Validator weist MCs ohne `check_type` zurueck +- [ ] DB-Schema (oder Sidecar) hat `check_type`-Spalte mit Default `review` (sicherer Fallback) +- [ ] Stichprobe von 50 generierten CRA-MCs vor Bulk-Run: TEXT-Anteil sollte 30-50% sein (mehr als bei den alten DSGVO-MCs, weil CRA stark dokument-fokussiert ist). + +## Update 2026-05-17 — Parallel-CRA-Session-Findings + +Die laufende CRA-Generation hat ein Feld `verification_method` (document/tool/hybrid/code_review/empty), das **NICHT identisch** mit `check_type` ist: + +- `verification_method` fragt: **WAS schaust du dir an?** (Dokument, Tool-Output, Code) +- `check_type` fragt: **KANN das per Text-Match geprueft werden?** (text/process/review) + +Ein Control kann `verification_method=document` haben UND trotzdem `check_type=process` sein. Beispiel: "Wird die SBOM regelmaessig (mindestens monatlich) aktualisiert?" — Du schaust ins Dokument SBOM-Historie, prüfst aber einen Prozess. Text-Match findet das nie. + +**Mapping-Heuristik (gut genug fuer 80% der Faelle, Rest LLM):** + +| `verification_method` | Auto-Mapping `check_type` | LLM noetig? | +|---|---|---| +| `tool` | `process` | nein | +| `code_review` | `process` | nein | +| empty/null | `review` (sicherer Default) | nein | +| `document` | erstmal `text`, Stichprobe pruefen | 10-20% sampling | +| `hybrid` | LLM klassifizieren | ja, alle | + +**Idealfall (fuer alle KUENFTIGEN Pass-0a-Generationen — auch CRA falls man nochmal generiert):** Beide Felder gleichzeitig generieren, nicht eins aus dem anderen ableiten. + +## Backfill-Workflow fuer die laufende CRA-Generation + +1. Aktueller Haiku-Job laeuft fertig (kein Restart, kein Verlust) +2. Nach Job-Ende: Auto-Mapping fuer eindeutige Buckets (tool/code_review/empty) +3. Sonnet-Klassifikation nur fuer `document`+`hybrid` Subset (~62 Calls fuer 1500 Controls, ~$0.05 statt $2) +4. Wiederverwenden: `breakpilot-compliance/backend-compliance/scripts/classify_mc_check_type.py` — nur DB-Query anpassen (Source-Tabelle + WHERE-Filter) +5. Validierung: TEXT-Anteil bei CRA sollte 40-60% sein (CRA ist dokument-zentrierter als DSGVO-Cookie) + +## Quervewweise + +- BMW-Run-Befund: `breakpilot-compliance` E-Mail vom 2026-05-17, check_id `08bcc9dd` +- Bestehender Klassifikations-Skript fuer Retrofit der alten 1874: `backend-compliance/scripts/classify_mc_check_type.py` +- Doc-Type-Audit-Query: dieselbe Datei, am Ende diff --git a/marketing-website/app/page.tsx b/marketing-website/app/page.tsx index 9d1f7c2..5251151 100644 --- a/marketing-website/app/page.tsx +++ b/marketing-website/app/page.tsx @@ -3,6 +3,7 @@ import Footer from '@/components/layout/Footer' import ChatFAB from '@/components/layout/ChatFAB' import HeroSection from '@/components/sections/HeroSection' import ProblemFlowSection from '@/components/sections/ProblemFlowSection' +import SavingsSection from '@/components/sections/SavingsSection' import UseCaseCards from '@/components/sections/UseCaseCards' import TrustBar from '@/components/sections/TrustBar' @@ -13,6 +14,7 @@ export default function HomePage() {
+
diff --git a/marketing-website/app/savings-methodik/page.tsx b/marketing-website/app/savings-methodik/page.tsx new file mode 100644 index 0000000..4d76d6f --- /dev/null +++ b/marketing-website/app/savings-methodik/page.tsx @@ -0,0 +1,213 @@ +import Navbar from '@/components/layout/Navbar' +import Footer from '@/components/layout/Footer' +import ChatFAB from '@/components/layout/ChatFAB' +import PageHeader from '@/components/ui/PageHeader' +import GlassCard from '@/components/ui/GlassCard' +import FadeInView from '@/components/ui/FadeInView' +import { Database, Layers, Calculator, AlertTriangle, Globe, Cookie } from 'lucide-react' + +export default function SavingsMethodikPage() { + return ( + <> + +
+
+ +
+ + {/* 4 Stufen */} +
+
+ + +
+
+ +
+
+
STUFE 1
+

Cookie-Footprint extrahieren

+

+ Playwright laedt die Webseite vollstaendig (inkl. JavaScript-Rendering) + und erfasst jeden gesetzten Cookie + jeden CMP-Payload + (ePaaS, OneTrust, Usercentrics, Cookiebot, Didomi, TrustArc). +

+
    +
  • • Cookie-Namen, Werte, Domains, Lifetimes
    • +
  • • IAB TCF v2.2 Vendor-Liste auswerten (Vendor-IDs zur eindeutigen Zuordnung)
    • +
  • • Drittanbieter-Quote pro Cookie
    • +
  • • Premium-Feature-Cookies erkennen (z.B. s_target_qa = Adobe Target Enterprise)
    • +
+
+
+ + + + + +
+
+ +
+
+
STUFE 2
+

Wissens-Datenbank-Abgleich

+

+ Jeder Cookie wird gegen unsere kuratierte Wissens-DB mit derzeit + ~50 Top-Vendors abgeglichen. Pro Cookie wissen wir: +

+
    +
  • • Setzender Anbieter + Sitzland
    • +
  • • Exakter funktionaler Zweck (nicht nur Kategorie)
    • +
  • • Welche Datenfelder gesammelt werden (Client-ID, IP, etc.)
    • +
  • • Re-Identifikations-Risiko (low/medium/high)
    • +
  • • §25(2) TDDDG technische Notwendigkeit
    • +
  • • Schrems-II-Status + relevante EuGH-/CNIL-Urteile
    • +
  • • Konkreter EU-Alternativ-Cookie + EU-Alternativ-Vendor
    • +
+
+
+ + + + + +
+
+ +
+
+
STUFE 3
+

Tier-Inferenz + Funktionale Kategorisierung

+

+ Pro Vendor leiten wir das Pricing-Tier aus dem Cookie-Footprint ab: +

+
    +
  • • <10 Cookies = Starter-Plan
    • +
  • • 10-30 Cookies = Professional / Mid-Market
    • +
  • • 30-60 Cookies = Enterprise
    • +
  • • >60 Cookies + Premium-Features = Premier-Tier
    • +
+

+ Parallel werden alle Vendors funktional klassifiziert (Web-Analytics, + Werbung, CDN, Marketing-Automation, …). Mehrere Vendors in + derselben Kategorie = Konsolidierungs-Kandidat. +

+
+
+ + + + + +
+
+ +
+
+
STUFE 4
+

Kosten-Schaetzung + EU-Konsolidierung

+

+ Pro Tier multiplizieren wir mit unseren Pricing-Lookups + (Gartner/Forrester 2025 + oeffentliche Listpreise). + Ergebnis: jaehrlicher Kostenbereich pro Vendor. +

+
    +
  • • Master-Vertrag-Dedupe (1 Adobe-Lizenz, viele Features)
    • +
  • • EU-Alternative mit gleicher Funktion + Listpreis
    • +
  • • Multi-Funktions-Tools die mehrere Kategorien gleichzeitig ersetzen
    • +
  • • Sparpotenzial = Aktuelle Listpreise − EU-Tool-Listpreis
    • +
+
+
+ + +
+
+ + {/* Caveats — ehrlich */} +
+
+

+ + Was wir NICHT versprechen +

+
+ +

Listpreise ≠ Vertragspreise

+

+ Konzern-Konditionen liegen ueblicherweise 30–50% unter Listpreis. + Wir geben Bereiche an, nicht exakte Zahlen. Verifikation mit dem + eigenen Einkauf ist Pflicht. +

+ + +

Funktionale Redundanz ≠ Strategische Redundanz

+

+ Mehrere Analytics-Tools koennen legitim sein (A/B-Test, regional split, + Marketing vs Produkt). Wir nennen die bekannten Gruende explizit. +

+ + +

Media-Spend nicht enthalten

+

+ Google-Ads-/Meta-Ads-/Programmatic-Budget ist NICHT in der Saving- + Schaetzung. Nur Tool-Lizenzen. Media-Optimierung ist ein separates + Thema. +

+ + +

Migrations-Kosten nicht abgezogen

+

+ Tool-Wechsel kostet Zeit + interne Implementation. Faustregel: + 3-6 Monate Amortisation einrechnen. Saving-Schaetzung ist Brutto. +

+ +
+
+
+ + {/* Datenquellen */} +
+
+

+ + Datenquellen + Updates +

+ +
    +
  • + Cookie-Wissen:{' '} + Cookiepedia, IAB Europe TCF v2.2 Vendor-Liste, Cookiebot Public DB, + Vendor-eigene Dokumentation +
    • +
  • + Pricing:{' '} + Gartner Hype Cycle 2025, Forrester Wave MarTech 2025, oeffentliche + Pricing-Pages, anonymisierte Kundengespraeche +
    • +
  • + Regulatorik:{' '} + EDPB Cookie Guidelines 2/2023, DSK-Orientierungshilfe Telemedien 2024, + CNIL Cookies-Recommendations +
    • +
  • + Updates:{' '} + DB wird kontinuierlich gepflegt. Neue Kunden geben uns Ground-Truth + fuer Kalibrierung. +
    • +
+ +
+
+
+