Google Search Analytics API

Am 5. August 2015 hat Google die Beta-Phase der Search Analytics API beendet und sie für alle Interessierten freigegeben. Somit können nun ganz offiziell Daten zur Suchanalyse aus der Google Search Console mittels API in eigene Systeme zur Analyse überführt werden. Grund genug, sich mit der neuen Zugriffsmethode zu beschäftigen und einen Vergleich anzustellen, zur bisherigen Möglichkeit an Daten der Webmaster Tools heranzukommen.


Die Google Search Console

Am 20. Mai 2015 wurde auf dem Google Webmasters Central Blog der Start der neuen Google Search Console (GSC) bekannt gegeben. Im Grunde war dies ein Rebranding der bereits seit fast 10 Jahren bestehenden Google Webmaster Tools. Mit die größte Neuerung ist die neue Suchanalyse, die in Sachen anwendbare Filter weitaus mehr Möglichkeiten bietet als der alte Bericht der Webmaster Tools:

Filter der Google Search Console

  • Metriken können einzeln hinzu- oder abgewählt und
  • Zusätzlich im Diagrammverlauf dargestellt werden
  • Länder, Geräte, Suchtyp und Zeiträume können als Dimension gewählt werden,
    die bisher lediglich eine Filtermöglichkeit waren
  • Nicht möglich ist jedoch ein kombinieren von Dimensionen (z.B.: Seiten, Suchanfragen und Suchtyp)
  • Weitere Einschränkung ist die geringere Menge der Daten (Beschränkung auf 1.000), die man zur Analyse erhält
  • Jedoch unverändert bleibt die Verfügbarkeit der Daten (Beschränkung auf 90 Tage)

Wer einen längeren Zeitraum analysieren will, muss sich auch jetzt darum kümmern, die Daten zu sichern und bereitzustellen. Dieses ist wichtig, um Jahresvergleiche zu ermöglichen und saisonale Effekte zu identifizieren.

Die Search Analytics API

BigstockBei dem Stichwort „Daten sichern“ kommen wir zur neuen Search Analytics API bzw. zum neuen Endpunkt Search Analytics in der bereits bestehenden Search Console API v3. Sie wurde im Verlauf der letzten Wochen durch interessierte Nutzer getestet, die sich hierfür bei John Müller anmelden konnten. Seit dem 5. August 2015 kann nun die Search Analytics API von allen genutzt werden.

Wie für alle anderen Entwickler-Projekte, gibt es auch für die Search Console API (Webmaster Tools API) eine schöne Webseite auf Google Developers, die den Einstieg erleichtert. Hier stellt Google einfache Beispiele bereit, wie mit der API umgegangen werden kann. Zum Beispiel die korrekte Authorisation oder das Anfordern von Daten. Die Anleitungen finden sich sowohl für Python, Java als auch für OACurls. Für Python und Java stellt Google jeweils einen API Client zur Verfügung. Wer Interesse hat, die API per PHP anzusprechen, kann den offiziellen Google API Client for PHP verwenden. Dieser befindet sich jedoch noch im Beta-Status (Google API PHP Client auf Github).

Für alle, die sich erste Gehversuche ohne Code wünschen, stellt Google den APIs Explorer zum Experimentieren bereit. Hier können sehr einfach sämtliche Abfragen getestet werden.

API Explorer der Google Search Console

Eine zusätzliche Inspiration

Paul Shapiro hat auf Search Wilderness bereits sein bestehendes Python-Script zum Download der SC-Daten auf die neue API angepasst. Hiermit werden die Search Console Daten geladen und in eine MySQL Datenbank gespeichert.

Kombinieren von Dimensionen in der Google Search Console API

Neben dem Sichern der Daten über 90 Tage hinaus, bietet das Verwenden der API noch weitere Vorteile gegenüber dem Web-Frontend. Im Gegensatz zu dessen Möglichkeiten können mittels API durchaus verschiedene Dimensionen kombiniert werden. Fragestellungen wie „Wie viele mobile Nutzer sahen Seite X zu Keyword Y in Google?“ kann beantwortet werden. Aufmerksame Leser werden merken, dass uns diese Neuerung wieder einige Möglichkeiten zurückgibt (Stichwort Not Provided).

