Auditing Your Website Tracking Stack: A Practical Guide

Summary. Find out what your site actually sends, to whom, and whether consent controls it.

Do not start with a list

The most common way a tracking audit fails is that counsel asks marketing for a list of tags and receives one. The list is always incomplete, for structural reasons:

• Tags get hard-coded into page templates and never enter the tag manager.
• Third-party widgets — chat, video players, review platforms, maps, fonts — load their own tags.
• Tags load other tags. A single container can chain to a dozen destinations.
• Agencies and contractors add tags and leave.
• Vendors change what their tag transmits without notice.
• Mobile apps have SDKs that nobody maps against the web inventory.

The audit begins with watching the site, not with asking about it.

PART ONE: CAPTURE

Step 1 — Capture live network traffic

Have an engineer load the site with browser developer tools recording all network requests, and export the results.

Capture across configurations, because behavior differs:

Capture across page types, not just the home page:

• Home and marketing pages
• Search and category pages
• Product or content detail pages
• Any page whose URL reveals a sensitive attribute — a condition, a financial product, a legal issue
• Forms: contact, application, scheduling, checkout
• Authentication pages
• Account and portal pages
• Pages with embedded video
• Pages with a chat widget
• Confirmation and success pages, where conversion tags fire

Step 2 — Reconcile against the tag manager

Export the tag manager configuration and compare it to what the capture shows.

Expect a mismatch. Document it. The delta — tags firing that are not in the manager — is where the unreviewed exposure lives, and identifying its source is part of the audit.

Also check: tags in the manager that no longer fire (dead configuration to clean up), and tags that fire on more pages than their trigger suggests.

Step 3 — Map what is transmitted, field by field

For each destination, record what actually goes out. This is the step that produces the legal analysis, and summarizing it as "analytics data" defeats the purpose.

For each request, capture:

• The destination domain and the vendor behind it
• The full URL, including query parameters
• The page URL transmitted as a referrer or parameter — this is how sensitive-page exposure happens
• Cookie and identifier values
• Custom event names and parameters
• POST body contents
• Whether any form field values appear
• Whether any keystrokes are captured

Flag immediately:

• Any page URL revealing a health condition, financial product, legal matter, or other sensitive attribute
• Any custom parameter carrying a user-supplied value
• Any email address, phone number, or hashed identifier derived from them
• Any keystroke capture in a form field
• Any chat message content
• Any video title or content identifier paired with a persistent identifier

PART TWO: ANALYZE

Step 4 — Sort by legal theory

Group findings by the analysis they trigger.

Contents of communications. Session replay keystrokes, chat message bodies, and form field values transmitted before submission. These are the strongest facts for two-party consent claims under statutes descending from 18 U.S.C. § 2511 and their state analogues, because they are unmistakably the contents of a communication.

Video viewing paired with identifiers. Any transmission of what a visitor watched, together with something that identifies them, is the 18 U.S.C. § 2710 pattern. Liquidated damages of $2,500 per violation make this disproportionately valuable to plaintiffs.

Sensitive-context URLs. Page addresses revealing health, financial, or similarly sensitive attributes transmitted to third parties. This is the enforcement exposure and, where a health provider is involved, a separate regulatory violation.

Children's data. Persistent identifiers collected from users under thirteen implicate 15 U.S.C. § 6501 and 16 C.F.R. Part 312.

Financial data. Nonpublic personal information disclosed by a financial institution implicates 15 U.S.C. § 6801 and 15 U.S.C. § 6802.

Everything else. Ordinary analytics and advertising identifiers, which carry the sale and targeted-advertising obligations of state privacy statutes and the accuracy obligation of 15 U.S.C. § 45.

Step 5 — Verify consent gating actually works

This is the single most important test in the audit, and it is the one most often skipped.

The procedure: load the site with traffic capture recording, decline all optional categories in the consent banner, and continue browsing. Then examine what fired.

What you are looking for:

• Tags that fire before any choice is made
• Tags that fire after declining
• Tags in a category the user rejected
• Tags that fire on a second page load after a decline
• Tags whose consent category is misassigned — an advertising pixel classified as "necessary"

A banner that does not gate is worse than no banner. It establishes that the operator represented it was honoring choices and did not, which converts a contested wiretap claim into a straightforward deception claim.

Also verify universal opt-out signal handling where a relevant jurisdiction requires it. Transmit the signal and confirm the site's behavior changes.

Step 6 — Review the vendor contracts

For each destination, pull the agreement and answer one question above all others:

