Google Workspace Admin to BigQuery: How to Move Your Data

Moving Google Workspace Admin Reports into BigQuery gives you a queryable record of what happens across your domain: who signed in from where, which applications people actually use, what administrators changed. The admin console shows recent activity through a filter interface, which is fine for looking something up and useless for analysis.

This guide covers the managed path with Airbyte. The prerequisite is unusually consequential, because this connector needs a service account with domain-wide delegated authority, and only a super administrator can grant that.

Google Workspace Admin Reports to BigQuery at a glance:

Why move data from Google Workspace Admin Reports to BigQuery?

Two situations account for most of these pipelines.

The first is retention for audit and compliance. Google keeps report data for a defined period that varies by report type and edition, and questions from an auditor routinely reach further back than that. A warehouse accumulating the reports answers them once the console no longer can.

The second is licence and adoption analysis. Usage reports tell you which applications people genuinely use, and joining that to your HR data by department or location turns a vague sense that nobody uses a product into a number you can act on at renewal.

What do you need before you start?

The first item needs a specific person with a specific role, so start it before anything else:

A super administrator willing to set up delegation. The service account must be created by an administrator of the Google Workspace, and enabling delegated domain-wide authority is restricted to a super administrator. That person is on your project whether they expected to be or not.

A service account with JSON credentials. Created following Google's process for delegating domain-wide authority. At the end of it you have a JSON key, which is what Airbyte needs. The Google Workspace Admin Reports source documentation links to Google's instructions.

Exactly two scopes, both read-only. One for reports audit and one for reports usage, each explicitly read-only. Grant those and nothing more, and say so when you ask, because it makes the request considerably easier to approve.

The email address of the admin who created the service account. This is a required configuration field rather than an optional one, because the service account acts on behalf of that administrator when it calls the API.

On the BigQuery side you need a project, a dataset and a service account with the BigQuery User and BigQuery Data Editor roles. Use a dataset dedicated to this source, because it will need its own access controls.

How do you build a Workspace Admin Reports to BigQuery pipeline in Airbyte?

Step 1: Make the delegation request properly

Go to your super administrator with the two scope names written down, an explanation of what the pipeline is for, and where the data will land. Domain-wide delegation is a capability people are rightly cautious about, and a request naming exactly two read-only scopes is a very different conversation from one asking for delegation in the abstract.

Step 2: Configure the source

Click Sources in the left navigation, then New Source, and select Google Workspace Admin Reports, following adding a source. Paste the JSON credentials and supply the administrator's email address. A connection failure here is usually the delegation step rather than the key, so check that the client identifier was authorised with both scopes in the admin console.

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. Set the dataset location to match your HR or identity datasets if you intend to join against them, since that cannot be changed after creation.

Step 4: Create the connection and sync ahead of retention

Click Connections, then New connection, select the reports you need and a sync mode. Daily is comfortable, and the thing to check is that your schedule stays well inside Google's retention for the report types you care about, because those windows differ.

The connector attempts to back off gracefully when it hits the Reports API's rate limits, so a slow sync on a large domain is expected behaviour rather than a fault.

What are you actually asking for with delegation?

Worth understanding properly, because you will be asked. Domain-wide delegation lets a service account act across your organisation's Workspace environment by impersonating users, without each of those users approving anything. It is powerful by design, which is why only a super administrator can enable it.

The reassuring part is that the capability is bounded by the scopes authorised alongside it. Here those are reports audit read-only and reports usage read-only, so the service account can read reports and nothing else. It cannot read mail, files or calendars unless somebody authorises those scopes too.

So the honest framing when you ask is that the mechanism is broad and the grant is narrow. Name the two scopes, explain that they are read-only, and record the decision somewhere your security team can find it later, because a delegated service account with no written justification is exactly what an access review will flag.

How should you treat the data once it lands?

As personal data, because it is. These reports describe named employees: when they signed in, from where, which applications they opened, what they did. That is legitimate to hold for security and licensing purposes, and it is also the kind of dataset that makes people uncomfortable if it appears in a general analytics environment.

Two measures cover most of it. Keep it in its own dataset with its own grants, so access is a deliberate decision rather than a side effect of having warehouse access. And set a retention period that reflects what your organisation has committed to, rather than accumulating indefinitely because storage is cheap.

It is also worth asking whether your analysis needs individuals at all. Licence and adoption questions work perfectly well on counts by department, so an aggregated view with the detailed tables locked down answers them without putting individual activity in front of everyone with a dashboard.

Frequently asked questions

Who can set this connector up?

The service account must be created by a Google Workspace administrator, and enabling delegated domain-wide authority requires a super administrator. Plan for that person's involvement from the start.

Which scopes does it need?

Two, both read-only: reports audit and reports usage. Nothing broader is required, and naming them precisely makes the approval conversation much easier.

Why does it need an admin email address?

It is a required field, because the service account acts on behalf of the administrator who created it when calling the API. Supply the address of that account.

Can I backfill older activity?

Only as far back as Google retains the reports, which varies by report type and edition. Beyond that, your warehouse history starts when the pipeline does, so set it up before you need it.

Can I do this without writing code?

Yes. The Airbyte setup is UI-driven and the Google side is admin console configuration. You will want BigQuery views aggregating usage by department for the licensing questions.

Get your Workspace admin data into BigQuery

Start with the super administrator conversation, naming the two read-only scopes so the request is easy to approve. Then keep the data in its own dataset with deliberate grants, set a retention period, and set the pipeline up before the audit question arrives, because history only reaches as far back as Google still holds it.

Airbyte's connector catalog includes 600+ pre-built connectors, so identity and usage data can sit beside your HR and security sources. For cloud audit activity in the same shape, see AWS CloudTrail to ClickHouse, and for collaboration adoption from the Microsoft side, Microsoft Teams to Databricks.

Start syncing now →