CJA vs Adobe Analytics for implementers

What this is

Customer Journey Analytics (CJA) processes data at report time from Adobe Experience Platform (AEP) datasets, where classic Adobe Analytics processes data at collect time into report suites. This reference maps the concepts, limits, and identity mechanics an implementer must translate: eVars/props/events to XDM schema fields, report suites to connections and data views, and visitor identity to Person ID and stitching.

Model and processing

Reporting-surface renames

The terms an implementer meets first when rebuilding reports.

Classic Adobe Analytics limits (for reference)

The comparison page restates the 75 props / 250 eVars figures but not the 1,000-event limit; the 1,000-event figure comes from Adobe’s product description. Confirm contract-specific limits before quoting. Low-Traffic thresholds are adjustable and were historically 500,000 — treat the numbers as account- and dimension-specific.

Connection and datasets

A CJA connection defines which AEP datasets are ingested.

Data views

Data views are the CJA equivalent of virtual report suites and become the report-time governance surface.

Migration mapping (feature to implementation)

None of these carry over automatically; each is manual migration work.

Identity and stitching

Web SDK and datastream

Schema design (durable fields, not slots)

Adobe advises against numbered slots but publishes no single prescriptive eVarX to XDM field-path mapping; any concrete mapping is an implementer choice, not an Adobe-specified rule.

Feature support notes

Support status is a moving target; re-check the live comparison page at build time.

Gotchas

1. Person counts drop and events silently vanish — cause: the Person ID must come from a schema identity, and any event row with no value for it is skipped; casing splits one person into many (abc123 != ABC123) — fix: carry a value on every row (use ECID as the always-present primary identity), normalize casing before ingestion, and stitch to backfill person IDs rather than dropping anonymous rows.
2. Conversion events double-count — cause: CJA deduplicates at the person or session level, and dedup IDs are not applied automatically — fix: configure deduplication IDs for conversion metrics in the data view and validate at the intended level before trusting the numbers.
3. Attribution differs from the old reports — cause: CJA defaults dimensions to Same Touch, whereas Adobe Analytics commonly relied on Last Touch (eVar last-allocation), and attribution now lives in the data view — fix: set attribution model, lookback, and persistence per component in the data view (persistence 90-day max) to match intended behavior.
4. A field was ingested with the wrong data type — cause: XDM schema is mandatory before ingestion, and once a dataset is populated with a wrong field type it must be deleted and recreated — fix: design and validate schema field types up front; use Data Prep to cast / validate on ingestion and treat type choices as hard to reverse.
5. Processing rules, VISTA, bot rules, and classifications did not carry over — cause: none are replicated automatically — fix: rebuild ingest logic in Data Prep, report-time logic in Derived Fields, classifications as Lookup Datasets, and Marketing Channels via Derived Fields for Web SDK data.
6. Calculated metrics and segments are missing — cause: calculated metrics are not auto-ported and segments (earlier called “Filters”) must be rebuilt against XDM fields, not eVars / props / events — fix: recreate them against data-view components; expect manual work, not a lift-and-shift.
7. High-cardinality dimensions explode — cause: Adobe Analytics buckets values over roughly 2,000,000 uniques per month as Low-Traffic; CJA applies no bucketing and keeps every unique value — fix: use Derived Fields to normalize / trim values (e.g. strip query strings) and design data views and filters for full cardinality.
8. Stitching links to the wrong person — cause: graph-based matching is timestamp-agnostic and picks the lexicographically first namespace on multi-identity or shared-device rows; field-based supports only single-step rekeying and halts after 50,000 transitions per device — fix: validate with the CJA stitching tooling, keep the person ID to a single namespace, set namespace priorities where supported, and account for the per-device transition cap.
9. A fresh Web SDK schema on the Analytics field group makes later CJA migration painful — cause: the Adobe Analytics ExperienceEvent field group recreates numbered eVar / prop slots inside XDM — fix: for CJA-bound builds, model durable fields (search.term, content.category) and populate any Analytics variables you still need via datastream mapping or Derived Fields.

Quick recipes

Configure the datastream with a first-party edge domain:

alloy("configure", {
  datastreamId: "ebebf826-a01f-4458-8cec-ef61de241c93",
  orgId: "ADB3LETTERSANDNUMBERS@AdobeOrg",
  // default is edge.adobedc.net; a first-party CNAME reduces ad-blocker
  // interference and keeps the kndctr_ ECID cookie first-party
  edgeDomain: "example.data.adobedc.net"
});

Send durable, self-describing XDM fields instead of numbered slots:

// Model each value once; data views project it into many components.
// Custom fields live under your tenant namespace in the schema.
alloy("sendEvent", {
  xdm: {
    search:  { term: "running shoes" },
    content: { category: "footwear" },
    user:    { membershipTier: "gold" }
  }
});

Carry a persistent ID on every row plus a person ID on some rows (for stitching):

// ECID (persistent, device-level) is added automatically on every row.
// Add a single-namespace person ID on authenticated rows as the primary
// identity so anonymous-then-authenticated journeys resolve to one person.
alloy("sendEvent", {
  xdm: {
    identityMap: {
      CRMID: [{ id: "crm-000123", authenticatedState: "authenticated", primary: true }]
    },
    web: { webPageDetails: { name: "account:home" } }
  }
});

Retrieve the ECID client-side:

alloy("getIdentity").then(function (result) {
  // ECID identifies a device, stored in the first-party kndctr_ cookie
  console.log(result.identity.ECID);
});

Normalize casing before a value becomes a Person ID:

// Person ID matching is case sensitive: abc123 and ABC123 do not merge.
// Apply one consistent rule before the value enters CJA.
var email = rawEmail.trim().toLowerCase();   // e.g. before hashing
var crmId = rawCrmId.trim();                  // keep casing rule stable
// then set the value on identityMap for the chosen namespace

Related

• Hub: Adobe guides
• AEP Web SDK configuration reference
• AppMeasurement to AEP Web SDK migration

Sources

Adobe Experience League pages these values were read from:

• Customer Journey Analytics overview (B2C) (read 2026-07-20)
• Comparison with Adobe Analytics — overview (read 2026-07-20)
• Customer Journey Analytics Feature Support (CJA vs AA) (read 2026-07-20)
• Create or edit a connection (read 2026-07-20)
• Combined event datasets (read 2026-07-20)
• Graph-based Stitching (read 2026-07-20)
• Field-based Stitching (read 2026-07-20)
• Data views (CJA) (read 2026-07-20)
• Architect your schema for use with CJA (read 2026-07-20)
• Implement Adobe Analytics with the Web SDK — overview (read 2026-07-20)
• Datastreams overview (read 2026-07-20)
• Identity data in the Web SDK — overview (read 2026-07-20)
• edgeDomain (Web SDK configure command) (read 2026-07-20)
• Low-traffic value in Adobe Analytics (read 2026-07-20)
• eVar (dimension) (read 2026-07-20)

Flagged rather than guessed: the 1,000-event limit is from Adobe’s product description, not the comparison page; the Low-Traffic thresholds are adjustable (historically 500,000); the 90-day data-view persistence maximum and the AEP Identity Service guardrails were not each re-verified on a dedicated reference page; and there is no official one-to-one eVarX to XDM field-path mapping.