May the vendor use the data for its own purposes?

This drives the party-versus-eavesdropper analysis that decides two-party consent claims. A vendor restricted to processing on the operator's behalf is arguably an extension of the operator; a vendor permitted to build cross-site profiles and improve its own products is arguably a third party listening in.

Also confirm:

Where the contract is silent or permissive, either renegotiate or remove the tag. A vendor that will not accept purpose limitation is telling you how it will be characterized in litigation.

Step 7 — Check the disclosures against reality

Read the privacy policy as a regulator would, next to the audit findings.

• Does the policy describe the categories actually collected?
• Does it name the categories of third parties actually receiving data?
• Does it accurately describe what triggers collection?
• Does it claim anything the site does not do — "we do not share with advertisers," "we do not track across sites"?
• Do state-specific disclosures match actual practice, including sale and targeted advertising categorization?
• Does the cookie notice list the tags actually present?

Accuracy is the most controllable variable in this entire area. Deception claims are the easiest for plaintiffs to prove, the easiest for regulators to bring, and the easiest for an operator to prevent.

PART THREE: REMEDIATE

Step 8 — Fix in priority order

Priority 1 — Stop collection on sensitive pages. Remove third-party advertising and analytics tags from health, financial account, children's, and authentication pages. Do this first; it takes hours and eliminates the highest-value claims.

Priority 2 — Make consent gating work. Fix the configuration so declining actually blocks. Re-test.

Priority 3 — Session replay and chat. Remove session replay from any page with form fields. Renegotiate or replace chat vendors whose contracts permit independent use.

Priority 4 — Video. Either stop transmitting viewing events with identifiers, or obtain consent in the specific form 18 U.S.C. § 2710 requires: separate, distinct, written, and revocable. A privacy policy does not qualify.

Priority 5 — Correct the policy. Describe what actually happens now.

Priority 6 — Vendor contracts. Renegotiate purpose limitation across the stack.

Priority 7 — Custom parameters. Audit every custom event for user-supplied values leaking into transmissions.

Priority 8 — Governance. Approval before deployment, technical enforcement, and quarterly verification.

Step 9 — Document everything

Produce a dated audit report: what was captured, when, in what configurations; what was found; what the legal assessment was; what was remediated and when; and what was accepted as residual risk and why.

This document is privileged work product if structured properly, and it is the most useful thing you will have if a regulator asks. Discuss with counsel whether it should be prepared at counsel's direction.

A worked audit

Larkspur Financial operates a consumer lending marketplace: users compare loan products, check rates, and submit applications. Roughly 2.4 million monthly visitors.

Its privacy counsel, Adaeze Lindqvist-Moreau, runs the audit after a peer company receives a demand letter.

Week one: the capture, and the first surprise

An engineer captures traffic across the matrix: three consent states, three browsers, desktop and mobile, two geographies, logged in and out. Thirty-six captures across eleven page types.

The tag manager lists nine tags. The capture shows twenty-three destinations.

The delta breaks down as: four tags loaded by other tags (a single advertising container chaining to affiliate networks); three hard-coded into page templates by a contractor two years ago; two loaded by an embedded chat widget; two loaded by a third-party rate-comparison component; and three that the tag manager does list but that fire on far more pages than their configured triggers suggest.

Adaeze's note to the file: "The list we would have gotten by asking was 39% complete."

Week two: the field mapping, and the second surprise

Mapping what each destination receives produces three findings that reorder the entire project.

Finding one: the rate-check URL is the problem. When a user checks rates, the URL becomes /rates/personal-loan?credit=fair&amount=15000&purpose=debt-consolidation. That URL is transmitted as a referrer to eleven of the twenty-three destinations. It discloses that an identified visitor has fair credit and is consolidating debt — nonpublic personal information under 15 U.S.C. § 6802, disclosed to advertising networks.

Finding two: the application form leaks before submission. The session replay tool captures keystrokes in all fields. The capture shows income figures and partial identifiers transmitted as the user types, before any submission. This is the contents of a communication, in the most literal sense the wiretap statutes contemplate.

Finding three: an email hash is going out. A custom parameter on the account creation confirmation transmits a hashed email address to two advertising destinations. Nobody in marketing knew this was configured; it came with a vendor's "enhanced matching" feature that was enabled by default.

Week two, day four: consent gating

The engineer loads the site, declines everything, and browses.

Nineteen of twenty-three destinations still fire.

The consent platform is configured, the banner appears, and the categories are defined — but the tags loaded by other tags and the hard-coded ones were never wired into it. The four that are correctly gated are the four the platform was originally deployed to manage.

