What it is
Amplitude analyses behaviour over time (retention, cohorts, funnels) against a device ID and, once identified, a user ID. Its footprint on a public marketing page is small; its footprint inside a product is substantial by design.
What a scan matches
A verification scan drives a real browser and records the outbound requests observed during its configured journeys, so Amplitude is identified by request hosts and paths rather than by source-code claims. Requests on unvisited paths, after unperformed interactions or solely on the server remain outside that observation.
- amplitude.com
Cookies are classified by name before domain because many analytics and advertising tags write first-party cookies through the page, which places a vendor-related identifier on your domain. Matching known names helps attribute those values without assuming that every first-party cookie came from your own application.
| Cookie | What it is for |
|---|---|
| amp_* | Amplitude device and session identifiers, matched by prefix |
| amplitude* | Related Amplitude state |
Controlling it with consent
No named adapter. Gate it as a custom script attached to analytics.
Amplitude’s SDKs support opt-out and identifier reset. If you use them, make sure the reset is wired to a consent withdrawal rather than left as a manual step.
No named adapter: choose the appropriate control
The product ships named adapters for Google Tag Manager, Google Analytics, the Meta and TikTok pixels, and Klaviyo. Choose the control route that fits this technology: a custom HTTPS script declaration for a browser loader, an individual consent condition inside a tag manager, a platform or app setting, or a click-to-load placeholder for a frame. Server-side integrations need their own enforcement because a browser runtime cannot stop them.
What breaks if it is refused: behavioural cohorts for refusing visitors.
Verifying it
Before consent there should be no request to amplitude.com and no amp_ cookie. After withdrawal, confirm the SDK has actually stopped rather than just stopped reporting.
- Before a choice: optional tracking endpoints and optional identifiers are absent; any intentionally loaded necessary or functional surface matches the control model described above
- After rejecting optional categories: optional activity remains absent and the refusal persists across a reload
- After granting the relevant category: the expected loader or embed appears and the feature behaves normally
- After withdrawing: new optional activity stops; where the vendor supports a consent signal, verify that the signal is sent as well as checking network behavior
Common questions
Should analytics and product analytics share a category?
They can, and most sites keep one analytics category. Splitting them only helps if a visitor could meaningfully want one and not the other, which is rare on a public site and occasionally true inside a product.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- Amplitude: Browser SDK cookies and consent management
Vendor documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.