GA4 User-Provided Data BigQuery Trap

There is a setting in GA4 Admin that, once enabled, permanently removes user_id from all BigQuery exports. It cannot be reversed. If any of your data pipelines, dbt models, attribution models, or customer data platforms depend on user_id being present in the raw BigQuery export, this setting silently breaks them with no immediate error signal.

The setting is called “User-provided data” and it lives in GA4 Admin → Data collection and modification → Collect user-provided data.

What the Feature Does

User-provided data collection allows GA4 to hash and use PII that users actively provide — email addresses, phone numbers, names — for Enhanced Conversions and audience matching. It’s a legitimate feature for improving conversion attribution. The UX flow is that GA4 collects this data in hashed form for matching against Google’s identity graph.

The catch is a permanent, undocumented (or at least under-documented) side effect: when this feature is enabled, GA4 stops exporting the user_id field to BigQuery. The field still appears in the schema; it simply contains no values.

Why It’s Irreversible

The stated reason from Google is privacy: once a property is configured to collect user-provided data (even hashed PII), Google’s policy prohibits exporting a user_id field that could potentially be used to re-identify users. Disabling the feature doesn’t restore user_id export because the policy applies to the property’s lifetime configuration, not just its current state.

There is no workaround. There is no Google Support escalation path that restores this capability. The setting, once toggled, is permanent.

What You Lose

The user_id field in GA4’s BigQuery export is how you link GA4 behavioral data to your own identity systems. It’s the bridge between:

• Anonymous user_pseudo_id (device cookie) and your CRM’s customer identifier
• Backstitching pre-login sessions to known users
• Building customer 360 models that combine GA4 journey data with purchase history
• Attribution models that need to tie conversions back to specific customers

Without user_id in the BigQuery export, user backstitching becomes impossible for new data. Historical data retains its user_id values (the field goes empty from the point of enabling the feature forward), but the backstitching join requires events where the user authenticated — and those new authentication events will no longer carry user_id.

Sessions can still be identified with the composite user_pseudo_id + ga_session_id key, but you lose the ability to connect those sessions to your application’s user identity system via the standard GA4 field.

How to Protect Against This

Audit your current state. Check immediately whether this feature is enabled in your property:

-- Verify user_id is still populating
SELECT
  COUNT(*) AS total_events,
  COUNTIF(user_id IS NOT NULL) AS events_with_user_id,
  COUNTIF(user_id IS NOT NULL) / COUNT(*) AS user_id_fill_rate
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN
  FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY))
  AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))

Your user_id_fill_rate should be greater than 0 for any events where logged-in users were active. If it drops to 0 suddenly, the feature may have been enabled.

Add this to your data quality monitoring. A daily check on user_id fill rate for authenticated events (filter to known authentication event names) catches this issue on day one rather than weeks later when someone notices attribution models are broken.

Establish governance around this GA4 Admin setting. Anyone with Edit access to a GA4 property can enable this feature. The recommended practice is to document the BigQuery impact and require data engineering sign-off before enabling it.

Consider an alternative. If your team wants Enhanced Conversions, it’s possible to implement them server-side via the Conversions API or Measurement Protocol without enabling the “User-provided data” collection toggle in GA4 Admin. A Google Ads or Google Tag Manager specialist can advise on the implementation path that avoids the BigQuery side effect.

The Monitoring Query

Add this to your data quality testing suite, ideally as a dbt test with alerting:

-- Check in your dbt source freshness or test config
-- Alert if user_id fill rate for login events drops below threshold
SELECT
  event_date,
  COUNTIF(user_id IS NOT NULL) AS with_user_id,
  COUNT(*) AS total,
  COUNTIF(user_id IS NOT NULL) / COUNT(*) AS fill_rate
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY))
  AND event_name = 'login'  -- or your authentication event name
GROUP BY event_date
ORDER BY event_date DESC

A fill rate of 0 on events that should always have an authenticated user is the clearest signal that something has changed in the property configuration.