{% callout type="warning" heading="Legacy JavaScript SDK" %} This guide covers 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 how Amplitude works with cookies, local storage, opt-in/opt-out options, and consent management (including CNIL regulations for France) when you use the legacy JavaScript SDK. {% callout type="info" heading="Recommended migration" %} For the most up-to-date 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 that the browser stores on a user's device. 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 constant `COOKIE_PREFIX` 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 SDK versions, you could customize the key for this cookie at initialization with 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 random base64 suffix, the SDK uses the cookie to test whether the user has cookies enabled. The SDK removes this cookie when the test completes. For more information, refer to 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 isn't used. 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 SDK uses the cookie to track the following metadata: - `deviceId`: A randomly generated string. - `userId`: When a user logs in, if your app sends this value to Amplitude, the SDK stores it in the cookie. Set this value to uniquely identify users. Amplitude encodes this value as Base64 before storing it. - `optOut`: A flag that opts this device out of Amplitude tracking. When 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 that distinguishes events. - `identifyId`: An incrementing sequence of identifiers that distinguishes identify calls. - `sequenceNumber`: A sequence number that orders events and identify calls. When the Amplitude JavaScript SDK loads, it checks the cookie for an Amplitude `device_id` (which exists if the user is returning and generated a `device_id` in a previous visit). If found, the SDK uses that value. Otherwise (for a new user or one who recently cleared cookies), the SDK randomly generates a `device_id` and saves it to the cookie. ### Cookie size Cookie size can vary from a minimum of 60 bytes to about 120 bytes. Because Amplitude can store two cookies (`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 through `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_.your_org_domain`: In previous versions of the Amplitude JavaScript SDK, the default cookie key was `amplitude_id`. This may appear in projects that use an SDK version earlier than 6.0.0. In that case, the cookie key is `amplitude_id_.organization.domain`. - `amplitude_test.your_org_domain`: The Amplitude SDK uses this cookie to test more thoroughly if cookies are available. By default, the key is `amplitude_cookie_test`, and the SDK removes this cookie after the test. ## Disable cookies using LocalStorage (opt-out cookies) The cookie contains data necessary for Amplitude 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 this storage (defaults to `true`). Amplitude stores every event it receives and removes it after successful upload. When set to `false`, events may be lost if the user navigates to another page before upload completes. - **Offline events**: The `savedMaxCount` option in the SDK's [options.js](https://github.com/amplitude/Amplitude-JavaScript/blob/4cbe557a81ca981d03e140bebed6134c49595a5e/src/options.js#L102) sets the number of offline events (defaults to 1000). If Amplitude logs more than 1000 events offline, the SDK removes the oldest events from storage. - **Failed events**: The SDK stores any failed event here for retry. Amplitude stores this data in the following keys: - `amplitude_unsent_`: 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_`: 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`, the SDK captures 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 LocalStorage instead of a cookie. For full detail, refer to [User property definitions](/docs/get-started/user-property-definitions). This action disables cookie storage, but Amplitude stores the same data in the user's browser Local Storage. It isn't a valid option for a user that 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 on every visit because the SDK 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 so Amplitude can 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 `optOut` to fulfill this request. To programmatically opt out of tracking, call `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 the scope of what it disables isn't clear. To honor that setting, write your own code to test for the DNT flag and then set the `optOut` option in the SDK. ## Managing cookie consent Some jurisdictions require users to consent to non-essential cookies before data collection. You're ultimately responsible for getting necessary consents and making 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 consents to your use of cookies. The Amplitude functions (for example, cookie storage, local storage, and tracking events) are enabled or disabled at SDK initialization. To support this, the JavaScript SDK offers a `deferInitialization` option (defaults to `null`). When set to `true`, this option disables the core SDK functions, including saving a cookie (or anything to local storage) and all tracking, until you explicitly enable them. The SDK instance loads without storage and tracking until you call `amplitude.getInstance().enableTracking()`. When you call `amplitude.getInstance().enableTracking()`, the SDK sets `deferInitialization` to `false` and Amplitude creates the cookie with the options values you configured, as shown 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 already have an Amplitude cookie, as shown in [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, you must remove any Amplitude cookies that already exist 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 exists yet, the flow proceeds as described in the [Managing cookie consent](#managing-cookie-consent) section, and the initialization of storage and tracking options waits when you use `deferInitialization = true`. 3. If the user consented to the Amplitude Analytics cookie 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, the SDK 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 find 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; ``` The console displays each option alongside its value. 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 after selecting the project you're interested in. If the Amplitude object instance isn't stored in the `window` object, this information isn't available from the console or the Chrome extension. This usually happens when you use 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 storage-related option. | Option | Default Value | Definition | | ---------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `cookieExpiration` | 365 | The number of days after which the Amplitude cookie expires. The default 12 months supports GDPR compliance. | | `cookieForceUpgrade` | False | Forces SDK pre-v6.0.0 instances to adopt SDK post-v6.0.0 compatible cookie formats. | | `deferInitialization` | Null | When `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 | When `true`, the SDK parses device ID values from the URL parameter `amp_device_id` if available. This option supports cross-domain tracking. Device IDs defined in the configuration options during init take priority over device IDs from URL parameters. | | `disableCookie` | False | Disables Amplitude cookies altogether. | | `domain` | The top domain of the current page's URL | Sets a custom domain for the Amplitude cookie. To include subdomains, add a preceding period, for example, `.amplitude.com`. | | `optOut` | False | Disables tracking for the current user. | | `sameSiteCookie` | None | Sets the SameSite flag on the Amplitude cookie. Decides cookie privacy policy. | | `saveEvents` | True | When `true`, the SDK saves events to local storage and removes them after successful upload. Without saving events, the SDK may lose them if the user navigates to another page before upload completes. | | `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 | When `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 that your cookie isn't visible to an attacker in a man-in-the-middle attack. | | `unsentIdentifyKey` | amplitude_unsent_identify | `localStorage` key that stores unsent identify calls. | | `unsetKey` | amplitude_unsent | `localStorage` key that stores unsent events. | ## Abstraction layer for storage You can find the storage abstraction layer, 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) The SDK 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. When a user lands on a website (for example, fit.amplitude.com), this site creates a cookie that the browser saves on the user's computer. Amplitude works this way. 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 a different source than the website being visited. 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 saved on the user's computer. The website owner embeds code, provided by YouTube, so the videos play directly on 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. This cookie qualifies as a third-party cookie because a different domain 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 previously, Amplitude isn't a third-party cookie. Amplitude customers add Amplitude to their website or bundle themselves, and Amplitude sets the cookie 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`?" %} The HttpOnly option exists so that `document.cookie` can't read cookies (because those cookies are only for client-server communication). Amplitude's cookies serve the opposite purpose: Amplitude needs to persist data specifically in the browser and to rest in `document.cookies`. Amplitude can't read from their server because Amplitude is client-side code. If you're concerned that this renders 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 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, then you should probably 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 that your cookie isn't visible to an attacker in a man-in-the-middle attack. Amplitude has no authentication or sensitive information in that cookie, so Amplitude isn't in danger of an XSS attack. The worst 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 scope events stored in the unsent keys (local storage) by API key. If a product changes the project (or its API key) it sends events to, those old events don't reach the new project. In SDK versions earlier than 4.0.0, 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 when the connection with Amplitude runs again. To mitigate this problem when you can't upgrade to a newer SDK version, use an instance name for the project instead of the default project. Use this to instantiate the Amplitude client: `amplitude.getInstance('ProjectName').init("API_KEY")`, and use this 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 cookies and other trackers operating on the domain, as required by applicable privacy laws such as GDPR, CCPA, and ePrivacy. Examples of these tools include OneTrust, Axeptio, and Responsum. Currently, Amplitude doesn't have a default integration with any of these tools. You must configure your CMP to pass the consent outcome to the Amplitude SDK so that any end user who hasn't provided consent or who has revoked consent (depending on the end user's jurisdiction) is opted out of tracking by the Amplitude SDK. 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 or cookies. Instead, 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 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 necessary consents and making 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 `amplitude.setOptOut(false)`. This sets the `optOut` option to `false`, resets the cookie with the new options, and enables tracking. You can 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" %} CNIL FAQs aren't intended as legal or regulatory advice and don't constitute any warranty or contractual commitment from Amplitude. Amplitude encourages customers to seek independent legal advice on legal and regulatory obligations 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 for cookies that collect only anonymous, aggregated statistical data used to measure 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 can run under the exemption. Any use of an analytics service under the CNIL exemption is subject to the following limitations: 1. Analytics cookies can ONLY be placed without asking for user consent if they collect ONLY 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?" %} The CNIL allows a limited exemption for 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 site, and it's limited to 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 in Amplitude (for example, the data set with just the users that opt in or consent) is more valuable than the limited data collected under the exemption, because: - Audience measurement (page views, overall sessions) doesn't help customers make better decisions; behavioral analytics guide actions and learning. - Amplitude doesn't need 100% of traffic to derive meaningful insights. - Most exempted tools don't have the analytics capabilities of Amplitude. Besides using the SDKs, customers can 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 necessary consents and making 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 1 year as of the current version. Most browsers limit the lifetime of cookies set through `document.cookie` to between 1 and 7 days by default. {% /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 of having 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 its ergonomics, estimation of the power of the servers 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. Customers can send only 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 the SDK drop IP addresses for projects that contain end users that 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 that 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 that haven't provided consent. - For end users that haven't provided consent, set a `userID` that's randomly generated or hashed. - Consider disabling the ability to filter end users at the individual level by hiding user properties such as `userID`, `deviceID`, and `Amplitude ID`. Refer to [Transformations](/docs/data/transformations) for more information. - Consider disabling user downloads. Refer to [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 complies with relevant domestic and international privacy regulations and laws for processing personal data, including GDPR. Amplitude offers customers the choice of hosting their data in the US-West based AWS environment or the EU based AWS environment. To ensure that Amplitude's customers can respond to and comply with end-user data deletion requests 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 [User Privacy API](/docs/apis/analytics/user-privacy) developer documentation. You can complete Data Subject Access Requests (DSARs) through the [DSAR API](/docs/apis/analytics/ccpa-dsar), which makes it easy to retrieve all data about a single user. For more information on Amplitude's stance on privacy and security, refer to the [Amplitude trust page](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 that haven't provided consent to third-party products. On request, Amplitude can disable its cohort syncing and data streaming capabilities for orgs that contain only data for end users that 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 the global follow-up of the navigation of the person using different applications or browsing on different websites. The exemption excludes 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. 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 that 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 used by the Amplitude SDK is a [first-party cookie](#frequently-asked-questions). The customer collects any data the cookie collects as the controller of the data. Amplitude only processes the customer's data as a processor or service provider and doesn't use customer data for its own purposes. {% /accordion %}