Gravity Field Implementation Types

Available Implementation Types

Gravity Field offers three implementation types:

Client-Side Implementation

Adding a .js script to the website

Server-Side API

Sending server-server API requests

Hybrid

A combination of both implementation types, which allows you to maximize the benefits of both types by combining various types of implementation on different pages and channels

Main advantages and disadvantages of Front-end and SSAPI Implementation Types

Each of the options has its own advantages and disadvantages.

Client-Side Implementation

Main advantages

The front-end implementation of Gravity Field allows platform users to launch personalization campaigns directly from the interface without the involvement of their development team. The advantages include:

• Easy to launch personalization campaigns.

• Quick and agile hypothesis testing.

Main disadvantage

• Adds an additional script to the site, which can affect the performance.

Server-Side API Implementation

Main advantages

• Reduces the impact on performance.

• Allows you to run personalization campaigns across channels in a single interface (web, mobile apps, POS-terminals, kiosks, etc.).

• Provides transparent data management and the ability to work without cookies as data is not stored in the user's browser with SSAPI implementation. Accordingly, it is suitable for working with properties containing sensitive data, for example, online banking or trading platforms.

Main disadvantages

• Requires the involvement of developers in launching each campaign.

• Requires more resources than Front-end implementation in the initial stages.

Hybrid Implementation

Main advantages

• Allows users to enjoy the advantages of both implementation types.

• Allows users to run personalization campaigns across channels (web, mobile apps, POS-terminals, kiosks, etc.), without sacrificing agility (time to market) on the web.

Main disadvantages

• Requires more resources for the initial implementation.

• Requires the involvement of developers in launching each Server-Side campaign.

Client-Side Implementation Flow

Client-Side Implementation

The general implementation process consists of the following stages (more detail of the process is provided in the documentation links attached below):

1. Script installation. 1. Gravity Field Script

2. Context setup. 2. Page Context Context markup is a message to the platform about which page the user is currently on.

3. Setting up events for key metrics. 3. Events

   For e-commerce "add to cart" and "purchase" events are mandatory. For properties that do not sell products, within the framework of the same events, other key metrics can be passed to the platform.

4. Product feed creation. 4. Feed - General Requirements and Additional Parameters

   The feed should contain relevant information about all the products and services the company provides. The feed is used for:

   • product recommendations;

   • calculation of users' interests (affinity profile);

   • calculation of Social Proof data;

   • and in many more use cases.

5. Ensuring seamless user identification regardless of the limitations of the browser used (cloning third-party cookies). 5. Cookies cloning with front-end implementation

6. Configuring SPA events (similar to page changes on non-SPA websites). Implementation on SPA-enabled sites

Server-Side Implementation Flow

Server-Side API

The general implementation process consists of the following stages (more detail of the process is provided in the documentation links attached below):

1. Defining unique identifiers for users and sessions on the site or other property (in the application, kiosk, etc.).

   It is necessary to assign unique user and session identifiers.

2. Creating an API key to identify requests.

   A unique API key is created for each of your sections in Gravity Field by a solution consultant responsible for the onboarding.

3. Passing the information about users’ actions. Events: Transmitting Information About Events

   For e-commerce "add to cart" and "purchase" events are mandatory. For properties that do not sell products, within the framework of the same events, other key metrics can be passed to the platform.

4. Sending campaign requests and processing received responses. Choose: Requesting Campaigns

5. Passing information about user engagement with campaigns. Engagement: Passing Information About Users’ Interactions With Personalization Campaigns

6. Passing information about page/screen views. Page: Sending Page View Information

7. Product feed creation. 4. Feed - General Requirements and Additional Parameters

   The feed should contain information about all the products and services the company provides. The feed is used for:

   • product recommendations;

   • calculation of users' interests (affinity profile);

   • calculation of Social Proof data;

   • and in many more use cases.

Hybrid Implementation Flow

Provided that hybrid implementation includes both Client-Side and Server-Side implementations, details are the same as provided earlier in this article. At the same time, we recommend considering the following nuances during your implementation:

1. During the implementation, you will need to decide where each of the events you send to the platform belongs (Client-Side or Server-Side) to avoid duplicated events.

2. For each of the personalization campaigns, it is necessary to decide early on which implementation it is going to run through to plan accordingly.

We will be happy to assist and answer any questions related to any of the implementation options and, if necessary, conduct an additional technical session. For the most effective session, we recommend providing a list of questions for discussion one business day before the call.