Facebook Pages to BigQuery: How to Move Your Data

Moving Facebook Pages into BigQuery gives you organic social performance somewhere it can sit beside everything else you measure. Meta's own insights are decent for a glance and unhelpful for the questions that matter, because they cover one page, one window at a time, and cannot be joined to web traffic, revenue or the campaigns running alongside them.

This guide covers the managed path with Airbyte. Two things shape the build: the token you use decides whether this works at all, and you get a fixed set of insight metrics rather than a menu to choose from.

Facebook Pages to BigQuery at a glance:

Why move data from Facebook Pages to BigQuery?

Two situations account for most of these pipelines.

The first is attribution across channels. Organic social is usually measured in its own silo and credited or blamed accordingly, and the only way to see whether it contributes anything is to put post performance beside web sessions, sign-ups and revenue. That join has to happen in a warehouse because no social platform will ever do it for you.

The second is history, since platform interfaces are built around recent windows and questions about last year are awkward to ask there. One thing to be clear about: this connector covers organic page activity, not advertising. If what you actually want is campaign spend and paid performance, Facebook Marketing to BigQuery is the connector for that, and the two are easy to confuse by name.

What do you need before you start?

Four things, and the first is where most attempts stall:

A long-lived Page access token. Not a short-lived one, and not a casually generated app token, for reasons covered below. A long-lived User token capable of generating a Page token for your page also works. The Facebook Pages source documentation walks through obtaining one.

Your Page ID, and one source per page. The identifier is the portion of your page URL after the domain. A brand running separate pages by market or product line needs a source for each, so count them now rather than building one and inheriting the rest later.

An OAuth app with the right permissions. Meta requires specific permissions for page data, and the sensible principle is requesting the fewest that let the connector work. Missing ones produce errors against particular page fields rather than a clean failure at setup.

A BigQuery dataset in the right location. Location is set at creation and cannot be changed afterwards, and BigQuery will not join across locations. Put this where your web analytics and revenue data already sit, since joining to them is the entire point.

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 Facebook Pages to BigQuery pipeline in Airbyte?

Step 1: Get the token right before anything else

This is the step that decides whether the pipeline is viable, and it is worth the half hour. Generate a long-lived Page access token rather than accepting whatever a Facebook App hands you by default, because the default is throttled to the point of uselessness for scheduled syncs. Test it against the Graph API directly before configuring anything in Airbyte, so a failure later is clearly about configuration rather than credentials.

Step 2: Configure the Facebook Pages source

Click Sources in the left navigation, then New Source, and select Facebook Pages, following adding a source. Supply the Page access token and Page ID. Leave Page Size at its default of 100 for now, and remember it exists: lowering it is the fix when Meta responds that you are asking for too much data at once.

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 by warehouse standards, so batched standard inserts are ample and Cloud Storage staging is unnecessary unless you are consolidating a great many pages.

Step 4: Create the connection and separate the pages

Click Connections, then New connection, select your streams and a sync mode. If you are running several pages, give each its own connection and make sure the page is identifiable in the destination, because a table blending three markets with no column distinguishing them is a problem you only notice once somebody reports a number.

Daily is plenty for organic social. Tables arrive partitioned on the extraction timestamp, so filter on that column as well as on post dates or your queries will read everything you have ever collected.

Why does the wrong token make this unusable?

Because Meta throttles tokens generated from Facebook Apps heavily by default, to the point where using one for scheduled syncs is not practical. The pipeline is not broken and the credentials are not wrong; the requests simply cannot proceed at any useful rate, which presents as a sync that crawls or stalls rather than one that fails with a helpful message.

A long-lived Page access token is the route that works. You can also supply a long-lived User token with the ability to generate a Page token for the configured page, which suits setups where the user account is the durable thing and page access is managed through it. Either way the word that matters is long-lived, since a short-lived token will strand the pipeline within hours.

Permissions are the related trap. Meta expects specific permissions for page data, and a missing one surfaces as an error on particular fields rather than as a clear refusal, so a mostly-working sync with a couple of unexplained gaps is usually a permissions question. Request the minimum that works, and record which permissions you granted, because the next person to debug this will otherwise start from nothing.

What exactly lands in BigQuery?

Page and post records with the fields the catalogue offers, plus insights drawn from a fixed set of metrics the connector requests. That last part is worth dwelling on: you are not choosing which insight metrics to collect. The connector asks Meta for a defined list, and what arrives is that list, so a metric you rely on inside the Meta interface may simply not be present.

Check for the handful of metrics your reporting actually uses before anybody rebuilds a dashboard on this data. It is far better to discover a gap during a test sync than after a team has been promised a like-for-like replacement of something they read every Monday. Fields also change over time, and one example is the product catalogues field on the page stream, which stopped being populated in a recent version because page tokens cannot see business-owned catalogues.

In BigQuery, treat this as a source to model rather than to query directly. Build a view exposing the metrics people recognise under names they use, with the page identified explicitly, and point reporting at that. Tables are partitioned daily on the extraction timestamp, so your view should filter on the latest extraction per reporting period rather than letting every dashboard scan the full history and bill you for it.

Frequently asked questions

Does this include advertising data?

No, this is organic page activity. Paid campaigns, spend and ad performance come from the Facebook Marketing connector, which is a different source despite the similar name.

Why is my sync impossibly slow?

Most likely the token. Tokens generated from Facebook Apps are throttled heavily by default, so use a long-lived Page access token instead of whatever an app produced.

Meta says I am requesting too much data. What do I change?

Lower the Page Size setting, which defaults to 100 and governs records per request for the post and post insights streams. Any value from 1 to 100 is valid.

Can I choose which insight metrics to sync?

No. The connector requests a fixed set of page and post insight metrics, so confirm the ones your reporting depends on are among them before committing to this as a replacement.

Can I do this without writing code?

Yes for the pipeline, though obtaining a long-lived token involves some fiddling in Meta's tooling. A view in BigQuery to tidy metric names and identify the page is worth writing once.

Get your Facebook Pages data into BigQuery

Spend the time on the token, because an app-generated one is throttled past usefulness and the symptom is slowness rather than a clear error. Check the fixed insight metrics against what your reporting actually needs before promising anyone a replacement. Create the dataset where your web and revenue data already live, identify the page explicitly when running more than one, and filter on the partitioning column so the bill stays sensible.

Airbyte's connector catalog includes 600+ pre-built connectors, so organic social can be measured alongside every other channel. For the other Meta organic surface into the same destination, see Instagram to BigQuery, and for comparable page analytics elsewhere, LinkedIn Pages to BigQuery.

Start syncing now →