{"id":66329,"plugin_id":"plugin_asdk_app_6a258ab1e0908191aa647c33299ad14c","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-28T12:05:39.535Z","digest":"f72074ba4d2d3c21c59111c646045bf327f60d3f259c8d1a0ee8220ac91ce252","against":null,"payload":{"description":"Analyse a Search Console property's international and device performance with the GSC Wizard MCP tools: per-country and per-device tables for the current and prior window from query_countries and query_devices, market-specific winning and losing pages and queries from filtered query_search_analytics pulls, the property anchor from get_site_summary, and real-user Core Web Vitals per form factor from get_core_web_vitals. Use when the user asks \"which countries drive my traffic\", \"how do I perform in Germany\", \"mobile vs desktop\", \"is mobile dropping\", \"where is my CTR low for the position I hold\", or about hreflang, local content or international SEO.","included_files":[],"name":"country-device","skill_md_contents":"---\nname: country-device\ndescription: Analyse a Search Console property's international and device performance with the GSC Wizard MCP tools: per-country and per-device tables for the current and prior window from query_countries and query_devices, market-specific winning and losing pages and queries from filtered query_search_analytics pulls, the property anchor from get_site_summary, and real-user Core Web Vitals per form factor from get_core_web_vitals. Use when the user asks \"which countries drive my traffic\", \"how do I perform in Germany\", \"mobile vs desktop\", \"is mobile dropping\", \"where is my CTR low for the position I hold\", or about hreflang, local content or international SEO.\n---\n\n# Country and Device Performance\n\nBuild a markets table and a device table for one property, find the gaps (markets where the position is fine but the CTR is low, declines that only mobile shows), and recommend fixes. The user's request may contain a property (a GSC site URL or a recognizable name), a date range, a country (a name or an ISO 3166-1 alpha-3 code), a device, or a URL path to narrow the winners and losers step.\n\n## Workflow\n\n1. **Resolve the property.** If the user's request or the conversation names a property, use it. Site URLs use GSC formats: `sc-domain:example.com` or `https://www.example.com/`. Otherwise call `list_sites` and pick the obvious match. If several plausible properties exist, ask the user which one before continuing.\n\n2. **Anchor and windows.** Call `get_site_summary` with `days: 28`, or with `startDate`/`endDate` when the user gave dates (a date you pass always wins and `days` only sizes an edge you leave out). Use the last 28 days compared with the previous period unless the user specifies dates.\n   - Read `current` and `previous` (`clicks`, `impressions`, `ctr`, `avgPosition`) and `deltas` (`clicks`, `impressions`, `ctrPoints`, `positionDelta`).\n   - Keep `range.startDate`/`range.endDate` and `comparison.startDate`/`comparison.endDate` from the response and pass those exact dates to every later call, so all sections line up.\n   - GSC data lags about 2 to 3 days: never treat the most recent 2 days as complete, and if a dip appears at the very edge of the range, say it is likely reporting lag, not a real drop.\n\n3. **Markets.** `query_countries` takes a single date range and no comparison argument, so call it twice: once with the current window and once with the comparison window, with `limit: 25` (raise it, or page with `offset` set to `pagination.nextOffset`, when the user wants more markets).\n   - Rows are `countries[]` with `country`, `clicks`, `impressions`, `ctr` (0-100) and `position`, sorted by clicks. Country codes are lowercase ISO 3166-1 alpha-3 as the tools return them (for example `usa`, `gbr`, `deu`); print the country name next to the code and keep the code, in that case, for filters, since an `equals` match is case-sensitive on both data paths.\n   - Join the two calls by `country` and derive the click, impression, CTR-point and position deltas; say they are derived. Quote property totals from `coverage.siteTotals`, not from summed rows, and give each top market's share of total clicks as a derived figure.\n\n4. **Devices.** Call `query_devices` twice the same way (current window, then comparison window). Rows are `devices[]` with `device` (`DESKTOP`, `MOBILE`, `TABLET`), `clicks`, `impressions`, `ctr` and `position`.\n   - Join by `device`, derive the deltas and the mobile share of clicks.\n   - A mobile-only decline is mobile clicks down while desktop is flat or up. Check whether mobile `position` worsened (a ranking problem, often page experience or mobile content parity) or only mobile `ctr` fell (a SERP-layout or snippet problem).\n\n5. **CTR gaps.** For each of the top 5 to 10 markets, compare its `ctr` and `position` with the property anchor from step 2 and with the best-performing market at a similar position. Apply the same comparison to `MOBILE` versus `DESKTOP`.\n   - A market whose position is within about one place of a comparable market but whose CTR is clearly lower is a CTR gap. The usual causes are a page in the wrong language ranking there, titles and snippets written for another market, missing or conflicting hreflang, or local competitors with richer results.\n   - Report no gap where the numbers do not show one; a low CTR at position 15 is a ranking problem, not a CTR gap.\n\n6. **Market-specific winners and losers.** For each market the user cares about (or the top 3 by clicks plus the market with the largest negative delta), call `query_search_analytics` with `dimensions: [\"page\"]`, `rowLimit: 50` and `filters: [{ \"dimension\": \"country\", \"operator\": \"equals\", \"expression\": \"<lowercase alpha-3 code>\" }]`, once per window; join by `keys[0]` (the page) and rank the page deltas.\n   - To see which page ranks where across markets in one pull, call it with `dimensions: [\"country\", \"page\"]` and `rowLimit: 500` (rows carry `keys: [country, page]`). A market served mainly by a page written for another market is the hreflang or local-content signal to report.\n   - For devices, call it with `dimensions: [\"device\", \"query\"]` and `rowLimit: 500` for both windows, or filter with `{ \"dimension\": \"device\", \"operator\": \"equals\", \"expression\": \"MOBILE\" }` and `dimensions: [\"query\"]`; the device expression is uppercase, as `query_devices` returns it.\n   - Keep to two dimensions: three or more distinct dimensions send the read to the live API, which is slower and capped. Rows carry `clicks`, `impressions`, `ctr` (0-100) and `position`; derive every delta you present.\n\n7. **Core Web Vitals per form factor.** `get_core_web_vitals` measures one device class per call (`formFactor`: `ALL` by default, or `PHONE`, `DESKTOP`, `TABLET`), so call it with `formFactor: \"PHONE\"` and again with `formFactor: \"DESKTOP\"`, and optionally with `url` set to the biggest mobile losing page from step 6.\n   - Read `metrics[]` (`label`, `coreWebVital`, `latestP75Formatted`, `latestRating`, `p75Series`, `goodDensitySeries`), `periods` (oldest first, so the last entry is the latest week) and `regressions`. When `regressions` is empty, `methodLimits` explains that only a rating-band change between the two latest weeks is listed, so read `p75Series` for a slower drift.\n   - A `notConfigured: true` response means the Chrome UX Report connection is not set up in the app; say so and skip page experience rather than guessing. A `noData: true` response means CrUX holds too little real-world Chrome traffic for that target and form factor; quote its `message` and run the wider call its `nextStep` names if present.\n   - A poor or regressing mobile vital next to a mobile-only decline from step 4 is a probable cause; without the decline it is a watch item.\n\n## Interpretation rules\n\n- `ctr` values are already percentages on a 0-100 scale. Never multiply them by 100. `coverage.hiddenClicksShare` and the CrUX `goodDensitySeries` are 0-1 fractions, so multiply those by 100 to present them.\n- `position`: lower is better. A change toward a lower number is an improvement; never color it as a decline.\n- Judge by clicks and impressions at stake, not by percentage alone: a 30% drop on a 40-click tablet row matters less than a 4% drop on the mobile row.\n- Present every multi-row result as a compact markdown table (top rows only, typically 5 to 10); keep prose for interpretation, not for restating numbers.\n- Do not fabricate rows the tools did not return. If a market or device is absent from a window, say so instead of filling in a zero.\n\n## Output\n\nPresent, in this order:\n\n1. **Anchor**: one sentence with the window, the comparison window and the four property metrics with their deltas (`get_site_summary`).\n2. **Markets table** (`query_countries`, both windows):\n\n   | Code | Country | Clicks | Prior clicks | Delta | Impressions | CTR | Position | Pos. delta | Share of clicks |\n   |---|---|---|---|---|---|---|---|---|---|\n\n3. **Device table** (`query_devices`, both windows):\n\n   | Device | Clicks | Prior clicks | Delta | Impressions | CTR | Position | Pos. delta | Share of clicks |\n   |---|---|---|---|---|---|---|---|---|\n\n4. **Gaps**: a short list naming each market or device gap with the evidence (the two numbers compared and the tools they came from): CTR gaps at a fine position, mobile-only declines, wrong-market pages ranking, and the Core Web Vitals verdict per form factor with any regression.\n5. **Winners and losers per market** (`query_search_analytics`): one small table per market covered, with page, clicks, prior clicks, delta and position.\n6. End with a short prioritized list of 3 to 7 concrete recommendations, each naming the market or device and the pages or queries to act on: add or fix hreflang where another market's page ranks, write or localise content for a market with impressions but weak CTR, rewrite titles and snippets for a CTR gap, fix the regressing mobile vital or the mobile content gap, and what to re-check next period.\n\n## Error handling\n\nIf any tool call fails with an authentication or subscription error, tell the user to reconnect the GSC Wizard app from their app or connector settings, and that a GSC Wizard account with an active plan or trial plus a connected Google Search Console account is required. If the property is not found, re-run `list_sites` and offer the closest matches instead of guessing a URL format. If a single tool fails for another reason, report the gap in the relevant section and complete the rest of the workflow with the remaining data.\n\n## Grounding\n\nEvery number you report must name the tool it came from and the date range it covers, for example \"clicks 12,340 (`get_site_summary`, 2026-09-21 to 2026-09-27)\". For a table, state the tool and date range once on the line above it. If you derive a figure yourself (a delta, a sum, a share), say so and name the tool outputs it was computed from. Never report a number no tool returned.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}