📘

Note

This guide is generally only relevant for backend integrations - if integrating via frontend and/or mobile and utilizing a Constructor client library, inclusion of identification parameters will be handled automatically.

To power personalized results and facilitate ease of debugging, Constructor requires two parameters (and one optional) to be sent with all requests. Identification parameters ensure that Constructor is able to anonymously track a user's behavior on customer websites in perpetuity, as long they continue to use the same browser / machine.

Identification parameters are assigned via the constructorio-id JavaScript module, which is bundled in within the Constructor beacon.

By default, the Constructor beacon maintains identification parameters within local storage in the user's browser.

In the case of backend integrations, it is common practice to change this configuration to store identification parameters in cookies so they can be easily accessed server side. This can be easily configured by Constructor.

Parameters

Client ID - i

Required

This denotes a user's browser session, and will usually be represented as a unique hash such as 6c73138f-c87b-49f0-872d-63b00ed0e395.

Session ID - s

Required

This value is an integer denoting the user's session number (starting with 1), which is incremented after 30 minutes of inactivity.

User ID - ui

Optional

This value is an identifier that maps to an internal user account ID on a customer website. It should only be sent for logged in customers.

Passing a user ID is recommended, as it helps us to tie multiple client and session IDs together to form a behavioral data profile across various devices.

📘

When are cookies used instead of local storage?

First party cookies may be utilized in favor of local storage to store the parameters listed for the following circumstances:

• Web platforms that extend across multiple sub domains
• Supporting customers who utilize a backend integration
• Websites that utilize both HTTP and HTTPS

Risks of not supplying identification parameters

Identification parameters are required by our system for a number of reasons. If they are not supplied with requests and tracking events, the following may be true:

No personalization can be applied to results

Without identification parameters, personalization cannot be applied to result sets returned from Constructor. The ability to learn about specific customers as they interact with an e-commerce platform to make personalized recommendations will be severely hindered.

Internal A/B tests cannot be performed

Data science uses identification parameters to assign users to specific cells to run A/B tests to improve results. For example, testing the impact of Cognitive Embeddings Search (CES).

Lost understanding of user "journey"

An important part of developing strong behavioral learnings is understanding the full user journey. For instance, if a customer searched for a product and was not able to find it using one query, what query did they try next to reformulate their search? Without having identification parameters in place, it is not possible to develop a deep understanding of how the user interacted with a given site.

Diminished debugging and analysis capabilities

Identification parameters make it far easier for the team to debug and understand user behavior. Without them, scenario analysis can become more difficult.

Due to the preceding concerns, it is imperative that identification parameters are sent with every request to Constructor.