What should a Shopify store log when a visitor changes their consent choice?
The consent change is the moment regulators care about most: a visitor said no after saying yes. Logging it properly means capturing the before, the after, and proof the site actually honored it.
The change is the highest-risk consent event
A first-time consent choice is a guess about the future. A changed choice is a correction, and corrections get scrutinized. When a visitor switches from accept to reject, every tracker that was firing must stop, every cookie set under the old choice must be dealt with, and the whole thing has to be provable later. Regulators and privacy auditors focus on changes precisely because this is where implementations most often fail quietly.
Most consent tools log the new choice and call it done. That is half the record. The useful log captures the transition: what the choice was, what it became, when it changed, and what the site did in response. Without the before-state, you cannot prove the after-state was honored.
What the log entry must contain
Each change record needs seven fields. The timestamp of the change, to the second. The previous choice, in full, not just a summary. The new choice, in full. The method of change: preference center, banner re-prompt, or a settings link. The page URL where the change happened. The consent tool and policy version in effect. And a session or visitor identifier that ties the record to the person without storing anything more personal than necessary.
The previous choice is the field everyone omits and auditors ask for first. "The visitor now rejects marketing cookies" is a statement. "The visitor accepted marketing cookies at 14:02 and rejected them at 14:47" is evidence. Keep both states or keep nothing.
Prove the site honored the change, not just recorded it
Logging the choice is step one. Step two is logging the enforcement. When consent narrows, the site should record that the relevant tags were blocked or removed and that previously set cookies in the revoked categories were deleted where possible. A change log that shows the choice but not the enforcement invites the obvious question: did anything actually change on the site?
This is worth testing directly. Change a consent choice in a test session and watch the network requests. The tags for revoked categories should stop firing on the next page load at the latest. If they keep firing, the log is documenting a choice the site ignored, which is worse than having no log at all.
Retention and access for change logs
Keep consent change records as long as you keep the underlying consent records, and apply the same access controls. These logs contain behavioral data about identifiable visitors, so they are personal data themselves in most frameworks. That means they need the same deletion handling as the rest of your consent data: when a visitor exercises deletion rights, the change log entries tied to them go too, subject to whatever legal retention obligations apply.
Make the records exportable. If a visitor asks what choices they made and when, or a regulator asks for proof of a specific change, the answer should be a query, not a project. Stores that can produce a change history in minutes look competent. Stores that need a week look like they are reconstructing it.
Design the preference center for changes, not just first choices
Most preference centers are designed around the first visit and treat changes as an afterthought. Flip that. The returning visitor who wants to change their choice should find the settings link easily, see their current choices stated plainly, and be able to change any category without resetting the rest. Every unnecessary step between intent and change is a place where the change does not happen.
Confirm the change visibly. A short confirmation that states what changed and when gives the visitor confidence and gives you a timestamped UI event to log. The best consent UX treats the change flow as the primary flow, because for your most privacy-conscious visitors, it is.
Frequently asked questions
What should a store log when a visitor changes their consent choice?
The new choice by category, the time, the banner and wording version shown, and how the change was made, settings page, banner, or withdrawal link. A change is a consent event with the same evidential weight as the original choice.
Why does the version shown matter for a change?
Because a choice is only meaningful against what the visitor was told at that moment. Categories and wording evolve, and the record must reconstruct what this change was actually agreeing or refusing.
How long should change records be kept?
Under the same retention policy as original consent records: at least while the choice is relied on, plus the period it could be questioned. A change record deleted early leaves the current state of consent unprovable.
Should a change take effect immediately?
Yes. Trackers in refused categories should stop from the change onward, and that behaviour should be tested. A settings page that saves a preference the tags ignore is a record of consent the site does not honour.