Experience API and Multi Touch Campaigns

Commenti

1 commento

  • Commento ufficiale
    Giuseppe Lombardi

    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:

    1. 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).
    2. 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.
    3. 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
    4. 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

    Azioni per commenti Permalink

Accedi per aggiungere un commento.