When the verification tag never fires

What "never fired" means

A verification tag is a small script that travels inside the ad. When the ad renders in the browser, the script runs and sends a measurement back — whether the ad loaded, where it sat, how long it was on screen. An impression the exchange served but for which no measurement ever arrived is one where the tag never fired.

It is different from an impression that fired and was then rejected — for a malformed ID, say. That one reached the verification server and was refused; this one never reached it at all. They have different causes, so keep them apart.

The usual causes

Cause	How it shows up
The tag is not inside the ad. It sits in the page, in a separate iframe, or in a tag manager beside the creative.	Near-total loss for one creative or one placement. If it fires at all, it measures the page, and its viewability figures mean nothing.
The ad server dropped it. A creative was re-uploaded, re-wrapped or trafficked without the tag.	A cliff on a date: the gap was normal, then one creative or line item went to zero measured.
The page was gone first. Slow pages, heavy creatives, fast scrolling.	A gap that grows on mobile and on slow sites, and shrinks on fast ones.
A content blocker stopped it. Some blockers let the ad render and block the verification request.	A steady gap concentrated on desktop browsers.
The page does not allow it. A publisher's content security policy or a restrictive SafeFrame setup blocks the request.	A gap confined to particular sites, whatever the creative.
The creative failed to render. A broken asset or a script error before the tag ran.	Loss for one creative across every site.

Fired, but refused

If the measurement arrives but cannot be used, it is not a "never fired", and the fix is on the integration side:

• Unexpanded macros. The impression or campaign ID arrived as a literal ${AUCTION_ID} or %%PATTERN:auction_id%%, because the ad server did not recognise the macro. The measurement cannot be matched to the impression that was billed.
• A stale measurement. The measurement arrived long after the impression was served — usually a cached or replayed creative.
• An unknown account. The tag named an account the verification server does not know.

Pixtru counts each of these by name per partner, so a wrong macro is visible within minutes of launch rather than at month end. Checking it works lists them all.

How to check, in order

1. Split the gap. By creative, site, browser, device and day. A tag problem is almost never spread evenly; find the slice where it lives.
2. Look at the creative as served. Pull the tag the ad server actually delivers, not the one you sent it. Confirm the verification script is inside the creative markup.
3. Fire it yourself. Load the ad in a clean browser profile with no extensions, open the network panel, and watch for the verification request. It should leave when the ad renders and be answered — Pixtru's collector answers 204 No Content whether the measurement was kept or not, so a 204 proves delivery, not acceptance.
4. Read the IDs in that request. Every value should be a real value. Anything still containing ${, %% or {{ is a macro the ad server did not replace.
5. Compare with and without a blocker. If the request disappears with one installed, you have found a share of the gap that no integration change will recover.

Whose problem is it?

Unmeasured impressions are usually charged for. Some causes belong to the buyer (the tag was trafficked wrongly), some to the seller (slow pages, blocking policies), and some to nobody (a reader who scrolled past before the ad loaded). Knowing which is which is the whole of the negotiation. Pixtru reports these impressions as tracker_never_fired — served, never measured — separately from those that were measured and failed a later test, so the two conversations stay separate. See why the numbers do not match for the other stages.