Consent, Privacy and What They Do to Your Data

Consent is usually treated as a banner problem. Somebody adds a notice, somebody else picks the wording, and the measurement team finds out afterwards that a share of their data has quietly changed shape. That sequence is backwards, and it is expensive.

Consent is a data architecture input. It determines what you are permitted to collect, from whom, for what stated purpose, and for how long. Those are the same variables that determine what your analytics can answer. Deciding them at the end, at the banner, means designing your measurement twice.

Consent changes the shape of your data, not just the volume

The naive assumption is that consent reduces your data proportionally, as if a random sample simply disappears. It does not work that way.

Refusal is not random. It correlates with device, browser, age, technical literacy and traffic source. The population that declines is systematically different from the population that accepts. So the data you retain is not a smaller version of the truth. It is a biased version of it, and the bias runs in a direction you cannot see from inside the data.

This matters most for exactly the questions operators care about. Channel comparisons break, because refusal rates differ by source. Cohort work breaks, because a returning user who declined on their second visit cannot be linked to their first. New versus returning splits drift. Funnel steps that sit behind a consent gate look worse than steps in front of it, for reasons that have nothing to do with the funnel.

The practical response is to measure your own consent outcomes as a first class metric, broken out by source, device and page. If you do not know your acceptance pattern, you cannot reason about any downstream number.

Collecting less versus modelling the gap

Once consent constrains collection, you have two honest paths and one dishonest one.

The first honest path is to collect less and say so. You restrict yourself to what consent permits, you accept that your absolute totals undercount, and you use the data for direction and comparison rather than for exact counting. Trends over a stable collection regime remain informative even when the level is wrong. This is the conservative option and it is a perfectly defensible one, particularly for a brand that would rather be certain about a smaller data set.

The second honest path is to model the gap. Where consent is absent, you use aggregate signals and statistical estimation to reconstruct totals rather than pretending the missing events did not happen. The important discipline is that modelled figures are labelled as modelled, everywhere they appear. A number that mixes observed and estimated conversions without saying so will eventually be used for a decision that needed observation.

The dishonest path is to route around the choice: collecting through mechanisms designed to persist regardless of the stated preference, or treating a technical capability as permission. This tends to be framed as a measurement optimisation. It is a compliance decision being made by people who do not own compliance, which is a bad way to make one.

There is also a legitimate middle layer worth understanding. Server side collection moves the point of collection from the browser to your own infrastructure. That changes reliability, and it changes who controls the payload. It does not change what you are permitted to collect. The consent state has to travel with the request and be respected there, otherwise you have simply moved a governance problem somewhere harder to audit.

India’s framework is a design input

India’s Digital Personal Data Protection Act reorganised how personal data is handled by anyone processing it here, and Indian ecommerce brands are squarely inside its scope. The point for this discussion is not the legal text. It is the mechanisms, because the mechanisms map directly onto system design.

The framework works through a small number of levers. Notice, meaning the person is told what is being collected and why before it happens. Purpose limitation, meaning data gathered for one stated reason is not silently reused for another. Consent as a basis for processing, given freely and specifically rather than bundled into a general acceptance. Withdrawal, meaning a person can revoke what they previously allowed and your systems must act on it. Rights of access, correction and erasure, meaning you must be able to find every copy of one person’s data on request. Obligations around retention and around any processor you share data with.

Read that list as engineering requirements and the design implications appear immediately. Withdrawal means consent state must be stored, versioned and readable by every collection path, not just the website. Erasure means you need a way to locate a person across analytics, your customer platform, your order system, your support tool and your warehouse. Purpose limitation means the tracking plan needs a purpose field per event, decided at design time. Retention means events need a defined lifespan rather than accumulating indefinitely because storage is cheap.

Also treat processors seriously. Every tool receiving your customer data is part of your obligation surface, including anything an agency introduced. Keep an inventory of what is collected, where it goes, on what basis, and for how long. Most brands cannot produce that document, and producing it is usually the moment they discover collection they had forgotten about.

Requirements in this area continue to develop through subordinate rules and enforcement practice. Treat everything above as a description of mechanisms rather than legal advice, and confirm your current obligations with your own counsel before you commit to a design.

The tradeoff you have to price

There is a genuine tension here and pretending otherwise helps nobody. More collection gives sharper measurement. More restraint gives lower risk and, increasingly, a better relationship with the customer. You cannot maximise both.

Price it explicitly. Ask what decisions actually require person level data, and you usually find fewer than expected. Budget allocation, creative performance and most merchandising questions can be answered with aggregated or modelled data. Personalisation, lifecycle messaging and service recovery genuinely need identity. Collect at the level each decision requires and no further.

The brands that handle this well do the same thing every time. They decide the purpose first, design collection to that purpose, make the notice honest and readable, and accept a slightly blurrier picture in exchange for a defensible one. That is not a compromise on measurement. It is what measurement looks like when the constraints are taken seriously at design time rather than discovered later.