Why an allowlist exists
Privacy law is not one rule. Under a GDPR opt-in model, a pixel that fires before the visitor consents is a real violation. Under a US opt-out model, a business may legitimately run analytics and advertising by default and offer the visitor a way to opt out afterward. Pulse cannot guess which regime a given client operates under, so by default it flags every tracker that fires during the consent-denied or GPC pass.
The Always-Active Trackers allowlist is how you tell Pulse "this one is intentional." When a tracker is on the list, firing under denied consent is expected behavior for that client, not a finding. This keeps the compliance score honest for opt-out clients without silencing genuine leaks on opt-in clients.
Open the project setup page
Edit the Pulse project you want to configure and scroll to the panel headed Always-Active Trackers. It sits below the scan configuration and above the Notifications and Scan Schedule panels.
The allowlist is stored per project. Two sites under the same company can carry different accepted trackers, which matters when one brand runs opt-in for an EU audience and another runs opt-out for a US audience.
Select your accepted trackers
Under the Accepted trackers label you will find a grid of tracker chips. Click each tracker the client has deliberately set to "always active" in their consent banner. The available options are Google Analytics, Google Analytics (gtag), Google Ads, Meta Pixel, TikTok Pixel, LinkedIn Insight, Pinterest Tag, Reddit Pixel, Snapchat Pixel, Twitter Pixel, Microsoft UET, The Trade Desk, Floodlight, DoubleClick, Hotjar, FullStory, Microsoft Clarity, Quantcast, and Segment.
Only select trackers you can defend. Anything you leave unchecked is still scored the normal way, so a pixel the client did not intend to run always-on will still surface as a violation. Save the project to store your selections, and they apply to every future scan.
How it changes scoring
A selected tracker that fires during the consent-denied or GPC pass is reported as an accepted note rather than a critical violation. Critically, it does not deduct from the compliance score. The same tracker firing on a project where it is not allowlisted would lower the score and appear in the findings list as an issue to fix.
This is the whole point of the feature: it separates deliberate, documented business decisions from accidental leaks, so the Privacy Score reflects real risk instead of penalizing a compliant opt-out configuration.
The allowlist is per project, so a single company can run opt-in scoring on one brand and opt-out scoring on another. Keep a short note in the project description recording who approved the always-on behavior, so the decision is traceable later.
Only use this when the always-on behavior is a deliberate, documented client decision. Under GDPR opt-in, analytics firing without consent is a genuine compliance finding. Allowlisting it there hides a real violation rather than recording an accepted one.
Troubleshooting
A tracker I allowlisted still shows as a violation
Confirm the chip name matches the tracker Pulse detected. The allowlist matches on the detected tracker name, so a pixel reported under a name not in the grid will not be suppressed. Re-run the scan after saving, since the allowlist applies to future scans rather than retroactively rescoring an old run.
The score did not move after I changed the allowlist
Saving the allowlist does not rescore the most recent scan. Run a fresh scan so Pulse evaluates the new accepted-tracker set, then check the Privacy Score tile and findings list on the new run.