Besucher- und Sucheinblicke

Überblick — was die Seite leistet

Neben der Zahl der eindeutigen Besucher stehen auf jeder Karte unter Service ▸ Web zwei Symbole, die jeweils ein modales Fenster öffnen.

Während Ihnen die nginx_meta_ct-Zugriffsdaten der Karte sagen, was Ihr Server empfangen hat, sagen Ihnen diese beiden Fenster, woher die Besucher kamen und welche Suchbegriffe sie gebracht haben — Informationen, die Ihre Serverprotokolle schlicht nicht enthalten.

Was Site Kit unter WordPress tut, läuft im Kern darauf hinaus, die Berichtsanfragen für Sie zusammenzubauen. Unter Laravel bauen Sie sie selbst und erhalten identische Zahlen; deshalb verwenden wir weder ein Plugin noch google/apiclient — die ganze Aufgabe lautet „ein JWT mit dem privaten Schlüssel signieren und gegen ein Zugriffstoken tauschen“, und der Server signiert das nativ. Ein großer Abhängigkeitsbaum für zwei REST-Endpunkte ist ein schlechtes Geschäft.

Wann Sie es einsetzen

• Der Verkehr auf einer Karte ist gestiegen und Sie wollen wissen, welcher Kanal und welche Quelle ihn erzeugt haben.
• Sie wollen die Suchbegriffe, die Impressionen und Klicks bringen, und auf welcher Seite jeder Suchbegriff landet.
• Sie wollen die Zusammensetzung des Publikums auf einen Blick sehen — Anteil neuer Besucher, Geräteverteilung, Herkunft des Verkehrs.
• Sie verfolgen nach einer Veröffentlichung Impressionen, Klicks und die durchschnittliche Position.

Aufbau

Beide Fenster gliedern sich in die Reiter Übersicht / Suchbegriffe / Verkehr (den Reiter „Suchbegriffe“ gibt es nur im Suchfenster), sodass Sie umschalten statt zu scrollen. Die Zeitraumauswahl bietet 7 / 28 / 90 Tage — genau die Menge, die der Server per Whitelist zulässt.

Besucheranalyse (GA4)

• Sechs KPI: Besucher, neue Besucher, Sitzungen, Seitenaufrufe, Interaktionsrate, durchschnittliche Sitzungsdauer — jeweils mit der Veränderung gegenüber dem unmittelbar vorangehenden Zeitraum.
• Drei Verteilungsstreifen: Besucherbindung (neu/wiederkehrend), Geräteverteilung (Desktop gegenüber Mobil und Tablet), Herkunft des Verkehrs (Suche gegenüber Sonstige). Alle drei sind Zweiteilungen und teilen daher dieselbe Bildsprache; da die KPI die absoluten Zahlen bereits tragen, zeigen sie nur den Anteil.
• Verlaufsdiagramm: Besucher, Sitzungen und Seitenaufrufe.
• Sechs Panels (Reiter „Verkehr“): Kanäle, Quellen, Städte, Länder, Geräte, meistbesuchte Seiten.

Kanal und Quelle sind nicht dasselbe. Der Kanal ist die gruppierte Antwort (Organic Search), die Quelle die konkrete (google, naver, github.com). Gerade bei koreanischen Websites entscheidet naver gegenüber google über zwei völlig verschiedene Akquisitionsgeschichten.

Suchverkehr (Search Console)

• Fünf KPI: Klicks, Impressionen, CTR, durchschnittliche Position, Anzahl der Suchbegriffe.
• Wortwolke: Größe und Farbe kodieren die Impressionen, ein ● markiert Suchbegriffe, die echte Klicks erzeugt haben, und die Zahlen sind die Impressionen ~1d / ~7d / all.
• Tabelle der Suchbegriffe: Klicks, Impressionen, CTR, Position.
• Einstiegsseite × Suchanfrage: Klappen Sie eine Seite auf, um die Suchbegriffe zu sehen, über die sie betreten wurde.
• Drei Panels: Einstiegsseiten, Länder, Geräte.

Die durchschnittliche Position ist impressionsgewichtet. Bei einem einfachen Mittelwert gleicht eine Impression auf Rang 1 zehntausend auf Rang 40 aus, was die Zahl massiv beschönigt.

