Privacy by Design and Default Questions

Direct answer

I would not treat the default as a pure growth call. First ask whether the law lets this sharing run on an opt-out default at all, then pick the default by what the sharing is, and only then run an experiment. Opt-out means data is shared unless the user switches it off. Opt-in means nothing is shared until the user turns it on.

Step 1: is opt-out even available? (counsel confirms)

• Under the EU GDPR (General Data Protection Regulation; its articles are the binding rules and its recitals are the explanatory preamble that shows how to read them), consent must be an affirmative act: recital 32 says "silence, pre-ticked boxes or inactivity should not therefore constitute consent". If the sharing needs consent, opt-out is not a lawful design there, however much conversion it saves.
• Article 25(2) also says that by default only data necessary for each specific purpose is processed.
• Some other regimes (certain US state laws) treat sale or sharing of data as opt-out with a visible "do not sell or share" control. So the answer can differ by market. I would state what each rule requires and let counsel decide the market list.

Step 2: choose the default by the nature of the sharing

If it fails most rows, the answer is opt-in, and the job becomes making opt-in convert: ask at the moment the user sees the benefit, state what is shared in one plain line, and offer a middle level (share aggregated data, or pseudonymized data where names are replaced by codes but it remains personal data).

Step 3: test it without gaming

Randomize by user into two arms, only in markets where both arms are lawful. Pre-register (write down and date before launch) the hypothesis, the primary metric, the run length and the stopping rule (the condition under which you stop), and do not peek and stop early. Peeking inflates false wins because every look is another chance for random noise to cross the 5% line. In a simulation of 1,000 experiments with no real difference, checking ten times and stopping at the first p below 0.05 declared a winner in about 19% of them instead of 5% (MEASURED, one simulation run).

• Both arms get equal-prominence choices and equally easy reversal. A hidden or hard-to-find toggle is a dark pattern (an interface design that steers people into a choice they did not clearly make): it inflates opt-out participation and produces a result that measures confusion.
• Primary metric: 90-day retention, because a default that wins on day-one sharing but loses users later is a loss.
• Counted separately: share rate, revocation within 30 days, privacy complaints and support contacts, and a short comprehension check ("what is shared?"). Participation that comes from not noticing is not engagement.
• Illustrative power calculation (computed in python). Alpha 0.05 is the accepted false-alarm rate and power 80% is the chance of catching a real lift. The normal approximation formula is n = (1.96 * sqrt(2 * pbar * (1 - pbar)) + 0.8416 * sqrt(p1(1-p1) + p2(1-p2)))^2 / (p1 - p2)^2, where 1.96 and 0.8416 are the normal-curve values for 5% two-sided significance and 80% power. With 40% baseline retention, a 2-point lift (p1 = 0.40, p2 = 0.42) needs about 9,490 users per arm, and a 3-point lift (p2 = 0.43) about 4,230 per arm. The 2-point test needs about 2.24 times the 3-point sample, which is (3/2) squared, because the difference is squared in the denominator; halving the detectable lift roughly quadruples the sample. Retention needs the 90-day wait, so the answer is not available at launch.

What would change my call

A regulator or counsel ruling the opt-out lawful and the data low-risk would let me ship opt-out with a prominent control. High revocation or complaint rates in the opt-out arm would flip me to opt-in even if retention looked flat. Product owns the experiment, legal decides the lawful arms, and a Security Architect reviews where the shared data goes.

Short answer. Keep the most identifying form the shortest and the least identifying form the longest: raw events 30 days, pseudonymized event-level data 13 months, aggregates 25 months, ML features 90 days rolling. Windows below are illustrative starting points; legal and the product's real analysis needs set the final numbers.

Key terms. Raw events carry direct identifiers (user id, device id, full IP). Pseudonymized means the identifier is replaced by a keyed hash (HMAC, a hash made with a secret key) so rows still join, yet the person is not named. It is still personal data. Aggregated means counts and averages with no per-person rows.

Retention schedule

Snapshots are the exception to the 90-day feature window: a snapshot freezes feature values for reproducing a model, so it holds per-user data for up to 180 days. Either build snapshots from pseudonymized rows with no direct identifiers, or accept that a deletion request does not reach an existing snapshot until it expires (at most 180 days), say so in the policy, and exclude deleted users when the next snapshot is built. A trained model is not edited either: retrain on the next scheduled cycle from data that already excludes the deleted user.

Why 13 and 25 months: 13 months lets a year-over-year comparison include one extra month; 25 months gives two full years of trend. If analysts can answer questions from aggregates, the event-level tiers can shrink.

One record traced. A user's page view is stored on 2026-01-05. The raw copy is dropped on 2026-02-04 (30 days). The pseudonymized copy lives until 2027-02-05 (13 months). Only its contribution to a daily count remains after that, kept until about 2028-02. If the user deletes their account on 2026-03-01, the raw copy is already gone, so the pseudonymized rows are deleted that day and their keyed id goes on the suppression list. Per-user features are recomputed without them within their 90-day window, and any snapshot that still holds them expires by 180 days from its creation.

