There are several things to ensure before you start using Experience APIs. If you're unsure about any of the points here, we're happy to help assess your use case.
Can you modify the source code?
This is the most obvious requirement: You should be able to modify the source code in each component of the system in which you'd like to embed personalization. This might be your server side, your client website and apps, or both: It isn't rare for decision to be made in the server while data collection is done directly from the client.
If your application is based on an off-the-shelf platform, verify that you have access to the parts of code where calls are to be added. Some CMS and e-commerce platforms are highly customizable, such as WordPress and Magento. Other platforms such as Shopify aim to simplify and streamline the development process, at the cost of lesser control. For such cases, consider using the built-in integrations.
Can you serve fresh content per user?
Using a CDN (Content Delivery Network, such as Akamai, Cloudflare, Fastly, and so on) is common practice for serving static assets, such as images, CSS, and JavaScript files, and has no impact on personalization. It’s also pretty common to cache the full HTML for some of your site’s pages to save on both rendering and serving time, as well as your computing resources.
For pages that are fully cached, so that everyone who visits these pages sees the same thing, there is no way to personalize that page except through some layer of post-processing. Our client-side integration provides a good way to modify content on such pages. If you want to personalize pages via API as you're rendering them, the final page layout needs to be composed dynamically, embedding any chosen variations.
However, this does not mean that all elements have to be fully rebuilt. On the contrary, you're encouraged to use techniques such as fragment caching to re-render only the parts that are really dynamic on the page. If the dynamic portion of the page is below the fold and can be loaded asynchronously, you can decide to load that part as a separate process after you've done displaying the cached above-the-fold content.
Where in the world is your data center?
Our API gateway is currently hosted in two locations: One in the United States and the other in the European Union. Note that these are two separate and complete instances of our system and no data is shared between them. This setup makes it easier to comply with local regulations on data privacy, especially within the EU. When you begin your journey with Dynamic Yield, your Customer Success Manager assigns your account to the appropriate instance.
- Our US-based servers are located in the AWS North Virginia data center, also known as us-east-1 region.
- Our European servers are located in the AWS Frankfurt data center, or eu-central-1 region.
Ensure that your servers, and any other components making synchronous calls to get content variations where latency is important, have good connectivity to the servers in your chosen Dynamic Yield location. Even if you're not using AWS, many other providers have good connectivity to the nearest AWS regions. See also the tips in the Best Practices article for ways to further optimize your network calls.