Cookies and Consent Management

We use first-party cookies. From a technical standpoint there’s no intrinsic difference between first-party and third-party cookies. The distinction is related to:

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

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

• First-party cookies are issued by a website that a user views directly. So, if a user lands on a website – for example, fit.amplitude.com – then this site creates a cookie which is then saved on the user’s computer. This is the case for Amplitude. When a customer decides to use on their website our JS SDK for the tracking, it is this customer and this website the one who is directly creating the cookie that is stored in the visitor’s computer.

• Third-party cookies are not created by the website being visited, but rather by someone else. Let’s say you’re visiting fit.amplitude.com, and this site uses YouTube videos for the virtual non-live classes. In this case, it will be YouTube who is setting a cookie which is then saved on the user’s computer.

  What is happening in this case is that the website owner is embedding pieces of code, provided by YouTube, for the videos to play directly in fit.amplitude.com. When that YouTube code is executed in the browser, or the video is loaded, YouTube can track the player and put data in its cookies. As a result, the cookie is classified as a third-party cookie, because it’s created by a different domain than fit.amplitude.com / amplitude.com

No, as previously indicated, Amplitude is not a third-party cookie. Amplitude customers add Amplitude to their website/bundle themselves and Amplitude sets it in their own bundled code through document.cookie, so Amplitude has the privilege of a first-party cookie.

It doesn’t really make sense for our cookies to be HttpOnly; the point of that option is so that document.cookie can’t read those cookies (since they’d only be used in the client-server communication). But the point of our cookies is the opposite: Amplitude wants to persist data specifically in their browser and be put in document.cookies, Amplitude can’t read from their server because Amplitude is client-side code.

For what it’s worth, the concerns of having our cookie be not HttpOnly are not really aligned with the fact of stealing authentication information: Amplitude has have no authentication information in that cookie so we’re not in danger of a XSS attack. The worst thing an attacker could do is steal our cookie and take that user’s device ID and user ID, which shouldn’t be PII to be begin with.

Nonetheless, if this is a serious concern for the customer, they should probably disable our cookies.

The secure flag is an additional flag for letting the browser send the cookie only when on encrypted HTTPS transmissions. This ensures that your cookie is not visible to an attacker in, for instance, a man-in-the-middle attack. We have no authentication information in that cookie nor any type of sensitive information, so we’re not in danger of a XSS attack not needing to set the cookie as secure by default. Again, the worst thing an attacker could do is steal our cookie and take that user’s device ID and user ID.

Based on those premises, Amplitude does not consider this as a security vulnerability.

No, the SDK versions later than 4.0.0 scope with the API key all events stored in the unsent keys (local storage) so if a product changes the project (or its API key) it is sending the events to, those old events won’t reach the new project.

Note – In SDK versions prior to 4.0.0, this wasn’t the case, and the events didn’t consider the API Key when queued to be retried. So, if the product is still using an old SDK version, the old unsent events remaining in local storage will unfortunately reach the new project the moment the connection with Amplitude runs again. A way that might mitigate this problem in the case the customer can’t upgrade to a newer SDK version is to use an instance name for the project instead of using the default project. Like this to instantiate the Amplitude client amplitude.getInstance(‘ProjectName’).init("API_KEY") and like this to log any event amplitude.getInstance(ProjectName).logEvent()

A consent management platform – or “CMP” – is a technology that websites/applications can use to manage legal consent from users to collect and process their personal data through cookies and other trackers in operation on the domain as may be required by applicable privacy laws, such as GDPR, CCPA and ePrivacy. Some examples of these tools are OneTrust, Axeptio or Responsum.

At the time of writing this document, Amplitude does not have an OOTB integration with any of these tools. Therefore, the customer must configure their CMP to pass the outcome of the consent to the Amplitude SDK, so that any end user that has not provided consent or has revoked consent (depending on the end user’s jurisdiction) will be opted out of tracking by the Amplitude SDK. That signal must be received by the SDK as implemented on the customer’s site/application to execute (if consent is accepted) the method amplitude.getInstance().enableTracking() while using the SDK deferred initialization as indicated in the section “Managing Cookie Consent”.