Logs by type (forensic need versus minimization)

• Security and audit logs: 12 months. Forensics needs the long window to see slow intrusions.
• Application debug logs: 14 days, free text scrubbed of PII at ingestion.
• Access logs with IP: 30 days, then IP truncated.

Archival. Archiving personal data is still retention, so never "archive raw" to dodge a window. Only aggregates go to long-term cold storage.

Backups and replicas. Backups expire on their own rotation (for example 35 days). Replicas follow the primary. State in the policy that a restore must replay the deletion ledger (the append-only list of deletion requests, kept without readable personal data) before data is served again.

Verification

• Each expiry job writes a receipt: table, partitions dropped, row counts.
• A daily check asserts that the oldest event time in each tier is inside its window.
• A weekly test injects a synthetic user (a fake test person created for this check), deletes it, and queries every tier and backup index for it.
• Per-user deletions are checked against the suppression list so deleted users do not reappear from late events.

Trade-off. Shorter raw windows make incident debugging and model retraining harder. Keep a pseudonymized copy for that need rather than extending the raw window.

Direct answer

Start from the decisions the analytics must support, then collect only the events that inform them, and make every data design choice (what, how much, how long, who sees it) serve those questions. The balance between utility and privacy is not a single dial: most product questions are about groups of users, so aggregate, sample and strip identifiers early, and reserve user-level data for the few cases that need it and have consent.

Design steps

1. Question first: write the metric or decision for each event ("which onboarding step loses users?"). An event with no decision attached is not collected.
2. Define the schema as an allow-list: event name plus a small set of approved properties. No free-text fields, no full URLs with query strings, no raw email or IP address.
3. Identify users with a random, resettable ID (the user can reset it in settings, after which new events cannot be linked to the old ones) rather than an email or device serial. Coarsen where precision is not needed (country instead of city; app version, not full device fingerprint).
4. Sample where totals suffice: for high-volume events, record a fraction and scale up. Example: at 2,000,000 events per day, 1 percent sampling stores 20,000 events. If 1,200 of them are "completed onboarding" (6 percent), the estimate is 6 percent of 2,000,000 = 120,000 events, which is the same as multiplying the 1,200 by 100. The uncertainty is about plus or minus 0.3 percentage points at 95 percent confidence, plenty for a funnel rate, though very rare events need full capture.
5. Store in tiers: event-level data for a short window, then aggregates only. Restrict access to the raw tier to a small group, and give analysts the aggregate tables.
6. Honour consent and deletion: analytics that is not strictly necessary follows the user's consent choice, and a deletion request removes or detaches that user's ID from the event store.

Trade-offs and what is lost

Cohorts and funnels

A cohort is a group of users who share a trait or a start date, such as everyone who signed up in March. A funnel is the ordered steps users move through, such as install, sign up, first purchase, with the share lost at each step. Cohort and funnel reports usually reach analysts through BI (business intelligence) dashboards, and that analysis can run on pseudonymous IDs with consent where required. Build deletion into the pipeline: when a user deletes their account or withdraws consent, the ID is removed from event tables and from derived cohort tables on the next batch, and the schedule is documented. Report small cohorts carefully: a segment of two people can identify them, so suppress groups under a minimum size, for example 20 users (an illustrative threshold your team sets). With that threshold, a country table might show US 8,400 and Iceland 35, while Liechtenstein with 4 users is merged into "Other".

Ethical side

User research and telemetry should not surprise users. Ask "would a user be comfortable seeing this event list?" and publish a plain-language description of what is measured. Avoid measuring things only because they are easy, such as keystroke-level behaviour, or recording that a user searched for a medical condition when a count of searches would answer the question.

Pitfall

Collecting everything "for later" and then promising to anonymize. Raw events with a stable ID plus enough detail can often be tied back to a person, so minimizing at collection is stronger than cleaning afterwards.

Direct answer

I weigh it by asking how much recommendation quality each extra data item actually buys (the gain is called lift: the improvement in a chosen recommendation metric, such as the share of recommendations clicked, compared with a baseline version) and what exposure it adds, then pick the cheapest data that delivers most of the value. In many products the first-party signals (data the product itself collects directly from what the user does in it, as opposed to bought or third-party data) and the user's stated interests deliver most of the lift, and the sensitive, intrusive signals add little, but that is a hypothesis to test on your own data, not a rule. So the default design collects less and processes closer to the user, and extra data is requested only where the user sees a benefit and agrees.

A repeatable decision process

1. List candidate signals (purchase history, in-app clicks, location, contacts, third-party data, inferred traits).
2. Estimate value for each by an offline test (replaying saved data through the model without showing anything to users) or an A/B experiment (showing different versions to randomly split groups of live users): how much does the recommendation metric move when the signal is removed?
3. Estimate privacy and legal risk: sensitivity (health, finances, children, precise location are higher), surprise to the user, and storage duration. Legal review decides where law restricts a signal.
4. Estimate engineering effort for consent capture, deletion support and storage controls.
5. Decide in this order: signals with high value and low risk go in; high risk and low value are dropped; the middle is gated behind consent or an on-device design.

