Framework zur Messung der Sichtbarkeit in der KI-Suche für technische Teams

Als ich Beetroots Sichtbarkeit in KI-Suchergebnissen gemessen habe, über 359 Antworten hinweg, kam dasselbe Produkt je nach Oberfläche und Prompt auf 0, 9, 13 oder 100 Prozent, und einer von acht Prompts trug jede einzelne nicht markenbezogene Erwähnung. In diesem Text ging es darum, eine Messung richtig durchzuführen. Hier geht es darum, was danach passiert: wenn jemand das Panel einen Monat später erneut laufen lässt und die beiden Zahlen nebeneinanderlegt.

Meine These ist eng gefasst und, glaube ich, für viele Dashboards unbequem: Die meisten berichteten Veränderungen der Sichtbarkeit in der KI-Suche sind Artefakte der Art, wie gemessen wurde. Das Prompt-Panel hat sich geändert, die Stichprobe war zu klein, um den Unterschied zu sehen, oder das Modell darunter wurde ausgetauscht, und niemand hat es geloggt. Eine Sichtbarkeitszahl, die ohne ihre Panel-Version, ihre Zahl der Samples und ihren Modell-Eintrag ausgeliefert wird, kann niemand überprüfen, auch nicht das Team, das sie erzeugt hat.

Was folgt, ist ein Design, um diese Messung als wiederkehrendes Programm zu fahren, für die Leute, die die Pipeline bauen und die Trendlinie verteidigen müssen: Engineering für die Datensammlung, Analytics für Definitionen und Statistik. Die Definitionen von Erwähnung, Zitat und Aufnahme in die Antwort sowie der Workflow für einen einzelnen Tag stehen im Begleittext. Hier tauchen sie nur dort wieder auf, wo ihre Verfolgung über die Zeit eine zusätzliche Anforderung mit sich bringt. Das Framework hat vier Objekte, Queries, Erwähnungen, Zitate und Wettbewerber, dazu die Sampling-Regeln, die unter allen vieren liegen. Die Grenzen kommen gegen Ende, und das ist der Teil, den ich zuerst lesen würde, wenn mir jemand einen so gebauten Bericht in die Hand drückt.

Warum kannst du dafür nicht dein SEO-Dashboard weiterverwenden?

Weil sich die Beobachtungseinheit geändert hat. Auch eine Suchergebnisseite variiert mit Personalisierung und Standort, aber sie ist stabil genug, dass ein Check pro Query und Tag eine vertretbare Messung ist, und ein Rank Tracker kann eine Position speichern. Die Antwort eines Assistenten wird jedes Mal neu generiert. Formulierung, Markenliste und zitierte Quellen können sich zwischen zwei aufeinanderfolgenden Läufen desselben Prompts ändern, und wenn der Assistent zuerst im Web sucht, bringt der Retrieval-Schritt seine eigene Varianz mit.

Aus der Position wird also eine Rate. Aus einem Check werden viele Läufe. Aus „Wir ranken auf Platz drei“ wird „Wir tauchten in 7 von 20 Läufen auf, mit einem 95%-Intervall von grob 18 bis 57 Prozent.“ Das will niemand auf einer Folie haben, und es ist die einzige Fassung der Zahl, die einen zweiten Lauf übersteht.

Der andere Unterschied ist der Klick. Auch im SEO-Reporting gibt es Impressionen ohne Sitzungen, aber die meisten Ergebnisse landen dort irgendwann in der Analytics. Ein großer Teil der Antworten von Assistenten endet damit, dass der Nutzer zufrieden ist und weg, also die Dynamik, die ich für Verlage in The Quality Paradox nachgezeichnet habe. Für die Messung heißt das: Du musst die Antwort selbst beobachten, statt auf Traffic zu warten, den sie vielleicht nie schickt.

Wie viele Läufe brauchst du wirklich?

Mehr, als die Intuition sagt. Und die entscheidende Frage ist, ob du eine Veränderung erkennen kannst, und das ist schwerer, als ein einzelnes Intervall zu bekommen. Alle Intervalle hier sind Wilson-Intervalle für einen binomialen Anteil. Für eine einzelne Rate um 50 Prozent ergeben 10 Läufe grob 24 bis 76 Prozent, 30 Läufe 33 bis 67 und 100 Läufe 40 bis 60.

