General troubleshooting

During the monitoring of campaign delivery, it is possible to encounter some unusual conflicts. Despite Adhese's best efforts to optimise delivery and ensure everything runs smoothly, errors can still occur during ad serving.

Ad delivery

Adhese does not report impressions for a booking if ad delivery is inhibited. There are several reasons why no impressions are being delivered, including:

• 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, nothing is displayed. The Creative status and Traffic status provide more information.
• Suppose a booking requires only a small number of impressions compared to the booked position's total available volume. In that case, the delivery may be completed before the end date (as the objective has already been achieved).
• If multiple bookings with varying priority levels are made at the same position, bookings with a higher priority will be delivered first. Our forecasting tool will indicate whether a booking will be delivered or not.

Contact Support if none of the above factors provides a solution.

Clicks

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 may be incorrect. To test this, check 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 will not 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.

Third-party discrepancies

Publishers may have to deal with third-party ad serving if an advertiser wants to manage its campaigns through its own ad server. Consequently, 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, discrepancies between a publisher's and an advertiser's reports are likely to occur. These differences in reporting are better known as third-party discrepancies.

The online advertising industry has a maximum discrepancy of 5 to 10 percent. If you experience a gap higher than 10%, you should justify or minimise 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. When manually implementing a third-party tag, it is important to exercise caution and verify that the correct tag and cache buster have been implemented. It is advisable to compare figures while a campaign is running, as fewer steps are available to explain discrepancies after a campaign has ended.

Examining third-party discrepancies

If you experience a discrepancy, 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 identified the root cause. Re-run the report and verify that the discrepancy has been resolved. If not (or if the reports were already generated correctly), 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:

1. Measurement methodology
   The measurement methodology of both ad servers differs. 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) and the ad has been delivered to the page (ad delivery).
2. Viewability
   A viewable impression is a metric for ads that were viewable (in part, entirely, or based on other conditional parameters) when served and, therefore, had a true chance of being seen. In this scenario, Adhese will count a viewable 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.
3. 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. Ensure you implement the correct cache buster to reduce discrepancies caused by caching.
4. Latency
   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 page element has to wait for another aspect 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.
5. 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.
6. Filtering impressions
   Ad servers, such as bots and spiders, may have different methods for filtering impressions of non-human traffic.
7. Device types
   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 has already been made as Adhese supports ad serving on any device, so Adhese logs an impression, and a difference in reporting occurs accordingly.
8. Browser exclusion 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 will cause Adhese to count the impression. However, the third-party server won't deliver the ad and, as a result, it will not count as an impression.

Please note that the information on Adhese's measurement methodology assumes a default setup. Depinding on the impression tracker used, the amount of measured impressions will differ.

Adhese-specific error codes

In some cases, a request to Adhese endpoints may result in an error and a custom error code will be returned. Here is the list of possible codes and an explanation.