Adobe Experience Platform interview questions, answered.

1. What decides whether an XDM schema holds record data or time-series data?

The class. Every XDM schema is built on exactly one class, and the class decides what the schema describes.

XDM Individual Profile is the record class: attributes about a person, such as name, email, loyalty tier or preferences, where the latest value matters. XDM ExperienceEvent is the time-series class: something that happened at a point in time, such as a page view, a purchase or an email open.

A useful rule: if the question is "what is true about this person now", use Individual Profile; if it is "what did they do, and when", use ExperienceEvent.

2. A team stores every purchase in a profile schema. What goes wrong? Scenario

Each new purchase overwrites the last one, so the purchase history is lost. Purchases are events: they belong in an ExperienceEvent schema.

Every ExperienceEvent record needs an _id and a timestamp, and the timestamp is an ISO 8601 date-time.

Error explained: missing required field (_id, timestamp) →

3. What are field groups?

Field groups add reusable sets of fields to a schema. Which field groups are available depends on the schema's class.

4. Records fail because of their data types. Which mistakes would you look for? Scenario

Most type failures come from a handful of mistakes, and converting values in the source file or in the mapping is easier than cleaning up failed records afterwards.

1. Object fields given a single text value instead of nested fields.
2. Number and integer fields given text such as "N/A", or values with units.
3. Boolean fields given "Y", "yes" or 1 instead of true or false.
4. Date and date-time fields not in ISO 8601, for example 2026-03-01 for a date.
5. Array fields given a single value instead of a list, even when there is only one item.
6. Fields with a list of allowed values (an enum) given anything else, including the same word in different capitalisation.

Error explained: expected type object but got string →

5. What is an identity namespace?

It says what kind of identifier a value is, for example Email, Phone, ECID or a company's own CRM ID.

Custom namespaces are created for identifiers Adobe does not provide, such as an internal customer number.

6. What is the difference between an ECID and an email address as identities?

An ECID (Experience Cloud ID) identifies a browser or device. An email address or CRM ID identifies a known person.

When a visitor logs in, sending a known ID together with the ECID lets the identity graph link the two, which is how an anonymous visitor becomes connected to a known person.

7. identityMap or identity fields: when would you use each?

There are two ways to mark identities. identityMap holds several identities per record, grouped by namespace, and is common for data sent from the Web SDK. Marking a single field as an identity is common for CRM-style record data with one clear customer ID.

Either way, one identity should be flagged as primary so the data can be used in Real-Time Customer Profile.

8. You can't enable a schema for Real-Time Customer Profile. Why? Scenario

The schema has no primary identity. A schema needs a primary identity before it can be enabled for Profile.

Error explained: no primary identity →

9. Data was ingested, but it doesn't show up in Real-Time Customer Profile. How do you troubleshoot it? Scenario

Check these in order; they find most missing-data problems:

1. The schema: is it enabled for Profile? It needs a primary identity first.
2. The dataset: is it enabled for Profile? Data reaches Profile only from Profile-enabled datasets, and a dataset can only be enabled if its schema is.
3. The identity values: every record needs a value in its identity field to be attached to a profile.
4. The merge policy: it decides how fragments from different datasets are combined into one profile view.

Error explained: dataset not enabled for Profile →

10. One profile has several different customers' data mixed together. What happened? Scenario

The identity graph has collapsed. The graph links every identity that appears together in the same record or event, so a value shared by many people, such as a family email, a shop's phone number or a placeholder like test@example.com, links all of them into one graph. Shared devices can do the same for browser identities such as ECID.

The fix is upstream: remove placeholder and default values, or leave them empty, before ingestion instead of sending them as identities. Checking how many identities a single profile links to is a quick way to spot a collapsed graph.

Error explained: profiles not merging as expected →

11. What is a merge policy?

A profile is built from fragments: each Profile-enabled dataset contributes its own piece of data about the same person. A merge policy decides how those fragments are combined when they disagree.

With timestamp ordered merging, the most recently updated value wins. With dataset precedence, datasets are ranked and the higher-ranked dataset wins, for example trusting the CRM over a web form. The identity stitching setting decides whether fragments linked by the identity graph are combined at all.

