The licence quote is the easy part. You know what Adobe Analytics costs per year, you know your server call commitment, and finance can model it. What nobody hands you in that conversation is the price of the work that makes the licence do anything: a data layer somebody has to specify and the engineering team has to actually emit, an AppMeasurement estate that has to be migrated to the Web SDK without losing year-over-year reporting, and — if Experience Platform is anywhere in the roadmap — XDM schemas and identity rules that have to be modelled before the first event lands. Under-scope that and you own a very expensive report suite that three people trust.
The evidence that this happens routinely is not anecdotal. Marketers report using just 42% of the capability available in their martech stack, and the following year that figure fell again to 33%. The implementation deficit is widening, not closing. Price the implementation like the product it is, scope by scope, and compare a specialist contractor against a partner SOW on the same line items.
The licence is predictable — the implementation is where the money moves
An Adobe Analytics implementation is four jobs that get sold as one. Each has a different skill profile, a different failure mode and a different sensible buyer.
| Scope | What it actually is | Who does it well | Realistic elapsed time |
|---|---|---|---|
| Measurement design | KPI framework, event and eVar taxonomy, solution design reference, consent mapping | Analytics-native consultant working with the analysts who will use it | A sprint or two, mostly workshops |
| Data layer design and build | Schema for the data layer, naming conventions, front-end emission, QA harness | Spec by the Adobe specialist, build by your front-end team | Spec in a sprint; build is a function of how many templates you own |
| AppMeasurement → Web SDK migration | Tags/Launch rebuild, XDM mapping, datastreams, parallel-tracking period, report suite parity checks | Someone who has done it on a live estate, not read the docs | Most of a quarter for a single-brand site; longer across multi-brand or app estates |
| XDM schema and identity modelling | Field groups, identity namespaces, merge policies, dataset design for downstream AEP/CJA use | Platform-side specialist, overlaps with data engineering | A quarter, and it is the one scope that quietly sets your ceiling for everything after |
The migration scope is the one buyers consistently mis-price. It is not a tag swap. It is a parity exercise: every rule, every custom code block, every plugin behaviour and every processing rule has to be reproduced or deliberately retired, with a parallel-tracking window long enough to prove the numbers match before you turn the old library off. Teams that skip the parallel window save a few weeks and spend the next two quarters arguing about whether traffic really dropped.
Why under-scoping is a hiring problem, not a product problem
Gartner’s own breakdown of the utilisation collapse names difficulty identifying and recruiting talent to drive adoption at 28% as a top-three cause, alongside tool overlap and ecosystem sprawl. That is a direct read-through for Adobe Analytics buyers: the gap between what you licensed and what you use is mostly a shortage of people who can translate business questions into a schema and a datastream.
It shows up downstream as data quality. 56% of data practitioners name data quality as a problem — which, on an Adobe stack, is exactly what a loose data layer and an under-modelled XDM schema produce. Nulls in the product string. Three spellings of the same page name. An identity namespace that was supposed to be a hashed email and is sometimes a session ID. None of that is fixable in a dashboard; all of it is cheap to prevent at spec time and brutal to retrofit once eighteen months of data carries it.
The dashboard argument you are having next year was decided in a spec document nobody wanted to pay for.
Contractor, in-house or partner SOW
There is no honest universal day rate, but there are honest anchors. The average US technology professional earns $112,521, and consulting as a sector pays above $125,000 for the same technical labour. That premium exists before any agency adds delivery margin, bench cost, account management or risk loading — which is the structural reason a partner day rate sits where it does. Separately, the median wage for web developers is $92,650, a useful number for splitting generalist front-end build cost out of specialist Adobe implementation cost. The people emitting your data layer are not the people designing it, and you should not pay a specialist rate for the former or a generalist rate for the latter.
| Model | Best for | Cost shape | Main risk |
|---|---|---|---|
| Specialist contractor | Migration, schema design, solution design reference, unblocking a stalled build | Day rate, scoped to a named deliverable, ends when the deliverable lands | You need someone internally who can hold the spec afterwards |
| In-house hire | Ongoing governance, release QA, analyst enablement | Salary anchored above the general tech average, plus loading, plus a hiring cycle | Hiring takes a quarter you may not have, and the first six months are ramp |
| Partner SOW | Multi-market rollouts, AEM plus Analytics plus AEP programmes, contractual risk transfer | Blended rate across a team, priced with margin on top of a consulting-sector salary base | Blanket scope hides which specialist is on which line; juniors get billed at blended rate |
The useful move is not choosing one. It is splitting the work: buy the migration and the schema from a specialist who has shipped both, buy the front-end emission from the team that already owns your templates, and keep governance in-house. We have broken the same economics down for the platform side in Adobe Experience Platform consultant rates and for the content side in AEM agency versus contractor versus in-house.
How to price a partner SOW line by line
A blanket SOW is priced to your uncertainty, not to the work. Break it into the four scopes above and ask for each one separately. Specifically:
- Named people, named scopes. Who is doing the XDM modelling, and what have they shipped? A blended rate across “the team” means you are paying specialist money for whoever is free.
- Deliverables, not phases. “Discovery” is not a deliverable. A signed solution design reference, a data layer specification with QA assertions, a datastream configuration and a parity report are.
- Parity criteria in writing. What variance between AppMeasurement and Web SDK counts as pass? Who runs the comparison and for how long?
- Handover as a line item. Documentation, a tagging governance process and a working session with your analysts. If it is not priced, it will not happen.
- Who owns the data layer long term. Implementations rot at the release boundary. The spec needs an owner on your side with a QA gate in the deployment pipeline.
Red flags in a scope document
A scope that prices migration as a fixed small block without asking how many templates, apps and consent variants exist has not looked at your estate. A scope that treats XDM as a configuration task rather than a modelling task will hand you field groups you cannot extend. And a scope with no parallel-tracking window is a scope that intends to be finished before anyone can check it.
What to test for before you sign anything
The skills that separate a real Adobe Analytics implementer from a Launch button-pusher are narrow and testable in an hour:
| Capability | What good looks like | How to probe it |
|---|---|---|
| Web SDK migration | Can describe mapping custom code and plugins to XDM, and what breaks in year-over-year reporting | “Walk me through retiring the getQueryParam plugin on an estate with 40 campaign parameters” |
| XDM and identity | Thinks in field groups, namespaces and merge policies; knows what is expensive to change later | “Which decisions in a schema are effectively irreversible, and why?” |
| Data layer design | Writes specs a front-end team can implement without interpretation, with QA assertions | Ask for a redacted spec they have written |
| Consent and governance | Knows where consent sits in the datastream and what the Privacy Service does | “Where does a deletion request actually land?” |
| Analyst empathy | Designs taxonomy against questions the business asks, not against the UI | “Which eVars would you refuse to create?” |
There is a longer version of this as a scoring sheet in the Adobe Experience Platform consultant scorecard. The same logic applies here: you are hiring for migration scar tissue and modelling judgement, not for product familiarity.
Build the budget around the scope, not the vendor
Price the four scopes independently. Anchor the specialist portions against a day rate you can defend, anchor the build portion against generalist front-end cost, and keep the governance in-house where it compounds. Buy risk transfer from a partner where it genuinely transfers risk — multi-market rollouts, regulated markets, programmes that span AEM and Analytics and Platform — and buy named specialists everywhere else.
The stat that should sit on the budget cover sheet is the utilisation one. If capability use fell from 42% to 33% in a single year across the market, the default outcome for an Adobe Analytics licence is partial use. Avoiding that default is an implementation decision taken at scoping time, and it costs a fraction of the licence it protects. Specialists who have done the migration on a live estate are findable without an SOW — browse the Adobe network and brief the scope rather than the vendor.