What's in this page
- The core capabilities of Dynamic Yield
- Why are API-based products becoming popular
- The different options for implementing Dynamic Yield in your website and apps
Dynamic Yield: A Short Introduction
Since 2012, Dynamic Yield has offered a one-stop-shop personalization platform with an ever-growing array of features across desktop and mobile web, mobile apps, and email.
Rather than being an analytics tool, our strength has always been in collecting rich data about user behavior and then allowing marketers to take action based on that data. Instead of serving the same content for everyone, our customers are now using A/B testing, Multi-Arm Bandits, and rich targeting capabilities for running dynamic banners, overlays and notifications, recommendation widgets, and much more.
Our core capabilities are the combination of:
-
Audience creation and ad-hoc targeting using a wide selection of conditions: real-time and long-term behavior, device properties, geolocation, uploaded first-party data, and even the weather forecast. Here's a short video.
-
A Decision Engine based on Bayesian statistics powering A/B Tests, Automatic Traffic Allocation with Multi-Arm Bandits, and Predictive Targeting.
-
A Recommendation Engine that's deeply integrated with our A/B testing and targeting capabilities so that recommendation strategies can be continuously tweaked and optimized.
-
Templates allowing marketers and developers to collaborate on re-using design & code: a developer would create a template (typically comprised of HTML, CSS, and Javascript), placing variables where the marketer should simply need to fill in the blanks. Over time, we've built dozens of customizable out-of-the-box templates:
Implementing Dynamic Yield: The Web-Based Approach
Since the beginning, the most notable requirement from our customers was the freedom to experiment. Rather than being tied to the capabilities of their Content Management System (CMS) or eCommerce platform, our end-users in marketing and product wanted to easily:
- Change that static creative with an A/B test
- Show an overlay with a special offer, but only to relevant users
- Sprinkle a bit of Social Proof
- Re-order the main navigation bar based on a user's known affinities
...and all that without needing to secure development time for each and every test from their super busy dev teams. Typically, a marketer would only need the assistance of an in-house template developer, or one of our implementation partners.
Of course, the process of getting a third-party product integrated into your web or mobile app is almost never completely hassle-free. The onboarding phase usually requires deeper IT involvement: we need to know the context of each page viewed, receive significant events and their details, as well as be able to access and periodically sync with an up-to-date product catalog. We offer integrations with many common platforms to automate or greatly simplify the process.
Here's how it works:
How our client-side script is downloaded and run in HTML pages
What the customer needs to do:
-
Provide an up-to-date product feed to Dynamic Yield, typically via a secure URL that you determine.
-
Add links to our CDN-based client-side scripts in the
<head>section of all pages in your site. -
Let us know what's going on by setting a page context variable in the page, plus calling our client-side API to report any significant events.
What our script does automatically:
-
Calls our serving layer to get personalized user data and recommendations, determines the chosen variations based on targeting rules, and visually renders the chosen variation. The script can sustain time-outs and errors using the default experiences defined in the data from CDN.
-
Automatically reports any page views to our Collection Layer servers, plus captures and reports impressions and clicks over the displayed variations.
We also offer a Mobile SDK that is based on the same script code behind the scenes, including on-device decision making based on data from CDN. The SDK provides a programmatic API over these scripts to iOS and Android app developers, adding mobile-only features such as push notifications.
For details on this type of implementation, please visit our Knowledge Base.
The Shift Towards APIs
Whether you support the claim that APIs are eating the world or not, a few major trends are now clear:
- More and more websites, many of which used to be based on classic server-side-rendering-and-some-jQuery, are now built or re-built as Single Page Applications (SPAs) using React and similar frameworks. Progressive Web Applications (PWAs) and "Hybrid" mobile apps are also gaining a foothold.
Cool frameworks of the day: React, Angular, Vue.
-
Developers are moving to unite much of the logic powering both their web and mobile apps into one core set of server-side services, some of which are designed as micro-services or serverless functions. These core server-side services carry out as much logic as possible and return the same logical payloads to all platforms.
-
Despite the relative ease of implementation, customers are increasingly ready to look beyond using third-party client scripts, due to both page load time and privacy concerns associated with the use of cookies.
It's no wonder demand for APIs and SDKs is rising, both on the client- and the server-side. We've designed our API to be called from either side or both, based on your architecture and bearing your security concerns in mind.
Using only the API vs. Using Both API and Web
Fear not: there is no need to go "all in" with the API approach.
You can use the API in any website where our client script is integrated, and create campaigns of both types running in parallel over the same user base. We use the term "Hybrid Mode" to describe this approach.
The hybrid approach allows marketers to keep enjoying all the out-of-the-box visual tools coming with DY’s client-side script, and create onsite experiences without little to no IT resources (and that's where our cool templates really come into play).
At the same time, you can run API-based campaigns where you need them the most, adopting them in a pace that fits you. This is beneficial both for existing customers wishing to make a gradual move towards using API Campaigns, and for new customers who often prefer to have a simple implementation first and see the business value before committing more development resources.
Here's a quick primer on the two approaches.
API-Only Mode
In API-Only Mode, your server and/or client apps securely interact with our API Gateway, passing the details of the current page and asking for relevant campaign variations and recommendations. Our "classic" client script is not integrated in your website at all.
The response is a JSON payload, which can either be based on a built-in schema (in case of recommendations), or a customer-defined payload (for Custom API Campaigns). It is then the caller's responsibility to parse the response and act on it, performing all needed rendering. The client also needs to report back any engagement with the chosen variations or significant user events. Unlike in the Web Mode, it's also your job to define and store user & session IDs (see Basic Concepts).
Hybrid Mode: Using the API and Web Together
In Hybrid Mode, you both integrate our client-side scripts and call our APIs. Each method is responsible for a subset of the running experiences, but all are running for the same users and potentially for the same page.
There is no special account type that needs to be created to use both. Once our client-script is integrated, you can start calling the API when and where you wish to use it.
Which Should I Choose?
Before integrating Dynamic Yield, you need to decide whether to go for the Web-based implementation (allowing API calls as needed) or an API-Only implementation.
There is an important difference between these implementation methods in how User and Session identifiers are managed, and so there is currently no way to switch between implementations later on without start all data collection afresh.
The implementation type is set when creating a "Site" entity in our Web UI. This is usually done by our Customer Success personnel when setting up your account, and additional Sites can be added later on by users with admin privileges to your account.
Here's how that choice looks like in the Site creation flow:
To learn more, please see Which Implementation is Right for Me?.
A Final Note
Using APIs means a larger effort is needed from your development teams. We know!
However, it doesn't mean that development resources must be secured for each and every change you want to make. This does require some planning ahead with all stakeholders around the table: business, product and R&D.
For more on this, see Best Practices and the Tutorial.
Updated about a year ago