Ein Bericht vergleicht aber zwei Zeiträume, und die Differenz zweier Raten rauscht stärker als jede der beiden Raten. Für einen zweiseitigen Test auf dem 5-Prozent-Niveau mit 80 Prozent Teststärke, bei einer Ausgangsrate um 50 Prozent, ist die kleinste Veränderung, die du zuverlässig erkennen kannst, grob:

Diese Zahlen setzen unabhängige Läufe voraus, und Läufe sind nicht vollständig unabhängig. Läufe desselben Prompts am selben Tag teilen sich einen Retrieval-Index, Caches und den Zustand, in dem das Modell in dieser Woche gerade ist. Wer jeden Prompt und jeden Lauf in eine große Binomialverteilung zusammenwirft, bekommt Intervalle, die präzise aussehen und zu eng sind. Drei Gewohnheiten helfen dabei: Verteil die Läufe innerhalb eines Zeitraums über mehrere Tage, behandle den Prompt als Einheit, wenn du die Unsicherheit auf Panel-Ebene berechnest (ein Bootstrap, der Prompts neu zieht und nicht Läufe, ist die einfache Variante), und vergleich Zeiträume auf denselben Prompts als gepaarte Daten.

Das Panel aus dem Begleittext zeigt, wie schnell das zuschlägt. Beetroots Erwähnungsrate auf der Oberfläche mit Websuche lag bei 7 von 80 nicht markenbezogenen Antworten, etwa 9 Prozent. Bei dieser Ausgangsrate können 80 Läufe pro Zeitraum zuverlässig eine Veränderung von grob 13 Punkten in beide Richtungen erkennen. Eine Verdopplung auf 18 Prozent im nächsten Monat würde höchstwahrscheinlich nicht als signifikant auftauchen, eine Halbierung auf 4 Prozent ebenso wenig. Die einzelne Momentaufnahme war aussagekräftig. Ein Vergleich von Monat zu Monat in derselben Größe würde vor allem Rauschen messen.

Dann rechne das Budget durch, bevor das Design festgelegt ist. Ein Panel mit 100 Prompts, je 20 Läufen, auf 3 Oberflächen sind 6.000 gesammelte Antworten pro Zeitraum, noch vor jeder Bewertung der Faktentreue. In dieser Größe siehst du Verschiebungen von einigen Punkten auf Panel-Ebene, aber kein einzelner Prompt hat genug Läufe, um eine Bewegung von 10 Punkten zu erkennen. Dieser Zielkonflikt ist die eigentliche Designentscheidung: weniger Prompts mit mehr Läufen, weniger Oberflächen, oder akzeptieren, dass Zahlen pro Prompt nur der Diagnose dienen. Schreib die Antwort vor dem ersten Bericht auf, als „Eine Veränderung kleiner als X ist bei unseren Stichprobengrößen Rauschen.“

Noch eine Falle. Bei 100 Prompts, die auf dem 5-Prozent-Niveau getestet werden, zeigen allein durch Zufall in jedem Zeitraum etwa fünf eine „signifikante“ Bewegung, und genau diese fünf landen dann im Foliensatz. Bewegungen pro Prompt sind dazu da, Stellen zum Hinschauen zu finden, nicht zum Berichten.

Ebene 1: Welche Queries solltest du messen?

Ein festes, versioniertes Panel von Prompts, nach Intent geschichtet, bei dem jeder Prompt festhält, wie er entstanden ist. Das Panel ist der Nenner jeder Metrik, die folgt, also ist es die folgenreichste Entscheidung im Framework und die, die sich am leichtesten verzerren lässt.

Bau drei Schichten und berichte sie getrennt:

• Nicht markenbezogene Discovery-Prompts. Fang bei echten Suchanfragen an (Search Console, Keyword-Tools) und bewahr die ursprüngliche Anfrage neben der Assistenten-Fassung auf, die du daraus ableitest. Umformulieren verändert den Intent leicht: „best open source clipboard manager for Windows“ und „a free clipboard manager that keeps images“ sind unterschiedliche Anliegen, und das zweite lässt die Open-Source-Bedingung stillschweigend fallen. Kennzeichne jeden abgeleiteten Prompt als synthetisch und speichere die Umformung.
• Vergleichs-Prompts. „Alternatives to X“, „X vs Y for a team of 20“. Verteil sie ausgewogen über die Wettbewerber, damit deine Marke nicht in den meisten davon der genannte Anker ist.
• Entitäts-Prompts. „What is [product]?“, „Who makes [product]?“. Sie nennen die Marke in der Frage, eine Erwähnung ist also fast garantiert. Sie messen, ob die Beschreibung stimmt, nicht ob du empfohlen wirst, und sie dürfen nie in einen Discovery-Score eingemischt werden.

