As covered in the API overview, there are two modes for integrating Dynamic Yield. One that uses only APIs, and the other, a web-based integration that also works side-by-side with APIs for select campaigns, which we call "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
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:
Content above the fold: For page elements at the top of the page that 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.
Campaigns based on sensitive business information: For example, testing different pricing models. Traditionally, such tests are not done using client-side A/B testing at all, to avoid exposing this information in the browser. When running campaigns via API, only the chosen variation is sent to the client.
Running a large number of tests: As your adoption of the platform grows, you might run dozens of campaigns concurrently, each with their own targeting rules and multiple variations. Because 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 loads faster.
The full performance benefits of the API are not achieved during the time the Dynamic Yield scripts are still loading in the heads of all pages.
Because the management of user and session IDs relies on cookies in this mode, it is not suitable for non-web environments: Mobile apps, retail locations, and so on.
Option 2: API-only
This is the best choice if and you have the resources to support the API implementation, and any of the following issues concerns your tech teams:
- Impact on page load time
- Conflicts with SPA framework of choice
- Workflow concerns (for example, all content needs to be delivered through a certain stack of tools or process rather than being injected in the browser)
Implementing campaigns purely via API has significant advantages:
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. Whatever best meets your performance needs and architecture.
Best control over data collection policy: You're making the API calls, so you decide exactly when to make the calls and which attributes to pass.
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:
You can't have nice things rendered automatically by our client-side script. If your dev team is already busy building whole user interfaces from scratch, then adopting our API shouldn't be difficult. 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.
It's up to your code to generate user and session IDs and store them for the appropriate duration.
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 decide to go for the API-only mode due to its advantages, you'll need to create a new Site entity in the Dynamic Yield console, which starts 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. Because the amount of data collected in this time period is effectively doubled, 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 uses our US-based data center rather than our EU server, 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'll enjoy the best latency but not have historical data.
When in doubt, talk to us!