The beacon is a JavaScript file that Constructor builds for your site. It sends behavioral events from the browser to Constructor. This guide explains how to load the beacon on your site.

The beacon does not know which elements on your page are results or buttons. After you load it, add the data-cnstrc-* attributes that Data-driven event tracking lists for each page type.

Before you start

Constructor gives you a bundle name for your site. The bundle name is part of the beacon URL. If you do not have a bundle name, ask your Constructor contact for it.

Pages that load the beacon

Load the beacon on every page of your site. At minimum, these pages must load it:

• Each page that has a search bar
• Search results pages
• Browse pages, for example category pages and collection pages
• Product detail pages
• The cart page
• The order complete page

If one of these pages does not load the beacon, the events from that page are lost. Nothing shows an error. A test is the only way to find the gap.

Add the beacon to your site

Add this script tag to the HTML of each page. Replace <CUSTOM_BUNDLE_NAME> with your bundle name, and remove the < and > characters.

<script defer src="https://cnstrc.com/js/cust/<CUSTOM_BUNDLE_NAME>.js"></script>

Put the tag between the <head> and </head> tags. In the head, the browser starts to download the beacon early. If you cannot edit the head, put the tag immediately before the closing </body> tag.

The defer attribute changes when the beacon runs, not when it downloads. The browser downloads the beacon while it reads the HTML, and runs the beacon after it finishes reading the HTML. The beacon does not block the page from rendering. The beacon works with or without defer. MDN describes the attribute.

Load the beacon with a platform connector

If your site runs on a platform that Constructor has a connector for, the connector can load the beacon:

• SFRA Salesforce cartridge
• Shopify UI

Make sure that the beacon loads

1. Open a page on your site in the browser.
2. Open the developer tools, and then open the network tab.
3. Reload the page.
4. Make sure that a request for cnstrc.com/js/cust/ followed by your bundle name returns status 200.
5. Do these steps again on each page type in the list above.

When the beacon loads, it creates the client ID i and the session ID s. By default, it stores these identifiers in local storage; Constructor can configure first-party cookie storage for integrations that need it. Identification parameters explains these IDs.

The Data Attributes Validator Extension (DAVE) shows the beacon and its attributes on a live page.

More considerations

UI A/B tests

If you split users into test cells that see different user interfaces, tell your Constructor contact. Constructor engineers can configure the beacon to track events in each version of your interface. To do this, they need a way to open each test cell.

If you run an A/B test with Constructor, the beacon must be able to read the test cell. Data-driven event tracking explains how to surface it.

Content Security Policy and Subresource Integrity

If your site uses a Content Security Policy (CSP), add these domains:

• In the script-src directive, add https://cnstrc.com. The beacon loads from this domain. If your policy also has a script-src-elem directive, add the domain there too.
• In the connect-src directive, add https://ac.cnstrc.com and https://pcs.cnstrc.com. The beacon sends events to these domains.

The beacon does not support Subresource Integrity (SRI), because Constructor updates the beacon code regularly. Do not add an integrity attribute to the script tag. Subresource Integrity (SRI) explains why.