Yes, Amplitude can be used in connection with a CMP, like OneTrust, in a GDPR compliant manner. However, in order to ensure compliance, customers must implement Amplitude in a way that meets their compliance needs. Amplitude is not able to advise customers on how to classify the Amplitude SDK/cookies as this is up to our customers’ privacy and legal teams to assess based on the data being collected. However, almost all customers, including in the EU, classify Amplitude cookies as Performance/Analytics cookies.

Additionally, customers may choose to implement via a server side integration, therefore bypassing Amplitude’s cookies from the SDK. However, customers who integrate via a server side integration will still be responsible for ensuring that they obtain any necessary consents and make any necessary disclosures for the personal data they collect and send to Amplitude.

Besides the method amplitude.getInstance().enableTracking() previously discussed, once a user has been opted-out, it can be opted-in programmatically by calling the method amplitude.setOptOut(false). This will set the option optOut to false, re-setting the cookie with the new options and enabling the tracking. You can find the following code in the amplitude client:

/**
* 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);
}
};

The CNIL (Commission Nationale Informatique & Libertés) is the French Data Protection Agency. As a general rule, the CNIL requires the consent of users before cookies can be used on a website, a mobile application or other connected device. The CNIL allows for a very limited exemption from this requirement for cookies that collect only anonymous, aggregated statistical data that's used for measuring website traffic or performance. Data collected from these cookies can't be combined with other data or used to identify users.

The CNIL maintains a list of services which can be used under the exemption. However, 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 only collect anonymous statistical data for audience measurement (overall traffic, page views).
2. It 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.

As discussed, the CNIL allows for 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 a site, and it's limited to the use of anonymous tracers.

Therefore, a customer’s use of an analytics service under the exemption will be very limited. Without the CNIL cookie exemption, customers might only collect and measure part of their traffic. However,the power of the limited data set (for example, the data set with just the users that opt-in/consent) in Amplitude is much more valuable than the very limited data that can be collected under the exemption. This is because:

Audience measurement (page views, overall sessions) don't help customers make better decisions; behavioral analytics guide actions and learning.

Amplitude doesn't need 100% of traffic to derive meaningful insights.

Most of the 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. However, as mentioned above, customers who integrate via a server side integration will still be responsible for ensuring that they obtain any necessary consents and make any necessary disclosures for the personal data they collect and send to Amplitude.

The Amplitude SDK has a cookieExpiration option to allow customers to set the number of days a cookie will live. It defaults to 1 year as of the current version. However, most browsers will by default limit the lifetime of cookies set using document.cookie from 1 to 7 days.

Customers can use Amplitude’s Time to Live functionality to set a retention schedule for their event data.

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 are in full control of the data that they choose to send to the Amplitude platform, and can choose to only send Amplitude events related to audience measurement/page views.

To use Amplitude to produce anonymous statistical data, Amplitude recommends taking the following steps:

• Reach out to Amplitude at cnil-support@amplitude.com, if you are a prospective customer, or via this form, if you are an existing customer, to:

  • request that IP address be dropped 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; and
  • discuss the most effective configuration options for your use case.

• 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 capacity to filter end users at the individual level by hiding user properties, such as userID, deviceID and Amplitude ID. See this documentation. -Consider disabling user downloads. See this documentation.

Amplitude’s privacy program is based on privacy-by-design principles. Amplitude's privacy program ensures that it complies with all relevant domestic and international privacy regulations and laws regarding the processing of personal data, including GDPR.

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

Additionally, Data Subject Access Requests (DSARs) can be completed using the DSAR API, which makes it easy to retrieve all data about a single user. More details can be found here.

More information on Amplitude’s stance on privacy and security can be found here.

No data is exported from Amplitude 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.

Additionally, upon request, Amplitude can disable its cohort syncing and data streaming capabilities for orgs containing only data for end users that haven't provided consent.

The CNIL exemption mentions that cookies must not allow the global follow-up of the navigation of the person 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, and should use a separate platform instrumentation for any projects with data from end users that haven't provided consent. By default, Amplitude doesn't employ cross domain tracking for customers.

In Amplitude, customer data is logically separated and stored in encrypted form in Amplitude’s AWS environment.

The cookie used by the Amplitude SDK is a first party cookie and any data collected by the cookie is collected by the customer as the controller of the data. Amplitude only processes the customer’s data as a processor / service provider, and doesn't use customer data for its own purposes.