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 is also pretty common to cache the full HTML for some of the pages in your site to save on both rendering and serving time, as well as your compute 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 classic client-side integration is actually a good way to modify content in 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. To the contrary, you're encouraged to use techniques such as fragment caching to only re-render the parts that are really dynamic in 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 starting to use our product, your Customer Success Manager will assign your account to the appropriate instance based on your needs.
- 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. Moreover, see the tips in the Best Practices article for ways to further optimize your network calls.