Docs › Adobe Target ›Business Cheatsheet
Target Business Cheatsheet
Plain-English guide to running experiments and reading results in Adobe Target — no technical background needed. Every concept comes with a real-world example.
Activity Types
A/B · MVT · XT · AP · RecsBefore you run anything in Target, you pick what kind of experiment makes sense. Think of these as five different science-fair project formats — same goal (figure out what works best for visitors), different methods.
A/B Test
One control, one or more variants, one winner
- •Traffic is split evenly between the control and all variants (A/B/C/D etc.)
- •After enough visitors, compare which version got more purchases, sign-ups, etc.
- •The winning version then shows to everyone
- •Best when each variant tests the same single change in different ways
You change your checkout button from 'Submit Order' to 'Get My Stuff!' and run it for 2 weeks. The new button gets more clicks and completions — it wins, you ship it to everyone.
Multivariate Test (MVT)
Test many changes at once
- •You test multiple elements (headline + image + button) simultaneously
- •Target figures out which combination of changes performs best
- •Needs far more visitors than a regular A/B test
- •Only practical on your highest-traffic pages
You test 2 headlines × 3 images × 2 buttons = 12 combinations. After 6 weeks, Target identifies that Headline B + Image 2 + Red Button wins — something you'd never find with separate A/B tests.
Experience Targeting (XT)
Show different content to different people
- •Not a test — you already know what each audience should see
- •You set a rule: if visitor is from Canada, show the CAD pricing page
- •Runs indefinitely with no end date needed
- •Think of it as a permanent personalization rule
Logged-in loyalty members always see a 'Members Exclusive' banner. Anonymous visitors see a 'Join & Save' prompt. No testing — you just set the rule once and it runs forever.
Auto-Personalize (AP)
Let the algorithm figure out who sees what
- •You upload multiple content variations; the algorithm tests them all simultaneously
- •Over time it learns which variation performs best for each visitor profile
- •No hypothesis needed — the machine explores for you
- •Needs ~1,000+ conversions/month to train; always keep a 10% control group
You create 8 different homepage hero banners. AP tests them all for a month, then automatically routes each visitor to the banner most likely to convert them — based on their browsing history, location, and device.
Recommendations
'You might also like…' for your website
- •Automatically surfaces products or content based on what each visitor views or buys
- •Common algorithms: recently viewed, frequently bought together, top sellers
- •You set the logic; Target handles the real-time matching
- •Requires a product or content catalog — your dev team sets this up once
A visitor looks at running shoes. Recommendations automatically shows: 'People who viewed this also bought running socks, foam rollers, and a hydration vest' — just like Amazon does it.
Audiences & Targeting
Profile · Behavior · Geo · Time · CDP · ScriptsAn audience in Target is just a rule that describes a group of visitors. You can show different experiences to different audiences — or limit a test to only run for a specific group. Here are the six types of rules you can build.
Visitor Profile
Who they are
- •New visitor vs. returning visitor
- •Loyalty tier, CRM segment, or account type
- •Custom attributes like "has made 3+ purchases" or "gold member"
- •Your dev team passes these attributes to Target at login
You want to test a loyalty upgrade prompt — but only for Silver-tier members. You build an audience rule: show this test only when loyalty_tier = 'silver'. Gold and Bronze members never see it.
Behavioral
What they've done on your site
- •Pages visited, products viewed, or categories browsed
- •Cart abandonment — added something but never checked out
- •Campaign source from UTM parameters (came from a specific email or ad)
- •Number of past visits or sessions
A visitor viewed your pricing page three times this week but never started a trial. You target them with a 'Still thinking it over? Get a free demo' banner — only them, not everyone.
Geo & Device
Where they are and how they browse
- •Country, state/province, or city
- •Mobile, tablet, or desktop
- •Browser type (Chrome vs. Safari) or operating system
- •Great for currency, language, and shipping-related personalization
Mobile visitors in the US see a 'Download our app — easier on your phone!' banner. Desktop visitors see nothing. You set this once; Target detects the device automatically.
Time & Date
When they visit
- •Day of week (weekdays vs. weekends)
- •Time of day (morning rush vs. evening browse)
- •Specific date range for a sale or seasonal event
- •Combine with other rules for precision (e.g. weekend + mobile)
Your Black Friday deals page shows a live countdown timer only from Nov 25–29. On Nov 30 the timer disappears automatically — no one has to manually turn it off.
Third-Party Audiences
Segments from your other marketing tools
- •Import segments from Adobe Audience Manager or Real-Time CDP
- •Use audiences built from your email, ads, or CRM data
- •Visitors who opened a specific email can see a matching on-site experience
- •Requires a one-time integration setup with your dev team
Your email tool flags everyone who clicked the 'Summer Sale' email. That list gets shared with Target. When those exact people visit your site, they see the Summer Sale homepage — matching what they clicked.
Profile Scripts
Custom rules your dev team writes
- •Small JavaScript snippets that Target runs on every visit
- •Can compute things Target can't track natively
- •Examples: "visited pricing page 3+ times", "cart value over $200"
- •Once written, you use them as normal audience rules — no code needed from you
Your devs write a script: if a visitor has spent over $500 lifetime, flag them as 'high_value = true'. Now you can target that audience in any activity — show them early product access, free shipping, or a VIP banner.
Writing a Brief
Hypothesis · Metric · MDE · Traffic · DurationA test brief is the document you fill out before your dev team touches anything. It forces you to answer the hard questions upfront — what are you changing, why do you think it will work, and how will you know if it did? Skipping this is the most common reason tests produce meaningless results.
Hypothesis
Your educated guess, written as a sentence
- •Format: "Because [observation], if we [change], then [metric] will [improve] because [reason]"
- •Forces you to explain WHY you think the change will work — not just what it is
- •If you can't fill in the "because" at the end, the hypothesis is too weak
- •One hypothesis per test — testing two things at once means you can't explain the result
'Because visitors don't see our free shipping offer until checkout, if we add a shipping banner to the product page, then checkout starts will increase because shipping cost is their #1 objection.'
Primary Metric
The one number that decides the winner
- •Choose this before launch — changing it midway is cheating (called p-hacking)
- •Common choices: checkout completion rate, trial sign-ups, revenue per visitor
- •Pick only ONE — if you track ten metrics, you'll find something significant by chance
- •Secondary metrics are useful to understand WHY, but they don't decide the winner
Your test changes the pricing page layout. Your primary metric is 'started a free trial.' Secondary metrics (time on page, scroll depth) help you understand the result but can't override it.
Minimum Detectable Effect (MDE)
How big a lift are you actually looking for?
- •The smaller the improvement you want to detect, the more traffic and time you need
- •A realistic MDE for most websites: 5–15% relative improvement
- •Plug your MDE into a free sample size calculator before you start
- •Chasing a 0.5% improvement requires millions of visitors — be honest about your scale
Your checkout converts at 3% today. A 10% relative improvement = 3.3% — that's your MDE. A sample size calculator says you need 18,000 visitors per variant. Your site gets 5,000/week, so plan for 4+ weeks.
Traffic Allocation
How you split visitors between versions
- •50/50 is the standard split for a simple A/B test
- •For Auto-Personalize, always keep at least 10% as a control group
- •Never change the split after the first visitor enters — it invalidates your data
- •Unequal splits like 90/10 are valid but take much longer to reach significance
You're nervous about showing a radical redesign to too many people. You set it to 10% variant, 90% control. Fine — but know it'll take 5x longer to get enough variant visitors to draw a conclusion.
Test Duration
How long to run before you even look at results
- •Minimum: 2 full business cycles — typically 2 weeks
- •Never stop because you see a lift on day 3 — early results are almost always misleading
- •Always include at least one full weekend if weekend traffic behaves differently
- •Planned duration = your sample size target ÷ daily unique visitors on the test page
Your sample size calculator says you need 20,000 visitors per variant. Your test page gets 2,000 unique visitors/day. That's 10 days — but round up to 14 (2 full weeks) to catch all visitor patterns.
Pre-Launch Checklist
QA · Goals · Audience · Metric · Sample · ExclusionsEvery item here takes 10–30 minutes to verify. Skipping any one of them can corrupt your entire test — bad data, zero conversions tracked, or real customers seeing broken experiences. Run through this list the day before every launch.
QA in staging
- •Click through every experience yourself — control AND all variants
- •Check on a real mobile device, not just browser dev tools
- •Look for layout breaks, missing images, or a flash of the original content
- •Confirm the VEC can load your URL — blocked iframes make the editor show a blank page
Open an incognito window, force yourself into the variant experience (your dev can show you how), and pretend you're a customer. Does the new banner show? Does the page look right on your iPhone?
Goals fire correctly
- •Your dev opens the browser network tab and completes the goal action
- •You should see a Target conversion request fire — not silence
- •If the goal is a purchase, confirm it fires once — not twice
Your goal is 'clicked Add to Cart.' Have your dev open Chrome DevTools → Network, filter by 'tt.omtrdc.net', then add an item to cart. A request should appear immediately. If not, the goal is broken and your test will show 0 conversions forever.
Audience targeting verified
- •Use Target's audience preview tool to confirm the right visitors qualify
- •Test the edge cases: someone who just barely qualifies, and someone who shouldn't
- •If the test is for returning visitors, verify a new visitor is excluded
Your test is for returning visitors only. Sign in with a brand-new test account — you should NOT see the variant. Sign in with an account that has past purchase history — you SHOULD see it. Both checks pass? Ship it.
Primary metric locked
- •Write the primary metric in the brief before any visitor enters the test
- •Get sign-off from whoever will review results — before launch, not after
- •After launch, this metric is frozen — changing it invalidates everything
You and your VP agree in writing: 'This test wins if checkout completion rate improves by 5%+.' Three weeks later when results are mixed, your VP can't move the goalposts to 'but look at the bounce rate improvement.'
Sample size estimated
- •Use a free online sample size calculator (Evan Miller's is popular)
- •Inputs: your current conversion rate, your target lift (MDE), 95% confidence
- •Output: visitors needed per variant → divide by daily traffic to get duration
Calculator says you need 15,000 visitors per variant. Your test page gets 1,500 unique visitors/day. That's 10 days per variant — run for 14 days to cover full weekly patterns. Block your calendar.
Exclusions set
- •Exclude your office IP address — your team's QA clicks will skew the data
- •Exclude known test/bot accounts from conversion reporting
- •Ask your dev to confirm these exclusions are active before launch
Your team of 20 QA-tested the experience 50 times each. That's 1,000 fake visits contaminating your test. Excluding your office IP takes 5 minutes and prevents weeks of bad data.
Report Metrics Glossary
CVR · Lift · Confidence · RPV · Significance · BoundsWhen you open a Target report, six numbers stare back at you. Here's what each one actually means — and more importantly, what action it should prompt. Don't declare a winner until you understand all of them.
Conversion Rate (CVR)
The raw score for each version
- •Out of everyone who saw that version, what % completed your goal?
- •Control CVR vs. variant CVR — that gap is what you're measuring
- •Higher is better for most goals
- •Your baseline CVR determines how long the test needs to run
Control: 100 visitors, 3 purchases = 3% CVR. Variant: 100 visitors, 4 purchases = 4% CVR. The variant is outperforming — but is that difference real or just luck? That's what the next metrics tell you.
Lift
How much better (or worse) the variant is
- •Positive lift = variant beat control. Negative lift = variant lost
- •Expressed as a relative % improvement: (variant CVR − control CVR) ÷ control CVR
- •Always pair lift with confidence — a 20% lift at 60% confidence means nothing
- •Think in dollars: a 5% lift on a $5M channel = $250K/year
Control CVR: 3%. Variant CVR: 3.6%. Lift = (3.6−3) ÷ 3 = 20% relative lift. Sounds big. But if confidence is only 71%, this is almost certainly noise — don't ship it yet.
Confidence
How sure are we the lift is real?
- •95% means: if we ran this test 100 times, 95 times the variant would genuinely win
- •Below 95% = not enough evidence to act — wait for more data
- •Above 99% = very strong signal — you're unlikely to be wrong
- •Confidence only goes up as you collect more visitors — time is your friend
Think of it like a coin flip. Flip 10 times and get 7 heads — maybe it's a fair coin, maybe not. Flip 1,000 times and get 700 heads — now you're confident something's off. More visitors = more confidence.
Revenue Per Visitor (RPV)
Total impact, not just purchase rate
- •CVR only counts who bought. RPV also captures how much they spent
- •A variant with lower CVR but higher RPV is still a winner if revenue is your goal
- •More variable than CVR — needs significantly more traffic to reach significance
- •Use RPV as your primary metric when order values vary widely
Control: 3% CVR, average $40 order → $1.20 RPV. Variant: 2.5% CVR, average $60 order → $1.50 RPV. The variant converted fewer people but made more money per visitor. RPV tells the true story.
Statistical Significance
Is the result real, or could it be random luck?
- •A result is significant when it's unlikely to have happened by pure chance
- •Not the same as confidence — significance says it's real; confidence says how sure
- •A result can be significant but tiny — a 0.01% improvement is real but useless
- •Always ask: is the lift both significant AND meaningful enough to act on?
You flip a coin 10,000 times and get 5,100 heads. That's statistically significant — almost certainly not a fair coin. But would you bet your business on a coin that's 51% heads? Significance ≠ importance.
Lift Bounds
The range of what the lift probably really is
- •Also called a confidence interval — shows the upper and lower bound of the lift estimate
- •Wide bounds (e.g. −2% to +18%) = collect more data before deciding
- •Narrow bounds (e.g. +6% to +10%) = stable estimate, you can act on this
- •If the lower bound crosses zero, the result is not significant
Your lift shows +8%, but the bounds are −3% to +19%. That means the true lift could be anywhere from a 3% loss to a 19% win. You genuinely don't know yet — keep the test running.
Calling a Winner
Criteria · Early stopping · Flat results · Post-win · NoveltyThe hardest part of running tests isn't launching them — it's knowing when to stop and what to do next. These five cards cover the most common mistakes and the right way to close out a test.
When to declare a winner
- •95%+ confidence — not 85%, not 91%
- •Ran for at least 2 full business cycles (usually 14+ days)
- •Hit your pre-planned sample size — not just "feels like enough"
- •The lift is practically meaningful, not just technically significant
95% confidence ✓, 18 days ✓, 32,000 visitors ✓, +12% lift on checkout ✓ — ship it. But if any one of those boxes is unchecked, you extend the test, not declare a winner.
Never stop a test early
- •Checking results daily and stopping when you see something good is called "peeking"
- •Peeking inflates false positives — you'll declare winners that aren't real
- •Early results fluctuate wildly before sample sizes stabilize
- •Set a calendar reminder for the planned end date and don't look until then
Day 3: variant shows 99% confidence and +25% lift. You're excited. You stop the test. Day 14 data (had you waited): 62% confidence, +4% lift — not significant. You shipped a loser. This happens constantly.
What to do when results are flat
- •Flat = your change didn't matter to visitors — that's a valid, useful finding
- •Ask: was the change visible enough? Did it address a real friction point?
- •Next test: go bigger — change the entire layout, not just the button color
- •Document the flat result; it prevents your team from retesting the same thing in 6 months
You tested a new headline. Flat result. Why? Because visitors barely scrolled past the hero image — they never even saw your headline. The real problem is above the fold, not the copy. Now you know.
After a win
- •Roll out the winning experience to 100% of traffic immediately
- •Document: what changed, what the lift was, and what you think explains it
- •Run a follow-up test — can you push the improvement even further?
- •Add the result to a shared learnings library your whole team can access
Your new checkout flow won with +14% completion. You roll it out, document 'urgency messaging near the CTA drives checkout,' and immediately brief a follow-up test: does adding a trust badge increase it further?
Novelty effect trap
- •When something changes on a site, curious visitors click it just because it's new
- •That spike makes week-1 results look better than the long-term reality
- •By week 3, returning visitors have seen it before — the novelty wears off
- •Always segment your report: do new AND returning visitors both show a lift?
Week 1: +18% lift on your new mega-menu. Everyone's excited. Week 3: +2% lift, falling. Why? New visitors still like it, but returning visitors ignore it. A true win holds across both groups.
Common Gotchas
SRM · Seasonality · Interaction · Edits · Mobile · Priority · Segments · LosersThese mistakes don't break the test — they produce results that look valid but aren't. Every one of them has caused teams to ship a loser or kill a real winner.
Sample ratio mismatch (SRM)
Your split doesn't match what you set
- •You set 50/50 but report shows 63/37 — that data is contaminated
- •Causes: bot traffic, caching layers serving one variant more, or an audience rule misfiring
- •Check visitor counts for each experience on day 1 and after any site changes
- •If the split is off by more than 1–2%, pause and investigate before reading results
You set up a 50/50 test and launch. Day 3: Control has 8,400 visitors, Variant has 5,100. Something is filtering variant traffic before it reaches your page. The result is meaningless until fixed.
Testing during atypical periods
Holiday and sale traffic behaves nothing like normal
- •Black Friday, Cyber Monday, product launches, major news events all skew behavior
- •Results during anomalous periods don't generalize to normal weeks
- •Either exclude those dates from analysis or plan tests around them
- •Mark atypical periods in your test calendar before you launch
You run a checkout flow test over Thanksgiving week. Variant wins with +22% lift. You ship it. The next four normal weeks show +1% lift — not significant. Holiday urgency was the real driver, not your change.
Two tests on the same page at once
Visitors can be enrolled in both simultaneously
- •A visitor might see Variant A from Test 1 AND Variant B from Test 2 — a combo you never designed
- •Either test can contaminate the other's results
- •Use activity exclusion groups or priority rules to prevent overlap
- •If overlap is unavoidable, run tests sequentially instead
You run a hero image test and a CTA button test at the same time. Visitors who see both are in an untested hybrid experience. If one test loses, you can't tell if it lost because of the variant or the combination.
Editing a live activity
Any mid-test change invalidates the combined data
- •Changing targeting rules, content, or goals after launch creates pre/post cohorts
- •Mixing pre-change and post-change data produces a result that represents neither
- •If you must change something, stop the test, note what you saw, and start fresh
- •The only safe mid-test edit is fixing a broken goal that records 0 conversions
Your test runs for 5 days with flat results. You tweak the variant headline. After 9 more days it shows a lift. Was it the headline? The original variant? The combined data can't tell you.
Shipping a desktop winner without checking mobile
A positive overall lift can hide a negative mobile result
- •A +15% overall lift can be +24% desktop and −8% mobile
- •Always segment your report by device type before rollout
- •Shipping a desktop win to all traffic can actively hurt mobile revenue
- •If results diverge by device, run separate tests for each — or roll out only to the winning device type
Your redesigned product page wins overall. You ship it. Mobile revenue drops 6% the next week. The variant worked for desktop shoppers but the layout was too cluttered for small screens. You should have checked.
Activity priority conflicts
Overlapping activities have a silent tiebreaker
- •If two activities target the same visitor and page, Target uses a priority number (0–999) to pick one
- •Default priority is 0 — the most recently modified activity wins ties, which you probably don't track
- •Set explicit, distinct priority numbers on any overlapping activities
- •Check the Collision report in Target to see which visitors are being suppressed
You have a homepage A/B test (priority 0) and a holiday promotion (priority 0) running at the same time. Half your visitors only see the promotion; the other half only see the A/B test. Neither gets full traffic.
Post-hoc segment wins aren't findings
Slicing results after the fact is hypothesis generation, not validation
- •"Variant B won for iOS users in California aged 25–34" is not a validated result
- •You didn't randomize that segment separately, so confounders exist
- •The more segments you look at, the more likely one appears significant by chance
- •Treat post-hoc segment wins as the hypothesis for your next dedicated test
Your test is flat overall. You slice every way possible and find iOS users in the Northeast show +31% lift. You ship to them. Follow-up test: +2%, not significant. The original result was noise in a small segment.
Keeping a clear loser running out of 'fairness'
95% confidence to call a winner — but no rule says you must run a proven loser
- •If a variant shows 98% confidence of being worse with a large negative lift, every day it runs costs real revenue
- •Set a pre-specified stop rule for losers in your test brief before launch
- •A reasonable rule: stop if variant reaches 95%+ confidence of losing with >5% negative lift
- •Document the stop, the data at the time, and your reasoning — don't just quietly kill it
Your variant has been at 96% confidence of losing with −12% lift for 8 days. You wait for the 'full' 14-day run. That's 6 more days of real visitors getting a provably worse experience. Stop it.