CUSTOMER DATA INFRASTRUCTURE
Snowflake and Braze, connected properly
Braze CDI syncs rows. Meiro Pipes resolves identity, transforms events into Braze's schema, and keeps profiles enriched in both directions. No Hightouch, no Census, no custom pipeline.
Free trial · No credit card · Live in minutes
What actually breaks when you connect Snowflake to Braze
Identity is the first wall. Snowflake records are keyed on whatever upstream systems use: Salesforce IDs, internal user IDs, emails. Braze expects an external_id. When these don't align, CDI syncs create duplicate profiles or drop records. No standard Snowflake connector reconciles cross-system identity. IDs pass through and the system assumes they match.
Braze's event model is strict. Every custom event needs a name, an ISO 8601 timestamp, and a typed JSON properties object under 100 KB. One event per row, no reserved key names. CDI requires a PAYLOAD column containing a handcrafted JSON string. That means writing change-detection SQL against Snowflake Streams, handling insert/update/delete separately via UNION ALL, and rebuilding that payload on every source schema change. Custom ETL, not configuration.
Every attribute sync costs a Braze data point; events count against your contract. Teams overspend because the attribute-versus-event decision happens in SQL rather than at the data model layer. Braze CDI is one-directional. Closing the loop from Braze behavioral data back into Snowflake requires Hightouch, Census, or more custom plumbing.
Five ways the Snowflake → Braze pipeline breaks
Identity mismatch
Problem
Snowflake has email. Braze has external_id. Your CRM has Salesforce account ID. Nothing in the standard pipeline reconciles them. Duplicate profiles, dropped records, broken segments.
Meiro solves it
Pipes resolves identity across email, user_id, device_id, phone, and CRM IDs using deterministic matching with configurable merge limits. One unified profile regardless of which system the identifier came from.
Braze event schema rigidity
Problem
Braze requires events in a specific JSON shape: name, ISO 8601 time, properties under 100 KB, one event per row, no reserved key names, consistent types across syncs. Your Snowflake tables don't look like that.
Meiro solves it
Sandboxed JavaScript transforms convert Snowflake rows into Braze-compatible event payloads. Schema mapping, field renaming, type coercion, and property formatting without raw SQL in Snowflake.
JSON payload construction
Problem
Braze CDI needs a PAYLOAD column with a precise JSON string. Building it means writing SQL to detect changes, construct minimal payloads, and handle insert/update/delete separately via Snowflake Streams and UNION ALL queries. Custom ETL that breaks on every schema change.
Meiro solves it
Pipes constructs the payload from your data model. You define what to sync; Pipes handles serialization, change detection, and delivery.
Data point waste
Problem
Every attribute sync costs a data point. Events count against your contract. Event properties don't, but they're invisible on the user profile and capped at 20 segmentable properties. Teams overspend because they can't optimize what to send as attributes versus events versus properties.
Meiro solves it
Pipes lets you model your data before it reaches Braze. Decide what becomes an attribute (persistent, segmentable, costs data points), an event (timestamped, trigger-able), or a property (free, contextual). Optimize spend at the infrastructure layer, not in Snowflake SQL.
No enrichment loop
Problem
Braze CDI is one-directional per sync. You can pull data in, but a Snowflake → Braze → Snowflake → Braze enrichment loop needs Hightouch or Census. Each adds cost, config, and a failure surface.
Meiro solves it
Pipes collects from both directions. Events from Braze flow into Snowflake. Snowflake data enriches 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 Snowflake
Events land in Snowflake automatically. Pipes connects directly: browse tables, map columns, join with CRM data, billing records, or any warehouse source. Snowflake stays your source of truth.
Resolve Identity
Pipes stitches profiles across Braze external_ids, Snowflake user_ids, CRM emails, device fingerprints, 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: attributes as JSON payloads, events properly formatted, properties correctly typed. Scheduled or real-time.
Use case: Churn prevention powered by warehouse intelligence
Your data science team builds a churn propensity model in Snowflake. It combines product usage data (from Braze events landed in the warehouse) with commercial data (contract value, support ticket volume, NPS scores from Salesforce).
The model produces a churn_risk_score for every customer.
Without Meiro: writing a Snowflake view that formats the score as a JSON payload in Braze CDI's exact shape, setting up a CDI sync, hoping identity matches, and watching the data type between runs. Or paying for Hightouch.
With Meiro Pipes: the churn_risk_score is modeled as an attribute in Meiro. Pipes resolves identity between the Snowflake user_id and the Braze external_id. The enriched profile 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.
From model output to live Braze campaign: hours.
Pipes speaks Braze's schema so your Snowflake doesn't have to
Your Snowflake table
SELECT
user_id,
email,
churn_score,
last_purchase_date,
account_tier,
updated_at
FROM analytics.customer_scores
WHERE updated_at > CURRENT_DATE - 1Pipes 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 `PAYLOAD` column. No UNION ALL queries. No change detection SQL. Pipes handles serialization, schema compliance, and delivery, and adapts when your Snowflake schema changes.
Standard stack vs. Meiro Pipes
The standard stack
- Braze CDI: requires `PAYLOAD` column in exact JSON format
- One sync per table, no cross-table joins
- No identity resolution, silent failures on type mismatches
- Hightouch or Census: another vendor, another contract
- Another schema mapping layer, another dashboard to monitor
- Still no identity resolution
- Custom Snowflake SQL for change detection via Streams
- UNION ALL for insert/update/delete, JSON payload construction
- Breaks on every schema change
Meiro Pipes
- Native connectors for Braze and Snowflake
- Deterministic identity matching across all identifiers
- Configurable merge limits, no duplicate profiles
- JavaScript sandbox transforms, not raw SQL
- Adapts automatically to schema changes
- 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 resolves identity or transforms schema. Meiro Pipes does all three.
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 data from Snowflake 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 as Braze custom attributes
- Build Canvases on full customer context, beyond Braze engagement data
- Optimize attributes vs. events to control data point spend
For the Data Engineer
You're tired of maintaining the Snowflake → Braze pipeline. The JSON payload SQL. The Streams-based change detection. The CDI config that breaks when marketing adds a new field.
- Connect Snowflake and Braze once. Pipes handles schema translation
- JavaScript transforms replace raw SQL payload construction
- Identity resolution across `external_id`, email, `user_id`, CRM ID
- Bidirectional sync. Events from Braze land in Snowflake automatically
- CI/CD-native config management via mpcli
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.
Snowflake Connector
Direct warehouse connection. Browse schemas, tables, columns. Map identifier columns to Meiro identity types. Model warehouse data as attributes or audiences.
Identity Resolution
Deterministic stitching across email, external_id, user_id, device_id, phone, any identifier. Configurable maxIdentifiers and priority to prevent false merges. Cross-system, not per-tool.
Transform Sandbox
Sandboxed JavaScript functions for schema translation. Convert Snowflake rows to Braze payloads. Filter, enrich, rename fields. No raw SQL in Snowflake. 47 allowlisted packages available.
Reverse ETL / Profile Sync (Meiro Engage)
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).
Why connecting Snowflake and Braze requires more than a connector
Braze CDI requires data in a precise format: a PAYLOAD column containing a JSON string that matches the /users/track API shape. Building and maintaining that JSON in Snowflake SQL means writing change detection queries, handling insert/update/delete separately, and constructing minimal payloads that include only modified fields. Custom ETL that breaks every time a source schema changes or a new attribute is added.
Identity is the harder problem. Snowflake stores customer records with whatever identifiers your upstream systems provide: CRM IDs, internal user IDs, emails. Braze identifies users by external_id, with optional email or phone. When these don't match (and they frequently don't), syncs create duplicate profiles, drop records, or associate data with the wrong user. Neither Braze CDI nor Hightouch resolves cross-system identity. They pass identifiers through and assume they match.
Braze's event model adds another layer. Custom events require specific formatting: ISO 8601 timestamps, one event per row, properties as typed JSON under 100 KB, no reserved key names. Inconsistent types between syncs cause silent rejection. The 20-property segmentation limit means teams have to decide upfront which properties are segmentable, a decision that's hard to change later.
The data point pricing model makes this worse. Every attribute sync costs a data point. Sending the wrong data shape (attributes instead of events, or syncing unchanged values) directly increases Braze costs with no additional value.
Stop debugging the pipeline. Start activating the data.
Connect Snowflake and Braze through Meiro Pipes. Identity-resolved, schema-aware, bidirectional. Start free.