Yandex Metrica to BigQuery: How to Move Your Data

Moving Yandex Metrica into BigQuery gives you web analytics you can join to everything else. Metrica reports capably on its own traffic and knows nothing about what those visitors bought, cost to acquire or went on to do, which is where a warehouse earns its place.

This guide covers the managed path with Airbyte. Two things shape the build: the connector offers two streams and both are raw rather than summarised, and that means the figures you produce will not match the Metrica interface unless you make them.

Yandex Metrica to BigQuery at a glance:

Why move data from Yandex Metrica to BigQuery?

Two situations account for most of these pipelines.

The first is joining traffic to outcomes. Whether a campaign produced customers rather than visits, and what those customers were worth, needs web activity beside order and revenue data that Metrica has never seen.

The second is keeping history and defining your own measures rather than accepting somebody else's. Volumes on a busy site are substantial, so if interactive speed over years of hits matters more than joins and governance, a column store suits that better than a warehouse.

What do you need before you start?

Four things, and the first takes longer than the rest combined:

An OAuth token, obtained by hand. You register an application with Yandex, request Metrica access, and collect a token from the redirect rather than clicking authorise in Airbyte. The Yandex Metrica source documentation walks through the sequence.

Your counter identifier, and one source per counter. A counter covers one site, so a business running several properties needs a source for each and a view to bring them together.

A BigQuery dataset in the right location. Location is fixed at creation and BigQuery will not join across locations, so put this where your order and marketing data already live.

Agreement about what your metrics will mean. Nothing arrives pre-aggregated, so bounce rate and session duration are definitions somebody in your organisation writes rather than numbers you receive.

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 Yandex Metrica to BigQuery pipeline in Airbyte?

Step 1: Get the token, and write down when it expires

Register the application, grant it Metrica access and capture the token from the redirect, then record where it came from and when it will need renewing. Tokens issued this way have a finite life, and the person who has to replace one in a year will not be the person who created it. A note beside the connection costs nothing and prevents a mystery.

Step 2: Configure the Yandex Metrica source

Click Sources in the left navigation, then New Source, and select Yandex Metrica, following adding a source. Supply the authentication token, counter identifier and a start date. Name the source after the site rather than the counter number, which nobody will recognise later.

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. Hit-level data from a busy site is one of the cases where Cloud Storage staging is worth considering over batched inserts.

Step 4: Create the connection and check a single day

Click Connections, then New connection, select your streams and a sync mode. Daily is right for web analytics. Then count sessions for one settled day and compare it to Metrica, expecting a difference and understanding why before anybody else notices it.

Have reporting read views that filter on the extraction timestamp partition, since BigQuery bills on bytes scanned and these tables grow quickly.

What do two streams actually give you?

Raw activity, which is both less and more than people expect. Views and sessions describe what happened on your site at the level of individual page views and visits, rather than the prepared reports the Metrica interface shows. There is no table of traffic sources by week waiting for you.

That is the more valuable arrangement for a warehouse, because raw events can be aggregated any way you like and a prepared report cannot be taken apart. It also means the work moves to you: every summary somebody wants is a query you write rather than a column you select.

Two practical consequences follow. Volumes are larger than a reporting export would be, so size your expectations to hits rather than to summaries. And the counter identifier scopes a source to one site, so a business with several properties ends up with a source each and wants a union view naming the site before anybody tries to compare them.

Why will your numbers not match the interface?

Because Metrica's figures are computed with Metrica's definitions and yours will be computed with yours. A session has a timeout rule, a bounce has a threshold, a visitor has an identity that persists in a particular way, and none of those rules travels with raw view and session records.

So an analyst computing sessions from the raw stream will produce a number close to but not identical with the dashboard, and somebody will ask which is right. The answer is that both are, for different definitions, which is an unsatisfying thing to say in a meeting and much easier to say in advance than afterwards.

Decide early which is authoritative for which question. Metrica's own figures are right when you want to match what the marketing team sees in the tool; your derivation is right when you need definitions consistent with how the rest of the business counts things. Write both down beside the tables, and build your measures in views so the rules live in one place rather than in each analyst's query.

Frequently asked questions

Which streams are available?

Views and sessions, both describing raw activity. Prepared reports like traffic sources by week are not among them, so you aggregate those yourself.

Why do my sessions differ from the Metrica dashboard?

Metrica applies its own session and bounce rules, and your query applies yours. Agree which is authoritative for which question rather than trying to reconcile them.

Can one source cover several sites?

No. A counter identifier covers one site, so several properties need several sources and a union view naming each one.

The pipeline stopped authenticating.

Tokens obtained through this flow expire, so check the token first. Recording its issue date when you set the source up makes this an easy diagnosis.

Can I do this without writing code?

The pipeline, yes, though obtaining the token means calling an endpoint yourself. The views defining your metrics are SQL and they are most of the value.

Get your Yandex Metrica data into BigQuery

Obtain the OAuth token by hand and record when it will need renewing, since that is the step people forget and the failure it causes is opaque. Expect one source per counter and raw activity rather than reports. Then agree what your metrics mean before anybody computes one, because your numbers will differ from the Metrica interface and both will be defensible.

Airbyte's connector catalog includes 600+ pre-built connectors, so web behaviour can be measured against what it was worth. For product analytics into the same destination, see Amplitude to BigQuery, and for another analytics platform into the same destination, Mixpanel to BigQuery.

Start syncing now →