Getting Started with Adobe Experience Platform (AEP)
This guide is for data, marketing technology, and IT leaders evaluating or planning an Adobe Experience Platform (AEP) implementation. AEP is the data and AI foundation underneath the rest of Adobe Experience Cloud — Real-Time CDP, Journey Optimizer, and Customer Journey Analytics are all built on it. You will get an overview of the architecture, a sequencing approach for implementation, and the governance decisions that determine whether AEP becomes a genuine activation layer or an expensive data lake.
Key takeaways
- AEP is built around Experience Data Model (XDM) schemas — get schema design right early, because it is the blueprint every downstream service depends on.
- The identity graph and merge policies determine what a "unified profile" actually contains; both need deliberate configuration, not defaults.
- Sandboxes let you separate development, testing, and production configurations without duplicating your entire data foundation.
- Data governance (usage labels, policies) should be configured before activation use cases go live, not retrofitted after an audit.
- AEP is designed for real-time activation, not batch reporting — treating it as a data warehouse wastes most of its value.
What Adobe Experience Platform actually is
AEP is the data and AI foundation of Adobe Experience Cloud: a set of interconnected services that ingest, standardize, unify, and activate customer data. It is not a single application but a platform other Adobe products build on — Real-Time CDP for audiences, Journey Optimizer for orchestration, and Customer Journey Analytics for cross-channel reporting. Understanding this relationship matters when scoping a project, because "implementing AEP" usually means implementing the data foundation for one or more of those downstream use cases, not building a standalone reporting tool.
Core architecture
Experience Data Model (XDM) schemas
XDM standardizes data structure across every source that feeds AEP — web, mobile, CRM, offline systems. Adobe provides standard field groups (commerce, marketing, loyalty) as a starting point, but most organizations need custom field groups for industry- or business-specific attributes. Design schemas with both current needs and two or three years of expected growth in mind; schema changes after datasets and profiles are populated are possible but disruptive.
Datasets and the Real-Time Customer Profile
Data lands in datasets that conform to your XDM schemas. Profile-enabled datasets feed the Real-Time Customer Profile, which merges records from multiple sources into a single, continuously updating view of each person, governed by the merge policies you configure.
Identity Service
The identity graph links different identifiers — email, mobile ID, CRM ID, cookie ID — into a single customer view. Start with a small number of reliable, high-confidence identifiers and expand deliberately; overly aggressive identity stitching creates false matches that are difficult to unwind later.
Sandboxes
Sandboxes give you isolated environments for schema and dataset development, testing, and production, so a rushed change in a lower environment doesn't reach live profiles or activation. Establish a promotion process — schema and dataset changes should move through sandboxes the same way code moves through environments in software delivery.
Implementation sequencing
- Data landscape assessment. Inventory every source system, its data quality, and its refresh cadence before designing schemas.
- Schema and identity design. Define your XDM schemas, identity namespaces, and merge policy before ingesting production data.
- Ingestion. Connect sources using Adobe's source connectors, batch ingestion for historical data, or streaming ingestion via the Web SDK and APIs for real-time events.
- Governance configuration. Apply data usage labels and policies before any downstream activation use case is switched on.
- Activation use case. Build the first real use case (an audience for Real-Time CDP, a data view for Customer Journey Analytics) to prove the foundation works end to end.
Data governance
AEP's governance framework lets you label data (for example, by contractual or regulatory sensitivity) and enforce policies that block or allow specific uses — such as preventing certain data from being exported to a given destination. Configure this alongside your first ingestion, not after; retrofitting governance onto live datasets means auditing everything that has already been activated.
Common mistakes
- Treating AEP as a data warehouse. If the only output is a weekly report, most of the platform's value — real-time profile updates and activation — goes unused.
- Over-engineering identity resolution on day one. Complex, unproven stitching rules produce false merges that are hard to detect and harder to reverse.
- Skipping the data landscape assessment. Poor source data quality surfaces downstream in profiles and audiences, long after the root cause is easy to trace.
- No sandbox discipline. Making schema changes directly in production sandboxes risks breaking live activation use cases.
- Deferring governance. Waiting until a compliance review to configure usage labels means retroactively untangling data that's already been used.
How Accure helps
Accure's Adobe practice designs AEP data foundations that support Real-Time CDP, Journey Optimizer, and Customer Journey Analytics use cases from day one, with schema, identity, and governance decisions made to last. If your next step is unifying profiles for activation, read our guide to Adobe Real-Time CDP implementation, and if reliable event data is still a gap, start with our Adobe Analytics implementation guide.