But what causes reporting discrepancies and what can be done to mitigate them?
Display/Banner reporting discrepancies are much more common than video. If video is delivered via VAST than all the different event impression pixels (video start, video quartiles, etc.) for all parties are contained within the VAST and as the Video player displays the video it fires all the pixels for each event at the same time. Although there is less chance for discrepancies with this approach, it still does occur. The main causes for video reporting discrepancies are if the video player has a limit of how many impression pixels they will fire for each event and there are more pixels listed than the limit, or if the pixel URL is not working or the server is unable to record the pixel firing for some reason.
If the advertiser does not provide a method for the publisher to pass in their own tracking URL than the publisher must append their own tracking pixel to the advertiser’s markup code. This is a less than ideal approach and invariably leads to the publisher reporting more impressions. There are several potential reasons this could lead to the publisher reporting more impressions than the advertiser.
First, since the publisher’s pixel is appended to the end of the advertiser’s code and is not combined with it, there is the potential for either the publisher’s pixel to fire only, the advertiser’s pixel to fire only, both pixels to fire or neither pixel to fire. If a publisher is able to pass in their impression URL to the advertiser, than the typical scenarios are either both impressions fire or neither impression fires, but only one of them firing is very unlikely. Since the publisher’s pixel is typically just a 1×1 image tag, it will most likely fire every time. The advertiser’s code may be more complicated decreasing the chance it works every time, so there is a high likelihood that the publisher’s pixel will fire more often, thus resulting in a higher count.
Second, since the publisher’s pixel is appended, it has no ability to know if the advertiser’s code rendered an ad or not. The publisher’s pixel may fire every time, but the advertiser’s code may only show an ad 80% of the time but the publisher’s code would never know that, so the publisher would report 20% more impressions. Attempts have been made to write code to be able to detect if an advertiser renders an ad or not, but it usually is not accurate every time. This capability is more likely within an app compared to mobile web.
There is no foolproof way to prevent reporting discrepancies, but there are a few things that can done to help lessen them. First the publisher should ask the advertiser if they are able to pass in their impression and/or click tracking pixel which can be fired at the same time as the advertiser’s. Second, if the advertiser does not support the publisher passing in their own tracking URL, they should discuss how each tracks and reports impressions and what can be done to try and limit any reporting discrepancies. Lastly, the publisher could consider integrating a third party pixel to use as an alternate source for reporting. This could bring some additional charges and may be easier to implement for video, but if the relationship is crucial and large enough it may be something they want to consider.
Experienced publishers typically expect a certain range of reporting discrepancies and they know their count will be higher, but newer publishers are sometimes surprised by this discrepancy and cannot understand why it is occurring. The current limitations in ad reporting makes it difficult to not have any discrepancies, but publishers and advertisers should both be monitoring and comparing each other’s reporting to ensure any discrepancy stays within acceptable limits. Even if small discrepancies exist, publishers and advertisers can usually establish a successful and long lasting relationship if they communicate clearly how they track and report impressions.