Operations
Part of Landing page software operations: gates and rollback
Landing page consent record: what to demand before launch in England
Before a landing page goes live in England, demand one consent record per lead form: fields, tags, what fires before and after the choice, and a signature.
What to take away
- Demand one consent record per lead form, tied to one build.
- List every field, tag and script with its purpose and recipient.
- Show what fires before the visitor's choice and what fires after it.
- A banner screenshot is not evidence.
- No supplier has submitted such a record for the Unbounce release discussed here, so the example is a format, not an assessed record.
Which rules the record answers to
In England, consent for non-essential cookies and similar tags falls under the Privacy and Electronic Communications Regulations (PECR). The standard a valid consent must meet comes from the UK GDPR, and the ICO regulates both.
The ICO's detailed consent guidance is written for readers who need a deeper understanding to apply consent in practice. Settle the opt-in wording against it, and keep the wording and the record together.
The UK rules guide lists the wider obligations a pack must satisfy. The consent record covers one of them, for one form, and holds the launch until it passes.
Tie the record to one build
A consent record is only useful if it names the build it describes. Write down the page ID, controlled domain, proposed URL, owner and candidate checksum, so the consent evidence can be matched to the release that carries it.
Identity and version evidence
- Page ID and controlled domain
- Proposed URL and owner
- Offer entity and candidate checksum
- Versioned brief and form schema
- Tag inventory and rollback target
Without those records, approval cannot be matched to the release it authorises. Claims, testimonials and image rights need their own evidence, which the pre-release checks on claims set out separately.
Keep each kind of evidence in its own record. A failure in one then cannot hide behind a pass in another, and the release controller can see exactly which record holds the launch.
List every field and every tag
The record needs a field-level data map and an inventory of tags, scripts, storage and link decoration. Each row states a purpose, a recipient, a retention period and a deletion route.
| Record item | What to write | Evidence that counts |
|---|---|---|
| Field and purpose | The field name and why it is needed | The versioned form schema |
| Lawful basis | Consent, where consent is the basis | The wording shown to the visitor |
| Tags and scripts | The build's tag manager, consent platform, each event | The tag inventory for the candidate |
| Recipients | Who receives the data | The supplier list |
| Retention | How long, and how deletion happens | The written schedule |
| Owner | A named data lead | A signature and date |
The inventory names the tag manager and the consent platform the build actually uses, then lists Google Analytics 4 events, Meta Pixel fires and Hotjar recordings. One row per purpose is how landing page data protection gets mapped.
Rebuild the inventory whenever a tag is added or removed. A new script can send data that the earlier record never mentioned, so an old record cannot vouch for a changed build.
Show behaviour before and after the choice
A generic consent banner screenshot proves nothing. The record has to show, tag by tag, what happens before a visitor chooses and what happens after.
- Open the candidate URL and note every tag that fires before any choice is made.
- Make the visitor's choice on the banner.
- Note which tags fire after it, including Google Analytics 4, Meta Pixel and Hotjar.
- Store both lists against the candidate checksum.
Landing page tools are software as a service, so also check each supplier against the NCSC's lightweight approach to cloud security, which proposes minimum expectations for any cloud service.
A record that would pass
A compliant record for one Unbounce lead form might read:
Field: email. Purpose: send the requested guide. Lawful basis: consent. Blocked before consent: Google Analytics 4, Meta Pixel, Hotjar. Retention: 24 months. Owner: named data lead. Signed: 6 September 2026.
That is a format example, not a submitted record. Copy its order of fields into your own record and fill each one from the build.
A record fails when it lists tags without saying when they fire, names a consent platform without showing its configuration, or carries a signature that predates the build.
Sign the record or hold the launch
The pass criterion is narrow: the record shows which tags fire before consent and which fire after it. If it does not, the form stays on hold, whatever the rest of the pack says.
A named data lead signs the record. An editorial desk role without privacy credentials cannot. Who owns what shows where that owner sits next to the publisher and the incident owner.
Keep the record with the other evidence in the release checklist, and record the exception if a tag has to ship without it. The operations and delivery guide covers rollback if the form has to be withdrawn.
Common questions
Which law covers the tags on a landing page form?
PECR covers consent for non-essential cookies and similar tags, and the UK GDPR sets the standard that consent must meet. The ICO regulates both.
Is a consent banner enough on its own?
No. A generic banner screenshot proves nothing about what the page does. Behaviour before and after the visitor's choice needs its own evidence, recorded tag by tag against the candidate build that will go live.
Who signs the consent record?
A named data lead signs it, as in the example. A desk role without advertising, privacy or accessibility credentials cannot.
Can a small team write this record?
Yes. The work is record keeping rather than tooling. One frozen candidate and one accountable owner are enough to start.