Behandle das Panel wie Code: eine ID, eine Version, ein Einfrieren für jeden Messzeitraum. Neue oder ausgemusterte Prompts erhöhen die Version, und Zahlen über Versionen hinweg werden erst verglichen, nachdem beide Panels neu berechnet wurden. Ein Score, der gestiegen ist, weil jemand fünf markenbezogene Prompts ergänzt hat, sieht genau aus wie ein Erfolg. Der Zusammensetzungseffekt braucht nicht einmal markenbezogene Prompts. Im Lauf aus dem Begleittext hat ein Prompt zu KI-Funktionen 17 von Beetroots 17 nicht markenbezogenen Erwähnungen auf den beiden Oberflächen mit Suche geliefert. Ein zweiter Prompt dieser Art hätte die Headline-Rate fast verdoppelt, ohne dass sich in der Welt etwas geändert hätte.

Ebene 2: Was zählt als Erwähnung?

Deine Entität, im generierten Antworttext genannt, erkannt von einem Matcher, den du auditieren und validieren kannst. Rohe Antworten kürzen Namen ab, schreiben sie falsch, beschreiben „das in Rust geschriebene“, ohne es zu nennen, oder hängen deinen Namen an die Funktion eines Wettbewerbers.

Erfasse pro Antwort:

• erwähnt: genannt über exakten Match, einen bekannten Alias oder einen geprüften Fuzzy-Match, aus einem versionierten Alias-Wörterbuch, das neben dem Panel liegt;
• Haltung: neutrale Erwähnung, Empfehlung oder ausdrückliche Ablehnung. „X is an option, but most users prefer Y“ ist eine Erwähnung und eine Niederlage;
• Position: der Rang in der Liste der Antwort, wenn die Antwort eine Liste ist;
• Faktentreue: ob stimmt, was die Antwort über dich sagt, bewertet gegen ein datiertes Faktenblatt (Lizenz, Plattformen, Preismodell, Kernfunktionen), mit „unsicher“ als zulässigem Ergebnis. Eine Antwort, die dein Open-Source-Tool proprietär nennt, ist eine Belastung, die ein naives Dashboard als Erfolg zählt.

Validier den Matcher gegen eine von Menschen gelabelte Stichprobe, die auch Antworten enthält, die der Matcher als ohne Erwähnung markiert hat, denn wer nur die erkannten Erwähnungen prüft, findet die verpassten nie. Wenn ein Modell bewertet, miss seine Übereinstimmung mit den menschlichen Labels und versioniere Bewerter und Bewertungsschema.

Der Lauf aus dem Begleittext hat beide Fehlerarten gefunden, die ein Matcher überstehen muss: eine Antwort, die Beetroot in eine Sammelzeile „similar indie apps“ packte, was eine Regex als volle Erwähnung wertet, und ein Modell ohne Webzugriff, das selbstsicher die falsche Lizenz nannte und auf fremde Repositories verlinkte. Über die Zeit werden auch Matcher und Bewerter zu versionierten Inputs. Änderst du einen der beiden, müssen alte Antworten neu bewertet werden, bevor die Trendlinie etwas bedeutet.

Die Kernmetrik ist die Erwähnungsrate: der Anteil der abgeschlossenen Läufe eines Prompts, die dich erwähnen. Aggregier über das Panel mit festen Gewichten pro Prompt (gleiche Gewichte sind ein vernünftiger Standard), nicht durch Zusammenwerfen der Läufe, sonst gewichtet eine Oberfläche, die diesen Monat öfter in ein Timeout lief, deinen Score still um.

Ebene 3: Was zählt als Zitat?

Ein Link oder eine Quellenangabe zu einer deiner URLs, die an der Antwort hängt. Das ist ein eigenes Objekt neben der Erwähnung, und die beiden können in beide Richtungen auseinanderlaufen.

Du kannst erwähnt werden, ohne zitiert zu werden, und du kannst zitiert werden, ohne erwähnt zu werden: deine Vergleichsseite oder Dokumentation als Quelle für eine Antwort, die jemand anderen empfiehlt. Den ersten Fall liest man leicht zu viel hinein. Eine Erwähnung ohne Zitat kann aus den Trainingsdaten des Modells stammen, aber auch aus abgerufenen Seiten Dritter, die die Oberfläche nicht angezeigt hat. Retrieval-Quellen und angezeigte Zitate sind nicht dieselbe Menge. OpenAIs eigene Dokumentation zur Websuche unterscheidet sie. Behandle das Muster als Hypothese, die du prüfst, nicht als Diagnose.

