Ich habe neulich angeteasert, dass ich diesen Artikel schreiben werde... Ich habe bereits dargelegt, dass sich GSC-API und Frontend nicht unterscheiden und bisher konnte mir, erwartungsgemäß, auch niemand das Gegenteil beweisen. Fakten sind nunmal schwer zu widerlegen (also zumindest außerhalb postfaktischer Logik).
Aber neben der API gibt es seit Februar 2023 den Big Query Bulk Data Export. Und Unterschiede zwischen der GSC-API und dem Big Query Bulk Data Export sind auch Fakten. Und die drösel ich Dir jetzt auf:
Warum gibt es da Unterschiede?
Ganz einfach: Datenbanken sind teuer, also zumindest wenn man den Google Traffic weltweit für 16 Monate speichert. Für den kostenlosen Service der Google Search Console hat Google den Zugriff daher kostensparend limitiert. Google sagt dazu: The remaining data will be large enough to create a representative sample of data.
Das stimmt im Groben. Aber in einer gewissen Größenordnung gibt es häufig Properties, bei denen über 50% der Impressions wegfallen. Klicks sind in der Regel weniger stark betroffen, aber sehr breit aufgestellte Properties weisen auch hier mitunter signifikante Unterschiede auf.
Worin liegt der Unterschied?
Wenn Du in meinem letzten Artikel über Fehlerquellen zwischen GSC-Frontend und der GSC-API bei Punkt 7 gedacht hast, dass das genau Dein Problem ist und genervt warst, dass ich Dir dort nicht schon weitergeholfen habe, wirds jetzt für Dich interessant:
Die GSC-API hat ein Limit von 50.000 Zeilen pro Tag und Suchtyp beim Abruf
(also beim Ziehen der Rohdaten aus der Datenbank, nicht bei der Ausgabe-Antwort über die API).
Der Bulk Export hat dieses Limit nicht. Daher bekommt man in dem BigQuery Export ein deutlich größeres Stück Longtail-Rankings ausgegeben, die über die GSC direkt oder die API nicht abgerufen werden können.
Wenn deine Domain also genug Rankings hat, um ggf. 50.000 Zeilen des Exports zu sprengen (das geht in der byPage-Logik schneller, als man denkt), dann verpasst Du ohne den Bulk-Export relevante Daten.
Ich habe mit folgender Query einzelne Tage großer Property-Bulk-Exporte mit den Ergebnissen über die GSC-API abgeglichen. Und das Ergebnis stimmt exakt überein:
SELECT
data\_date, url, query, device, country, is\_amp\_top\_stories, is\_amp\_blue\_link, is\_job\_listing, is\_job\_details, is\_tpf\_qa, is\_tpf\_faq, is\_tpf\_howto, is\_weblite, is\_action, is\_events\_listing, is\_events\_details, is\_search\_appearance\_android\_app, is\_amp\_story, is\_amp\_image\_result, is\_video, is\_organic\_shopping, is\_review\_snippet, is\_special\_announcement, is\_recipe\_feature, is\_recipe\_rich\_snippet, is\_subscribed\_content, is\_page\_experience, is\_practice\_problems, is\_math\_solvers, is\_translated\_result, is\_edu\_q\_and\_a, is\_product\_snippets, is\_merchant\_listings, is\_learning\_videos,
SUM(impressions) AS impressions, SUM(clicks) AS clicks, SUM(sum\_position) AS sum\_position
FROM
\``$byPage-dataset\_url\_impression\`` # byPage dataset
WHERE
data\_date = "$datum" # Achtung: das limit ist pro tag. wenn Du einen längeren Zeitraum abrufst, passt es wieder nicht
AND search\_type = "$searchtype" # WEB, IMAGE, VIDEO, DISCOVER etc..
AND query IS NOT NULL # Anonymized queries rauswerfen. Falls du ohne Queries abfragst, fällt dieser filter ggf weg
GROUP BY
url, query, device, country, is\_amp\_top\_stories, is\_amp\_blue\_link, is\_job\_listing, is\_job\_details, is\_tpf\_qa, is\_tpf\_faq, is\_tpf\_howto, is\_weblite, is\_action, is\_events\_listing, is\_events\_details, is\_search\_appearance\_android\_app, is\_amp\_story, is\_amp\_image\_result, is\_video, is\_organic\_shopping, is\_review\_snippet, is\_special\_announcement, is\_recipe\_feature, is\_recipe\_rich\_snippet, is\_subscribed\_content, is\_page\_experience, is\_practice\_problems, is\_math\_solvers, is\_translated\_result, is\_edu\_q\_and\_a, is\_product\_snippets, is\_merchant\_listings, is\_learning\_videos
ORDER BY
clicks DESC,
impressions DESC # zur Sortierung nach impressions habe ich nix in der dokumentation gefunden, und hat auch in meinen tests keine unterschiede gemacht, aber es ist schlüssig, dass man danach auch sortiert. oder vielleicht nicht um rechenleistung zu sparen.
LIMIT
50000
Die eigentliche API-Datenbank-Abfrage ist etwas anders gestrickt und effizienter aufgebaut, aber das Ergebnis stimmt, wie gesagt, exakt mit der API überein.
Wenn Du möchtest, kannst Du also mit einer unnötig umfangreichen und langsamen Query alle Vorteile des Bulk-Exports künstlich wieder aus den verfügbaren Daten raushalten. Toll oder?
Was macht die Unterschiede aus?
Was Du verpasst, sind hauptsächlich Longtail-Keywords.
Im Ergebnis sind in den Big Query-Daten:
- die Anzahl der Keywords massiv höher
- die gesamten Impressionen signifikant höher
- die Klicks nur schwach höher
- die CTRs entsprechend schlechter
- die Positionen...
Der Effekt ist in den byPage-Daten deutlich stärker als in den byProperty-Daten, weil jede URL mehr Zeilen produziert und somit das API-Limit von 50.000 Zeilen pro Tag schneller erreicht ist.
Außerdem gilt:
- Big Query-Daten sind ausschließlich finalisierte Daten.
- Anonymized Queries werden aggregiert ausgegeben und müssen ggf. bewusst herausgefiltert werden
- Search Types sind alle in einer Tabelle. Für den korrekten Vergleich muss man hier auch korrekt filtern.
und aus leidvoller Erfahrung noch folgender Tipp für Dich:
Falls jemand an den BigQuery-Einstellungen oder Zahlungsdaten rumgespielt hat, kann es passieren, dass für einen Zeitraum keine Daten importiert wurden. Wenn Du neu mit einem Datenset arbeitest, das Du nicht selbst angelegt hast, lohnt es sich, einen Blick auf die data_date-Werte, um etwaige Lücken zu erkennen.
Was kannst Du noch vergleichen, was nicht?
Grundsätzlich sind die Daten vergleichbar, wenn man sorgsam die gleichen Filter wie in GSC-API/Frontend setzt. Aber je größer Deine Domain ist und je mehr Rankings Du hast, desto größer wird die Differenz. Wie gesagt, bei großen, longtailigen Properties werden schonmal >50% mehr Impressionen über den Bulk-Export ausgegeben. In Einzelfällen haben wir sogar schon 20-30% mehr Klicks in BigQuery-Daten gesehen.
Aber:
Die Trends sind in der Regel gleich. Wenn der Traffic laut BigQuery um x% einbricht oder wächst, sind es in der Regel auch im Frontend (oder Via API) näherungsweise die gleichen x%.
Du wirst im Alltag in der Regel für die gleiche Fragestellung mit beiden Datenquellen zu den gleichen Erkenntnissen/Entscheidungen kommen.
Aber bei der Analyse des Longtail-Traffics sind die BigQuery Daten heutzutage für viele Properties ein Muss. Die Menge an Informationen, die hier schlummert, ist zu groß.
Für Properties mit einem sehr breiten Keyword und URL-Set kann es auch sein, dass ein signifikanter Teil Klicks ohne BigQuery verloren geht.
Wie groß ist der Unterschied für Deine Property?
Daniel Weisberg schreibt in seinem GSC Deep Dive:
“A few very large websites can be affected by this, but even for those we believe the remaining data will be large enough to create a representative sample of data.”
Damit hat er grundsätzlich recht, aber: "very few" macht einen erstaunlich großen Anteil der Properties aus, bei denen wir den Vergleich machen konnten (der Fairness halber sei gesagt: in unserer Stichprobe sind very large Websites möglicherweise auch überrepräsentiert...).
Zweites aber:
Queries werden in Zeiten von LLMs immer individueller. Der Longtail wächst, während der Midtail schrumpft. Das bedeutet naturgemäß, dass wir SEOs uns mehr mit dem Longtail beschäftigen müssen... Je stärker das wird, desto spannender wird das Mehr an Daten aus dem Bulk Export. Spätestens wenn Deine Domain auch Unterschiede in den Klickzahlen aufweist, wird es Zeit, über BigQuery als Quelle für Analysen nachzudenken.
Wenn Du weniger als 50.000 Impressionen pro Tag in Deiner GSC-Property siehst, wirst Du in BigQuery keine zusätzlichen Daten finden, denn es können nicht mehr Zeilen als Impressionen in der Datenbank entstehen.
An sich kannst Du dann hier auch aufhören weiter zu gucken. Aber in dem Fall bleibt die Menge an Daten, die in BigQuery einlaufen, auch locker so klein, dass keine Kosten für BigQuery anfallen (sofern Du die 10 GB for free nicht schon anders nutzt). Also verursacht der GSC-Export auch keine Mehrkosten.
Wenn Du mehr Traffic hast, solltest Du es zumindest mal ausprobieren und gucken, wie groß der blinde Fleck bei Deinen GSC-Properties ist.
Ich empfehle einen einfachen Test über die GSC-API. Nimm dazu folgende Query und frage sie in der GSC-API für Deine Property ab:
{
"aggregationType": "BY\_PAGE",
"dataState": "FINAL",
"dimensions": \[
"QUERY",
"PAGE",
"COUNTRY",
"DEVICE"
\],
"type": "WEB",
"startDate": "2025-07-01",
"endDate": "2025-07-01",
"startRow": 40000,
"rowLimit": 25000
}
Diese Abfrage fragt einen Tag (wenn der 2025-07-01 für Dich kein repräsentativer Tag war, setze einen anderen ein) mit allen möglichen Dimensionen ab, um möglichst nah an die Gesamtzahl der Zeilen zu kommen. Dabei werden mittels startRow die ersten 40.000 Zeilen ignoriert, da das maximale rowLimit 25.000-Zeilen pro query sind, aber uns die Annäherung an 50.000 interessiert.
Wenn Du keine API-Verschnüffelung hast, kannst Du das auch einfach auf der Dokumentationsseite im Browser machen. Dafür klickst Du auf der API-Reference für die Search Analytics Schnittstelle auf “try it now”.
Da man Search-Appearance nicht mit als Dimension abfragen kann, ist das nur eine Näherung, aber in der Regel völlig ausreichend.
Wenn diese Query leer ist, hat die Abfrage weniger als 40.000 Zeilen für den abgefragten Tag produziert. Da könnte durch verschiedene Search-Appearance noch ein paar Zeilen mehr drin sein, aber solange deine URL-Anzahl oder Dein Traffic nicht signifikant steigen, ist da noch Luft, bevor GSC-API und Big Query Unterschiede zeigen.
Wenn in der Abfrage Ergebnisse sind, dann ist im Bulk-Export langfristig ziemlich sicher ein wenig mehr an Daten drin. Wenn es mehr als 19.000 Ergebnisse sind, teste auch noch ein paar andere Tage. Wenn das immer wieder vorkommt, dann kommst Du wahrscheinlich täglich über den Schwellwert.
In dem Fall rate ich Dir dringend, den Bulk-Export zumindest mal Testweise einzurichten. Spätestens wenn die letzten Ergebnisse aus der API noch Klicks haben, ist es Pflicht, den Bulk-Export zu testen!
Vielleicht sind es nur ein paar Impressionen von Zufallsrankings mehr, mit denen Du vielleicht nie relevanten Traffic machst, vielleicht ist es aber auch ein größeres Stück vom Kuchen. Je mehr Traffic, desto größer ist die Wahrscheinlichkeit, dass wertvolle Informationen über Deinen Longtail-Traffic unter den Tisch fallen würden. Sicher wissen kannst Du es nur, wenn Du es mal ausprobierst.
Was kostet BigQuery
Selbst bei großen Domains reichen die erwähnten freien 10 GB locker, um das ein paar Wochen zu testen.
Falls Du mehrere hundert Millionen Impressionen im Monat in deiner GSC Property siehst, könnte das schon im ersten Monat knapp werden mit den 10 GB... aber dann kann es Dein Geschäftsmodell hoffentlich verkraften, wenn da beim Test versehentlich 10€ BigQuery Kosten anfallen... Deine Opportunitätskosten der Arbeitszeit, die es braucht, auf BigQuery-Daten zu gucken und zu prüfen, wie groß der Unterschied ist, ist betriebswirtschaftlich auf jeden Fall relevanter.
Da die Felder mit dem größten Speicherbedarf die URLs und Keywords sind, lassen sich die exakten Speicherkosten einer Property schwer vorhersagen. Wahrscheinlich sind es nicht über 100€ für 24 Monate (und das freie TiB Abfragevolumen knackt man nur, wenn man den Abfrageprozess nicht im Griff hat und Abfragen unnötig häufig wiederholt und dazu eine große Property hat).
Nach ein paar Wochen, kannst Du aber abschätzen, wie viel Speicherbedarf pro Monat in BigQuery bei Deiner Property anfallen würden und den Preis einfach hochrechnen (https://cloud.google.com/bigquery/pricing?hl=en#storage).
Brauchst Du BigQuery
Das ist am Ende Deine Entscheidung. Mit den beschriebenen Tests kannst Du einschätzen, was Dir ohne Bulk-Export durch die Lappen geht. Vielleicht reicht Dir das Wissen schon, um den blinden Fleck einkreisen zu können.
Auch wenn der Unterschied bei Deiner Property nicht so riesig ist, schadet es aber auch nicht, die BigQuery Daten mitlaufen zu lassen (sofern es Dir nicht zu teuer ist). Insbesondere wenn Du Dich für unterschiedliche Search Appearance interessierst, sind die Daten des Bulk-Export besser zu verarbeiten.
Unabhängig davon gibt es noch einen weiteren guten Grund für den Bulk-Export:
Wenn Du (oder Dein Chef) für Dein Reporting einen vollen Vorjahresvergleich möchtest und nicht nur die 16 Monate der API, dann ist das mit dem BigQuery Export langfristig möglich. Denn wie lange die Daten aufbewahrt werden, liegt dann bei BigQuery in Deiner Hand.
Frag uns gern, wenn Du mehr zum GSC Bulk Export und Big Query wissen willst.
|
