Das Standard-Assessment auf dieser Seite ist ein Cold Audit: es nutzt nur öffentlich beobachtbare Signale (Website-Crawl + Stichproben echter KI-Suchantworten) und schätzt echte Rankings, Klicks und Conversions nur directional. Diese Übersicht beschreibt, wie ein Audit zum Connected Audit wird, sobald der Kunde — die Firma, für die das Audit läuft — seine First-Party-Daten read-only anbindet: Google Search Console, GA4, Google Ads und Google Business Profile. Zwei klar getrennte Teile: Für den Kunden (Vertrauen & Datenschutz) und Intern (technische Durchführung).
Der Cold Audit kann nicht wissen, wofür eine Marke heute real rankt. GSC liefert genau das: echte Queries × Position × Klicks × CTR. Daraus entsteht das stärkste Connected-Signal überhaupt — die Lückenliste „rankt organisch, wird aber in KI-Antworten NICHT zitiert":
Das verbindet die OVI-Linse (organisch, gemessen aus GSC) direkt mit der AVI-Linse (agentisch) und macht aus geschätzten Lücken belegte Maßnahmen — etwas, das ein Cold Audit prinzipiell nicht leisten kann. Siehe Assessment-Engine §1b.
Ein Kunde stellt im Kern zwei Fragen: (1) „Muss ich überhaupt handeln?" (Handlungsnotwendigkeit / Diagnose) und (2) „Was zuerst — und was bringt es konkret?" (priorisierte Maßnahmen). Cold und Connected beantworten diese beiden Fragen ungleich gut — und genau dort sitzt der eigentliche Mehrwert der Datenanbindung.
| Die zwei Fragen des Kunden | Cold Audit (öffentliche Signale) | Connected Audit (+ First-Party-Daten) |
|---|---|---|
| ① Diagnose „Besteht eine KI-Sichtbarkeitslücke — muss ich handeln?" |
Belastbar. Zeigt directional zuverlässig, DASS die Marke in KI-Antworten kaum vorkommt. Reicht in den meisten Fällen für die Go/No-Go-Entscheidung. | Schärfer, aber selten entscheidungsändernd — bestätigt dieselbe Lücke mit echten Zahlen. Nutzen hier: gering bis mittel. |
| ② Maßnahmen „Was zuerst, und welcher Euro-Wert hängt dran?" |
Oberflächlich. Liefert eine plausible Liste von On-Site-/Content-Hebeln — aber ohne Priorisierung nach echtem Geschäftswert. Welche Lücke zuerst Umsatz bringt, bleibt geschätzt. | Hier liegt der Hebel. Priorisierung nach realen Queries × Klicks × Conversion-Wert (GSC/GA4) → aus „plausibel" werden belegte, gereihte Maßnahmen. Nutzen hier: hoch. |
Kernaussage: Das Cold Audit ist stark in der Diagnose, schwach in der Priorisierung. Der Grenznutzen der Anbindung steckt fast vollständig in den Maßnahmen — nicht im „Ob überhaupt". Das gilt aber nicht pauschal; wovon es abhängt, zeigt der Entscheidungsbaum unten.
Das Cold Audit ist der niedrigschwellige Erstbefund: schnell, günstig bis kostenlos, beantwortet Frage ① (Handlungsnotwendigkeit + grobe Richtung) belastbar. Sagt die Diagnose „ja, handeln", folgt das Connected Audit als kostenpflichtiger Schritt — es liefert die belegte, nach Geschäftswert priorisierte Roadmap, die ein Cold Audit prinzipiell nicht leisten kann. Der Erstbefund verkauft also nicht sich selbst, sondern die Notwendigkeit des nächsten Schritts.
Die Antwort hängt an drei Bedingungen. Je weiter rechts im Baum, desto klarer lohnt der Connected-Schritt:
Die drei Bedingungen: (1) organische Basis vorhanden? · (2) transaktionales Geschäft (Conversion-/Umsatz-Attribution lohnt)? · (3) Reifegrad/Wettbewerb (viele Hebel konkurrieren um dasselbe Budget)? — Treffen (2) oder (3) zu und (1) ist erfüllt, ist die Anbindung der Hebel; sonst trägt der Cold-Erstbefund die Entscheidung bereits.
Die Datenanbindung ist read-only, ephemer und jederzeit widerrufbar. Es werden keine Passwörter weitergegeben und keine Kundendaten dauerhaft gespeichert.
webmasters.readonly,
analytics.readonly). Keine Änderung an Konten/Properties möglich.Vorbehalt (ehrlich): GSC anonymisiert je nach Property einen Teil der Queries; GA4 unterzählt KI-Traffic ohne Custom-Setup. Wird im Report mit Confidence-Label ausgewiesen.
Aus einer Deep-Research-Recherche (Google-Primärdokumentation + Anbieter-Quellen, adversarial verifiziert) ergeben sich drei tragfähige Architektur-Varianten. Vergleich nach Auth/Datenschutz, Aufwand für den Kunden, Kosten, Datenfrische und Anbindung an die FastAPI/Python-Audit-App.
| Kriterium | ① Direct OAuth (selbst gebaut) | ② Windsor.ai ★ | ③ OneClick Onboard |
|---|---|---|---|
| Auth-Flow | Eigener OAuth-2.0-Webflow, least-privilege Read-Scopes | Connector + „Authorize via Link": Kunde autorisiert in ~2 Min in seinem eigenen Konto — Berater fasst nie Credentials an | Eine konsolidierte OAuth deckt alle 5 Google-Dienste in einem Flow |
| Datenschutz | ★★★ Daten direkt Kunde → eigene App, kein Dritt-Vendor | ★★ über Windsor; Credentials nie geteilt, jederzeit widerrufbar | ★★ über Vendor |
| Knackpunkt | 🔴 Sensible Scopes ⇒ Google-Verifizierung (bis 10 Tage); unverifizierte App = „unverified app"-Warnscreen + lebenslang 100-User-Cap | ✅ umgeht Verifizierung & 100-User-Falle komplett | ⚠️ unklar, ob rohe Tokens/API an eigene FastAPI durchgereicht werden (evtl. geschlossenes Agentur-Portal) |
| Aufwand Kunde | mittel–hoch (Warnscreen abklicken) | niedrig — 1 Link, ~2 Min | am niedrigsten — 1 Klick, alle Dienste |
| Kosten | Google-APIs gratis, aber Dev-/Compliance-Aufwand | Free 30 Tage → Basic 19 €/Mt (3 Q.) / Standard 99 €/Mt (7 Q.). ⚠️ Row-Kosten ~$20/1 Mio. Zeilen extra | Vendor-Preis (nicht belegt) |
| Datenfrische | Echtzeit möglich | täglich/stündlich — für Stichtags-Audit mehr als genug | k. A. |
| FastAPI-Anbindung | googleapiclient direkt, synchron |
2 Wege: (a) API-Key-URL + requests, (b) MCP (Claude/ChatGPT/Gemini) |
❓ offen |
Windsor.ai löst genau den Engpass, an dem Direct OAuth für eine kleine Beratung scheitert:
keine 10-Tage-Verifizierung, keine lebenslange 100-User-Deckelung, delegierte Auth ohne
Credential-Handling, niedrige Per-Prospect-Kosten und zwei native Anbindungen an die
Python/FastAPI-Pipeline (requests + MCP).
requests# ephemer: Rohdaten nur zur Laufzeit, nichts persistiert import requests url = f"https://connectors.windsor.ai/all" \ f"?api_key={KEY}&date_preset=last_28d" \ f"&fields=source,clicks,impressions,position,query" rows = requests.get(url, timeout=60).json()["data"] # → in OVI-Scorer (gemessen) statt directional
MCP-Server mcp.windsor.ai bzw. Repo windsor-ai/windsor_mcp
dockt direkt an LLM-Clients (Claude / ChatGPT / Gemini) an — passt zur bestehenden Subscription-CLI-/MCP-Architektur
der Engine. Die Kundendaten werden so dem Audit-Modell als Tool bereitgestellt, ohne ETL-Zwischenschicht.
Caveat live prüfen: Pricing-Tiers, Row-Caps und 100-User-/Verifizierungs-Regeln können sich ändern — vor Angebotskalkulation verifizieren.
Nicht jede Readiness-Dimension profitiert gleich von Kundendaten. Drei Achsen sind weitgehend crawl-deterministisch (Cold voll belastbar), fünf werden durch eine First-Party-Quelle erst wirklich scharf. Die Reihung folgt dem Grenznutzen der Anbindung: Wie weit ersetzt die Quelle eine geschätzte durch eine gemessene Aussage — und sitzt die Achse im geldwert-kritischen Maßnahmen-Teil (§0b)?
| # | Dimension | Daten-Bedarf | Begründung — was die Anbindung hebt |
|---|---|---|---|
| 1 | Actionability & Agentic Viability Quelle: GA4 |
HOCH | Die Achse fragt, ob ein realer, reibungsarmer Handlungs-/Conversion-Pfad existiert. Cold sieht nur die On-Site-Heuristik (CTAs, Formulare, strukturierte Aktionen) — ob diese Pfade zum Abschluss führen und welcher Euro-Wert je Quelle dranhängt, zeigt erst GA4 (echte Conversion-Pfade/-Raten, inkl. KI-Referral). Erfolgsmetrik rein First-Party → höchster Grenznutzen. |
| 2 | Organic Search Reach Quelle: GSC |
HOCH | Misst, ob heute relevante unbezahlte Nachfrage eingefangen wird. Cold schätzt das nur directional aus einer öffentlichen SERP-Stichprobe; die Kernzahlen — echte Klicks, CTR, Position je Query, Index-Abdeckung — liegen ausschließlich in GSC. Ohne Anbindung bleibt die Achse explizit „directional only". |
| 3 | Content & Journey Coverage Quelle: GA4 + Google Ads |
MITTEL | Cold bewertet die Inhalts-/Funnel-Struktur crawl-basiert (welche Journey-Stufen sind abgedeckt). Wo Nutzer real abbrechen, welcher Suchintent konvertiert und welchen CPC-Geschäftswert ein Thema hat, sieht erst GA4 + Ads. Die Anbindung macht aus Struktur-Lücken geldwert-priorisierte Lücken. |
| 4 | AI Answer Presence Quelle: GSC (AI-Mode) |
MITTEL | Wird primär per Test-Prompts gegen KI-Suchmaschinen gemessen — diese Linse ist auch Cold schon belastbar. Die Anbindung schärft sie um GSC-AI-Overviews-/AI-Mode-Impressionen und deckt die „rankt, wird aber nicht zitiert"-Lücke auf: wertvoll, aber additiv, nicht konstitutiv. |
| 5 | Offer & Entity Clarity Quelle: GBP |
MITTEL · bedingt | Die HTML-/Schema-Klarheit der Entität ist crawl-deterministisch (Cold belastbar). Der Connected-Mehrwert (GBP: lokale Sichtbarkeit, Bewertungen, Map-Pack) greift v. a. bei lokalen/Map-relevanten Geschäften — bei rein nationalen/digitalen Anbietern gering. Stark kontextabhängig. |
| 6 | Evidence & Trust Quelle: — |
KEINER | Autorschaft, Quellenbelege, Aktualität, Transparenz und unabhängige Reputation sind on-page bzw. öffentlich sichtbar. Keine First-Party-Daten nötig — Cold ist hier voll belastbar. |
| 7 | Technical Discoverability Quelle: — |
KEINER | Crawlbarkeit, Rendering, Indexierbarkeit und strukturierte Daten sind vollständig crawl-deterministisch und ohne Kundendaten abschließend prüfbar. Eine Anbindung fügt nichts hinzu. |
| 8 | Knowledge-Catalog Readiness NEU Quelle: GSC verified-domain / Discoverability-API |
GERING | Die agenten-konsumierbaren Signale — JSON-LD-Vielfalt, potentialAction/Transactability,
Feed/llms.txt/API-Endpoints, maschinenlesbare Preis-/FAQ-Daten — sind crawl-deterministisch
(Cold belastbar, Confidence B). Der Connected-Mehrwert ist eng umrissen: eine
Search-Console-verifizierte Domain + Discoverability-API/First-Party-Katalog heben einzelne
Sub-Checks auf Confidence A. Transactability bleibt in beiden Tiers ein Code-Signal — ein echter
A2A-/Booking-Probelauf ist bewusst Backlog (fragil & einwilligungspflichtig). |
Lesart: HOCH = Cold-Aussage bleibt ohne Daten geschätzt/„directional", Anbindung ersetzt sie durch eine gemessene · MITTEL = Cold liefert eine belastbare Grundaussage, Daten schärfen sie · KEINER = crawl-deterministisch, Cold voll belastbar. Deckt sich mit den Per-Maßnahme-Markern im Report (🔌 vs. ✓) und der §0b-These „Hebel sitzt in den Maßnahmen".
Guardrail bleibt: jede Zahl mit Quelle, Datum, Confidence; bei fehlenden Daten „not measured" statt Score 0; keine Ranking-/Traffic-Garantien — auch nicht mit First-Party-Daten.