Die Zitierrate ist außerdem die Metrik, die am stärksten von der Technik rundherum abhängt. Im Lauf aus dem Begleittext hat das Mitzählen von Inline-Markdown-Links neben strukturierten Annotationen die Rate bei denselben Antworten um das 2,5-Fache verschoben, und die Zitate einer Oberfläche kamen beim Collector gar nicht erst an. Für eine Trendlinie heißt das: Die Parsing-Regel hat eine Version wie alles andere, und eine stille Änderung am Parser ist von einer echten Verschiebung nicht zu unterscheiden.

Erfasse jede zitierte URL roh und normalisiert (Weiterleitungen aufgelöst, Tracking-Parameter entfernt), ihre Eigentümerklasse (deine, die eines Wettbewerbers, die eines Dritten) aus einer versionierten Eigentümerliste und ob das Zitat inline steht oder in einem getrennten Quellenbereich. Bewahr strukturierte API-Responses oder gerenderte Belege auf, wo du kannst, denn eine flache URL-Liste verliert, an welcher Aussage ein Zitat hing. Aus diesem Datensatz:

• Zitierrate: Anteil der abgeschlossenen Läufe, die mindestens eine deiner URLs zitieren;
• zitierte Seiten: welche deiner URLs zitiert werden, der einzige Teil dieses Frameworks, der sich direkt auf Seiten abbilden lässt, die dein Team ändern kann;
• Zitatanteil Dritter: der Anteil der beobachteten Zitate, die auf Bewertungsseiten, Foren und Verzeichnisse zeigen statt auf dich oder einen verfolgten Wettbewerber. Er sagt dir, wer die angezeigten Quellen sind, nicht wie viel jede davon zum Text beigetragen hat.

Server-Logs liefern eine unabhängige Sicht, mit zwei Klassen von Bots, die du auseinanderhalten musst. Such-Crawler (OAI-SearchBot, PerplexityBot, Claude-SearchBot) indexieren Seiten für später. Von Nutzern ausgelöste Fetcher (ChatGPT-User, Perplexity-User, Claude-User) rufen eine Seite ab, weil gerade in diesem Moment jemand etwas gefragt hat. Die zweite Klasse ist näher an einem Beleg für echte Nutzung, keine der beiden beweist ein Zitat. Googles AI Overviews und AI Mode greifen auf Googles regulären Index zurück, die Logs zeigen also nichts, was spezifisch für sie wäre. Prüf die Identität eines Crawlers gegen veröffentlichte IP-Bereiche oder Reverse DNS, bevor du einem User-Agent-String traust.

Ebene 4: Wie misst du Wettbewerber fair?

Dasselbe Panel, dieselben Läufe, derselbe Matcher, und Share of Voice statt deiner eigenen Rate für sich allein. Deine Erwähnungsrate ist auch allein aussagekräftig, aber neben einem Kategorieführer bei 35 Prozent liest sie sich ganz anders als neben einem bei 90.

Definier Share of Voice über Präsenz: In jeder Antwort zählt jede verfolgte Marke einmal, wenn sie vorkommt, egal wie oft sie genannt wird. Der Share of Voice für einen Prompt ist deine Präsenzzahl geteilt durch die gesamte Präsenzzahl aller verfolgten Marken. Wenn keine verfolgte Marke vorkommt, ist der Wert undefiniert, nicht null. Berichte diese Antworten in zwei getrennten Töpfen: Antworten, die überhaupt keine Marke nennen, und Antworten, die nur Marken nennen, die du nicht verfolgst. Wächst der zweite Topf, ist deine Wettbewerberliste vermutlich veraltet.

Berechne ihn pro Intent, bevor du irgendeine Kategoriesumme bildest. Im Lauf aus dem Begleittext dominierten Ditto und CopyQ die meisten Prompts, während beim Prompt zu KI-Funktionen eine Oberfläche in allen 10 Antworten Microsofts PowerToys Advanced Paste nannte, jedes Mal mit Beetroot auf Platz zwei, und weder Ditto noch CopyQ überhaupt auftauchten. Ein Anteil über die ganze Kategorie würde zwei verschiedene Wettbewerbslagen zu einer mitteln, die es nirgends gibt. Auch Zitate gehören hierher: Bei Vergleichs-Prompts lohnt es sich zu verfolgen, wessen Seite zitiert wird, wenn die Antwort die Wahl einordnet.

