Adobe Customer Journey Analytics Developer Expert common mistakes
Adobe Customer Journey Analytics Developer Expert · Understand the traps and how to avoid them.
Treating Customer Journey Analytics connections as if they were Adobe Analytics report suites and expecting Adobe Experience Platform dataset fields to appear automatically without mapping them to schema fields in the connection.
Candidates study the Analytics UI first and carry over the assumption that data collection settings flow straight into reporting. In CJA, a connection maps one or more Experience Platform datasets into a unified schema, and only mapped fields become available downstream.
What to do instead
Memorise the pipeline: dataset (XDM schema) → connection (dataset selection plus field mapping to a common schema) → data view (component creation) → project. Practise describing what breaks at each hand-off when a mapping is missing.
Assuming historical data appears immediately after adding a dataset to a connection, or that data older than the connection's start date will backfill on its own.
The rolling-window and backfill behaviour of connections is easy to conflate with the near-real-time feel of the Analytics UI. Candidates forget that a connection has a defined data window and that late-arriving or out-of-window data needs deliberate handling.
What to do instead
Learn the connection's data-window settings and the difference between the connection's start date and the dataset's event timestamps. When a scenario mentions missing older data, check window configuration before assuming ingestion failed.
Building every component in the data view and then wondering why reports show unexpected values, instead of deliberately choosing attribution, allocation, and component settings per component.
The data view is where most CJA-specific behaviour is decided, but candidates treat it as a simple field picker and skip the non-default settings that change how numbers are calculated.
What to do instead
For each component type, be able to state its default versus configured behaviour - attribution model and lookback window for dimensions, allocation and metric type for metrics, and how those interact with the connection's data. Trace a single reported number back through these settings.
Confusing data view component settings with Workspace-level settings, or assuming a change in one applies to the other.
Both layers expose similar-sounding options, and candidates memorise definitions without pinning them to the layer that owns them, so they choose the wrong place to fix a reporting discrepancy.
What to do instead
Maintain a two-column mental map: what is set once in the data view (applies to all projects) versus what is overridden per panel or visualisation in Workspace. Use 'where would I change this and who else does it affect' as the test question.
Designing lookups or derived fields that join on non-unique or differently-typed keys and expecting clean enrichment.
Lookup and field-based stitching scenarios sound straightforward, but candidates overlook key uniqueness, case sensitivity, and type mismatches between the source field and the lookup dataset.
What to do instead
Before answering, explicitly check the join key: is it unique in the lookup, is it the same type (string vs numeric), and what happens on a miss. Know the fallback behaviour when no match is found.
Assuming cross-device or cross-channel identity resolves automatically because a person ID field exists in the schema.
Identity resolution in Experience Platform and stitching in CJA are separate steps. Candidates conflate the identity graph with CJA's stitching, and forget that stitching depends on a designated person identifier and a defined replay/lookback window.
What to do instead
Separate the two concepts in your notes: Platform identity namespaces and graph versus CJA cross-channel stitching using a person ID and a stitching window. Be able to say what happens to events that arrive after the stitching window.
Treating Workspace freeform tables, attribution, and calculated metrics as independent of data view configuration, and diagnosing a 'wrong number' only inside the panel.
Workspace surfaces the result of decisions made upstream. Candidates debug at the visualisation layer because that is where the discrepancy is visible, and never check the component definition that produced it.
What to do instead
Adopt a fixed debugging order for numeric discrepancies: data view component settings → segment/date-range definitions → panel or visualisation overrides → data freshness. Practise applying that order to hypothetical scenarios.
Assuming derived data (such as sessionisation or derived fields) is applied retroactively to all historical data without considering processing scope and timing.
Derived data feels like a reporting-layer transformation, but it is computed during processing against defined rules and windows, so candidates misjudge which events are affected and when results change.
What to do instead
Know what derived data operates on, how session definitions are configured, and the latency between a rule change and its effect on reports. When a question mentions 'historical numbers changed', check derived-data scope first.
Believing that deleting a dataset, connection, or data view removes the underlying data from Experience Platform, or that governance labels in Platform automatically block use in CJA.
Candidates mix up layers of control: data retention and deletion live with the dataset in Platform, while CJA-side settings govern who can see and use components. Labels and policies need enforcement points to actually take effect.
What to do instead
Map each governance control to its owner: dataset-level retention and deletion in Platform, schema/field labels and policies for enforcement, data view and Workspace permissions for access. Answer 'who can still see this and where' for each control.
Diagnosing missing or low row counts by rebuilding segments or data views instead of first checking ingestion status, schema mapping, and timestamp/date-range alignment.
Troubleshooting questions reward a systematic elimination path, but candidates jump to the most familiar tool. Timestamp mismatches and unmapped fields are frequent root causes that look like reporting bugs.
What to do instead
Use a checklist: dataset ingestion succeeded? field mapped in the connection? component exists and is enabled in the data view? date range and timezone align with event timestamps? permissions allow the data? Work the checklist in order before proposing a fix.