Concept
A customer attribute is a named claim about a customer: lapsed, high value, cart abandoner, likely to churn. What a journey or an audience builder shows is a single value, true or false, a number, a date, but that value is only the output of four things that sit behind it. There is a business meaning, which says what the claim represents and who agreed to it. There is the logic that produces it, meaning the inputs, filters, windows and precedence rules. There are its dependencies in both directions, the events and tables that feed it and the audiences, journeys, models and destinations that read it. And there is its refresh behaviour, how often it is recalculated and how stale it may be at the moment a decision reads it. Owning an attribute means owning all four, and that ownership is a responsibility in its own right, separate from owning identity or storing the profile.
Why it matters
Attributes are the interface between the data layer and every decision in the stack. Identity resolution tells you who the customer is, and attributes tell every downstream system what that customer currently is, so a definition that drifts changes behaviour everywhere it is used without anyone touching a journey. When the meaning is invisible to the people who use the attribute, they stop trusting it and build their own, which is how a stack ends up with four attributes that share a name and disagree about who qualifies. The responsibility can sit in several places. A packaged CDP carries it through features such as computed attributes in Adobe Experience Platform or calculated insights in Salesforce Data Cloud, while a warehouse-centric stack can carry it in a semantic layer such as dbt’s, which exists precisely so that a definition changed once is refreshed everywhere it is invoked. The layer or product question applies in full, since what matters is one owned definition per customer concept, readable by the people who build on it.
A simple example
A retailer runs a win-back programme against “lapsed customers”. In the CRM, lapsed means no purchase in twelve months. The email team built its own version, no open in ninety days, because the CRM field refreshed monthly and they wanted something fresher. Paid media uses no site visit in six months, because that was what the ad platform could see. All three are called lapsed. The result is a customer who bought last week, never opens email and receives a win-back discount, while another who has not bought in two years keeps browsing and is excluded from the paid campaign. None of the three definitions is wrong, and the fix is to stop letting them share a name: one owned definition of lapsed, plus explicitly named variants such as inactive on email for ninety days, each with a visible meaning, logic and refresh rate.
The architecture view
The value in the dropdown is the smallest part of the attribute. The other four facets are what someone has to own.
For every attribute that a decision depends on, the operating test is whether a marketer can open it and answer five questions without asking an engineer: what does it mean, how is it produced, what feeds it, what reads it, and when did it last change. Engineering still builds the foundations and reviews new computations, but reading an implementation should not be a prerequisite for understanding a concept.
The mistake I often see
The recurring error is shipping attributes as columns. The implementation team produces a tidy list of fields, lapsed, vip, cart_abandoner, and exposes them in the audience builder, where a marketer can select cart_abandoner = true and has no way to see the waiting window, the purchase sources it checks or the fact that it refreshes once a day. The team calls this self-service, and within a year the stack holds several copies of each concept, built by people who could not see the original and did not trust it. The opposite mistake is locking definitions so tightly that every harmless variation needs an engineering ticket, which produces the same duplication by a slower route; who can change the logic covers that trade-off. Both failures come from treating the definition as an implementation detail when it is the part of the data model the business actually uses.
Go deeper
Attributes are built on a resolved profile, so read what identity resolution is and what a CDP is first. For how a definition behaves over time, event, state and transition separates what happened from what is currently true. The longer argument about where definitions live across architectures is in When the Warehouse Becomes the Campaign Brain and CDP and CEP patterns, Part 2.
Sources
Platform documentation
- Adobe Experience League, Computed attributes overview. Aggregations over experience events, with lookback windows that set the refresh rate.
- Salesforce Help, Create a Calculated Insight Using SQL. Profile-level metrics defined in Data Cloud.
- dbt Developer Hub, dbt Semantic Layer. Central metric definitions refreshed everywhere they are invoked.
Practitioner writing
- Melanys Figueredo Toledano, Reflections on the importance of Customer Data Platforms in data-driven organizations, LinkedIn, 22 September 2026. Makes the case for attributes as first-class, inspectable objects, and prompted this node.