Privacy and consent implementation guide

You can set up Amplitude in a privacy-friendly way. The right setup depends on your policy, your region, and how much data you want to collect before consent. Before you choose a method, align with your legal and privacy teams on what's allowed in your case.

A good way to think about this: first choose your consent model, then configure storage and access in Amplitude to match it.

Using this guide

This guide helps you implement a privacy-conscious analytics setup in Amplitude. It doesn't replace legal advice. Your team decides which consent model, disclosures, and regional requirements apply to your business. This guide shows you practical ways to implement those choices in Amplitude.

There's no single setup that fits every company. Some organizations need strict opt-in before analytics starts. Others may use a more limited measurement-only approach in some regions. The right choice depends on your product, your data, and the rules that apply where you operate.

Use this guide as a decision and implementation framework:

1. Choose the consent method that fits your policy.
2. Configure Amplitude to match that method.
3. Add the governance, retention, and deletion controls you need.
4. Validate the setup before launch.

The guide covers common implementation patterns and the controls most teams need first. For complex use cases, use it as a starting point and identify the decisions to make with your legal, privacy, and security teams.

Before you start

Before you configure anything, answer these three questions:

1. Do you need consent before analytics starts?
2. Do you want to collect no data, or limited anonymous measurement, before consent?
3. Which fields should reach Amplitude at all?

You're responsible for obtaining any required consent, making the right disclosures, and deciding how to classify Amplitude cookies in your policy.

A practical starting point is to write down:

• which events you want to collect.
• which identifiers you want to store.
• which properties are sensitive.
• what should happen when a user declines consent.
• what should happen when a user grants consent after an initial decline.

That one-page decision document makes the implementation much easier to review and test.

Choose the setup that fits your policy

Method 1: Ask for consent and collect data only from users who consent

This is the clearest option if your policy requires consent before analytics begins. It's also the easiest model to explain to users and auditors because nothing starts until the user grants consent.

How it works

In Browser SDK 2, the SDK may create Amplitude cookies as soon as it initializes. If you need to avoid cookies before consent, don't initialize the SDK until the user has consented.

How to set it up in Amplitude

Only call amplitude.init() after consent is captured. Let your site load normally, and hold off on initializing until your consent tool confirms that analytics is allowed.

import * as amplitude from '@amplitude/analytics-browser';

// User hasn't consented yet.
// Don't initialize the SDK here.

function onConsentGranted() {
  amplitude.init('API_KEY');
}

If you need to anonymize a user after logout, call amplitude.reset(). This clears the userId and creates a new deviceId. The next activity appears as a new anonymous user until the user signs in again.

What to do outside Amplitude

Use your CMP to control whether initialization happens. Amplitude doesn't provide a default CMP integration, so your CMP needs to pass the consent outcome into your Amplitude implementation.

Centralize SDK initialization

Make amplitude.init(...) run from one place only. If several teams initialize the SDK in different parts of the site, proving that tracking is gated by consent becomes much harder.

When you test this setup, open your browser developer tools and confirm that no Amplitude cookies are present before consent.

Method 2: Ask for consent, but collect limited anonymous measurement from users who don't consent

Some organizations want a middle ground: full analytics for users who consent, and very limited measurement for users who don't. This can be appropriate only when your legal team confirms that this kind of limited audience measurement is allowed in your jurisdictions.

How it works

Keep this method limited to anonymous or strongly minimized audience measurement, such as total traffic or page views. Don't let it turn into user-level behavioral analysis.

Rules can vary across Europe, so treat local regulatory guidance as part of the implementation decision. France is one well-known example: the Cookies and consent management guide describes the CNIL exemption as a narrow case for anonymous statistical audience measurement without consent, not full analytics. It's a useful reference point, but don't treat it as the default rule for every European market.

How to set it up in Amplitude

For the limited anonymous flow, reduce or remove persistent identity:

