Dynamic Yield for Developers Hub

Welcome to the Dynamic Yield for Developers Hub. Here, you'll find comprehensive guides and documentation to help you start working as quickly as possible. Let's jump right in!

Get Started    

Implementation Checklist


Here are a few things which are normally done once, and then not frequentl changed afterward:

  1. Decide on the user & session identifiers you will use. If unsure, please refer to Best Practices.

  2. Create API keys for your application. If you want to call the API directly from the client-side, choose whether to use a JWT or client-side API key (see the link), or alternatively have your server-side act as a proxy for the client, so that it will perform all reporting on behalf of clients. This latter option does involve more work, but is actually quite popular: it plays well with centralizing the reporting of user actions to multiple downstream systems, and with hiding implementation details and keys from the client.

  3. Make sure your product feed is up and running, as is kept synchronized with Dynamic Yield.

It is good practice to ensure you're reporting any new page rendered (a.k.a. location or screen depending on the framework) and important events before starting to run campaigns. This is crucial for building user audiences and running any campaigns later on.

Choosing Campaign Variations & Reporting Pageviews

Reporting a pageview, and choosing campaign variations relevant for that page, are best done with a single call to the choose API endpoint, for minimal latency. You can also later asynchronously can call choose with for any campaigns that can be displayed after the page has rendered. In such a case, make sure to set the implicit pageview parameter to false when making these calls, as mentioned below.

Typically, the implementation workflow looks like this:

  1. Integrate a choose call in all pages types in your application with the proper page context, without referring to any campaign yet.

  2. Along with the business user responsible for managing campaigns in your organization (be it Marketers, Product Managers, Merchandisers, or other relevant roles), identify the places in your application where Dynamic Yield-managed campaigns should run. Any campaign that you run will have a known API Selector Name which you'll use to get the chosen variation.

  3. Now, adapt your call to choose in each page type to fetch the selected variations for all campaigns which are part of rendering that page. By default, that call also handily causes a new page view to be reported, since all the needed context is passed to us in the request already.

Any subsequent calls to choose which are asynchronous should be made with "options": { "isImplicitPageview": false } in the request body.

For all you need to know on choose, see the detailed guide. There is an option to only report a pageview using a dedicated API endpoint, typically asynchronously - see the link for more.

Reporting Events

  1. Report Important Events. This typically includes cart and purchase operations in case of eCommerce, video views in the world of media, and any other events custom to your needs. Note that if you only report events from your server-side, it is easier to avoid "noise" generated by bots and such.

Tracking and Reporting User Engagement with Variations

  1. As part of running campaigns in the page, you should store the unique identifiers returned in the response from the choose API. This is typically done on the client side. When a user then clicks on a variation or a specific recommended product, you'll need to pass these identifiers back to us.

    • For a click on a custom variation, that would be the decisionId (and also the variationIds only in case of multi-variation campaigns such as sliders).
    • For a click on a recommended item, this would be the slotId.

On the web, it is common to store these as data attributes on the DOM element that is rendering the variation, e.g. <div id= ... data-dy-decision-id="d512ae8f">.

  1. Set up on-click listeners on all rendered variations and report any clicks to Dynamic Yield, using the unique identifiers above. This step is almost always initiated from the client-side, but can be proxied from your server-side to our API to avoid having too much logic (or keys) in clients.

Enabling Preview Support

  1. While not technically a must, it's really strongly recommended to do this "one more thing" and add the code to support previewing content straight from the Admin UI.

Updated 2 months ago

Further Reading

Creating Keys

Implementation Checklist

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.