Cookies & Storage


Bloomreach Engagement stores the following cookies in the browser:

NameDescriptionTypeDefault expiration
__exponea_etc__Customer's Bloomreach Engagement generated client-side cookiefirst-party, client-side7 days - 3 years (depends on browser)
xnpe_[project-token]Customer's Bloomreach Engagement generated server-side cookiefirst-party (for CTD) or third-party, server-side3 years
__exponea_time2__Timestamp offset between browser and server timefirst-party, client side60 minutes
__exponea_ab_[ABTestName]__Variant name returned for an A/B testfirst-party, client side7 days - 3 years (depends on 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.

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.


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:

  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:

  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:

  cookies: {
    expires: new Date( + 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:

__exponea_experiment_event[EXPERIMENT_ID]_last_show__Timestamp of last showing of specific experiment to the customer. Used in the frequency matcher/filter.
__exponea_experiment_event[EXPERIMENT_ID]_last_interaction__Timestamp of last customer's interaction with specific experiment. Used in the frequency matcher/filter.
__exponea_safari_push_subscribed__Boolean value indicating whether push token has been stored for safari web push notifications.
__exponea_last_session_ping_timestamp__Customer's last session ping.
__exponea_last_session_start_timestamp__Customer's last session start.
__exponea_banner_event__[BANNER_ID]_last_showTimestamp of last showing of specific banner to the customer.
__exponea_banner_event__[BANNER_ID]_last_interactionTimestamp of last customer's interaction with specific banner.
__exponea__sync_modifications__This value is present if you are using the Synchronous solution for Experiments.

Session storage

Bloomreach Engagement stores the following data in Session storage:

__exponea_tracking_definition__Customer's specific tracking definitions set up in Data Manager -> Automatic Web Tracking.

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.