Adobe Analytics RFP Template

Before You Issue a Adobe Analytics RFP

An Adobe Analytics engagement is rarely just a tagging project, and RFPs that describe it as one attract proposals priced for tagging alone. The expensive part is upstream of the code: agreeing what the business actually needs to measure, translating that into a solution design reference the whole organization can live with, and specifying a data layer your developers can maintain after the consultants leave. Ask vendors to describe how they run that discovery, not just how they deploy the Web SDK.

The other scoping decision worth making before you issue the RFP is your position on Customer Journey Analytics. Adobe's investment has visibly shifted toward CJA, so any new implementation should be scored partly on how well it sets up an eventual migration — event-driven data collection, clean schemas, no legacy props-and-eVars sprawl that will have to be untangled later.

Budget for enablement explicitly. Implementations that skip analyst training produce beautiful report suites nobody opens; a good partner will insist on adoption sessions and will name who delivers them.

What the Adobe Analytics Sections Cover

• Report suite and virtual report suite boundaries
• A solution design reference the vendor maintains, not just delivers
• Data layer ownership split between your developers and theirs
• Variance thresholds that define a passing validation
• AppMeasurement or Web SDK, and who funds the switch
• Whether Customer Journey Analytics is in scope or deferred

Writing the Adobe Analytics Scope of Work

Write the scope around the solution design reference rather than around the tag. State how many report suites are in play, whether you want a global suite with virtual report suites on top or separate suites per brand, and who signs the design off. The SDR is the contract inside the contract: it fixes the variable inventory, the events, the classification structure and the processing rules, and every estimate you receive is really an estimate of how long that document takes to agree. If you already have an SDR, attach it and say whether the engagement is extending it or replacing it.

Draw the data layer boundary explicitly, because it is the most commonly fudged line in Adobe Analytics scoping. Three arrangements are common: the vendor writes a specification and your developers implement it, the vendor implements directly in your codebase under your review, or the vendor works entirely in the tag manager and reads whatever the site already exposes. The third is cheapest and ages worst. Say which arrangement you want, whether the vendor gets repository access and a place in your release train, and who is responsible when a front-end deployment silently breaks a data layer key.

Name the surfaces. Web is assumed; mobile apps, connected TV, kiosks, call-center systems and offline uploads are not, and each carries a different implementation path through the Web SDK, the Mobile SDK or the Bulk Data Insertion API. If you are moving from AppMeasurement and legacy mbox code to the Web SDK, say so, because that is a migration project with a parallel-tagging period rather than a configuration change. Also state whether marketing channel processing rules, Activity Map and Data Feeds are in scope, since each has downstream consumers who will notice if they are quietly dropped.

Put a real out-of-scope list in writing. Typical exclusions worth naming: cleaning up a decade of abandoned props and eVars, rebuilding Report Builder workbooks and scheduled reports, admin console and SSO changes, consent management platform selection, and any Customer Journey Analytics work. Then define done in terms someone can test. Tags firing is not done. Done is the reported figures reconciling with the order or CRM system inside a tolerance you state in advance, the SDR delivered as a maintained document, and the implementation validated across your staging and production environments rather than on a single page.

Requirements That Actually Separate Adobe Analytics Proposals

• Solution design maintenance — require the SDR to be delivered in a form your own team can keep current, and ask what the vendor does when a new variable is requested after go-live: who updates the document, and how the change reaches the tag manager without drift.
• Data layer specification depth — ask for the actual key naming, typing and event-timing rules the vendor will impose, and how they handle single-page applications where a virtual page view must fire after the data layer has settled rather than on route change.
• Reconciliation tolerance — state the tolerance you will accept between Analytics revenue and your order system, and require the vendor to describe the debugging path they follow when a specific eVar or currency event drifts outside it.
• Report suite architecture reasoning — require a written recommendation on global versus regional suites, virtual report suites and roll-ups, with the consequences for segment portability, permissions and the eventual move to a CJA connection spelled out.
• Processing rule and classification handling — ask how much logic they place in processing rules and classifications versus the data layer, since rules applied at collection are invisible to anyone debugging later and cannot be reprocessed historically.
• Consent and regional variation — require an explicit description of how collection behaves under each consent state in each market you operate in, including what is dropped entirely rather than merely anonymised.
• Data Feed and Data Warehouse consumers — if downstream systems read raw hits, require the vendor to inventory those consumers first and state which schema changes would break them, because feed columns are a published interface.

Common Mistakes in Adobe Analytics RFPs

• ✕ Scoping only the tag deployment and discovering the solution design, data layer and QA phases as change orders.
• ✕ Accepting “certified team” claims without named individuals — certifications belong to people, not logos.
• ✕ Leaving the Customer Journey Analytics question out entirely, then paying twice when the migration arrives.
• ✕ No acceptance criteria for data quality at launch, so “done” means tags fire rather than numbers reconcile.
• ✕ Forgetting the handover: no SDR documentation deliverable, no admin training, no governance model.

• ✕ Scoping a Web SDK migration as a like-for-like swap when the variable mapping, consent wiring and Target integration all have to be rebuilt, and both collection paths must run in parallel while you compare them.
• ✕ Excluding mobile apps from the scope on the grounds that the website is the priority, then discovering the cross-device reporting the business actually asked for requires app instrumentation that nobody budgeted.
• ✕ Leaving currency, timezone and reporting-calendar configuration out of the requirements, so multi-market reporting is technically correct and commercially unusable from day one.
• ✕ Asking for tracking of every campaign parameter your media agencies use without deciding who owns the classification files, leaving thousands of unclassified tracking codes within a quarter.

Questions Worth Asking Adobe Analytics Vendors

1. Show a redacted solution design reference from a delivered project — how do you document variables, events and processing rules?
2. How do you validate data quality before launch, and what does your hypercare period cover in the first 30 days?
3. Who writes the data layer specification, and how do you hand it to our development team for long-term ownership?
4. What is your recommended position on migrating this implementation to Customer Journey Analytics, and on what timeline?
5. Which analysts on the proposed team will deliver training, and what does your adoption program look like after go-live?

How to Weight the Adobe Analytics Evaluation

Weight design and documentation capability above deployment speed. Tag deployment in Adobe Analytics is largely a solved problem and most credible vendors can do it; what varies enormously is whether the resulting implementation is legible in two years. A proposal that allocates serious effort to the solution design reference, the data layer specification and the validation plan is worth more than one that reaches go-live a month earlier with the design captured in a spreadsheet nobody owns. Score the artifacts you will be left holding.

Give real weight to migration posture. Adobe Analytics implementations built today are almost certainly the input to a Customer Journey Analytics connection later, and event-based collection through the Web SDK with clean schemas migrates cheaply while props-and-eVars sprawl does not. A vendor who can explain which of your existing variables would survive that transition, and which are dead weight, is demonstrating a kind of judgment that does not show up in a deployment plan.

Weight validation and enablement more heavily than you would on a pure engineering project, because the failure mode here is social rather than technical. Analytics implementations die when one stakeholder finds a number they cannot explain and the organization quietly reverts to the old report. Evidence of a structured validation pass across environments, plus a plan for teaching your analysts what each metric actually counts, protects the investment more than additional build capacity does.