POST Visit Data

Description: An API call to send visit data to the SiteSpect engines. By default, SiteSpect counts visits according to the User Session Timeout setting in the Manage, Site Settings, User Tracking area, typically set to 30 minutes (1800 seconds). SiteSpect evaluates the last request time via SSRT cookie to determine if the visit should be extended by the User Session Timeout amount or if the request should be tracked as a new visit.

Example: POST

Note: SiteSpect uses cookies to track assignment, which must be sent and updated with all calls. For convenience, cookies and headers can be passed/received in the body of the request/response.

POST body JSON parameters:

  • An array of objects. Each object represents visit data for one session.
  • Top-level attributes:
    • Data: An object that stores hits (and optionally value capture data) for each Metric under the Metric ID.
    • AsmtCounted: An array that stores the Variation Group IDs for visits that are counted. When this is sent, SiteSpect automatically updates the counted state for the visitor and Campaign based on the Variation Group ID. If the visitor has been shown a change in your application or if the AsmtCounted parameter in the GET response is true, then the Variation Group ID should be added to the AsmtCounted array. If a visitor is assigned to a Control Variation Group, mark that visitor as counted if that visitor would have seen a change from another Variation Group within that Campaign.
    • time:A UNIX timestamp passed as a string that overrides the current visit time. By default, SiteSpect uses the current time for each visit, but you can define the exact time of each visit by passing this optional field.
    • newsession:A Boolean that overrides the default logic that uses the User Session Timeout setting and starts a new visit. This makes sense if you want to have full control over the session from the application. For example, when testing native apps you might want to use this optional field to terminate the session on app close.

POST body JSON structure:

{   "visits": [{     "AsmtCounted": ["VariationGroupID"], "time": Unix epoch //optional, "newsession": boolean //optional,

    "Data": {       "MetricID": {         "Hits": number, //required         "ValueCapture": number //optional       }     }   }] }

POST body JSON example:



{   "visits": [{     "AsmtCounted": ["88","89"],     "Data": {       "151": {         "ValueCapture": 15         "Hits": 1       },       "152": {         "Hits": 2       }     }   }] }

Note: The response of this call contains the same Assignment and Campaign Data that you receive from a GET call. It makes sense to leverage the response and to update the current assignment in your application.

Alternative Method for Triggering Metrics and Updating Counted State

Metrics in SiteSpect are often setup with URL triggers to capture visitor behavior on specific pages. Any Metric can be set to Count User When Triggered, which updates the counted state of the visit. A single call that flows through the SiteSpect proxy can update one or more Metrics according to the URL Trigger settings.

Since the Engine API calls are not proxied, but SiteSpect is the end point, this doesn't work. However, in the POST call, you can pass a URL query parameter with a value of the visitor's URL location. SiteSpect evaluates that against the URLs in the existing Metrics and updates hit and value capture data as well as counted state for the visit if you have enabled Count User When Triggered for a given Metric.

For example:

The POST call above updates the hit count by 1 for any Metric that has a URL trigger regex that matches "/one". It would also capture a value of 5 if that Metric's value capture name is set to "count".