Adobe Customer Journey Analytics Developer Expert cheat sheet

A CJA connection maps one or more Adobe Experience Platform datasets to a single logical data source; every dataset in the connection must share a common person identifier or be explicitly excluded from stitching.

Dataset records must be enabled in the Experience Platform schema and the dataset must be added to the connection before any data view can reference its fields.

The connection's person ID (default ECID) determines the identity namespace used for cross-channel stitching; changing it requires re-evaluating historical stitched data.

Event datasets contribute rows to the fact table; lookup and profile-style datasets join on a key and do not add rows to event counts.

Data arriving after the connection's backfill window is not automatically re-ingested; late-arriving records require a dataset backfill or a new connection refresh.

AEP dataset schema changes (new fields) are picked up by the connection only after the field is added to the data view's component list.

Multiple connections can feed one data view only if their schemas share the same identity namespace and compatible timestamp field.

Connection-level data retention is governed by the AEP dataset retention policy, not by CJA; CJA queries only rows that still exist in the lake.

A data view is the container for dimensions, metrics, segments, and calculated metrics; a connection can back multiple data views with different component definitions.

Component visibility (on/off) removes a field from the left rail without deleting it; deleting a component removes it from all projects that reference it.

Attribution and allocation settings are configured per metric at the data view level; changing them affects all reports using that metric.

Dimension component settings include persistence (last touch, first touch, etc.) and expiration; these control how values are attributed across visits.

A data view's default calendar and time zone determine how dates are bucketed; mixed time zones across datasets cause misaligned reporting.

Session definition (session timeout, background events) is set in the data view and governs session-based metrics like visits and bounces.

Calculated metrics and segments created in a data view are scoped to that data view and are not shared across data views.

The component ID, not the display name, is the stable identifier; renaming a component does not break saved projects.

Stitching combines events from different datasets into a single person timeline using the person ID; it is required for cross-device and cross-channel reporting.

Field-based stitching uses a high-confidence identifier (e.g., authenticated user ID) to link events; graph-based stitching uses the AEP identity graph.

Stitching has a lookback window; events older than the window are stitched only after a re-stitch operation, which is costly and time-limited.

Identity namespaces must be mapped consistently across datasets; an ECID in one dataset and a CRM ID in another without a linking field will not stitch.

The person-level metric (e.g., people) counts distinct stitched identities; the visit-level metric counts sessions, which can be higher than people.

Lookup datasets join to event data on a key and enrich dimensions; a failed join produces 'no value' rows rather than dropping events.

Derived fields (e.g., marketing channel) are computed at query time from rules; changing a rule reclassifies historical data on the next query.

Data view-level identity settings override connection defaults; a mismatch between the two produces inconsistent person counts across data views.

Freeform tables support up to 400 rows per breakdown by default; the row limit is configurable in table settings and affects performance.

Segments applied at the panel level filter all visualizations in the panel; segments at the table level filter only that table.

Attribution IQ and anomaly detection operate on the metric's data view attribution model; changing the model changes the anomaly baseline.

Calculated metrics can reference other calculated metrics, but circular references are rejected at save time.

Derived fields are created in the data view, not in Workspace, and become available as dimensions in all projects using that data view.

Flow and fallout visualizations require a dimension with a defined path; fallout supports up to 10 touchpoints per step.

Summary datasets and data warehouse exports use the same segment and metric definitions as the Workspace project.

Project sharing permissions are separate from data view permissions; a user needs both to view a shared project's data.

Data governance labels applied in AEP (e.g., sensitive, contractual) propagate to CJA and can block a field from being used as a dimension or metric.

Data privacy requests (access/delete) are handled at the AEP dataset level; CJA reflects the deletion after the lake record is removed and the data view is refreshed.

Consent and opt-out flags must be captured in the schema and filtered via segments; CJA does not automatically exclude opted-out users.

Row-level data filters in the data view restrict which rows a user can see; they are enforced at query time and are not visible to the user.

A missing dimension value usually indicates a schema mapping gap or a failed lookup join, not a data view configuration error.

Person count discrepancies across reports commonly trace to differing identity namespaces or stitching windows between data views.

Metric totals that do not equal the sum of breakdown rows indicate a non-additive metric (e.g., people, visits) or an attribution model.

Audit logs in AEP record dataset and connection changes; CJA component changes are logged in the Admin console audit trail.