Build a marketing data hub in BigQuery and teach the agent your own Skills
An agent is only as good as the data it can reach and the method it follows. BigQuery solves the first: it's where ad cost, store revenue, CRM outcomes and any third-party source sit together under keys you control. Skills solve the second: instead of re-explaining your methodology every run, you write it down once and the orchestrator plans your way. That's how you get from ad-hoc questions to a repeatable analysis your team actually trusts.
Why put a warehouse in the middle
Every ad platform reports on itself, using its own attribution, its own conversion definitions and its own idea of where a day ends. Ask three platforms how they performed and you'll get three answers that don't add up to your bank statement.
A warehouse fixes the arithmetic by making you commit to one definition of an order, one definition of revenue and one calendar. It also fixes a subtler problem: it gives the agent a stable place to look, so your analysis doesn't break the day a platform changes its reporting surface.
What's worth landing in BigQuery
| Source | What it adds that the ad platforms can't |
|---|---|
| Store / order system | Real revenue, refunds and margin — not platform-attributed conversion values |
| CRM | Which leads became customers, and how long that took |
| Ad-platform cost exports | One cost table across Google, Meta, TikTok and DV360 on a shared calendar |
| Product / inventory feed | Stock and margin per SKU, so the agent avoids promoting what you can't ship |
| Subscription or billing data | Lifetime value, so acquisition decisions run off LTV instead of first-order value |
| Offline or call-tracking data | Conversions the pixel never saw |
Getting third-party data in
Be clear on the division of labour: Agent Planners reads BigQuery, and you own the loading. That's deliberate — a system that both writes your warehouse and reasons over it is a system that can quietly corrupt its own evidence.
Use whichever loading path fits the source, and keep it outside the agent:
- BigQuery Data Transfer Service for Google-native sources on a schedule, with no code to maintain.
- Partner connectors and ETL tools for the long tail of SaaS sources that already ship a maintained BigQuery destination.
- Your own scheduled jobs, writing through the Storage Write API or batch loads, when a source has an API but no connector.
- Scheduled queries inside BigQuery, to reshape raw landing tables into the modelled tables the agent reads.
Model it so an agent can actually reason over it
An agent writes SQL against whatever it finds. A little modelling discipline turns vague questions into correct queries, and it costs you about one afternoon.
- One grain per table, named in the table name. `orders_daily` and `ad_cost_daily` beat one wide `marketing` table nobody can reason about.
- One canonical date column, named the same everywhere, in one timezone you've written down.
- Money in one currency, with the currency stored as a column — mixed currencies with no marker is the single most common source of wrong totals.
- Shared join keys across the cost and revenue tables. A campaign id in one and a UTM string in the other means every query needs a fragile parse.
- Column descriptions in the table schema. They're free, and they tell the agent what `value_v2` actually means instead of leaving it to guess.
Now write the method down as a Skill
With the data in place, the remaining variable is method. Left to itself an agent will produce a reasonable analysis — and a slightly different reasonable analysis next week. A Skill bundles the tools with your proven approach, so the orchestrator plans your way instead of re-deriving one each time.
Skills live per organization. Built-in ones seed when you create an org, you can add your own, and the agent can save a new Skill mid-run when it finds an approach worth keeping.
- The question it answers, stated plainly — this is what the planner matches against.
- Which tables to use, by name, and which to ignore.
- Your definitions: what counts as a conversion, which orders are excluded, how refunds are handled.
- The thresholds you act on, so the output is decisions rather than a data dump.
- The shape of the output — a ranked table, a specific set of columns, a recommendation per row.
A worked example: a "true ROAS review" Skill
Here's the shape of a Skill that turns a weekly argument about numbers into a repeatable report.
- 1Scope: "Rank campaigns by true ROAS over a given window and recommend budget moves."
- 2Data: join ad_cost_daily to orders_daily on campaign id and date, in shop timezone; exclude refunded and test orders; use net revenue, not gross.
- 3Method: compute spend, net revenue, true ROAS and the delta versus the prior period, per campaign.
- 4Thresholds: flag anything under 1.5× for a budget cut, and anything over 3× with capped impression share for an increase.
- 5Output: one table sorted by spend, plus at most five ranked recommendations with the numbers behind each.
- 6Guardrails: never propose changes to campaigns listed as protected in account memory.
Skills versus memory — use both, for different things
These are easy to confuse, and they solve different problems. A Skill is method: how to do a piece of analysis. Account memory is context: the standing facts and constraints for one account. Method belongs in a Skill so it applies wherever you run it; targets and protected campaigns belong in memory so every run against that account respects them without being told.
| Put it in a Skill | Put it in account memory |
|---|---|
| The tables to query, and how to join them | This account's CPA and ROAS targets |
| Your definition of a conversion | Campaigns the agent must never pause |
| The analysis steps, in order | Geos to exclude |
| The output format you want | Notes on why past decisions were made |
Close the loop with a schedule
A Skill plus a schedule is the whole payoff: the analysis you argued your way to once now runs every Monday against live data, in your timezone, following your method — and any change it proposes still waits for a human. That's the difference between a dashboard you stop opening and a review that actually drives decisions.
Frequently asked questions
- Why use BigQuery as a marketing data hub?
- Because every ad platform reports on itself with its own attribution, conversion definitions and day boundaries, so their numbers never reconcile. A warehouse forces one definition of an order, one revenue figure and one calendar, and gives an agent a stable place to query that doesn't break when a platform changes its reporting.
- Can Agent Planners load data into BigQuery for me?
- No — it reads BigQuery, and you own the loading pipeline. Use the BigQuery Data Transfer Service, a partner connector, your own scheduled jobs, or scheduled queries inside BigQuery. Keeping loading outside the agent means the system reasoning over your evidence can't quietly corrupt it.
- How do I connect third-party data sources to BigQuery?
- Data Transfer Service for Google-native sources, a partner ETL connector for common SaaS tools, and your own jobs via the Storage Write API or batch loads for anything with an API but no connector. Land those in raw tables, then use scheduled queries to reshape them into the modelled tables the agent reads.
- What is a Skill in Agent Planners?
- A reusable bundle of tools plus your proven method, stored per organization, that the orchestrator consults while planning. It's how you stop re-explaining your methodology — write the tables, definitions, thresholds and output format down once, and every future run follows it.
- What's the difference between a Skill and account memory?
- A Skill is method — how to run a piece of analysis — and applies wherever you use it. Account memory is context for one specific account: its targets, protected campaigns, excluded geos and decision history. Use Skills for how, and memory for the standing facts.
- How should I structure BigQuery tables for an AI agent?
- One grain per table with the grain in the name, one canonical date column in a documented timezone, money in one currency with the currency as a column, shared join keys between the cost and revenue tables, and column descriptions filled in so the agent doesn't have to guess what a field means.