Data Views, Schemas, and Component Curation
The contract between engineering and analysis
A data view is where schema fields become the dimensions and metrics analysts actually use. One connection can feed several data views, commonly one per brand, region, or business unit, so candidates should reason about the data view rather than the raw schema.
Inside a data view you configure the person-level defaults: session timeout and session start triggers, attribution model and lookback window, calendar and time zone, currency conversion, and how the Person metric is defined. You also curate: renaming technical XDM fields into business language, writing descriptions, hiding fields the business should not use, creating numeric buckets, and building derived fields. A schema field that was never enabled in the data view will not appear in Workspace, which is the most common missing-dimension diagnosis.
Component curation is governance as much as tidiness. Renaming in the data view does not alter the XDM schema, which is deliberate: the schema is shared with other AEP consumers such as Real-Time CDP, so analyst-friendly naming belongs here. Hiding a component removes it from the panel while existing projects may still reference it. Skipping curation leaves hundreds of raw fields and inconsistent definitions across teams.
Rule of thumb: treat the data view as the agreement between data engineering and the analytics team. Anything a business user must see, name, or trust is decided here, once, rather than redefined in every project. Worked example: a team renames the page URL field to Page URL, hides internal staging pages, and buckets order value into bands, and every downstream project inherits those choices.