Adobe Customer Journey Analytics has added sub-event analysis: the ability to segment on individual containers inside a single event rather than the whole event at once. The canonical example is an order — instead of filtering on “purchase completed” as one flat record, a team can now segment on a single product category within that order, without pulling in every other item the customer bought in the same transaction. That’s a genuine step up from event-level analysis, which has always forced a choice between granularity and simplicity: split every line item into its own event and multiply your event volume, or keep one event per order and lose the ability to ask questions about individual items within it.
The feature only works, though, if the underlying event data is actually structured to support it. Sub-event segmentation reads from containers — objects or arrays nested inside an event, defined as part of a connection and data view — and a flat event schema with no nested structure simply has nothing for a container to segment. Teams that hear about this feature and expect it to work retroactively on existing data will find it only applies to data captured with the right shape going forward, which makes the schema decision a bigger deal than it looks: get the container structure wrong now, and the same limitation that made this feature necessary in the first place persists for months of backfilled history.
Data Points to Track
- Nested container structure per event type, confirming that multi-item events (orders, carts, content lists) actually carry a defined array or object Adobe can segment on, not a flattened summary
- Container definition mapping, documenting which fields within a data view are configured as queryable containers versus which remain flat and un-segmentable
- Schema migration cutover date, marking exactly when container-structured data collection began, since historical events captured before that point won’t support sub-event queries
- Container-level query performance, since segmenting inside high-volume nested containers can behave differently than top-level event segmentation and is worth benchmarking
- Coverage gaps between event types, flagging any event category still shipping a flat structure while others have been migrated to containers
Setup Steps
- Audit every multi-item event — orders, carts, playlists, content bundles — for whether the underlying data already carries a nested array or object Adobe can treat as a container.
- Define containers explicitly in the connection and data view configuration, rather than assuming Adobe will infer structure from an unconfigured nested field.
- Migrate flat event schemas to nested containers incrementally, starting with the highest-value use case (typically product-category-level purchase analysis) rather than a full schema rewrite at once.
- Mark the container migration cutover date clearly in documentation, so anyone running a sub-event query knows how far back the data actually supports it.
- Validate a sample container-level segment against a manually pulled order to confirm the granularity is behaving as expected before rolling the capability out to the wider team.
Actionable Insights
Sub-event analysis turns “which product category drives repeat purchases” from a data-engineering project into a segment builder click — but only for events already shaped to support it. Prioritise container migration for the event types where component-level granularity actually changes a decision (a checkout event with mixed categories, a content feed with mixed formats), rather than restructuring every event type at once. Teams that get the container schema right now inherit a genuinely more capable analytics layer; teams that don’t will keep hitting the same event-level ceiling the feature was built to remove.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert