Do these 12 steps in order, in a development environment. Each step lists where to go, what to do, what to check, what you must know, and the questions interviewers ask about it.
Step 1
Plan use cases & data
Where
Outside AEP — discovery workshop + data inventory
What you do
List priority use cases, the sources each needs, and collect sample files from the client (JSON/CSV).
Tips
Check the sample JSON/CSV is well-formed and consistent (same keys, types, date formats) before modeling.
Check before moving on
Use case catalog and data requirements doc signed off.
Must know
Start from use cases, not from the data the client happens to have. Each use case names its audience, its sources, the identities that join them, and where it is activated.
Every source has to be modelled in XDM, so collect real sample files early. Messy samples mean messy schemas.
Check expected data volumes and profile counts against the licence before committing to sources.
Interview questions tap to reveal a model answer
How would you run a discovery workshop for an AEP implementation?
Bring marketing, IT and privacy together, list business goals, turn each into a named use case, then map the sources, identities, consent and activation channel each one needs.
How do you decide which use cases go in Wave 1?
Score each on data availability, feasibility, business impact and dependencies, then pick the top 3 to 5 that are high value and can run on data you already have.
A client wants "all their data" in AEP. How do you respond?
Push back politely: ingest what the agreed use cases need. Extra data costs licence volume, adds governance risk and slows the build.
Screenshot Sample source file (JSON/CSV) the client providedAdd screenshots/aep/step-01.pngStep 2
Create a Development sandbox; create roles for schema, dataset and audience work and assign named users.
Tips
Least-privilege access; build and test everything in Dev before Prod.
Check before moving on
Each user lands in the right sandbox with the right permissions.
Must know
Sandboxes isolate everything: schemas, datasets, identities, audiences and data in one sandbox are invisible to another.
There are production and development sandboxes. Development sandboxes together are capped at 10% of your licensed profiles, and both types can be reset (wiping their contents).
Sandbox tooling (packages) copies configuration between sandboxes, never data. Source credentials are not copied, datasets arrive with Profile turned off, and data usage labels are not carried over.
Access is granted through roles and permissions, down to individual sandboxes and features.
Interview questions tap to reveal a model answer
Development vs. production sandbox: what is the difference?
Development sandboxes are for building and testing; production sandboxes hold live data that feeds real activation. You build in Dev and promote validated configuration to Prod.
How do you move schemas and datasets from Dev to Prod?
Package them with sandbox tooling, then import the package into the production sandbox and re-run QC there.
How would you limit a user to one sandbox and schema work only?
Create a role whose permissions cover schema management only and whose sandbox access lists just that sandbox, then assign the user to it.
Screenshot Sandbox list showing Dev and ProdAdd screenshots/aep/step-02.pngStep 3
Create identity namespaces
Where
Customer > Identities > Create identity namespace
What you do
Confirm standard namespaces (Email, ECID, Phone) and create custom ones such as CRMID or LoyaltyID.
Tips
Pick the identity type carefully (cross-device vs. device); namespace codes cannot be renamed later.
Check before moving on
Namespace names and codes recorded in the SDR.
Must know
A namespace gives an identity value its context: "a@b.com" only means something once it is tagged as Email.
Identity type matters: cross-device IDs (CRM ID, loyalty ID), device IDs (ECID, IDFA), email, phone and non-people identifiers. Non-people identifiers are not stitched into identity graphs.
Standard namespaces (Email, Phone, ECID) already exist. A custom namespace's identity symbol cannot be changed after you create it.
Not every ID is a person. A booking reference (PNR) or order ID is shared or transactional, so store it as a field, not an identity.
Interview questions tap to reveal a model answer
Namespace vs. identity value?
The namespace is the type or context (Email, CRMID); the value is the actual ID ("a@b.com"). Identity Service needs both to link records.
What is ECID and where does it come from?
The Experience Cloud ID: a device/browser identifier set by Web SDK or the ECID service. It identifies anonymous visitors and links to known IDs at login.
Would you make a PNR or order ID an identity?
No. Several travellers share a PNR and an order is a transaction, so using them as identities would merge different people. Keep them as fields.
Choose the class: Individual Profile for attributes, Experience Event for time-stamped actions. Name it per convention.
Tips
One schema per entity type; records (who someone is) vs. events (what they did) decides the class.
Check before moving on
Class matches the data you will ingest.
Must know
Every schema has exactly one class, and the class decides how it behaves. Individual Profile = who someone is (attributes). ExperienceEvent = what happened and when (time series).
An ExperienceEvent schema is not the place for profile attributes. A loyalty tier sent inside an event is stored as event data; it does not update the person's profile attributes. Model those in a Profile-class schema.
ExperienceEvent schemas always require _id and timestamp.
Design carefully up front: once a schema is enabled for Profile and data is ingested, changes are additive only (no removing or renaming fields, no type changes).
Interview questions tap to reveal a model answer
Individual Profile vs. ExperienceEvent class: when do you use each?
Profile for slowly changing attributes such as name, tier and consent; ExperienceEvent for time-stamped actions such as page views, bookings and purchases.
How would you model a booking with several flight segments?
As an ExperienceEvent with an array of segment objects (flight number, origin, destination, date) plus booking-level fields like fare class and total.
What can you still change after data is ingested?
Only additive changes: add new fields and field groups. Once a schema has been used to ingest data you cannot remove, rename or change the type of existing fields.
Screenshot Create-schema dialog with class selectionAdd screenshots/aep/step-04.pngStep 5
Add field groups & custom fields
Where
Schema editor > Field groups > Add
What you do
Add standard field groups (Demographic Details, Personal Contact Details, Consents and Preferences); add custom fields for gaps.
Tips
Standard field groups first; custom fields sit under your _tenantId object, like the client JSON sample.
Check before moving on
Every field in the sample file has a matching XDM field.
Must know
Field groups are reusable building blocks defined for specific classes; you can only add groups that are compatible with the schema's class.
Use Adobe's standard field groups first. AJO, CJA, Commerce and Analytics integrations expect standard fields.
Custom fields live under your tenant object (_tenantId), so they never clash with Adobe's fields.
Data types are reusable field structures (an address, a flight segment) that you can use in several field groups.
Interview questions tap to reveal a model answer
Field group vs. data type?
A field group adds a set of fields to a schema of a given class; a data type is a reusable structure (like an address) that you place inside field groups or schemas.
Why do custom fields sit under the tenant ID?
It namespaces your organization's fields so they never collide with Adobe standard fields or other organizations' fields.
What do you do when no standard field fits?
Create a custom field group with fields under the tenant object, reusing data types where possible, and document it in the SDR.
Screenshot Schema editor showing field groups and _tenantId fieldsAdd screenshots/aep/step-05.pngStep 6
Mark CRMID (or email) as the primary identity with its namespace, then enable the schema for Profile.
Tips
Once Profile-enabled and data lands, structural changes become additive only — review before saving.
Check before moving on
Exactly one primary identity per schema; Profile toggle on where needed.
Must know
To enable a schema for Profile it needs a primary identity field. Web SDK events usually carry identities in identityMap, where one identity is marked primary.
All Profile-enabled schemas of the same class combine into the union schema, which is what Profile and segmentation actually read.
Once a schema is enabled for Profile and saved, it cannot be disabled again. Get sign-off before you flip the toggle. After a schema has been used to ingest data, only additive (non-breaking) changes are allowed.
Both the schema and the dataset must be enabled for Profile for data to reach Real-Time Customer Profile.
Interview questions tap to reveal a model answer
What is the union schema?
A merged view of every Profile-enabled schema of the same class. Segmentation and the profile viewer read the union, not individual schemas.
Identity fields vs. identityMap?
Identity fields mark specific schema fields with a namespace; identityMap is a flexible map of namespaces to values, used heavily by Web and Mobile SDK events.
Why does the primary identity matter?
It is the key the profile fragment is stored under, so a wrong or shared primary identity breaks profile assembly and can merge people.
Screenshot Field properties with Identity and Primary checkedAdd screenshots/aep/step-06.pngStep 7
Create the dataset
Where
Data management > Datasets > Create dataset > Create dataset from schema
What you do
Pick the schema, name the dataset, and turn on the Profile toggle if it should feed Real-Time Customer Profile.
Tips
One dataset per schema/source combination (e.g., CRM Profiles, Web Events).
Check before moving on
Dataset shows the correct schema and Profile status.
Must know
A dataset is a storage container for data that follows exactly one schema.
Ingested data always lands in the data lake; the Profile toggle additionally sends it to the Profile store.
Profile-enabled data counts toward licensed profile entitlements, so do not enable Profile for data no use case needs.
Set retention on high-volume ExperienceEvent datasets (clickstream, playback) to control cost.
Interview questions tap to reveal a model answer
Schema vs. dataset?
The schema is the structure (the blueprint); the dataset is where records that follow that structure are stored.
Data lake vs. Profile store?
The data lake keeps all ingested data for Query Service and CJA; the Profile store keeps Profile-enabled data assembled into real-time profiles for segmentation and activation.
Which datasets would you not enable for Profile?
Raw logs, high-volume data no audience uses, and anything sensitive that must not be activated. They can still be analysed from the data lake.
Screenshot Dataset activity page with Profile toggleAdd screenshots/aep/step-07.pngStep 8
Authenticate, select the file or table, choose the target dataset, then map source fields to XDM fields.
Tips
Use calculated fields in mapping for fixes such as date formats or lower-casing emails.
Check before moving on
No required field left unmapped; data preview looks right.
Must know
Sources bring data in by batch (files, warehouses, CRMs) or streaming (HTTP API, streaming connectors). Website and app data usually arrive through Web/Mobile SDK and a datastream instead.
Data Prep maps source fields to XDM and can transform values on the way in with calculated fields (date formats, lower-casing emails, joining fields).
Required XDM fields must be mapped, or those records fail.
Hash or tokenize sensitive values where policy requires, before or during ingestion.
Interview questions tap to reveal a model answer
Batch vs. streaming ingestion?
Batch is scheduled bulk loads (CRM extracts, warehouse tables) with higher latency; streaming sends records as they happen (web events, booking updates) for near real-time use cases.
How does website data reach AEP?
Web SDK (usually through Tags) sends XDM events to the Edge Network; the datastream routes them to the AEP dataset and other services like Analytics.
A date arrives in the wrong format. How do you fix it?
Use a Data Prep calculated field (date functions) in the mapping step so it is converted to the XDM date-time format during ingestion.
Set batch frequency (or streaming), run the first load into Dev, and open the dataflow run details.
Tips
Compare source row counts with ingested counts (target under 1–2% variance).
Check before moving on
Failed records investigated and re-run successfully.
Must know
A batch can fail completely or partly. Partial ingestion with an error threshold lets good rows in while you inspect the failed ones.
Streamed data reaches Profile in near real time; batch data takes longer before it is available to Profile and segmentation.
Monitor dataflow runs and set alerts; always compare source counts with ingested counts.
Interview questions tap to reveal a model answer
A batch failed overnight. How do you troubleshoot it?
Open the dataflow run, read the error diagnostics, check failed rows against the schema (types, required fields, formats), fix mapping or source, then re-run.
What is partial ingestion?
An option that ingests the valid rows of a batch and rejects the invalid ones up to an error threshold, instead of failing the whole batch.
How quickly is streamed vs. batch data available?
Streamed data is available to Profile within minutes; batch data depends on the schedule and processing, so it is slower.
Screenshot Dataflow run details with success and failed countsAdd screenshots/aep/step-09.pngStep 10
Query the dataset for row counts and nulls; look up known customers by identity in the profile viewer.
Tips
Spot-check 20–30 known customers across channels.
Check before moving on
Profiles merge correctly and consent attributes are present.
Must know
Query Service runs SQL on data lake datasets, not directly on the Profile store.
Nested XDM fields are queried with dot notation, e.g. _tenant.booking.fareClass.
Standard checks: row counts vs. source, null rates on key fields, duplicate IDs, and how many records carry an identity.
To look someone up in the profile viewer you need the namespace plus the identity value.
Interview questions tap to reveal a model answer
Can you query the Profile store with Query Service?
Not directly. Query Service reads datasets in the data lake; profile data can be analysed through profile snapshot exports.
Write a query that finds duplicate order IDs.
SELECT commerce.order.purchaseID, COUNT(*) FROM orders GROUP BY 1 HAVING COUNT(*) > 1;
How do you prove the ingestion is correct?
Reconcile row counts with the source, check nulls and duplicates on key fields, and spot-check 20 to 30 known customers in the profile viewer.
Screenshot Profile viewer for a test customerAdd screenshots/aep/step-10.pngStep 11
Review the identity graph
Where
Customer > Identities > Identity graph viewer
What you do
Search a test identity and confirm the linked IDs form one real person.
Tips
Watch for over-merging through shared devices or generic emails.
Check before moving on
No unexpected links in the graph.
Must know
Identities that appear together in the same record or event get linked; the linked set forms one person's identity graph.
Graph collapse (over-merging) comes from shared devices, shared or fake emails, and placeholder values such as "user_null".
Identity Graph Linking Rules prevent it: mark a namespace as unique (a graph can hold only one identity from it) and set namespace priority.
Merge policies (RTCDP stage) decide which fragments and values win when the profile is assembled.
Interview questions tap to reveal a model answer
How does AEP link an anonymous visitor to a logged-in customer?
When an event carries both the ECID and a known ID (e.g. CRMID at login), Identity Service links them in the graph, so earlier anonymous activity joins the known profile.
What causes graph collapse and how do you prevent it?
Shared devices, shared emails and junk values. Prevent it with unique namespaces and namespace priority, and by never sending placeholder IDs.
Identity graph vs. merge policy?
The graph decides which identities belong to one person; the merge policy decides how their profile fragments and conflicting attribute values are combined.
Screenshot Identity graph for a test customerAdd screenshots/aep/step-11.pngStep 12
Promote & monitor
Where
Sandboxes > Packages (sandbox tooling); Data management > Monitoring
What you do
After Build sign-off, package validated schemas/datasets and import them to Prod; set ingestion alerts.
Tips
Promote configuration, not test data; repeat the QC checks in Prod.
Check before moving on
Prod dataflows running and alerts configured.
Must know
Promote configuration with sandbox tooling packages; data never moves between sandboxes. Check which objects a package supports, because some connections and credentials must be set up again in Prod.
Test data never goes to Prod. Re-run the QC checks in Prod after promotion.
Set alerts on dataflow failures and ingestion lag before go-live, not after.
Interview questions tap to reveal a model answer
Walk me through your AEP go-live checklist.
Signed-off QC in Dev, package and import to Prod, recreate connections, run first Prod loads, reconcile counts, verify profiles and consent, confirm alerts, then hand over runbooks.
How do you promote changes from Dev to Prod?
Sandbox tooling packages for schemas, datasets and other supported objects, followed by validation in Prod.
What do you monitor during hypercare?
Dataflow failures, ingestion lag, profile counts, identity graph health and audience sizes, daily for the first two to four weeks.
Screenshot Monitoring dashboard in ProdAdd screenshots/aep/step-12.png
Sources (UI paths checked against Adobe Experience League, Oct 2026 — menus can move between releases; confirm in your org): end to end tutorial · create schema ui
Implementation by domain
How to use: do each step in your sandbox using the “How to do it” column, then read across the row to see how the same step changes by domain. Each domain column follows one scenario from top to bottom. Add a screenshot and what you learned in the last column.
Travel & Airlines · practice brand: SkyLumen Airways
In Phase 3, add Commerce field groups (Product, Order, Cart Abandonment) to Profile/ExperienceEvent schemas.
In Phase 5, configure real-time cart-event streaming from the commerce platform (Adobe Commerce/Shopify/SAP).
In Phase 6, load-test ingestion at expected peak volume (e.g., Black Friday) before go-live, not just steady-state volume.
In Phase 9, build segments for cart abandonment, browse abandonment, and post-purchase cross-sell as the first wave.
In Phase 10, pre-negotiate rate limits with ad-platform destinations ahead of peak season.
Healthcare
Lab use case: Patient profile (non-PHI)
Profile: B2C (patients) + B2B (providers, payers). Compliance focus: HIPAA, HITRUST, consent-first data collection, no PHI in standard analytics tools without a BAA-covered environment.
What changes in this domain: Segment only on non-PHI derived attributes unless in a compliant sandbox
What changes in this domain: Extra governance labels required; limit destination list to compliant vendors
Appointment reminders, care-gap outreach. Sources: scheduling extract (non-PHI), CRM. Legal defines PHI vs. non-PHI before anything else.
How (any domain): Workshop: list use cases, the sources each needs, and collect sample files; validate the sample JSON/CSV.
Check: Use case catalog and data inventory signed off.
Screenshot Use cases & data inventory · HealthcareAdd screenshots/aep/health-01.png
HIPAA-ready setup and signed BAA before any patient-adjacent data; roles limited to credentialed staff.
How (any domain): Sandboxes > Create sandbox (Dev); roles per job (schema, dataset, audience); least privilege.
Check: Each user lands in the right sandbox with the right role.
