Experience API and Multi Touch Campaigns
What are some ways users have configured multi-touch campaigns when using the Experience API implementation? Is it possible? Is there some equivalent?
-
Official comment
Hi Kyle Beloin,
Thank you for the question!
In a traditional client-side implementation, Multi-Touch Campaigns are designed to split traffic once and then consistently apply coordinated experiences across multiple touchpoints on the website. Dynamic Yield scripts handle both the traffic allocation and the orchestration of those connected touchpoints within the UI experience.
With an Experience API implementation of Dynamic Yield, the architecture is different.
In API-based setups, Dynamic Yield is typically responsible for decisioning, while the client application (web, app, backend, middleware, etc.) is responsible for orchestration and state management across touchpoints. Because of this separation of responsibilities, there is generally no need for a dedicated “Multi-Touch API Campaign” equivalent.
That said, customers can absolutely achieve a very similar setup using coordinated API campaigns and custom attributes.
A common pattern looks like this:
- Create a single API Custom Code campaign responsible for traffic allocation
This campaign splits users into the desired variations/groups (for example: Variation A, B, or C). - Create separate API campaigns for each touchpoint with targeted experiences
For each touchpoint or placement, create a dedicated campaign with matching exoerience (A/B/C).
These experiences target users based on a custom attribute representing the allocation from step 1. -
Persist and pass the allocation value in Experience API Choose requests
Once the initial allocation is determined, the application stores that value and sends it as a custom attribute in subsequent Experience API requests, to match the Experience targeting from step 2.Example:
experience_group = A
- Render the coordinated experiences across touchpoints
Each touchpoint campaign uses the custom attribute for targeting and returns the corresponding experience for that user group, allowing the application to render a consistent multi-touch journey across the site or app.
In practice, this approach provides the same core outcome as client-side Multi-Touch Campaigns – consistent user allocation and coordinated experiences across touchpoints – while aligning with the orchestration model of Experience API implementations.
As implementation details can vary significantly depending on the customer’s architecture and integration design, we also recommend confirming the approach with your TAM, who will be more familiar with your specific implementation and can help validate the best setup for your use case.
Best,
Giuseppe
Comment actions - Create a single API Custom Code campaign responsible for traffic allocation
Please sign in to leave a comment.
Comments
1 comment