What Your Website Sends Before Consent: The Tracking Risk Most Audits Miss

A consent banner can record a choice. It cannot, by itself, prove what the browser sent, when it sent it, or where the data went.

The privacy question is not only which trackers are installed, but what data actually leaves the browser and where it goes.

A website can load correctly, display a privacy banner, and still send data to third parties before the visitor makes a choice. That is the gap many privacy reviews miss.

Most audits start with configuration: which tags, pixels, SDKs, chat tools, analytics services, or consent platforms are installed. That inventory matters. But it does not answer the harder questions: what information actually left the browser, when it left, which domain received it, whether the visitor had accepted or rejected tracking, and whether the first recipient passed data onward.

Those details matter because privacy exposure follows the data flow, not the label on the tag.

What can a website send before consent?

The answer is broader than cookies. Depending on the site and the tool, a browser request can carry identifiers, page context, event data, and technical metadata before a user has interacted with a consent banner.

Data in a request

Why it matters

IP address

Network address exposed as the browser connects to a server

Cookie or device identifier

A value that can recognize a browser or device across requests

Page URL and referrer

The page being viewed and, sometimes, where the visit came from

Account or user ID

An identifier tied to a logged-in or recognized visitor

Event data

Page view, click, purchase, search, signup, or other interaction

Form-related data

Values or events associated with forms, depending on implementation

Browser and device details

Browser type, language, device characteristics, and similar metadata

Destination

The third-party domain or endpoint receiving the request

The Federal Trade Commission has described tracking pixels as technology that can send information about page interactions, purchases, clicks, and information entered into forms. In the FTC’s GoodRx complaint, the agency alleged that third-party tracking tools sent data that could include contact information, persistent identifiers, location information, and event data. FTC technical explanation | GoodRx complaint

A useful distinction

A tag tells you what technology is present. A network request tells you what actually happened.

Why a tag inventory is not proof of website behavior

Imagine two sites with the same advertising pixel installed. On one site, the pixel stays blocked until the visitor opts in. On the other, it fires on page load and continues after rejection. The inventory is identical. The behavior is not.

That is why a scanner that only lists cookies, scripts, or vendors can miss the core issue. Data can move through network requests, APIs, local storage, URL parameters, server-side integrations, tag-manager changes, and other mechanisms. The meaningful question is whether the site can reconstruct the transfer itself.

The FTC made the same practical point in its 2024 complaint against Monument. Among other allegations, the agency said the company failed to conduct tests to determine what data was transferred to third parties through tracking technologies. FTC v. Monument complaint

A request-level review looks at actual browser traffic, not only the list of scripts or vendors installed on the page.

Why consent timing changes the investigation

Website tracking should be tested as a sequence, not a screenshot. A simple session can move through several privacy states within seconds:

1. The page loads.

2. Scripts initialize.

3. The consent interface appears.

4. The visitor accepts, rejects, or ignores it.

5. A browser-level opt-out preference signal may also be present.

6. Requests continue as the visitor clicks, logs in, searches, purchases, or submits a form.

The same request can mean something very different depending on where it falls in that sequence. If a consent platform records “rejected” while an advertising request keeps firing, the interface and the underlying behavior are telling different stories.

California also requires covered businesses to honor qualifying opt-out preference signals, such as Global Privacy Control, as requests to opt out of sale or sharing. That creates another state worth testing: what changes in the network traffic when the signal is present? California Privacy Protection Agency FAQ

A consent banner and the browser network log should be tested together. The interface shows the choice; the traffic shows the result.

What do pen-register claims have to do with website tracking?

A pen register is a legal term for a device or process that records or decodes dialing, routing, addressing, or signaling information from a wire or electronic communication, without capturing the contents of the communication. California uses that formulation in Penal Code § 638.50. Federal law uses a closely related definition in 18 U.S.C. § 3127. California Penal Code § 638.50 | 18 U.S.C. § 3127

