Tracking beacons are the analytics and marketing scripts embedded in web pages. Learn what they are, who sets them, and why auditing them matters.
Almost every commercial website embeds third-party scripts that report back to analytics, advertising, and personalization vendors: page views, clicks, conversions, session replays, heatmaps, chat widgets, consent state. These embedded trackers — snippets, pixels, tags, beacons — are what the audit scans for.
A vendor tracker belongs to one company and does one job: Google Analytics 4 measures traffic, the Meta Pixel feeds ad targeting, Hotjar records sessions. A container like Google Tag Manager is a loader: one script on the page that can inject dozens of vendor tags at runtime, configured from a web dashboard without touching site code. Containers are why a page can carry twenty trackers while its HTML shows only one. How the audit handles GTM.
First-party trackers are served from the site's own domain; third-party trackers phone home to the vendor's domain. The distinction matters for privacy regulation and for browser blocking (Safari's Intelligent Tracking Prevention and ad blockers mostly target third-party). The audit's beacon table shows the vendor and how each tracker loads, so you can see the mix.
The audit pattern-matches page HTML against 40+ tracker signatures and extracts identifiers (container IDs, measurement IDs, pixel IDs). The default scan reads static HTML; browser-render mode executes the page's JavaScript to catch trackers injected at runtime — which is most of them when a tag manager is involved. Why static scans miss trackers.