The consent record should carry the browser user agent
The requirementstatement
Every consent record must carry the device or browser user agent behind the submission.
- Severityseverity
- LowLOWBest practice. Worth fixing, rarely fatal on its own.
- When it bitesphase
- Gates approvalapprovalGet this wrong and the brand or campaign is refused at registration.
- What is checkedobject
- campaign.message_flow + privacy policy
- Where it liveslayer
- OperationalOPERATIONAL
- How Ekas settles itdetectability
- AI · formAI_FORM
- A semantic question about what you wrote: whether a description matches a use case, whether a name looks like a filed entity. Judged by a model against written criteria.
- What the fix involvesfailureClass
- Fix the fieldRETRY_FIELD
- A better value in the form fixes it. Ekas can rewrite it and re-check.
- Who requires itauthorities
- CTIAmytcrplus
- When it appliesapplicabilityText
- Applies when consent was collected by web form, checkout, account settings, third party, chat, social, email and QR code.
Why this rule existsrationale
When a consumer says they never filled in the form, the IP and timestamp establish that something was submitted and nothing more. The user agent is the one field on the record that speaks to how it was submitted — a real browser on a phone reads differently from a scripted post — and it is free to capture, since the header arrives with every request.
How to fix itremediation
Capture the User-Agent header alongside the IP address at submission and store it on the consent record. Done when a record shows the browser and device as well as the address it came from.
A compliant exampleexample
Each web opt-in stores user_agent: "Mozilla/5.0 (iPhone; CPU iPhone OS 18_2 like Mac OS X) …" beside the IP.
Notesnotes
Registration-side twin: we judge whether the programme describes storing the field, never whether the stored record exists.
Rules you will hit next
6 other rules read campaign.message_flow + privacy policy. Fixing one field to satisfy a single rule is how a resubmission trades one rejection for another, so read these before you change anything.
OPS-056Opt-out records must keep the words the consumer actually sentBlockingBLOCKINGOPS-085The programme must scrub deactivated numbers before sendingBlockingBLOCKINGOPS-210Telemarketing consent must retain the request, its purpose and the answerBlockingBLOCKINGOPS-236An IVR opt-in must log the prompt, the keypress, the time and the callBlockingBLOCKINGOPS-261Only the charity may use the numbers a charity collectsBlockingBLOCKINGOPS-199Consent records must capture all seven required fieldsHighHIGH
OPS-208 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.