What is an API?
Application Programming Interface (API): In basic terms, APIs just allow applications to communicate with one another. When people speak of “an API”, they sometimes generalize and actually mean “a publicly available web-based API that returns data, likely in JSON**”. The API is not the database or even the server, it is the code that governs the access point(s) for the server. We can send an API a request (AKA call) detailing the information we want. Each API is called - endpoint.
**JSON stands for JavaScript Object Notation and is basically a way of representing data that looks like JavaScript objects. Let’s look at a very typical JavaScript Object for a person, which might look a bit like this:
{“person”: [
“name”: “Shreya”,
“address”: “Dwarka”,
“pin-code”: “110078”,
“phone”: “9899013456”,
“email”: “shreyapd06@gmail.com”
]}
For each item, the key is on the left, and the value is on the right.
What are the Experience APIs?
The Experience APIs are a new way of implementing DY. They are a set of endpoints that our customers can call from their site's code. We have the ‘classic’ script implementation which customers can still use to create personalized campaigns, and now we have the API implementation that allows for the same type of personalization and data available, however, it needs to be called from their code base so that Dynamic Yield knows to return the relevant data. Once the data is received, it's up to you to do something with the data in your site's code.
How Can I Use the APIs?
You can use Experience APIs in two different types of Dynamic Yield sites:
Web Sites
You can use Experience APIs in any website where our client script is integrated, and create campaigns of both types running in parallel over the same user base.
This approach allows marketers to keep enjoying all the out-of-the-box visual tools available with Dynamic Yield's client-side script, and create onsite experiences with little to no IT resources.
At the same time, you can run API-based campaigns where they’re needed most, adopting them at your own pace. This is beneficial for customers wishing to run performance sensitive campaigns, for example , content above the fold, or campaigns with sensitive data that should not be exposed in the browser.
Additionally, this method of implementation allows existing customers 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.
API Sites
You can use a site designed to manage APIs without implementing the Dynamic Yield script on your site. In this method, 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, while also reporting interactions with your site (pageviews and events). Our "classic" client script is not integrated into your website at all.
Regardless of the implementation method, a campaign created cannot be transitioned from one method to another without losing data.
What are the Prerequisites?
- The ability to modify the source code (you have a developer available)
- Prepare a clear design roadmap for incorporating the Experience API and personalization into your app.
- The ability to serve fresh content per user (the page must not be entirely cached inside a CDN)
- Determine which Dynamic Yield servers to use. We currently have one API gateway in the United States, and one in the Europe Union. These are two separate and complete instances of our system and no data is shared between them.
Why Would I Want to Use Experience APIs?
The value of the Experience APIs depends on your role in the company:
Marketers:
- Wants flawless experience, without flickering
- Wants his customers to have the same digital experience throughout different channels (Omni-channel),
- Doesn’t want to expose his campaigns to the browser, as they expose his internal strategies.
- Is concerned about privacy and regulations.
Developers:
- Need to handle page load performance issues.
- Need to progress to better frameworks, and use SPA, WPA, and such.
- Want full control over their technology stack.
Should I Use a Dynamic Yield Project of type Web or API?
There are two ways of working with APIs using Dynamic Yield: one is designed for API only, the other is the Web-based integration which enables users to choose whether to use the classic setup, or the API for select campaigns. To determine which option is best for you, let's consider two scenarios:
Option 1: Web
If you're used to client-side testing & personalization tools and you wish to minimize time to value while keeping your future options open, you can use a standard Dynamic Yield Web Site.
This gives you the opportunity to gradually implement API-based campaigns. Here are some use-cases that are especially suitable for implementation via API and we recommend starting with:
- 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-side, 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 via client-side A/B testing at all, in order not to expose this information in the browser. When running campaigns via the API, only the chosen variation is sent to the client.
- Large number of running tests: as your adoption of the platform grows, you may run dozens of campaigns concurrently, each having their 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 using sites of type Web:
- As the Dynamic Yield scripts are still loading in the header of all pages, the full performance benefits of the API will not be attained.
- Management of User & Session IDs relies on cookies in Web sites, and this is not suitable for non-web environments such as mobile apps, retail locations, etc.
Option 2: API Only Sites
If one of the following issues concerns your tech-teams, and you have the resources to support an API implementation, we recommend using an API only site:
- Impact of 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)
Advantages:
- No scripts to download. You can decide from which end to call our APIs (server or client), whether to block the page rendering waiting for results or not - whatever meets your performance needs and architecture best.
- Best control over data collection policy - you're making the API calls, deciding exactly when to make the calls, and which attributes to pass.
- Your code responsible for calling Dynamic Yield to make decisions 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).
Cons
- Quick turnaround - this implementation method is highly reliant on your dev teams. It is more of a challenge to build and improve on use cases in a quick and easy manner.
- It's up to your code to generate user and session IDs and store each of them for the appropriate duration.
- There is no going back to using web-based campaigns without starting data collection afresh.
To sum it up best in Stan Lee's 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.
How Can I Check my Implementation and Troubleshoot API Calls?
With the API Logs dashboard you can see how many API calls were made, how many of them were correct, and get an in-depth view of the customer’s implementation:
