AI Assistant Traffic

Report how much of one property's traffic comes from AI assistants and what the shape of its search queries says about AI-driven use, from GA4 referrals and Search Console queries only. The user's request may contain a property, a date range, a focus hint (one assistant, one section of the site, "trend only"), or a search type; honor it and resolve the rest below.

Workflow

1. 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. Use the last 28 days compared with the previous period unless the user specifies dates; the trend step uses complete months. 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. The GA4 tool reads the same settled window when the dates are omitted; when explicit dates reach the last day or two, say GA4 may still be processing them.

2. Assistant referrals in GA4. Call get_ga4_llm_traffic with siteUrl, comparisonStartDate and comparisonEndDate set to the previous period (without both, the prev* fields are 0 and hasComparison is false), limit: 25 landing-page rows (max 1000) and includeDailySplit: true only when the user wants a daily series (sourceTimeseries, one point per assistant per day). When the tool reports no assistant sessions at all, say that plainly (its emptyBecause says whether the property had any sessions in the window); otherwise read the response in four parts:

   • The totals: summary (sessions, active, total and new users, page views, engagementRate, averageSessionDuration, bounceRate, event count and key events, all for assistant-referred sessions) against prevSummary, totalSessions for the whole property, and llmShareOfSessions (a 0-1 fraction; multiply by 100 for display) against prevLlmShareOfSessions.
   • The assistants table: one row per assistant under the name the tool puts in key, with sessions, activeUsers, engagedSessions, engagementRate, keyEvents, totalRevenue, transactions and addToCarts, sorted by sessions. Present the rows under those names and never rename or merge them.
   • The landingPages table: where assistant visitors land, with sessions, activeUsers, bounceRate, keyEvents and totalRevenue; hasEcommerce says whether ecommerceSummary carries revenue (currencyCode).
   • The caveats, which go into the report: methodLimits says that Google's own AI surfaces pass no distinct referrer, so their visits count as google / organic and are not in these numbers; and, by the tool's contract, an assistant's activeUsers adds up its referrer domains, so a user who arrived through two of them counts twice (summary.activeUsers is exact).

3. Query shapes. Call analyze_query_shapes with siteUrl, examplesPerBucket: 10 (0-100; 0 returns counts only) and the default searchType: "web". The tool classifies every visible query by how it looks, in 27 languages, into buckets returned in bucketOrder with the conventional bucket last; each carries label, queries, clicks, impressions, shareOfQueriesPct and shareOfImpressionsPct (0-100), zeroClickQueries, avgPosition and examples (query, clicks, impressions, ctr as 0-100, position, language, signals), plus the aiShaped roll-up of the three conversational buckets with the same shares. Read the buckets this way: