Adobe CJA Business Practitioner Pro common mistakes
Adobe CJA Business Practitioner Pro · Understand the traps and how to avoid them.
Creates a separate CJA connection for each source (one for the Adobe Analytics web data, one for the call centre, one per brand), then tries to answer cross-source questions by stacking segments in Workspace.
Habit carried over from Adobe Analytics, where each report suite was an isolated silo, makes one-connection-per-source feel like the natural mapping. Connections superficially resemble report suites, so the difference is never questioned.
What to do instead
Model one connection per logical business containing every dataset that shares a person identifier, and add new datasets to that connection over time. Verify person-level totals inside the connection before building data views on top of it.
Sets the Person ID to a cookie or device field, or to an identifier that only exists within a session, then reports unique persons and finds totals far higher than the known audience size.
The Adobe Analytics visitor concept is treated as interchangeable with a CJA person. Identity stitching is an explicit configuration decision made at connection level, not something the platform infers on its own.
What to do instead
Choose the identity namespace deliberately when the connection is created, enable identity stitching where authenticated cross-device journeys matter, and reconcile person counts against a trusted source such as a CRM or CDP audience before anyone consumes the reports.
Adds every field from the schema into the data view as a component, keeping the raw technical field names, so analysts face hundreds of near-duplicate dimensions and metrics with no descriptions.
There is an assumption that more available components means more analytical capability, and the data view gets built before the reporting use cases are agreed, so nothing drives the curation decisions.
What to do instead
Build each data view against a defined audience and use case: rename to business language, write descriptions, hide or exclude fields nobody will use, group components into folders, and create derived fields for the values people actually report on.
Compares the same metric across two tables that have different column-level attribution or lookback settings, sees two different numbers, and reports a data discrepancy or logging issue.
Attribution is a property of the metric column and can be overridden inside each freeform table, yet the two tables look visually identical, so the override is invisible to anyone reviewing the report.
What to do instead
Open column settings and check the model and lookback before escalating anything. Set the intended model as the data view metric default, document any deliberate overrides in the panel title, and remove overrides that were only created for a one-off experiment.
Filters a channel or campaign report with an event-level segment such as 'order ID exists' or 'purchase event exists', then reads channel credit from the resulting table and concludes that upper-funnel channels are worthless.
Segment containers are not examined closely, and there is an expectation that segmentation behaves like the report-suite filtering people knew in Adobe Analytics rather than filtering hits before attribution is calculated.
What to do instead
Use a person-level container when the full journey of converting persons is needed, and reserve event-level containers for hit-scoped questions. Validate by comparing metric totals with and without the segment before drawing conclusions about channel contribution.
Publishes a segment as a Real-Time CDP audience using event- or session-scoped logic and a short lookback, then reports that audience membership does not match the counts seen in the CJA segment.
Workspace evaluates segments at query time over historical data, while audiences are evaluated on a schedule against person-level profiles, so scope, lookback, and refresh cadence all change the resulting population.
What to do instead
Design audiences from durable, person-level conditions, confirm the evaluation frequency and identity namespace expected by the destination, and reconcile counts using the same date range and evaluation window rather than comparing a dashboard to a destination profile count.
Searches for Marketing Channel processing rules and paid-channel classification logic inside CJA, or tries to apply an attribution model directly to a dimension such as Campaign or Channel.
Marketing channel rules and dimension-level allocation are long-standing Adobe Analytics capabilities, and the assumption is that CJA inherits them. In CJA there are no processing rules, and attribution applies to metrics rather than dimensions.
What to do instead
Build channel logic explicitly as derived fields in the data view, or resolve it upstream in the Experience Platform schema or through classifications, then attribute a metric such as revenue or orders to the channel dimension and use the Attribution panel to compare models.
Treats data governance as a final step, applying data usage labels to data view components only after segments have been shared and audiences published to downstream destinations.
Because labels set at schema and dataset level propagate automatically, teams assume governance is already handled and defer the review, without checking how policies surface inside the data view and on published segments.
What to do instead
Label data at the schema and dataset level first, then confirm how policy enforcement appears in the data view and on any segment destined for publishing. Get privacy or legal sign-off on the audience contract before anything leaves CJA.
Assumes that deleting or correcting records in the source dataset immediately removes that person from existing CJA reports, and promises stakeholders an erasure date on that basis.
CJA is expected to behave like a live query over the data lake, when in fact ingested data is retained for the configured retention window and erasure follows a specific workflow.
What to do instead
Use the Experience Platform Privacy Service and the CJA deletion process for erasure requests, know the retention window before committing to a date, and record the actual turnaround in the privacy runbook so that future promises are realistic.
Opens Workspace and starts building tables immediately, before the business question, KPI definitions, decision owner, and dimension priorities have been agreed with the stakeholder.
It is a tool-first habit reinforced by pressure to show output quickly, and by confusing the data that happens to be available with the data that is actually relevant to the decision.
What to do instead
Write a one-page measurement plan covering the decision, the KPI and its exact definition, the source field, and the owner, then map it to specific data view components and get sign-off. Build only the panels that answer those questions, and state explicitly which decisions the workspace supports.