Leg die Wettbewerberliste zusammen mit dem Panel fest. Ein starker Wettbewerber, der mitten im Zeitraum dazukommt, senkt den Anteil aller und sieht aus wie ein Rückgang.

Was gehört in den Datensatz eines Laufs?

Jeder Lauf, auch die fehlgeschlagenen. Der Begleittext listet den Mindestdatensatz für eine einzelne Messung auf. Ein wiederkehrendes Programm braucht mehr, weil ein Trend Änderungen am Modell, am Collector und an den Definitionen überstehen muss. Das Schema trennt, was du einstellst, von dem, was du beobachtest, denn auf den meisten Consumer-Oberflächen kannst du weder das Modell festlegen noch Retrieval erzwingen:

# set by the collector
run_id, panel_version, prompt_id, surface, requested_mode,
country, language, account_state, fresh_conversation, timestamp
 
# observed in the response
status (completed | refused | timeout | parse_error | no_ai_feature),
retry_of, model_reported, search_triggered, issued_queries[],
answer_text, citations[] (raw_url, normalized_url, placement)
 
# applied later, re-runnable
matcher_version, grader_version, ownership_list_version

status hält den Nenner ehrlich. Ein Timeout ist keine Antwort ohne Erwähnung, und bei Google ist „für diese Query wurde keine AI Overview angezeigt“ ein eigenes Ergebnis: Berichte die Sichtbarkeit sowohl über alle infrage kommenden Queries als auch bedingt darauf, dass die Funktion erscheint. Veröffentliche die Abschlussraten neben jeder Metrik.

model_reported ist oft leer. APIs geben Modell-IDs heraus, Consumer-Produkte meistens nicht, und Anbieter wechseln Modelle hinter einem unveränderten Produktnamen. Auf solchen Oberflächen lässt sich ein Modellwechsel nur erschließen, aus Release Notes oder aus einer abrupten Verschiebung über viele Prompts gleichzeitig. Erfasse, was du kannst, markier den Rest als unbekannt und annotiere die Zeitreihe mit jedem bekannten Release des Anbieters. Dasselbe Argument habe ich für Agenten-Pipelines in Ein Modell ist eine Abhängigkeit, die nicht stillhält gemacht: Du kannst die Drift des Anbieters nicht von deinen eigenen Änderungen trennen, wenn du nicht geloggt hast, wogegen du gemessen hast.

API-Ergebnisse und Consumer-Oberflächen sind verschiedene Oberflächen, keine Stellvertreter füreinander. Halte ihre Zeitreihen getrennt. Wenn du über Browser-Automatisierung von Consumer-Oberflächen sammelst, lies zuerst die Nutzungsbedingungen des Produkts. Automatisierter Zugriff auf eine Consumer-App kann gegen sie verstoßen und den Account gefährden.

Was können dir diese Zahlen nicht sagen?

Schreib das in den Haupttext jedes so gebauten Berichts. Eine Grenze in einer Fußnote ist eine Grenze, die niemand liest.

Es ist nicht die Gesamtheit der Antworten. Das Panel ist eine gestaltete Stichprobe. Echte Nutzer formulieren auf ihre eigene Art, bringen Chatverlauf und Gedächtnis mit und sehen personalisierte Ergebnisse. Das Panel misst eine kontrollierte Bedingung. Genau das macht es über die Zeit vergleichbar, und genau deshalb ist es keine Traffic-Schätzung. Mehr Läufe verringern das Stichprobenrauschen, gegen ein verzerrtes Panel helfen sie nicht.

Tools von Anbietern sind auch Messungen. Kommerzielle Tracker unterscheiden sich: Bei manchen definierst du deine eigenen Prompts, andere berichten über ihre eigenen Prompt-Datenbanken und schätzen die Reichweite, indem sie Prompts mit Suchvolumen gewichten, angepasst an die Nutzung der jeweiligen Plattform. Halte fest, welches Tool, welcher Modus und welche Methodik-Version, und beschrifte seine Zeitreihe klar. Seine Zahlen sind nicht mit deinen austauschbar, auch wenn die Metrik gleich heißt.

