.svg)
BrazeAI Decisioning Studio Pro learns from the data you connect, so data readiness decides how well an agent can work. Braze documents four principles: one customer identifier across every asset, events delivered as an incremental stream, snapshots refreshed on a schedule, and clean, deduplicated records. This guide covers those principles, the connection options and the backfill rules, then ends with a four-pass readiness check.
Key Takeaways
- Braze documents four data principles for Decisioning Studio Pro, and says breaking any of them is among the most common causes of degraded model performance.
- Use exactly one primary customer identifier across every asset. Braze recommends the Braze external ID.
- Deliver events as individual timestamped records, and refresh snapshots on a schedule for every customer, including customers with no new events.
- Slice daily event exports on the creation timestamp, because slicing on the event timestamp permanently misses late-arriving records.
- Choose features that help the agent tell your specific options apart, not features that only describe customers broadly.
- We recommend four readiness passes in order: identity, events, snapshots, then backfill.
What are the Braze Decisioning Studio data requirements?
BrazeAI Decisioning Studio comes in two tiers, and the data work differs between them. Go learns from three signals, all within Braze: your audience, that audience's email engagement and its own understanding of your content. Pro adds your first-party data, such as custom attributes, warehouse data and custom conversion events.
The data preparation pages are written for Pro, and they are direct about the stakes. High-quality data is the foundation of an effective agent. Violating any of the four principles is among the most common causes of degraded model performance.
| Asset | Shape | What it tells the agent | Key fields |
|---|---|---|---|
| Customer profile | Snapshot | The current state of each customer | Customer identifier, snapshot date |
| Activations | Event stream | What the agent decided to do | Customer identifier, event type, event timestamp, creation timestamp |
| Engagements | Event stream | How customers responded to the message | Same as activations |
| Conversions | Event stream | Whether the business outcome was achieved | Same as activations, plus the metric value when the success metric is not binary |
For native Braze integrations, activation and engagement data may arrive automatically through Braze Currents. If your success metric is revenue rather than converted or not converted, each conversion record must carry its value. If direct attribution isn't possible, the agent falls back to proximity-based attribution.
Which customer identifier should every asset use?
Braze's guidance is exactly one primary identifier, present in every asset, and it recommends the Braze external ID. Pro operates exclusively on that ID as its unit of customer identity.
A warehouse ID for features and a platform ID for activations need a translation layer. The pages say that layer introduces fragility, and an engine that can't join assets reliably breaks the feedback loop.
In Braze, a user profile corresponds to a reachable communication channel. A customer with two email addresses has two profiles and two external IDs, and Pro treats them as separate entities. If duplicate profiles aren't reliably merged, the pages say some customers may receive lower-quality personalisation because their history is fragmented.
We recommend counting how many profiles a typical customer has in your workspace before you design an agent. Unmerged duplicates are a data requirement in their own right.
CustomerIK's customer data management service covers identity resolution and merging duplicate profiles. Our case study on consolidating fragmented customer profiles describes that kind of work.
If your business has multiple storefronts or sub-brands, discuss the customer hierarchy with the AI Decisioning Services team first. The pages ask for this before you finalise the identifier strategy.
How should events and snapshots be delivered each day?
Pro runs its recommendation pipeline once per day and needs two shapes of data. Snapshots describe a customer's state, such as profile fields and computed features. Event streams record what happened, one immutable record per event.
Snapshots should be generated on a schedule for every customer, including those with no new events. New snapshot records are appended rather than written over earlier values. Events work the other way round, as only customers who had an event get new records.
Slice each daily export on the creation timestamp. Events written to your system after they occurred are permanently missed if you slice on the event timestamp. The pages give this query pattern, where t is the run date:
-- Correct: use create_timestamp to ensure late-arriving events are captured
SELECT * FROM events_data WHERE DATE (create_timestamp) = { t - 1 }
-- on run date t, export all records created yesterday
| Braze mechanism | Data shape | Documented behaviour |
|---|---|---|
| Custom attributes | Snapshot data: customer profiles and computed features | Each update overwrites the previous value, so the attribute holds the latest state and earlier events are gone. Braze says not to use custom attributes to pass raw event data. |
Braze Currents, USER_BEHAVIOR_CUSTOM_EVENTS table | Event stream data | Captures every instance of a custom event as it occurs, making it the correct source for activation, engagement and conversion events. |
The pages describe appended snapshots in one place and overwriting custom attributes in another. Our suggestion is to ask the AI Decisioning Services team how state history is preserved in your set-up.
Two failure modes recur in the documentation. Aggregating events into a snapshot field, such as a last send time attribute, loses each event's timing and blocks precise attribution. Updating a snapshot only when an event occurs freezes time-based features, so days since last purchase goes stale for customers who haven't purchased recently.
How do you connect the data, and what needs security review?
Braze lists four integration patterns for Pro, and the setup complexity differs between them.
| Integration pattern | Best for | Setup complexity |
|---|---|---|
| Braze Data Platform | Customers already using Braze | Low |
| Braze Cloud Data Ingestion (CDI) | Connecting external data warehouses | Medium |
| Cloud Storage (GCS, AWS, Azure) | Direct data exports from other platforms | Medium |
| CEP integrations | SFMC, Klaviyo data extensions | Medium |
We recommend choosing the pattern by where your outcome data already lives, not by which is quickest to wire. A pattern that moves conversion data through a second system adds one more place for identifiers to drift.
Warehouse data can reach Pro in two ways through CDI. You can sync it into the Braze Data Platform, or send it directly to Pro without adding it to user profiles or custom attributes. The direct option is in early access, and a release note dated 20 Aug 2026 carries the same status.
Each direct sync needs a primary or composite key and maps to a single asset, so plan one sync per asset.
Several documented details belong in a security review before anything is connected:
- The connect-your-data page says Information Security will still need to vet all connection points.
- The integration guide says Decisioning Studio doesn't accept PII, so an export by external ID must return only non-PII fields.
- The assets page lists geography as a profile attribute with the qualifier "where permitted by your industry and privacy requirements".
- The integration guide lists the Braze API key permissions the integration uses, and they aren't all read-only.
/users/trackupdates custom attributes on user profiles, and/messages/sendsends recommended variants through API campaigns. - The Klaviyo route asks for a private API key with Full Access to Profiles. The Salesforce Marketing Cloud route asks you to provide the extension ID and API key to the AI Decisioning Services team.
These pages don't describe subprocessors, retention or cross-border transfer, and this post doesn't settle those questions. We recommend starting the security work alongside the identifier pass. A pattern that fails review sends you back to the table above, and the identifier work is the same whichever pattern survives.
Which features should you build for the agent?
Braze describes four feature types: user profiling, user propensity, user behavioural and environmental. Profiling features hold objective facts about status, and propensity features are model-derived scores. Behavioural features summarise activity over a time window, and environmental features carry signals external to the customer.
The guidelines read like a data quality checklist: features should cover every customer in the target audience, stay within valid ranges and refresh on a schedule. Avoid features that are zero or null for the vast majority of customers. Avoid features that are highly correlated with each other.
The pages suggest 7 to 28 days for high-frequency activity such as app logins. They suggest 90 to 365 days for infrequent activity such as subscription renewals. If a large percentage of a feature's values are zero, the window is probably too short.
Pro is a ranking system, so features should help the model tell the available options apart for a given customer. Braze says broad features, such as high email engagement, don't help much when the model must rank two specific options. In our view, choosing between a discount and a reminder calls for a feature recording each customer's past response to discounts.
How should you backfill historical data?
Braze lists new features, data recovery and logic changes as common reasons to backfill. The lookback window is measured in months and depends on the model's training needs. The AI Decisioning Services team confirms it for your use case, and this post gives no number.
Two standards are mandatory. Historical snapshots must come from a process fully consistent with live snapshot creation. The schema must match the daily pipeline, including fields, data types and column names.
Braze calls data leakage the most critical backfilling mistake. Its example is a lifetime value feature built from total spend to date, then used to predict behaviour from months ago. The fix is to rebuild each historical feature from the information available at that historical timestamp.
Backfill jobs that fail mid-run and are restarted can produce duplicate records. Design every script to be idempotent, so running it twice gives the same result as running it once. Braze names two patterns: delete then insert for the target time range, or an upsert keyed on a unique transaction ID or timestamp.
We recommend running the first backfill in a non-production environment. Then compare one historical snapshot with what the live pipeline would have produced on that date.
Where do data readiness checks usually go wrong?
These points are our judgement, formed by reading the documented rules against each other. Braze doesn't make these statements, so treat them as places to look.
The identifier test under-runs first. A mapping can look one-to-many on a sample and still hold many-to-many cases in the tail, such as a reassigned account number. Test the whole mapping table, because the pages tie identity drift to corrupted training signals and wrong attribution.
Outages come second. A tempting fix after a gap is to rerun the export sliced on event time. That brings back the late-arrival loss the pages warn about, so rerun on the creation timestamp.
Feature definitions come third. If the warehouse team and the lifecycle team calculate an active customer differently, a backfill will mix the two. Pick one owner and one definition before any history is rebuilt.
Early-access routes come last. Planning a launch date around the direct warehouse sync means planning around a status that can change. Keep the Braze Data Platform route as the fallback until the status moves.
What does a readiness check look like in practice?
Take a hypothetical subscription retailer that wants an agent to choose between a discount and a reminder for lapsed subscribers. This is an illustration and not client work, and it uses no figures. The retailer's features sit in the warehouse under an account number, while its Braze profiles came from email sign-ups.
| Pass | What happens in the hypothetical case | Exit test you can run |
|---|---|---|
| 1. Identity | Build a mapping from account number to Braze external ID and look for accounts that map to more than one profile. Merge or document each case, then key every asset on the Braze external ID. | Every row in every asset joins to one external ID, and each account mapped to several profiles is merged or documented. |
| 2. Events | The retailer keeps a last discount sent attribute in Braze. That field overwrites itself, so the send history has to come from Currents as individual records. | For any one customer, you can list every send in order with its own event timestamp and creation timestamp. |
| 3. Snapshots | Days since last order is recalculated only when an order arrives. Lapsed subscribers are the target audience, so the feature must refresh on a schedule for every subscriber. | A customer with no activity still shows a different time-based feature value tomorrow. |
| 4. Backfill | Lifetime spend is calculated to date. Rebuild it as it stood on each historical date, or the model trains on information it could not have had. | Running the job twice gives identical row counts, and an old record matches what you knew on that date. |
The order matters because each pass inherits the mistakes of the one before it. A wrong identifier corrupts events, snapshots and backfills alike, while a stale feature only affects one column.
We recommend treating the agent as not ready to design until all four passes are clean.
How does this connect to the rest of the programme?
Tier choice comes first, and our guide to choosing between Decisioning Studio Go and Pro sets out that decision. Our plan for which Braze AI features to adopt first shows where data work sits in the sequence.
For the feeds Pro reads from, integrating CRM data into Braze and tracking user events in Braze are the practical starting points. Segment hygiene matters for Go, because its entry audience shouldn't be used in another Canvas or campaign. Our guide to segmenting your audience in Braze covers that.
Braze's own guidance on preparing your data is the source of truth for every limit and status in this post. Check it again before you plan.
Frequently Asked Questions
1. Does Decisioning Studio Go need this data preparation?
The data preparation pages refer to Pro throughout, and Go learns from three signals, all within Braze. Its setup page asks for an entry segment that isn't used in another Canvas or campaign. It recommends at least 20,000 users and supports up to 40,000,000.
2. Which identifier should I use for Decisioning Studio Pro?
Use the Braze external ID. Braze says Pro operates exclusively on it as its unit of customer identity. It recommends one identifier across every data asset.
3. Can I send warehouse data without adding it to Braze profiles?
Yes, through Cloud Data Ingestion with Decisioning Studio as the destination. Braze lists this option as early access. Data from these syncs is made available to Decisioning Studio, while your user profiles and Braze workspaces remain unchanged.
4. Does Decisioning Studio accept personal data?
The integration guide says Decisioning Studio doesn't accept PII, so user exports by external ID must return only non-PII fields. Whether your own set-up meets your privacy obligations is a separate question, and this post doesn't settle it.
5. How far back should I backfill?
The window is measured in months and depends on the model's training requirements. The pages give no number. The AI Decisioning Services team confirms it for your use case.
Sources
- Braze, Decisioning Studio overview (Pro). Retrieved 21 Oct 2026.
- Braze, Prepare your data. Retrieved 21 Oct 2026.
- Braze, General principles. Retrieved 21 Oct 2026.
- Braze, Connect your data. Retrieved 21 Oct 2026.
- Braze, Critical data assets. Retrieved 21 Oct 2026.
- Braze, Snapshots versus event streams. Retrieved 21 Oct 2026.
- Braze, Use Braze external ID. Retrieved 21 Oct 2026.
- Braze, Choose good features. Retrieved 21 Oct 2026.
- Braze, Backfill best practices. Retrieved 21 Oct 2026.
- Braze, Integrating BrazeAI Decisioning Studio (developer guide). Retrieved 21 Oct 2026.
- Braze, Sync BrazeAI Decisioning Studio data. Retrieved 21 Oct 2026.
- Braze, Set up your Decisioning Studio Go agent. Retrieved 21 Oct 2026.
- Braze, BrazeAI Decisioning Studio Go. Retrieved 21 Oct 2026.
- Braze, Release notes. Retrieved 21 Oct 2026.
- Early-access status, audience limits and release-note entries were read on 21 Oct 2026 and can change, so check the current Braze pages before you plan.
- Written by CustomerIK, a Braze implementation partner.
CustomerIK is a Braze implementation partner working across onboarding, technical integration, marketing operations and customer data management.
If you're deciding whether your data can support a Pro agent, CustomerIK can walk through the four passes with your team, so let's talk.
.svg)
