This article is aimed at technically oriented dynamic yield users
In todays market, where user retention is dictated by both site performance and personalised experiences, businesses often face two opposing opinions - prioritising site performance versus delivering highly personalised content.
On the one hand, personalisation teams want to be completely independent from development teams and launch perfectly curated creatives for each user during sales periods, special offers or other meaningful events that don’t line up with the development delivery cycles. Additionally, content teams typically already use an independent tool for content management and would like to avoid learning how to work in a new platform and maintaining two separate sources of content.
On the other hand, development teams want to have control over what and how content is displayed to ensure that the user’s experience is cohesive throughout the site and delivered flawlessly.
The use of the Experience API functions of Dynamic Yield in combination with your CMS of choice can meet the needs of both groups to deliver highly personalized content in a way that is optimized for performance. This configuration can be done in parallel with typical client-side scripted campaigns.
Use Case Example
A typical scenario that would lead to a need for such integration is a case where a large amount of personalised content has to be delivered to smaller user segments. For example, the content team would like to deliver homepage banners that are personalised based on:
- User’s gender
- User’s affinity to a product group
- User’s affinity to a specific colour.
Assuming that a typical e-commerce store offers at least 5 different product groups in 5 different colors for 2 genders, the number of variations would already increase to 50 different banners. To create such a campaign manually, each gender and color variant would have to be managed separately by creating the content, exporting it and uploading it to the corresponding variants in Dynamic Yield. This is not only inefficient, but also requires regular maintenance and could potentially lead to human error.
The benefits of using an automated CMS integration would decrease the time spent on the creation and maintenance of this campaign by:
- Making the campaign structure much leaner and easier to oversee
- Decreasing the maintenance time to minimum - in case the content needs to be changed at some point during the campaign runtime, there would be no need to interfere with the setup as the changes would come directly from the CMS.
Such a setup would generally consist of 3 parts:
- App - renders the content
- CMS - holds creatives
- Dynamic Yield - acts as a decision-making engine
The sequence diagram below describes the actions and data flow starting from the user’s first interaction with the website:
From an integration perspective, the App would communicate with Dynamic Yield via the Experience API - by requesting a decision for a specific campaign. This request would include user data (user ID) which let’s Dynamic Yield make the best decision based on the experience targeting within the campaign.
Before starting to implement the setup, it’s important to consider how the handling of different user groups (e.g., opted-out users, logged in users, guests) would be carried out!
Dynamic Yield Setup
All Dynamic Yield decisions are campaign-based. Whenever a decision is required from Dynamic Yield, a corresponding campaign must be stored in the platform that can be queried by the application, as Dynamic Yield cannot send information proactively. Such campaigns can contain numerous targeted experiences for personalization as well as multiple variations for A/B testing.
In this case, each experience is targeted to users in specific weather conditions during the current day - Rainy, Cloudy or Sunny. Each experience also includes 2 variations to test which creative performs better for each weather type.
It’s always best practice to include a “Fallback” experience - to make sure users who don’t match any of the other targeting conditions get served some content.
As opposed to typical API campaigns, the variations in Dynamic Yield would not contain, e.g., URLs to actual banner content. Instead, the campaign response would contain an ID or name of the content that can be found in the respective CMS.
After receiving an API request from the App, Dynamic Yield would perform calculations to determine which variation should be displayed:
- Which experience does the user belong to?
The API request to Dynamic Yield contains a user ID and additional user information. Dynamic Yield uses this property to retrieve user data from databases (for targeting based on audience, event, etc.) or to serve data from the user's browser or location (for targeting based on location, device, etc.)
- Which variation should be displayed to the user?
- In case of A/B testing, the decision will be based on the traffic split defined in the experience
- In case of Dynamic Allocation, the decision will depend on which variation has the best chance of converting the user.
After that, Dynamic Yield will return a decision to the App containing information about which content should be displayed to the user.
Rendering Content to the User
In our example case we have defined that the marketing content in our CMS can be identified by content ID (e.g., 112233-sun-version_b).
Once the decision is received from Dynamic Yield, the App would have to fetch the chosen creative from the CMS - depending on the integration, this would most likely be a form of an API request, where the App looks for a specific ID and renders it to the user once it’s found.
For the best performance, it is recommended to fetch the decision from Dynamic Yield before any rendering is done on the site (as soon as the user makes the first contact with the App) to minimise any flickering or visible content shifting.
Another important step is to add engagement tracking to the rendered content - this would mean sending data back to Dynamic Yield to report how users interact with each od the decisions. This is important for:
- User data collection - to help identify specific user characteristics (e.g. users who click on Variation A generally prefer cheerful messages)
- 2. Campaign data collection - to determine the A/B test winner or help allocation more traffic to the best performing variation in case of Dynamic Traffic Allocation.
The exact steps on how to implement tracking are described in the Dynamic Yield API Reference .
Eliza Suhareva is a Technical Team Lead at Up Reply, specialising in development and solutions architecture consulting. With a deep technical expertise in Dynamic Yield's capabilities, she helps clients integrate personalisation and optimisation into a variety of platforms to drive omni-channel user engagement and retention. For the blog, Eliza will share insights and best practices on technical implementation and hands-on execution plans.