Cookies & Storage

Cookies

Exponea stores the following cookies in the browser:

Name

Description

Type

Default expiration

__exponea_etc__

Customer's Exponea generated client-side cookie

first-party, client-side

7 days - 3 years (depends on browser)

xnpe_[project-token]

Customer's Exponea generated server-side cookie

first-party (for CTD) or third-party, server-side

3 years

__exponea_time2__

Timestamp offset between browser and server time

first-party, client side

60 minutes

__exponea_ab_[ABTestName]__

Variant name returned for an A/B test

first-party, client side

7 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 Exponea 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, Exponea 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 Exponea 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

Exponea stores the following data in Local storage:

Name

Description

__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

Exponea stores the following data in Session storage:

Name

Description

__exponea_tracking_definition__

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

Exponea 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.

Updated about a month ago

Cookies & Storage


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.


We rely on cookies

to optimize our communication and to enhance your customer experience. By clicking on the Accept and Close button, you agree to the collection of cookies. You can also adjust your preferences by clicking on Manage Preferences. For more information please see our Privacy policy.

Manage cookies
Accept & close

Cookies preferences

Accept & close
Back