Adaeze's assessment: this is the worst fact in the file. Larkspur's banner tells users their choices are honored. They are not. That converts a contested wiretap claim into a straightforward deception claim under 15 U.S.C. § 45 and state analogues, and it undermines every consent-based defense.

Weeks three and four: vendor contracts

Twenty-three destinations; nineteen contracts located; four vendors nobody can identify a contract for.

Of the nineteen:

• Six restrict the vendor to processing on Larkspur's behalf. Good.
• Nine permit the vendor to use data to "improve its services," which in practice means cross-customer modeling. These are the eavesdropper-characterization problem.
• Four expressly permit the vendor to use the data for its own advertising products. These are indefensible in a two-party consent state.
• The four with no contract are the affiliate networks in the advertising chain. Larkspur has no relationship with them at all; its advertising vendor does.

The remediation, in order

Day one. Remove all advertising and analytics tags from the rate-check pages, the application flow, and the account pages. Traffic on those pages now goes to a first-party endpoint only.

Day two. Change the rate-check URL structure so parameters move to a POST body rather than a query string. This eliminates the disclosure mechanism entirely rather than trying to control who receives it.

Day three. Disable the vendor's "enhanced matching" feature transmitting hashed emails.

Week one. Remove session replay from the application flow.

Week two. Rewire the consent platform to gate everything. Then re-capture and verify. Then re-capture again after the next release, because the first fix broke two functional tags and the fix for that broke the gating again.

Weeks three through eight. Renegotiate the nine "service improvement" contracts. Six vendors accept purpose limitation; two negotiate to a narrowed version; one refuses and is replaced.

Week four. Terminate the advertising container chaining to unidentified affiliates, and replace it with direct integrations Larkspur can enumerate.

Week six. Rewrite the privacy policy to describe actual practice. Adaeze specifically declines to write it broadly enough to cover the old behavior.

Week eight. Governance: publish rights restricted to two people, mandatory review before deployment, prohibited-page list enforced by an automated scan, and quarterly consent verification with a named owner.

The outcome

Total cost: about $310,000 including engineering time and outside counsel. No demand letter arrived during the audit; one arrived fourteen months later, and Larkspur's response — a dated audit report, a remediation record, and a current tag inventory — resolved it for a fraction of what the peer company paid.

The three findings that mattered were all invisible from the tag list: the URL structure, the pre-submission keystroke capture, and the fact that the consent banner was decorative.

Mobile applications

Web audits routinely stop at the browser, and mobile applications are frequently worse governed.

What is different:

• SDKs replace tags, and they are compiled into the application rather than loaded at runtime. Removing one requires a release.
• Device identifiers are more persistent and more directly linkable to an individual.
• Permissions matter: location, contacts, photos, and health data access create categories of exposure that do not exist on the web.
• App store disclosure requirements demand accurate declarations of what data is collected and how it is used, and inaccurate declarations are their own violation.
• The consent interface is different, and platform-level tracking permissions interact with the operator's own consent flow in ways that confuse both.

How to audit an application:

1. Proxy the traffic. Route the device through an intercepting proxy with a trusted certificate and capture every request. This is the equivalent of browser developer tools and it is the only reliable method.
2. Decompile or inspect the build for embedded SDKs, and compare against the dependency manifest.
3. Test each permission state: granted, denied, and the platform tracking permission separately.
4. Test first launch, which is where SDKs frequently transmit before any consent interface appears.
5. Map the same fields as on the web, plus device identifiers, advertising identifiers, and any hardware attributes.
6. Compare against the app store disclosure and correct any mismatch.
7. Check the SDK contracts for the same purpose-limitation question.

The recurring finding: an SDK that transmits on application launch, before the consent screen renders. This is difficult to defend on any theory and is usually fixable with an initialization change.

A working sequence

Total: eight to twelve weeks for a mid-sized site, with the highest-value fixes landing in week one.

Mistakes that recur

Asking for a list instead of capturing traffic. The list is always incomplete.

Testing only the home page. The exposure is on the sensitive pages and the form pages.

Testing only in the default consent state. The finding that matters is what fires after a decline.

Summarizing transmitted data as "analytics." The field-level detail is the analysis.

Ignoring mobile SDKs. Applications have their own stack, frequently worse governed than the web.

Ignoring embedded third-party widgets. Chat, video, reviews, maps, and fonts each load their own tags.

Reviewing the tag but not the contract. The vendor's permitted use decides the party-exception argument.

