.svg)
Braze publishes exactly which fields cost a data point and which do not. That list tends to get read once, at contract time, and then filed. Read it instead as a design brief for the sync itself and it tells you what to send, what to leave behind, and which patterns turn a routine integration into a recurring bill.
Key Takeaways
- A data point is a session start, a session end, a custom event, a purchase, or any attribute set on a profile.
- Push tokens, device information and every campaign engagement event are not billable, because Braze collects them itself.
- Writing engagement data back from your warehouse as custom attributes pays to re-import data you already hold.
- Country and language are billable when you set them and free when the SDK collects them.
- Subscription state and subscription group changes cost nothing to write.
- Usage is cached and refreshes every 24 hours, so a change made this morning will not show today.
What does Braze actually charge you for?
A data point is a session start, a session end, a custom event, a purchase, or any attribute set on a profile. Each one counts once, at the moment it lands.
What Braze collects on its own is outside that count. Push tokens, device information and every campaign engagement event, opens, clicks, impressions and dismissals, are not billable.
That second list is the one worth sitting with. Engagement data already arrives in Braze at no data point cost. If your warehouse also stores opens and clicks, and your sync writes them back as custom attributes, you are paying to re-import data you already have.
Which CRM fields are worth syncing?
Sort your field list against what Braze charges for before you map a single column.
| Sync from your CRM | Cost | Note |
|---|---|---|
| First name, city, phone, date of birth | Billable | Send once, update on change |
| Custom attributes and custom events | Billable | The bulk of any integration |
| Purchases and purchase properties | Billable | Properties count separately |
| Country and language | Billable if you set them | Not billable when Braze collects them |
| Subscription state and subscription groups | Not billable | No cost argument for letting it drift |
| Engagement events, push tokens, device data | Not billable | Braze already has these |
| Install source, campaign, ad group | Not billable | Attribution arrives on its own |
Country and language are the clearest example of a field you can pay for twice. Set them yourself and they are billable. Let the SDK collect them and they are not.
Subscription state sits at the other end. Writing it costs nothing, which removes the last excuse for a preference centre that never updates the profile. A preference a user set and your sync ignored is worse than one you never collected.
In what order should you build the sync?
- List every field your CRM could send, then mark each one billable or not.
- Cut anything Braze already collects, starting with engagement and device data.
- Decide attribute or event per field, on whether you need history not on the source name.
- Build change detection before you build the sync, so unchanged values never leave.
- Run one field end to end, confirm it lands, then open the rest.
- Check usage after a week, remembering the figure lags.
Step four is the one that gets postponed, and postponing it is what makes a sync expensive. Braze recommends passing only new and relevant data, which in practice means your side needs to know what it sent last time. A nightly full export does not know that.
Where does a sync get expensive without anyone noticing?
1. Arrays rewritten on every run
Updating an array costs one data point per call even when nothing changed. A remove operation for a value that was never there still costs one. Setting a whole simple array at once costs a single data point, so batching beats incremental writes.
2. Nested attributes flattened from a CRM object
Every key in a nested object counts. Mapping a rich CRM record straight across without trimming turns one logical update into as many data points as it has keys.
3. File imports used as a sync
Custom attributes in a file import are billable. Imports made for segmentation, using only an identifier column, are not. The same file can sit on either side of that line depending on which columns you include.
4. Usage checked too soon
Usage is cached rather than live and refreshes every 24 hours. A change made this morning will not show today, which is an easy way to conclude a fix failed and revert it.
How does this change what you can send?
The data you sync is the data you can segment and personalise on. Cutting spend is a means, not the goal.
Once the sync is honest, the fields that survive are the ones doing real work in your retention campaigns and your onboarding journey, right through to the activation campaigns that follow. That is also what makes personalisation and dynamic content worth building on top.
Frequently Asked Questions
1. Does syncing engagement data back from our warehouse cost anything?
Yes, if you write it as custom attributes. Braze records engagement events itself at no data point cost, so re-importing them pays for something you already hold.
2. Is it cheaper to send one nested object or several flat attributes?
Neither is cheaper on its own. Every key in a nested object counts, so the total depends on how many keys you update rather than on the shape you send.
3. Do subscription changes count against our allowance?
No. Subscription state changes, globally and around subscription groups, do not log data points, and neither does updating those fields in an import.
4. Why has our usage figure not moved since we made a change?
Because the number is cached rather than live and refreshes on a daily cycle. Wait for the next refresh before drawing a conclusion.
5. Does location tracking cost a data point every time someone moves?
Entering and exiting a geofence does not, because that data is not stored on the profile. Most recent location is billable, so the cost sits in how often you update it.
Sources
- Braze, Data points. Retrieved 07 Sep 2026.
- 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 your data point usage is climbing and nobody can say which sync is doing it, let's talk.
.svg)
