Learn how to move from Adobe Analytics to Customer Journey Analytics with a proven, architecture-first approach. This guide shows how to modernize data collection, modeling, and governance to drive better insights.

Migration from Adobe Analytics to Customer Journey Analytics (CJA) is not a dashboard rebuild exercise. It is an architectural transformation that redefines how data is collected, modeled, governed, and analyzed. Because CJA operates on top of Adobe Experience Platform (AEP), the migration requires a shift in mindset — from report configuration to data architecture design.

The following structured learnings outline the critical steps, challenges, and architectural considerations observed during real-world migrations.

1. Start with use cases, not implementation

Before enabling ingestion or configuring schemas, clarity is required on:

• The business problems being solved

• The journeys requiring cross-channel stitching

• The KPIs that must maintain historical continuity

• The gaps in the existing Adobe Analytics implementation

2. Understanding the architectural shift

The fundamental difference between Adobe Analytics and CJA lies in the separation of concerns across the data lifecycle

No report suites in CJA

CJA eliminates the concept of report suites entirely. The equivalent construct is connections + data views:

• A connection links one or more AEP datasets to CJA

• A data view is configured on top of a connection and acts as the reporting governance layer

• Multiple data views can be created from a single connection — analogous to creating multiple virtual report suites from one dataset

This architecture provides far greater flexibility but requires intentional governance. Organizations must plan Connection and Data View structures before implementation.

3. Migration approach: Historical and real-time phases

A structured migration typically unfolds in two phases.

Phase 1: Historical backfill via Adobe Data Connector

Adobe data connector (ADC) enables historical Adobe Analytics data to be ingested into AEP and made available in CJA.

Key characteristics:

• Suitable for historical backfill

• Not real time

• Data latency may extend several hours

This phase helps establish:

• Metric parity validation

• Reporting baseline comparison

• Classification logic recreation

Phase 2: Real-time ingestion via Web SDK

For forward-looking architecture, Web SDK becomes essential. Adobe's long-term recommended primary collection pipeline is:

Web SDK → AEP (XDM schema + datasets) → CJA (Connection + Data View)

Web SDK enables:

• Near real-time event ingestion

• Unified collection across Adobe solutions

• Future scalability

4. Schema governance: The foundational requirement

In AEP, the schema must be defined before data ingestion. Critical considerations include:

• Proper XDM class selection

• Accurate data types

• Identity namespace mapping

• Event vs profile dataset separation

5. Key platform differences and their implications

Classification Rule Builder replacement

Adobe Analytics supports Classification Rule Builder for dimension enrichment. CJA does not support this functionality natively.

Processing rules, VISTA rules, and bot rules

In Adobe Analytics, organizations rely on processing rules, VISTA rules, IP exclusions, and bot filtering. These functions are not automatically replicated in CJA. Equivalent logic may need to be implemented using:

• DataStream configurations

• Dataset-level transformations

• Bot score logic

• Data View filters

No low-traffic bucketing in CJA

Adobe Analytics applies low-traffic bucketing—high-cardinality dimension values that exceed a threshold are grouped into a '(Low-Traffic)' line item. CJA does not apply this bucketing; all unique dimension values are retained at full granularity.

Implications:

• CJA reports may surface more unique dimension values than AA for high-cardinality fields (e.g., page URLs, search terms, product IDs)

• Teams comparing AA vs CJA metrics for dimensions should account for this difference

• Schemas should accommodate cardinality expectations — data volumes may be higher than estimated based on AA reporting alone

Target server call impact

When migrating to Web SDK, Target-related events may flow into AEP and CJA depending on the configuration. This can cause:

• Increased event counts

• Inflated metrics

• Reporting discrepancies compared to Adobe Analytics

Data View–level filtering and exclusion logic may be required to align reporting expectations. Clear stakeholder communication regarding expected metric shifts is critical.

6. Attribution model alignment

Failure to align attribution models leads to:

• Conversion discrepancies

• Funnel inconsistencies

• Stakeholder confusion

7. Event deduplication requirements

In CJA, deduplication IDs must be configured for conversion events. Event settings require an explicit deduplication definition.

8. IP and bot exclusions

IP exclusion logic does not automatically transfer from Adobe Analytics. Challenges include:

• Large IP lists

• Multiple DataStreams

• Maintaining consistency

Possible solutions:

• DataStream bot rules

• Bot score-based filtering

• Data View filters

9. The role of Data View in CJA

Data View acts as the reporting governance layer in CJA. Configuration typically includes:

• Attribution models

• Sessionization rules

• Metric definitions

• Lookup dataset application

• Deduplication configuration

• Inclusion/exclusion filters

Because ingestion and reporting are separated architecturally, Data View becomes the primary control layer for analytics logic.

10. Architectural model overview

A layered migration architecture can be conceptualized as follows:

1. Data Collection

   Web SDK (real-time) · Adobe Data Connector (historical)

2. Adobe Experience Platform

   XDM schema · Dataset creation · Identity resolution · Data governance

3. CJA Connection

   Dataset selection · Identity stitching validation

4. Data View

   Attribution · Deduplication · Session rules · Filtering · Lookup enrichment

5. Reporting & Analysis

   Journey exploration · Funnel analysis · Attribution insights · Cross-channel reporting

Collection ≠ Storage ≠ Modeling ≠ Reporting

11. Strategic learnings from migration

Several core insights emerge from Adobe Analytics to CJA transitions:

1. Migration is architectural, not cosmetic — requires fundamental rethinking of data flow.

2. Documentation is essential. Legacy rules must be captured before any migration begins.

3. Attribution must be deliberate. Default models differ: CJA uses Same Touch for dimensions, while AA commonly uses Last Touch. Explicit alignment is required.

4. Deduplication is not automatic. Conversion events must be configured for deduplication.

5. Schema errors are costly. Post-ingestion corrections require dataset recreation.

6. No report suites. Everything is Connections + Data Views. Multiple Data Views per Connection enable virtual suite-like segmentation without duplicating ingestion.

7. No Low-Traffic Bucketing. CJA retains all unique dimension values at full cardinality. AA comparisons for high-cardinality dimensions should account for this.

8. Web SDK is the target state. Adobe recommends Web SDK → AEP → CJA as the primary long-term collection pipeline.

9. Stakeholder education matters. A configuration without communication leads to reporting distrust.

12. Conclusion

Migrating from Adobe Analytics to Customer Journey Analytics on top of Adobe Experience Platform represents a shift from channel-based analytics to person-level journey intelligence.

The transformation requires:

• Strong schema governance

• Rule documentation

• Attribution alignment

• Clear deduplication strategy

• Thoughtful reporting configuration

When approached methodically, the result is not simply a new reporting interface — it is a scalable, unified, and future-ready analytics foundation.