• Set identityStorage to none if you don't want persistent browser identity.
• Set identityStorage to session if you want to track users within a single session but not across sessions. This is a useful middle ground for some implementations.
• Avoid sending a stable userId.
• Keep the event set small and focused on aggregate traffic measurement.

amplitude.init('API_KEY', {
  identityStorage: 'none',
});

You can also shorten cookie duration if your policy allows cookies but you want a more conservative setup.

What to do outside Amplitude

Decide exactly which events belong in the anonymous flow. Keep that list short. For most teams, that means page views, traffic totals, and other high-level measurement only.

If you need stronger control, send data through your own proxy before it reaches Amplitude. A domain proxy can help you filter, block, or anonymize data before forwarding it.

Keep the anonymous flow narrow

If you choose this method, be disciplined. Don't quietly turn a "limited anonymous measurement" flow into full behavioral analytics over time. The more your anonymous flow starts to look like user analysis, the weaker your privacy position becomes.

Keep consented and non-consented data in separate projects

If you collect both consented analytics data and a limited non-consented measurement stream, always keep them in separate Amplitude projects. Mixing the two into a single project creates problems that are difficult to untangle later. Three reasons to be strict about this from the start:

• Reporting integrity: non-consented data uses minimized or rotating identifiers, so user-level metrics like uniques, funnels, and cohorts behave very differently from your consented data. Keeping them separate makes it clear which numbers mean what.
• Risk of unintended user stitching: Amplitude resolves identity at the organization level, not the project level. If the same user ID or device ID appears in both projects, Amplitude treats them as the same user. If your non-consented project wasn't designed with this in mind, you may inadvertently link anonymous data to identified users across projects.
• Access control: the non-consented project should have tighter controls. Disable individual user-level event lookup so analysis stays at the aggregate level. This is much easier to enforce when the data is already in its own project.

Configure the non-consented project more strictly

Separate projects let you configure the non-consented stream differently from the start. In practice, that usually means using the stricter setup in the non-consented project: no cookies, no persistent storage, no stable user ID, and a minimal event set.

How to set it up

A common setup looks like this:

• one project for consented users, where full analytics begins after consent.
• one project for non-consented users, where you only send the limited anonymous measurement events your policy allows.

When a visitor hasn't consented, route the allowed events to the non-consented project. If the visitor later gives consent, initialize Amplitude with the consented project and begin normal tracking there.

If you use this approach, make sure your identity strategy is intentional in both projects. Across projects in the same organization, Amplitude assumes that the same user ID or device ID refers to the same user. That's useful for legitimate cross-project analysis, but it also means you should be careful not to reuse identifiers across consent states unless that matches your legal and implementation model.

Restrict user-level access where appropriate

For some teams, separating projects isn't enough on its own. They also want the project that contains non-consented data to have tighter access to user-level views.

In those cases, review whether features such as User Lookup, user profiles, user streams, or similar user-level surfaces should remain available for that project. This is especially relevant if the project contains anonymous or non-consented data and your privacy posture is meant to avoid individual-level exploration.

As a practical rule, many teams want a stricter setup for the non-consented project and a more standard setup for the consented one. If you need that kind of project-specific restriction, discuss it with your Amplitude team as part of the implementation design so they apply the right controls for your organization.

Disabling User Lookup at the project level

In addition to DAC and RBAC, Amplitude supports disabling the User Lookup feature at the project level. When your Amplitude team enables this setting, team members can't access individual user event streams from contextual menus in charts and dashboards (for example, the microscope icon that opens a user's event stream).

This control is especially relevant when your privacy posture requires analysis to happen at the aggregate level only, and you want to prevent access to raw individual-level user events. For example, to comply with CNIL requirements in France, the exemption for analytics without consent applies only to aggregate statistical measurement.

Your Amplitude team manages this setting at the project level. To apply it, contact your Amplitude team so they can enable it as part of your project configuration. You can also control broader user-level access using RBAC, but the User Lookup control is separate and more targeted, specifically for disabling individual event stream access.

Use Portfolios to combine top-line reporting

