Build 7 · Target
This tool across the project What Target needs in every phase, from kickoff to handoff, next to the sign-off gate for that phase.
Phase Target Gate (all tools) 1. Initiation (RFP / kickoff) Edition, sites, testing goals RFP response; sponsor and team named 2. Discovery (current & future state) Current implementation, past tests, traffic levels Current State Assessment; Future State Blueprint — Discovery sign-off 3. SOW & plan Implementation plus first activities SOW signed: scope, deliverables, timeline, price 4. Design (SDR / SDD) Roadmap, audiences, A4T, properties/workspaces SDR + SDD — Design sign-off 5. Build & configure Implementation → properties → audiences → activities → goals → QA links Configured environment — Build Complete sign-off 6. QA / UAT Flicker, metric on every variant, audience bucketing QC checklist executed — UAT sign-off 7. Go-live Activate first activities Production cutover — Go-Live sign-off 8. Hypercare (2–4 weeks) Traffic split, page performance Daily monitoring; fixes — Hypercare Exit sign-off 9. Closure & handoff Results repository, roadmap process, governance Handoff pack: runbooks, access list, training, open backlog
Implementation overview Phase What you do Deliverables Define Testing/Personalization Strategy Prioritized roadmap, KPI alignment with Analytics Testing roadmap, KPI doc Implement Target at.js/alloy.js via Launch, mbox/view calls, anti-flicker snippet Implementation doc Configure Audiences Target rules, Analytics/AEP segments, audience sharing Audience library Build Activities A/B, Experience Targeting (XT), MVT via Visual Composer Activity design brief Configure Recommendations/AP Recommendation criteria, Automated Personalization models Recommendations criteria doc QA Activities Preview across devices/browsers, metric capture validation Pre-launch QA checklist Launch & Monitor Traffic allocation, statistical significance tracking Activity monitoring dashboard Analyze & Iterate Call winners, document learnings, feed next roadmap cycle Test results repository
AI agent note: The Data Engineering Agent spans AJO for pipeline/event troubleshooting. Brand Concierge is Adobe’s conversational, agent-driven customer-facing layer — relevant if you’re evaluating adding a conversational entry point to journeys rather than only trigger-based automation. Treat any agent-generated journey logic as a draft: run it through the QC checklist above before activating.Step-by-step implementation Do these 11 steps in order, in a development environment. Each step lists where to go, what to do, what to check, what you must know, and the questions interviewers ask about it.
Where Outside Target — prioritization workshop
What you do Score test ideas with ICE/PIE, write a hypothesis for each, and tie each to an Analytics KPI.
Tips Agree the significance method and sample size before launch.
Check before moving on Prioritized roadmap signed off. Must know Every test starts from a hypothesis: "If we change X for audience Y, metric Z improves because...". Prioritize tests by impact, confidence and effort, and check traffic is enough to reach significance. Agree one primary success metric per test before building it. Interview questions tap to reveal a model answer How do you build a testing roadmap? Collect ideas from data and stakeholders, write hypotheses, score them (impact, confidence, effort), check traffic, then schedule.
What makes a good hypothesis? A specific change, a target audience, an expected effect on a named metric, and the reason you expect it.
How do you know if you have enough traffic? Use a sample size calculator with baseline conversion, minimum detectable lift and confidence level.
Screenshot Testing roadmap / hypothesis sheetAdd screenshots/target/step-01.png
Where Data Collection > Datastreams > add Adobe Target service (Web SDK via Tags); or Administration > Implementation for at.js
What you do Add Target to the datastream and fire personalization through the Web SDK (or deploy at.js via Tags).
Tips Add the pre-hiding (anti-flicker) snippet and check Core Web Vitals.
Check before moving on Target requests visible in the Debugger. Must know Target can be implemented with at.js or with Web SDK (Target enabled in the datastream). Flicker (original content showing before the test content) is prevented with a pre-hiding snippet and synchronous or early loading. Single-page apps need view-change notifications so Target applies changes on route changes. Interview questions tap to reveal a model answer at.js vs. Web SDK for Target? at.js calls Target directly; Web SDK sends one Edge call that returns Target decisions alongside other services. Web SDK is the strategic path.
What causes flicker and how do you fix it? Default content renders before Target's changes apply; fix it with a pre-hiding snippet and loading the library early in the head.
How does Target work on a single-page app? Views are triggered on route changes (e.g. triggerView in at.js or the equivalent Web SDK call) so Target applies the right experience.
Screenshot Datastream Target service / implementation settingsAdd screenshots/target/step-02.png
Where Administration > Properties; Admin Console workspaces
What you do Create properties for each site/app and assign users (enterprise permissions, if licensed).
Tips Keeps teams from editing each other’s activities.
Check before moving on Users see only their workspace. Must know Properties and workspaces (enterprise permissions, Target Premium only) limit which sites and teams each user can change. Roles (Observer, Editor, Approver, Publisher) control who can launch activities. Set this up before many activities exist; retrofitting permissions is painful. Interview questions tap to reveal a model answer What are properties and workspaces in Target? Properties scope activities to channels or sites; workspaces group properties and users so teams only see and edit their own work.
Who should be allowed to activate tests? Only approvers or publishers, after QA sign-off, to avoid untested experiences going live.
Why does this matter for a multi-brand airline? Each brand team can work independently without touching another brand's live tests.
Screenshot Properties listAdd screenshots/target/step-03.png
Where Audiences > Create Audience (or audiences shared from AEP/RTCDP)
What you do Create rule-based audiences (geo, device, visit, profile) or use shared RTCDP audiences.
Tips Reuse library audiences instead of activity-only ones where possible.
Check before moving on Test profile qualifies for the audience. Must know Audiences can come from Target rules, Analytics, or AEP/RTCDP (shared through the Target destination). Avoid overlapping audiences in the same location unless you set priorities. For regulated industries, never build audiences on sensitive data. Interview questions tap to reveal a model answer Where can Target audiences come from? Target's own rules (browser, location, parameters), Analytics segments, and AEP/RTCDP audiences shared via the Target destination.
Two activities target the same page and audience. What happens? Priority decides which experience a visitor gets; conflicting activities should be resolved before launch.
How would you target loyalty Gold members? Share a Gold-tier audience from RTCDP to Target, or use a profile attribute passed in the Target call.
Screenshot Audience builder rulesAdd screenshots/target/step-04.png
Where Activities > Create Activity > A/B Test > Visual > enter URL
What you do Pick the activity type (A/B, Experience Targeting, MVT) and open the page in the Visual Experience Composer.
Tips Use the Form-Based Composer for apps, email or server-side.
Check before moving on Page loads in the VEC. Must know Pick the activity type by goal: A/B Test, Auto-Allocate, Auto-Target, Experience Targeting, Multivariate, Automated Personalization, Recommendations. Choose the Visual Experience Composer for page changes, or the form-based composer for code, JSON offers and non-web channels. Decide the reporting source (Target or Analytics for Target) before activating. Interview questions tap to reveal a model answer A/B test vs. Experience Targeting? A/B splits traffic randomly to compare experiences; Experience Targeting shows each defined audience its own experience without a random split.
When would you use Auto-Allocate? When you want to send more traffic to the winning experience as soon as it starts winning, rather than waiting for a fixed split to finish.
VEC vs. form-based composer? VEC edits the page visually; form-based delivers code or JSON offers to locations, useful for SPAs, apps and server-side.
Screenshot Create activity dialogAdd screenshots/target/step-05.png
Where Visual Experience Composer > Experience B
What you do Edit text, images, layout or code for each variant; name the activity.
Tips Keep one hypothesis per test so results are readable.
Check before moving on Variants render correctly on desktop and mobile view. Must know Keep the control experience unchanged so you have a true baseline. Change one main idea per experience so the result is interpretable. Check every experience on mobile and desktop. Interview questions tap to reveal a model answer Why keep a control? Without an unchanged baseline you cannot measure lift.
Test five changes at once in one experience? Only if you accept you will not know which change caused the result; otherwise use separate tests or an MVT.
How do you build an experience for an SPA? Use the form-based composer or VEC with views, delivering changes when the relevant view loads.
Screenshot VEC with Experience B editsAdd screenshots/target/step-06.png
Where Activity > Targeting
What you do Choose the audience and set traffic allocation (manual split, Auto-Allocate or Auto-Target).
Tips For low-traffic B2B pages consider XT instead of strict A/B.
Check before moving on Allocation matches the design. Must know Targeting decides who enters the activity and the traffic split between experiences. Keep the split even for A/B tests unless there is a reason not to. Exclude internal traffic from live results. QA traffic is reported separately in Target, but with A4T it does land in your live report suite. Interview questions tap to reveal a model answer How do you split traffic? Set the allocation per experience (often 50/50 for two experiences) and the share of the eligible audience entering the activity.
Why not send 90% to the variant? It slows learning about the control and increases risk if the variant is worse; use Auto-Allocate if you want adaptive traffic.
How do you keep employees out of results? Exclude by audience (IP or internal flag) and use QA links for testing; remember QA hits still reach Analytics when A4T is the reporting source.
Screenshot Targeting step flow diagramAdd screenshots/target/step-07.png
Where Activity > Goals & Settings
What you do Set the primary goal (conversion, clicked element, revenue), reporting source (Target or Analytics/A4T) and priority.
Tips A4T lets you analyze the test with Analytics segments.
Check before moving on Goal metric fires for every variant. Must know One primary goal metric; add secondary metrics for guardrails (e.g. bounce, revenue per visitor). Analytics for Target (A4T) lets you use Analytics metrics and segments as the reporting source. Set the sample size and run time before launch and do not stop early. Interview questions tap to reveal a model answer What is A4T? Analytics for Target: using Adobe Analytics as the reporting source, so any Analytics metric or segment can be used to analyse the test.
Why not stop a test as soon as it looks significant? Peeking inflates false positives; run until the planned sample size and full business cycles are reached.
What secondary metrics would you track on a booking test? Revenue per visitor, ancillary attach rate and drop-off at payment, to make sure the primary win is not hurting something else.
Screenshot Goals & Settings stepAdd screenshots/target/step-08.png
Where Activity Overview > QA links
What you do Open QA links for every experience across browsers and devices; confirm metric capture.
Tips QA links don’t pollute reporting.
Check before moving on Pre-launch checklist complete. Must know QA links let you preview each experience without entering the live activity. Target reports QA traffic separately (the QA Mode Traffic environment), but with A4T those hits go to the live report suite. Check flicker, rendering, every metric firing, and correct audience bucketing. Test on real devices and browsers. Interview questions tap to reveal a model answer How do you QA a Target activity? Use activity QA links for each experience, check rendering on devices, confirm metrics fire in Debugger, and verify audience rules.
Do QA visits count in reports? Not in Target's live report; QA traffic is kept separate. With A4T, though, QA hits are sent to the live Analytics report suite, so segment them out.
What is the most common Target QA issue? Flicker or a goal metric that never fires, which makes the test unreadable.
Screenshot QA link previewAdd screenshots/target/step-09.png
Where Activity Overview > Activate; Reports tab
What you do Activate and check after 24–48 hours that traffic split is correct; monitor toward significance.
Tips No early peeking — stop only at the agreed sample size.
Check before moving on Allocation verified. Must know Activate after QA and approval, then watch traffic split and errors in the first hours. Check page performance has not degraded. Pause immediately if an experience breaks a key flow. Interview questions tap to reveal a model answer What do you check right after activation? Visitors entering each experience, an even split, metrics recording, and no errors or performance drop.
The split is 70/30 instead of 50/50. Why? Caching, a broken experience, audience rules or redirect issues; investigate before trusting results.
When would you pause a live test? If it breaks checkout or booking, shows wrong prices, or causes a large drop in a guardrail metric.
Screenshot Activity report with confidenceAdd screenshots/target/step-10.png
Where Reports (Target or Analytics A4T); results repository
What you do Call the winner or a no-difference result, document learnings, and feed the next roadmap cycle.
Tips A “no difference” result is still a useful finding.
Check before moving on Results logged. Must know Read lift and confidence for the primary metric, then guardrails and segments. Record every result, including losses, in a results repository. Turn winners into permanent changes or personalization, then plan the next test. Interview questions tap to reveal a model answer How do you read a test result? Check the primary metric's lift and confidence, confirm sample size, review secondary metrics, then look at key segments.
A test is flat. Is that a failure? No. It shows the change does not matter, saving development effort; record it and move on.
What happens to a winning experience? Ship it permanently through the site code or keep it in Target as an Experience Targeting activity while development catches up.
Screenshot Final results reportAdd screenshots/target/step-11.png
Sources (UI paths checked against Adobe Experience League, Oct 2026 — menus can move between releases; confirm in your org): test create ab · ab audience
Implementation by domain How to use: do each step in your sandbox using the “How to do it” column, then read across the row to see how the same step changes by domain. Each domain column follows one scenario from top to bottom. Add a screenshot and what you learned in the last column.
Travel & Airlines E-commerce & Retail Healthcare BFSI Media & Telecom Manufacturing / B2B
Travel & Airlines · practice brand: SkyLumen Airways Lab use case: Search results test
Profile: B2C, seasonal, multi-currency/locale. Compliance focus: GDPR (EU travelers), loyalty program data, real-time pricing/inventory sensitivity.
What changes in this domain: Pre-trip, day-of, post-trip journeys; real-time flight/booking-change triggers
Special considerations: Time-zone-aware send windows; urgent transactional overrides marketing cadence
Hypothesis & roadmap Showing the cheapest nearby date raises bookings.
How (any domain): Score ideas (ICE/PIE); write hypothesis and success metric.
Check: Hypothesis and metric written down.
Screenshot Hypothesis & roadmap · Travel & AirlinesAdd screenshots/target/travel-01.png Implement Target Works inside the search results app.
How (any domain): Add Target to the datastream (Web SDK) or deploy at.js via Tags; add the pre-hiding snippet.
Check: Target calls visible in the debugger.
Screenshot Implement Target · Travel & AirlinesAdd screenshots/target/travel-02.png Audiences Loyalty tier from RTCDP; market.
How (any domain): Audiences > Create, or shared RTCDP audiences.
Check: Test visitor lands in the right audience.
Screenshot Audiences · Travel & AirlinesAdd screenshots/target/travel-03.png Create activity A/B test on search results.
How (any domain): Activities > Create Activity > A/B Test (or XT/MVT) > Visual > URL.
Check: Activity opens in the composer.
Screenshot Create activity · Travel & AirlinesAdd screenshots/target/travel-04.png Experiences Nearby cheaper date banner.
How (any domain): Edit Experience B in the composer.
Check: Variants render on desktop and mobile.
Screenshot Experiences · Travel & AirlinesAdd screenshots/target/travel-05.png Targeting, traffic & goals 50/50; goal: booking; watch price volatility.
How (any domain): Pick audience, traffic split, primary goal, reporting source (A4T).
Check: Goal fires for every variant.
Screenshot Targeting, traffic & goals · Travel & AirlinesAdd screenshots/target/travel-06.png QA Check in two markets/currencies.
How (any domain): QA links for every experience across browsers and devices.
Check: Pre-launch checklist done.
Screenshot QA · Travel & AirlinesAdd screenshots/target/travel-07.png Run & analyse Control for fare changes during the test.
How (any domain): Activate; confirm split after 24–48 h; stop only at the agreed sample size; document results.
Check: Result logged with learnings.
Screenshot Run & analyse · Travel & AirlinesAdd screenshots/target/travel-08.png
E-commerce & Retail · practice brand: Cartwell Lab use case: Product page test
Profile: B2C, high volume. Compliance focus: PCI-DSS (payment data), GDPR/CCPA, cookie consent, high-cardinality product catalogs.
What changes in this domain: Cart abandonment, browse abandonment, post-purchase, replenishment journeys
Special considerations: Peak-season send-volume planning (holiday throttling)
Hypothesis & roadmap Showing delivery date near the price raises add-to-cart.
How (any domain): Score ideas (ICE/PIE); write hypothesis and success metric.
Check: Hypothesis and metric written down.
Screenshot Hypothesis & roadmap · E-commerce & RetailAdd screenshots/target/retail-01.png Implement Target Check flicker on product pages; Core Web Vitals.
How (any domain): Add Target to the datastream (Web SDK) or deploy at.js via Tags; add the pre-hiding snippet.
Check: Target calls visible in the debugger.
Screenshot Implement Target · E-commerce & RetailAdd screenshots/target/retail-02.png Audiences New vs. returning; RTCDP high-value shoppers.
How (any domain): Audiences > Create, or shared RTCDP audiences.
Check: Test visitor lands in the right audience.
Screenshot Audiences · E-commerce & RetailAdd screenshots/target/retail-03.png Create activity A/B test on a product template.
How (any domain): Activities > Create Activity > A/B Test (or XT/MVT) > Visual > URL.
Check: Activity opens in the composer.
Screenshot Create activity · E-commerce & RetailAdd screenshots/target/retail-04.png Experiences Delivery date block added.
How (any domain): Edit Experience B in the composer.
Check: Variants render on desktop and mobile.
Screenshot Experiences · E-commerce & RetailAdd screenshots/target/retail-05.png Targeting, traffic & goals 50/50; goal: add to cart, then revenue.
How (any domain): Pick audience, traffic split, primary goal, reporting source (A4T).
Check: Goal fires for every variant.
Screenshot Targeting, traffic & goals · E-commerce & RetailAdd screenshots/target/retail-06.png QA Check on product pages with long names.
How (any domain): QA links for every experience across browsers and devices.
Check: Pre-launch checklist done.
Screenshot QA · E-commerce & RetailAdd screenshots/target/retail-07.png Run & analyse Watch seasonality skew in peak weeks.
How (any domain): Activate; confirm split after 24–48 h; stop only at the agreed sample size; document results.
Check: Result logged with learnings.
Screenshot Run & analyse · E-commerce & RetailAdd screenshots/target/retail-08.png
Healthcare Lab use case: Find-a-doctor page test
Profile: B2C (patients) + B2B (providers, payers). Compliance focus: HIPAA, HITRUST, consent-first data collection, no PHI in standard analytics tools without a BAA-covered environment.
What changes in this domain: Appointment reminders, care-gap nudges built only on consented, non-PHI attributes
Special considerations: Extra legal review of message copy; opt-out must be immediate and honored across channels
Hypothesis & roadmap A simpler search form increases appointment requests. Non-clinical content only.
How (any domain): Score ideas (ICE/PIE); write hypothesis and success metric.
Check: Hypothesis and metric written down.
Screenshot Hypothesis & roadmap · HealthcareAdd screenshots/target/health-01.png Implement Target Exclude patient-portal pages entirely.
How (any domain): Add Target to the datastream (Web SDK) or deploy at.js via Tags; add the pre-hiding snippet.
Check: Target calls visible in the debugger.
Screenshot Implement Target · HealthcareAdd screenshots/target/health-02.png Audiences All visitors — no health-based audiences.
How (any domain): Audiences > Create, or shared RTCDP audiences.
Check: Test visitor lands in the right audience.
Screenshot Audiences · HealthcareAdd screenshots/target/health-03.png Create activity A/B test on the find-a-doctor page.
How (any domain): Activities > Create Activity > A/B Test (or XT/MVT) > Visual > URL.
Check: Activity opens in the composer.
Screenshot Create activity · HealthcareAdd screenshots/target/health-04.png Experiences Compliance approves both variants’ copy.
How (any domain): Edit Experience B in the composer.
Check: Variants render on desktop and mobile.
Screenshot Experiences · HealthcareAdd screenshots/target/health-05.png Targeting, traffic & goals 50/50; goal: appointment request.
How (any domain): Pick audience, traffic split, primary goal, reporting source (A4T).
Check: Goal fires for every variant.
Screenshot Targeting, traffic & goals · HealthcareAdd screenshots/target/health-06.png QA Check nothing patient-related is in the URL.
How (any domain): QA links for every experience across browsers and devices.
Check: Pre-launch checklist done.
Screenshot QA · HealthcareAdd screenshots/target/health-07.png Run & analyse Report requests; no individual-level analysis.
How (any domain): Activate; confirm split after 24–48 h; stop only at the agreed sample size; document results.
Check: Result logged with learnings.
Screenshot Run & analyse · HealthcareAdd screenshots/target/health-08.png
BFSI Lab use case: Application form test
Profile: B2C + B2B. Compliance focus: PCI-DSS, SOX, GLBA, strict PII handling, fraud/KYC constraints on data sharing.
What changes in this domain: Statement-ready, fraud-alert, product-eligibility journeys
Special considerations: Transactional vs. marketing message separation (regulatory)
Hypothesis & roadmap Fewer fields on step 1 raise completed applications. No rate personalization.
How (any domain): Score ideas (ICE/PIE); write hypothesis and success metric.
Check: Hypothesis and metric written down.
Screenshot Hypothesis & roadmap · BFSIAdd screenshots/target/bfsi-01.png Implement Target Only public pages; never authenticated banking pages.
How (any domain): Add Target to the datastream (Web SDK) or deploy at.js via Tags; add the pre-hiding snippet.
Check: Target calls visible in the debugger.
Screenshot Implement Target · BFSIAdd screenshots/target/bfsi-02.png Audiences All visitors; no audience based on financial data.
How (any domain): Audiences > Create, or shared RTCDP audiences.
Check: Test visitor lands in the right audience.
Screenshot Audiences · BFSIAdd screenshots/target/bfsi-03.png Create activity A/B test on application step 1.
How (any domain): Activities > Create Activity > A/B Test (or XT/MVT) > Visual > URL.
Check: Activity opens in the composer.
Screenshot Create activity · BFSIAdd screenshots/target/bfsi-04.png Experiences Fields removed from step 1.
How (any domain): Edit Experience B in the composer.
Check: Variants render on desktop and mobile.
Screenshot Experiences · BFSIAdd screenshots/target/bfsi-05.png Targeting, traffic & goals 50/50; goal: completed application.
How (any domain): Pick audience, traffic split, primary goal, reporting source (A4T).
Check: Goal fires for every variant.
Screenshot Targeting, traffic & goals · BFSIAdd screenshots/target/bfsi-06.png QA Check the form still validates.
How (any domain): QA links for every experience across browsers and devices.
Check: Pre-launch checklist done.
Screenshot QA · BFSIAdd screenshots/target/bfsi-07.png Run & analyse Compliance reviews the result before rollout.
How (any domain): Activate; confirm split after 24–48 h; stop only at the agreed sample size; document results.
Check: Result logged with learnings.
Screenshot Run & analyse · BFSIAdd screenshots/target/bfsi-08.png
Manufacturing / B2B Lab use case: Landing page CTA test
Profile: B2B, long sales cycles. Compliance focus: Account-based data models, CRM/ERP integration depth, smaller but higher-value data volumes.
What changes in this domain: Lead-nurture, event-follow-up, renewal-reminder journeys tied to account stage
Special considerations: Longer wait steps (days/weeks); sales-notification steps into CRM
Hypothesis & roadmap A shorter form raises demo requests.
How (any domain): Score ideas (ICE/PIE); write hypothesis and success metric.
Check: Hypothesis and metric written down.
Screenshot Hypothesis & roadmap · Manufacturing / B2BAdd screenshots/target/b2b-01.png Implement Target Marketing site only.
How (any domain): Add Target to the datastream (Web SDK) or deploy at.js via Tags; add the pre-hiding snippet.
Check: Target calls visible in the debugger.
Screenshot Implement Target · Manufacturing / B2BAdd screenshots/target/b2b-02.png Audiences Target industry (via firmographic data).
How (any domain): Audiences > Create, or shared RTCDP audiences.
Check: Test visitor lands in the right audience.
Screenshot Audiences · Manufacturing / B2BAdd screenshots/target/b2b-03.png Create activity Experience Targeting if traffic is low.
How (any domain): Activities > Create Activity > A/B Test (or XT/MVT) > Visual > URL.
Check: Activity opens in the composer.
Screenshot Create activity · Manufacturing / B2BAdd screenshots/target/b2b-04.png Experiences 3-field form instead of 7.
How (any domain): Edit Experience B in the composer.
Check: Variants render on desktop and mobile.
Screenshot Experiences · Manufacturing / B2BAdd screenshots/target/b2b-05.png Targeting, traffic & goals XT or 50/50; goal: demo request.
How (any domain): Pick audience, traffic split, primary goal, reporting source (A4T).
Check: Goal fires for every variant.
Screenshot Targeting, traffic & goals · Manufacturing / B2BAdd screenshots/target/b2b-06.png QA Check form submissions still reach Marketo.
How (any domain): QA links for every experience across browsers and devices.
Check: Pre-launch checklist done.
Screenshot QA · Manufacturing / B2BAdd screenshots/target/b2b-07.png Run & analyse Expect weeks to reach significance.
How (any domain): Activate; confirm split after 24–48 h; stop only at the agreed sample size; document results.
Check: Result logged with learnings.
Screenshot Run & analyse · Manufacturing / B2BAdd screenshots/target/b2b-08.png Full task list Every numbered task from your board, grouped by phase. Use it as the project checklist once you know the steps above.
Strategy 2 tasks Implementation 3 tasks Audiences 2 tasks Activities 4 tasks Recommendations/AP 2 tasks QA 3 tasks Launch 2 tasks Analyze & Iterate 3 tasks QC / validation checklist Key terms and sources Each term links to Adobe's documentation.
