Skip to main content

Beacon FAQ

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

The Krestor 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.

2. Can we install the beacon before sending over our catalog?​

Yes, the beacon can be installed before the catalog is sent. After receiving the catalog, our developers may need to modify the beacon a bit to ensure that behavioral tracking data can be correctly attributed to the data provided in the catalog. These updates require no action on your team's end, but can restart the clock on gathering behavioral tracking data.

3. Do your developers need to hand-build the beacon to recognize specific events and values on the site? i.e. how would the beacon know the user performed a given action like searching?​

Our developers customize our beacon to send tracking events based on various DOM events from your end users (e.g. search input focus, search submit, search result page load, etc.). More on this here

4. What is the difference in data capture from a Proof Schedule beacon to a live customer's beacon?​

  • For prospects & fully integrated customers:
    • Session start
    • Search input focus
    • Search term submit
    • Search results load
    • Browse results load
    • Search result click
    • Browse result click
    • Add-to-cart
  • For fully integrated customers only:
    • Letters typed into the search input
    • Search filters applied
    • Autosuggest suggestions clicked
    • Purchases
    • Custom Interest signals specific to the site
    • Viewed Recommendation pods
    • Recommendations Clicked

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

Nope! 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 listed here

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

Here's one of our tracking events sent from this page: https://bonobos.com/search?term=blue

https://ac.cnstrc.com/autocomplete/blue/search?original_query=blue&c=ciojs-2.343.2&i=b1b17fce-6e1b-47d1-ba0d-4e91efbe7c6b&s=1&key=key_Mp65OJnW8U79Olpq&origin_referrer=bonobos.com%2Fsearch&_dt=1648058713786
Example Tracking Event

7. Do we have different scripts for different environments like staging vs 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.
  • From Krestor's perspective, there is no need to add this script to lower environments during a Proof Schedule
  • Of course, feel free to add it to lower environments for your own testing and security purposes before adding it to your production environment. Please note that the beacon was developed for the DOM that we see in your production environment so if there are differences between environments, certain tracking events generated by the beacon script may not work as intended in lower environments.

8. Can we install the same beacon script in our lower environment?​

Feel free to test the beacon in lower environments before adding it in production. If you run automated tests in these lower environments, we'll filter that data out prior to training our ML on our end.

9. Does the beacon use cookies? If so, what type?​

We use a single first-party cookie, setting and reading an anonymous user id from the same host domain that the user is visiting. This anonymous user id is used to associate behavioral events across sessions for a browser. We do not use any third-party cookies.

As a reminder of the differences between first-party and third-party cookies:

  • first-party cookies are used to improve the user experience on a single website
  • third-party cookies are mostly used to collect data for ads and can follow users across multiple websites (more on this here)

10. Do we need to QA anything 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 some 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.