If you want to analyze consented and non-consented projects together, use a Portfolio view.

Portfolio lets you combine multiple projects into one cross-project view so you can build charts across them. This is useful when you want a broader picture of traffic or activity across consent states without collapsing the underlying implementations into one project.

A good pattern is to:

• keep the data collection separate.
• use a Portfolio to report across both projects where that makes sense.
• set expectations clearly about what can and can't be combined.

For example, top-line event counts may be useful across both projects, while user-level metrics require more caution. If the non-consented project uses minimized identity, don't expect Portfolio reporting to recreate the same kind of user continuity you have in the consented project.

Document the routing rules

If you adopt the separate-projects pattern, document it clearly for both implementers and analysts. Teams should know:

• which events go to which project.
• when traffic moves from the non-consented project to the consented project.
• which identifiers are allowed in each project.
• which user-level features should be restricted in the non-consented project.
• which charts should use the Portfolio view versus a single source project.

This is one of the most practical ways to support privacy-sensitive measurement while keeping your analytics setup understandable and maintainable.

Method 3: Don't ask for consent, but reduce identifiers and data collection where your policy allows it

In some regions or use cases, your legal team may decide that consent isn't required for your analytics setup. If so, you can still make that setup more privacy-friendly by limiting identifiers, shortening storage, and minimizing what you send.

How to set it up in Amplitude

Choose the storage mode that matches your policy:

• cookie for standard browser persistence.
• localStorage if you prefer browser storage without cookies.
• none if you want no persistent identity.

If you use localStorage, remember that it's limited by subdomain. A user on one subdomain won't automatically carry the same stored identity to another.

If you use identityStorage: "none", Amplitude generates a new device_id on every page load (or app start), because there's no stored identity to reuse between loads.

What to do outside Amplitude

Make sure your privacy notice matches what you're actually doing. If you're not asking for consent, your policy should still explain what you collect, why, and how users can opt out if that applies to your model.

Minimize data by default

Even when consent isn't required, data minimization is still a good default. Collect what you need, not what happens to be available.

Use a proxy when you want tighter control

A domain proxy is useful when you want more control over what reaches Amplitude. It lets you send tracking requests through your own domain and can help with filtering, blocking, debugging, audit logging, and anonymization before forwarding data to Amplitude.

This is especially helpful if you want to remove fields such as IP address, location, or userId before data leaves your environment. A proxy isn't the only way to do this. You can also exclude or suppress specific fields directly in the SDK at initialization time, which is easier when you only need to strip a small number of fields client-side.

If you build a proxy, involve your developer operations and information security teams early.

Keep noisy traffic out of your data

Privacy settings work better when your data is also clean.

Block bot traffic

If you track public web traffic, bot traffic can distort your metrics. Amplitude lets you create a block filter so this data is never ingested in the first place.

To set it up:

1. Go to your project's main branch.
2. Open Filters.
3. Open the Block Filters tab.
4. Click Create Block Filter.
5. Select Bot Traffic.
6. Save the filter.

Amplitude blocks bots based on the User-Agent, using the IAB/ABC International Spiders and Bots List.

Block internal traffic

If your team tests in production, block internal IP addresses so employee traffic doesn't inflate your metrics. In Amplitude Data, create a block filter for Events where IP Address equals the addresses you want to block.

A good practice is to keep a separate development project for testing and only use production for final validation.

Restrict who can see sensitive data

Collecting data responsibly is only half the job. You should also control who can see it.

Amplitude's Data Access Control (DAC) lets you classify properties as PII, revenue, or sensitive, then grant or deny access to those classifications by group.

With DAC enabled:

• restricted users can't view charts, cohorts, dashboards, notebooks, or user sessions that contain restricted data.
• Amplitude hides classified properties from Event Stream and User or Account Lookup.
• restricted values appear as [DAC Restricted].

To set it up:

1. Ask Amplitude Support to enable DAC for your organization.
2. In Amplitude Data, classify the properties you want to protect.
3. In Settings > Organization settings > Groups, open the group and configure access on the Data Access tab.

