Browser/proxy server caching

Use cache busting to ensure that impressions are counted each time your ad servers. Cache busting typically involves adding a random number generator (RNG) to your ad tags, also known as a cache buster.

This process is the same for all ads on all devices, including mobile and non-mobile inventory. All ads in DCM use standard tags, and all standard tags should include a cache buster.

How does cache busting work?

Browsers get site content and ad content from servers. Webpages have code that instructs browsers to "call" servers to request this content, including images and videos. When your browers cache content, they store it on the user's computer (or a proxy server) for later use. Once content is cached, the browser no longer has to request it from servers. This speeds up load times.

The trouble is, DCM records impressions on your ads based on content requests. If a browser caches ad content for a particular ad, it will not need to request the ad content when your ad tag fires. Without a request, DCM cannot log an impression.

Cache busting is way to prevent browsers from cachcing your ad content. Cache busting adds a random string to your ad tag each time the tag fires — typically a random number. Because the tag has a different number each time, the browser sends a new request each time. The browser can't tell that it has already cached content associated with your tag because the tag has a different random number each time it fires.

Generally, tags use random number generation (RNG) to dynamically add a random number to your tag each time it fires. This number is a value for the ord= attribute.

Add cache busters to tags

  • For publishers that use DoubleClick for Publishers, add a random number generator (RNG).

  • For publishers that use other ad serving solutions, use a timestamp variable or other variable that the system can recognize.

See below for steps.

Cache busting for DFP

If your publisher uses DFP, insert the %n macro after ord= in your tags. E.g., ord=%n. If there is already an ord value, replace it with %n.

In order for the click-through URL and the image to work correctly, you must place the variable as the value of the ord= key in both the <HREF>and the <IMG SRC> tags.

Only DFP knows to expand %n into a random number, so do not use this RNG unless your publisher uses DFP.

About RNGs

As discussed above, an RNG inserts a random number into your ad tag each time it fires. If the tag is different each time (because it has a different random number), the browser sends a new ad request each time the tag fires. This ensures that impressions are logged each time your ad appears, and that the browser does not use its caached content.

An RNG is best implemented with a macro that the publisher's system automatically expands into a random or different value each time the tag fires.

Cache busting for non-DFP

If your publisher doesn't use DFP as its adserving solution, you should still add a cache buster, such as a timestamp variable or a random number generated by an RNG that the system recognizes.

Sample RNGs

For DART Enterprise, RealMedia, or Adforce, the publisher can replace the [timestamp] component of the tags with these variables:

Ad serving solutionTimestamp variable
DART Enterprise $gmt$
RealMedia %GMTTIME%

These variables are guidelines only. Please verify the timestamp for your ad serving solution with your contact at the respective company, as these variables vary according to the third-party ad server version.

If a random number cannot be generated at the server level, you can use JavaScript code to generate a string at the client (browser) level. Learn more

What happens if I don't use RNGs or other cache busters to defeat caching?

Once a browser or proxy server receives a creative asset from DCM, it stores it in the browser cache. The browser draws any additional calls for the asset from the cache, rather than from the DCM ad servers. DCM therefore doesn't record additional impressions, which causes discrepancies.