So richten Sie es ein

1. Ein Dienstkonto anlegen (Google Cloud)

1. Google Cloud Console → Projekt auswählen oder anlegen → IAM & Verwaltung ▸ Dienstkonten → Dienstkonto erstellen. Eine Rolle auf Projektebene ist nicht erforderlich.
2. Konto öffnen → Schlüssel → Schlüssel hinzufügen ▸ Neuen Schlüssel erstellen ▸ JSON → Datei herunterladen.
3. Aktivieren Sie unter APIs & Dienste ▸ Bibliothek die Google Analytics Data API und die Google Search Console API.

2. In InfraGuard hinterlegen

Unter Service ▸ Web ▸ Websites verwalten ▸ Bearbeitungsreiter der Website, im Abschnitt Google-Anbindung:

Die GA4-Property-ID ist nicht die Konto-ID. In #/a405285491p550688232/ ist der Teil nach a das Konto und der Teil nach p die Property. Google unterscheidet bewusst nicht zwischen „Property existiert nicht“ und „keine Berechtigung“ (die Existenz einer Property ist selbst schon eine Information), daher sieht eine falsche Nummer exakt wie ein Berechtigungsproblem aus. Prüfen Sie zuerst die Property-ID.

Leiten Sie die Search-Console-Property niemals aus der Domain ab. Nur wer sie bestätigt hat, weiß, ob es sich um eine Domain-Property (sc-domain:) oder ein URL-Präfix (https://…/) handelt, und die falsche Wahl liefert ein leeres Ergebnis statt eines Fehlers.

3. Das Dienstkonto zu jeder Property einladen

Das JSON ist nur eine Identität; der Zugriff wird je Property gewährt. Kopieren Sie die nach dem Speichern angezeigte client_email und dann:

In GA4 ist dies die Zugriffsverwaltung der Property, nicht die des Kontos (die linke Spalte ist das Konto, die mittlere die Property). In der Search Console muss es Vollzugriff sein, nicht „Eingeschränkt“ — die Search Analytics API weist eingeschränkte Nutzer ab. Dienstkonten haben kein Postfach; entfernen Sie daher den Haken bei „per E-Mail benachrichtigen“.

4. Die Verbindung testen

[Verbindung testen] im Verwaltungsfenster fragt beide APIs mit den gespeicherten Zugangsdaten je einmal ab (letzte 7 Tage) und meldet jeden Teil einzeln.

Ohne jegliche Zugangsdaten wird nichts aufgerufen (null ausgehende Anfragen). Ungespeicherte Änderungen werden nicht getestet — bitte zuerst speichern.

Regeln für korrekte Zahlen — warum sie so gebildet werden

Sie folgen den Fallstricken, die Site Kit bereits belegt hat, jeder davon nachweisgestützt.

Datenquellen

Dienste: Services\Google\{GoogleTokenService, GoogleReportService, SiteInsightService}; Endpunkte Service\WebController@insight{Visitors,Search,Test}.

Zwischenspeicherung: Berichtsantworten werden zwischengespeichert, und der Cache-Schlüssel enthält die handelnde Identität (client_email). Dieselbe URL mit demselben Rumpf unter einem anderen Konto ist eine andere Autorisierung; ein gemeinsamer Schlüssel würde einer Website die zwischengespeicherte Antwort einer anderen aushändigen.

Warum die Zugangsdaten je Website gelten

Ein einzelner globaler .env-Schlüssel kann hier nicht funktionieren. Registrierte Websites gehören verschiedenen Eigentümern und damit verschiedenen Google-Konten, und ein Dienstkonto liest nur die Propertys, zu denen es eingeladen wurde — sobald die Websites zweier Kunden registriert sind, scheitert also immer mindestens eine. Daher das Feld zum Einfügen je Website.

• Gespeichert mit Crypt (APP_KEY) und nur schreibend: Das Modell verbirgt den Geheimtext, sodass die Oberfläche stets nur einen Booleschen Wert und die nicht geheime client_email sieht. Der private Schlüssel kommt nicht wieder heraus.
• Beim Speichern wird dreifach geprüft: Das JSON lässt sich parsen, client_email/private_key sind vorhanden, und eine Signaturschlüsselprüfung akzeptiert den Schlüssel. Abgeschnittene Einfügungen sind häufig, und lässt man eine durch, zeigt sie sich später als vermeintliche „Berechtigung verweigert“, die Sie durch Googles IAM suchen lässt.
• Ein serverweiter Zugang bleibt als Rückfalloption für Installationen mit einem einzigen Konto bestehen; die eigenen Zugangsdaten einer Website gewinnen immer.

Das Zugangsdatenfeld wird nur übertragen, wenn Sie es anfassen. Das Formular erhält den privaten Schlüssel nie zurück; „fehlt“ als „löschen“ zu deuten, würde die Zugangsdaten also jedes Mal verwerfen, wenn jemand nur die Notiz bearbeitet. Es ausdrücklich zu leeren ist die einzige Art der Entfernung.

Berechtigungen

• Lesen: jeder angemeldete Benutzer (infr.auth, Stufe ≥ 1). Es werden lediglich externe Statistiken gelesen, in InfraGuard wie bei Google ändert sich nichts; daher gibt es weder eine erneute Authentifizierung noch einen Audit-Eintrag (dieselbe Disziplin wie bei der IP-Reputationsabfrage).
• Speichern von Zugangsdaten/Propertys: user_level >= 2 (wie das Speichern einer Website), festgehalten in infr_audit_log.

Das Ziel wird ausschließlich über die id der registrierten Website angesprochen — eine Property-ID lässt sich nicht als Parameter übergeben. Könnten Aufrufer eine Property benennen, würden die Berechtigungen unseres Dienstkontos zu einem Weg, die GA4-/Search-Console-Propertys anderer Leute zu lesen (dieselbe SSRF-Vermeidung wie bei den Live-Tests im Katalog). Der Zeitraum ist serverseitig ebenso auf 7/28/90 begrenzt.

Fehlersuche · FAQ

• Keine Symbole auf der Karte — eine Website braucht sowohl Zugangsdaten als auch eine Property-Zuordnung, bevor die Schaltflächen erscheinen. Die Prüfung erfolgt je Website; eine Website mit eigenen Zugangsdaten funktioniert daher auch dann, wenn die globale .env leer ist. Speichern, dann neu laden.
• Jede Prüfung ist grün und trotzdem kommt 0 — das ist ein Erfassungs-, kein Abfrageproblem. ① Das Zeitfenster endet gestern, ein heute eingebautes Tag liegt also noch außerhalb. ② Vergewissern Sie sich, dass die tatsächlich ausgelieferte Mess-ID (G-…) zu der abgefragten Property gehört (GA4-Verwaltung ▸ Datenströme); landen die Daten in einer anderen Property, lesen Sie auf Dauer null. ③ Die Search Console hinkt rund 2 Tage hinterher, und eine neue Website hat womöglich noch gar keine Impressionen.
• User does not have sufficient permissions — entweder fehlt Schritt 3 (das Einladen des Kontos) oder die GA4-Property-ID ist falsch. Beides erzeugt denselben Wortlaut, also prüfen Sie zuerst die Property-ID.
• Nur die Search Console kommt leer zurück — höchstwahrscheinlich entspricht die Property-Zeichenfolge nicht der Realität (sc-domain: gegenüber https://…/). Sie scheitert als leeres Ergebnis statt als Fehler; gleichen Sie sie deshalb mit der Property-Auswahl ab.
• Die Zugangsdaten sind nach dem Speichern verschwunden — mit geleertem Feld zu speichern ist eine ausdrückliche Entfernung. Lässt man es unberührt, bleiben sie erhalten.
• Das Fenster zeigt ein Sample-Abzeichen — es wurden noch keine Daten erfasst, daher wird zur Beurteilung des Layouts ein veranschaulichendes Beispiel gezeigt. Sobald Daten eintreffen, wechselt es automatisch auf echte Werte.

Verwandte Themen

• Service ▸ Web — der Web-Überwachungsbildschirm selbst (Karten, Verfügbarkeit, Zertifikate)
• Öffentliche Landingpage und Besucheranalyse — die Erfassungsseite (gtag/GTM, Bestätigung in der Search Console)
• IP-Reputationsabfrage — dasselbe Berechtigungsmodell für externe Abfragen ohne Schreibzugriff