Dynamic Yield Developer Documentation

Browse Dynamic Yield's latest developer documentation including API references, articles, and sample code for optimizing, personalizing, and creating consistent digital customer experiences across touchpoints.


Which Implementation is Right for Me?

As covered in the overview, there are two modes of integrating Dynamic Yield. One which purely utilizes APIs, and the other, a Web-based integration that also works side-by-side with APIs for select campaigns, aka "Hybrid Mode."

In some cases, the choice of which integration mode to use is clear.

Let's consider two scenarios:

Option 1: Starting with Web, then Adopting the API

If you're used to client-side testing & personalization tools - whether Dynamic Yield's or those of other vendors - and you wish to minimize time to value while keeping your future options open, go for the Hybrid Mode.

This gives you the opportunity to gradually implement API-based campaigns. Here are some use cases especially suited for implementation via API that we recommend starting with:

  1. Content above the fold: For page elements at the top of the page which are immediately visible when the page loads, you want to ensure minimal latency and no flicker. This is easier to achieve when calling our API from your server, as the personalized content is already included in your markup when serving the page back to the browser.

  2. Campaigns based on sensitive business information: For example, testing different pricing models. Traditionally such tests are not done via client-side A/B testing at all, in order not to expose this information in the browser. When running campaigns via API, only the chosen variation is sent to the client.

  3. Running a large number of tests: As your adoption of the platform grows, you may run dozens of campaigns concurrently, each with their own targeting rules and multiple variations. Since the details of API campaigns are not included in our client-side script (specifically, api_dynamic.js, which holds this data), the script can remain light and thus faster to load.

The Cons of Hybrid Mode:

  1. As the DY scripts are still loading in the head of all pages, the full performance benefits of the API are not achieved.

  2. In case you want to use DY for additional channels (for example mobile) with consistency to the web behavior, you could leverage the APIs for that channel alongside the script for the web.

Option 2: API Only

If one of the following issues concerns your tech teams; Impact on page load time, conflicts with SPA framework of choice, or workflow concerns (e.g. all content needs to be delivered through a certain stack of tools or process rather than being injected in browser) and you have the resources to support the API implementation, this is the way to go.

Implementing campaigns purely via API has significant advantages:

  1. No scripts to download - You can decide from which end to call our APIs (server or client) or whether to block the page rendering waiting for results or not - whatever meets your performance needs and architecture best.

  2. Best control over data collection policy - You're making the API calls, deciding exactly when to make the calls and which attributes to pass.

  3. Your code is responsible for calling Dynamic Yield to make decisions that can be deployed once and called by multiple platforms while hiding most implementation details from all these client types (web, app, hybrid, and specialized applications).

The cons are also important to note:

  1. You can't have nice things rendered automatically by our client-side script. If the dev team in your org is already busy building whole user interfaces from scratch, then adopting our API is certainly not hard. The challenge is usually to maintain a quick turnaround on ongoing business needs - creating and improving personalized components as well as expanding supported use cases into more areas.

  2. It's up to your code to generate user and session IDs and store each of them for the appropriate duration.

  3. If you want to go back to implementing web-based campaigns, there is no doing so without starting data collection afresh.

To sum up it up best in Stan Lee's own words: "With great power comes great responsibility." We don't know whether Stan had in mind rebuilding your website from the ground up using React - but the wording does seem to fit.

For Existing Customers

If you've been running with the Dynamic Yield platform for some time (based on the web integration), you probably have a trove of collected data by now. This data is highly important for advanced targeting, fine-tuning recommendation strategies, and serving personalized widgets.

To hold on to all that data, the hybrid approach is easiest: simply start creating API-based campaigns. If you have decided to go for the API-only mode due to its advantages, you'll need to create a new "Site" entity in Dynamic Yield, which would start off empty of any data.

To mitigate this, there is an option of starting data collection "in the background" for a short time while the client-script is still embedded in your website and serving campaigns. Since the amount of data collected in this time period is effectively doubled, please contact your Customer Success Manager if you're interested.

One potential caveat when considering the hybrid approach: if your servers are in the EU but your account in Dynamic Yield is using our US-based data center rather than our EU server, then API calls you make from your servers will incur the network latency of going over the ocean.

This may or may not be an issue for you depending on the use cases in your roadmap and the actual network latency you experience from your servers. Alternatively, you might decide to switch to API Only with a separate new account in our data center that's closest to you. In this case, you will enjoy the best latency but not have historical data.

When in doubt, talk to us!

Updated about a month ago

Which Implementation is Right for Me?

Suggested Edits are limited on API Reference Pages

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