Plausible to BigQuery: How to Move Your Data

Moving Plausible into BigQuery lets you join web analytics to everything Plausible cannot see: signups, revenue, support tickets, product usage. That is the reason to build this, and it comes with a caveat that Airbyte's own documentation states plainly rather than burying.

Plausible is a privacy-first analytics service, and the data available from its API is intentionally less granular and less comprehensive than what Google Analytics offers. That is a design choice rather than a connector shortcoming, and it decides what you can and cannot model once the data lands. This guide covers the managed path with Airbyte and what those limits mean in practice.

Plausible to BigQuery at a glance:

Why move data from Plausible to BigQuery?

Two situations account for most of these pipelines.

The first is connecting traffic to outcomes. Plausible tells you which pages and sources brought visitors. Your own systems know which of those visitors signed up and what they were worth. Neither answers the question about acquisition cost per customer, and a warehouse holding both does.

The second is history across sites. If you run several domains, Plausible shows each separately, and a warehouse lets you compare and combine them. If you only need traffic numbers for one site, the Plausible dashboard already does that well and this pipeline adds machinery for nothing.

What do you need before you start?

A short list, and one expectation that matters more than any of the settings:

A Plausible API key. Generated from your Plausible account settings. The Plausible source documentation links to Plausible's own guide for creating one.

Your site ID, in the right form. This is the domain of the site as configured in Plausible, entered without the scheme and without www. It is the domain field in your Plausible site settings, and getting the format wrong is the most common setup mistake here.

The right API URL if you self-host. The connector defaults to Plausible's hosted stats endpoint, and a self-hosted instance needs its own URL supplied instead.

Realistic expectations about granularity. Daily aggregates rather than sessions or individual pageviews. If your plan involves rebuilding session-level journeys or user-level attribution, that is not available from this API and it is far better to know before you scope the project.

On the BigQuery side you need a project, a dataset and a service account with the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match the datasets holding your signup and revenue data, since it cannot be changed after creation.

How do you build a Plausible to BigQuery pipeline in Airbyte?

Step 1: Decide what you need grouped by

Because non-metric properties can only be grouped on rather than exported, the questions you want to answer determine what you can retrieve. Write down the breakdowns your team actually uses, by source, by page, by country, and confirm each is available as a grouping. That check takes ten minutes and prevents a project scoped around data the API does not expose.

Step 2: Configure the Plausible source

Click Sources in the left navigation, then New Source, and select Plausible, following adding a source. Supply the API key, the site ID as a bare domain, the API URL if you self-host, and a start date in ISO-8601 format. Repeat once per site, naming each source clearly so a workspace with several domains stays manageable.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project, dataset and service account key. Batched standard inserts is the default and is more than adequate, because daily aggregates for a website are tiny by warehouse standards even across several sites and several years.

Step 4: Create the connection and schedule daily

Click Connections, then New connection, select your streams and a sync mode. Daily matches the grain of the data, so syncing more often mostly re-reads the same aggregates. If you run several sites, consider a shared dataset with the site as a column, which makes cross-site comparison a single query rather than a union.

After the first sync, compare a few days against the Plausible dashboard. Aggregated data is easy to misread, and confirming the numbers agree once saves an awkward conversation when somebody notices a discrepancy later.

What does privacy-first mean for your data?

Two concrete limits, both intentional. When retrieving multi-day data, metrics are aggregated to a daily grain. And non-metric properties such as referrer, entry page and exit page cannot be directly exported, only grouped on.

The first means you cannot analyse traffic by hour of day from a multi-day pull, and you have no session or visitor-level records at all. The second is subtler and more consequential: you can ask for pageviews grouped by referrer, and you cannot get a table of pageviews with a referrer column that you then aggregate yourself. The grouping happens at the source rather than in your warehouse.

That inverts the usual warehouse pattern, where you land detail and aggregate downstream. Here you land aggregates, which means each new breakdown someone asks for is a source configuration question rather than a SQL question. Worth explaining to analysts up front, because it is not how they will expect the data to behave.

How do you join daily aggregates to your own data?

By date, and by whatever dimension you grouped on. That is a genuine constraint on the analysis: you cannot follow an individual visitor from a referrer to a signup, because there is no visitor identifier to follow. What you can do is compare daily traffic by source against daily signups by source and look at the relationship.

For many teams that is entirely sufficient, and it is worth saying so rather than treating it as a compromise. Knowing that organic traffic doubled in the month conversions rose is often the actual question, and it does not require tracking individuals. It is also, of course, the point of choosing Plausible in the first place.

Where you do need user-level attribution, that has to come from your own application capturing a source at signup rather than from this pipeline. Establish that before the project starts, because it is an engineering task in your product rather than something to configure in Airbyte.

Frequently asked questions

Can I get hourly or session-level data?

No. When retrieving multi-day data, metrics are aggregated to a daily grain, and there are no session or visitor-level records. This is intentional in Plausible's privacy-first design.

Why can I not export referrer or entry page as a column?

Non-metric properties cannot be directly exported, only grouped on. You request metrics grouped by referrer rather than receiving a detail table you aggregate yourself.

How do I enter the site ID?

As the bare domain configured in Plausible, excluding the scheme and www. It is the domain field in your Plausible site settings.

Does this work with self-hosted Plausible?

Yes. Change the API URL from the hosted default to your own instance's stats endpoint.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views joining the daily aggregates to your own daily figures, which is short SQL.

Get your Plausible data into BigQuery

Confirm the breakdowns you need are available as groupings, enter the site ID as a bare domain, create one source per site, and schedule daily to match the grain. Then set expectations with your analysts, because landing aggregates rather than detail is not how they will expect a warehouse pipeline to behave.

Airbyte's connector catalog includes 600+ pre-built connectors, so web analytics can sit beside product and revenue sources. For a product analytics source with event-level detail, see PostHog to BigQuery, and for marketing attribution on the same visitors, Adjust to BigQuery.

Start syncing now →