CUSTOMER DATA INFRASTRUCTURE
The missing link between BigQuery and Braze
Braze CDI can't handle BigQuery nested fields and structs. Meiro Pipes flattens nested fields, resolves identity, transforms events into Braze's schema, and keeps profiles enriched in both directions — without Hightouch, Census, or a brittle query you'll be rewriting every month.
Free trial · No credit card · Live in minutes
Everyone says BigQuery and Braze integrate. Nobody warns you about what nested fields do to that plan.
BigQuery's native data model uses nested and repeated fields — STRUCT and ARRAY types that work well for analytics. Braze CDI requires flat JSON and cannot ingest them directly. Every nested field must be explicitly flattened in SQL before it reaches Braze, and that SQL becomes a maintenance liability the moment any upstream schema changes a nested property. This is not a one-time migration.
Identity is the second problem. BigQuery stores records with whatever identifiers upstream systems assigned — Firebase installation IDs, Salesforce account IDs, internal user IDs. Braze expects an external_id. When these don't align, CDI syncs silently drop records or create duplicate profiles. BigQuery also bills per byte scanned: full-table-scan change-detection queries — the naive approach to finding what changed since the last sync — are a direct GCP line item. Poorly scoped WHERE clauses cost real money at scale.
Braze CDI is one-directional per sync. Closing the loop — Braze behavioral events into BigQuery, a BQML model over that data, scored profiles back to Braze — requires a separate reverse ETL layer. Each additional tool means another credential boundary, another schema mapping step, and another failure surface.
Five ways the BigQuery → Braze pipeline breaks
Nested field flattening
Problem
BigQuery structs and arrays are first-class citizens in your data model. Braze CDI doesn't know what to do with them. Every nested field has to be explicitly flattened in SQL before it can sync — and that SQL breaks every time upstream schemas evolve.
Meiro solves it
Pipes transform functions handle nested field flattening in JavaScript — unpack structs, map array elements, flatten repeated fields into Braze-compatible attribute shapes. When the upstream schema changes, you update the transform once, not every downstream query.
Identity mismatch
Problem
BigQuery has Firebase IDs, Salesforce account IDs, internal user IDs. Braze has external_id. No standard CDI or pipeline tool reconciles them. Duplicate profiles, dropped records, broken segments.
Meiro solves it
Pipes resolves identity across every identifier type — email, user_id, device_id, phone, CRM ID — using deterministic matching with configurable merge limits. One unified profile, regardless of which system the identifier came from.
Query cost from inefficient change detection
Problem
BigQuery bills per byte scanned. Full table scans for change detection in CDI sync pipelines aren't just slow — they're a direct line item on your GCP bill. Poorly scoped SQL costs money every time the pipeline runs.
Meiro solves it
Pipes handles change detection at the infrastructure layer, using partition pruning and efficient query patterns against BigQuery. You're not writing full-table-scan WHERE clauses to detect what changed. Pipes manages it, and your query costs reflect only what actually moved.
Service account credential sprawl
Problem
BigQuery CDI requires a service account with precise IAM permissions. As you add environments, datasets, and destinations, credential management becomes a full-time problem — especially with key rotation and least-privilege enforcement.
Meiro solves it
Pipes maintains one managed connection to BigQuery with scoped credentials. Add datasets, change permissions, rotate keys — all in one place. No per-sync service account configuration scattered across CDI, Hightouch, and custom pipelines.
No enrichment loop
Problem
Braze CDI pulls data in. It doesn't push behavioral data back to BigQuery for BQML enrichment, and it can't close the loop — Braze events → BigQuery model → scored profiles → Braze — without a separate reverse ETL tool.
Meiro solves it
Pipes collects from both directions. Braze behavioral events flow into BigQuery. BigQuery model outputs enrich profiles. Enriched profiles flow back to Braze via scheduled or real-time sync. One platform, bidirectional, identity-resolved.
One pipeline. Identity-resolved. Schema-aware.
Collect from Braze
Braze engagement data — opens, clicks, conversions, custom events — flows into Pipes via Currents or webhook. Events land without replacing your Braze SDK.
Load & Model in BigQuery
Events land in BigQuery automatically. Pipes connects directly — browse datasets, map columns, join with nested struct fields or any warehouse source. BigQuery stays your source of truth.
Resolve Identity
Pipes stitches profiles across Braze external_ids, BigQuery user_ids, CRM emails, Firebase IDs — any identifier. Deterministic matching with configurable limits. No duplicate profiles. No dropped records.
Activate Back to Braze
Enriched profiles push back to Braze in the exact schema Braze expects — nested fields flattened, attributes as JSON payloads, events properly formatted. Scheduled or real-time. No Hightouch. No Census.
Use case: Churn prevention powered by BigQuery ML intelligence
Your data science team builds a churn propensity model using BQML directly in BigQuery. It combines product usage data (from Braze events landed in the warehouse) with commercial data — contract value, support ticket volume, NPS scores — stored in nested STRUCT fields alongside the user record.
The model produces a churn_risk_score for every customer, written back to a BigQuery table with a nested prediction_metadata struct.
Without Meiro: Getting that score back into Braze means writing a BigQuery view that flattens the prediction_metadata struct, formats the score as a JSON payload in Braze CDI's exact shape, sets up a CDI sync, manages service account credentials, hopes identity matches, and monitors GCP query costs every time the sync runs. Or paying Hightouch $10K+/yr to handle it.
With Meiro Pipes: The churn_risk_score is modeled as an attribute in Meiro. The transform function unpacks the nested struct, flattens the prediction fields, and maps them to Braze attribute names. Pipes resolves identity between the BigQuery user_id and the Braze external_id. The enriched profile — including the score — pushes to Braze as a custom attribute in the correct format. Your lifecycle team builds a Canvas that triggers a retention campaign for anyone with churn_risk > 0.7. No struct flattening SQL. No CDI payload debugging. No credential spreadsheet.
Time from BQML model output to live Braze campaign: hours, not sprints.
Pipes speaks Braze's schema so your BigQuery nested fields don't have to
Your BigQuery table
SELECT
user_id,
email,
churn_score,
last_purchase_date,
account_tier,
updated_at
FROM `analytics.customer_scores`
WHERE updated_at > DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)Pipes transform
// Pipes send function (Event Destination)
async function send(payload, headers) {
return payload.events.map(row => ({
external_id: row.user_id,
attributes: {
churn_risk_score: row.churn_score,
account_tier: row.account_tier,
last_purchase_date: new Date(row.last_purchase_date)
.toISOString()
}
}));
}What Braze receives
{
"external_id": "usr_8472",
"attributes": {
"churn_risk_score": 0.82,
"account_tier": "enterprise",
"last_purchase_date":
"2026-03-15T00:00:00.000Z"
}
}No manual struct flattening. No `PAYLOAD` column construction. No GCP query cost from inefficient change detection. Pipes handles serialization, schema compliance, and delivery — and adapts when your BigQuery schema adds or changes nested fields.
The cost of bolting it together
The standard stack
- Braze CDI — requires `PAYLOAD` column, cannot handle BigQuery structs or arrays
- Manual nested field flattening SQL for every table, breaks on schema changes
- No identity resolution, silent failures on type mismatches
- Hightouch or Census — $10K+/yr for another vendor
- Another schema mapping layer, another service account to manage
- Full table scan change detection — burning GCP query budget on the pipeline itself
- Custom BigQuery SQL — struct unpacking, JSON payload construction
- Breaks on every upstream schema change
- No enrichment loop from Braze behavioral events back through BQML
Meiro Pipes
- Native connectors for Braze and BigQuery
- JavaScript transforms that flatten nested fields and structs automatically
- Deterministic identity matching across all identifiers
- Efficient change detection — no full table scans, no unnecessary GCP query costs
- Configurable merge limits — no duplicate profiles
- Correct JSON format, correct types, every sync
- Scheduled or real-time bidirectional sync
Braze CDI is a data pipe. Hightouch is a sync tool. Neither flattens BigQuery nested fields or resolves identity. Meiro Pipes does all three — and the pipeline that remains is one you can actually maintain without a BigQuery SQL specialist on call.
One platform. Two problems solved.
For the Lifecycle Marketer
You want to build a Braze Canvas that targets high-value customers at risk of churning — using BQML model outputs and enriched data from BigQuery you can't currently access.
- Describe the audience you need — Piper builds it
- Warehouse-enriched attributes appear in Braze without engineering tickets
- Churn scores, LTV, account tier — all available as Braze custom attributes
- Build Canvases on complete customer context, not just Braze engagement data
- Optimize what you send as attributes vs. events to control data point spend
For the Data Engineer
You're tired of maintaining the BigQuery → Braze pipeline. The nested field flattening SQL. The service account credential rotation. The CDI config that breaks when a `STRUCT` field gets a new nested property.
- Connect BigQuery and Braze once — Pipes handles struct flattening and schema translation
- JavaScript transforms replace raw SQL payload construction and nested field unpacking
- Identity resolution across `external_id`, email, `user_id`, Firebase ID
- Efficient change detection — no full table scans burning your GCP query budget
- Bidirectional sync — events from Braze land in BigQuery automatically
Under the hood
Braze Event Destination
Native connector. Pushes attributes, events, and purchases to Braze in the exact /users/track API format. Handles JSON serialization, ISO 8601 date formatting, and property type validation.
BigQuery Connector
Direct warehouse connection with managed service account credentials. Browse datasets, tables, and nested STRUCT columns. Map identifier columns to Meiro identity types. Handles partition pruning for efficient change detection — no full table scans.
Identity Resolution
Deterministic stitching across email, external_id, user_id, device_id, phone, Firebase ID — any identifier. Configurable maxIdentifiers and priority to prevent false merges. Cross-system, not per-tool.
Transform Sandbox
Sandboxed JavaScript functions for schema translation. Flatten BigQuery STRUCTs and ARRAYs into Braze-compatible payloads. Filter, enrich, rename fields. No raw SQL in BigQuery. 47 allowlisted packages available.
Reverse ETL / Profile Sync (Customer Studio)
Scheduled or real-time Live Profile Sync. Push enriched profiles and segments to Braze or any destination. On-demand exports for backfills. Full delivery history and retry.
Data Point Optimization
Model data before it reaches Braze. Decide at the infrastructure layer what becomes an attribute (costs data points), event (costs events), or event property (free). Stop overspending on Braze's pricing model.
Why connecting BigQuery and Braze requires more than a connector
What the documentation doesn't explain is what happens when your BigQuery data looks like BigQuery data — nested STRUCTs, ARRAY fields, repeated records. Braze CDI requires flat JSON. It cannot ingest BigQuery's native hierarchical types. Every nested field must be manually flattened in SQL before it reaches Braze, and that SQL becomes a maintenance liability the moment any upstream schema changes.
BigQuery's billing model adds a cost dimension that no other warehouse creates at the same scale. CDI sync pipelines that rely on full table scans for change detection — finding rows modified since the last run — scan potentially billions of bytes per execution. On large tables with frequent syncs, the pipeline itself becomes a significant GCP line item. Efficient change detection requires partitioning awareness and careful query design, not just a WHERE updated_at > last_sync timestamp dropped into a view.
Identity remains the hardest problem. BigQuery stores records with whatever identifiers your upstream systems assigned — Firebase installation IDs, Salesforce account IDs, internal user IDs, emails. Braze identifies users by external_id. When these don't align — and they rarely do cleanly — CDI syncs create duplicate profiles, drop records, or silently attribute data to the wrong user. No standard BigQuery integration tool resolves this cross-system identity gap.
Service account credential management adds operational surface area. Braze CDI needs a service account with scoped BigQuery IAM permissions. As teams add datasets, rotate keys, and manage least-privilege access across environments, the credential overhead compounds at every integration boundary.
Stop debugging the pipeline. Start activating the data.
Connect BigQuery and Braze through Meiro Pipes. Nested fields flattened. Identity-resolved. Schema-aware. Bidirectional. Start free.