CRM Data Quality Sets the Floor. AI Lifts the Ceiling.
A DTC brand can have every order flowing into Braze and still make poor message decisions if browse events are missing, purchase recency is stale, and product preferences live in an outdated custom attribute. To a decision model, that customer may look inactive, anonymous, or broadly interested in the entire catalog. The model is not making a mysterious mistake. It is working with an incomplete description of the person.
This is the practical relationship between CRM data and AI personalization: data quality sets the floor. A decision layer can find useful patterns and choose among message variants, but it cannot infer every missing behavioral signal reliably. Before adding more automation, lifecycle teams should understand what their CRM captures, how consistently it captures it, and which gaps affect the decisions they want to make.
Start with the decisions, not the event catalog
A data audit is more useful when it begins with a decision the team wants to improve. For example, a lifecycle marketer may want to decide whether a customer should receive a product recommendation, a replenishment reminder, a discount, or no message at all. Each decision depends on different signals.
- Recommendation quality may depend on product views, category interest, searches, purchases, and returns.
- Replenishment timing may depend on order dates, product type, quantity, and expected usage interval.
- Discount decisions may depend on prior promotion response, margin group, purchase frequency, and recent engagement.
- Send timing may depend on recent activity, local time, channel permission, and previous message exposure.
Once the decision is clear, inspect the fields and events that support it. Do not treat an event schema as proof of usable data. An event can exist in documentation but arrive with inconsistent names, missing properties, long delays, or a null-heavy payload. The question is not simply whether product_viewed exists. It is whether the event arrives for most relevant sessions, includes a product identifier, maps to a known catalog item, and arrives soon enough to influence the next send.
A realistic gap: orders tracked, browsing invisible
Consider a fictional subscription brand with several hundred thousand customer profiles. Its Braze workspace receives completed orders reliably, including order value and product category. The team assumes it has enough data to personalize post-purchase messages. After reviewing the event stream, they discover that the storefront only sends browse events for logged-in users. Anonymous visits are not connected to a profile when the visitor later signs in or checks out.
The gap changes the model's view of customer intent. A customer who spends twenty minutes comparing two products but leaves without buying appears inactive. A customer who returns later and purchases may look as if the purchase came without preceding interest. The model can still use purchase history and message engagement, but it cannot accurately distinguish current consideration from general inactivity.
The team also finds that the last_purchase_date custom attribute is updated by a nightly warehouse job. A customer who buys in the morning can remain eligible for a win-back campaign until the next refresh. The issue is not that the CRM lacks a purchase field. The issue is that the field is stale at the moment a decision is made.
A sensible response is not to discard personalization. The team could first limit decisions to signals with acceptable coverage, suppress win-back messages when a recent order event is present, and repair browse tracking for authenticated and newly identified visitors. It could then compare event arrival rates, identity resolution, and campaign outcomes before expanding the decision space.
Four checks that reveal whether data is decision-ready
Small teams do not need a large data-governance program to find the most damaging gaps. A focused review across four dimensions is often enough to establish a useful baseline.
Completeness
Measure how often the expected event or field is present for the profiles and time periods where it should exist. If 80 percent of purchasers have an order event but only 35 percent have product-level properties, product recommendations are operating on a much smaller evidence base than the event count suggests.
Completeness should be measured by segment as well. Mobile and desktop users, logged-in and anonymous visitors, new and returning customers, and different markets may have very different coverage. An overall rate can hide a serious gap in one high-value segment.
Null rates and property validity
Check null rates for properties used in decisions, then check whether non-null values are valid. A populated product_id that does not match the catalog is functionally missing. A field containing both ISO country codes and free-text country names may be populated but difficult to use consistently.
Useful checks include valid-value rates, unexpected defaults, type consistency, and the distribution of categorical values. A custom attribute with “unknown” in 42 percent of profiles should not be treated as a precise preference signal.
Timeliness
Measure the delay between a customer action and its availability in Braze, Klaviyo, or the system making the decision. A signal that arrives within seconds can support a send-time choice. The same signal arriving after twelve hours may only support the next campaign cycle.
Track both average delay and long-tail delay. An average of two minutes can conceal a meaningful number of events delayed for several hours because of queue backlogs or failed retries.
Identity and consistency
Events need to connect to the right person. Review anonymous-to-known transitions, duplicate profiles, merged accounts, device identifiers, and consent state. Also check whether the same business action is represented consistently across web, app, support, and back-office systems.
If an order is recorded under an email address in one system and a customer ID in another, a decision layer may see two partial histories. More events do not solve that problem. They can make it harder to diagnose.
Good data expands the options, but does not remove judgment
Clean, timely, well-connected behavioral data gives a model more evidence. It does not automatically tell the model which business objective matters, which outcomes are desirable, or when a message should not be sent. A model can identify that a customer is likely to click a discount message, but that does not establish that discounting is profitable or appropriate.
Data quality also does not correct a poor experiment design. If every high-value customer receives the same treatment, there may be insufficient variation to estimate whether a recommendation or offer caused an incremental purchase. Nor does better tracking resolve conflicting priorities such as revenue, margin, retention, customer experience, and contact pressure.
Teams still need clear eligibility rules, sensible message variants, frequency controls, consent handling, and evaluation criteria. The AI decision layer selects among the choices and signals available to it. It should not be asked to compensate for missing governance or unclear campaign strategy.
Sparse data is a starting point, not a blocker
Many growing DTC and SaaS teams have limited event coverage. They may have purchases, sign-ups, email clicks, and a few custom attributes, but no reliable browse history or product-level interaction data. They can still start with a narrow decision surface.
For example, a SaaS company might use plan type, account age, active seats, recent login activity, and previous email engagement to choose between an onboarding explanation, a feature education message, and a check-in. A DTC team might use purchase recency, category, order count, and recent email clicks to choose a replenishment reminder or product education message.
With limited signals, the model can compare known behavioral patterns and adapt message selection for customers who resemble those patterns. It cannot reliably infer unseen intent, distinguish two customers with identical records, or make strong recommendations for products nobody has viewed or purchased. Those limits should shape the initial use case.
A practical rollout starts with a small set of well-defined events and variants. Establish baseline coverage, monitor null rates and event delay, and record where the model falls back to a default choice. Then add one new signal at a time, such as browse events or support activity, and test whether it improves decisions enough to justify the tracking and maintenance cost.
For a small team, this approach keeps the work grounded. The goal is not to collect every possible event. It is to make the important signals dependable enough that a per-person decision layer can use them without pretending to know more than the CRM contains. Better data raises the ceiling, but the first useful improvement is often simply knowing where the floor is.