A vendor can ingest an event quickly while the audience your team uses remains unchanged. Another can return a profile quickly even though some of its attributes were refreshed earlier.
When evaluating a real-time customer data platform, ask what becomes current, when and for which workflow. Speed is useful only when the right customer context reaches the decision before it loses value.
Key Takeaways
Separate event ingestion, identity recognition, profile freshness, audience evaluation and downstream delivery.
Ask which attributes update from events and which depend on another processing schedule.
Test known, unknown and newly identified customers; recognition isn't the same as rebuilding every identity relationship.
Measure the complete path to the receiving system, including its processing and eligibility rules.
Use batch and real-time processing according to the job rather than demanding the same latency everywhere.
Define the decision before the latency target
Start with the customer moment. A website deciding what to display during a session has a different timing requirement from an analyst calculating a historical retention cohort.
State the input, decision and destination. Then identify the latest point at which the information remains useful. Ask the vendor to demonstrate that specific workflow with timestamps, rather than offering one platform-wide speed claim.
Our discussion of batch and real-time customer data explains why both processing patterns can contribute to customer understanding.
Follow the five stages of freshness
Event ingestion is when the platform receives an activity. Identity recognition determines which customer context, if any, is associated with it. Profile processing makes the relevant information available to a consuming workflow.
Audience evaluation determines whether the customer meets a definition. Delivery then sends data or a request to another system, which may have its own processing delay.
A fast stage doesn't make the entire path equally fast. Request the start and end points behind every latency statement, including how failed or delayed events are handled.
Ask which profile attributes are current
A single profile can combine attributes with different update patterns. Recent browsing may be event-driven, while a historical aggregate depends on a scheduled source feed or database calculation.
For each important field, ask where it comes from, what updates it and how its freshness can be inspected. Include late-arriving events, corrected transactions and deleted or changed source records in the discussion.
Our guide to customer data unification provides the broader context: connecting records is useful when the resulting information has a clear meaning and can support the intended decision.
Test identity recognition and identity resolution separately
Recognition connects an incoming identifier to available customer context. Broader identity resolution evaluates relationships among records and can change which records belong together.
Test a known customer, an unidentified visitor and a visitor who later provides an identifier. Ask what happens to earlier activity, which relationships update immediately and which depend on another process.
Amperity's real-time overview distinguishes batch processing and Stitch from event streams, profile collections, real-time segments and journeys. That distinction is more useful than implying every part of the customer record refreshes in the same way.
Verify when the audience changes
Ask whether an audience is evaluated when events arrive, on a schedule or when another workflow runs. Then test entry, continued membership and exit.
Choose examples with a clear expected result. If a customer makes a purchase, when do they leave an abandonment audience? If an attribute arrives late, is eligibility reconsidered? What happens when the same event is delivered twice?
Keep the test tied to documented behavior. A destination described as an audience connector doesn't necessarily provide event-driven updates or immediate removals.
Include the destination in the measurement
The receiving application may accept data before it finishes processing it. It may also apply identifier matching, minimum audience sizes or message eligibility rules.
Observe the destination state and record the time at which the information becomes usable. Distinguish accepted delivery from audience availability and from an actual customer experience.
A relevant test could follow the customer interaction through the platform to a real-time personalization workflow. Verify every dependency that the experience requires rather than assuming the CDP controls the whole path.
Ask for a failure demonstration
Normal-case latency is only part of the evaluation. Ask how the workflow behaves when a source is delayed, an identifier is missing, a destination rejects a request or a credential expires.
Confirm which failures generate alerts, how retries behave and who can inspect the result. Define what your experience or campaign should do while context is unavailable or stale.
Use those answers to compare platforms against your operational needs. The best timing model is the one that makes the decision dependable.
Choose freshness by use case
Use recent events where the customer moment demands them, and durable history where the decision depends on a broader relationship. Keep each data source's meaning and timing visible.
Explore our real-time activation capabilities, then ask for a demonstration that follows your own event, customer and destination from start to finish.
