Ad blockers and privacy settings permanently omit some users

What it is

Ad blockers, tracking prevention, system limits on advertising identifiers, cookie rejection, and a “no” on a consent banner keep some people’s client events out of the analysis store forever. This is not a few unlucky days of sampling; a class of users leaves the frame. They often care more about privacy and use particular browsers, and they behave unlike people who remain visible. Estimating “all users” from visible users treats a selected subgroup as the population.

Why it happens

Missingness hits the collection boundary: a script is blocked, an identifier is reset, software never initializes without consent. Unlike dropped packets, there is often no failure count to calibrate against, because the instrument never started. Missingness tracks attitude and is not random: people who refuse tracking are more likely to skip ads, run content blockers, and move across devices. The web is harder hit than in-app flows, because extensions and intelligent tracking prevention act on scripts directly. The server may still see logged-in transactions, but the front of the funnel, anonymous browsing, and cross-site attribution are blind on this side. Treating the consented sample as everyone systematically overstates the contribution of trackable channels.

Studying it

Report the observable cohort separately from true product activity (from server counts that do not depend on scripts). Estimate block and refusal rates: consent-banner choices, known blocker signatures, accounts with server activity but no client events. For critical paths, read server completions beside client paths; the gap is the scale of missingness. Claims that generalize to everyone must state the missingness mechanism; if they cannot, stop the conclusion at the observable subgroup. Do not impute refusers as average tracked users.

Where it stops holding

Pure server-side, post-login measurement that does not rely on third-party scripts is less exposed. Managed or intranet devices block less, and they do not represent consumer markets. People who disable blockers later appear as false new users. Legally required opt-outs must be honored; research needs to admit the hole, not route around the blocker. When consent is designed to approach one hundred percent, missingness becomes another bias: those who remain were persuaded or did not see the choice.

Applying it

• Treat server-side posting as the source of truth for critical completions; describe client paths only for people who consented and were not blocked.
• Print coverage (client-event people / server-active people) in the report; do not write rates as population facts when coverage is low.
• Before comparing channels or browsers, look at each channel’s block and refusal rate; do not write “Safari converts worse” as a product defect by default.
• If a decision involves the blocked population’s experience, use surveys, recruit that group for tests, or a server-side proxy; do not read a blank as no demand.

Related

• Same group: Q3.11.1 Logs record behavior but not motive · Q3.11.2 Instrumentation design determines which questions can later be answered · Q3.11.3 Missing events cannot be backfilled after the fact · Q3.11.4 Inconsistent event names prevent joining data across versions · Q3.11.5 Sampling and dropped reports systematically undercount rare actions · Q3.11.7 The same event may fire under unequal conditions across platforms
• Adjacent: Q1.04 Sampling and representativeness · Q1.13 Informed consent and research ethics
• Search terms: privacy-induced missingness · ad blocker analytics · consent bias