Data Governance, Privacy, and Administration
Inherited governance, explicit administration
Governance in CJA is inherited, not invented. Data usage labels (contract, identity, and sensitive categories) are applied to XDM fields in AEP, and CJA respects them: connections display the labels, data view components inherit them, and Workspace warns when a component carries a restrictive label. Administrators can also flag components as sensitive inside a data view.
Privacy requests arrive through Adobe Experience Platform's Privacy Service. A deletion request supplied with an identity namespace and value locates the person's records in the relevant datasets, and CJA data derived from those datasets is removed by the same job. Deleting a user account, hiding a component, or shortening retention does not satisfy an erasure request. Retention windows set at the connection bound how much history exists at all, and shortening a window permanently discards older data.
Administration runs through the Admin Console. Product profiles grant permissions such as data view management, segment and calculated metric creation, audience publishing, and project sharing. Users need access to both the product profile and the relevant data views; access is not inherited from AEP merely because someone can see datasets. Familiarity with Adobe Analytics report suite administration does not transfer, which is a frequent trap.
Rule of thumb: label fields at the schema, before ingestion, because retroactive classification is slow and error-prone. Worked example: a customer exercises erasure rights; the admin submits a Privacy Service job using the hashed email namespace, confirms which datasets are affected, then verifies the person no longer appears in person-level reporting.
Business Strategy, Measurement Planning, and Insight Communication
From objective to defensible number
Strategy questions test whether you can move from a business objective to a measurable, defensible plan inside CJA. The chain is: business objective, critical business questions, KPIs, metric definitions, dimensions and segments, then reporting cadence and owner. Write it down as a measurement plan, sometimes called a KPI framework, and keep it short enough that people actually read it.
Each KPI needs four documented elements: numerator, denominator or scope, the segment or population it applies to, and the person or team accountable. Engagement without those is not a KPI. A North Star metric plus a small tree of driver metrics outperforms a dashboard of twenty unrelated numbers.
Traps appear as plausible but unfalsifiable metrics. Activity metrics such as page views or sessions are frequently offered where an outcome metric such as conversion, retention, or revenue per person is required. Options that silently change historical numbers, including switching attribution models, shortening a lookback, or altering identity stitching, should be presented as methodology changes rather than improvements. A KPI that cannot be expressed with a segment or calculated metric in CJA is a wish, not a measurement.
Rule of thumb: if you cannot write the KPI's definition in one sentence and build it in CJA's calculated metric builder, redefine it before it reaches a stakeholder. Worked example: a subscription business tracks Trial-to-Paid Conversion as paid starts divided by trial starts, person-scoped, with a 30-day window and a named growth owner; because the trial is 14 days, the lookback is sufficient and the window is stated in every readout.