Build server experiences
Build server experiences
This is for:Developer
In this article, we’ll introduce you to Server Experiences, how they are delivered, and the advantages over our standard method of delivering personalizations.
Advantages of this approach are:
You can deliver personalizations on any channel that can access the HTTP API, such as server-side, mobile apps, desktop apps, or even in-store point-of-sale systems such as kiosks
You can write experience code in any language you choose, such as Java, Swift, node.js, or C++
Delivering personalizations server-side enables you to send a personalized page to the user’s browser, eliminating execution time in the browser that can lead to unwanted "flicker"
You can take advantage of enhanced security when required for specific use cases, for example, accessing private databases and APIs that you do not wish to expose to a browser environment
By defining variables as configurable content, you can inject dynamic variables into your experience code that can be later updated with a quick change to the Experience within app.qubit.com and without requiring a software release
The Qubit API handles the segmentation and automatically chooses which variation each visitor is served. The experience and relevant variables are then returned for a developer to implement, freeing them to focus on implementing the experience without worrying about any decisioning logic.
Supported channels and use cases
Mobile applications (iOS and Android) are compiled binaries with limited scope for dynamic code injection and must go through a review process by app-store providers. Because of this, custom experience logic, typical in web channels, is not possible.
The Server Experiences API allows experiences to be served inside mobile apps, using the Qubit Mobile SDK. These experiences are tracked in the same way as web experiences and utilize the same levels of segmentation.
The key difference is that variations need to be built into the app when released; Qubit then controls which variation is shown, to which users, and when.
Common use cases
New checkout flow A/B testing Google or Apple Pay
Showing VIP sale section of the app to loyal customer segments
Feature rollout to a percentage of visitors or segment
When testing much broader site or API changes, such as complete new checkouts or a new backend, the traffic split needs to be done in the backend system before the response is served to the browser. The Server Experiences API can be called from anywhere that can make an HTTP request and has access to a user Id, such as the _qubitTracker cookie, or a User Id of your choosing.
The API will respond with the experiences and variations the user should see, which a developer can then use to serve a new page template, customize a search result ordering, or enable a new feature.
Feature rollout to a percentage of traffic or segment
Landing page optimization with no
Testing a whole new site design