When monitoring campaign delivery, you might run into some peculiar conflicts. Although Adhese goes to great lengths to optimize delivery and tries to ensure everything goes as planned, errors can still creep into the process of ad serving.
Only use the Publish button in urgent situations. Contact Support for help.
Adhese reports no impressions for a booking if ad delivery is inhibited. One of the following factors might explain why no impressions are being delivered:
- An ad tag must be implemented for the position to deliver an ad. If you do not implement an ad tag for the booked position, a browser can not request an ad.
- If no creative files are uploaded or attached to a booking, there is nothing to display. The Creative status and Traffic status provide more information.
- The delivery of a booking stops when its objective is reached. If a booking needs to deliver only a small number of impressions compared to the booked position's total available volume, the delivery might stop before its end date (as the objective is already achieved).
- When multiple bookings with varying priority levels are booked at the same position, bookings with a higher priority have precedence in delivery. Our forecasting tool indicates whether a booking will deliver or not.
Contact Support if none of the above factors provides a solution.
One of the following reasons might explain why a report does not indicate any clicks:
- If the creative's file is a third-party tag:
- The clickTAG might be wrong. You can test this by checking the URL of the uploaded creative in its live context (see Checking the uploaded creative URL). If the target URL clicks through correctly, the following message will appear:
If the above message does not appear, Adhese won't track clicks because of one of the following reasons:
- The advertiser might not support click tracking by the publisher. The advertiser tracks the clicks on its own server.
- Adhese might not recognize the third party. List of third-party ad servers and marketplaces provides an overview of third-party ad servers Adhese can integrate with.
- The 3rd party code does not contain the click-tracker macro of Adhese (%c).
Contact Support if none of the above reasons provides a solution.
Publishers may have to deal with third-party ad serving if an advertiser wants to manage its campaigns through its own ad server. Thus, each party will have a different ad server in place. Adhese enables the integration with the advertiser's third-party ad server – allowing the ad servers to communicate. The third-party ad server is responsible for the ultimate display of the advertiser's ad.
However, a mismatch between the reports of a publisher and an advertiser is likely to occur. These differences in reporting are better known as (third-party) discrepancies.
The online advertising industry accepts a maximum discrepancy of 5 to 10 percent. If you experience a gap higher than 10%, you should try to justify or minimize the ad count difference. It is important to note that a discrepancy can never be reduced to 0% since there are several reasons you cannot track, such as ad-blockers and browser shutdowns.
Discrepancies can be prevented before a campaign starts. Always be careful when you manually implement a third-party tag and double-check if you have implemented the correct tag and cache buster. It is recommended to compare figures while a campaign is running because fewer steps are available to explain the discrepancy after a campaign has ended.
Examining third-party discrepancies
If you experience a discrepancy, you should check if both reports are pulled against the same ad tags, placements, time zone, and date range. If you run into something conflicting, you may have found the cause. Re-pull the report, and verify if the discrepancy is minimized. If not (or if the reports were already correctly pulled), contact us, and we will assist you in finding the source of the discrepancy.
Here is an overview of some of the most common sources of discrepancies:
- Measurement methodology
There are differences in the measurement methodology of both ad servers. Each ad server counts an impression at a slightly different moment in the ad serving process. Adhese (or the publisher's ad server) counts an impression when the request to serve an ad is made (ad request), while the advertiser may count an impression later on in the process of ad serving: when the ad is actually delivered to the user (ad delivery).
A viewable impression is a metric of ads that were viewable (in part, entirely, or based on other conditional parameters) when served and, therefore, had a true chance to be seen. In this scenario, Adhese will count an impression when the ad is actually in view within the browser window based on the conditional parameters. However, the third-party ad server may count the impression earlier: when the ad is delivered.
- Cachebuster (or timestamp)
If a booking is delivered, its creative file will temporarily be saved to the cache. The cache is the temporary memory of a browser. When the booking is requested a second time, the browser will retrieve its cache's creative file. The third-party ad server won't count the second impression. A cache buster prevents this practice. A cache buster is a unique piece of code that prevents a browser from serving content from its cache. The cache buster forces the browser to fetch a fresh copy for each request. Make sure you implement the correct cache buster to reduce discrepancies caused by caching.
Websites are increasingly equipped with heavy images, custom fonts, and auto-play videos. The entire HTML content of a page may be loaded quickly. Still, if one element of a page has to wait for another element to finish loading and rendering, "heavy" elements (either large in size or complex to render) will increase the total page load time. If the website takes a long time to load into the visitor's browser, the visitor might leave the website (intentionally or not) before the ad is actually delivered. Asynchronous rendering is a solution that allows the browser to render content elements in parallel. Asynchronous rendering reduces latency, or the time elements are waiting for another element to finish and, therefore, it reduces discrepancies due to visitors leaving before the ad request is fulfilled.
- Ad blockers
If an adblocker is in place, the adblocker may prevent third-party ad servers from delivering and displaying ads to someone's browser while the browser still issues an ad request to the Adhese ad server.
- Filtering impressions
Ad servers may have different methods for filtering impressions of non-human traffic, such as bots and spiders.
It occurs that a third party doesn't support ad serving on specific devices, like tablets and smartphones. Because the third party cannot serve an ad in such a situation, the third party won't count an impression. However, the call to Adhese is already made as Adhese supports ad serving on any device, so Adhese logs an impression, and a difference in reporting occurs accordingly.
Third-party tags can contain a piece of code that inhibits the delivery of an ad in specific browsers. For example, tags from DoubleClick that contain the code
abr=!ie won't be shown in Internet Explorer browsers. In this scenario, the ad will be requested, which causes Adhese to count an impression. However, the third-party server won't deliver the ad and, as a result, does not count an impression.