At Amperity, we’ve spent our summer architecting our customer data cloud to eliminate one of the oldest trade-offs in customer data: the choice between customer profile completeness and customer profile latency.
Balancing completeness and latency
For years, customer data teams have faced an impossible choice:
Batch pipelines deliver more complete customer views, but lag hours or days behind reality.
Streaming systems capture the moment, but lack historical context, struggle with non-event data (e.g. loyalty, inventory, reservations), and force data teams to craft custom ETLs to translate data models to event streams.
Neither alone powers the experiences customers expect. Imagine a shopper who joined a loyalty program in the morning, then visits the store that afternoon. The associate greets him but can’t find his newly-created account because the batch system lags a day behind the loyalty system.
Unifying these is hard.
Most customer data platforms treat batch and streaming as separate systems with separate data latencies. Bridging these lanes requires reconciling fundamentally different assumptions about time, order, and state. In this world, small discrepancies can cause profiles to diverge, attributes to get out of sync, and “real-time” data to lose meaning. This results in different data models, different identity graphs, different segment definitions, risking drift and profile inconsistency.
The Lambda Architecture (or variants of it) is typically what data architects reach for as a starting point to solve the data latency problem. Theoretically we could serve customer profiles through a combination of weaving together historical and event data at a serving layer, but that would introduce technical complexity, scale concerns, and additional product restrictions related to attribute freshness and end-to-end data latency. Brands that have tried to build a solution in-house often reach for two separate tools, introducing additional maintenance and integration overhead.
Avoiding the common pitfalls
Most platforms that try to solve this problem fall into one of two traps:
Event-first systems start with stateless streaming pipelines and later try to layer on data from data warehouses to form profiles. While they may claim to work well for onsite personalization, the problem still remains that without a durable identity backbone, they struggle to unify historical data or reconcile cross-channel identities, resulting in fast but shallow customer views.
Warehouse-first systems retrofit streaming ingestion on top of analytical storage. That often leads to bifurcated paths with batch customer segments living in the warehouse and real-time customer segments in a cache or stream processor. Ultimately this leads to inconsistent logic, schema drift, and hidden refresh limitations.
Our approach to the real-time profile
This fall, we’re introducing a real-time profile architecture that unifies those worlds. It merges our existing AI-powered identity resolution with a streaming design that processes events and exposes profile updates in milliseconds. Every new click, booking, or loyalty change updates the profile instantly and is immediately available for activation.
We built from the ground up: starting from our differentiated foundation in identity resolution and extending forward into streaming. No retrofitting existing architectures, no bolt-on sidecar services. This ensures that the entire product shares the same identity graph and access control layer, so streaming data inherits the same lineage guarantees without bifurcation.
How we built it
Our batch pipelines have always been the backbone of our Customer 360, stitching the best identity-resolved, compliant, and auditable profiles for brands around the world. But batch alone obviously can’t support in-session personalization or trigger actions seconds after a customer event.
We needed an architecture that could:
Process events continuously without introducing a separate identity model.
Preserve data quality and lineage consistent with our batch environment.
Scale elastically across tenants while maintaining predictable and reliable latency to support in-the-moment activations.
The result is a unified dataflow layer that reconciles streaming and batch updates inside one governed profile store.
Architectural overview
At a high level, every customer event flows through three coordinated layers:
Ingestion: Events are streamed to Amperity from any source in their raw JSON form. This can include both online and in-person interactions.
Processing: A distributed dataflow engine continuously processes events and updates the relevant customer profiles.
Actioning: The live profile store immediately triggers in-the-moment journey orchestrations and supports millisecond-level lookups via our Profile API.
This design keeps a single source of truth across both analytical and operational workloads. There’s no dual maintenance of “real-time” versus “batch” segments: they’re the same object, continuously updated.
Identity in motion
Every event we process is tied back to Amperity’s stitched profiles in real time - milliseconds after arrival. That means a “browse” event isn’t just an anonymous click; it’s linked to a profile that already encodes lifetime spend, consent status, loyalty tier, and more.
This alignment unlocks:
Instant enrichment: new events update existing profile attributes within seconds.
Continuous segmentation: segment membership is recalculated automatically as data changes.
Event-triggered activation: profile updates can trigger directly into downstream systems through journeys or APIs, powering true 1:1 personalization.
The outcome is architectural coherence: one data cloud that governs identity, streaming, and activation end to end that’s in line with customer use case expectations and without duplication or drift.
What this means
The engineering innovation we’re delivering with Real-Time Profiles allows brands to always have the most up-to-date representation of their customers, period. Amperity is continually processing data as it arrives, with no staggered schedule bottlenecks in the system. It just works.
One less tool to worry about in a broader ecosystem of tools means less time spent by data engineers in troubleshooting why a message got stuck in a queue somewhere and more time spent by brands delivering personalized experiences in moments that matter.
This enables a whole new suite of activation opportunities that give true power to marketers to be able to target customers in moments that matter:
Event-triggered journeys that react instantly to customer behavior.
Always-current segments that stay synchronized across channels.
In-session personalization for websites and apps using live Profile API lookups that incorporates the latest data across any channel.
A customer’s journey with a brand is full of key moments, including online cart creation/abandonment, loyalty tier changes, credit card approvals, and on-property check-ins. Amperity’s Real-Time Profiles allow brands to define interactions with customers in these moments of outsize importance. In a world where customers are constantly being bombarded with brand messaging, brands that deliver in the moments that matter most are the ones that will win mindshare and ultimately wallet share.
Beyond real-time personalization, Real-Time Profiles establish the foundation for AmpAI agents to operate with live context, reason over continuously evolving profiles, surface insights, and autonomously trigger next-best actions across a brand’s ecosystem. This is the groundwork for a future where agents drive value for marketers by acting on customer data as it changes, not after the fact.
Closing thoughts
Real-time personalization isn’t a single feature - it’s a system design problem. It requires reconciling the durability of historical batch with the velocity of streaming without creating a forked data model.
At Amperity, we’ve built that foundation. Every event, attribute, and decision now flows through one identity-aware architecture that’s capable of serving both high-volume analytics and sub-second activations. Learn more.
If you’re building data systems that bridge these worlds, we’d love to compare notes.