Die Grenzen der Google Search Console API

Wem nun direkt große Projekte mit riesigen Keyword Mengen aus der Search Console vorschweben, sei gesagt, die Grenzen des Frontend zum Umfang der Daten bleiben bestehen. Immerhin die Anzahl an Zeilen, die die API liefert, kann auf 5000 erhöht werden. Bei wirklich großen Projekten ist das aber immer noch viel zu wenig. Leider unterstützt die API auch keine Paginierung (1-5000; 5001-10000; usw.). Es bestehen jedoch mehrere Möglichkeiten diese Grenzen auszuweiten.

Abfrage der Leistungsdaten zu Suchanfragen auf Tagesbasis

Zum einen sollte man die Daten auf Tagesbasis abfragen und die Werte für Kalenderwochen oder Monate selbst aggregieren. Diese Methode liefert wesentlich mehr Daten als eine Abfrage über 30 Tage. Hierbei ist natürlich zu beachten, dass auch die aggregierten Daten unvollständig sein können. Folgendes Szenario zeigt die Schwäche gut auf.

Beispieldaten für die fiktive Suchanfrage „Beispiel für Datenaggregation“

TagZeile im ExportSuchanfrageImpressionsKlicksIm Export
01.08.20154997Beispiel für Datenaggregation253Ja
02.08.20155012Beispiel für Datenaggregation121Nein
03.08.20154995Beispiel für Datenaggregation272Ja

Im Export über die Google Search Console API wären die Leistungsdaten zur fiktiven Suchanfrage „Beispiel für Datenaggregation“ vom 02.08.2015 nicht enthalten. An diesem Tag liegt der Wert außerhalb der Exportgrenze. Die Daten fehlen uns somit in unserer Datenbank. Jede Datenaggregation zu dieser Suchanfrage ist demnach zukünftig unvollständig.

Merke: Unvollständige Daten zu Suchanfragen, die am Rand der Exportgrenze liegen, sind dementsprechend mit Vorsicht zu interpretieren!

Abfrage der Leistungsdaten aus der GSC API auf Verzeichnisebene

Wie schon bei der alten API gilt, je mehr Verzeichnisse man verifiziert, desto mehr Daten bekommt man. Es macht demnach Sinn möglichst viele Verzeichnisse einer Domain zu verifizieren. Übrigens, die Verifizierung kann auch über die API erfolgen. Man ist nicht gezwungen die Verifizierung für die Google Search Console über das Frontend vorzunehmen. Es spricht auch nichts dagegen, wichtige Landingpages einzeln zu verifizieren, um für diese möglichst alle verfügbaren Daten zu erhalten.

Ein weiterer Vorteil der Verifizierung von Verzeichnissen in der Google Search Console liegt darin, dass man die Leistungen der einzelnen Verzeichnisse direkt miteinander vergleichen kann. Schwächen in der Informationsarchitektur können schnell identifiziert und Erfolge bei der Optimierung in einzelnen Verzeichnissen direkt mit den Leistungsdaten abgeglichen werden.

Merke: Immer möglichst viele Verzeichnisse in der Google Search Console verifizieren. Ihr bekommt direkt mehr Daten und habt eine erste Segmentierung der Daten.

Abfragen von gefilterten Daten aus der GSC API

Eine weitere Möglichkeit an mehr Daten zu kommen besteht darin, gefilterte Reports abzufragen. Das geht auch über das Frontend. Folgende Beispieldaten zeigen dieses sehr schön:

Daten aus dem Suchanfragereport der Google Search Console

Das Beispiel zeigt die letzte Zeile im ungefilterten Suchanfragereport für die letzten 28 Tage. Darunter sind die Ergebnisse für denselben Report der letzten 28 Tage gefiltert nach „Barcelona“. Es ist gut zu sehen, dass der gefilterte Suchreport ab Position 4 Suchanfragen enthält, die im Gesamtreport nicht enthalten sind. Außerdem sind die Leistungsdaten zur Suchanfrage „barcelona wassertemperatur aktuell“ im gefilterten Report höher als im ungefilterten Suchanfragereport. Letzteres lässt darauf schließen, dass Google im Frontend auch die Tageswerte aggregiert, wie oben beschrieben. Deshalb kommt es auch im Frontend zu den von uns aufgezeigten Ungenauigkeiten.

