Adobe Target RFP Template

Before You Issue a Adobe Target RFP

There are two different Adobe Target engagements and your RFP should say which one you are buying. One is an implementation: SDK deployment, A4T wiring, audience plumbing. The other is a program: a partner runs (and then transfers) an experimentation practice with a hypothesis backlog, test velocity targets and analysis standards. Vendors that excel at one are often mediocre at the other, and pricing differs by an order of magnitude.

If it is a program, put numbers in the RFP: tests per month, expected time-to-first-test, and the statistical standards you expect analyzes to meet. Then ask how the program transfers — the goal of a good experimentation partner is to make themselves unnecessary, and their answer to the handover question tells you whether they agree.

What the Adobe Target Sections Cover

• Monthly test volume the retainer actually buys
• at.js or Web SDK delivery, and flicker control on both
• A4T wiring so results reconcile with Analytics
• Who builds experiences — their developers or yours
• Stopping rules and the statistics behind a declared winner
• The point at which your team runs tests unaided

Writing the Adobe Target Scope of Work

State the delivery method first, because it constrains everything else. Client-side delivery through the Web SDK, server-side delivery through the delivery API, and hybrid arrangements differ in latency, flicker behavior, what content can be personalized and which team has to be involved in every test. If your site is server-rendered or built on a modern front-end framework, say so, since single-page applications need explicit view definitions and a decision about when offers are requested relative to route changes. Say which properties and which apps are in scope, and which are explicitly not.

Define the activity mix you are buying. Manual A/B tests, experience targeting, automated personalization and recommendations are different disciplines with different data prerequisites. Automated approaches need enough traffic and conversion volume per experience to train on, and recommendations need a product or content catalog with a feed, an exclusion model and a fallback for cold items. If recommendations are in scope, the catalog feed is a real integration with an owner and a refresh schedule, not a configuration step, and it should appear in the scope as such.

Scope the audience supply chain, since a personalization platform is only as good as the signals reaching it. Say which audiences come from on-page data, which from Analytics segment sharing, which from Real-Time CDP, and what latency each carries. Profile attributes uploaded in bulk have a refresh cadence that should be stated. If any personalization depends on authenticated customer data, say how identity is resolved at the point of delivery and what the experience is for a visitor whose data has not arrived yet, because the default experience is the one most people will see.

Separate the build from the running of the program in the scope even if one vendor does both, and give each its own acceptance. For the build, done means offers deliver without visible flicker at a stated threshold, reporting reconciles between Target and Analytics, and QA links work for stakeholders. For the program, done is expressed in throughput and learning: a stated number of tests reaching a decision per period, each with a documented hypothesis, a pre-registered primary metric and a written result, including the losers. Put the decision-making forum in scope, since tests that nobody acts on are an expensive hobby.

Requirements That Actually Separate Adobe Target Proposals

• Flicker mitigation approach — require the specific technique proposed for your rendering architecture, the measured delay it introduces, and what happens to the page when the offer request is slow or fails entirely.
• Traffic and power realism — ask the vendor to estimate, from your actual traffic and conversion rates, how long a test on a named page must run to detect an effect worth acting on, and which pages simply do not have the volume.
• QA and preview workflow — require a demonstration of how a stakeholder reviews an unlaunched experience across devices and audiences, since the review bottleneck is usually what limits test velocity rather than build time.
• Recommendations catalog handling — where recommendations are in scope, require the feed design, update frequency, exclusion rules and the cold-start behavior for new items to be described explicitly.
• Profile and audience latency — ask how quickly an attribute set elsewhere becomes usable for targeting at the edge, since personalization designed around data that arrives minutes later will not behave as the business expects.
• Analytics reconciliation — require a written explanation of how Target and Analytics reporting differ structurally, so that when the two disagree the team debugs the right thing rather than relitigating the platform choice.
• Experiment governance — ask for the rules they apply to stopping tests, handling overlapping activities on the same page, and preventing a personalization rule from silently contradicting another one.

Common Mistakes in Adobe Target RFPs

• ✕ Not distinguishing implementation from program, so proposals for different services get compared on price.
• ✕ No test-velocity target, letting the program drift into one over-engineered test a quarter.
• ✕ A4T reporting left unspecified, so Target and Analytics tell different stories about the same test.
• ✕ Personalization ambitions stated without the audience data to power them.
• ✕ No handover plan, creating permanent dependency on the vendor for every test launched.

• ✕ Scoping personalization ambitions that require authenticated profile data on pages where most traffic is anonymous, so the sophisticated experiences reach a small fraction of visitors and the business concludes personalization does not work.
• ✕ Omitting the page-template dependencies, so every test needs a front-end developer to add a container or stabilise a selector, and the program moves at the speed of the release train.
• ✕ Treating recommendations as an activity type rather than a data integration, leaving the catalog feed, inventory status and exclusion rules unowned until the first out-of-stock item is promoted.
• ✕ Running personalization and experimentation on the same surfaces without a rule for how they interact, so a targeted experience silently invalidates the control group of a concurrent test.

Questions Worth Asking Adobe Target Vendors

1. What monthly test velocity did your last three programs sustain, and what limited it?
2. Show a hypothesis backlog and prioritization framework from a live program (redacted is fine).
3. What are your statistical standards — minimum detectable effect, confidence thresholds, and stopping rules?
4. How do you wire Analytics for Target, and how do you reconcile when the two report differently?
5. Describe a program you transferred fully in-house: timeline, training, and what the client runs today.

How to Weight the Adobe Target Evaluation

Weight statistical judgment above tooling familiarity. Most vendors can configure an activity; far fewer will tell you that a test on your checkout page cannot reach a conclusion in under three months, or refuse to declare a winner on a metric that moved by chance. Because the deliverable of an experimentation program is decisions, a vendor's analytical honesty has more commercial consequence than their configuration speed, and the evaluation should reflect that ordering.

If you are buying a program rather than a build, weight throughput evidence and backlog quality far above case-study uplift numbers. Reported uplifts are unverifiable and usually selected; sustained test cadence, the ratio of tests that reached a decision, and the proportion that produced a negative result you can learn from are much harder to fake and much more predictive of what you will get.

Score the integration surface more heavily than on a standalone testing tool. Target sits between your delivery layer, your analytics and your audience platform, and most of its failure modes are at those seams rather than inside the product. A vendor who can describe how they will wire and validate those connections, and who has done it on a stack resembling yours, is managing the risk that actually materialises.