If you want broader role control beyond sensitive properties, use RBAC to define what users can do in each project and assign those roles through groups.

Set a retention period

If you don't need to keep event data forever, set a retention period.

Amplitude's Time to Live (TTL) lets you define event retention at the organization level and override it per project.

To configure it:

1. Ask Amplitude to enable TTL controls for your organization if they aren't already enabled.
2. Go to Organization Settings.
3. Open the Time to Live (TTL) tab.
4. Choose a retention period and confirm.
5. Add project-level overrides if some projects need a different retention policy.

Be careful here. TTL causes irreversible data loss, and existing charts zero out for periods outside the retention window.

A good rule is to set a shorter TTL for higher-risk datasets and a longer one only where there's a clear business need.

Prepare for deletion requests

If a user asks you to delete their data, you need a process that covers both Amplitude and any upstream systems.

Amplitude's User Privacy API lets you programmatically submit deletion requests for known Amplitude IDs or User IDs.

By default, deletions are project-based. If you want to delete the user across your organization, set delete_from_org to true.

Two things matter in practice:

• deleting a user doesn't block future tracking for that user.
• if the same user data still exists in your warehouse or another ingestion source, Amplitude may ingest it again on the next sync.

So your deletion workflow should be:

1. Receive the request.
2. Identify the correct user IDs.
3. Delete the user in Amplitude.
4. Delete the same user from the warehouse or any synced source.
5. Log completion for audit purposes.

Validate your setup before launch

After your setup is live, test it with real scenarios.

At minimum, test:

• a visitor who hasn't consented.
• a visitor who grants consent.
• a signed-in user.
• a user who logs out.
• a user whose data is deleted.

In Amplitude, use User Lookup to inspect the event stream for a specific user and confirm what data was actually ingested.

For each test case, check:

• whether the SDK initialized.
• whether Amplitude cookies or storage were created.
• whether the expected events were sent.
• whether the expected identifiers were present.
• whether restricted data is visible only to the right users.

This step is worth the time. Most privacy issues come from small implementation gaps, not from the policy itself.

Recommended rollout order

If you want a simple order of operations, use this:

1. Choose the consent method.
2. Decide what data is allowed.
3. Configure SDK initialization and storage.
4. Connect your CMP if needed.
5. Add filters for bots and internal traffic.
6. Classify and restrict sensitive properties.
7. Set data retention.
8. Document your deletion workflow.
9. Validate everything with end-to-end tests.

That sequence keeps the work manageable and makes it much easier to explain your setup to internal stakeholders and external auditors.

Additional considerations

Depending on your implementation, you may need to configure more than cookies, storage, and access controls. The topics below are worth reviewing before you consider your setup complete.

Session Replay

If you use Session Replay, review it separately from your core analytics setup. Replay can capture a richer set of user interactions, so it often requires its own privacy review, masking rules, and consent treatment.

In practice, this means you should:

• decide whether Replay is covered by the same consent choice as analytics or needs separate treatment.
• review masking and exclusion settings before rollout.
• make sure your privacy notice accurately describes the use of replay technology.

You can learn more in the Session Replay documentation.

Access requests, not only deletion requests

Many privacy programs focus first on deletion, but customers may also need to respond to requests for access to personal data. If you support privacy requests, plan for both.

For deletion workflows, use the User Privacy API. If you also need to support data access requests, refer to the DSAR API documentation.

A good practice is to document one operational workflow that covers:

• request intake.
• identity verification.
• access or deletion in Amplitude.
• cleanup in upstream systems.
• audit logging.

Privacy notices and disclosures

Your implementation and your privacy notice should stay aligned. If you collect analytics data, use Session Replay, or rely on a limited anonymous measurement flow, review your disclosures to make sure they still describe what you collect, why you collect it, and how users can exercise their choices.

This is especially important when teams change implementation details over time. A privacy issue is often caused not by the tool itself, but by a gap between what the product does and what the notice says.