Design choices that keep value while collecting less

Collection strategy

Capture consent at the moment of benefit, store the preference where the recommendation service reads it, keep the data in the region and system where it is needed, and give the user a control to view, correct or delete. Enforce the choice in code, not only in the interface: the feature pipeline should drop signals for users who declined.

Worked example

A retail app tests three versions: (a) in-app clicks only, (b) clicks plus purchase history, (c) both plus precise location and contact data. Illustrative results on the metric "share of recommendations clicked": (a) 3.0%, (b) 3.6%, (c) 3.7%. Lift over (a) is +0.6 points for (b) and +0.7 points for (c), so (b) captures 0.6 / 0.7 = about 86% of (c)'s lift while using no location or contact data. The extra 0.1 point from (c) does not justify its exposure, so ship (b) by default and offer location as an opt-in for local offers. The decision is evidence-based and the sensitive data stays out unless it earns its place. (These figures are made up to show the method; real tests also report confidence intervals before anyone decides.)

What would change the call

A test showing a large lift from a sensitive signal, plus a clear user benefit and valid consent, can justify collecting it. A regulator's rule or a children's audience can rule it out regardless of lift.

Direct answer

Treat the request in two layers. First, delete the person's data everywhere it is stored as data: source tables, feature stores, training snapshots, caches and exports. Second, decide model by model whether the trained artifact still holds the person's information. Retraining is necessary only when it does, or when you cannot show that it does not. I would tell the user exactly what was deleted and what happens to models by a stated date, and the regulator only what a complaint or inquiry asks for, with counsel (the company's lawyers) deciding the legal position.

Step 1: Map what the person touched

A deletion ledger is a list of person IDs that every training job reads and excludes from its input. It stops the data coming back at the next run. Store the IDs hashed (run through a one-way scramble, with a secret key added so common IDs cannot be guessed) so the ledger itself does not become a list of people to leak; hashed IDs are still pseudonymous, which is acceptable for a list that exists only to enforce exclusion.

Pseudonymizing (swapping names for IDs while a key exists elsewhere) is not erasure: the data is still personal data. Only truly irreversible anonymization removes it, and that is hard to prove.

Step 2: When is retraining actually necessary?

Ask whether the model could reveal or reproduce this person's data.

• Low risk, no immediate retrain: a model trained on millions of rows with simple features (for example a gradient-boosted churn model, which combines many small decision trees and learns general patterns rather than storing rows) where one person has a negligible influence and the model outputs only a score. Exclude them via the ledger at the next scheduled retrain and record the date.
• High risk, retrain or retire promptly: a model that stores records (a nearest-neighbour lookup keeps the training records and returns the closest ones; an embedding index holds numeric fingerprints of text or items that can be mapped back to them), a fine-tuned language model that can regurgitate text, or a small model where the person is a large share of the data. Test with a membership-inference check (can an attacker tell whether a record was in the training set? Example: show the model 1,000 records it trained on and 1,000 it never saw, and let the attacker guess which is which. Guessing right 1,030 times out of 2,000 is 51.5%, close to the 50% of a coin flip, so no meaningful leakage; 90% would mean the model gives records away) and a probe for memorized strings. If the test cannot clear it, retrain without the person or roll back to a model trained before their data.
• Cost trade-off: a retrain costing days of compute can be batched into the normal cadence if risk is low. Machine-unlearning research methods (techniques that try to remove one person's influence from a trained model without retraining it) exist but are not settled enough to be your only defence.

Step 3: What to tell whom

• User: within one month of the request (Art. 12(3) sets one month, extendable by two further months for complex or numerous requests, with the person told of the extension and the reason within the first month): confirm deletion from systems, say that models will exclude them from the next training run by a date, and name any retained data with the legal reason (Art. 17(3) lists the exceptions to erasure, such as a legal obligation to keep invoices or the need to defend legal claims).
• Regulator: erasure requests are not themselves reported. If the user complains, show the record: ledger entry, model risk assessment, dates. Do not claim "the model forgot you" unless you tested it. Wording and any contested position go through counsel and the data protection officer (DPO, the person some organisations must appoint to advise on and monitor GDPR compliance).
• Recipients: tell processors (vendors that handle data on your behalf) and partners who received the data unless impossible or disproportionate effort (Art. 19).

Worked example

A support-ticket classifier is trained monthly on 2 million rows. A user asks for erasure on day 3. You delete their 14 tickets and features by day 5, add them to the ledger, and the day-30 training run excludes them. A membership check on the live model shows no leakage above chance, so you keep it until then and record that. If the same data had fine-tuned a model that quotes tickets, you retire it now.