Consent Across Devices: Why Your Phone Never Heard About Your Laptop's No
A user refuses tracking on their laptop, carefully, purpose by purpose. That evening they open the same site on their phone, logged into nothing, and the banner asks again, which feels like the site ignored them. It did not. It never knew. The refusal is a cookie, and cookies live and die inside one browser.
That gap between what users expect consent to be, a property of them, and what it mechanically is, a property of a browser profile, explains a steady share of complaints and a fair number of bad design decisions made trying to close it.
The tempting fixes, and their costs
Fingerprinting would close the gap, and it is off the table: identifying a device by its characteristics in order to honour a privacy refusal would collect exactly the kind of data the refusal was meant to stop, and regulators treat fingerprinting itself as a tracking technique needing consent. Probabilistic matching through IP addresses and accounts on other services has the same shape of problem at one remove.
What remains legitimate is the account. Where a user is logged in, consent can be a server side profile attribute: asked once, stored against the account, applied on any device at sign in, and exportable when the user asks what you hold. The seams show at the edges. Browsing before login uses the browser's local state, login merges the two, and the merge rule needs deciding in advance: does the account's older consent govern, or the device's newer one? Newer should win, and the record should show the merge happened.
Guest devices and shared screens
Shared and borrowed devices cut the other way. A consent stored in a browser persists for the next person using that profile, which is why a household tablet carries one family member's acceptances into another's session. Sites cannot fully solve that, but long lived consent on shared style devices, library and kiosk contexts especially, deserves shorter storage and a visible way to review the current choices, not a settings link buried in a footer.
The settings link matters more than the sync question for most sites. A user who can find their choices, read them in plain language, and change them on the device they are holding has a working consent system, even if the laptop at home still holds yesterday's answer until they next use it.
What to tell users, plainly
One sentence in the cookie notice does the work: your choices are saved on this device and browser, and if you use another, we will ask there too, unless you are signed in, in which case your account choices apply. That sentence converts a perceived betrayal into an explained behaviour, and it costs nothing.
For account based services, add the choices to the account settings alongside email preferences, with the same timestamps the compliance team keeps. Consent a user can see and edit is consent you can also prove, and the proof and the experience turn out to be the same feature built once.
Related reading
These earlier guides cover connected questions in more depth: When Consent Signals Disagree: Troubleshooting CMP, Tag Manager, and Vendor State, Consent Log Retention When You Change Vendors: Export First, Cancel Second, and Consent and Embedded Video: The Player That Phones Home Before Play.
Frequently asked questions
Why did a site ask for consent again on my phone?
Because consent is stored in the browser on each device, usually in a cookie or local storage. A choice made in your laptop browser is not visible to your phone browser unless you are signed into an account that syncs it.
Can sites sync consent without an account?
Not reliably or legitimately. The techniques that could identify the same person across devices without a login are themselves tracking techniques, which would need the very consent they are trying to carry.
Which consent wins when account and device disagree?
The most recent choice should govern, and the system should record the merge. If a user refuses on a device today, an older account level acceptance should not silently override that refusal.
Should consent choices appear in account settings?
Yes for logged in services. Showing the current choices, their date, and an edit path in account settings makes consent visible to the user and produces the record the service needs for its own compliance.