HARstack reads one HAR file at a time. The report you get is faithful to that file. It is not, on its own, an audit of your site. A site can look clean on the homepage and look like a serious exposure on the form submit. The same homepage with GPC on and GPC off can produce two different reports. The same checkout flow on mobile and desktop can fire different trackers.
This page is a guide to the kinds of captures worth running, what each one shows, and how to do it. Some are quick and obvious. A few are the captures that meaningfully change how you understand your stack.
This is the baseline. Open your homepage in a fresh browser session, capture, and audit. The report tells you what fires the moment a visitor arrives, before any interaction, before any consent decision, before any form. This is the tracking surface every visitor encounters, including the ones who leave after three seconds.
A homepage capture answers one question very well: what do we ship by default? Everything else in this guide is some variation of "and what happens when the user does X?"
Recommended browser: Firefox Private Window. Exports the most complete HAR file. Includes full response bodies, which enables HARstack's body-fingerprint scanner to catch trackers hiding behind first-party subdomains.
- Open Firefox Private Window with
Ctrl+Shift+Por⌘+Shift+P - Open DevTools with
F12and click the Network tab - Navigate to your homepage. Watch the Network panel fill
- Wait until network activity quiets down. Five to ten seconds after page load is usually enough
- Right-click anywhere in the Network panel and choose Save All As HAR
Do not log in. Do not click anything else first. The homepage capture is about the default state.
This is the capture that earns its name. A homepage capture shows the tracking that runs on arrival. A form-submit capture shows the tracking that runs at the moment a visitor hands over a name, email, phone number, or anything else. Those are two different exposures and they deserve two different audits.
When a user submits a contact form, a lead form, a newsletter sign-up, or any form that takes their information, your stack does things that are invisible on the homepage. It hashes their email and sends it server-side to ad platforms. It fires conversion pixels with their data attached. It may capture the field values themselves in a session-replay recording. None of this shows up if you only ever capture the homepage.
If you only run one capture beyond the homepage, run this one.
The key trick: keep DevTools recording across the submit. The HAR has to contain the POST request and any third-party requests fired as a result of the submit. If you stop recording too early, you capture only the page load and the audit will read like a homepage capture.
- Open Firefox Private Window. Open DevTools, Network tab
- Navigate to the page with the form
- Fill the form with realistic but disposable values. Use
[email protected]rather than something tied to an actual person - Verify DevTools is still recording — the red record dot should be on. Submit the form
- Wait for any thank-you or confirmation page to fully load. Wait another five to ten seconds. Most CAPI calls fire on a small delay
- Right-click the Network panel → Save All As HAR
If your form is part of a multi-step funnel, capture through to the step where the data is actually committed. Some funnels collect a name on step one but only POST the data after step three.
Sanitize concern. The HAR will contain the form values you typed. HARstack processes it locally in your browser. If you share the file with anyone, use the Export Sanitized HAR button in the report. That export strips request bodies, response bodies, cookie values, and credentials while keeping the URLs and field paths the audit was based on.
A checkout flow is a form-submit capture with stakes. The data fields are not just contact information; they include payment card numbers, billing addresses, transaction amounts, and sometimes account or routing information. The trackers that fire during checkout are often configured to capture purchase value and customer identifiers for ad attribution.
If your site has a payment flow, this capture is the most important audit you can run. The information involved is more sensitive than a lead form. Mistakes here are more expensive and the regulatory framing is heavier. Run this capture before you launch any new ad pixel, any new analytics SDK, any new third-party integration that touches the checkout page.
Same workflow as the form-submit capture, with extra care about test data and what happens after.
- Open Firefox Private. DevTools, Network tab
- Navigate through your funnel: product → cart → checkout
- If you have a test card or sandbox mode, use it. Do not put a real card in for an audit capture you might keep on disk or share. If you have to use a real card, plan to delete the HAR after running it through HARstack
- Complete the purchase or, if there is a final "place order" button, capture up to but not including it if your sandbox cannot process the transaction
- Wait for the confirmation page or post-purchase page to fully settle
- Export the HAR
If your checkout is hosted on a payment processor's domain (Stripe Checkout, Shopify Checkout, a separate subdomain you do not control), the HAR will only show what fires on the pages you load. The processor's domain is the processor's problem. But the pre-checkout and post-checkout pages on your domain are still yours.
If you process payments through embedded BaaS (Thread Bank, Bond, Marqeta, Unit), your stack is subject to GLBA. The trackers that fire on pages where account or payment information is entered are evaluated against the Safeguards Rule, not just the FTC Act. HARstack does not make this determination for you, but a finding involving a session-replay tool on a money-movement page is the finding that warrants the most urgent investigation.
What trackers fire on a page only your logged-in users see? Many sites apply consent and tracking rules to their public pages and then carry a different, looser configuration through to the authenticated experience. A dashboard, an account settings page, or a transaction history page may be carrying tracking it should not.
The other thing this capture surfaces: identity. Once a user is logged in, your stack knows who they are. If a tracker fires on an authenticated page, that tracker can now associate behavior with a specific person, not just a browser fingerprint. The privacy implication of session replay on a logged-out marketing page is different from session replay on a logged-in account page, even if it is the same tool with the same configuration.
identify calls that ship user IDs to ad platforms that did not have them before.
Use a test account. Not your own. The HAR will contain whatever session cookies and user IDs are associated with the account you used.
- Create or use a test account dedicated to audits. Note the account ID somewhere
- Open Firefox Private. Log in to the test account through your normal sign-in flow
- Once you are inside the app, open DevTools, Network tab. Reload the page so the Network panel captures the authenticated load from the start
- Navigate to whichever authenticated pages you most want audited: dashboard, account settings, transaction history, profile
- Export the HAR
Run this capture more than once for sites with multiple distinct authenticated surfaces. The trackers on an admin dashboard often differ from the trackers on a customer-facing account page.
Sanitize concern. The HAR will contain session cookies that belong to the test account. The Export Sanitized HAR button strips these before any sharing. Or delete the test session after the audit.
Global Privacy Control is a signal a visitor's browser sends that says, in effect, "do not sell or share my data." The right thing for a site to do when it receives this signal is to suppress the trackers that sell or share data. The wrong thing is to keep firing them anyway. The difference between right and wrong is enforceable under California law.
You cannot tell from a single capture whether your site is doing the right thing. You can only tell by capturing twice — once with GPC active, once without — and comparing what fires. If the GPC-on capture shows the same advertising trackers firing as the GPC-off capture, your site is not responding to the signal. That is a finding.
The same workflow tests something else worth knowing: pre-consent vs post-consent behavior. Capture the site before you click "Accept" on the consent banner. Then capture again after. If the two captures look the same, your consent banner is decorative. If they differ, the gating is real.
This capture tells you whether your stack responds to the signal. The consent-flip capture below tells you how it responds — whether the consent state was actually propagated to each ad platform, or whether the trackers fired with their default-granted state because nothing wired the signal through.
You need two captures, same page, same session shape, different signal posture.
- Capture A — GPC off. Open Firefox Private Window. Do not install a GPC extension. Navigate to the page. Export the HAR. Label it
page-gpc-off.har - Capture B — GPC on. Either use Brave (which ships GPC on by default), or open a fresh Firefox Private session with Privacy Badger or a dedicated GPC extension installed and verified active. Navigate to the same page. Export. Label it
page-gpc-on.har - Run both through HARstack separately. For the GPC-on capture, answer "Yes: GPC active" on Step 2. For the off capture, "No: no GPC signal"
- Compare the two reports side by side. The trackers that appear in both are the ones your stack is firing regardless of GPC
The same procedure tests the consent banner. Run one capture where you do not interact with the banner at all. Run a second where you accept everything. Compare. The trackers in the first capture are the ones that fire pre-consent, which should be a much shorter list than the second.
A practical note about Brave. Brave blocks more than just sale-and-sharing trackers; it also fingerprints requests and blocks third-party cookies. A Brave capture is informative, but it is a privacy floor, not a clean GPC test. For a strict GPC test, use Firefox with a GPC extension and Brave separately, then compare.
A real visitor does not land on your homepage and leave. They click around. They view two pages, three, sometimes more. They add to cart. They abandon. They come back. The captures so far in this guide are snapshots of single pages or single events. A cross-page session capture is the visit itself.
This capture surfaces cookie persistence and identity stitching. Some cookies are set on the homepage and never touched again. Some get re-read on every page. Some receive new values as the user navigates. Some trackers carry visitor identifiers from one page to the next, building a profile across the session that no single-page capture would reveal. If you want to understand what your stack actually learns about a visitor across a normal visit, this is the capture for that.
Keep DevTools recording across navigation. By default, Firefox and Chrome clear the Network panel on each page load. You need to disable that.
- Open Firefox Private. Open DevTools, Network tab
- In the Network panel, check the Persist Logs option (Firefox) or Preserve log option (Chrome). This tells DevTools to keep recording across page loads
- Navigate through a realistic visitor path. Homepage → category page → product page → add to cart → cart page. Or homepage → blog post → contact page → form submit
- Do not click around randomly. Pick a path that represents a real user journey for your site
- Once you reach the end of the path, export the HAR. It will now contain every request from every page in the session
HARstack reads the whole HAR. When the report runs against a multi-page HAR, the third-party domain table shows the union of every domain contacted across the session. The cookie summary reflects cookies set or modified at any point in the session. The total tracker count is the count of distinct trackers across the visit, not per page.
A surprising number of sites fire different tags on mobile. Some load mobile-specific app-install banners. Some ship lighter analytics on small viewports to keep page weight down. Some fire heavier ad-tracking on mobile because mobile traffic is more valuable to specific platforms. If most of your visitors are on phones and you only ever audit on desktop, you are auditing the wrong site.
This capture is also a fast way to detect mobile-only third-party SDKs or scripts you may not have known were running.
You do not need an actual phone. Browser DevTools include a device emulation mode that changes the viewport size, user agent, and other signals that determine how a site renders.
- Open Firefox Private. Open DevTools
- Click the responsive design mode icon (a small phone-tablet icon in the DevTools toolbar) or press
Ctrl+Shift+M - Select a mobile preset (iPhone, Pixel, Galaxy — any of them is fine for this purpose)
- Reload the page. Both the viewport and the user-agent string now look like a mobile device to your site
- Switch to the Network tab and capture as you would for any other capture type — homepage load, form submit, checkout, whichever you are comparing
- Export the HAR. Label it with the device preset you used
Caveat about native mobile apps. A HAR file captures browser traffic. It does not capture what a native iOS or Android app does. If your business has a real mobile app, the HAR audit covers the web side only. The app side requires separate tooling.
The five captures above tell you what fires. They do not tell you how each tracker thinks about the user's consent state at the moment of firing. Two different sites can produce identical tracker inventories and have completely different exposure profiles, depending on whether the trackers are receiving an accurate consent signal from your stack.
The consent-flip capture is three captures of the same page under three different consent states. Pre-consent, where the visitor has not yet interacted with your consent banner. Post-grant, where they clicked "Accept all." Post-denial, where they clicked "Reject all" (or where they sent GPC). The three captures, compared side by side, tell you whether the consent banner is actually wired to the trackers, and whether each tracker received the consent signal in the format it expects.
This is the capture HARstack's consent-signal findings explicitly point you toward. When the audit surfaces "Google Consent Mode v2 not wired," or "Meta Pixel fired with no Data Processing Options signal," or "Microsoft UET fired with consent granted despite GPC," the consent-flip capture is how you verify whether the finding is intermittent, persistent, or actually correct.
Three captures of the same page, in this order. The order matters because consent state persists in cookies and localStorage, and you want a clean slate before each capture.
- Capture A — pre-consent. Open Firefox Private Window. Open DevTools, Network tab. Navigate to the page. Do not interact with the consent banner at all. Wait for the page to settle, then export. Label it
page-preconsent.har - Capture B — post-grant. Close the Private Window. Open a fresh Private Window. Navigate to the same page. Click "Accept all" in the consent banner. Reload the page so you capture a full session under the granted state. Export. Label it
page-grant.har - Capture C — post-denial. Close the Private Window. Open a fresh Private Window. Navigate to the same page. Click "Reject all" or the equivalent denial action in the consent banner. Reload. Export. Label it
page-deny.har - Run all three through HARstack separately. For capture A, answer "No: no GPC signal" on Step 2 unless your browser also sends GPC. For B and C, answer according to whether GPC was active
- Compare the three reports. Look at the consent-signal findings on each: do the gcs values change between B and C? does the dpo parameter appear in C but not B? does Microsoft UET's gv change from 2 to 1? If yes, your consent state is wired correctly. If no, you have a propagation gap
This capture pairs with a CMP cookie inspection. Open DevTools, Application tab, Cookies pane. Find the consent cookie set by your CMP (Osano: osano_consentmanager, OneTrust: OptanonConsent, Cookiebot: CookieConsent, Termly: TERMLY_API_CACHE, CookieYes: cookieyes-consent). Compare the consent state recorded by the CMP against the consent signals appearing in the tracker requests. If the CMP cookie says marketing is denied but the tracker requests carry granted-state signals, the gap is at the CMP-to-tracker handoff. If the CMP cookie itself reflects the wrong state, the gap is at the GPC-to-CMP layer.
Server-side note. A consent-flip capture only tells you what the browser-side tracker requests carry. Your server-side conversion APIs (Meta CAPI from your backend, Google Enhanced Conversions via offline upload, Reddit CAPI) make their own consent decisions outside the browser. Those events are not in the HAR. Even a clean consent-flip capture leaves the server-side path unverified. The captures answer "is the browser signal wired correctly." They do not answer "is the backend ignoring the wire."
If you only run two of the three, run grant and deny. The pre-consent capture is informative when your consent banner is configured to block trackers entirely until interaction, but most banners do not work that way; pre-consent looks more like the grant capture than you might expect.
A finding warrants investigation. No findings does not mean compliant.
HARstack reads what your browser saw. It does not read your data processor agreements, your tag manager configurations, your server-side pipelines, your authenticated APIs, or your mobile apps. Every capture in this guide is a single window into your stack. The more captures you run, the more windows you have. None of them, individually, is the whole picture.
If a capture turns up something that looks like exposure, treat it as a starting point for an investigation. Confirm against your actual configuration. Check your contracts. Talk to your privacy counsel. The audit is the beginning of the conversation, not the end of it.
Ready to capture?
Open the HARstack audit tool. Walk through the wizard. Run your first audit in under five minutes.
Open the audit tool →