Qubit's personalizations are primarily delivered to a client's website via smartserve.js, our proprietary Javascript bundle, which is injected into a page. However, because of the shift to mobile and frontends like React/Angular, Qubit has delivered a more advanced solution, Server Experiences, which uses an API as its delivery mechanism.

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.

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.

• 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 flicker
• Testing a whole new site design