Will the beacon affect our site's performance or load times?

The Constructor beacon is architected to have no impact on site performance. The beacon does not block the browser event loop in any way and is largely made up of event listeners to track your users’ clickstream activity. Our beacon scripts are served from a CDN, gzipped, and can be loaded in asynchronously.

Can we install the beacon before sending over our catalog?

In the majority of cases, we require that a catalog file is sent to us before a beacon can be installed. This is to ensure that behavioral events can be correctly attributed to the data provided in the catalog.

Who builds the beacon to recognize specific events and values on the site?

Constructor engineers will be responsible for customizing Constructor's beacon to work with Constructor's AI technology.

How would Constructor's beacon know the user performed a given action like searching?

Once Constructor's engineers have customized Constructor's beacon for a particular e-commerce website, the beacon will send tracking events based on various DOM interactions from your end users (for example, search input focus, search submit, search result page load, etc.).

What user events does the beacon track? (clickstream data)

For prospects & fully integrated customers the beacon captures:

• Session start
• Autocomplete - Input Focus
• Autocomplete - Submit
• Search - Results Load (PLP)
• Browse - Results Load (PLP)
• Search - Result Click (PLP)
• Browse - Result Click (PLP)
• Conversion (Add to Cart)

For fully integrated customers only, the following may be captured:

• Recommendations - Result View
• Recommendations - Click
• Autocomplete - Select
• Generic Result Click
• Item Detail Load (PDP)
• Purchase
• Custom Interest / segmentation signals specific to the integration

Other than adding the script tag to our site, is there anything else that we need to configure?

No. The script tag will load the beacon into the user's browser, then send anonymous tracking events from their browser directly to our servers. No additional configuration is needed on your end to support Proof Schedule tracking beyond loading the beacon on the pages described in the Introduction.

What kind of data is sent from the browser to your servers? What would an example of a behavioral tracking event look like?

No personal identifiable information (PII) is transmitted with behavioral requests. Our beacon is fully compliant with all major privacy regulations including the GDPR and CCPA.

An anonymous user and session identifier is assigned by the beacon and transmitted with requests to instrument user journey. In addition, the API key, page URL and timestamp will be appended. Each event tracks key metrics relevant to the context of that event to inform our machine learning models. For example, a search result click event will track the ID and name of the item (product) that was clicked.

As an example, below is an autocomplete submit event:

GET https://ac.cnstrc.com/autocomplete/banana/search?original_query=banana&c=ciojs-2.618.4&i=1c682294-455c-46cf-9d6e-4adf3556a519&s=57&origin_referrer=constructor.io/demo.html&_dt=1687997113097

Filtering within the browser developer tools network panel by domain match against cnstrc may help to narrow down and behavioral tracking requests as seen in the following image.

Does the beacon have different code for different environments (staging, production)?

The purpose of the beacon is to gather behavioral tracking data from end users, so this script is intended for use (and only provides value) when loaded in the production environment. There is generally no need for the beacon to be loaded in non-production environments during a Proof Schedule.

The beacon can be added to lower environments for testing and security purposes before adding to a production environment. Note that the beacon was developed for the DOM in the production environment. If there are UI differences between environments, certain tracking events generated by the beacon script may not work as intended in lower environments.

Does the beacon use cookies? If so, what type?

No. The Constructor beacon does not utilize use cookies by default. The beacon only uses local storage and session storage.

Constructor rarely ever needs to customize a beacon's behavior to use cookies for a Proof Schedule, but there are some conditions when it does make sense to use first-party cookies for a full integration.

If we ever run into a situation where we need to use cookies to support an integration with your site, we'll confirm with you first & explain exactly why we need to use cookies to support an effective integration with your website.

For more on this, please refer to: does Constructor use third-party cookies to track visitors?

Do we need to perform any QA before loading the beacon on our site?

The same core tracking code is used across all of our beacons. This code is thoroughly tested and optimized. For each beacon, our engineers write and maintain custom JavaScript to configure our core tracker to listen for events specific to your user experience and the DOM that is powering it. As with our core tracker, all custom code is thoroughly reviewed and tested before it makes its way to production.

What domains need to be allowed-listed in our site's Content Security Policy header?

There are two domains that need to be allow-listed in a web servers Content Security Policy (CSP) header, under two separate CSP directives.

• Under the script-src directive, the domain https://cnstrc.com/* needs to be permitted to load our Beacon.
• Under the connect-src directive, the subdomain https://ac.cnstrc.com/* needs to be permitted to allow our Beacon to transmit events.