Consent

The checkbox on a signup screen was a formality for a long time. Terms of service, data collection, and marketing messages went into one bundle behind a single accept-all box, and pressing next was the end of it. The team that built the screen never expected it to be read, and the person pressing it didn't read it.

The formality turned into a problem later, every time. Six months after signing up, someone gets a promotional text, asks where the number came from, and hears that they agreed at signup. The record does show a checkbox, so the company isn't lying, and the user has no memory of permitting anything, so it feels like a trick. The box is there and the permission is not.

So consent got redefined as permission that meets conditions rather than as a stored checkbox state. There are two ways to establish the right to handle personal data: getting permission in advance, and being recognized as entitled without it. Consent is the first, and it carries conditions in exchange for being the one that applies almost everywhere.

It works in order: disclose before asking, separate the items so each can be answered on its own, and store the result of what was answered.

Four things have to hold for permission to count as consent.

1. Disclosure comes first. What is collected, what it is used for, and how long it is kept have to be readable on the screen where the answer is given. A link pointing at another page leaves the disclosure unmade.
2. Items are separated. Anything the service genuinely needs is asked separately from anything it doesn't. For a document tool, the email address is the first kind and job title and company size are the second.
3. Refusing has to leave the service usable. A signup button that stays dead until the marketing box is ticked doesn't produce freely given permission, so what gets stored can't support the processing later.
4. The answer is recorded — who agreed, when, and to which version of the wording. If the wording changes and the purpose grows, the earlier agreement doesn't stretch to cover the new one.

Defaults fall under the same rules. A pre-ticked box doesn't count, because it records the person who did nothing and the person who agreed in exactly the same state, leaving no way to tell them apart.

Withdrawal gets built with the same weight. If two clicks gave permission and taking it back requires emailing support, the asymmetry itself casts doubt on whether the original permission was free. This is why data minimization, collecting only what the purpose requires, is the fastest way to shrink a consent screen.

It attaches to two moments: the screen where personal data is first collected, and the point where data already held gets used for a new purpose. Five places account for most of the work.

1. The signup screen, where required and optional items are asked separately. Skip the separation and every later processing activity hangs on one basis.
2. Marketing sends, which need marketing consent collected on its own before promotional messages go out. Text, email, and push are separate channels, so permission in one place doesn't carry to another.
3. Web tracking, where cookie consent comes before analytics or advertising cookies are set. Cookies the service needs to function at all sit outside this.
4. Device tracking in apps, where App Tracking Transparency (ATT) — Apple's rule requiring permission before an app tracks a user — raises its own prompt.
5. Adding a new tool. One more analytics service means one more purpose, so the privacy policy text and the consent wording have to ship with the code. Shipping the code and leaving the document alone is the most common failure here.

Knowing where consent doesn't belong matters just as much. Route every processing activity through it and the signup screen turns into a field of checkboxes where one refusal stops the service. Handling card details to take a payment is needed to perform the contract, and that belongs on a different basis. Consent is one way to establish the right to process, not the default for all of them.

"Is this field required? Drop it to optional and we lose a consent screen."

Cut the item and the procedure around it disappears too.

"You can't sign up without the marketing box ticked — we're treating that as consent we never got."

The record exists but won't hold up as a basis.

"If the new analytics tool is live, the policy and the consent copy ship the same day."

Tie the document update to the deploy.

At Pagedeck the word came up during the sprint that added a new analytics tool. Grace pointed out that the policy document had to change with it, and Theo asked what happens to users who already signed up. Consent stands per purpose, so an old agreement can't cover a new one — existing users get asked once on their next visit, and Theo built a switch that drops accounts who refuse out of the event stream.

The signup screen got reworked in the same pass. Job title and company size moved from required to optional, and the marketing box shipped unticked. Signup completion went from 84 percent to 86 percent and marketing opt-in fell from 71 percent to 38 percent. Less than half as many emails go out now, and open rates doubled.

The most common belief is that consent, once collected, permits anything. Having asked feels like holding a pass. But consent only stands inside the purpose that was disclosed. Using a phone number collected for billing to promote a new feature is outside that purpose even with a signed record. Teams that hold this belief start writing consent copy as broadly as possible, and broad vague wording fails as disclosure, which knocks out the whole basis rather than widening it.

The other common belief is that consent is the safest basis. Since the user was asked, responsibility feels transferred. In practice it's the least stable one: whoever gave it can take it back, and processing stops that day. Build something the service depends on top of consent and every withdrawal removes a feature from that account, which is how teams end up moving the withdrawal button somewhere harder to find.