
{% callout type="warning" heading="Legacy JavaScript SDK" %}
This guide covers behavior with the legacy JavaScript SDK. **For new implementations, use the [Browser SDK 2 cookies and consent management guide](/docs/sdks/analytics/browser/cookies-and-consent-management)**, which covers the current TypeScript SDK.

New customers must use the new TypeScript SDK (Browser SDK 2). Existing customers should consider migrating to Browser SDK 2 for the latest features and improvements.
{% /callout %}

This guide covers functional and technical information about how Amplitude works with cookies, local storage, opt-in/opt-out options, and consent management (including CNIL regulations for France) when using the legacy JavaScript SDK.

{% callout type="info" heading="Recommended migration" %}
For the most current cookies and consent management features, migrate to [Browser SDK 2](/docs/sdks/analytics/browser/browser-sdk-2) and use the [Browser SDK 2 cookies and consent management guide](/docs/sdks/analytics/browser/cookies-and-consent-management).
{% /callout %}

## Amplitude cookies

A **cookie** is a piece of data from a website stored on a user's web browser. Websites retrieve cookies later to access data stored for functional or technical purposes. After initialization, the Amplitude SDK creates a cookie that begins with the prefix `AMP_` and ends with the first 10 digits of your project API key. You can customize this prefix with the `COOKIE_PREFIX` constant in the SDK's [constants.js](https://github.com/amplitude/Amplitude-JavaScript/blob/35e2dd3f342614cfb27fcb6455e361595ae222d7/src/constants.js#L36) file. The SDK defines the cookie's value in [amplitude-client.js](https://github.com/amplitude/Amplitude-JavaScript/blob/03c0a890d578db1ada383cf1e6195d71275bac44/src/amplitude-client.js#L121).

For example, if you use the default value for the prefix with the following:

```js
amplitude.getInstance().init("a2dbce0e18dfe5f8e...");
```

The Amplitude Browser 2.0 SDK creates a cookie with the format `AMP_` followed by the first 10 characters of your project's API key.

In previous versions of the SDK, you could customize the key for this cookie at initialization using the `cookieName` option. This no longer works, but if you use older SDK versions, the cookie name may differ from the standard name.

If another cookie appears with the key `amplitude_cookie_test` followed by a suffix of a random base64 string, the SDK uses that cookie to test whether the user has cookies enabled, and the SDK removes it when the test completes. For more information, refer to the detail in the SDK's [base-cookie.js](https://github.com/amplitude/Amplitude-JavaScript/blob/main/src/base-cookie.js#L97) file.

Sometimes, the SDK doesn't remove the `amplitude_test_cookie` cookie. In this case, the cookie remains in the cookie list, but the SDK doesn't use it. You can customize the key of this cookie with the `COOKIE_TEST_PREFEX` constant in the SDK's [constants.js](https://github.com/amplitude/Amplitude-JavaScript/blob/35e2dd3f342614cfb27fcb6455e361595ae222d7/src/constants.js#L35) file.

The cookie tracks the following metadata for the SDK:

- `deviceId`: A randomly generated string.
- `userId`: At user log-in, if your app sends this value to Amplitude, Amplitude stores it in the cookie. Set this to uniquely identify users. Amplitude encodes this value as Base64 before storing it.
- `optOut`: A flag to opt this device out of Amplitude tracking. If this flag is set, Amplitude stores no extra information about the user.
- `sessionId`: A randomly generated string for each session.
- `lastEventTime`: Time of the last event, used to decide when to expire and create a new session ID.
- `eventId`: An incrementing sequence of identifiers used to distinguish events.
- `identifyId`: An incrementing sequence of identifiers used to distinguish identify calls.
- `sequenceNumber`: A sequence number used to order events and identifies and to sequence them.

When the Amplitude JavaScript SDK loads, it checks the cookie for an Amplitude `device_id` (if the user is a returning user and generated a `device_id` in a previous visit). If so, the SDK uses that value. If not (either because the user is new or recently cleared cookies), the SDK randomly generates a `device_id` and saves it to the cookie.

### Cookie size

The cookie size varies from a minimum of 60 bytes to about 120 bytes. Because Amplitude can store two of them (`amp_*` and `amp_*.organization.domain`), assume 120 bytes as a safe average size for Amplitude cookies **per project API key**.

### Expiration time

The Amplitude SDK has a `cookieExpiration` option that lets you set the number of days until a cookie expires. Before SDK version 7.0, the default value was 10 years. After SDK version 7.0, `cookieExpiration` defaults to one year. Most browsers limit the lifetime of cookies set using `document.cookie` to between one and seven days.

### Remove Amplitude cookies

To programmatically remove the Amplitude cookie, use the JavaScript SDK's `clearStorage()` method. This method clears all cookies and deletes any metadata stored on them.

### Deprecated cookies

The following cookie keys are deprecated in the latest SDK versions:

- `amplitude_id_<API_KEY>.your_org_domain`: In previous versions of the Amplitude JavaScript SDK, the cookie key defaulted to `amplitude_id`. This may appear in projects that use an SDK version before 6.0.0. In that case, the cookie key is `amplitude_id_<PROJECT_API_KEY>.organization.domain`.
- `amplitude_test.your_org_domain`: The Amplitude SDK uses this cookie to more thoroughly test if cookies are available. By default, the key is `amplitude_cookie_test`. The SDK removes this cookie after the test.

## Disable cookies using LocalStorage (opt-out cookies)

The cookie contains data Amplitude needs to function correctly. It saves `deviceId`, `sessionId`, and the last event's timestamp. To store this information in a user's local storage instead, set `disableCookies` to `true` in the SDK's [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/4cbe557a81ca981d03e140bebed6134c49595a5e/src/options.js#L70) file.

### Data stored in local storage

Besides the information managed in the cookie, Amplitude uses local storage for:

- **Online events**: The `saveEvents` option in the SDK's [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/4cbe557a81ca981d03e140bebed6134c49595a5e/src/options.js#L103) controls these events (defaults to `true`). Amplitude stores every event it receives, then removes the event after successful upload. If set to `false`, events may be lost if the user navigates quickly to another page before Amplitude uploads the events.
- **Offline events**: The `savedMaxCount` option in the SDK's [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/4cbe557a81ca981d03e140bebed6134c49595a5e/src/options.js#L102) manages the number of offline events (defaults to 1000). If Amplitude logs more than 1000 events while offline, the SDK removes the oldest events from storage.
- **Failed events**: Amplitude stores failed events here for retry.

Amplitude stores this data in these keys:

- `amplitude_unsent_<PROJECT_API_KEY>`: Stores unsent events. You can customize its name with the `unsentIdentifyKey` option in the SDK's [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/4cbe557a81ca981d03e140bebed6134c49595a5e/src/options.js#L126).
- `amplitude_unsent_identify_<PROJECT_API_KEY>`: Stores unsent identify calls. You can customize its name with the `unsentKey` option in the SDK's [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/4cbe557a81ca981d03e140bebed6134c49595a5e/src/options.js#L125).

{% callout type="warning" heading="Local storage limitations" %}
Local storage restricts access by subdomain. For example, if you track non-identified users across subdomains like `www.amplitude.com` and `analytics.amplitude.com`, the `device_id` value for each subdomain isn't available while browsing the other.

The Amplitude SDK supports cross-site tracking with the `deviceIdFromURLParam` option in the SDK's [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/4cbe557a81ca981d03e140bebed6134c49595a5e/src/options.js#L71). When set to `true`, this option enables the SDK to capture the `amp_device_id` parameter from the URL. For more information, refer to [JavaScript SDK | Cross-domain tracking](/docs/sdks/analytics/browser/browser-sdk-2#cross-domain-tracking).
{% /callout %}

Other auto-captured properties aren't affected by using local storage instead of a cookie. [Refer to this article](/docs/get-started/user-property-definitions) for full detail.

This action disables cookie storage, but Amplitude stores the same data in the user's browser local storage. This isn't a valid option for a user who wants to fully opt out.

## Disable cookies and local storage / session storage (opt-out storage)

When you disable cookies and the user disables local storage and session storage, Amplitude creates a new `device_id` for that user every time they visit your site because Amplitude can't find an existing ID. If the user logs in or provides other identifying information, Amplitude's identity resolution system ties the various `device_id` values together with that user ID. The user must log in on each visit to enable Amplitude to merge identifiers.

## Disabling tracking (opt out tracking)

Users may want to opt out of cookies (which prevents Amplitude from storing any data in the cookie) and also opt out of tracking completely (which means Amplitude doesn't store events or records of their browsing history). The Amplitude SDK provides an `optOut` option to fulfill this request. To programmatically opt out of tracking, use the SDK method `amplitude.setOptOut(true)`.

### "Do not track" setting on browsers (DNT flag)

Some browsers have a "Do not track" setting intended to block all tracking. Amplitude doesn't adhere to this setting. The DNT standard isn't widely supported and it isn't clear what it's meant to disable. If you want to consider that setting, write your own code to test for the DNT flag and then set the `optOut` option in the SDK.

## Managing cookie consent

Certain jurisdictions require users to consent to non-essential cookies before you can collect any data. You're responsible for getting any necessary consents and making any necessary disclosures for the personal data you collect and send to Amplitude. You're also responsible for determining how you classify the Amplitude cookies in your cookie policy based on your specific use case and the jurisdictions in which you use them.

If you use the Amplitude SDK in one of these jurisdictions, don't initialize the SDK until the user has consented to your use of cookies. SDK initialization enables or disables Amplitude functions (for example, cookie storage, local storage, and tracking events).

To support this, the JavaScript SDK offers a `deferInitialization` option (defaults to `null`). If set to `true`, it disables the core function of the SDK (including saving a cookie or anything to the local storage) and all tracking until you explicitly enable it. The SDK instance loads without storage and tracking until you call `amplitude.getInstance().enableTracking()`.

When you call `amplitude.getInstance().enableTracking()`, Amplitude sets the `deferInitialization` option to `false` and creates the cookie with the option values you configured, as in the code in [client.js](https://github.com/amplitude/Amplitude-JavaScript/blob/03c0a890d578db1ada383cf1e6195d71275bac44/src/amplitude-client.js#L2060):

```js
/**
 * Enable tracking via logging events and dropping a cookie
 * Intended to be used with the deferInitialization configuration flag
 * This will drop a cookie and reset initialization deferred
 * @public
 */
AmplitudeClient.prototype.enableTracking = function enableTracking() {
  // This will call init (which drops the cookie) and will run any pending tasks
  this._initializationDeferred = false;
  f(this);
  this.runQueuedFunctions();
};

/**
 * Saves deviceId, userId, event meta data to amplitude cookie
 * @private
 */
var _saveCookieData = function _saveCookieData(scope) {
  const cookieData = {
    deviceId: scope.options.deviceId,
    userId: scope.options.userId,
    optOut: scope.options.optOut,
    sessionId: scope._sessionId,
    lastEventTime: scope._lastEventTime,
    eventId: scope._eventId,
    identifyId: scope._identifyId,
    sequenceNumber: scope._sequenceNumber,
  };
  if (scope._useOldCookie) {
    scope.cookieStorage.set(
      scope.options.cookieName + scope._storageSuffix,
      cookieData,
    );
  } else {
    scope._metadataStorage.save(cookieData);
  }
};
```

This doesn't affect users who have an Amplitude cookie, as shown in the code from [amplitude-client.js](https://github.com/amplitude/Amplitude-JavaScript/blob/03c0a890d578db1ada383cf1e6195d71275bac44/src/amplitude-client.js#L140). At some point, the user provided consent, which is all Amplitude needs to create the cookie legitimately. To opt that user out of tracking, remove any Amplitude cookies already set for that user.

The presence of an Amplitude Analytics cookie determines whether Amplitude tracks a user's events. For users who have one, consider the following:

1. If you manually set `cookieExpiration` to a short lifespan, you may need to run `amplitude.getInstance().enableTracking()` when the Amplitude Analytics cookie expires, or when the user logs in.

2. If the user removes all cookies, they see the consent banner again the next time they visit your app. Because no Amplitude Analytics cookie is set yet, the flow follows the [Managing cookie consent](#managing-cookie-consent) section, and the initialization of storage and tracking options waits if you use `deferInitialization = true`.

3. If the user consented to the Amplitude Analytics cookie at some point in the past, and that consent has expired for any reason (website cookie deletion, consent tracking expired), Amplitude prompts the user for consent again. If the user declines, you **must** explicitly remove the Amplitude Analytics cookie. Otherwise, it continues to collect the user's information against their will.

## Getting the SDK initialization options per project

From any site that uses the Amplitude JavaScript SDK, you can see which initialization options are set. Run the following command from the JavaScript console in the browser you use to access the site:

```js
amplitude.getInstance().options;
```

Amplitude displays the options alongside their values. For example, on amplitude.com you may see the following.

### API options in Amplitude Event Explorer Chrome extension

If you use the Amplitude Event Explorer Chrome extension, you can access the initialization options values in the "API Options" tab by first selecting the project you want.

If the Amplitude object instance isn't stored in the `window` object, this information isn't available to extract from the console or from the Chrome extension. This usually happens when using Node.js instead of the JavaScript SDK.

The error in the console appears like this.

### Storage options explained

This table gives a brief overview of each option related to storage.

| Option                 | Default Value                            | Definition                                                                                                                                                                                                                                                      |
| ---------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cookieExpiration`     | 365                                      | The number of days after which the Amplitude cookie expires. The default 12 months is for GDPR compliance.                                                                                                                                                      |
| `cookieForceUpgrade`   | False                                    | Forces SDK pre-v6.0.0 instances to adopt SDK post-v6.0.0 compatible cookie formats.                                                                                                                                                                             |
| `deferInitialization`  | Null                                     | If _`true`_, disables the core functions of the SDK, including saving a cookie and all logging, until you explicitly enable them by calling _`amplitude.getInstance().enableTracking()`_.                                                                       |
| `deviceIdFromUrlParam` | False                                    | If _`true`_, the SDK parses device ID values from the URL parameter `amp_device_id` if available. This is useful for cross-domain tracking. Device IDs defined in the configuration options during init take priority over device IDs from URL parameters.      |
| `disableCookie`        | False                                    | Disable Amplitude cookies altogether.                                                                                                                                                                                                                           |
| `domain`               | The top domain of the current page's URL | Set a custom domain for the Amplitude cookie. To include subdomains, add a preceding period, for example: _`.amplitude.com`_.                                                                                                                                   |
| `optOut`               | False                                    | Disable tracking for the current user.                                                                                                                                                                                                                          |
| `sameSiteCookie`       | None                                     | Sets the SameSite flag on the Amplitude cookie. Decides cookie privacy policy.                                                                                                                                                                                  |
| `saveEvents`           | True                                     | If `true`, the SDK saves events to local storage and removes them after successful upload. **Note:** Without saving events, events may be lost if the user navigates to another page before Amplitude uploads them.                                             |
| `savedMaxCount`        | 1000                                     | Maximum number of events to save in local storage. If the SDK logs more events while offline, it removes the oldest events.                                                                                                                                     |
| `secureCookie`         | False                                    | If `true`, the SDK sets the Amplitude cookie with the Secure flag. The secure flag lets the browser send this cookie only on encrypted HTTPS transmissions. This ensures your cookie isn't visible to an attacker in, for instance, a man-in-the-middle attack. |
| `unsentIdentifyKey`    | amplitude_unsent_identify                | _`localStorage`_ key that stores unsent identifies.                                                                                                                                                                                                             |
| `unsetKey`             | amplitude_unsent                         | _`localStorage`_ key that stores unsent events.                                                                                                                                                                                                                 |

## Abstraction layer for storage

Find the abstraction layer for storage, available options, and stored metadata in Amplitude's GitHub:

- [constants.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/constants.js).
- [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/options.js).
- [cookiestorage.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/cookiestorage.js).
- [cookie.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/cookie.js).
- [base-cookie.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/base-cookie.js).
- [localstorage.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/localstorage.js).
- [metadata-storage.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/metadata-storage.js).

Amplitude sets the options at initialization. For cookie and metadata storage, this happens in the `Init` method for the Amplitude client:

- [amplitude-client.js](https://github.com/amplitude/Amplitude-JavaScript/blob/master/src/amplitude-client.js)

```js
this.options.apiKey = apiKey;
this._storageSuffix =
  "_" +
  apiKey +
  (this._instanceName === Constants.DEFAULT_INSTANCE
    ? ""
    : "_" + this._instanceName);
this._storageSuffixV5 = apiKey.slice(0, 6);

this._oldCookieName = this.options.cookieName + this._storageSuffix;
this._unsentKey = this.options.unsentKey + this._storageSuffix;
this._unsentIdentifyKey = this.options.unsentIdentifyKey + this._storageSuffix;

this._cookieName = Constants.COOKIE_PREFIX + "_" + this._storageSuffixV5;

this.cookieStorage.options({
  expirationDays: this.options.cookieExpiration,
  domain: this.options.domain,
  secure: this.options.secureCookie,
  sameSite: this.options.sameSiteCookie,
});

this._metadataStorage = new MetadataStorage({
  storageKey: this._cookieName,
  disableCookies: this.options.disableCookies,
  expirationDays: this.options.cookieExpiration,
  domain: this.options.domain,
  secure: this.options.secureCookie,
  sameSite: this.options.sameSiteCookie,
  storage: this.options.storage,
});

const hasOldCookie = !!this.cookieStorage.get(this._oldCookieName);
const hasNewCookie = !!this._metadataStorage.load();
this._useOldCookie =
  !hasNewCookie && hasOldCookie && !this.options.cookieForceUpgrade;
const hasCookie = hasNewCookie || hasOldCookie;
```

## Frequently asked questions

{% accordion title="Are Amplitude's cookies first-party or third-party cookies?" %}
**Amplitude uses first-party cookies**. From a technical standpoint, there's no difference between first-party and third-party cookies. The distinction relates to:

1. The context of a particular visit.
2. Who creates the cookie.

Every cookie has an owner, which is the domain defined in the cookie:

- **First-party cookies** come from a website that a user views directly. If a user lands on a website (for example, `fit.amplitude.com`), this site creates a cookie that's then saved on the user's computer.
  This is how Amplitude works. When a customer adds the Amplitude JS SDK to their website, the customer (through their website) directly creates the cookie stored on the visitor's computer.

- **Third-party cookies** come from somewhere other than the website the user is visiting. Imagine you're visiting `fit.amplitude.com`, and the site uses YouTube videos for virtual non-live classes. In this case, YouTube sets the cookie that's saved on the user's computer.

The website owner embeds code, provided by YouTube, so the videos play directly in `fit.amplitude.com`. When that YouTube code executes in the browser, or the video loads, YouTube can track the player and put data in its cookies. The cookie qualifies as a third-party cookie because a domain other than `fit.amplitude.com` / `amplitude.com` creates it.
{% /accordion %}

{% accordion title="Will Google Chrome's plan to remove third party cookies affect Amplitude?" %}
**No.** As stated above, **Amplitude is not a third-party cookie**. Amplitude customers add Amplitude to their website or bundle themselves, and Amplitude sets it in their own bundled code through `document.cookie`, so Amplitude has the privileges of a first-party cookie.
{% /accordion %}

{% accordion title="Why aren't Amplitude cookies marked as `HttpOnly`?" %}
It doesn't make sense for Amplitude's cookies to be `HttpOnly`. The point of that option is to prevent `document.cookie` from reading those cookies (because they'd only be used in client-server communication). The point of Amplitude's cookies is the opposite: Amplitude **wants** to persist data in the browser and rest in `document.cookies`. Amplitude can't read from the server because Amplitude is client-side code.

If you're concerned that this makes the Amplitude cookie vulnerable to authentication information theft, you shouldn't be. Amplitude stores no authentication information in that cookie, so there's no danger of an XSS attack. The worst thing an attacker could do is steal Amplitude's cookie and take that user's device ID and user ID, which shouldn't be PII to begin with.

If this is still a serious concern for you, disable Amplitude's cookies.
{% /accordion %}

{% accordion title="Why aren't Amplitude's cookies marked as secure?" %}
The secure flag lets the browser **send the cookie only on encrypted HTTPS transmissions**. This ensures your cookie isn't visible to an attacker in, for instance, a man-in-the-middle attack. Amplitude stores no authentication information or other sensitive information in that cookie, so Amplitude isn't in danger of an XSS attack. Again, the worst thing an attacker could do is steal Amplitude's cookie and take that user's device ID and user ID.

For these reasons, Amplitude doesn't consider this a security vulnerability.
{% /accordion %}

{% accordion title="Will cookies cause unsent events to send to a project with a different API key?" %}
No. SDKs later than version 4.0.0 all scope events stored in the unsent keys (local storage) with the API key. If a product changes the project (or its API key) it's sending events to, those old events don't reach the new project.

In SDK versions before 4.0.0, this wasn't the case. The events didn't consider the API key when queued for retry. If the product still uses an old SDK version, old unsent events remaining in local storage reach the new project the moment the connection with Amplitude runs again. To mitigate this problem if you can't upgrade to a newer SDK version, try using an instance name for the project instead of the default project. Use this code to instantiate the Amplitude client: `amplitude.getInstance('ProjectName').init("API_KEY")`. Use this code to log any event: `amplitude.getInstance(ProjectName).logEvent()`.
{% /accordion %}

{% accordion title="How do you integrate with third-party Consent Management Platforms?" %}
Websites and applications can use a consent management platform (CMP) to manage legal consent from users about collecting and processing their personal data through any cookies and other trackers operating on the domain, as applicable privacy laws (such as GDPR, CCPA, and ePrivacy) may require. Some examples of these tools are OneTrust, Axeptio, and Responsum.

At the time of this writing, Amplitude doesn't have a default integration with any of these tools. Configure your CMP to pass the outcome of the consent to the Amplitude SDK, so that the Amplitude SDK opts any end user who hasn't provided consent (or who has revoked consent, depending on the end user's jurisdiction) out of tracking. The SDK as implemented on the customer's site or application must receive that signal to execute the _`amplitude.getInstance().enableTracking()`_ method while using the SDK deferred initialization as described in [**Managing Cookie Consent**](#managing-cookie-consent).
{% /accordion %}

{% accordion title="Can I use OneTrust with Amplitude to stay GDPR compliant?" %}
Yes, you can use Amplitude with a CMP, like OneTrust, in a GDPR-compliant manner. Amplitude can't direct you on how to classify the Amplitude SDK and cookies. Your privacy and legal teams should make this assessment based on the data you're collecting. Most customers, including in the EU, classify Amplitude cookies as Performance/Analytics cookies.

Customers may also choose to implement through a server-side integration, bypassing Amplitude's cookies from the SDK. Customers who integrate through a server-side integration are still responsible for getting any necessary consents and making any necessary disclosures for the personal data they collect and send to Amplitude.
{% /accordion %}

{% accordion title="When a user opts out, how can I opt them in again?" %}
Besides the `amplitude.getInstance().enableTracking()` method discussed earlier, after a user opts out you can opt them in programmatically by calling the `amplitude.setOptOut(false)` method. This sets the `optOut` option to `false`, resetting the cookie with the new options and enabling tracking. Find the following code in the Amplitude client:

```js
/**
 * Sets whether to opt current user out of tracking.
 * @public
 * @param {boolean} enable - if true then no events will be logged or sent.
 * @example: amplitude.setOptOut(true);
 */
AmplitudeClient.prototype.setOptOut = function setOptOut(enable) {
  if (this._shouldDeferCall()) {
    return this._q.push(
      ["setOptOut"].concat(Array.prototype.slice.call(arguments, 0)),
    );
  }
  if (!utils.validateInput(enable, "enable", "boolean")) {
    return;
  }
  try {
    this.options.optOut = enable;
    _saveCookieData(this);
  } catch (e) {
    utils.log.error(e);
  }
};
```

{% /accordion %}

## CNIL France - Frequently asked questions

{% callout type="warning" heading="CNIL France FAQs" %}
FAQs related to CNIL aren't intended as legal or regulatory advice and don't constitute any warranty or contractual commitment on the part of Amplitude. Amplitude encourages customers to seek independent legal advice on your legal and regulatory obligations with issues related to this subject matter.
{% /callout %}

{% accordion title="CNIL France - What is the CNIL cookie exemption?" %}
**The CNIL (Commission Nationale Informatique & Libertés)** is the French Data Protection Agency. As a general rule, the CNIL requires user consent before a website, mobile application, or other connected device can use cookies. The CNIL allows a limited exemption from this requirement for cookies that collect only anonymous, aggregated statistical data used for measuring website traffic or performance. You can't combine data collected from these cookies with other data or use it to identify users.
{% /accordion %}

{% accordion title="CNIL France - What does the CNIL cookie exemption really mean?" %}
The CNIL maintains a list of services that you can use under the exemption. Any use of an analytics service under the CNIL exemption is subject to the following limitations:

1. **You can place analytics cookies** without asking for user consent **only if they collect anonymous statistical data for audience measurement** (overall traffic, page views).
2. **This doesn't mean a customer can collect ALL data** about a user for analysis.
3. Under the exemption, **customers can't use or create "user" analyses**.

{% /accordion %}

{% accordion title="CNIL France - What does the CNIL exemption mean for Amplitude and our cookies?" %}
As discussed, the CNIL allows a limited exemption from the requirement that companies obtain user consent for any non-essential cookies. In general, this exemption applies to analytics cookies for the limited purpose of audience measurement of an app or a site, and it's limited to the use of anonymous tracers.

**A customer's use of an analytics service under the exemption is therefore very limited**. Without the CNIL cookie exemption, customers might only collect and measure part of their traffic. The power of the limited data set (for example, the data set with just the users that opt in or consent) in Amplitude is much more valuable than the limited data that you can collect under the exemption, because:

- Audience measurement (page views, overall sessions) doesn't help customers make better decisions; behavioral analytics guides actions and learning.
- Amplitude doesn't need 100% of traffic to derive meaningful insights.
- Most exempted tools don't have the powerful analytics capabilities of Amplitude.

Besides using the SDKs, customers can still send data to Amplitude server-side. This doesn't require customers to obtain consent for a separate Amplitude SDK cookie. Customers who integrate through a server-side integration are still responsible for getting any necessary consents and making any necessary disclosures for the personal data they collect and send to Amplitude.
{% /accordion %}

{% accordion title="CNIL France - 13-month cookie limit" %}
The Amplitude SDK has a [`cookieExpiration` option](#expiration-time) that lets customers set the number of days a cookie lives. It defaults to one year as of the current version. Most browsers default to limiting the lifetime of cookies set using `document.cookie` to between one and seven days.
{% /accordion %}

{% accordion title="CNIL France - 25-month data retention max" %}
Use [Amplitude's Time to Live](/docs/data/time-to-live) functionality to set a retention schedule for event data.
{% /accordion %}

{% accordion title="CNIL France - Purpose strictly limited to the sole measurement of the site's or application's audience" %}
On the requirement to have a purpose strictly limited to the sole measurement of the site's or application's audience (performance measurement, detection of browsing problems, optimization of technical performance or ergonomics, estimation of the server power required, analysis of contents consulted), for the exclusive account of the publisher: Amplitude customers fully control the data they choose to send to the Amplitude platform, and can choose to only send Amplitude events related to audience measurement and page views.

{% /accordion %}

{% accordion title="CNIL France - Only serve to produce anonymous statistical data" %}
Before you start using Amplitude to produce anonymous statistical data:

- [Contact Amplitude](https://amplitude.zendesk.com/hc/en-us/requests/new) to:
  - Request that Amplitude drop IP address for projects that contain end users who haven't provided consent.
  - Discuss disabling Amplitude's User Look-Up and the ability to view user streams for projects that contain data for end users who haven't provided consent.
  - Discuss the most effective configuration options for your use case.

- Ensure you don't send `deviceID` to Amplitude for end users who haven't provided consent.
- For end users who haven't provided consent, set a `userID` that's randomly generated or hashed.
- Consider disabling the capacity to filter end users at the individual level by hiding user properties such as `userID`, `deviceID`, and `Amplitude ID`. Review [Transformations](/docs/data/transformations) for more information.
- Consider disabling user downloads. Review [Managing Projects](/docs/admin/account-management/manage-orgs-projects) for more information.

{% /accordion %}

{% accordion title="CNIL France - Compliant with GDPR" %}
Amplitude's privacy program is based on privacy-by-design principles. Amplitude's privacy program ensures it complies with all relevant domestic and international privacy regulations and laws about processing personal data, including GDPR.

Amplitude also offers customers the choice of hosting their data in the US-West based AWS environment or the EU based AWS environment. To ensure Amplitude's customers can respond to and comply with end-user data deletion requests as required by global privacy laws such as GDPR, Amplitude built an API endpoint that lets customers programmatically submit requests to delete all data for a set of known Amplitude IDs or User IDs. For more details, refer to the developer documentation: [User Privacy API](/docs/apis/analytics/user-privacy).

You can also complete Data Subject Access Requests (DSARs) using the DSAR API, which makes it easy to retrieve all data about a single user. For more details, refer to the [CCPA DSAR API documentation](/docs/apis/analytics/ccpa-dsar).

For more information on Amplitude's stance on privacy and security, refer to [Amplitude Trust](https://amplitude.com/trust).
{% /accordion %}

{% accordion title="CNIL France - Cookies must not lead to a cross-checking of the data with other processing or that data be passed on to third parties." %}
Amplitude doesn't export data unless the customer chooses to export data to third-party products. Customers shouldn't use Amplitude to export data related to end users who haven't provided consent to third-party products.

On request, Amplitude can disable its cohort syncing and data streaming capabilities for orgs containing only data for end users who haven't provided consent.
{% /accordion %}

{% accordion title="CNIL France - Cookies must not allow the global follow-up" %}
The CNIL exemption states that cookies must not allow global follow-up of a person's navigation using different applications or browsing on different websites. Any solution that uses the same identifier across multiple sites (for example, through cookies placed on a third-party domain loaded by multiple sites) to cross-reference, duplicate, or measure a unified reach for content is excluded.

To comply with this requirement, **customers shouldn't use Amplitude's [cross-domain tracking](/docs/sdks/analytics/browser/browser-sdk-2#cross-domain-tracking)**, and should use [separate platform instrumentation](/docs/get-started/cross-platform-vs-separate-platform) for any projects with data from end users who haven't provided consent. By default, Amplitude doesn't use cross-domain tracking for customers.
{% /accordion %}

{% accordion title="CNIL France - The data is collected, processed and stored independently for each publisher" %}
In Amplitude, customer data is logically separated and stored in encrypted form in Amplitude's AWS environment.
{% /accordion %}

{% accordion title="CNIL France - The trackers are completely independent of each other and of any other tracker" %}
The cookie the Amplitude SDK uses is a [first-party cookie](#frequently-asked-questions), and the customer (as the controller of the data) collects any data the cookie collects. Amplitude only processes the customer's data as a processor or service provider, and doesn't use customer data for its own purposes.
{% /accordion %}
