Blog The developer's guide to consent and privacy

The developer's guide to consent and privacy

2 min read

The developer's guide to consent and privacy
TL;DR Real consent means non-essential scripts do not run until the user opts in, not a banner that tracks anyway. Collect the least data you can, default to privacy, and tell people plainly what you gather and why. The engineering is mostly gating scripts on consent and keeping data minimal.

Privacy law can feel like a legal thicket, but the developer's part is fairly concrete. Most of it comes down to a few engineering habits: gate non-essential scripts behind real consent, collect as little as you can, and be honest about it. Here is the practical version.

Real consent means blocking, then loading

The core rule, and the one most sites get wrong, is timing. Non-essential scripts, analytics, ad tags, trackers, must not run until the user agrees. A banner that appears while the trackers are already loading is theatre: the tracking happened before the choice.

So the pattern is: block the non-essential scripts by default, and only load them once the user opts in. Consent mode approaches, where analytics runs in a limited, cookieless state until consent, are one way to do this cleanly. Whatever the mechanism, the principle is block first, load on consent.

Necessary versus non-essential

You do not need consent for everything. Strictly necessary cookies, the ones a site needs to function at all, are exempt. Consent is for the non-essential set: analytics, advertising, tracking. Your job is to draw that line correctly and gate only the non-essential side behind the opt-in.

Collect less

The most underrated privacy technique is simply gathering less data. Data you never collect cannot leak in a breach, cannot be misused, and does not need protecting. Before adding a field, a tracker, or a log that captures personal data, ask whether you actually need it. Usually the answer is no.

  • Default to privacy. The safe state should be the one that collects and shares the least.
  • Minimise fields. Ask only for what the feature genuinely requires.
  • Do not log what you do not need. Personal data in logs is data you now have to guard.

Be honest

The last piece is plain honesty. Tell people what you collect and why, in language they can understand, not a wall of legalese. A clear, short privacy explanation builds more trust than an exhaustive one nobody reads, and it keeps you disciplined about only collecting what you can actually justify.

The short version

Block non-essential scripts until the user opts in. Draw the line between necessary and non-essential correctly. Collect the minimum, default to privacy, and say plainly what you do. That is most of the developer's job on consent and privacy, and it is more about restraint than machinery.

FAQ

What counts as real cookie consent?

The non-essential cookies and scripts, analytics, ads, tracking, do not run until the user actively agrees. A banner that sets a flag but loads the trackers on the first visit is not consent; the tracking already happened before the user chose.

Do I need consent for all cookies?

No. Strictly necessary cookies, the ones a site needs to function, do not require consent. Consent is for non-essential ones: analytics, advertising, and tracking. The distinction is what you gate behind the opt-in.

What is the simplest way to stay on the right side of privacy?

Collect less. Data you never gather cannot leak, be misused, or need protecting. Default to privacy, gate non-essential scripts behind consent, and be honest in plain language about what you collect and why.