Customer Journey Analytics Partners

Getting the event model right the first time

Experience Data Model, or XDM, is the shared schema language Experience Platform uses. You build a schema from field groups, assign it a class such as ExperienceEvent for behavioral data or Individual Profile for attributes, and then ingest records that conform to it. The critical constraint is that schemas are additive: you can add fields, but you cannot rename or repurpose existing ones or change their type once data has landed. A schema designed carelessly in week two becomes something you work around for years.

Spend real time on the event taxonomy before anything is ingested. Decide whether an action is a distinct event type or an attribute of a shared one, whether product detail belongs in a nested array or a flattened field, and how you will represent things that Adobe Analytics historically crammed into a single delimited string. Ask to see the schema diagram and a sample payload for every source before build starts, and have an analyst rather than only an engineer read it, because the person who will write the queries is the person who finds the modeling mistakes.

Data views versus report suites as a mental model

In traditional Analytics, processing decisions such as attribution windows, allocation and visit timeouts were baked in at collection time and stored in the report suite. In Customer Journey Analytics those decisions move to the data view, which is a report-time configuration layer over a connection. That is a substantial shift in how you work: you can create a second data view with a different session timeout or attribution model and compare them against the same underlying data, without re-collecting anything.

The practical consequence is that data views become a governance surface. Two teams with two data views over identical data can produce different numbers entirely legitimately, and someone has to own which view is canonical for which decision. Ask how many data views the build will create, what each is for, and who approves changes to them. A deployment with one shared view and a handful of curated team views is manageable; one where every requester gets their own view reproduces the variable sprawl problem in a new place.

Namespaces, merge policies and what stitching actually does

Identity work is where Customer Journey Analytics either earns its cost or fails. An identity namespace labels the kind of identifier a value represents, such as a cookie identifier, a hashed email address or a CRM identifier. Stitching is the process of taking event records that carry only an anonymous identifier and retroactively attaching a persistent one, so that a person's pre-login browsing joins to their post-login behavior. Adobe offers field-based stitching, which uses a persistent identifier present on some events, and graph-based stitching, which resolves across the identity graph.

These methods produce materially different results, and the difference is not cosmetic. Field-based stitching within a single dataset is predictable and easy to explain, but it only reaches back as far as the identifier appears. Graph-based resolution reaches further and can merge devices, but it introduces the risk of over-merging shared devices into one apparent person. Ask which method is being used, on which datasets, and what the expected effect on unique person counts is, because that number will move and someone will ask why.

Questions to settle before ingestion starts

• Which namespace is the person — decide the primary identity that a person is counted by, and make every source able to emit it or be stitched to it.
• How merge policies resolve conflicts — when two profile fragments disagree, the merge policy decides which wins, and that choice changes audience sizes.
• What happens to unauthenticated traffic — a large share of events may never stitch, and your reporting has to represent them honestly rather than dropping them.
• Whether shared devices are acceptable to merge — household devices can inflate journey complexity and distort per-person frequency metrics.
• How consent revocation propagates — deletion and opt-out requests must reach the datasets and the identity graph, not just the front-end tag.

Cost scales with volume, not with seats

This is the single most important commercial fact about Customer Journey Analytics and it catches buyers out. Your consumption is driven by the volume of rows ingested into Experience Platform and reported on, not by how many analysts log in. A decision to pipe in every low-value event, every server log line and every third-party file at full fidelity is a decision to raise the running cost permanently. It is entirely possible to build something technically correct that nobody can afford to keep.

Scope this explicitly. For each proposed source, ask what the daily row volume is, what questions it answers that nothing else answers, and whether it could be aggregated, sampled or filtered before ingestion without losing those answers. High-frequency events such as scroll depth or mouse interaction are the usual offenders. It is also worth asking what the plan is for reducing volume later, because pruning after the fact is harder than being disciplined at the start.

How much history to backfill

• Start from the comparisons you actually run — if nobody looks past thirteen months, backfilling five years is expenditure with no reader.
• Backfill is a one-off ingestion charge — historical rows count toward volume exactly like live ones, so the decision has a price attached.
• Old data rarely matches the new schema — historic records usually need transformation, and that effort scales with how far back you go.
• Stitching may not apply retroactively — historical events often lack the identifiers that make new data joinable, so old periods behave differently.
• Consider a reduced historical shape — an aggregated or narrowed version of older data preserves trend lines at a fraction of the volume.

Why the numbers will not match, and how to say so

During parallel running, Customer Journey Analytics and traditional Adobe Analytics will disagree, and the disagreement is usually correct rather than a defect. Stitching means a person who used two devices becomes one person rather than two, which lowers unique counts. Session definitions are configured in the data view rather than fixed at collection, so visit totals shift. Bot filtering, virtual report suite processing and attribution defaults all differ. If nobody explains this in advance, the first comparison meeting turns into a credibility problem that takes months to recover from.

Ask for a written variance analysis as a deliverable: for each headline metric, the expected direction and rough magnitude of the difference and the mechanical reason for it. Then validate the specific metrics that matter rather than trying to reconcile everything. A short list of numbers that tie out or have an explained gap is far more useful, and far more achievable, than a blanket promise of parity that cannot be met.

Running both systems without paying twice forever

Parallel running has a real cost: two collection paths to maintain, two sets of definitions and two places for people to look. Set a decommission date for the legacy reporting at the start, tie it to a specific list of reports and users that must be migrated, and hold to it. The common failure is an indefinite overlap in which the old system stays alive because three unnamed reports might still be needed, which doubles the maintenance burden and keeps analysts hedging between two sources.

A sensible shape is a defined overlap covering one full business cycle, so that seasonality is visible in both systems, followed by read-only access to the legacy suite for historical lookups. Agree what happens to historical reporting after cutover, because the answer determines how much backfill you need, and that in turn determines the ingestion cost. These three decisions are connected and should be taken together rather than in sequence.

Programs rarely stop at one product. Buyers hiring for Customer Journey Analytics often pair it with Adobe Analytics partners , Adobe Brand Visibility partners or Adobe Campaign partners , or review the whole Adobe landscape before committing.