This guide outlines the end‑to‑end technical onboarding process for API‑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 production readiness.
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 Dynamic Yield 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 API or SDK use cases and placements (where personalization will be rendered)
- Recurring technical onboarding syncs are scheduled with your TAM
- Your team gets access to Experience OS and can begin implementation in a staging environment
MS2: Set up the product feed
Goal
Provide Dynamic Yield with structured, reliable product data that aligns with Experience API or SDK implementation.
Overview
Product feeds supply the catalog data used to power recommendations, targeting, and reporting across API‑based campaigns.
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 Dynamic Yield via API or SDK, validate request and response structures, and ensure readiness for production rollout.
Authentication & setup
-
Generate API keys:
- Server‑side keys for backend API calls
- Client‑side keys, where relevant
- Ensure the correct endpoint is selected (EU vs US)
SDK initialization (SDK only)
- Kotlin: Complete installation prerequisites and initialize
- Swift: Complete installation prerequisites and initialize
- React Native: Complete installation prerequisites and initialize
Choose request and pageview implementation
Purpose
Manage identifiers, report pageviews, retrieve personalized campaign variations, and render them in your application.
API requirements
Make an API call to the choose endpoint (choose request) on every pageview. In the request:
- Report a pageview (set isImplicitPageview to true)
- Pass proper page context type and data ( context.page.type / context.page.data)
- When context.page.type is PRODUCT or CART, make sure context.page.data includes the same SKU values that are passed in the feed for the corresponding product.
- When context.page.type is CATEGORY, make sure context.page.data includes the same category values that are passed in the feed for products with the same category (separated by commas).
- Pass user consent status (if required)
- Identify where campaigns should render in your application 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)
- Note that identity management for SDK is different
- Inform personalized experiences
SDK requirements
- Report pageviews
- Identify where campaigns should render in your application and make a choose variations call on those pages (each campaign is mapped to an API selector (selectorNames) defined in Experience OS)
- Kotlin
- Swift
- React Native
- Use the response payload to inform personalized experiences
- Manage user consent status (if required)
Additional considerations
Additional attributes can be included in choose request calls to support analytics integrations and response optimization (for example, limiting payload size)
Engagement tracking
Purpose
Track user interaction with API or SDK‑driven 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)
API requirements
- Send engagement events to the engagement endpoint for all rendered campaigns
- Ensure that engagement data aligns with the corresponding choose response (decisionId and slotId)
SDK requirements
Report engagements for all rendered campaigns via the Choice return object method or DYSdk object method:
Event tracking
Purpose
Capture meaningful user interactions via API or SDK 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 API logs
Staging QA
Your QA on staging
Validate the following via the API logs (API & SDK requests are visible here):
- Choose requests return correct variations and include proper data
- Engagements are reported correctly
- [SDK only] Pageviews are reported accurately, without errors
- Events fire with valid schemas
- The product feed aligns with API responses
- User and session identifiers persist correctly
- Consent is passed accurately (if required)
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 Dynamic Yield in production
Goal
Deploy the Dynamic Yield API or SDK implementation to the production environment.
What happens
- API or SDK integrations are enabled in production
- Requests begin executing on live user traffic
Exit criteria
- Dynamic Yield API or SDK implementation is live in production.
MS5: Production QA
Goal
Confirm the production environment behaves as expected and that data is accurate.
Your QA on production
Validate the following via the API logs (API & SDK requests are visible here):
- Choose requests return correct variations
- Engagements are reported correctly
- [SDK only] Pageviews are accurate
- Events fire with valid schemas
- The product feed aligns with API responses
- User and session identifiers persist correctly
- Consent status is passed accurately (if required)
Dynamic Yield implementation validation on production
To complete implementation validation for mobile apps, you must provide the .ipa file (for iOS) or (.apk/.aab) file for Android. The Dynamic Yield QA team validates the implementation in 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 completed successfully
- Data validation is completed successfully
MS6: Technical onboarding complete
Outcome
- API or SDK implementation is complete
- Data is validated and reliable
- Account is ready for:
- Use case and campaign execution
- Onboarding additional Dynamic Yield products (if relevant)
This milestone marks the official completion of technical onboarding.