Audiences are evaluated using a merge policy, so two audiences with different merge policies can see the same person differently.

12. What is the union schema?

It combines the fields of all Profile-enabled schemas that share the same class. Enabling a new schema for Profile adds its fields to the union schema.

Looking at a single profile's fragments is the quickest way to see which source a value came from.

13. Batch or streaming ingestion: how do you choose?

Batch ingestion loads files, such as a nightly CRM export, into a dataset in one go. Streaming ingestion sends records one at a time as they happen, for example from a website or an app. Both validate records against the dataset's schema.

Batch suits large volumes that don't need to be acted on within seconds; streaming suits data that should update a profile quickly. Many implementations use both: streaming for behaviour, batch for CRM and offline data.

14. A batch failed. What do you check? Scenario

A batch is ingested into one dataset, and every record is validated against that dataset's schema. The usual causes:

1. A missing required field, a wrong data type or a malformed date-time in the failed records.
2. Numbers sent as text with units, such as "12 kg", in a number field.
3. Boolean fields given "yes" or "Y" instead of true or false.
4. Date-time values that aren't ISO 8601, for example 2026-01-15T09:30:00Z.
5. An empty file, or one with only a header row, which produces no records.

Free tool: check a record against a schema →

15. After an upload, some CSV columns are missing from the dataset. Why? Scenario

Columns that aren't mapped to a schema field are dropped, not stored somewhere else. A CSV has flat columns while XDM has nested fields, so each column is mapped to a field path such as person.name.firstName.

The mapping also has to convert formats (dates to ISO 8601, yes/no values to booleans, numbers without units), and the identity column must be mapped to a field marked as an identity. Testing the mapping on a small sample file shows problems before the full upload.

Free tool: map a CSV to XDM →

16. What does partial ingestion do?

It lets valid records through while the failed rows are reported, instead of rejecting the whole batch. Each batch reports whether it succeeded and how many records failed, so it can be monitored as a unit.

17. How would you check what actually landed after ingestion?

With Query Service, which runs SQL against datasets in the data lake; each dataset appears as a table. Row counts, empty fields and unexpected values show mapping mistakes early.

Query Service supports PostgreSQL-compatible clients, and query results can be saved as a new dataset.

18. What does a datastream do?

The Web SDK sends website data to the Edge Network, and the datastream decides where it goes next, for example Experience Platform, Adobe Analytics or Adobe Target.

Events sent through the Web SDK are XDM ExperienceEvents, so they must match an ExperienceEvent schema.

19. What is the difference between batch, streaming and edge evaluation of audiences?

Batch evaluation runs on a schedule over all profiles. Streaming evaluation updates membership as new data arrives, for the rule types it supports. Edge evaluation runs on the Edge Network for same-page and next-page personalisation, for a narrower set of rule types.

Rules too complex for streaming or edge are evaluated in batch, so the choice is a trade-off between speed and how complex the rule can be.

20. What is a destination, and what does activation need?

A destination is a configured connection to an external platform that receives audiences, such as an advertising platform, an email tool or cloud storage. Streaming destinations receive audience changes close to real time through an API; file-based destinations receive exports on a schedule.

Activation needs a mapping from profile attributes and identities to the fields the destination expects, and data usage policies are checked on the way.

21. What are data usage labels?

Labels applied to datasets and fields to say how that data may be used. Identity labels: I1 marks directly identifiable data such as an email address; I2 marks indirectly identifiable data such as a browser ID. Contract labels (C) record restrictions from agreements, and sensitive labels (S) mark sensitive data.

Policies define which labels can't be used for which marketing actions, and Experience Platform flags an activation that would break a policy before the data is sent. Labelling data when the dataset is created is easier than finding out at activation time.

22. Why do teams use development sandboxes?

Sandboxes are isolated: schemas, datasets and profiles in one sandbox are not visible in another. Development sandboxes are for testing schemas, mappings and audiences before they go live, and sandbox tooling can move configuration between sandboxes instead of rebuilding it by hand.