The Silent Bug in Every Ad Pixel

Every site running paid ads eventually installs the same piece of code: a small JavaScript snippet from an ad platform that reports back when something worth knowing happens, a page loaded, a form got submitted. It's usually a few lines, it's usually copy-pasted from a setup guide, and it usually works on the day it ships.

The failures don't show up on that day. They show up months later, as a quiet gap between what actually happened on the site and what the ad platform believes happened. The gap is never explained by one dramatic bug. It's built out of several individually reasonable decisions that were never checked against each other.

The fifteen-minute fix that broke the first event

A landing page needs to log the moment someone arrives, before they do anything else. The obvious implementation:

useEffect(() => {
  analytics.capture("landing_viewed");
}, []);

Correct, minimal, and it works instantly in local testing. It ships.

Separately, for good reason, the analytics SDK's own initialization was deferred to browser idle time elsewhere in the app, so it wouldn't compete with the page's first paint:

const idleId = requestIdleCallback(() => sdk.init());

Also correct. Also a completely reasonable performance decision, made by someone thinking about load time, not about the mount effect three files away.

Individually, both of these are good code. Together, they're a race: on a fast device, idle time arrives before the mount effect runs, and everything works. On a slow or loaded device (an in-app browser inside a social app is the textbook case), the mount effect wins, calls into an SDK that hasn't initialized yet, and the call is simply discarded. No exception, no console warning. The function that doesn't exist yet just doesn't get called, and the calling code has no way to know that happened.

The event lost this way is, almost always, the single most valuable one in the whole funnel: the first touch from a paid visitor. And because it fails silently, on a subset of devices, on a subset of sessions, the failure shows up not as a bug report but as an unexplained soft dip in a chart that everyone assumes is normal variance.

The fix isn't complicated once you see it: the deferred initialization needs to announce when it's actually done, and anything racing against it needs to wait for that announcement instead of assuming it already happened.

sdk.init({
  loaded: () => window.dispatchEvent(new Event("sdk-ready")),
});

// caller:
if (window.__sdkReady) fire();
else window.addEventListener("sdk-ready", fire, { once: true });

The general shape of the bug is worth naming, because it recurs anywhere a system defers its own setup for performance reasons: any call site that assumes a dependency is ready, without being told so, is a race, even if it passes every test you happen to run it on.

One event, never two

Browser pixels fail in ways no amount of careful coding can fix from inside the browser: ad blockers block the request outright, browser privacy features truncate or delete the cookies the pixel relies on, and some in-app browsers behave unpredictably enough that the request never leaves at all. The industry's answer is to also report the same event from the server: a direct, backend-to-backend call that never touches any of those failure modes.

Which immediately creates a new problem: now the same real-world action can be reported twice, once from the browser and once from the server, and the ad platform has no way to know they're the same event unless it's told.

The fix is a deduplication ID: one identifier, generated once per real action, attached to both the browser call and the server call. The platform is told: if you see this exact ID twice within some window, keep the first copy and discard the second.

The part worth designing carefully is what the ID is derived from. Deriving it from the click, or from the attempt, seems obvious and is wrong: a person who submits twice by mistake would count as two conversions, and a retried request after a network blip would too. Deriving it from the identity behind the action (a hash of whatever uniquely identifies the person completing it) means a genuine repeat submission from the same actual person collapses correctly, while two different people never collide.

const dedupeId = `conv-${sha256(identity.trim().toLowerCase())}`;

That one design decision is the entire contract between two systems that otherwise have no way of knowing about each other.

Where it broke, part one: the correct code that did nothing

The server-side leg was written defensively, the way it should be: if the required credential isn't configured, log a warning and skip, rather than crash.

if (!accessToken) {
  console.warn("Server-side leg not configured, browser pixel still works alone.");
  return;
}

This is good code. It's also exactly the code that let a misconfiguration hide for weeks: the credential was simply never set in the deployment environment, and because the failure mode was a graceful no-op rather than an error, nothing surfaced it. Dashboards looked normal, because the browser leg was still reporting something. Nobody noticed the server leg had never fired a single event, because "silently doing nothing" and "working correctly" produce identical dashboards until you go looking with a tool built specifically to inspect the wire traffic, rather than trusting the code that generates it.

The lesson isn't "don't fail gracefully": failing gracefully was the right call, since a tracking outage should never be allowed to break the actual product. The lesson is that a graceful no-op needs an independent way to be noticed, because by design it looks exactly like success.

Where it broke, part two: the second owner nobody knew about

Months later, a routine audit turned up a tag-management container (the kind of tool meant to let non-engineers manage tracking scripts without touching code) sitting in the project, alongside code that already hardcoded the same ad account's conversion tracking directly. Inside that container, unpublished, was a duplicate configuration for the exact same account ID, added years earlier by someone who no longer had context on it, and never fixed or removed.

Nothing had actually broken yet: the duplicate configuration was still in draft, never activated. But the failure mode it represented was worse than an active bug: a second, independent owner of the same tracking identifier, unknown to the first owner, one click away from going live. Neither person who added either copy had done anything unreasonable. Each was solving a real problem, at a different time, with no way to see the other's work.

The rule this points to is simple to state and easy to violate by accident: every tracking identifier should have exactly one place that's allowed to activate it, and that place should be discoverable by anyone who goes looking, not just by the person who happens to remember adding it.

What we would do differently

Announce readiness the moment you defer anything for performance. Any requestIdleCallback, lazy-load, or deferred init is a race by construction. The fix costs one event dispatch and should be written in the same commit as the deferral, not bolted on after the first silent drop gets noticed.

Design the deduplication key before writing the second leg, not after. It's tempting to add server-side reporting as a copy of what the browser already sends. The one question that actually matters ("what real-world action does this ID represent, and what should and shouldn't collapse into it") has to be answered deliberately, because getting it wrong either double-counts or silently drops repeat legitimate activity.

Treat "fails silently" as a design requirement to test for, not a side effect to tolerate. A defensive no-op is the right code. It also means you cannot verify the system worked by reading the code: you have to go inspect the actual traffic, with a tool built for exactly that, on a schedule, not just once at launch.

None of this is exotic. Every step above was the reasonable choice at the time it was made. The gap between "what we built" and "what the ad platform actually received" was never one bad decision: it was several good ones, made without a way to see each other.