California Penal Code § 638.51 generally bars a person from installing or using a pen register or trap-and-trace device without a court order, subject to listed exceptions for electronic or wire communication providers, including when user consent has been obtained. California Penal Code § 638.51

Plaintiffs have applied that language to modern web tracking by arguing that certain pixels, scripts, or similar processes collect routing, addressing, or signaling information from a visitor’s device. Whether a particular implementation fits the statute is a legal question. But the factual questions underneath it are technical:

• What request actually fired?

• What identifiers or metadata were transmitted?

• Which endpoint received the request?

• Did the transfer occur before or after a consent state was established?

• Was the information limited to addressing/signaling data, or did the request contain content as well?

• Can the site reproduce and document the behavior?

Legal status note: September 21, 2026

California SB 690 has passed the Legislature and was presented to the Governor on September 4, 2026. The enrolled text would limit private § 638.51 website, online-application, and mobile-application actions under § 637.2 so that only the Attorney General could bring them. As of the date checked, the official status still lists the bill as enrolled and with the Governor; it has not yet become law.

Official SB 690 status | Enrolled bill text

The solution found: technical evidence 

While researching how a company could investigate this kind of allegation, I found Melurna’s guide to website tracking. What stood out was the narrower claim it makes: not that software can decide whether a tracker is legally a pen register, but that the technical behavior behind the allegation can be observed and preserved.

Melurna says its platform performs recurring observations of browser and application traffic and captures requests, responses, cookies, headers, query parameters, destinations, timing, and interaction context. Its insurance materials separately describe preserving time-bounded records of observable data movement, consent behavior, recipients, and policy drift to support claims triage and investigation “without asserting legal conclusions.” Those are vendor claims, but the distinction is useful: counsel interprets the law; technical evidence establishes what the site actually did.

For a pen-register allegation, that means the useful output is not a label saying “legal” or “illegal.” It is a reproducible evidence set that can answer questions such as:

• which tracker or process initiated the request;

• what identifiers, parameters, headers, or other fields were present;

• which recipient received the request;

• what consent or preference state existed at the time;

• whether the behavior changed across later observations; and

• whether data moved beyond the first recipient to additional parties.

That is a stronger way to position the use case. Melurna is not a substitute for legal counsel. It is a way to monitor the technical conditions that can create, support, or rebut a tracking-related claim.

Vendor references: Melurna platform · Melurna insurance/claims context

The investigation becomes more useful when it follows the request beyond the first visible tag to the recipients and downstream relationships around it.

Why the first recipient may not be the end of the data journey

Privacy reviews often describe a flow as “website to analytics provider” or “website to advertising platform.” That can be too simple. A first-party page can invoke a tag manager, which loads another service, which resolves an identity or calls another endpoint. A vendor can also change its own integrations without the website owner adding a new visible tag.

That does not automatically create liability. It does create an evidence problem. If a business cannot identify the recipients involved, it cannot reliably compare actual data movement with contracts, disclosures, consent choices, or risk assessments.

A privacy review should identify destinations and relationships, not stop at the name of the first tag that fired.

What should a useful website tracking audit capture?

A useful audit should produce evidence that another person can review later. At minimum, it should answer seven questions.

1. What left the browser?

Capture the actual outbound request or transfer, not only the tag name.

2. What information was included?

Record identifiers, parameters, headers, URL data, event fields, and other transmitted values that matter to the review.

3. Who received it?

Resolve the destination domain or endpoint and the organization behind it where possible.

4. When did it happen?

Tie the request to page load, banner display, acceptance, rejection, opt-out preference signals, login, form submission, purchase, or other relevant events.

5. Did behavior match the visitor’s choice?

A consent record should correspond to the expected change in network behavior.

6. Did behavior match disclosures and contracts?

Compare observed flows with the privacy notice, vendor terms, data-processing agreements, and internal approvals.

7. Did the behavior change later?

Repeat observations so a new script, endpoint, identifier, or downstream recipient does not go unnoticed.

What evidence is worth preserving?

