AD-TECH GLOSSARY
Eight terms that explain how the ad-tech industry makes every website heavier, slower, and more surveillant. Each definition is linked to the pillar article that quantifies what the term actually costs you.
Ad-tech
The collective system of servers, networks, exchanges, and scripts that serve advertisements and track user behavior across the modern web.
Ad-tech is not a single thing; it's an economy. On the advertiser side: DSPs that buy inventory in milliseconds via real-time bidding. On the publisher side: SSPs that auction ad slots on pages. Between them: ad exchanges that match buyers and sellers. Orthogonal to all of that: trackers, pixels, session replay scripts, and analytics SDKs collecting the data that feeds the whole system.
A single news-site homepage in 2026 typically loads 70–400 third-party requests from 40–120 distinct ad-tech hostnames. The total payload from ad-tech requests averages 1.5–4 MB per pageview — often larger than the content the user came to read. adbloat measures exactly what that overhead costs on your specific network setup.
Tracker
A third-party script or pixel loaded by a web page that records user behavior — clicks, scrolls, time on page, device info — and reports it to a collection server.
Trackers range from benign analytics (Google Analytics, Plausible) to aggressive surveillance SDKs (session replay, cross-site fingerprinters). The category includes any code running on a page that collects information about the visitor and transmits it to a destination other than the page owner's own server. The legal and ethical boundaries depend heavily on jurisdiction; GDPR and similar laws require consent for most tracker use but enforcement is inconsistent.
On a modern web page, trackers are often the largest source of network traffic. DNS-layer blockers (Pi-Hole, AdGuard Home) catch the well-known tracking domains. First-party trackers (scripts hosted on the same domain as the site content) evade DNS-layer blocking and require content-layer filtering via a browser extension like uBlock Origin.
Tracking pixel
A 1x1 transparent image embedded in a page or email that, when loaded, silently reports the view to a tracking server; the original surveillance primitive.
The tracking pixel is a 1990s artifact that refuses to die because it is the simplest possible tracker: any page or email that can display an image can ship a pixel. The image request URL includes a unique identifier plus query parameters describing the view (user ID, campaign, referrer). Loading the image = reporting the event. Blocking the image = preventing the report.
Facebook Pixel, TikTok Pixel, LinkedIn Insight Tag, and hundreds of lesser-known tracking-pixel products are all variants of the same underlying mechanism. Modern pixels are usually invisible 1x1 GIFs or sometimes JavaScript-initiated fetches to a tracking endpoint; the logical function is the same.
Session replay
A class of tracker that records every mouse move, click, keystroke, and scroll on a page and reconstructs a video-like playback of the session for later review.
Session replay is the most aggressive category of publisher-side tracking. FullStory, Hotjar, LogRocket, Microsoft Clarity, and Mouseflow all record full user sessions including form field contents (before submission), scroll patterns, and rage-clicks. The publisher then watches the sessions back to "understand user behavior" or feed product design decisions. Users almost never know it is happening.
Privacy implications are severe: session replay frequently captures keystrokes in form fields marked sensitive (passwords, SSNs, credit card numbers) because the redaction rules are opt-in at the publisher's SDK config. Academic studies from 2017 onward have repeatedly documented unintended PII capture. Blocking session replay at the tracker-SDK-domain level (via blocklists) is effective.
Third-party cookie
A cookie set by a domain different from the site being visited, used to identify a user across multiple websites for cross-site tracking.
When you visit example.com and an embedded script from tracker.net sets a cookie, the tracker.net cookie is third-party. The same cookie is sent every time any site that embeds tracker.net loads, allowing the tracker to build a cross-site profile tied to the persistent cookie value. Third-party cookies have been the foundation of programmatic ad targeting since the late 1990s.
Safari and Firefox block third-party cookies by default as of 2020. Chrome's deprecation has been delayed repeatedly and is now scheduled for 2026. Ad-tech has been preparing replacement identifiers since ~2018: Unified ID 2.0, Google's Privacy Sandbox FLoC/Topics API, server-side IDs via logged-in email hashes, and advanced fingerprinting. None of the replacements are strictly better for the user.
Demand-Side Platform (DSP)
The buy-side infrastructure that advertisers use to bid on and purchase ad inventory programmatically across multiple exchanges in real time.
A DSP is the advertiser's seat at the automated auction. The advertiser defines targeting (audience segments, creative, bid price, budget); the DSP then participates in millions of real-time auctions per second, bidding on specific impressions across many ad exchanges. The bid decision happens in ~100 milliseconds between the moment a user hits a publisher page and the moment an ad renders. Major DSPs: The Trade Desk, Google DV360, Amazon DSP, Adobe Advertising Cloud, MediaMath.
For users, DSPs are invisible infrastructure. The user-visible consequence is targeted advertising: the DSP's bid is informed by data about the specific visitor (demographics, browsing history, device fingerprint, segment membership), making highly personalized ads possible.
Supply-Side Platform (SSP)
The sell-side infrastructure that publishers use to manage and auction their ad inventory programmatically to the highest bidder.
If a DSP is the buyer's seat, the SSP is the seller's. A publisher integrates with one or more SSPs; when a user loads a page, the SSP calls out to ad exchanges soliciting bids for the ad slot(s). The winning bid serves its ad. Major SSPs: Google AdX (via Ad Manager), Magnite (the merger of Rubicon and Telaria), PubMatic, OpenX, Xandr.
From a performance perspective, SSPs are the origin of the "ad-tech tax" on page weight. Each SSP integration adds scripts, cookies, and outbound requests. Header bidding — a technique where publishers call multiple SSPs in parallel to maximize competition — multiplies the overhead further.
Ad exchange
A digital marketplace connecting DSPs (buyers) and SSPs (sellers) that matches ad buyers with publisher inventory via real-time bidding.
The ad exchange is where the auction happens. When a user loads a page, the publisher's SSP sends a bid request to one or more exchanges. The exchange fans out to the DSPs that serve the buyers targeting this user/context; each DSP returns a bid in ~100ms. The exchange ranks, picks the winner, returns the winning creative to the SSP, which returns it to the browser. Total elapsed time: under 300ms in most cases.
Major exchanges: Google AdX (the largest), OpenX, Xandr Monetize (formerly AppNexus), PubMatic, Index Exchange, Magnite. Most publishers run header bidding against 5–15 exchanges per pageview, which is why a single article page can trigger 200+ outbound requests just from the ad-tech side.
> MEASURE WHAT THIS COSTS ON YOUR NETWORK
ADBLOAT fires 46 real tracker endpoints and grades your defense against a naked-Chromium baseline. Composite A-F letter, bytes blocked, handshakes prevented, hours reclaimed per year.
> RUN ADBLOAT →