Data Architecture, Connections, and Dataset Configuration
Where CJA data actually comes from
Customer Journey Analytics does not collect data itself. Events land in Adobe Experience Platform (AEP) datasets that conform to an XDM schema, and CJA reads them through a connection. A connection is the architectural contract: it names the sandbox, lists the datasets to include, declares the person ID (an identity field with a namespace), and sets the rolling data retention window.
Three ideas carry most exam weight. First, sandbox alignment: a connection only sees datasets in its own AEP sandbox, so a trap question may describe datasets in two sandboxes that simply cannot be joined. Second, dataset roles: event datasets supply behavior, profile datasets supply person-level attributes, lookup datasets enrich events through a matched key, and summary datasets supply aggregated numbers where raw events do not exist. Third, the person ID is declared once at connection level and can only be changed within a limited window after creation; after that you build a new connection.
Retention deserves care. The window is rolling and set per connection; late-arriving events whose timestamps predate the window are dropped, and extending the window later does not resurrect data already discarded.
Rule of thumb: if two datasets share no identity namespace, the connection will not join them, and no Workspace configuration can repair that. Worked example: a retailer ingests web events keyed on ECID and CRM orders keyed on CRM ID. The architect adds a bridging dataset carrying both identifiers, sets the person ID to the shared namespace, and validates match rate before analysts see anything.