Pendo to BigQuery: How to Move Your Data

Moving Pendo into BigQuery puts your product analytics configuration somewhere you can query it alongside everything else. Which features exist, who your visitors are and which accounts they belong to become joinable to revenue and support data, which Pendo itself has never seen.

This guide covers the managed path with Airbyte. Two things shape the build, and the first decides whether this project is what anybody expected: the aggregation endpoint is not supported, so the event data is out of scope. The second is that every sync reads everything.

Pendo to BigQuery at a glance:

Why move data from Pendo to BigQuery?

Two situations account for most of these pipelines.

The first is joining your product's users to your commercial data. A visitor and the account they belong to mean rather more when set against contract value, renewal date and support volume, and that join can only happen somewhere both datasets exist.

The second is governing the product analytics estate itself, since tagged features and pages accumulate and nobody can say which are still meaningful. Be clear about the limit: this does not deliver the clickstream. If event-level analysis is the requirement, Posthog to BigQuery shows what an event pipeline actually looks like, and Pendo's events need a different route entirely.

What do you need before you start?

Four things, and the first is a scoping conversation rather than a credential:

Agreement about what this covers. The aggregation endpoint is outside the connector, which puts event data outside this pipeline. The Pendo source documentation states this plainly, and it is worth reading aloud to whoever commissioned the work.

An integration key from a Pendo admin. Created under Integrations, then Integration Keys. Leave the write access box unticked, since this pipeline only reads and a read-write key is an unnecessary risk.

A BigQuery dataset in the right location. Location is fixed at creation and BigQuery will not join across locations, so this belongs wherever your revenue and support data already sit.

A decision about keeping history. Because syncs are full refresh only, whether these tables show current state or accumulate a record over time is something you choose rather than something the pipeline provides.

If your network restricts traffic by IP, add the Airbyte Cloud IP addresses to the relevant allow list before you begin.

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

Step 1: Establish what nobody is getting

Ask what questions this data is meant to answer, then check them against a connector that does not reach the aggregation endpoint. Questions about which features exist, who visitors are and how accounts are structured are well served. Questions about how often a feature was clicked last month are not, and the difference between those two lists is the difference between a useful project and a disappointing one.

Step 2: Configure the Pendo source

Click Sources in the left navigation, then New Source, and select Pendo, following adding a source. Supply the integration key, which is essentially the whole configuration. Select the streams describing your product structure and your audience, since those are what the v1 endpoints expose.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project identifier, dataset and service account credentials. Volumes here are modest, so batched standard inserts are ample and Cloud Storage staging is unnecessary.

Step 4: Create the connection and choose the refresh variant

Click Connections, then New connection, select your streams and a sync mode. Only full refresh is available, so the real choice is between overwrite, which keeps a current picture, and append, which accumulates one complete copy per sync. Daily is generous for a configuration estate.

Then build the views, because the raw tables are either a snapshot or a pile of snapshots and neither is what anybody wants to query.

What does this connector actually reach?

The v1 endpoints describing your product analytics setup and audience, and not the aggregation endpoint. That single exclusion is the most important thing to know here, because Pendo's event data lives behind aggregation, and aggregation is where anybody asking about feature usage expects to go.

So what you receive describes structure rather than behaviour. Tagged features and pages, the guides you show, your visitors and the accounts grouping them: all present, all useful, none of it telling you what anybody did. A product manager asking for Pendo data in the warehouse almost always means usage, and handing over definitions instead is the disappointing version of this project.

Taken for what it is, it answers real questions. Which tagged features have accumulated over three years and whether anybody still maintains them, how visitors map to accounts, which guides exist and where. Joined to commercial data it supports genuinely useful analysis about who your users are, and it does that without pretending to be a clickstream.

How do you turn repeated snapshots into history?

By appending, and then by partitioning sensibly. Every sync reads everything because the list endpoints offer no server-side timestamp filter to read from, which means the connector has nothing to be incremental against. Full refresh overwrite therefore gives you a table that is permanently current and permanently without memory.

Full refresh append builds the record instead, adding a complete copy of your features, pages, guides and visitors on every run. Because tables arrive partitioned on the extraction timestamp, those copies become dated observations rather than an undifferentiated pile, and BigQuery gives you that structure without anybody designing it.

Build two views over that. One selecting the most recent extraction, which is the current picture most reporting wants. One over the full history, which answers when a feature was first tagged, when a visitor's metadata changed and how the estate has grown. Have both filter on the partitioning column, since BigQuery bills on bytes scanned and a query ignoring it reads every snapshot you have ever taken.

Frequently asked questions

Can I get feature usage counts?

Not through this connector, since the aggregation endpoint is not supported and that is where Pendo's event data lives. Establish this before scoping any usage analysis.

Why is there no incremental sync?

The connector supports full refresh only, and the list endpoints offer no server-side timestamp filter for it to read from. Choose between overwrite and append accordingly.

Who can create the integration key?

A Pendo admin, under Integrations then Integration Keys. Leave the write access option unticked, since this pipeline only reads.

How do I see when a feature was first tagged?

From appended snapshots, using the extraction timestamp partitioning to find the earliest run in which it appeared. Overwrite discards exactly that.

Can I do this without writing code?

The pipeline, yes, and it is a short setup. The two views over an appended table are modest SQL and they are what makes the data answerable.

Get your Pendo data into BigQuery

Establish first that this covers product structure and audience rather than events, because the aggregation endpoint is outside the connector and that is where usage lives. Get a read-only integration key from an admin. Then choose append over overwrite, use the extraction timestamp partitioning to turn snapshots into dated observations, and expose both a current view and a historical one while filtering on that partition column.

Airbyte's connector catalog includes 600+ pre-built connectors, so product data can sit beside the commercial data that explains it. For product analytics events into the same destination, see Amplitude to BigQuery, and for another analytics platform into the same destination, Mixpanel to BigQuery.

Start syncing now →