Consent Change Record vs. comparing the two traces by eye
Reading a before and after export side by side and checking which URLs show up in both is the default way to eyeball a consent change. It reliably misses a tracker that still fires, just fewer times -- because "still appears in both" and "unchanged" are not the same question. This free tool counts occurrences instead.
What comparing two traces by eye involves
Reviewing a consent sequence by hand usually means opening both exports and scanning the after trace for each URL that appeared before: is it still there? Gone? Something new? That works well for a tracker that either fires cleanly in both states or disappears entirely -- both are visible as presence or absence.
It works less well the moment a request fires more than once in one or both traces, which real trackers do routinely -- a pixel loaded once per page section, a script polling on an interval. A URL present three times before consent and once after is still, by a presence check, "in both traces" -- so it reads as unchanged, even though two of its three firings actually stopped. The reverse hides the opposite problem just as easily: a tracker that fired once before and started firing repeatedly after.
| What matters | Comparing the traces by eye | This tool |
|---|---|---|
| A request that fires fewer times after consent, without disappearing entirely. | Reads as unchanged -- the URL is present on both sides, and nothing draws the eye to how many times. | Counts occurrences per request on each side and reports the surplus as removed. |
| A request that starts firing more often after consent. | Same blind spot in reverse -- presence alone cannot distinguish once from repeatedly. | Reports the extra occurrences as added, the same counting logic applied both ways. |
| A storage key that is genuinely new versus one that was already there. | Usually visible -- a short list of keys is easy to scan for an unfamiliar name. | Diffs storage keys the same way as requests, for consistency and a single exported record. |
| A source-linked record you can hand to someone else. | Whatever notes the reviewer happens to write down. | A downloadable report naming exactly which requests and storage keys changed, and by how much. |
Comparing the traces by eye is not wrong -- it is how anyone reviewing a consent sequence starts, and it is right about anything that is purely present or purely absent. What it is not well suited to is a duplicate count, which is exactly the case a script that fires on an interval or per page section produces.
Open Consent Change Record to compare your own two traces.
The same worked example a presence check would pass
Before a visitor rejects analytics consent, an endpoint fires three times. After, it fires once more -- still present, just not three times:
BEFORE AFTER GET cdn.example.test/app.js GET cdn.example.test/app.js POST analytics.example.test/collect POST analytics.example.test/collect POST analytics.example.test/collect storage: consent_state, _ga POST analytics.example.test/collect storage: consent_state
Scanning the after trace for analytics.example.test/collect finds it -- it is right there, exactly as it was before. A presence check confirms "still fires" and moves on. Run this tool's own comparator (compareTraces) against the same two traces and it reports 2 removed requests to that URL (three before, one after -- two firings actually stopped) alongside one storage key added (_ga), with the request that still fires once correctly listed as unchanged, not as evidence nothing changed. Every figure here is asserted directly against the comparator's own output, not estimated.
Common questions
Isn't comparing two DevTools exports by eye enough?
It catches a request or storage key that is entirely new, or one that vanishes completely -- both stand out because the URL is simply present or absent. It works less well the moment a tracker fires more than once, which trackers routinely do (a pixel loaded once per section, a script polling on an interval). A URL that appears three times before consent and once after still 'appears in both traces' to a presence check, so it reads as unchanged -- even though two of its three firings actually stopped.
How easy is it really to miss a reduced-but-not-removed tracker by eye?
In this tool's own worked example, an analytics endpoint fires three times before a visitor rejects analytics consent and once after. Scanning the after trace for that URL finds it -- it is right there, so a reviewer confirms 'yes, this still fires' or 'no, nothing changed here' without counting instances. The correct finding is neither: two of the three firings stopped and one did not, which only shows up if you count occurrences on each side rather than checking presence.
Does this tool replace reviewing the traces myself?
No, and it only diffs the two trace files you give it -- it does not capture traces, crawl a site, or determine whether what it found is compliant with any law. Reviewing what a consent sequence should do in the first place is still your job. This tool exists for the specific, mechanical part of that review most likely to go wrong under a presence-only read: counting occurrences of each request and storage key correctly on both sides.
Already checked how this compares to a full consent management platform? See Consent Change Record vs. Cookiebot.