![\"Queries](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/gsc-seo-dashboard-en.png\")
What the API Gives That the Interface Does Not<\/h2>\n
The performance report exports up to a thousand rows. The For a dashboard, Looker Studio’s native Search Console connector calls the same API without any code, which is the practical route unless the data is being warehoused. Its one structural constraint is worth knowing before designing anything: the connector offers a site-level table where the query dimension exists and a URL-level table where the landing page exists, and query and landing page cannot be combined<\/strong>. That is a limitation of the Search Console data itself, not of the connector, and no calculated field works around it.<\/p>\n Both places where a regular expression can be written behave in a way that surprises people who know regex from elsewhere.<\/p>\n Search Console uses RE2<\/strong>, which has no lookahead and no lookbehind. The familiar trick for non-brand \u2014 a negative lookahead excluding the brand name \u2014 simply fails to compile. The supported approach is the filter’s own inversion: a custom regex filter set to doesn’t match<\/em>, with the brand pattern as the expression.<\/p>\n Looker Studio’s The The same construction, extended, becomes the dimension the dashboard is built on. Order matters \u2014 the first matching branch wins, so brand belongs first, or a branded search for a feature lands in that feature’s cluster:<\/p>\n Keeping an explicit Unmatched<\/em> branch rather than a catch-all label is what makes the field maintainable. That bucket is a working queue: sorted by impressions, it lists the demand the taxonomy has not accounted for yet, and every cluster after the first two usually comes out of reading it.<\/p>\n A cluster dimension makes three charts sufficient. Impressions by cluster over time show whether visibility is broadening or concentrating. Clicks and CTR per cluster show whether that visibility converts into visits. A table of the unmatched queries feeds the next iteration of the taxonomy.<\/p>\n The trap in this view is the brand cluster. Brand searches rise with awareness, with campaigns, and with seasonality, and they convert far better than anything else \u2014 so a total that looks healthy can hide non-brand clusters shrinking underneath it. Reporting brand and non-brand as separate lines rather than as one visibility total is what keeps that visible.<\/p>\n Search Console has no dimension for AI-generated answers. Impressions that occurred inside a generative result are included in the same performance data as ordinary results, and there is no filter that separates them, so any dashboard claiming to measure generative visibility from this source is inferring rather than measuring.<\/p>\n What the data does support is a pattern worth watching: an informational cluster whose impressions hold steady or grow while its clicks and CTR decline, over a period with no ranking loss to explain it. That shape is consistent with answers being satisfied on the results page. It is also consistent with a changed snippet or a shifted mix of queries within the cluster, which is why it belongs in a report as a question to investigate rather than a metric to present.<\/p>\n Three properties of the source data limit what the dashboard can honestly claim. Rare queries are withheld entirely for privacy reasons, so the query rows will always sum to less than the property totals \u2014 the difference is not a bug to reconcile, and cluster shares should be read as shares of the queries that are<\/em> reported.<\/p>\n History stops at sixteen months, which makes year-over-year comparison possible but not a second year of it, so anything longer needs its own storage. And average position is already an impression-weighted average within each row; averaging those averages across a cluster produces a number that looks precise and means very little, which is why impressions and clicks carry the argument better than position does.<\/p>\n","protected":false},"excerpt":{"rendered":" Getting more rows out of Search Console than the interface exports, splitting queries into brand and topic clusters with regex calculated fields in Looker Studio, and reading the result honestly \u2014 including what the data cannot say about generative search results.<\/p>\n","protected":false},"author":1,"featured_media":11407,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[127],"tags":[91386,91353,91094,91219,91252],"class_list":["post-10146","post","type-post","status-publish","format-standard","hentry","category-tutorials-en-digital-marketing","tag-marketing-cyfrowy-pl","tag-looker-studio","tag-seo","tag-tutorial","tag-web-analytics"],"yoast_head":"\nsearchanalytics.query<\/code> method of the API returns up to 25,000 per request and pages through the rest with startRow<\/code>, which is the difference between seeing the head of the distribution and seeing the long tail where new topics first appear.<\/p>\nPOST https:\/\/searchconsole.googleapis.com\/webmasters\/v3\/sites\/\n https%3A%2F%2Fexample.com%2F\/searchAnalytics\/query\n\n{\n \"startDate\": \"2026-07-01\",\n \"endDate\": \"2026-07-31\",\n \"dimensions\": [\"query\"],\n \"rowLimit\": 25000,\n \"startRow\": 0,\n \"dimensionFilterGroups\": [{\n \"filters\": [{\n \"dimension\": \"query\",\n \"operator\": \"includingRegex\",\n \"expression\": \"(?i)(pricing|cost|licen[cs]e)\"\n }]\n }]\n}<\/code><\/pre>\nTwo Regex Rules That Decide Whether Any of This Works<\/h2>\n
REGEXP_MATCH<\/code> requires the pattern to match the entire<\/strong> field value, not a fragment of it. A pattern of acme<\/code> matches only the query that is exactly the word acme<\/em>; matching any query containing it needs the wildcards spelled out:<\/p>\n-- Field: Brand vs non-brand\nCASE\n WHEN REGEXP_MATCH(Query, '(?i).*(acme|acme corp|acmecorp|acme app).*')\n THEN 'Brand'\n ELSE 'Non-brand'\nEND<\/code><\/pre>\n(?i)<\/code> flag makes the match case-insensitive in both systems. The brand alternation is worth over-populating from the start: misspellings, the spaced and unspaced form, and the product name all belong in the brand bucket, because every one of them left outside inflates the non-brand figure with searches that were never won on merit.<\/p>\nTurning Topics into Clusters<\/h2>\n
-- Field: Query cluster\nCASE\n WHEN REGEXP_MATCH(Query, '(?i).*(acme|acmecorp).*') THEN 'Brand'\n WHEN REGEXP_MATCH(Query, '(?i).*(pricing|cost|how much).*') THEN 'Pricing'\n WHEN REGEXP_MATCH(Query, '(?i).*(integrat|api|webhook|sync).*') THEN 'Integrations'\n WHEN REGEXP_MATCH(Query, '(?i).*(vs |alternative|compare).*') THEN 'Comparison'\n ELSE 'Unmatched'\nEND<\/code><\/pre>\nReading the Dashboard<\/h2>\n
What This Data Cannot Say About Generative Results<\/h2>\n
Staying Inside the Guardrails<\/h2>\n