Engine API is a simple and powerful REST API that enables programmatic communication with SiteSpect as an endpoint
The SiteSpect Engine API enables testing, optimization, and targeting for server-side, client-side, mobile apps, Over-the-Top (OTT) devices, kiosks, and any other application that makes HTTP calls. You can use the Engine API as a standalone system, but it is also complementary to SiteSpect proxy and client-side SDK approaches. You can use them all simultaneously and with consistency for the same end user.
Table of Contents
- High level flow for Engine API interaction
- Getting Started: Control Panel
- Working with API calls
- Flow - Campaign Assignment and Counting
Engine API logic works in the same way as the proxy does. The user is assigned to a campaign when a request is made to the Engine API endpoint. That user can be counted in a campaign with a subsequent request.
Proxied Web vs. Engine API App
High level flow for Engine API interaction
- The end user launches a mobile app on a smartphone. We’re using the smartphone as the example, but this could just as easily be pretty much any application that uses HTTP calls.
- Your app makes an Engine API call to determine which experience(s) the user should see.
- Based on the response of the Engine API call (Variation Group ID), the mobile app displays the experience(s).
- Your app sends back a POST to Engine API reporting that the user is counted in the campaign and optionally metric hits.
- As the user progresses through a mobile app visit, your app makes API calls to capture user behavior and conversions, sending metric hits.
- SiteSpect will automatically close out the user's visit based on 30 minutes of inactivity. Once there is a another POST outside of that visit, the same user will be automatically counted in a new visit.
Getting Started: Control Panel
Prerequisite: If Engine API is enabled for your configuration, you should see a Campaign Set called Engine API and be able to specify the Type: Engine API when creating a new Campaign. If you don't see this option, please work with your Account Manager to request this feature.
Note: There is an option to enable Engine API from with Advanced Settings. The intent of this option is to be able to use a Campaign for both proxied traffic AND Engine API. This is a less common use case. If you want to use a Campaign dedicated to Engine API traffic, please use the above process to create a campaign that is of the Type: Engine API.
Create a Campaign
Create an Engine API Campaign from the SiteSpect Control Panel, just as you would for any other type of Campaign. Using the A/B Campaign Builder, follow these steps:
- Select New, A/B Campaign.
- In the General section of the page, select Engine API from the Type drop-down.
- Create Variation Groups. You can also optionally create Live Variables.
- Add Metrics and choose a KPI. In the Metrics section of the page, drag any Metrics you want to add to the Campaign from the Metrics List area to Assigned Metrics area. In addition, select a Metric and drag it to the Key Performance Indicator area. All Metrics have IDs that are used by your application to send visitor behavior data to the SiteSpect engines.
- Add Audiences. In the Audience section on the page, optionally drag and drop any Audiences to set targeting rules for assignment.
- Save the Campaign. When you save the Campaign, SiteSpect automatically assigns a unique ID to each Variation Group.
- Retrieve IDs From SiteSpect for Variations, Metrics, and Audiences. You’ll use these in your API code.
- Change the Campaign Status to Active-running. Your API calls won’t work until the Campaign is Active. Optionally test it out on a limited set of users by using a restricted Audience such as a header value.
Working with Engine API calls
It is recommended that when new to Engine API you test it by using your favorite environment. We use curl or Postman.
The API endpoint resource typically follows the convention of the first two but can be customized:
The optional parameter ?format=array can be used to format the JSON response as an array.
Please work with our Solutions Architecture team for configuration changes.
When a user has not yet had any interaction with SiteSpect, they have no cookies. Cookies are used to track Campaign Assignment and counted status. Cookies must be used in subsequent visits so the user is properly tracked. A request with no cookies is considered a new user.
Cookies can be managed automatically (like in a browser) by using a cookie jar in your code environment. Optionally cookies can be managed in another way and passed into the JSON payload in the body of the POST. When there are Engine API cookies in the JSON payload, any cookies that are passed as cookies would be ignored - the JSON payload take precedence.
The most recent cookie values should always be used. That is, the cookie set that was returned from the most recent request should be used in the next request.
JSON Request Body
None of the Body Properties are required for subsequent POSTs after the user has been counted in the initial visit once. The act of counting makes that user "stick" and be included in the data set. More on counting in the next section.
Request headers can be used at will. These will be evaluated against Audiences and Metric Triggers.
Flow - Campaign Assignment and Counting
1. Get Assigned to Campaign(s)
Send a POST with an empty body at the beginning of a new visit.
Examine the response to see which Campaign Variation groups the user is assigned to.
Users (with cookies) who were counted in a previous visit will automatically be counted in a new visit for those Campaigns. "AsmtCounted": true will be returned for each Campaign Variation Group the user was counted in in a past visit.
Campaigns where the user was not counted in a previous visit (such as newly launched) will show as "AsmtCounted": false for counted status.
Also note, as you might expect, Campaigns that have been paused or ended will no longer be represented in the response. Every time a POST is performed, the current list of Campaign Variation Group IDs will be returned along with their counted status.
2. Count User in Campaign(s)
Send a POST with "AsmtCounted": ["VariationGroupID"] with an array of Variation Group IDs (VGID) that you want the user counted in. VGIDs were the user is already reported as counted don't need to be included but doing so causes no harm.
Send a POST with for each Variation Group ID that the user should be part of. Optionally also send any Metric Hits at this time, and/or send them later in the visit.
When a user is counted in a campaign, it is one way - meaning the user cannot be uncounted unless they are expired out of the campaign (Advanced Campaign Settings), or the campaign status is changed to ended.
Subsequent POSTs within a visit will make no change to the counted status. These additional POSTs serve to allow for sending metric hits or extend the active visit (expires after 30 minutes of inactivity).
In this example, the user has not been counted for the Variation Group 132187. The following JSON payload will count the user.
POST JSON request payload for the user to be counted and two metrics to be hit. The Data section with Metric hits is not required, AsmtCounted is the minimum requirement for counting the user.
The "AsmtCounted" is now showing as true for this Campaign VGID.
Variation Group IDs are unique and tied to a campaign. A user will get assigned to only one Variation Group ID (VGID) per campaign as they normally do. Each VGID will return the following data every time a POST is made:
- Control: boolean (is the Variation Group a control or not)
- AsmtCounted: boolean (has the user been counted in this Campaign yet
- All available metrics that are associated with that Campaign
- The SiteSpect Cookie Set (returned in JSON even when tracking in a cookie jar)
- Live Variables if used
What are Live Variables
Live Variables is a JSON data layer that are managed in a Campaign or Variation Group and passed to all visits assigned to the Campaign. This allows you to specify dynamic variables that can be used in your application and changed or managed in SiteSpect. You can even use it for a mapping of Variation Group IDs to custom defined tokens that you use in the app to apply changes.
Live Variables can be used at the Campaign level and Variation Group level. They are manged in the New Build Flow either by selecting Live Variables from the three-dot menu in the upper right area of the page, or from each Variation Group. There you can insert any valid JSON data that you want to associate with the campaign. Once saved, this data will show up in the response of the Engine API POST.
- SSID: Visitor Tracking - A persistent cookie that tracks a visitor over time. (Required)
- SSRT: Recent Request Time - Stores the data and time of the visitor's last request to determine if the visit has timed out. (Required)
- SSOD: Additional Data Storage - Stores additional Campaign data for the visitor, including the hit rating value and the baseline Metric hit data.
Note: cookie naming can be something other than what is stated here based on your individual configuration.
If using Engine API from the browser, SiteSpect supports Cross-Origin Resource Sharing (CORS), which adds specific headers to the SiteSpect server response that allow such cross-domain communication.
Additional POSTs within a visit will allow SiteSpect to calculate visit time. If you see a visit
length of 0 in your data export, that indicates a single POST for that visit. The visit time will
represent the time between the first and last POST in a visit. A visit is automatically closed out
after 30 minutes of inactivity so additional Engine API communication can be used to extend a
visit. Conversely there is newsession boolean that can used to force a user into a new session.
There are a couple of options to test showing your changes.
- Determine your own custom flag that will instruct your code to apply the changes that would be applied from the signal from the Engine API response. For example using a custom header a custom URL parameter.
- Temporarily add an Audience to your campaign that restricts assignment. This could be a header, URL parameter, or IP address. Once the Audience is added, the campaign can be set to active with no risk of assignment from your normal traffic. If, for example, you have a Control and two Variation Groups - you would need to clear cookies and get assigned as a new user until you were randomly assigned to each Variation Group* (see note below). Once you have completed that validation, the custom Audience can be removed.
AppVG is your chosen parameter name, and 2235223 is the system provided Variation Group ID.