Cookie scan returns a different result on every run

Consent Pro
1

Hi, I am running Consent Pro on a client site and the cookie scan gives me a
different result almost every time. Nothing on the site changes in between.

The scan should be finding three providers: GA4, Google Ads and the LinkedIn
Insight Tag. Most runs find nothing at all, occasionally a run finds the two
Google Analytics cookies, and once it found all three providers.

All tracking on that site lives in Google Tag Manager. There are no tracking
scripts in the page itself, so GTM is the only place the scan could pick
anything up.

I cannot tell yet whether I set something up wrong or whether this is a bug.
Has anyone run into this?

Thanks

2

Hey @juicydisorder!

This is actually documented scanner behavior rather than a bug or a misconfiguration on your end. Here’s what’s going on.

The Consent Pro scanner doesn’t list Google Tag Manager itself as a tracker entry — it only detects trackers through the resources GTM loads. So if your downstream scripts (GA4, Google Ads, LinkedIn) don’t fire during the scan, they simply won’t be detected.

The scanner reliably picks up GTM scripts only when they’re triggered on:

  • All Pages, or
  • A Consent Pro custom event like consent-updated

If your GA4, Google Ads, or LinkedIn Insight Tag triggers are set to something more specific — scroll depth, button clicks, custom events — the scanner may miss them entirely or show inconsistent results. We’ve seen this confirmed in previous support cases.

To narrow this down, could you check your GTM container and let us know: :folded_hands:

  1. Are your GA4, Google Ads, and LinkedIn tags set to fire on All Pages or Consent Updated?
  2. Or are they using conditional or interaction-based triggers?

If they’re using custom triggers, the fix is to update them to use the Consent Updated trigger you set up during the Consent Pro GTM setup (covered in Steps 5 and 6 of the setup guide). That ensures they fire in a way the scanner can actually catch.

Also worth a quick check — in your GTM Consent Initialization tag, the “Wait for consent update” setting defaults to 1000ms. If your network is on the slower side, bumping that to 1500–2000ms can help.

Share your current trigger config and we can go from there. If everything looks correct and you’re still seeing inconsistencies, we can escalate for a deeper look. :flexed_biceps:

3

Thanks Finn, that is useful. Here is the trigger config.

Three tags fire on the Consent Updated custom event, and they are the only ones
that set cookies:

  • Google Tag (GA4), additional consent check: analytics_storage
  • LinkedIn Insight Tag 2.0, base tag, additional consent check: ad_storage
  • Conversion Linker, additional consent check: ad_storage

Everything else in the container is interaction based: seven GA4 event tags,
three Google Ads conversion tags and three LinkedIn conversion tags, on click,
scroll, element visibility and custom form events. None of those set any cookie
beyond what the three base tags above already set.

The Consent Pro Init tag is on Consent Initialization - All Pages, region
Global, all six storage types denied.

So all three providers I would expect the scan to find already sit on Consent
Updated. That is why I am stuck: the documented condition looks met.

I have also tested “Wait for consent update” at 500ms, 1000ms and 2000ms. No
difference, the scan right after the change to 2000ms returned zero trackers
again.

Happy to share the domain with you directly if that helps.