Google BigQuery integration data from your systems in one place
BigQuery is Google's cloud data warehouse: no server to look after, and the bill follows volume rather than a subscription. We wire it to the systems you already run: the shop, the CRM, the ad accounts, accounting and the spreadsheets. We settle what reaches the warehouse from each source, how often and in what shape. The dataset sits in a European location, with access granted per department.
- 1 TBof data processed by queries a month at no charge, alongside 10 GB of storage. Google Cloud pricing
- 2 to 6 weeksfrom the workshop to a warehouse fed by your systems; the first tables sit in BigQuery inside the first week
- 3,506 operationshow many times in 30 days our own agent loaded the data warehouse with no person involved. Details and the caveat in the proof section
The problem
What does it cost to keep company data in eight systems at once?
Orders sit in the shop, deals in the CRM, cost across three ad accounts, invoices in the accounting system, and targets plus manual corrections in a spreadsheet one person keeps. Every system shows a slice and counts it its own way: the shop with tax, the CRM without, accounting only once the invoice is issued. There is no place where those numbers stand side by side, so every time somebody assembles them by hand.
That work comes back every week and it has a price: export, spreadsheet, glue, then an hour spent working out why two numbers disagree. Worse is what cannot be counted at all. History ends where the source system ends it: an ad account gives back the last dozen or so months, a shop loses archived orders in a migration, and last year's spreadsheet was overwritten in March.
A warehouse takes that problem away, as long as it does not create a bigger one on the invoice, which is why we count the cost before the first load. Under Google Cloud pricing, in the on demand model you pay for the volume of data a query processes and for storage, and the first terabyte of queries a month and the first 10 GB of storage carry no charge. A table nobody has touched for 90 days moves to a storage rate half as high. A B2B company with a CRM, a shop and ad accounts counts its data in gigabytes rather than terabytes, so the conversation about cost starts at the free tier.
- The same export repeats every week, because there is no place where the data stays
- Sales history ends where the source system ends it
- The shop, the CRM and accounting report three different revenues, and each is true in its own way
- One person understands the spreadsheet with the targets, and their holiday stops the reporting
Why now
Why does wiring BigQuery to company systems now take weeks rather than quarters?
Most of the work that used to make a warehouse a project has gone. BigQuery is serverless: no database to administer, no backups to watch, no maintenance window to schedule. Google Ads comes in through a ready data transfer, GA4 has a native export into BigQuery, and systems with no Google Cloud integration we load over their API, Cloud Scheduler or Apps Script. Instead of writing a script per source from scratch, we assemble the warehouse out of connectors and schedules.
The second change is the order of work with data. Raw records land in the warehouse first, and the calculations are built on top of them as SQL views. The effect is practical and shows up at the first change of definition: when the board reads margin differently, you fix one view instead of pulling everything again out of five systems. The raw layer stays untouched, so every recalculation can be repeated on last year's data.
The third change is about where the data sits and who sees it. A dataset is created in a chosen location, for example the EU multi region or the Warsaw region, and queries run there. Permissions are granted on the dataset and on the view rather than on the whole project, so a department manager sees their own slice and columns with personal data stay masked. The location cannot be changed later without moving the data, which is why that decision is made in the workshop rather than a year in.
What changes
What does a company get once it wires its systems to BigQuery?
You know exactly what reaches the warehouse
For every source we write down the tables, the columns and the loading method, and separately what deliberately stays outside the warehouse. The document stays with you and still answers the question of where a column came from six months later.
A list of sources, tables and columns handed over as documentation, not kept in our heads
Refresh frequency matched to who is looking
Hourly where somebody makes a decision during the day, which usually means the shop and the CRM. Nightly where yesterday's state is enough: ad accounts, invoices, the ERP.
Ad data is refetched for the last few days, because the platforms correct it retroactively
A raw layer nobody overwrites
Records stay in the shape the source handed them over, and metrics are counted on top of them in SQL views. The year on year trend exists even when the source system deleted its history long ago.
Changing the definition of margin is an edit to a view, not another fetch from the sources
The bill counted before the first load
Tables are partitioned by date, so a query reads the days you name rather than the whole history. A daily cap goes on the project, so a mistake ends in a message rather than a line on an invoice.
1 TB of queries and 10 GB of storage a month at no charge under Google Cloud pricing
Data in Europe, access granted per department
The dataset sits in your Google Cloud project, in a European location. Permissions go on the dataset and on the view rather than the whole company, and every query stays in the project log.
The location is chosen once, in the workshop, because changing it later means moving the data
A foundation for a dashboard and for questions in plain sentences
On the views in the warehouse you build a dashboard in Looker Studio or Power BI, and on the same views an AI agent. Both read one formula, so they do not report two different revenues.
The dashboard and the AI agent count a metric from the same SQL view
Proof
Do you keep your own data in a warehouse?
Yes, and that is the only proof we can show without asking a client for permission to publish their numbers. In our founders' agency the warehouse is fed by an AI agent, the same one behind the figures on our AI for business page. Below is the scale of that work, together with what the number does NOT prove.
Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.
JustBottheir agentJustIdea Agency, a performance marketing agency of around 30 people
- 23
- people from the company work with the agent
- 38
- systems wired in permanently
- 112
- processes run without a human
- 475
- thousand lines of the agent’s code
A data warehouse wired to Google Ads, Meta, the CRM, the task system, the SEO tool, Analytics and Search Console. First commit on 1 March 2026, and 23 people use warehouse data today, including people who have never written an SQL query.
8 of 38 systems it works in
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Before
- Data on campaigns, leads and tasks sat in seven systems. Putting it side by side was manual work: export, spreadsheet, glue, and older history existed only in somebody's file.
- After
- The warehouse loads with no person involved, through the same tables every night and every hour. A person comes in where a result has to be interpreted, not where it has to be fetched.
3,506 data warehouse load operations in 30 days, with no person involved
And in your company
What if a warehouse is overkill for us?
Four sentences we hear on BigQuery consultations, and what we answer to each of them. The first one is sometimes right, and when it is, we say so.
If you are after a neighbouring piece, there are separate pages for the automatic data pipeline, for AI data analysis and for API integration.
We do 300 orders a month, BigQuery is a sledgehammer for us.
Often it is, and we will say so in the consultation, before any invoice. When all the company data fits in one spreadsheet, one person looks after it and nobody asks about history older than a year, you get more out of decent reports inside the shop itself and a tidy spreadsheet. We come back to the conversation when a second sales channel appears, or a question about margin per product.
We have Google Sheets and they are enough for us.
A spreadsheet as a data source is fine, and it usually stays as one of the warehouse sources, because it holds the targets and the manual corrections. The trouble starts when it plays the part of the warehouse: a row limit, formulas that take half a minute to recount, no history once something is overwritten, and one person who knows what is in which tab. Raw data then goes to BigQuery, and the spreadsheet stays where it is good, which is manual entry.
We are afraid of a cloud bill we cannot control.
That is why the limits go in before the first load, not after the first invoice. The first terabyte of queries a month and the first 10 GB of storage carry no charge under Google pricing, tables are partitioned by date, a daily cap goes on the project, and older tables drop to a cheaper storage rate on their own after 90 days. After the first month we show you the real volume, so the next decision rests on your number.
Our data cannot leave the EU, and access has to be controlled.
We create the dataset in a European location, for example the EU multi region or the Warsaw region, and BigQuery runs queries in the dataset's location. The warehouse sits in your Google Cloud project, on your billing account, and we get access for the duration of the work. Permissions go on the dataset and on the view, columns with personal data are masked, and the query log stays with you. Duties as controller under <a href="https://eur-lex.europa.eu/eli/reg/2016/679/oj" rel="noopener">Regulation 2016/679</a> stay on your side.
- Sales and shop
- BaseLinker, Allegro, Shopify, WooCommerce, PrestaShop
- CRM
- HubSpot, Pipedrive, Salesforce, LiveSpace
- Ads and analytics
- Google Ads through a data transfer, GA4 through the native export
- Accounting and ERP
- Fakturownia, iFirma, Subiekt, Comarch Optima, sevDesk, Xero
- Spreadsheets and databases
- Google Sheets, Microsoft 365, Google Workspace, SQL databases
- Loading layer
- n8n, Make, Zapier, Cloud Scheduler, Apps Script, custom API integrations
Layers in the warehouse, what sits in them and who has access
A warehouse is not one bucket for data. The split into layers and datasets decides who sees what and what a typical query costs. We settle the access scope in the workshop and write it down as a document, because nobody will reconstruct it from memory six months later.
| Layer or dataset | What sits in it | Who has access |
|---|---|---|
| Raw layer | records in the shape the source gave them, no calculations, partitioned by date | the service account that loads the data and the person who owns it |
| Cleaned layer | unified types, currencies and time zones, duplicates merged on a key | the data owner, the analyst, the supplier for the duration of the work |
| Metric views | revenue, margin and cost per customer counted by one formula | the board and managers, through a dashboard or an AI agent |
| Department view | only the rows and columns of one department or one market | the manager of that department, with no sight of the others |
| Dataset with personal data | contacts, counterparty details, sensitive columns masked | a short named list, agreed in the workshop |
| Archive dataset | tables untouched for 90 days, on a cheaper storage rate | read on request, when a multi year trend is needed |
| Test dataset | a sample with no personal columns, for experiments and training | the whole data team, with no risk to production |
The rows are a starting point. A first rollout usually covers the raw layer, the cleaned layer and the metric views; the department split and the test dataset come in when the team actually asks for them.
How we do it
Five steps from eight systems to one warehouse
Each step ends with something you can judge before you decide on the next one. The first one can end with the conclusion that you do not need a warehouse.
Workshop and source inventory
We write down every system that produces data and every spreadsheet kept next to it. We settle which numbers the board asks about, who glues them together by hand today and how long it takes. At the end we say plainly whether BigQuery is needed, or whether order in what you already have is enough.
Design of the datasets, the access model and the cost
We decide the dataset location, the split into layers, the partitioning and who sees which view. For every source we pick a loading method: a data transfer, the native export, an API or a schedule in n8n. We estimate storage and query volume against the free tier and set a daily cap on the project.
First two sources and agreeing the numbers
We start with sources that have a ready connector, so the first tables sit in the warehouse in the first week. Every table is compared against the number in the source system: the sum of invoices in BigQuery has to match the sum in accounting. A discrepancy is information here, because it shows where the definition of a metric lives in somebody's head.
The rest of the sources, the views and handover
We add the remaining systems without stopping what already runs, and write the metric views agreed in the workshop. We grant access per department, mask personal columns and connect the dashboard or the AI agent. We leave documentation behind: a list of sources, the table schema and a metric dictionary.
Measurement after 30 and 90 days
After 30 days we check whether anybody still exports by hand and which source turned out to be unnecessary. After 90 we look at the bill: what the queries really cost, which tables moved to the cheaper storage rate and what is worth turning into a view so it stops being counted from scratch.
Before and after
How the week changes for the person who answers for the numbers
Before
- Starts the week with three exports and one spreadsheet glued by hand
- Explains to the board why shop revenue disagrees with accounting
- Answers a question about year on year with the news that data that old is gone
- Grants access one person at a time, because nobody wrote down who should see which data
After
- Data from every source sits in the warehouse before anybody opens a laptop
- Revenue, margin and cost per customer are counted from one SQL view
- The multi year trend comes out of the raw layer, because nobody overwrites it
- Access is described per dataset and per department, and a new joiner gets a ready scope
The first tables sit in the warehouse in the first week of work. The full set of sources and views is reviewed after 30 days, and storage and query cost after 90 days, because only then do some tables move to the cheaper rate.
For the person signing this off
What the person who signs off a warehouse gets out of it
You are signing off a project that can be stopped halfway and still stands on something. The warehouse is built in your Google Cloud project and on your billing account, and the source list, the table schema and the views stay with you as documentation. If you change supplier, they take over a working warehouse rather than a tool of ours that only works with us attached.
The second thing counts in a budget conversation. Cloud cost here is not a subscription but a bill against volume, whose ceiling you set yourselves: the free tier at the start, partitions by date and a daily cap on the project. After the first month we show you the real query and storage volume, so the next decision rests on your own number rather than on our estimate.
- The warehouse in your Google Cloud project and on your billing account
- A source list, a table schema and a metric dictionary handed over as documentation
- The free tier, date partitions and a daily cap set before the first load
- The dataset located in Europe, access described per dataset and per department
What it costs
The workshop has a published price, the rollout is quoted after it
The process workshop costs EUR 3,500 net per week. On a warehouse one week is usually enough: the source list, the layer design, the dataset location and the access model. We quote the rollout after the workshop, because the cost depends on how many sources come in and whether they have APIs, not on the number of tables.
For BigQuery itself you pay Google directly, with no commission from us, and you pay against volume. The first terabyte of queries a month and the first 10 GB of storage carry no charge under Google pricing, and a B2B company with a few sources usually stays inside that tier for a long time. Costs for the loading tools, if any come in at all, you pay to their vendors on the same terms. Where the AI agent is in scope, model queries cost the vendor EUR 0.005 to 0.07 each.
Process workshop
EUR 3,500 net
per week, on a warehouse usually one week
A self-contained piece of work. It ends with a source list, a design of the datasets and layers, and an answer on whether BigQuery is needed here at all. You can execute the plan without us.
- A source inventory: what produces data and who glues it together by hand today
- A design of the datasets, the raw layer and the metric views
- The choice of location, the per department access model and the cost limits
- An estimate of storage and queries against the free tier
- An answer on whether a warehouse is needed, or order in a spreadsheet is enough
- Most popular
Workshop and BigQuery rollout
Quoted after the workshop
scope follows from the number of sources and whether they have APIs
The option most companies choose. A working warehouse within 2 to 6 weeks of the workshop, fed by your systems, with numbers reconciled against the source.
- Everything in the workshop
- Datasets and a raw layer in a European region, partitioned by date
- Connectors to 2 to 4 sources, refetching the days that get corrected
- Metric views and a reconciliation test against the number in the source system
- Per department access, masking of personal columns, a daily cap on the project
- Documentation: a source list, a table schema and a metric dictionary
Warehouse and an AI agent
Quoted after the workshop
for companies that ask about numbers several times a day
Everything in the BigQuery rollout plus BOND, our company AI agent, which answers questions from the views in the warehouse.
- Everything in the BigQuery rollout
- BOND wired to the warehouse, an answer from company data in 5 to 10 seconds
- A read only service account, limited to the views you name
- A BOND rollout of around 2 months, in stages, measured after 30 and 90 days
If the workshop shows that your data fits in one spreadsheet and one person looks after it, we say so plainly and we do not sell you a warehouse. What you get then is a source list and a plan for order in what you already have: a document that stands without us and that you can hand to your own team or to another supplier.
Frequently asked questions
What is a BigQuery integration?
It is the wiring of Google's data warehouse to the systems you already run, so that data reaches it on its own. We settle what comes in from each source, how often and in what shape, create the datasets and the raw layer in a European region, and on top of them the views a dashboard or an AI agent reads. BigQuery is serverless, so there is no database to administer and no backups to watch.
What reaches the warehouse and where from?
Most often orders and returns from the shop or from BaseLinker, deals and stages from the CRM, cost and conversions from the ad accounts, invoices and cost of goods from accounting, events from GA4, and spreadsheets with targets and manual corrections. Only the tables and columns needed for the agreed metrics go into the raw layer. What stays outside the warehouse we write down as carefully as what goes into it.
How often does the data refresh?
Hourly where somebody makes a decision during the day, which usually means the shop and the CRM. Nightly where yesterday's state is enough: ad accounts, invoices, the ERP. Ad data is refetched for the last few days, because the platforms correct it retroactively. The frequency is settled in the workshop, because every extra refresh means more queries and more money on the bill.
What does BigQuery cost at our scale?
You pay Google against volume: for the data your queries process and for storage. Under Google pricing the first terabyte of queries a month and the first 10 GB of storage carry no charge, and a table untouched for 90 days drops to a storage rate half as high. A B2B company with a CRM, a shop and ad accounts counts its data in gigabytes, so it usually stays inside the free tier; on top of that we set a daily cap on the project.
How is the raw layer different from the prepared one?
The raw layer keeps records in the shape the source handed them over, with no calculations and no overwriting. The prepared layer is SQL views, where revenue, margin or cost per customer are counted by one formula for the whole company. The split has a practical effect: changing a metric definition is an edit to a view, not another fetch of data out of every system.
Does our data stay in Europe and who has access to it?
We create the dataset in a European location, for example the EU multi region or the Warsaw region, and BigQuery runs queries in the dataset's location. That location cannot be changed later without moving the data, so the decision is made in the workshop. Access is granted on the dataset and on the view, columns with personal data are masked, and every query stays in your project's log.
When is BigQuery overkill?
When all the company data fits in one spreadsheet, one person looks after it and nobody asks about history older than a year. A small shop with a few hundred orders a month gets more out of decent reports inside the shop itself than out of a warehouse somebody then has to maintain. We say this in the free consultation, before anybody pays for a workshop.
How long does it take to wire BigQuery to our systems?
A week of workshop, then 2 to 6 weeks, depending on the number of sources and whether they have APIs. The first tables sit in the warehouse in the first week of work, because we start with a source that has a ready connector. The longest part is not the wiring but agreeing the metric definitions, and that is work on your side which no tool can speed up.
Let us check whether your data needs a warehouse
The free consultation takes 30 minutes. You tell us how many systems your data sits in today, who glues it together by hand and which numbers the board asks about. We will say plainly whether the first step is BigQuery or order in what you already have. You do not have to give us access to any system at this stage.
We run at most two rollouts at a time, so that someone is actually sitting on each of them.
Book a free consultationPS. If somebody at your company assembled a report out of three exports this week, that is exactly this problem. A warehouse will not count anything for you, but it does mean data from every system sits in one place, in Europe, with a history nobody overwrites. That is where the workshop starts.