A cached impression is a lie

Floodlight ord and num

Campaign Manager activity tags put a unique value in ord. src, type, cat, and ord are required. Unique counting needs num alongside ord; num without ord is meaningless. A leftover literal ord=1 on a live tag is a classic trafficking miss: every impression looks like the same GET, and the first CDN hop wins. Pixellint's Floodlight pack flags missing or empty ord, empty num, and unique counting without ord.

Unique does not mean secret. A timestamp plus a random, or the ad server's cache-buster macro expanded at serve time, is enough. 13-digit milliseconds or a UUID both work. Do not reuse the order id unless you understand Floodlight's counting: sales tags often want a unique ord per transaction, which is a different job from cache busting an impression, even though the parameter name is the same.

Other names, same job

cb, cbuster, random, z, and [CACHEBUSTER] all mean the same job: make this GET unique so caches miss. GAM, many SSPs, and VAST Impression URLs use [CACHEBUSTER] or ${CACHEBUSTER} or {{CACHEBUSTER}}. The ad server must expand the macro at serve time. A fired URL that still contains [CACHEBUSTER] never busted anything. Core flags that as an unexpanded macro when the artifact state is fired.

Pick one syntax per URL. Mixing [CACHEBUSTER] and ${RANDOM} in one impression is a trafficking smell (core.macro.mixed_syntax). The player will not expand both families. Confirm on a HAR from the player, not on the creative in GAM, or you will fail a legal template.

Do not put PII in ord

ord is copied into CDN logs, bidder logs, and any Referer that still carries the full impression URL. An email, a phone, or a name in ord is a leak with no matching benefit. Hashing does not belong here either; Floodlight will not SHA-256-match an email stuffed into ord. Use an opaque random. If you need to key a sale, use the documented Floodlight custom variable slots, not the cache buster.

The same warning applies to cb and random. A well-meaning engineer who puts user_id=email@shop.com in every unique slot has published that email to every hop that cached or logged the 1x1. Core URL rules will not call that PII; Meta's pack will if the host is facebook.com/tr. On doubleclick.net, the leak is still a leak.

Do not cache-bust clicks the same way

Click URLs are navigations. Uniqueness comes from click ids (gclid, fbclid, the MMP id), not from fighting a CDN. Extra random query params on a click chain just make log joins harder and can push you toward URL-length problems on long wrappers. A click 302 that adds &cb=Math.random() on every hop is noise.

If a click URL is being cached, you have a different bug: a GET that should 302 is being stored as 200, or an intermediary is caching 302 without Vary. Fix the Cache-Control on the click tracker. Do not add ord to a click URL because the impression tag had one. Different slot, different contract.

Template versus a live ord

In GAM or Campaign Manager the tag still shows ord=[timestamp] or ord={{ord}}. Validate that as template. In Chrome Network the same tag shows ord=1724284800123. Validate that as fired. pixellint validate url on a template with --state template will not demand expansion. The same paste as fired will.

A CI job that only lints the template will never see a leftover literal ord=1 that a trafficker typed into the live tag. A job that only lints one HAR will never see the next creative that shipped ${RANDOM} in the host. Keep both fixtures. The example below is a template: src, type, cat, and ord are present, and the cache buster is still a token.

https://ad.doubleclick.net/activity;src=1234567;type=inv123;cat=impr00;ord=[timestamp];num=1?

Check the artifact

Paste the pixel URL or JSON body into the playground. Same engine as pixellint validate. Nothing leaves the tab.