Reporting

KI-Antworten sind nicht deterministisch — eine Zahl zur KI-Sichtbarkeit ist deshalb eine Stichprobe, kein absoluter Wert. Damit das ehrlich bleibt, zeigen die KPI-Karten zur KI-Sichtbarkeit — in der App genauso wie in Berichten und geteilten Links —, wie belastbar jeder Wert ist. Unter der Kennzahl steht „Basierend auf n = N Durchläufen“, wobei N die Zahl der dahinterliegenden Scan-Durchläufe ist (Prompts × Modelle × Wiederholungen im Zeitraum). Bei der Sichtbarkeit in Prozent zeigt die Karte zusätzlich eine Fehlermarge als „± X %“. Wir berechnen sie so, dass sie wirklich etwas aussagt und nicht bloß beruhigt: Sie ist randsicher (sie unterstellt nie eine unmögliche Sichtbarkeit unter 0 % oder über 100 %) und sie wird breiter, wenn deine KI-Engines untereinander uneinig sind oder die Stichprobe dünn ist — eine Rate aus vielen übereinstimmenden Durchläufen zeigt also ein enges ±, eine wackelige ein weites. Deshalb können zwei Marken denselben Prozentwert tragen und trotzdem sehr unterschiedliche Spannen haben; lies die Zahl und ihr ± immer zusammen. Bei Veränderungen über die Zeit gehen wir noch einen Schritt weiter. Wenn sich die Sichtbarkeit gegenüber der Vorperiode bewegt, vergleichen wir die Veränderung mit der kombinierten Fehlermarge beider Zeiträume. Erst eine Bewegung von mindestens dem Doppelten dieser Marge liegt klar über der Fehlermarge; alles darunter nicht, und es wird auf den KPI-Karten neben dem Delta als „im Unsicherheitsbereich“ gekennzeichnet und steht auf der Startseite, in der Wettbewerbstabelle und unter „Größte Veränderungen“ der Übersicht und in einem Bericht an den Veränderungen der Markentabelle (Brand), in der Spalte Δ Sichtbarkeit der Prompt-Tabelle und in den Tabellen Brand × Tag, Tag × Month, Brand × Month und Tag grau mit einem „~“ vor der Veränderung. Es ist überall dieselbe Regel mit derselben Marge (dem „± X %“ der Hauptkennzahl), eine Bewegung liest sich also nie an einer Stelle als Gewinn und an einer anderen als „~“. KI-Zusammenfassungen folgen derselben Regel: Crunch hat die Anweisung, eine solche Veränderung als unverändert zu beschreiben, nie als Anstieg oder Rückgang. Eine Anzahl wie die Erwähnungen hängt außerdem davon ab, wie viele Antworten gesammelt wurden; neben einem Vergleich nennt ihre Karte deshalb die Antworten beider Zeiträume („Basierend auf 1.426 Durchläufen · 2.940 im Vergleichszeitraum“). Das ist ein ehrliches Signal, dass es gut Rauschen sein kann und keine echte Verschiebung, damit ein kleiner Ausschlag (etwa ein Rückgang um drei Nennungen bei stark schwankenden Zitaten) nicht als Trend überinterpretiert wird. Ein kleiner farbiger Punkt neben „Basierend auf N Durchläufen“ fasst zusammen, wie verlässlich der Wert insgesamt ist — grün für hoch, bernsteinfarben für mittel, grau für niedrig — und verbindet dabei die Stichprobengröße mit der Breite des ±. Dieser Hinweis erscheint nur bei Kennzahlen zur KI-Sichtbarkeit, wo überhaupt eine Stichprobe im Spiel ist — Zahlen aus Werbeplattformen und Analytics kommen direkt aus der Quelle und werden nicht gesampelt. Es ist dasselbe Prinzip wie beim kostenlosen KI-Sichtbarkeits-Check: Stichprobengröße zeigen und nie mehr behaupten, als eine einzelne Zahl hergibt. Dieselbe Ehrlichkeit gilt, während ein Scan läuft. Schlagen einzelne Checks fehl — ein Provider-Ausfall, ein Rate-Limit —, versucht der Scan sie eine begrenzte Zahl von Malen erneut, schließt dann ohne sie ab und zeigt direkt in der Scan-Statusleiste, wie viele fehlgeschlagen sind. Ein fehlgeschlagener Check wird nie endlos still wiederholt und nie als Durchlauf gezählt — N enthält also immer nur Checks, die wirklich stattgefunden haben. Nach dem Scan zeigt der Tab Prompts genau, bei welchen Prompts Checks fehlgeschlagen sind — ein bernsteinfarbenes Badge am Prompt nennt die Engine und die Original-Fehlermeldung des Anbieters. Eine kleinere Stichprobe ist damit immer erklärbar, nie mysteriös. Nur vollständige Antworten zählen. Eine Engine meldet, warum sie aufgehört hat zu schreiben: Sie war fertig, sie hat die Längengrenze des Scans erreicht, ihrer Websuche sind die Runden ausgegangen, oder sie hat die Antwort verweigert. Antworten von ChatGPT, Gemini, Claude, Grok, Perplexity, DeepSeek und Meta AI werden nur gespeichert, wenn sie vollständig sind. Eine Antwort, die leer oder abgeschnitten ankommt, ist keine Messung (eine Marke, die nach dem Schnitt genannt wird, wäre unsichtbar), also zählt sie weder als Erwähnung noch als Fehlanzeige: Der Check schlägt mit Grund fehl, ein späterer Durchgang des Scans kann erneut fragen, und eine Engine, die weiter so antwortet, wird für den Rest des Scans gestoppt, mit dem Grund in der Scan-Leiste. Eine Antwort, die die Engine verweigert hat, wird als ihre Antwort gespeichert, denn genau das bekommt ein echter Nutzer; eine, die ihr Sicherheitsfilter mittendrin abgebrochen hat, ist ein Bruchstück und wird nicht gespeichert. Ein Fehler auf Seiten des Anbieters, der innerhalb einer Antwort gemeldet wird, ist vorübergehend und wird erneut versucht. Google AI Overviews, AI Mode und Microsoft Copilot funktionieren wie bisher: Ein leeres Ergebnis heißt dort, dass keine KI-Antwort angezeigt wurde. N ist die Zahl der Antworten, die zählen. Die Grenzen lassen Platz für die längsten echten Antworten: 8.192 Tokens für Claude und Gemini und 8.000 für ChatGPT, Meta AI und Grok, und Gemini denkt auf seiner niedrigen Stufe nach, weil sein Nachdenken auf dieselbe Grenze angerechnet wird. Markennamen werden aus bis zu 40.960 Zeichen einer Antwort gelesen. Antworten, die gespeichert wurden, bevor es diese Prüfung gab (Oktober 2026), wurden so nicht geprüft. Bis dahin waren Antworten von Claude auf 1.024 Tokens begrenzt, die meisten endeten deshalb vor dem Schluss, und manche kamen leer an, und Antworten von Gemini endeten oft nach wenigen hundert Zeichen; Zahlen zu Claude und Gemini von vor der Änderung fallen deshalb zu niedrig aus. Ein Projekt mit Antworten von davor bekommt in seiner Timeline einen Hinweis, sobald seine erste vollständige Antwort gespeichert ist, und Warnungen zu Rückgängen und Überholungen, Signale und Kunden-Digests lassen diese Engine aus jedem Vergleich über diesen Hinweis hinweg heraus (bleibt keine Engine übrig, melden sie nichts). Im MCP-Connector zeigt get_ai_answer, warum jede gespeicherte Antwort endete (stopReason). Von Google verlinkte Namen in AI Overviews. SerpAPI, über das wir Google AI Overviews, AI Mode und Microsoft Copilot auslesen, liefert manchmal einen Namen, den Google verlinkt hat, ohne seinen Text: Die Adresse des Links kommt zurück, der Name nicht. Ein Listenpunkt lautet dann „: Eine der führenden Full-Service-Agenturen …“, ohne Namen vor dem Doppelpunkt. Seit dem 11. Oktober 2026 behält ein Scan diese Links mit der Antwort. Beginnt ein Listenpunkt oder Absatz ohne seinen Namen (mit Doppelpunkt, Komma oder Gedankenstrich, oder leer) und ist sein erster Link ein solcher Link, steht die Domain des Links in eckigen Klammern an der Stelle des Namens, etwa „[example.com]: Eine der führenden …“. So ist sichtbar, dass dort ein verlinkter Name stand; den Anzeigenamen der Marke raten wir nicht. Dieser Link, und nur dieser, zählt als Erwähnung, wenn seine Domain die eigene Domain des Kunden oder eines getrackten Wettbewerbers ist: die Website des Kunden, eine als „Owned“ markierte Domain, die Domain des GEO-Audits oder ein als Domain geschriebener Alias, oder eine Wettbewerber-Domain aus den Einstellungen des KI-Sichtbarkeits-Projekts. Eine Subdomain oder eine geteilte Plattform (facebook.com, g2.com, amazon.de und ähnliche) steht für keine Marke. Eine solche Erwähnung zählt nur für Sichtbarkeit und Share of Voice, ohne Position und Sentiment, und nur, wenn die Antwort die Marke nicht ohnehin nennt. Die Ansicht Antworten und get_ai_answer im MCP-Connector kennzeichnen sie: ein verlinkter Name, den SerpAPI ohne seinen Text geliefert hat; gezählt über die Domain des Links. Ein Link ohne Text mitten im Satz, Links mit Text und die Quellen unter einer Antwort zählen nie als Erwähnung. Antworten, die vor dem 11. Oktober 2026 gespeichert wurden, wurden so nicht gelesen und können eine von Google verlinkte Marke verfehlen; sie bleiben, wie sie sind. Ein Projekt mit früheren Antworten bekommt je Engine eine interne Notiz in seiner Timeline, am Tag, an dem seine erste Antwort so gelesen wird, und Alerts vergleichen nicht über diesen Tag hinweg. Eine Tabellenzeile, deren Namen SerpAPI samt Link weggelassen hat, lässt sich nicht wiederherstellen. Ein Scan pro Tag zählt. Wird ein Prompt am selben Tag mehr als einmal gescannt — ein manueller Neustart, eine Wiederholung nach einer Einstellungsänderung — ersetzt der spätere Scan den früheren für diese Engine und diesen Tag. Er kommt nie hinzu. Beide zusammenzurechnen würde die Stichprobe ohne neue Evidenz verdoppeln und diesen Tag zu einer größeren Grundgesamtheit machen als jeden anderen. Dieselbe Regel gilt überall, wo die Durchläufe gelesen werden: Kopf-Kennzahlen, Themen- und Quellenkarten, Berichts-Widgets, API und MCP-Connector messen dieselben Durchläufe, ihre Zahlen stimmen also überein. „Letzte 30 Tage“ heißt 30 ganze Tage. Das Zeitfenster wird in Kalendertagen (UTC) gezählt und endet immer mit dem heutigen Tag: „letzte 30 Tage“ am 23. September ist der 25. August bis 23. September, einschließlich — nie 31 Tage und nie ein halber Tag an einem der Enden. Das ist wichtig, weil ein Fenster als „jetzt minus 30 × 24 Stunden“ den ältesten Tag mittendrin abschneiden würde und je nach Uhrzeit des Seitenaufrufs einen anderen Zeitraum abdecken würde. Alle Oberflächen nutzen diese eine Definition: die Kennzahlen oben, die Diagramme, die Wettbewerbstabelle, die Themen- und Quellenkarten, die Tabellen je Engine, Report-Widgets, die REST-API und der MCP-Connector. Eine Stichprobengröße auf einer Karte beschreibt damit dieselbe Grundgesamtheit wie die daneben. Es sind UTC-Tage, weil Scans nach UTC-Tag gespeichert werden. In einem Bericht kommen die Daten selbst aus dem Zeitraum des Berichts, der der Zeitzone deines Workspaces folgt; die KI-Sichtbarkeit zählt dann die Scans dieser Daten nach ihrem UTC-Tag.