# Cookies

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.

**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:

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

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

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_show`Timestamp of last showing of specific banner to the customer.
`__exponea_banner_event__[BANNER_ID]_last_interaction`Timestamp 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.