When a questionable flow appears, the best record is one that lets a reviewer reconstruct the event rather than rely on a screenshot or memory.

Evidence

Question it answers

Timestamp

When did the request occur?

Page and interaction

What was the visitor doing?

Consent or preference state

Had the visitor accepted, rejected, or sent an opt-out signal?

Destination and initiator

Who received the request and what caused it to fire?

Request fields

What data or metadata was transmitted?

Identifier context

Could the browser, device, account, or visitor be recognized?

Recipient chain

Did the data move beyond the first service?

Historical comparison

Is the behavior new, recurring, or changed?

What should happen when a tracking claim arrives?

The first response should be factual. Preserve the current site state before changing tags or consent settings. Reproduce the relevant pages and user states. Capture the requests. Identify the recipients. Compare the behavior with the allegation, privacy notice, consent records, and applicable contracts. Then give counsel the evidence needed to evaluate the legal theory.

That order matters. If the site is changed first and investigated later, the most useful evidence may disappear.

The operational rule

Do not start with “Which vendor is on the site?” Start with “What did the browser send, when, and to whom?”

Frequently asked questions

Can a website send data before a visitor clicks a consent banner?

Yes. Scripts and third-party requests can execute during page load. Whether that behavior is permitted depends on the data, purpose, applicable law, consent requirements, and configuration. The technical question is answered by observing the network traffic before any choice is made.

Is every tracking pixel a pen register?

No. A pixel or script should not be treated as a pen register merely because it tracks users. The legal analysis depends on the statute and the facts, including what the process records or decodes. California § 638.50 focuses on dialing, routing, addressing, or signaling information and excludes the contents of a communication from the pen-register definition.

Does a consent management platform prove that tracking stopped?

Not by itself. A consent platform can record a choice, but the underlying requests still need to be tested. A useful audit checks whether the browser’s behavior changed as expected after acceptance, rejection, or an opt-out preference signal.

How can a company investigate a pen-register website claim?

Preserve the relevant site state, reproduce the page and consent conditions, capture the network requests, identify the data fields and recipients, and document timing. Legal counsel can then evaluate the claim against the statute using evidence of what actually happened.

What is Melurna’s role in a pen-register investigation?

Melurna describes its role as technical evidence and monitoring rather than legal judgment. Its materials say it observes browser and application traffic, tracks recipients and consent behavior, and preserves evidence histories that can support claims triage without asserting legal conclusions.

Follow the request, not just the tag

A privacy banner can document a choice. A tag inventory can document a configuration. Neither, by itself, proves what happened to the data.

The durable control is request-level visibility: what left the browser, when it left, who received it, what privacy state existed at that moment, and whether the behavior changed later. That evidence is useful whether the issue becomes a pen-register allegation, a regulator inquiry, a contract review, or an internal privacy investigation.

For teams dealing with website tracking risk, the practical rule is simple: follow the request.

Primary sources and further reading

Legal and regulatory sources below were checked on September 21, 2026.

1. California Penal Code § 638.50: definitions of pen register and trap-and-trace device - California Legislature

2. California Penal Code § 638.51: prohibition and statutory exceptions - California Legislature

3. 18 U.S.C. Chapter 206, including §§ 3121 and 3127 - U.S. House Office of the Law Revision Counsel

4. SB 690 official status - California Legislature

5. SB 690 enrolled text - California Legislature

6. California Privacy Protection Agency FAQ: opt-out preference signals - California Privacy Protection Agency

7. Lurking Beneath the Surface: Hidden Impacts of Pixel Tracking - Federal Trade Commission

8. FTC complaint against GoodRx - Federal Trade Commission / U.S. District Court filing

9. FTC complaint against Monument - Federal Trade Commission / U.S. District Court filing

Melurna references (vendor materials): Pen register guide · Platform methodology · Claims context

Editorial/legal note: This article is general information, not legal advice. SB 690 is pending as of the legal-status date above and should be rechecked if publication occurs after September 21, 2026.