Writing a broad privacy policy to cover everything. An accurate narrow description is defensible; an inaccurate broad one is not.

Doing the audit and not the governance. The stack drifts back within two quarters.

When a demand letter arrives mid-audit

• Preserve immediately: tag manager history, consent platform logs, policy versions, page templates, vendor contracts.
• Verify the allegation. Automated scans generate letters about tags that are not present or that fire only in configurations the scanner used.
• Stop the ongoing conduct on the identified pages regardless of the merits.
• Assess arbitration before anything else. An enforceable clause reaching the plaintiff changes the entire posture.
• Do not produce the audit without a privilege analysis.
• Do not remediate in a way that destroys evidence of the prior configuration.

Reading a capture: what to look for, concretely

Counsel who can read a network capture make better decisions than counsel who receive a summary. The skill is not difficult.

Each request has four parts that matter.

The destination. The domain receiving the request. Resolve it to a company — many advertising domains bear no resemblance to the vendor's name, and a single vendor may use several. Maintain a mapping.

The query string. Everything after the question mark. This is where page URLs, event names, and custom parameters travel. Read every parameter. Names are frequently abbreviated (dl for document location, dr for referrer, cid for client identifier, ev for event) and vendor documentation explains them.

The headers. The Referer header transmits the page the user was on. This is how sensitive page URLs leak to every third party on the page, without anyone configuring it. Referrer policy settings control it, and most sites have never configured them.

The body. For POST requests, the payload. Session replay and chat traffic lives here, and it is where keystroke and message content appears. Bodies are often compressed or encoded; decode them.

Specific patterns to search for across the whole capture:

The distinctive-test-data technique is the most useful single method. Fill every form field with a unique string — a made-up name, a specific dollar amount, a nonsense email — and then search the entire capture for those strings. Anything that appears is being transmitted, regardless of what the vendor's documentation claims.

Verify the negative too. After declining consent, search the capture for the advertising destinations. Their absence is the finding you want; their presence is the finding you need.

Designing pages so the leak cannot happen

Remediation removes tags. Design prevents the exposure from existing.

Keep sensitive attributes out of URLs. This is the single most effective architectural change available, and it is frequently a small engineering task. A URL of /results?condition=diabetes discloses to every third party on the page. A URL of /results with the parameters in a POST body or in session state discloses nothing. Audit URL structures for: health conditions, financial products and amounts, legal matters, employment status, immigration status, and anything else a person would not announce.

Set a restrictive referrer policy. A Referrer-Policy header of strict-origin-when-cross-origin or no-referrer prevents the full page URL from traveling to third parties automatically. Most sites have never set one and are leaking page addresses to every tag by default.

Segregate sensitive flows. Put the application form, the symptom checker, or the account area on a distinct template with no third-party tags at all, enforced by build configuration rather than by tag manager rules. A rule that can be overridden in a user interface will eventually be overridden.

Use first-party endpoints for measurement. Collect the events you need on your own server, then decide deliberately what to forward and to whom. This preserves measurement while giving you a control point that does not exist when the browser talks directly to a vendor.

Do not put form values in event parameters. Conversion tracking needs to know that a conversion happened, not what was entered. Send an opaque event identifier and reconcile server-side.

Disable default features you did not choose. Vendors ship "enhanced matching," "automatic event detection," and similar features enabled by default. These transmit far more than the operator intended and are among the most common findings in an audit.

Load third-party widgets in isolation. Chat, video, and review components that load their own tags should be sandboxed or replaced with first-party implementations on sensitive pages.

Build consent gating at the loader, not at the tag. A gate the tag itself honors depends on the tag behaving. A gate that prevents the script from loading at all does not.

Make the prohibited-page rule automatic. An automated scan that fails the build if a third-party script appears on a page in the restricted set is worth more than any policy document.

Working with marketing

The audit produces findings that marketing experiences as loss, and the projects that succeed are the ones where that is handled deliberately rather than by memorandum.

Bring the measurement data, not the statute. "Removing this pixel from the symptom checker costs us nothing measurable" is a persuasive sentence. "This violates a two-party consent statute" is not, to a person whose objectives are conversion metrics.

Quantify what is actually at stake. In most audits the tags on sensitive pages contribute a small fraction of measurable attribution, because conversion happens elsewhere in the funnel. Run the analysis before the conversation. Where a removal genuinely costs performance, say so and price the risk honestly rather than pretending the trade-off does not exist.

