BigQuery AI Functions Can Reason Over Your Rows — If the Rows Carry Content
BigQuery AI Functions — AI.GENERATE, AI.GENERATE_TABLE, AI.CLASSIFY — went GA in January 2026. Claude Desktop Live Artifacts shipped in April. Together they create a two-tier natural-language interface to WooCommerce data: the operator asks Claude a question, and Claude writes SQL that calls AI Functions to reason over individual rows. But AI.GENERATE classifying refund reasons needs a refund_reason column. AI.CLASSIFY categorising cart intent needs cart-level context fields. AI.FORECAST predicting revenue needs historical data at daily or hourly granularity. None of these exist in a default WooCommerce order-export schema. The AI functions are production-ready. The data underneath most WooCommerce stores is not.
Two Natural-Language Layers in Thirty Days
Both layers are production-ready. The data between them usually isn’t.
Two natural-language layers reached general availability within thirty days of each other in spring 2026. BigQuery AI Functions — AI.GENERATE and AI.GENERATE_TABLE — went GA on January 27, 2026, letting analysts call Gemini, Claude, and Mistral models directly from inside a SQL query against warehouse data. Claude Desktop Live Artifacts shipped on April 20 as the dashboard layer that talks to that warehouse via the BigQuery MCP server.
The managed AI functions — AI.IF, AI.SCORE, and AI.CLASSIFY — have been in public preview since November 2025. After March 17, 2026, the BigQuery MCP server is automatically enabled for all new projects. The infrastructure is in place. The capability gap closed.
For a WooCommerce operator, the implication is a two-tier natural-language interface that didn’t exist in early 2026. The operator asks Claude Desktop a question in plain English. Claude Desktop writes a SQL query that includes AI Function calls running over individual rows. The result is dashboards that can summarise free-text fields, classify cart contents, and forecast inventory — all from one prompt.
BigQuery AI Functions AI.GENERATE and AI.GENERATE_TABLE reached general availability on January 27, 2026, letting SQL analysts call Gemini, Claude, and Mistral models directly from inside a SQL query against warehouse data.
How the Two-Tier Interface Works
The top tier interprets the question. The bottom tier reasons over the rows.
Claude Desktop reads BigQuery through the MCP server. When you ask “what’s the most common refund reason this week?” Claude doesn’t guess. It writes a SQL query. But the query it writes can now include an AI.GENERATE call that runs over every row in the refund table, classifying the free-text reason field into categories.
The top tier (Claude Desktop) handles intent: it understands what you’re asking and translates it into SQL. The bottom tier (BigQuery AI Functions) handles row-level reasoning: it processes individual text fields, classifies them, scores them, or extracts structured data from them. Neither tier works alone for semantic questions.
You may be interested in: Claude Desktop’s BigQuery MCP: 90-Second Setup, Empty WooCommerce Results
The combination is what makes it new. One prompt from the operator triggers a SQL query that contains an LLM call, against real warehouse data, returned as a dashboard.
Three Use Cases That Expose the Gap
Each use case works — and each one requires a column most WooCommerce stores don’t have.
Use case 1: Classify refund reasons. “What’s the most common reason customers are returning products this month?” Claude writes a query calling AI.GENERATE over the refund_reason column. Requires: a refund_reason text field on every refund record. The default WooCommerce REST API export doesn’t include it.
Use case 2: Detect gift-intent carts. “Which carts this week contain gift-intent signals?” Claude calls AI.CLASSIFY over cart-level context — product mix, gift wrapping, shipping address different from billing. Requires: cart-level event data with product attributes and address comparison fields. Standard tracking captures add_to_cart with a product ID and nothing else.
Use case 3: Forecast revenue by category. “What should I expect from running shoes next week?” Claude calls AI.FORECAST over historical daily revenue partitioned by category. Requires: purchase events at daily granularity with product category as a partition column, going back 90+ days.
| Use Case | AI Function | Required Column | Default WooCommerce? |
|---|---|---|---|
| Classify refund reasons | AI.GENERATE | refund_reason (free text) | No |
| Detect gift-intent carts | AI.CLASSIFY | Cart context (product mix, gift wrap, addresses) | No |
| Forecast revenue by category | AI.FORECAST | Daily revenue by product category | Partial (GA4 delayed) |
| Summarise support tickets | AI.GENERATE_TABLE | customer_note (free text) | No |
| Score lead quality | AI.SCORE | Session behaviour, page depth | No |
AI.GENERATE classifying refund reasons requires a refund_reason text column on the order record — a field that doesn’t exist in the default WooCommerce REST API export or any standard analytics plugin schema.
What the Data Has to Look Like
AI Functions reason over text. They need text to reason over.
AI.GENERATE takes a prompt and a row. The prompt tells the model what to do. The row provides the content. If the row contains only order_id, total, status, and date, the model has nothing semantic to work with.
The fields AI Functions need are the fields most WooCommerce analytics stacks drop: free-text fields (refund_reason, customer_note, order_comment), context fields (product attributes on add_to_cart, gift-wrap flags, coupon codes), and behavioural fields (session depth, pages viewed, time between first visit and conversion).
The Order-Only ETL Problem
Most WooCommerce-to-BigQuery pipelines export orders. AI Functions need events.
The typical pipeline pulls completed orders via the REST API, flattens them into a table, and loads on schedule. The result is an orders table: one row per order, structured fields only. Great for revenue reporting. Useless for AI Functions.
You may be interested in: Six Live Artifact Dashboards for WooCommerce — and the Events Each One Needs
Sentiment analysis on 10,000 customer reviews costs approximately $0.18 in Gemini API charges versus $16,675 in analyst labour at 15 reviews per hour. The cost of the AI function is trivial. The cost of not having the data to feed it is the entire capability.
Server-side event capture writes extensible custom parameter slots at event time, pre-populating the text fields and context columns that BigQuery AI Functions need to produce real answers instead of empty classifications.
The Server-Side Fix
Write the text fields at capture time, not after the fact.
The architectural fix: capture the rich fields server-side at event time, before the browser strips them and before the ETL pipeline flattens them out. Server-side event capture writes extensible custom parameter slots at event time — the free-text fields, the product context, the session-level behaviour data that AI Functions need.
Transmute Engine™ writes every WooCommerce event to BigQuery with extensible custom parameter slots. Refund reasons, customer notes, cart context, and session behaviour are captured server-side at event time. When Claude Desktop asks BigQuery to classify refund reasons, the refund_reason column is already there, populated at capture, ready for AI.GENERATE to reason over.
Key Takeaways
- Two NL layers reached GA within thirty days: BigQuery AI Functions (January 27) and Claude Desktop Live Artifacts (April 20) create a two-tier interface to WooCommerce data.
- AI Functions need semantic content in the rows: AI.GENERATE needs free-text fields. AI.CLASSIFY needs context columns. AI.FORECAST needs historical data at the right granularity.
- Default WooCommerce schemas don’t carry it: Order exports have structured fields. AI Functions need unstructured text and behavioural context.
- The cost gap is dramatic: $0.18 for AI sentiment analysis on 10,000 rows versus $16,675 in analyst time.
- Server-side capture pre-populates the columns: Write extensible custom parameters at event time, and AI Functions have something to reason over.
SQL-callable functions invoking Gemini, Claude, or other models directly from a query. They can classify refund reasons, categorise cart intent, or forecast revenue — but only if the tables carry the needed text fields and context columns.
Two-tier NL interface. Claude Desktop interprets the question and writes SQL. The SQL includes AI Function calls that reason over individual rows. Both tiers fail when data is too thin.
Default exports have structured fields (order_id, total, status, date). AI Functions need semantic content — free-text refund reasons, customer notes, cart context. A column saying ‘refunded’ tells AI.CLASSIFY nothing.
Free-text fields on orders/refunds, cart-level context on add_to_cart events, UTMs persisted to purchase events, and historical revenue at daily/hourly granularity for forecasting.
References
- Google Cloud. “New BigQuery gen AI functions for better data analysis.” cloud.google.com, January 27, 2026. link
- Google Cloud. “SQL reimagined for the AI era.” cloud.google.com, November 13, 2025. link
- Google Cloud. “Generative AI overview — BigQuery.” cloud.google.com, 2026. link
- Google Cloud. “BigQuery release notes.” cloud.google.com, 2026. link
- Dataslayer. “BigQuery AI Functions for Marketing.” dataslayer.ai, Feb 2026. link
- Google Cloud. “The AI.GENERATE function.” cloud.google.com, May 2026. link
- NextFin. “Google Launches New BigQuery Gen AI Functions.” asianfin.com, Jan 2026. link
- Anthropic. “Live Artifacts announcement.” April 20, 2026.
The AI functions are ready. The question is whether your BigQuery tables have anything worth reasoning over. Start with the event schema.