Merke: Im obigen Fall wäre es beispielsweise sinnvoll für alle Destinationen eine gefilterte Abfrage zu stellen. Für einen Shop könnte man alle Kategorien und Hersteller als Filter nutzen. Natürlich müssen die Daten danach von Doubletten bereinigt werden.

Hier zeigt sich, dass diese Abfragen nicht mehr zu akzeptablen Kosten per Frontend durchzuführen sind. Da die neue API zu den Suchanfragen auch die angezeigten bzw. geklickten URLs liefert, können die Abfragen auch auf URLs gefiltert werden. Das Resultat ist dann ähnlich.

Fazit zur Abfragestrategie der neuen GSC API

Ein einfacher Vollexport der Suchanfragedaten ist nicht möglich. Durch eine geschickte Abfragestrategie kann dieses Manko allerdings ausgeglichen werden:

  1. Abfrage immer auf Tagesbasis durchführen
  2. Möglichst viele Verzeichnisse verifizieren und einzeln abfragen
  3. Gefilterte Abfragen nutzen
  4. Und natürlich alles performant in einer geeigneten Datenbank ablegen

Die folgende Präsentation zeigt ein Beispiel für eine einfache Datenhaltung, leider noch auf Basis der alten API. Ich denke aber, dass das Prinzip dennoch deutlich wird:

Vergleich zur „alten Google Webmaster Tools API“

Die neuen Möglichkeiten im Web-Frontend sind für Nutzer des Online Tools sicher eine fantastische Neuigkeit. Für Anwender, die die Daten aber bereits schon selbstständig gesichert und für eigene Analysen verwendet haben, ist hier nicht viel Neues dabei.

Bereits seit 2011 ist es möglich, Daten zur Suche aus den Webmaster Tools automatisch herunterzuladen und in eigene Systeme zu überführen. Hierfür stellte Google ein kleines Python Script zum Download der Suchanfragen zur Verfügung. Dieser Zugang war jedoch nie ein offizieller Teil der Google Webmaster Tools API, daher steht API hier in Anführungszeichen.

Für PHP Freunde hat der Github Nutzer „eyecathup“, inspiriert von Google Python Script, eine PHP Klasse geschrieben, um Daten zur Suche und sogar einiges mehr aus den Webmaster Tools zu laden. Hierauf habe ich ebenfalls bei meinem Vortrag „ETL & BI Für SEO Analysen und Reportings“ auf der Campixx 2015 hingewiesen. Bis heute (14.08.2015) ist es möglich, Daten zum alten Suchanalyse-Bericht zu laden. Offiziell ist dieser Zugang (Clientlogin) jedoch seit dem 20. April seitens Google gesperrt.

Vorteil der neuen Search Analytics API ist jedoch ganz klar das Kombinieren von Dimensionen und freien Filtern.

Mit dem bisherigen Download musste, um alle Daten zu laden, jeweils ein Download für Suchanfragen (WEB), Suchanfragen (MOBILE), Suchanfragen (IMAGE), Suchanfragen (VIDEO) und Suchanfragen (ALLE) gestartet werden.

Interessant ist, dass in der neuen API WEB und MOBILE um TABLET erweitert wurde und nun die Dimension GERÄTE bilden. WEB, IMAGE und VIDEO gehören ab jetzt zum Suchtyp. Der Typ ALL ist weggefallen.

Vorteil der „alten API“ ist ganz klar der größere Umfang an Daten. Je nach abgefragtem Zeitraum wurden hier über 10.000 Keywords geliefert. Der Download über die „alte API“ war leider jedoch oft fehleranfällig: Zu schnell ausgeführte Anfragen führten zu Ausfällen im Download, wofür es leider nie eine offizielle Dokumentation gab.

