Consent and Cookie Preferences
Let users decide about optional tracking before the scripts load.
What it adds
A consent layer that blocks non-essential scripts and storage until the user allows them, and records the choice as proof.
What your agent is told to do
6
What your agent is told to do
6-
1
Inventory every script, pixel, embed, and cookie the app sets, and classify each as strictly necessary, functional, analytics, or marketing.
-
2
Block non-essential categories from loading at all until consent exists. Loading a tracker and then asking is not consent.
-
3
Store the choice with a version, timestamp, and how it was given, so a later policy change can re-prompt only the people it affects.
-
4
Give equal weight to accepting and rejecting, and provide a persistent way to reopen preferences and withdraw consent later.
-
5
Apply the same decision on the server: server-side event forwarding, log enrichment, and backend analytics must read the stored consent rather than assuming the browser handled it.
-
6
Do NOT gate the app behind the banner or make rejecting harder than accepting. A modal that traps the page or hides the reject option fails the regulation it was built for.
Edge cases it handles
7
Edge cases it handles
7- Region defaults cannot rest on IP geolocation alone — it is wrong often enough to matter. Combine signals and default to the stricter policy when unsure.
- Withdrawing consent must actively delete the cookies and local storage already set, not merely stop setting new ones.
- The consent record itself is personal data; keep it minimal and covered by the retention policy.
- Third-party embeds such as video players and maps set their own cookies — placeholder them until consent, rather than trusting them.
- A user with consent on one device has not consented on another; the choice is per-browser unless the user is signed in and you sync it.
- The banner must be keyboard-navigable and screen-reader-usable, and must not be the first focus trap a user hits.
- Bots and prerender requests should not create consent records or block essential rendering.
Definition of done
9
Definition of done
9- Every script and cookie is classified and non-essential ones do not load before consent.
- Accept and reject are equally prominent and equally easy.
- Consent is stored with version, timestamp, and source.
- Preferences can be reopened and withdrawn, and withdrawal clears already-set cookies and storage.
- Server-side tracking respects the stored consent.
- Regional defaults do not rely solely on IP geolocation.
- The consent UI is fully keyboard and screen-reader accessible.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Age Verification Gate
Age Verification Gate
Ask visitors to confirm their age before restricted content, and remember the answer.
What it does
An interstitial on age-restricted pages that records a confirmation and does not ask again on every visit.
How it works
- 1 Apply the gate only to the pages that genuinely need it. Gating an entire site, including its help and legal pages, drives away visitors who were never going to see the restricted content.
- 2 Store the decision the same way the app already stores Consent and Cookie Preferences, and put the age confirmation in that same preference record rather than inventing a second cookie with its own expiry rules.
- 3 Give a refusal a real destination: an explanation page, or the site the visitor most likely came from. A blank screen or an infinite redirect loop reads as a broken site, not a policy.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/age-verification-gate
Data Anonymization
Data Anonymization
Strip identity out of old records without wrecking your reporting.
What it does
An irreversible scrub of identifying fields across the schema that keeps rows, relationships, and aggregate counts intact.
How it works
- 1 Classify every column as identifying, quasi-identifying, or non-identifying. Free-text notes and file names carry identity too and are the ones teams forget.
- 2 Replace identifying values in place rather than deleting rows, so foreign keys stay valid and historical counts do not change.
- 3 Make the replacement irreversible: random or tokenized values with no stored mapping back to the original. If a lookup table exists, this is pseudonymization, not anonymization — call it that.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/data-anonymization
Personal Data Export
Personal Data Export
Give a user everything you hold about them, safely.
What it does
A subject-access-request flow that gathers one person's data from every table and file store, packages it, and delivers it to a verified requester.
How it works
- 1 Enumerate every place personal data lives for a single user — profile, content, comments, activity, sessions, billing, support messages, uploaded files — and assemble the export from that list, not from whatever a list view happens to show.
- 2 Verify identity before generating and again before releasing the file. Re-authenticate, and require the account's second factor if one is enabled.
- 3 Generate asynchronously and notify the user when it is ready. A complete export can take minutes and must not run in a web request.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/personal-data-export
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.