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
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
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
<IMG SRC> tags.
Only DFP knows to expand
%n into a random number, so do not use this RNG unless your publisher uses DFP.
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.
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.
For DART Enterprise, RealMedia, or Adforce, the publisher can replace the
[timestamp] component of the tags with these variables:
|Ad serving solution||Timestamp variable|
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.
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.