Offer alternatives rather than prohibitions. Server-side measurement, first-party event collection, aggregated conversion reporting, and modeled attribution all preserve measurement capability. A legal team that arrives with an alternative is a partner; one that arrives with a list of removals is an obstacle to be routed around, and routing around is how tags get hard-coded into templates.

Give marketing a fast approval path. If review takes three weeks, tags will be deployed without it. A same-week turnaround for standard requests, with a documented escalation for novel ones, is the price of having a rule anyone follows.

Put the prohibited-page list in their tools. A tag manager configured so restricted pages cannot receive advertising tags removes the decision from the moment of pressure.

Explain the asymmetry. A tag that improves attribution by two percent, deployed on a page whose URL reveals a health condition, is trading a marginal measurement gain against per-visitor statutory damages. Framed that way, the decision is usually easy — and marketing teams generally make it correctly when they are told the arithmetic rather than the rule.

Include them in the audit. A marketing lead who watched the traffic capture and saw what a pixel actually transmits becomes the most effective advocate for governance in the company. This is worth more than any policy.

Frequently asked questions

Who should own this permanently? Someone with both technical access and standing to say no — typically a privacy engineer or a privacy counsel with a named engineering counterpart. The failure mode is ownership by a lawyer with no ability to read a capture, or by an engineer with no authority to block a launch. The role needs both halves.

Is this ever finished? No. Vendors change what their tags transmit, sites get redesigned, consent platforms update, new jurisdictions become relevant, and marketing teams turn over. The audit is a periodic exercise and the governance is continuous. An organization that treats it as a one-time remediation will be back where it started within about eighteen months, which is roughly the observed interval.

Should the audit be done under privilege? Where the findings are likely to identify legal exposure, yes — engage counsel to direct the work, have technical findings reported to counsel, and label the analysis appropriately. Note the limits: the underlying facts about what the site transmits are not privileged, and remediation records generally are not either. Privilege protects the legal assessment, not the network capture.

What do we do about tags on pages we do not control? Co-branded pages hosted by partners, embedded widgets, and syndicated content all raise this. The answer is contractual: require partners to honor your tag standards on pages bearing your brand, obtain the right to audit, and prohibit third-party tags on any page collecting user data on your behalf. Where the partner will not agree, the exposure is real and should be documented.

How long should we keep the capture files? Long enough to demonstrate what the site did at a given time, which is genuinely useful when a demand letter alleges a configuration you changed a year ago. Retain the captures and the tag inventory versions with the audit report, subject to your ordinary retention schedule and any litigation hold.

How often should we re-run this? Full audit annually; consent gating verification quarterly; and after any tag change, site redesign, or consent platform update.

Can our agency run the audit? They can run the capture. The legal analysis should not be done by the party that deployed the tags, and the report should be prepared at counsel's direction if privilege matters.

What about tags on pages behind login? Those matter more, not less, because the visitor is identified. Capture in the authenticated state.

Do server-side tags avoid the problem? They change the technical path and may improve the argument that the operator, not the vendor, is the recipient. They do not answer what is ultimately disclosed to whom.

Is there a tool that does this? Several scanners produce useful inventories. None substitutes for capturing traffic in the configurations that matter and reading the vendor contracts.

What if marketing objects to removing tags? Quantify. Removing advertising pixels from a symptom checker or an account page costs almost nothing in measurable conversion, because those pages are not where optimization happens. Bring the data rather than the statute.

The residual risk memorandum

No audit eliminates everything. Some tags stay because the business needs them, some vendors will not accept purpose limitation and cannot be replaced, and some historical collection cannot be undone. What matters is that the remaining exposure is identified, priced, and accepted by someone with authority.

Structure:

RESIDUAL RISK — WEBSITE TRACKING            DATE: ______
PREPARED AT THE DIRECTION OF COUNSEL

1. WHAT WE REMEDIATED
   [Summary, with dates]

2. WHAT REMAINS, AND WHY
   For each item:
   - The tag or practice
   - Why it was retained (business justification)
   - The claim theories it supports
   - Estimated population affected
   - Statutory damages exposure, if applicable
   - Mitigations applied
   - Accepted by:              Date:

3. HISTORICAL EXPOSURE
   - Practices discontinued, and the period they ran
   - Limitations periods by claim and jurisdiction
   - Population estimates
   - Preservation status

4. MONITORING
   - Quarterly consent verification owner
   - Annual audit date
   - Change triggers

5. ASSUMPTIONS AND LIMITATIONS
   [What the audit did not cover: mobile, subdomains, acquired
    properties, non-English sites, partner-hosted pages]