Ganz anders bei der aktuellen GSC API: Das kostenlose Kontingent der Developer Console besteht aus 1.000.000 Anfragen/Tag und 20 Anfragen/Sekunde/Nutzer. Die Grenzen sind somit ganz klar abgesteckt.

Eigene Analysen der Suchanfragedaten

Für eigene Analysen in allen Granularitäts-Stufen ist es sinnvoll die Daten per API auf Tagesbasis zu laden und in eine Datenbank zu speichern. Der einzelne Tag stellt die kleinste Betrachtungsebene dar, die uns die Search Console ermöglicht. Wochen, Monate und Jahre können auf Basis dieser Informationen selbst aggregiert werden.

Neben dem eigentlichen Download aus der Search Console, müssen die Informationen in ein eigenes Datenbank- oder Analysesystem überführt werden. Je nach Größe und Umfang des Projekts macht es hier durchaus Sinn, sich über einen komplexeren ETL Prozess und ein Datenhaltungskonzept Gedanken zu machen.

Liegen die eigenen Daten in einer Datenbank, können Analysen über einen längeren Zeitraum als 90 Tage angestellt werden. Hierfür bieten sich verschiedene Tools an. Mein Favorit für kleine Analysen ist hier für die Kombination aus Power Query und Powerpivot für Microsoft Excel. Aber auch Tools wie Tableau eigenen sich hierfür bestens.

Sehr nützlich ist es ebenfalls, die eigenen Daten um eine Dimension zu erweitern. So macht es durchaus Sinn, die Suchanfragen in Segmente aufzuteilen. Aus dieser abstrakteren Betrachtungsebene der Daten lassen sich häufig völlig neue Erkenntnisse erzielen und Aussagen zur Optimierung treffen.

Segmentierung auf Basis der Suchanfragen

Suchanfragen SegmentierenDie Segmentierung nach Suchanfragen war schon bisher möglich. Verbreitet sollte die Aufteilung der Suchanfragen nach „Brand“ und „non-Brand“ sein. Das ist sinnvoll, um die Suchanfragen zur eigenen Marke klar von den freien Suchanfragen zu trennen. Diese Trennung kann man auch über das Frontend durchführen.

Spannender sind die Segmente, die aus mehreren Suchanfragebestandteilen bestehen. Wir klassifizieren deshalb die Suchanfragen unserer Kunden und leiten daraus Segmente für die automatische Klassifikation aller zukünftig importierten Suchanfragen ab. So kann ein Segment aus Suchanfragen bestehen, die explizit einen lokalen Bezug haben. Hierzu werden beim Import alle Suchanfragen mit einer Städteliste abgeglichen und dem Segment „lokal“ zugeordnet. Oder ein Segment „Fragen“, welches alle Suchanfragen gegen Fragewörter oder typischen Fragebestandteilen abgleicht. Im eCommerce kann man Hersteller oder Kategorien als Listen nutzen, um zu wissen, wie viel Prozent der Suchanfragen einen Hersteller oder eine Kategoriebenennungen enthalten.

Spannend ist, dass man pro Segment alle Leistungsdaten im Zeitverlauf erheben kann, also wie ist die SERP-CTR und das durchschnittliche Ranking zu Suchanfragen, die einen Hersteller beinhalten. Wie unterscheiden sich diese zu Suchanfragen, die eine Kategoriebenennung beinhalten. Oder schlicht, welcher Suchanfragetyp funktioniert besser?

Segmentierung auf Basis von URL-Pfaden

Da wir in der aktuellen Google Search Console API erstmalig zu den Suchanfragen die angezeigten und geklickten URLs bekommen, können wir natürlich auch nach URLs segmentieren. Klassiker wäre eine Segmentierung nach Seitentyp wie Kategorieseiten, Schlagwortseiten, Produktseiten, Contentseiten etc. oder Segmentierung nach Verzeichnissen/Kategorien.

Diese Segmente setzen natürlich eine sinntragende URL-Struktur voraus, die immer gegeben sein sollte, wenn man SEO auch nur halbwegs nachhaltig betreiben will.

Kombination aus URL & Suchanfragesegmenten

