Trackers that load before anyone consents

A visitor lands on a B2B SaaS marketing page, and before they have clicked anything, before a cookie banner has even rendered, an analytics script or an ad pixel has already set an identifier in the browser. No prompt, no toggle, nothing to click "accept" or "reject" on. The tracker just runs. For a small SaaS company selling into procurement teams that read privacy policies closely, that is not a minor technical detail. It is the kind of thing a prospect's security review turns up in five minutes, and it undercuts every claim on the trust page above it.

What we found

We ran a passive, public data scan across a sample of US B2B SaaS companies with 5 to 50 employees (population as of the 2026-09-04 monthly refresh, N = 1054). We looked at whether a site loads cookies or tracking identifiers before any consent mechanism is present, using only what a browser can see on a normal page load. Nothing was logged in, nothing was probed, and no company in the sample is named individually.

Across that sample, 49.9% of sites (n = 526) had trackers setting identifiers with no consent mechanism visible on arrival. That is not a fringe misconfiguration. It is close to half the population.

This is a passive, public-data, k-anonymised aggregate. It is not a penetration test or any form of offensive testing, and a single scan is a snapshot, not proof of ongoing non-compliance.

Picture this

Imagine a fifteen-person project management tool with a marketing site built on a common SaaS template. Someone added Google Analytics for traffic numbers and a retargeting pixel for a paid campaign months ago, copying a snippet from a blog post into the site header. Both scripts load on every page, for every visitor, the instant the page renders. There is no cookie banner, because nobody on the team ever circled back to add one once the ad campaign wrapped. Now a prospect's procurement team runs their own privacy check before signing a contract. They open dev tools, watch the network tab, and see two third-party requests firing before any consent choice was offered. That single observation goes into their vendor risk notes, next to questions about data handling that the sales team now has to answer defensively instead of confidently.

Where to start

If this sounds like your site, the fix is usually smaller than the finding suggests.

• Inventory what actually loads on page arrival. Open your own marketing site in a private browser window with dev tools open and watch the network tab before you click anything. Most teams are surprised by what fires automatically.
• Separate consent-required scripts from consent-free ones. Analytics and ad pixels almost always need consent first. A basic uptime monitor or a font loaded from your own server usually does not.
• Add a consent mechanism that actually gates the script, not just a banner sitting on top of a page that has already set the cookie. The order matters: block first, load after acceptance.
• Check whether the ad or retargeting pixel is still earning its keep. It is common to find a tracker from a campaign that ended a year ago, still running, with nobody left who remembers adding it.
• If you want a free, no-login look at how your own domain reads from the outside, including this kind of check, run it at https://orangestealth.com/check. It is the same free public checker behind this data, separate from our paid External Security Posture Assessment, which goes deeper and covers the rest of what a buyer's security review is likely to ask about.

None of this requires a legal team or a rewrite. It requires someone opening the network tab, which is usually the part that never happens because nobody owns it.