This guide outlines the end‑to‑end technical onboarding process for script‑based Dynamic Yield implementations, organized by technical onboarding milestone. Each milestone includes its purpose, required actions, and completion criteria to help your teams move confidently from kickoff to go‑live.
Milestones
An implementation timeline is defined by your team and provided to your Technical Account Manager (TAM) to mark the following milestones:
- MS1: Begin implementation
- MS2: Set up the product feed
- MS3: Implementation & QA on staging
- MS4: Deploy Experience OS in production
- MS5: QA on production
- MS6: Technical onboarding complete
MS1: Begin implementation
Goal
Align on business objectives and technical scope before development work begins.
What happens in this phase
- Technical requirements that will impact implementation are defined with your Customer Success Manager (CSM):
- Events to be tracked
- Product feed requirements
- Initial use cases
- Recurring technical onboarding syncs are scheduled with your TAM.
- Your team gets access to the Dynamic Yield system, Experience OS, and can begin implementation in the staging environment.
MS2: Set up the product feed
Goal
Provide Dynamic Yield with structured, reliable product data that aligns with onsite behavior and events.
Overview
Product feeds supply the catalog data used to power recommendations, affinities, targeting, and reporting.
Required feed fields
Your feed must include the following, at minimum:
→ See our Dev Docs for details about mandatory columns
- SKU
- Product Name
- Product URL
- Price
- Category
- Group ID
- Image URL
- In‑stock status (with correct data type)
Key decisions & considerations
-
Feed format: CSV, JSON, or XML
- Files larger than 180 MB or 200,000 products must be CSV
- Sync method: Live URL, Amazon S3, SFTP, or API
- Feed update cadence (affected by file size and format)
- Multi‑language columns (if applicable)
- Additional custom columns to support targeting and recommendations (for example, color, size, material, discount %, sale flag)
→ See our Dev Docs for details on creating and syncing CSV or API-based product feeds.
Alignment requirements
- Product feed SKUs must match:
- Product page context data
- Cart page context data
- Product IDs reported in events
- Product feed categories should align with category page context data.
Optional: Feed parsing
If the source feed requires adjustments prior to ingestion, set up a feed parser.
Exit criteria
- Feed is successfully syncing to Dynamic Yield
- Feed data is validated (required and agreed‑upon attributes are present)
- SKUs and categories align with site context and events
MS3: Implementation & QA on staging
Goal
Implement all required Dynamic Yield scripts, validate data schema accuracy, and ensure readiness for production.
Script and infrastructure implementation
Dynamic Yield script
- Add the script to the <head> of every page
- The script must load after page context and cookie consent scripts (extremely important)
- Validate using the Implementation Helper
DNS preconnect
- Implement DNS preconnect tags as high as possible in the <head>
- Tags must load before the Dynamic Yield script
→ This improves performance and loading efficiency
ITP (Safari) solution
- To mitigate Apple’s 7‑day cookie expiration policy:
- Duplicate the _dyid value into a server‑side cookie (_dyid_server)
- Set a 1‑year expiration
- Validate according to Dynamic Yield developer documentation
Cookie consent (if required)
- Determine whether you need to implement active user consent mode
- Consent logic must execute before Dynamic Yield initializes
Page context implementation
Purpose
Ensures the correct experiences run on the correct pages and that behavioral data is accurately collected.
Requirements
- Page context must be placed before the Dynamic Yield script
- Supported page types:
- Homepage
- Category
- Product
- Cart
- Other
- Context data/attributes should be included and validated according to the page type
→ Validate using the Implementation Helper - Multi‑locale sites must include locale (lng), where applicable
- Single page applications (SPAs): Update page context on route change (triggers a Dynamic Yield re‑execution for each virtual pageview)
Event tracking
Purpose
Capture meaningful user interactions for targeting, reporting, and A/B testing.
Required events
For e-commerce sections:
For financial institution sections:
Omni-channel events (highly recommended)
These events are fired upon identification moments:
- Login
- Signup
- Newsletter Subscription
- Identify User (used in any other identification scenario)
Omni-channel events help you identify users across devices, and require using a consistent customer unique identifier (CUID).
Recommended CUID identifier type: SHA‑256 encoded, lowercase email address.
Custom & optional events
- Dynamic Yield has predefined event schemas for additional common events
- Any other events can be set up as custom events
Requirements
-
Required and additional events are fired consistently with the necessary data
→ Validate using the Implementation Helper
For sections using APIs: Authentication & setup
Generate API keys:
- Server-side keys for backend API calls
- Client-side keys, where relevant
Ensure the correct endpoint is selected throughout implementation based on the primary region (EU vs US)
For sections using APIs: Choose request
Purpose
Retrieve personalized campaign variations from Dynamic Yield and render them within your website.
Requirements
Make an API call to the choose endpoint (choose request) on every pageview:
- Report a pageview
→ Pass isImplicitPageview as false so that pageviews aren’t reported (this is handled by scripts) - Pass proper page context type and page context data that matches the script implementation
- Pass user consent status (if required)
- Identify where campaigns should render within your website and include the campaign selector in the choose request on those pages (each campaign is mapped to an API selector defined in Experience OS)
Use the response payload to:
- Manage identifiers (_dyid, _dyjsession, _dyid_server)
- Inform personalized experiences
For sections using APIs: Engagement tracking
Purpose
Track user interaction with API campaigns.
Types of engagement
Campaign-level interactions:
- Impression events (IMP)
- Click events (CLICK)
Product-level interactions (slot-level engagement for recommendation campaigns):
- Slot impression event (SLOT_IMP)
- Slot click event (SLOT_CLICK)
Requirements
- Engagement events must be sent to the engagement endpoint for all rendered campaigns
- Engagement data must align with the corresponding choose response (decisionId and slotId)
Staging QA
Your QA on staging
Review and validate the following:
- Script and context order
- ITP solution
- Cookie consent implementation
- Page context accuracy across pageviews
- Product feed syncing and category alignment
- Events are firing with valid schemas
If you're using APIs, validate the following via the API logs:
- Choose request calls return correct variations and include proper data
- Engagements are reported correctly
- User and session identifiers persist correctly
- Consent status is passed accurately in calls (if required)
→ Use the Implementation Helper to validate scripts, context, and events.
→ Resolve all warnings or errors before Dynamic Yield validation.
Dynamic Yield validation on staging
The Dynamic Yield QA team validates implementation on the staging environment, and your TAM returns results with details about any required fixes. Additional rounds of validation can be completed as necessary.
Exit criteria
- All Dynamic Yield validation checks pass on staging
- Approval is received to proceed to production rollout
MS4: Deploy Experience OS in production
Goal
Deploy Experience OS to the production environment. This includes core implementations, including scripts, context, events, and the product feed, not campaigns or use cases.
What happens
- Scripts and configuration are released to production
Exit criteria
- Experience OS is live in production
MS5: Production QA
Goal
Confirm the production environment behaves as expected and that data is accurate.
Your QA on production
Review and validate the following:
- Script and context order
- ITP solution
- Cookie consent implementation
- Page context accuracy across pageviews
- Product feed syncing and category alignment
- Events are firing with valid schemas
If you're using APIs, validate the following via the API logs:
- Choose request calls return correct variations and include proper data
- Engagements are reported correctly
- User and session identifiers persist correctly
- Consent status is passed accurately in calls (if required)
- Use the Implementation Helper to validate scripts, context, and events
- Resolve all warnings or errors before DY validation
→ Use the Implementation Helper to validate scripts, context, and events.
→ Resolve all warnings or errors before Dynamic Yield validation.
Dynamic Yield implementation validation on production
The Dynamic Yield QA team validates implementation on the production environment, and your TAM returns results with details about any required fixes. Additional rounds of implementation validation can be completed as necessary.
Dynamic Yield Data validation on production
To complete data validation, you must provide a file of purchase transactions from a 24–48 hour timeframe (post go‑live). This file must include order totals/revenue and transaction IDs (IDs must match uniqueTransactionId in Dynamic Yield purchase events). Ideally, this file comes from a trusted analytics platform (for example, GA or Adobe).
Dynamic Yield validates the purchases in the file against those collected via Dynamic Yield events and shares details about any discrepancies. Additional rounds of data validation can be completed as necessary, with a goal of at least a 95% match rate.
Exit criteria
- Implementation validation is successfully completed
- Data validation is successfully completed
MS6: Technical onboarding is complete
Outcome
- Script implementation is complete
- Data is validated and reliable
- Account is ready for:
- Use case execution
- Onboarding additional Dynamic Yield products (if relevant)
This milestone marks the official completion of technical onboarding.