Every Adobe Experience Platform engagement arrives dressed as martech. The brief mentions journeys, audiences, personalization, maybe a Real-Time CDP rollout tied to a campaign date. Then the work starts and it is schema modeling, identity resolution, ingestion scheduling and query cost — a data-engineering job with a marketing stakeholder. The people who fail on it are rarely bad engineers. They are AEM developers who shipped components and templates for six years, collected a Platform credential along the way, and have never debugged why 40% of profiles refuse to stitch. Here is how to tell them apart before the statement of work is signed.
The credential is the weakest signal on the résumé
Adobe’s certification program covers an enormous surface. A practitioner or architect badge confirms somebody sat an exam on sandboxes, schemas, segment definitions and activation destinations. It does not confirm they have ever run a production identity graph, watched a dataset bill triple after an unexpected full-table backfill, or negotiated with a marketing team about which fields genuinely belong in the union profile.
That matters more in the Adobe ecosystem than almost anywhere else, because the brand name is a single word across wildly different jobs. “Adobe experience” on a CV can mean Experience Manager component development, Analytics implementation, Target, Campaign, Journey Optimizer, or Platform/RTCDP data architecture. Four of those are front-end or tag-adjacent. One of them is a data platform engagement that happens to sit under a marketing cloud.
If the brief talks about audiences but the work is schemas, hire for schemas.
The practical consequence: you cannot screen on the Adobe word. You screen on artifacts — the schema diagrams, the identity namespace decisions, the dataset-expiration policies they set and why.
Even public pay data can’t tell the two roles apart
US market pay for Adobe Experience Platform architecture work averages $76.18 an hour — roughly $600 a day before any agency margin sits on top. That figure is useful for one reason and misleading for another.
Useful: it is the floor beneath a market where AEP and RTCDP work consistently prices above generalist AEM delivery. The premium exists because the candidate pool is smaller, the failure modes are more expensive, and the skill transfers from data engineering rather than from front-end work.
Misleading: aggregate job-board data pools everything with “Adobe Experience” in the title. AEM developers, Platform architects and hybrid martech roles land in the same bucket. So the published average is simultaneously the best public anchor you have and proof that the market does not distinguish the two hires — which means your vetting process has to do it instead. We break the day-rate structure down further in Adobe Experience Platform consultant rates for 2026.
| Signal | What it looks like on an AEP/RTCDP consultant | What it looks like on an AEM developer |
|---|---|---|
| Primary artifact | XDM schemas, identity namespaces, dataset configs | Components, templates, dispatcher configs, Sling models |
| Language they default to | Fields, cardinality, merge policies, union profile | Authoring, workflows, replication, OSGi |
| Cost conversation | Dataset volume, profile-enabled datasets, query service usage | Publish instance sizing, dispatcher caching |
| Debug story | Why identities failed to stitch | Why a component broke in author mode |
| Hand-off partner | Data engineering, CRM, warehouse team | Front-end, design, content ops |
If a candidate’s strongest stories all sit in the right-hand column, you are buying an AEM contractor at an AEP rate. That can still be the right hire — but only if your engagement is genuinely AEM, in which case the agency versus contractor versus in-house tradeoff is the question to answer instead.
The scorecard
Five evidence checks. Score each 0–2: zero for no answer, one for a textbook answer, two for a specific story with a named consequence. A real Platform consultant clears eight.
| # | Check | Pass condition |
|---|---|---|
| 1 | Schema design | Has modeled XDM from scratch, can justify field groups vs. custom fields, knows what makes a schema profile-enabled and why that is irreversible in practice |
| 2 | Identity graph | Can describe a stitching failure, the namespace that caused it, and how they diagnosed it in the identity graph viewer |
| 3 | Dataset cost control | Names concrete levers — dataset expiration, selective profile enablement, ingestion batching, Query Service discipline |
| 4 | Activation reality | Knows destination throughput limits, segment evaluation cadence (batch vs. streaming) and what breaks under both |
| 5 | Governance | Has set data usage labels and policies, and has told a marketer “no” about a field |
1. Schema design
Ask: “Walk me through the last XDM schema you designed. What went in a field group, what went custom, and what would you change?”
The tell is regret. Anyone who has shipped schemas into a production sandbox has at least one decision they would reverse — an over-nested object that made segmentation painful, a field they made an identity that should not have been, a schema they enabled for profile before they understood the volume implications. Candidates who describe schema design as a clean, solved exercise have only done it in a training sandbox.
Follow up with cardinality. Ask what happens when a high-cardinality field lands in the union profile. If they shrug, they have never carried the bill.
2. Identity graph
This is the single highest-signal area and the one AEM developers cannot fake, because identity resolution has no front-end analogue.
Ask: “Describe a time profiles didn’t stitch the way the business expected. What was the root cause?”
Strong answers get specific fast — a shared device identity collapsing unrelated customers into one profile, a CRM ID arriving in the wrong namespace, a login event sending a hashed email in one system and a raw one in another, a namespace they had to retire and rebuild. They will mention the private graph, how they inspected it in the identity graph viewer, and what the merge policy did to the resulting profile.
Weak answers stay abstract: “we configured identity namespaces per the implementation guide.” That is the exam answer.
3. Dataset cost control
AEP bills on data. A consultant who treats ingestion as free will hand you a platform that works beautifully and costs more than the program it supports.
Ask what they have actually turned off. Good consultants have killed datasets, narrowed what gets profile-enabled, moved event data to expiration policies, pushed heavy transformation upstream into the warehouse rather than running it in Query Service, and argued that not every source needs to land in AEP at all. They should be able to describe the moment somebody asked for “all of it” and they said no.
This is also where the data-engineering overlap becomes obvious. The reasoning is identical to the reasoning on any lakehouse or warehouse engagement — storage discipline, partition sense, and a bias toward processing data before it reaches the expensive layer rather than after.
4. Activation reality
Segments that evaluate on a batch cadence do not fire in real time, no matter what the brief promised. Destinations have throughput ceilings. Streaming segmentation supports a narrower set of conditions than batch.
Ask how they have handled the gap between what a marketing team expected and what the platform delivers. The answer reveals whether they have ever stood in front of a stakeholder with bad news, which is most of the job in month three.
5. Governance
Data usage labels and policies are the part everybody skips until legal asks. A consultant who has implemented them has usually also been the person who blocked an activation — and who can explain, calmly, why a field with a sensitive label cannot go to that destination.
Three questions that sort the pool in ten minutes
If you only have a short screen, use these:
- “What’s the difference between a dataset and a schema, and when have you had one without the other?” Trivial for a Platform consultant. AEM developers answer it from documentation and cannot supply the “when.”
- “How do you decide whether a field becomes an identity?” Real answers weigh uniqueness, stability over time, and blast radius if it is wrong. Textbook answers list namespace types.
- “What would you check first if profile count suddenly doubled overnight?” This is the identity-collapse question in disguise. A Platform consultant goes straight to namespaces and the graph. Everyone else guesses at ingestion.
The structure mirrors how we approach a technical screen generally — tight, artifact-led, and designed to surface a specific failure the candidate has survived. The same logic as vetting a Databricks engineer in 90 minutes applies here, because it is the same kind of job.
What the premium actually buys
At roughly $600 a day before margin, the AEP rate is not paying for Adobe knowledge. It is paying for the specific scar tissue of having run a customer data platform in production: the knowledge that identity decisions are near-permanent, that profile-enabling a dataset is easy and un-enabling it is not, that marketing’s definition of “real time” and the platform’s rarely match.
Hire the AEM developer at that rate and you get someone who will learn all of this on your sandbox, on your timeline, with your identity graph as the training set. The cost is not the day rate. It is the six-month remediation project after the first graph collapse, which is where the genuine expense of a bad AEP hire lives.
Three hiring shapes work, in descending order of how much you should trust them:
| Shape | When it fits | Main risk |
|---|---|---|
| Specialist contractor, named person | You have a defined schema/identity build and an internal owner to hand it to | Availability — the pool is small |
| Blended — specialist architect plus your own engineers | You want the knowledge to stay after the engagement ends | Requires an internal engineer who can absorb it |
| Generalist agency pod | Broad Adobe estate, AEM plus Platform, long horizon | Platform work gets staffed by whoever is on the bench |
The third shape is where most badge-only staffing happens. Not out of bad faith — out of utilization math. Ask who specifically is doing the schema and identity work, by name, and run the scorecard on that person rather than on the pod.
Where to look
The people who clear this scorecard are, almost without exception, already employed and not on job boards. They are architects at brands running RTCDP at scale, or senior consultants inside implementation partners who do this and nothing else. Reaching them means reaching into networks of currently-employed specialists rather than posting a requisition and hoping the AEP ones self-identify — which, given that the public pay data cannot distinguish the roles, they largely will not. Browsing anonymized Adobe ecosystem specialists by what they have actually built is the faster route to the same conclusion the scorecard would reach.