Cookies

Bloomreach Engagement stores the following cookies in the browser:

xnpe_{project-token} cookie is a server-side version of the __exponea_etc__ cookie. They will both hold the same value and in combination with custom tracking domain (CTD) and they help to keep the user's identity for browsers that have shorter expiration for client-side cookies such as Safari.

Cookie expiration

Because we know different jurisdictions have different rules, we give you full control over the expiration date of Bloomreach Engagement cookies.

How does it work

The default cookie expiration values can be customized according to your needs in the configuration object passed into the exponea.start() function.

The expiration date of the cookies is reset (to the default value or the one set in the configuration) every time a customer reloads the webpage or makes a new page visit. Therefore, if the customer returns to the website regularly, their cookie will technically not expire.

Example
A customer comes to your website today. You have not changed the default expiration values and so their tracking cookies are set to expire in 3 years. If the customer comes back again the next day, their tracking cookies will be reset to expire in 3 years from the next day.

If afterward, you change the default expiration date in the SDK configuration to, e.g. 2 years and they come back in a week, their expiration date will be reset again, this time to 2 years from the date of the visit.

Configuration

Inside of the configuration object, you can change the default values in 2 ways:

1. Use a single value for cookies.expires configuration option which will set all the cookies to expire at the same time
2. Specify a different expiration for each cookie category separately

Please, consider the following 3 examples.

(1) Set a 6-month expiration for all cookies:

exponea.start({
  cookies: {
    expires: 182 * 24 * 3600 // = 182 days
  }
});

(2) Set a 1-year expiration for tracking cookies, 1-month expiration for AB test cookies, and leave the time cookie expiration as default:

exponea.start({
  cookies: {
    expires: {
      tracking: 365 * 24 * 3600, // = 1 year
      ab_test: 30 * 24 * 3600, // = 30 days
    }
  }
});

(3) Using Date to set relative expiration date of cookies:

exponea.start({
  cookies: {
    expires: new Date(Date.now() + 3600 * 24 * 1000) // = always 1 day from now.
// careful! `expires` takes seconds but
// `new Date` takes milliseconds, hence the “* 1000”
  }
});

🚧

When using a Date, never use an absolute date for expiration. Always calculate the expiration date from the current date. Otherwise, when your date value in the SDK config expires (i.e. becomes a date in the past), the SDK will use the default expiration values.

📘

If you input invalid values in your config (e.g. a date in the past, negative numbers, alphanumeric characters, etc.) the expiration will revert to default values. You will receive a warning message explaining why the input is invalid.

Our recommendations

The tracking cookie handles tracking of unidentified customers, merging of their events, attribution and website personalization, analytics etc. This is why it is important not to set the expiration value too small. If, for example, an unidentified customer returns after 6 months, but the tracking cookie's expiration date is set to 5 months, Bloomreach Engagement will not be able to link these two sessions together under one customer profile.

We use the time cookie only for synchronization purposes between local time and server time, so this cookie does not need to have longer expiration dates than 1 hour.

📘

Note that Bloomreach Engagement cannot modify Google Analytics ID. In case you have Google Analytics turned on in the integration snippet changing the default cookie expiration has a limited effect on the merging of customer’s profiles.
The cookie expiration change in the config snippet does not reset Google Analytics IDs which leads to an immediate merge of the user with the original and newly assigned cookie back into one customer.

Local storage

Bloomreach Engagement stores the following data in Local storage:

Session storage

Bloomreach Engagement stores the following data in Session storage:

Bloomreach Engagement stores information about when the last session for the customer occurred to decide whether to track the page visit within the last session, or whether to track it as a new session.

The storage for ‘Experiment’ settings, to ensure that experiments are displayed within their defined policy setting, is also stored. This data has no expiration.

Under session storage the SDK settings for tracking are cached. This setting expires when the tab/browser is closed. IndexedDB, a JavaScript-based object-oriented database, can be a data storage for actions from browser push notifications. This data has no expiration. There is potentially PII in push notification messages.