Kunden-Case · redigiert
Vertikales Vergleichsportal mit einem Betreiber-Bias-Problem.
Ein Engagement, bei dem der schwierigste Teil weder das Frontend noch das Matching war — sondern die Frage, in Code und Scoring-Architektur zu beantworten: Kann ein Vergleichsportal glaubwürdig sein, wenn sein Betreiber zugleich einer der gelisteten Anbieter ist?
- —Reales Engagement; Namen, Branche und Zahlen einvernehmlich redigiert.
- —Architektur, Scoring-Regeln, Daten-Taxonomie und Governance-Disziplin werden vollständig offengelegt.
- —Die Redactions sind explizit markiert — keine Pseudo-Konkretheit, die einen Namen vorgaukelt.
// Engagement-Form
- Kunde
- [REDACTED] — B2B-Anbieter in einem vertikalen Industrie-Dienstleistungssegment
- Setting
- Der Betreiber ist zugleich einer der gelisteten Anbieter auf dem Portal
- Scope
- Vergleichs- und Matching-Portal, von Recherche bis Produktion
- Rolle
- End-to-end: Recherche, Datenmodell, Scoring, Validierung, Frontend, Release
- Status
- Live; Iteration unter validierter Scoring-Baseline
- Offenlegung
- Einvernehmlich redigiert; Mechanik und Architektur offengelegt
Kontext
Ein selbstbetriebenes Vergleichsportal in einem vertikalen B2B-Markt.
Der Kunde operiert in einem engen B2B-Dienstleistungssegment — eng genug, dass Käufer eine Handvoll Kandidaten haben und fast keine unabhängige Möglichkeit, sie zu vergleichen. Der Kunde entschied, das fehlende Vergleichsportal selbst zu bauen.
Diese Entscheidung schuf ein Governance-Problem, bevor ein technisches entstand. Der Kunde ist zugleich einer der Anbieter, die das Portal listet. Ein Leser, der das bemerkt — und anspruchsvolle B2B-Käufer bemerken es — wird dem Portal nur dann trauen, wenn die Architektur die Bias-Frage beantwortbar macht.
Das Engagement wurde daher um Glaubwürdigkeit als Systemeigenschaft aufgespannt, nicht als Copy-Behauptung. Alles andere — Recherche-Template, Datenschema, Frontend, Matching-Logik — folgte aus dieser Randbedingung.
Ausgangsproblem
Vier Dinge mussten sich ändern, bevor eine einzelne Seite ausgeliefert wurde.
-
Die selbstbetriebene Vergleichsplattform hatte ein Glaubwürdigkeitsproblem, bevor sie ein technisches hatte.
Der Betreiber ist zugleich einer der gelisteten Anbieter. Diese strukturelle Verzerrung muss in der Scoring-Architektur beantwortet werden, nicht im Copy — sonst ist das Portal eine Marketing-Oberfläche, kein Vergleichstool.
-
Datenqualität auf Feldebene wurde stillschweigend geschätzt.
Anbieterprofile mischten belegte Fakten, plausible Schätzungen und logische Ableitungen ohne Marker pro Feld. Das machte nachgelagertes Filtern und Scoring unsauber — und für den Leser unsichtbar.
-
Vokabular driftete zwischen den Anbieterprofilen.
Kategorien, Preismodelle und Servicebegriffe wurden über Profile hinweg inkonsistent paraphrasiert. Filterergebnisse hingen davon ab, welches Synonym eine Researcherin an welchem Tag gewählt hatte.
-
Die Scoring-Logik war selbst für ihre Autoren undurchsichtig.
Keine Validierungs-Suite; keine gearbeiteten Beispiele gegen realistische Kaufprofile; keine Möglichkeit, den Fall zu fangen, in dem eine kleine Dimension eine grosse still überwältigt.
Was gebaut wurde
Sechs Artefakte, jedes zu einer Datei im Projekt-Repo rückverfolgbar.
Jedes Item nennt den Ort im Projekt-Repo, an dem das Artefakt liegt. Das Repository selbst ist privat; die Architektur hier ist der veröffentlichbare Teil.
// Artefakte
- 01
Glaubwürdigkeits-orientierte Scoring-Prinzipien
docs/scoring-strategy.md
Vier Prinzipien, kodifiziert als Randbedingungen des Scoring-Codes: Belegbarkeit vor Eigeninteresse; Transparenz der Gewichte; Nutzerrelevanz als Massstab; Ausschluss statt Abwertung. Kein Kriterium bevorzugt den Betreiber ohne öffentliche Quelle.
- 02
Harte Filter vs. weiche Differenzierung
scoring.ts · zweistufige Logik
Harte Filter (Servicegebiet, Mindestgrösse, Cashless-only, App-Pflicht, Vertragslaufzeit) schliessen ein oder aus — sie verändern keinen Score. Differenzierungs-Kriterien aktivieren sich nur, wenn der Nutzer die Präferenz explizit nennt.
- 03
Typisierte Datenkonfidenz-Taxonomie
Frontmatter: verified · estimated · inferred · unknown
Jedes Anbieterfeld trägt einen Konfidenz-Status. "Unknown" ist ein erstklassiger Wert, keine Leerstelle. Das Frontend zeigt den Status, wenn er eine Ranking-Aussage betrifft — der Leser sieht die Konfidenz, nicht nur das Ergebnis.
- 04
Normalisierungsregeln als Code
docs/normalization-rules.md · validate-frontmatter.py
Kontrolliertes Vokabular für Kategorien, Preismodelle, Servicebegriffe und regionale Abdeckung. Ungültige oder Alt-Werte fallen im CI-Stil durch den Validator. Paraphrasierung hört als Drift-Quelle auf.
- 05
Scoring-Validierungs-Suite
scripts/validate-scoring.js · 5 Kaufprofile
Fünf realistische B2B-Kaufprofile über Grössenbänder, Umfelder und Präferenz-Flags. Jede Scoring-Änderung läuft gegen die gesamte Matrix. Die entstehende Rangtabelle ist das Regressions-Artefakt.
- 06
Markdown → JSON Export-Pipeline
scripts/md-to-json.py · scripts/validate-export-integrity.py
Recherche lebt als prüfbares Markdown mit YAML-Frontmatter. Export normalisiert zu JSON unter dem publizierten Schema. Ein Integrity-Check stellt sicher, dass das Frontend nur vokabulartaugliche Werte sieht.
Delivery & Safeguards
Governance-Disziplinen, die die Glaubwürdigkeits-Randbedingung tragend hielten.
-
Nummeriertes Defect-Log, kein Ad-hoc-Gedächtnis.
Jeder während der Validierung gefundene Scoring-Defekt wurde mit Identifier festgehalten (B-1 für Bugs, F-1…F-5 für Fixes), einer einzeiligen Beschreibung und dem Profil oder Ausdruck, der ihn ausgelöst hat. Dieses Log ist der Audit-Trail für jede spätere Änderung.
-
Betreiber-Neutralität als prüfbare Eigenschaft.
Weil der Betreiber im Vergleich selbst sitzt, prüft die Scoring-Suite explizit Kaufprofile, in denen der Betreiber NICHT an erster Stelle ranken sollte — und schlägt fehl, wenn er es ohne Evidenz-Deckung tut. Der Bias-Guardrail ist im Test, nicht im Ton.
-
Ausschluss, wo Evidenz fehlt.
Anbieter ohne Hard-Filter-Feld für eine gegebene Kaufabfrage werden aus dieser Abfrage ausgeschlossen — sie werden nicht niedriger gerankt mit einer impliziten Strafe. Die Alternative straft weniger dokumentierte Anbieter still ab; sie wurde bewusst verworfen.
-
Recherche und angezeigte Inhalte sind rückverfolgbar.
Jede im Portal sichtbare Aussage ist zu einem quellbelegten Feld im Research-Markdown rückverfolgbar. Ein Leser (oder ein Prüfer) kann den Weg von einer Vergleichszeile bis zum Anbieterprofil und zur zugrundeliegenden Quelle nachgehen.
Ergebnis
Operative Anker, keine aufgeblähten Kennzahlen.
Die Ergebnisse unten beschreiben Systemeigenschaften, die durch erneutes Ausführen der Validierungs-Suite gegen den Datensatz reproduziert werden können — keine Marketing-Aussagen. Kommerzielle Performance-Zahlen werden nicht offengelegt.
- ✓ Fünf realistische Kaufprofile ranken Anbieter gegen eine validierte Scoring-Baseline — ein erneuter Suite-Lauf nach einer Änderung zeigt Regressionen vor dem Release.
- ✓ Mehrere Scoring-Defekte wurden während der Validierung gefangen und gefixt (Bug-Register mit IDs B-1 und F-1 bis F-5), darunter eine Regex, die einen regionalen Anbieter fälschlich in einem bundesweiten Ergebnis hielt, und eine Dimension, die die Primärpräferenz still überwältigte.
- ✓ Anbieterprofile nutzen eine verified / estimated / inferred / unknown Konfidenz-Taxonomie — unknown wird ehrlich erfasst, statt mit einer plausiblen Vermutung gefüllt.
- ✓ Betreiber-Bias-Risiko ist strukturell adressiert: der Betreiber erscheint nur dann als Top-Ranked, wenn Kaufpräferenzen und öffentliche Evidenz beides stützen. Die Prüfung liegt in der Suite, nicht im Marketing-Copy.
- ✓ Vokabular-Normalisierung macht aus paraphrase-getriebenem Filter-Drift eine vom Validator erzwungene Eigenschaft: ungültige Kategorie-, Preismodell- oder Servicebegriffe fallen im Profil-Check durch.
// Outcome-Anker · in Vorbereitung
Ein weiterer Anker wird mit dem Kunden vorbereitet — eine freigegebene Zahl, eine unterzeichnete Aussage oder ein Vorher/Nachher zu einer konkreten Systemeigenschaft. Bis zur Freigabe verankert diese Seite Ergebnisse nur in den oben beschriebenen Systemeigenschaften. Aktuell diskutierte Anker-Typen:
- —Governance- / Review-Gewinn: vor Release verhinderte Betreiber-Bias-Vorfälle; Audit-Trail-Abdeckung der Ranking-Entscheidungen.
- —Adoptions-Signal, das dem Portal ohne Triangulation zuordenbar ist.
- —Freigegebene Kundenstimme zur Scoring-Disziplin oder zur Konfidenz-Taxonomie.
- —Redigiertes, aber echtes Vorher/Nachher zum Betreiber-Ranking über die Kaufprofil-Matrix.
Dieser Slot wird bewusst offen gehalten. Die Alternative — eine plausibel wirkende Zahl ohne Freigabe zu publizieren — widerspräche dem Case selbst.
Grenzen
Was redigiert ist — und warum die Redactions markiert sind.
Redaction wird als Eigenschaft des Cases behandelt, nicht als Einschränkung. Die Alternative — weiche Paraphrase ohne benannte Lücken — wäre weniger glaubwürdig, nicht mehr.
- — Kunde, Branche und Wettbewerbernamen sind redigiert. Das Portal ist für Kenner der Domain erkennbar; diese Seite benennt es nicht, damit die Darstellung übertragbar bleibt.
- — Konkrete Gewichtungswerte, Dimensions-Caps und Tiebreaker-Regeln werden nicht offengelegt. Die Struktur des Scorings (Hard Filter vs. Differenzierer; Evidenz-Regel; Ausschluss-Regel) ist offengelegt; die Zahlen nicht.
- — Die vollständige Anbieterliste wird hier nicht offengelegt. Sie ist auf dem Portal selbst öffentlich und auf Anfrage zugänglich.
- — Kommerzielle Konditionen des Engagements werden nicht offengelegt.
- — Konkrete für die Validierung verwendete Kaufprofile werden abstrakt beschrieben (Grössenband, Umfeld, Priorität, Region, Flags); exakte Parameter und erwartete Rangtabellen sind intern in der Validierungs-Suite.
// Wenn die Redactions blockieren
Die Punkte oben beschreiben, was auf dieser Seite nicht steht. Was in einem Scoping-Gespräch diskutierbar ist, geht weiter:
- —Namentliche Version dieses Engagements, unter NDA.
- —Konkrete Scoring-Gewichte, die Betreiber-Bias-Testmatrix und das Defect-Log vollständig.
- —Ob eine ähnliche Architektur zu einem Ranking-, Routing- oder Empfehlungssystem in eurem Umfeld passt.
Stack & Artefakte
Die konkrete Oberfläche.
// Darstellung
- Astro
- Tailwind CSS
- Static Output
- Gefilterte Liste · Detail · Compare (bis 4) · 4-Schritt-Bedarfsmatch
// Datenschicht
- Markdown mit YAML-Frontmatter
- JSON-Export unter publiziertem Schema
- Kontrolliertes Vokabular
- Konfidenz-Taxonomie
// Scoring & Check
- TypeScript-Scoring-Modul
- JS-Validierungs-Suite
- Python-Frontmatter- + Export-Integrity-Validatoren
// Governance
- Nummeriertes Defect-Log
- Betreiber-Bias-Test
- Evidenz-vor-Eigeninteresse-Regel
- Ausschluss-statt-Abwertung-Regel
Was eine stärkere Version dieses Cases bräuchte
Fünf Fakten, die in dieser Darstellung nicht enthalten sind.
Klar benannt, damit der Leser den Unterschied erkennt zwischen dem, was hier beansprucht wird, und dem, was nicht.
- Pre/Post-Kennzahl zum Betreiber-Ranking über die Kaufprofil-Matrix (Release 1 → heute).
- Eine publizierbare Nutzungszahl (einzigartige Kaufanfragen; Wiederkehr-Rate), ohne Triangulation dem Portal zuordenbar.
- Outcome-Signal von Betreiber-Seite: hat das Portal messbar Inbound-Lead-Qualität verändert oder einen Sales-Zyklus verkürzt?
- Freigabe der Scoring-Suite durch einen zweiten, unabhängigen Reviewer — aktuell läuft die Suite beim Autor.
- Eine schriftliche Bestätigung des Kunden, dass die Redaction hier vollständig und korrekt ist — aktuell aus dem Engagement-Kontext abgeleitet.
Nächster Schritt
Ein ähnliches Glaubwürdigkeitsproblem in eurem System?
Betreiber-Bias, Quellen-Konfidenz-Taxonomie und Ausschluss-statt-Abwertung sind nicht branchenspezifisch. Sitzt euer Ranking-, Routing- oder Empfehlungssystem in einem strukturellen Konflikt — selbstgelistete Marktplätze, intern gescorte Workflows, KI-gestützte Entscheidungen mit einem verantwortlichen Inhaber — gelten die gleichen architektonischen Schritte.