Referrals sind beobachtet, keine Wirkung. Die ChatGPT-Suche hängt utm_source=chatgpt.com an Referral-Links (OpenAI Publisher-FAQ), und manche Assistenten geben einen Referrer mit. Die Search Console hat seit diesem Sommer einen eigenen Leistungsbericht für generative KI, aber er deckt Impressionen für AI Overviews und AI Mode zusammen ab, und Klicks landen weiterhin in den normalen Web-Summen. Nenn das „beobachtete zurechenbare Sitzungen“. Sie sind weder eine Untergrenze für den geschäftlichen Effekt noch eine Conversion-Rate für Erwähnungen.

Ein Trend ist keine Ursache. Ein stabiles Panel zeigt, dass sich die Sichtbarkeit bewegt hat. Es zeigt nicht, dass das Schema-Markup oder die neue Vergleichsseite sie bewegt hat. Eine bestimmte Änderung zu testen, braucht ein eigenes Design: eine behandelte Menge von Seiten oder Prompts, eine vergleichbare unbehandelte Menge und ein Beobachtungsfenster, das vorher festgelegt ist.

Checkliste für die Umsetzung in Engineering- und Analytics-Teams

Der Text oben erklärt jeden Punkt. Diese Liste ist das, was existieren muss, und wem es gehört, bevor die erste Zahl das Team verlässt.

Engineering

• Prompt-Panel, Alias-Wörterbuch, Eigentümerliste und Faktenblatt in der Versionsverwaltung, jeweils mit einer Versions-ID.
• Ein Collector pro Oberfläche (API, wo es eine gibt, Browser-Automatisierung nur, wo die Nutzungsbedingungen es erlauben), der jeden Prompt N-mal pro Zeitraum laufen lässt, über mehrere Tage verteilt, aus festen Regionen und Account-Zuständen.
• Der vollständige Datensatz für jeden Versuch, einschließlich Fehlschlägen, rohem Antworttext und strukturierten Zitaten.
• Log-Parsing für Such-Crawler und von Nutzern ausgelöste Fetcher pro URL, mit Identitätsprüfung.
• Neuverarbeitung: Jede Änderung an Matcher, Bewerter oder Eigentümerliste lässt sich erneut gegen die gespeicherten Rohantworten laufen lassen.

Analytics

• Panel in drei Schichten gebaut (Discovery, Vergleich, Entität), jeder abgeleitete Prompt mit seiner Ausgangsanfrage verknüpft, pro Zeitraum eingefroren.
• Stichprobengröße anhand der Tabelle der erkennbaren Veränderungen und des Budgets für die Datensammlung gewählt, und die daraus folgende Rauschschwelle aufgeschrieben.
• Matcher und Bewerter gegen menschliche Labels validiert, einschließlich Negativfällen.
• Metriken pro Schicht und Oberfläche berichtet: Erwähnungsrate, Haltung, Faktentreue, Zitierrate, zitierte Seiten, Zitatanteil Dritter, Share of Voice, jeweils mit Abschlussrate, Zahl der Läufe und Intervall.
• Zeitreihe annotiert mit Panel-Versionen, bekannten Modell-Releases und deinen eigenen Website-Releases.
• Referral-Daten als beobachtete zurechenbare Sitzungen beschriftet, nie als Ergebnismetrik.

Gemeinsam

• Eine Seite, die jede Metrik in einfachen Worten definiert. Wenn die Zahlen angezweifelt werden, ist das die Seite, die du verteidigst.
• Ein vierteljährlicher Panel-Review: Prompts ausmustern, die niemand mehr stellt, neue Nachfrage aufnehmen, die Version erhöhen, den Vergleich neu berechnen.

Wo das hingehört

Ein Framework ist eine Methode, kein Befund. Die Messung mit einem einzelnen Panel ist der erste Datenpunkt. Die Befunde entstehen, wenn man so etwas wie dieses Framework lange genug laufen lässt, um zu sehen, welche der populären Empfehlungen, wie man „in KI-Antworten kommt“, standhalten, und die dann mit einem ordentlichen Interventionsdesign testet. Im Bereich Research liegt die Arbeit mit eigenen Daten auf dieser Website, jedes Stück mit Methode und Quellen direkt neben dem Ergebnis. Diesen Maßstab sollte auch eine Sichtbarkeitszahl erfüllen: Wenn niemand sonst prüfen kann, wie sie entstanden ist, ist sie eine Meinung mit Diagramm.