BS_46131262Wirklich spannend, um Schwachstellen in der internen Struktur, also der Informationsarchitektur einer Website zu identifizieren, ist eine Kombination beider Segmentierungsarten. Wenn wir beispielsweise ein Segment „Produktarten“ haben sowie URL-Segmente für Produktdetailseiten und Kategorien, dann können wir prüfen, ob Suchanfragen nach Produktarten eher URLs des Segments Produktseiten oder Kategorien enthält.

Sinnvoll wäre es, wenn jemand, der nach einer Produktart (z.B. Wasserkocher) sucht, eine passende Kategorie von uns angezeigt bekommt. Ein konkretes Produkt soll er hingegen nicht angezeigt bekommen. Dennoch kommt es oft vor, dass zu solchen generischen Suchanfragen konkrete Produkte gefunden werden, anstatt die oft ebenfalls vorhandene Kategorie.

In diesem Fall ist die Informationsarchitektur an irgendeiner Stelle fehlerhaft. Da wir jetzt beide Segmente gebildet haben, können wir alle Suchanfragen ermitteln, zu denen der falsche URL-Typ gefunden wird. Die Kombination ist demnach eine gute Analyse, um die Fehler in der Informationsarchitektur zu ermitteln.

Weitere mögliche Analysen der exportierten Daten aus der GSC

BS_56913500Wer erst einmal die Daten hat, ist nicht mehr durch die Limitierungen des Frontend der Google Search Console behindert. Eine spannende Anwendung sind dann selbst definierte Alerts:

  1. Alert bei Rankingveränderungen zu wichtigen Suchanfragen
  2. Alert bei außergewöhnlichen Veränderungen der Leistungsdaten der Segmente
  3. Alert bei neuen „nicht segmentierten“ Suchanfragen in großer Menge oder hohem Volumen
  4. Alert bei Änderung rankender URLs zu wichtigen Suchanfragen
  5. Oder die Erhebung von kombinierten Kennzahlen

Ein Beispiel ist die URL-Volatilität, also zu wie vielen Suchanfragen ändert sich die angezeigte URL. Wenn sich die in den Suchergebnisseiten angezeigte URL zu einer spezifischen Suchanfrage regelmäßig ändert, dann konkurrieren intern mehrere Seiten zum Thema. Jetzt aber können wir diese Prüfung automatisch und täglich für alle Suchanfragen durchführen, zu denen wir angezeigt werden. Das Verhältnis der geänderten URLs zu den gleichbleibenden URLs nennen wir URL-Volatilität. Diese sollte sich im Rahmen einer Optimierung stetig verbessern.

Welche Analysen fallen Euch noch ein? Ich bin auf eure Kommentare gespannt!

Ich möchte nicht Programmieren!

All denjenigen, die sich nicht mit der API auseinandersetzen möchten und auch keine Datenbanken mögen, kann ich das Excel Addon Analytics Edge wärmstens empfehlen. In der Core-Variante bietet es sehr nützliche Funktionen zur Automatisierung, die Excel auch für nicht VBA Profis noch einmal richtig interessant macht. Das wichtige sind allerdings zusätzliche Connectoren, die für verschiedene Systeme vorhanden sind. In diesem Zusammenhang besonders wichtig: Der Google Webmaster Tools Connector. Er spricht sowohl die alte als auch die neue API an und ermöglicht euch viele Daten abzufragen.

Habt Ihr Fragen oder weitere Anregungen? Dann hinterlasst direkt hier unten ein Kommentar.

Johannes Kunze
Johannes Kunze
Der Autor dieses Artikels hat das Unternehmen verlassen. Bei Fragen zum Artikel wenden Sie sich bitte an [email protected]!
4 Antworten
  1. Hallo Johannes,

    vielen Dank für den sehr inspirierenden Artikel. Als Einsteiger habe ich dazu eine kurze Frage.

    Mit der Verifizierung von Verzeichnissen meinst du das Anlegen neuer Properties für Verzeichnisse?

    Viele Grüße
    Micha

    1. Vielen Dank, Johannes,

      das Thema nehme ich mir definitiv auf die Agenda. Kann bestimmt bei Gelegenheit berichten.

      Viele Grüße
      Micha

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert