Tags: experimentation web-dev platform
Adobe Target
Checked: 2026-08-16
Adobe’s testing and personalisation engine. It is not primarily an A/B testing tool that also personalises — it’s a decisioning engine that also runs A/B tests, and almost everything confusing about it follows from that.
§0 The one idea
The unit is the decision, not the experiment.
Optimizely and VWO are built around “here is a test, split the traffic, read the result”. Target is built around “a visitor arrived, decide what to show them” — where an A/B test is just the case where the decision is random.
That inversion explains the rest:
- Machine-learning activity types are first-class, not bolted on. Auto-Target and Automated Personalisation are the products Adobe actually sells
- The visitor profile is central and persistent, and can be computed server-side on every call
- Reporting is often somewhere else entirely — in Adobe Analytics, not in Target
- The vocabulary is its own, inherited from Offermatica via Omniture, and predates the industry settling on shared terms
vs Optimizely/VWO: those ask “which variant won”. Target asks “what should this person see”, and winning is one answer to that.
TARGET SAYS EVERYONE ELSE SAYS
─────────── ──────────────────
activity experiment / campaign
experience variant
offer the content itself
mbox the injection point
audience segment
profile the visitor record
VEC visual editor
A4T report in Analytics
instead of in Target
At a glance
| What it is | Testing + personalisation + recommendations |
| Sits in | Adobe Experience Cloud |
| The old library | at.js 2.x |
| The current library | Web SDK (alloy.js) — migrate to this |
| Delivery | Client-side, server-side, on-device, hybrid |
| Editors | Visual (VEC) and form-based |
| The ML activities | Auto-Target, Automated Personalisation — Premium |
| Bandit activity | Auto-Allocate — 80/20, not pure bandit |
| Reporting | Target’s own, or A4T into Analytics |
| Statistics | Frequentist. Welch’s t-test, confidence = 1 − p |
| The flicker problem | Real, and managed by a pre-hiding snippet |
The vocabulary
Learn these six and Target stops being opaque. Everything in the UI is a combination of them.
Activity — the container. A test, a targeted campaign, a personalisation programme. What everyone else calls an experiment.
Experience — one variant within an activity. A set of changes applied together.
Offer — the actual content. HTML, an image, JSON, a redirect. Offers live in a library and are reusable across activities, which is genuinely useful and is why the distinction from “experience” exists.
mbox — short for marketing box, the point on the page where content gets injected. The historical model was many named mboxes; the modern model is a single global mbox for the whole page, with targeting done by selector instead. If someone talks about “putting an mbox on the page”, they’re describing an older implementation.
Audience — a segment. Built from profile attributes, behaviour, geo, device, Analytics segments, or Real-Time CDP audiences.
Profile — the persistent visitor record. This is the part Target treats as central and most tools treat as an afterthought.
How a request actually works
The sequence that produces flicker, and the reason CRO people have opinions about Target.
page starts loading
↓
PRE-HIDING SNIPPET hides the body
↓ inline · synchronous · must be first
library loads (at.js or alloy.js)
↓
request to the Adobe Target Edge
↓ ← network round trip
decision returns · DOM modified
↓
pre-hiding style removed · page revealed
if the call is slow or fails:
a TIMEOUT fires and reveals the original
→ flicker, or the test silently not running
The pre-hiding snippet is the whole trick. It’s a small inline style block that hides the page (or a region) before anything renders, so the visitor never sees the original. Target then reveals the page once it has applied changes.
The cost is explicit: you are hiding the page on a network round trip. Get it wrong and you either flash the original — Flicker and Flash of Original Content — or you delay first paint for everyone, including the control group, which shows up directly in Core Web Vitals and can bias the test.
Migrating to Web SDK changes the snippet. The Web SDK uses a pre-hiding style ID of alloy-prehiding and is not compatible with the at.js pre-hiding snippet — a verified and commonly-missed migration step, and the failure is silent flicker rather than an error.
Activity types
This is where Target is genuinely differentiated, and where the Premium line falls.
| Activity | What it does | Tier |
|---|---|---|
| A/B Test | Fixed split, read the winner | Standard |
| Auto-Allocate | Shifts traffic to the leader while running | Standard |
| Auto-Target | Serves the best experience per profile | Premium |
| Experience Targeting (XT) | Rule-based: this audience sees this | Standard |
| Multivariate (MVT) | Tests combinations of elements | Standard |
| Automated Personalisation (AP) | ML combines offers per visitor | Premium |
| Recommendations | Product recommendation algorithms | Premium |
Auto-Allocate
The bandit-style option, and the split is worth knowing because it isn’t a pure bandit:
standard A/B 50 / 50, fixed throughout
auto-allocate 80% allocated by the
algorithm to winners
20% random across ALL
experiences
↑ this is what keeps
it learning
The 20% random floor is why it can still adapt when visitor behaviour changes, and why it doesn’t collapse onto an early false leader as hard as a naive bandit would — Multi-Armed Bandits.
Use it to reduce the cost of losing variants, not to get an answer faster. It optimises conversions during the test; it does not give you a cleaner estimate of the effect — Winner’s Curse.
Auto-Target versus Automated Personalisation
The distinction that gets muddled, and both are Premium:
AUTO-TARGET
you author whole experiences
ML picks WHICH EXPERIENCE per profile
supports full VEC, custom code,
and per-experience audiences
AUTOMATED PERSONALISATION
you author individual offers
ML assembles a COMBINATION per profile
more combinations, less control
Auto-Target is the more controllable one and supports VEC features AP doesn’t, including the custom code editor and multiple experience audiences. AP explores a larger space and is correspondingly harder to reason about.
Both are personalisation rather than experimentation: they optimise delivery and do not produce a clean causal estimate. If you need to know whether the programme worked, you need a holdout — Holdout Groups, Personalisation Tests.
Audiences and profiles
The part that’s genuinely more powerful than the competition.
SCOPE OF DATA
mbox parameter this call only
profile.attribute persists across visits
user.categoryAffinity built-in behavioural
Analytics segment shared from Adobe Analytics
RTCDP audience shared from Real-Time CDP
Profile scripts
The distinctive feature, and the one worth understanding even if you never write one.
A profile script is a JavaScript snippet Adobe runs on its own servers, on every single Target call, before the visitor is evaluated for audience and activity membership. It writes a value onto the visitor’s profile.
visitor makes a Target call
↓
ALL profile scripts execute (server-side)
↓
audiences evaluated using the results
↓
activity membership decided
↓
offer returned
What that buys you: derived attributes that no data layer has to supply — visit counts, running spend, “has viewed three products in this category”, days since last purchase. Computed centrally, available to every activity, no engineering ticket.
What it costs: they run on every call, for every visitor, forever. A slow or badly-written script is a latency tax on the whole implementation, and scripts accumulate — an old Target instance typically has dozens nobody can account for. They’re also invisible to your own analytics unless you deliberately export them.
Profile scripts are also how mutually exclusive activities are done — a script assigns a bucket, and each activity targets one bucket. Worth knowing because it’s the standard answer to “how do we stop these two tests interacting” — Interaction Effects.
Delivery methods
Four, and the choice is an architecture decision rather than a preference.
CLIENT-SIDE at.js / Web SDK in the browser
✓ visual editing, marketer autonomy
✗ flicker risk, slowest, blockable
SERVER-SIDE Delivery API / server SDKs
✓ no flicker, full ML available
✗ you render it, no visual editing
ON-DEVICE rules cached on YOUR server
✓ near-zero latency decisions
✗ simple rules only — no ML activities
artifact downloaded from a CDN
HYBRID per activity, automatically
simple rules → decided on-device
ML activities → call the Edge
On-device decisioning downloads a rule artifact to your server and decides locally with no network call. The trade is explicit and verified: it supports only the activity types expressible as static rules, so anything ML-driven still needs the Edge.
Hybrid is the answer to that trade — Target works out which activities can be decided locally and which need a server call, so you get fast simple decisions without giving up the ML ones.
Adobe’s hybrid deployment model is a genuine differentiator: a non-technical user authors in the VEC, and the experience is executed and rendered server-side. Most competitors make you choose between visual authoring and server-side delivery — Client-Side vs Server-Side Testing.
at.js → Web SDK
The live migration, and the thing to know if you join a team mid-transition.
OLD — one library per Adobe product
at.js Target
AppMeasurement.js Analytics
visitorAPI.js identity
NEW — one library for all of them
alloy.js Web SDK
Verified migration constraints, all of which bite:
- You cannot mix on a page. Web SDK for Target alongside AppMeasurement for Analytics on the same page is not supported, and running both libraries causes rendering and tracking problems. All Adobe libraries on a page migrate together
- You can migrate page by page, but you must set
idMigrationEnabledandtargetMigrationEnabledtotrueso identity and Target state carry across the boundary - The pre-hiding snippet must be swapped — different style ID, not compatible
What the migration buys: smaller footprint and better page speed, first-party IDs for longer-lived visitor identification, audience sharing from Real-Time CDP, and integration with Journey Optimizer offer decisioning.
For any team on Target, this migration is the current live topic. A team still on at.js 2.x has a project ahead of it; a team on Web SDK has probably rebuilt its whole data collection layer.
Reporting and statistics
Two reporting paths, and the choice matters more than it sounds.
TARGET REPORTING A4T
───────────────── ───
Target's own metrics Adobe Analytics metrics
fast to set up one source of truth
goals defined in any Analytics metric
Target Analysis Workspace
segment AFTER the fact
↑ the real reason
A4T — Analytics for Target — sends Target activity data into Adobe Analytics so results are reported on Analytics metrics. The decisive advantage is post-hoc segmentation: you can slice a finished activity by any Analytics segment without having pre-declared it, which Target’s own reporting can’t do.
The corresponding risk is exactly that freedom — slicing until something is significant is the classic route to a false finding, and it’s easier here than almost anywhere else — Segmentation (test results), The Multiple Comparisons Problem.
What Target’s numbers mean
Frequentist, verified. A4T uses a Welch’s t-test — a t-test that does not assume the two groups have equal variance — and reports a confidence percentage plus a confidence interval. Adobe Analytics treats all metrics as non-binary, so each visitor carries a continuous outcome and the variance is computed per experience.
The reported confidence = 1 − p-value:
p-value 0.03 → confidence 97%
p-value 0.05 → confidence 95%
p-value 0.20 → confidence 80%
In plain terms: 95% confidence does not mean there’s a 95% chance the variant is better. It means that if the two experiences were genuinely identical, you’d see a difference this large or larger less than 5% of the time. It’s a statement about how surprising the data would be under “no difference” — not a probability that you’re right — P-Values, Confidence Intervals.
Lift is the percentage difference between control and variant. The Analysis Workspace A4T panel shows lift with confidence interval bounds — worst, midpoint and best at 95%. Read the bounds, not the midpoint. A lift of “+8%” with an interval spanning −2% to +18% is not an 8% win — Reading a Test Result.
The peeking problem is live here. Target reports continuously and updates as data arrives, and a fixed-sample t-test is only valid at the sample size you planned for. Watching until it crosses 95% inflates the false positive rate substantially — Peeking, Sequential Testing, Stopping Rules, Sample Size Calculation.
Standard versus Premium
| Standard | Premium | |
|---|---|---|
| A/B, XT, MVT, Auto-Allocate | ✓ | ✓ |
| Auto-Target | — | ✓ |
| Automated Personalisation | — | ✓ |
| Recommendations | — | ✓ |
| Enterprise user permissions | — | ✓ |
The Premium line is the machine learning. Standard is a competent testing tool; Premium is what Adobe is actually selling, and it’s where the price sits.
Practical consequence: “Adobe Target experience” means very different things depending on tier. Someone who ran A/B tests in Standard and someone who ran Auto-Target programmes have done substantially different work.
Where it’s strong
- Personalisation at scale. The profile model, profile scripts and ML activities have no straightforward equivalent in the mid-market tools
- The hybrid deployment model — visual authoring with server-side delivery
- Integration with the rest of the Adobe stack. If Analytics, Real-Time CDP and AEM are already there, Target inherits audiences and reporting rather than duplicating them
- Enterprise governance — permissions, workspaces, approval
Where it hurts
- The vocabulary. Nothing is called what it’s called elsewhere, and the docs assume you already know
- Flicker management is your problem, and the pre-hiding snippet is a page-speed cost paid by every visitor including the control
- Implementation complexity. Between at.js, Web SDK, mboxes, profile scripts, A4T and the ECID, a Target implementation has many more failure modes than a VWO one
- Cost and lock-in. It’s an enterprise contract, and the ML that justifies it is Premium
- Personalisation is hard to evaluate. The ML activities optimise delivery and don’t hand you a causal estimate — you have to construct that yourself with a holdout
- Legacy debris. Long-lived instances accumulate profile scripts, audiences and dormant activities that nobody will risk deleting
Related
- Client-Side vs Server-Side Testing — the trade Target lets you take both sides of
- Flicker and Flash of Original Content — the pre-hiding snippet’s whole reason to exist
- Personalisation Tests · Holdout Groups — how to evaluate the ML activities
- Multi-Armed Bandits — what Auto-Allocate is a constrained version of
- Peeking · Sequential Testing — why continuous reporting is a trap
- Adobe Analytics · Adobe Experience Cloud — the rest of the stack