Every Monday morning in a lot of small ecommerce businesses, someone exports three CSVs. Orders from Shopify. Sends and opens from Klaviyo. Spend from the ads account. Then they spend an hour in a spreadsheet trying to work out why the three files disagree about how many customers exist. That hour is not analysis. It is plumbing, done by hand, by a person who was hired to do marketing.
On 8 August Google added connectors for Shopify, Klaviyo, HubSpot and Mailchimp to BigQuery Data Transfer Service, all in preview, alongside Microsoft SQL Server. PostgreSQL, MySQL and Snowflake moved to general availability. The Shopify connector pulls order histories, inventory logs and customer profiles. Klaviyo pulls email and SMS engagement logs including sends, clicks and opens. HubSpot syncs pipeline and contact tracking. Mailchimp brings campaign performance and audience list attributes.
Stated plainly: the Monday morning CSV job is now a configuration screen.
The part that actually changes the maths
Marketing teams have been able to warehouse their data for years. What stopped most small teams was not capability, it was the standing cost of a third-party pipeline tool sitting between the platforms and the warehouse, priced per row or per connector, on top of a warehouse bill.
Google’s pricing removes one side of that. Ingestion from first-party Google sources is free, which covers Google Ads, Google Analytics 4, Campaign Manager, YouTube and Cloud Storage, with Google Play the exception. Amazon S3, Azure Blob Storage, Redshift and Teradata are also free to ingest. The new third-party connectors run on consumption pricing rather than row counts, with compute in major regions quoted at under six cents per slot-hour. Google also quotes a monthly uptime target at or above 99.99%, though that figure describes the service rather than the preview connectors specifically.
For a twelve-person direct-to-consumer brand, that is the difference between a data project needing a budget line and a data project needing an afternoon. Ad spend and site behaviour arrive free. Orders and email engagement arrive cheaply. Everything lands in one place with the same customer identifiers available to join on.
Getting the data in is the easy half
This is where these announcements usually oversell themselves, so it is worth being blunt. Loading four sources into a warehouse does not produce an answer. It produces four tables that still disagree with each other, now in SQL instead of Excel.
The work that remains is identity. Klaviyo knows a person by email. Shopify knows them by customer ID, and by a different one if they checked out as a guest. HubSpot has a contact record that may or may not match either. Somebody has to decide which identifier is authoritative and write the logic that stitches them, and that decision is a business judgement, not a technical one. Nothing in this release makes it for you.
Then someone has to write the queries. If nobody on the team can write SQL, a warehouse full of clean data is an expensive filing cabinet. The honest version of the plan includes either a person who can query it or a reporting layer on top, and both cost something.
What can go wrong
Preview status is the first thing to respect. Preview connectors can change schema, behave inconsistently, or be withdrawn. Do not build the report your board reads on a preview connector, and do not switch off the existing process until you have run both side by side for a full month and reconciled the difference.
Cost surprises are the second. Consumption pricing is cheap when volumes are modest and stops being cheap when someone schedules a full historical resync every hour because incremental transfers looked complicated. Set the schedule deliberately, check the first month’s bill against expectations, and set a budget alert before you set anything else.
The third is the one that gets people in real trouble. A Shopify customer profile and a Klaviyo engagement log contain personal data. Moving them into a warehouse creates a new copy in a new place, and your retention policy, deletion process and data map all need to know it exists. If a customer asks to be deleted, the request has to reach BigQuery too. Deciding that afterwards is much harder than deciding it now.
And a quieter one: a warehouse does not solve attribution. It gives you the raw material to build a view. The interpretation problems do not go away, in the same way that a new metric appearing in Search Console does not tell you what it means.
When to leave this alone
If your business runs almost entirely inside one platform, the native reporting is usually enough and this is a solution looking for a problem. A Shopify store doing most of its revenue through Shopify’s own checkout, with email as a supporting channel, can answer nearly every useful question without a warehouse. The case gets strong when you have three or more systems that each hold part of the customer, when the same question gets a different answer depending on who you ask, or when someone is spending a recurring half-day per week on exports.
The signal worth watching in this release is not the connector list. It is that ingestion is being priced towards zero while the value moves up the stack, into modelling, into the agent layer, and into whoever can ask the warehouse a sensible question. Getting your data in is becoming a commodity. Knowing what to ask it is not, and that is where a small team should be spending its next hour.
Editor’s note: This area changes quickly, so check the latest platform policy before making compliance decisions.