Hosting region and data residency

For some organizations, especially in Europe, hosting region is part of the privacy decision. Amplitude offers both US and EU data center options, and that choice may affect your internal review process.

If data residency matters to your business, confirm your hosting setup early and make sure it matches your internal requirements. You can learn more about data residency options.

Operational caveats after launch

Some privacy controls work exactly as expected, but still have practical consequences that teams should plan for.

A few important examples:

• deleting a user doesn't prevent Amplitude from tracking that user again.
• if deleted data still exists in a warehouse or synced source, Amplitude may reingest it.
• retention settings can permanently remove historical data and affect old charts.
• test privacy settings after every major instrumentation or tag-management change.

A good rollout doesn't end at launch. Re-test your setup periodically, especially after SDK updates, consent banner changes, new event launches, or changes to upstream pipelines.

When to ask for help

If your setup includes regional legal complexity, multiple consent categories, sensitive personal data, or multiple downstream activation tools, involve your legal, privacy, and security teams early. It's much easier to design a privacy-conscious setup from the start than to retrofit one later.

In general, the safest approach is to keep the implementation simple, collect only what you need, and add complexity only when there's a clear business and legal case for doing so.

Server-side tracking as an alternative for known users

For logged-in or identified users, server-side tracking offers an alternative that avoids some client-side consent constraints. If a user is authenticated, you can pass their user ID directly to Amplitude's HTTP API from your backend, bypassing the browser SDK entirely.

In many jurisdictions, server-side tracking of authenticated users doesn't trigger ePrivacy Directive requirements. ePrivacy applies to accessing or storing information on the user's device (cookies, localStorage, and so on), and server-side calls don't touch the device. For logged-in users, server-side Amplitude tracking may therefore not require consent under ePrivacy rules in some regions.

Important caveats:

• This only applies to known, logged-in users. For anonymous visitors, you still need a client-side identifier to track behavior across pages, even if your server generates that identifier (as with cookieless tracking approaches). As soon as you store or access any persistent identifier on the user's device, ePrivacy rules apply.
• Your legal team should confirm whether server-side tracking of identified users is sufficient for your jurisdiction and use case.
• Confirm with your privacy team that processing authenticated user data server-side aligns with your data processing agreements and your GDPR lawful basis.

Why Amplitude doesn't generate modeled data for non-consenting users

Some analytics platforms fill in the gap left by non-consenting users by modeling estimated behavior, statistically inferring what those users might have done based on users who did consent. Amplitude doesn't take this approach. Here's why.

• Modeled data is inconsistent and hard to interpret. Platforms that offer modeling typically generate estimates only when they have enough activity volume to do so. Below certain thresholds, the platform produces no model at all, and coverage is uneven across segments, time periods, and properties. You can't easily tell when you're looking at real data and when you're looking at an estimate, and applying consistent analysis rules across your dataset becomes nearly impossible.
• Modeled data behaves differently depending on where you query it. If you export modeled event data to a warehouse and run the same analysis there, you often get different results than you do inside the analytics UI. Platforms typically apply this logic at query time in the UI, not at ingestion. This creates a split source of truth that is very difficult to reconcile, particularly for teams who rely on warehouse exports for reporting or compliance.

Amplitude's approach focuses on clear consent boundaries and accurate first-party data. It's better to know precisely what you measured and for whom than to fill gaps with estimates that are hard to validate or explain to auditors. If your organization uses Google services alongside Amplitude, you can configure Google Consent Mode for those tools independently. It doesn't affect how Amplitude processes data.

Privacy and Amplitude AI features

Final recommendation

If you want the safest and simplest default, start with Method 1: initialize Amplitude only after consent, keep your event schema tight, and add access controls and retention rules from day one.

If your policy allows more flexibility, you can still keep the setup privacy-friendly by reducing identifiers, using a proxy when needed, filtering bad traffic, and limiting access to sensitive data inside Amplitude.