Section 5 matters more than it looks. Audits routinely omit subdomains, acquired properties running on separate infrastructure, marketing microsites, partner-hosted co-branded pages, and non-English versions of the site. Stating what was not covered prevents a later finding from being characterized as concealed.

Section 2's acceptance line is the point of the document. Residual risk that nobody has explicitly accepted is residual risk that will be described later as an oversight. A named executive signing the line converts it into a business decision, which is what it is.

Refresh annually. Risk that was acceptable at one traffic volume, in one regulatory environment, with one set of vendor contracts, may not be at the next.

Scoping the audit for different organizations

The sequence above assumes a mid-sized commercial site. Adjust.

A small business site with a handful of pages. The full matrix is unnecessary. Capture in three consent states on the home page, the contact form, and any page with a sensitive URL. Read the vendor terms for whatever analytics and advertising tools are in use. Fix the referrer policy. Total effort: two days.

A large enterprise with many properties. The problem is inventory before it is analysis. Start by enumerating every domain and subdomain the organization operates — the list is always longer than anyone believes, because marketing campaigns, acquired companies, and regional teams stand up properties independently. Sample rather than exhaustively auditing, and prioritize by traffic and by sensitivity of content.

A health care organization. Begin with the patient-facing surfaces: portal, scheduler, symptom tools, provider directory, bill pay. Assume any third-party tag on these is a finding. The regulatory exposure exceeds the litigation exposure, and the remediation should be immediate rather than prioritized.

A financial institution. Same posture, focused on account pages, application flows, rate tools, and product comparison. 15 U.S.C. § 6802 constrains disclosure of nonpublic personal information, and the URL structure of a rate-comparison tool is frequently the leak.

A publisher or media site. Video is the distinctive exposure. Enumerate every page with embedded video, identify every analytics integration in the player, and assess the 18 U.S.C. § 2710 pattern. Publishers also tend to have the largest number of advertising integrations and the least visibility into the chain.

A service directed to children. The analysis inverts: assume no third-party collection is permissible without verifiable parental consent under 15 U.S.C. § 6501 and 16 C.F.R. Part 312, including persistent identifiers. Audit for the presence of any third-party tag rather than for what it transmits.

An organization in an acquisition process. Run the audit before diligence rather than during it. Acquirers now ask, and an organized answer with a remediation record is worth substantially more than a defensive one produced under deadline.

Tools and resources

Browser developer tools. The network panel in any modern browser is the primary instrument. Enable "preserve log" so navigation does not clear the capture, and export as HAR for analysis and retention. Nothing commercial replaces this for understanding a single page in detail.

Intercepting proxies. For mobile applications and for capturing traffic that browser tools do not surface, a proxy with a trusted certificate installed on the test device is the standard approach.

Commercial tag scanners. Several services crawl a site and report the tags found, and they are useful for breadth and for ongoing monitoring. They are weaker on depth: they will not tell you what a custom parameter contains, and they generally do not test consent states.

Consent platform diagnostics. Most consent management platforms include a scanning and categorization function. Treat its output as a starting inventory, not as verification — the platform reports what it knows about, which is the problem.

Vendor documentation. Every major analytics and advertising vendor publishes documentation of its parameters. Reading it is how you learn that dl means document location and that "enhanced matching" transmits hashed contact information. This is the fastest way to understand a capture.

Referrer policy documentation. The Referrer-Policy header is standardized and well documented. Setting it correctly is a small change with a large effect and is frequently the single highest-value technical fix available.

Regulator guidance. Enforcement agencies have published guidance on tracking technologies in health contexts, on dark patterns in consent interfaces, and on the definition of sale under state privacy statutes. Consent orders are also instructive: they describe, in detail, what the regulator considered wrong and what remediation it required.

Counsel with the technical fluency. The distinguishing skill in this area is the ability to read a network capture and connect a specific parameter to a specific statutory element. Advice given without looking at the traffic is advice about a site somebody imagined.

Related documents

• Tracking Pixels, Session Replay, and the Wiretapping Lawsuits Reshaping Adtech
• Website Tracking Compliance Checklist: A Practical Checklist
• Adtech Privacy Toolkit: Tag Inventories, Consent Records, and Litigation Defense
• Developing a Privacy Compliance Program
• Data Subject Rights Request Handling Checklist: A Practical Checklist
• Building a Vendor and Third-Party Risk Management Program
• State Consumer Privacy Laws: The CCPA, the CPRA, and the Multi-State Patchwork
• HIPAA Business Associates and Cloud Computing