Both can describe the same customer, but they answer different questions.
“Customer booked Paris” is a moment. “Customer has three lifetime bookings” is state. One is useful for triggering a journey around what just happened. The other is useful for segmentation and decisions that need the current truth.
Why the distinction matters.
If durable state is represented only as a stream of events, every downstream team has to reconstruct the current answer. If every moment is flattened into attributes, you lose useful sequence and timing.
| Data | Shape | Useful for |
|---|---|---|
| Search abandoned | Event | Triggering a timely follow-up |
| Purchase completed | Event | Confirmation / post-purchase orchestration |
| Loyalty tier | Attribute | Current segmentation |
| Lifetime booking count | Attribute | Eligibility / personalization |
| Last purchase date | Attribute derived from events | Lapse logic / reporting |
Some data should exist in both forms.
A purchase can be an event because the moment matters, while lifetime purchase count and last purchase date are durable state updated as a consequence. The mistake is assuming the same shape should serve every use case.
The practical rule.
Ask whether downstream users need to know that something happened, what is true now, or both. Model from that requirement rather than from whichever API field is easiest to populate.