How to Manually Reproduce ObservePoint Privacy Results in a Browser

Overview

This guide will show you the correct way to manually reproduce the tests that ObservePoint audits perform on your site to check privacy compliance by using a clean test Chrome profile, the ObservePoint Debugger extension, and its built-in GPC simulation. By the end, you'll be able to line up what you see in a real browser against what an ObservePoint audit reports.

Before you start: delete all browsing data before each test

A normal, everyday Chrome profile is full of things that can make a page behave differently than it did for ObservePoint's crawler:

Cookies and login state from prior visits to the site
Ad blockers or privacy extensions that block trackers before the CMP even gets a chance to
A consent choice you already made on that domain months ago, silently persisting
Extensions that inject their own scripts into every page

Any one of these can make a tag look "suppressed" when it isn't, or vice versa. A dedicated test profile removes those variables so you're comparing like with like.

Note: Delete all browsing data before every single test, not just cookies. Cache, local storage, IndexedDB, and service workers can all quietly persist a CMP's earlier decision or a tag's earlier state even after cookies are cleared. So a "clean" run that only clears cookies can still be contaminated. Before each pass (Default, Accept-All, Reject-All, GPC), go to chrome://settings/clearBrowserData, select All time, and check cookies, cached files, and site data (not just the cookies box).

Skipping this step is the single easiest way to get a false negative: a tag that looks blocked simply because a prior run already let it set everything it needed.

Implementation

Step 1: Create a dedicated Chrome test profile

In Chrome, click your profile icon (top-right) → Add Chrome Profile
When prompted, select Stay signed out; you don't want this profile syncing history, extensions, or saved logins from your main profile.
Name it something obvious, e.g. OP-Test, Consent-Test, or Cookie Monster so you never confuse it with your daily browser and select Done.

Treat this profile as disposable. Clear cookies (or just delete and recreate the profile) between test runs so a prior visit's consent choice doesn't linger and quietly bias your next test.

Step 2: Install the ObservePoint Debugger extension

The ObservePoint Debugger is ObservePoint's free Chrome extension (it also works in Edge), the in-browser counterpart to what the audit platform does at scale. Unlike most extensions, it doesn't live in the toolbar; it opens as a panel inside Chrome DevTools. On whatever page you're viewing, it shows:

Every tag and pixel firing, with request-level detail (encoded and decoded)
Every cookie set in the browser, first- and third-party, with all attributes
WCAG accessibility issues (2.0/2.1/2.2, levels A/AA/AAA)
The effect of simulated GPC signals (more on this in Step 3)

Install it inside the new test profile (not your daily browser, so it doesn't affect your normal footprint):

Open the Chrome Web Store from inside your new Chrome test profile and install ObservePoint Debugger.
Navigate to a page that you will not be testing, we usually recommend google.com because it sets minimal cookies
Open DevTools (Mac: Cmd+Option+I; Windows: Ctrl+Shift+I or F12), then click the ObservePoint tab.
Note: The ObservePoint extension will only be visible in the dev tools if you have rendered a real web page. It won't work from a new tab where you haven't loaded a page or on the extensions menu.
One time only, Log in with your ObservePoint account credentials, or create a free login if you don't have one (this also gives you access to an automated ObservePoint account, but for this exercise you're using it purely as a local debugger).
Refresh the page and confirm tags start populating the list.
Now that your ObservePoint Debugger is installed and open, go to a simple page like google.com, clear all site data and permissions one more time, and then navigate to the page you wish to manually test.

If you followed all of these steps correctly, now you can explicitly opt out or opt in and you should be able to reproduce exactly what ObservePoint is doing in one of it's audits.

Step 3 (optional): Simulate GPC directly in the Debugger

Global Privacy Control is a browser-level opt-out signal, and it's asserted before the user ever touches the consent banner, which is what makes it a different test than clicking "Reject All."

The ObservePoint Debugger has GPC simulation built in, so you can validate tag and cookie behavior with GPC enabled directly inside the same panel you're already using.

How to use it:

In the ObservePoint tab in DevTools, enable the GPC simulation option;
Reload the page with the simulation active and without interacting with the consent banner;
Watch the tag and cookie lists the same way you would for any other pass. If you want to double-check the signal itself is present (not just trust the toggle), a public GPC-detection page will confirm navigator.globalPrivacyControl and the Sec-GPC header are set.
Keep this as its own run, separate from your Default and Reject-All passes. Don't mix a GPC signal into a run where you're also clicking Reject All, or you won't know which mechanism is doing the work.

Step 4: Run the comparison against the Audit

With the profile ready, reproduce each consent state ObservePoint tested, one at a time, clearing cookies between passes:

State	What to do in the test profile	What it proves
Default	Load the page fresh, don't interact with the banner	Nothing non-essential should fire before consent
Accept-All	Click *Accept All* in the banner	Full set of tags the site is capable of firing
Reject-All	Click *Reject All* in the banner	The banner's own opt-out reaches the tags
GPC (optional)	Enable GPC simulation in the ObservePoint Debugger, then load the page with no banner interaction	The browser-level signal is honored independently of the banner

For each state, use the ObservePoint Debugger to note what actually fired and what cookies were set, then line that up against the corresponding ObservePoint Audit's Tag Inventory and Cookie Privacy Report.

What you're looking for:

A tag that appears in your Reject-All (or GPC) pass but shouldn't be there is the same leak compare_consent_states would show you between the Audit runs, just confirmed live.
When a tag fires identically no matter what state you're in, it means it's consent-blind, ignoring the signal entirely.
A mismatch between your manual pass and the Audit itself is worth a second look, since it can point to something environment-specific (geo-IP, a session cookie ObservePoint's crawler never had, a bot-detection rule treating the synthetic browser differently than a real one).

Good to know

Even a clean profile or Incognito window is a real browser on a real IP, not ObservePoint's synthetic browser - expect close, not identical, results.
Corporate VPNs can affect results. They often filter tags/cookies before the page ever sees them, making something look "blocked" when it's the VPN, not the site and it's not representative of a normal visitor anyway. Test without one active if you can.
Match the Audit's location. Consent behavior is often geography-driven. Check where your Audit runs from and test from the same region, or you may get a different (still valid) result.
If tags route through server-side GTM, this only confirms what left the browser. Pair with server-side logs for the rest.
This manual process is for explaining and confirming a finding, not for producing your compliance evidence. The Audit run, the Rule pass/fail, and the Cookie/Request Privacy Reports remain the system of record.

Conclusion

A clean test profile, the ObservePoint Debugger extension, and (when relevant) a GPC signal give you a fast, credible way to put an Audit finding in front of a real browser and watch it happen. That's often what turns a report line item into something engineering or legal will actually act on.

It doesn't replace the Audit (the Audit run and its Privacy Reports stay your system of record), but as a sanity check and a persuasion tool, reproducing the result by hand is hard to beat. Once you've confirmed a finding this way, the next step is usually feeding it back into the corresponding Rule or Audit configuration so it's caught automatically going forward, rather than relying on manual spot-checks each time.