The Impression Discrepancy: What it is, why you should care, and how you can fix it.
While it makes over $300B dollars a year, making money from mobile advertising is still very hard. During our time helping mobile app developers make money from their apps we’ve come across this nasty little surprise many times: the ad serving impression discrepancy. We’ve tried to put down the basics to help you understand why it’s important, how it’s caused and— most importantly—how to fix it.
What is an serving impression discrepancy?
An ad impression discrepancy—also called an ad serving discrepancy– is when there is a difference in the number of impressions reported by the different ad servers that are fulfilling an ad request. In short, it’s a disagreement between two parties on the impressions shown to end-users. These impressions are counted by events fired when the the ad is loaded– called a “pixel”– and both the ad server and the network have their own pixels loaded and fired from each advertisement.
The most typical situation is when a mediation platform (or ad server) and the ad network/DSP report different numbers of impressions. For example, you may see MoPub report 1000 impressions for an Admob line item, but Admob reports 1100 impressions. The ad industry benchmark for discrepancies is +/- 10%.
I always found it funny that the advertising industry had an “acceptable” industry standard for an impression discrepancy – so much so that the IAB writes white-papers about it. Imagine a discrepancy from your bank: “Yes, you transferred $100 yesterday but we only received $90.”
I don’t know if many would find that “acceptable.”
Why you should care
It’s important to stay on top of potential an ad impression discrepancy. While the numbers won’t always line up perfectly, a discrepancy in the impressions being counted will impact revenue – either you’re missing out on additional revenue, or over-counting revenue that could be clawed back. When significant discrepancies of 10% of more do arise, we recommend pausing the demand until the problem can be addressed.
Why is this so hard? When you dive down into ad tech it quickly becomes a very challenging technology– and for good reason. Think about it: the recipients (the phones) are highly distributed; running on a variety of operating systems; constantly changing connection types; and running on third-party integrated and developed technology (apps). Then two completely different companies– running different technologies (ad mediators and networks)– need to agree on how to count, fire, track and reconcile events. It’s actually surprising when the counts are less than 10%!
What causes an impression discrepancy?
We’ve seen several common causes of an impression discrepancy in apps. The most common causes we see are:
Photo by Fahrul Razi on Unsplash
1. Integration issues: there is an issue or problem with the integration of the network SDK or the mediation SDK integration.
Example: the mediation adapter isn’t collecting or transferring data/serving-control to or from the network SDK correctly.
Photo by Tingey Injury Law Firm on Unsplash
2. Ad Rendering /Policy Issues: These take a few different forms, but the most common reasons include the impression not rendering correctly, or the impression refreshing too quickly. When an impression doesn’t render correctly, it’s usually because there is another element of the app canvas that is interfering with it, such as rendering over content, or at the extreme edge where the screen curvature cuts the ad off. The minimum refresh rate may vary from network to network, but the typical minimum refresh rate is usually 30 seconds for banners.
Sidebar: ad-networks won’t pay for impressions they judge as “incomplete.” For instance in our testing AdMob won’t count an impression that was shown to the user for less than 2 seconds.
Further reading on AdMob policies.
Photo by Mike van den Bos on Unsplash
3. Pre-caching: Some types of ad formats– like interstitials– can be pre-cached, while banners and MRECs (typically) aren’t. Ad impressions may be miscounted by the network but they aren’t actually displayed due to caching. This happens especially with JavaScript tags, SDKs have more control over when to send out an ad request & the pixels that fire to “count” the impression.
Also: Pre-caching is also a common reason for fill-rate issues. Remember when you’re looking at fill rates on pre-cached ads: a request may not lead to an impression because the pre-cached ad never was called to be shown!
Photo by Agê Barros on Unsplash
4. Latency: An entire article could be written about the challenges with latency, but in specific reference to ad serving discrepancies, latency can cause ad requests or impressions to be lost. For instance if an ad request took longer than 100ms to process, the mediator may move onto the serving option. The network may eventually return an ad and erroneously count it as an impression.
Photo by Pankaj Patel on Unsplash
5. JavaScript Tags: in general, Java Script Tags on mobile app inventory aren’t as robust as SDK integrations when it comes to counting impressions correctly. We’ve seen their ability to fire and receive pixels periodically degrade and cause to discrepancies. Comment: as technology improves, we see these counting mechanisms change and adapt. While this will (eventually) mean better counts, it can mean there are times it gets worse – it’s not uncommon for a “working” integration to break as the servers go through updates.
How to find the cause: Data Indicators
The best way to find impression discrepancies is through analysis of your ad serving data. Two different types of ad serving data are helpful to understand if there are discrepancies.
Compare impression counts: Compare the impression data of the mediator and ad network, looking by each ad format that you are running (banners, natives, interstitials, etc). A similar discrepancy across all units can mean a different type of problem than one limited to a single type of ad unit.
Ad Network yields: Some networks provide additional demand statistics, such as the number of bid rate and win rate of the underlying demand. These statistics are commonly shared for bidding demand. In addition, some networks like Admob share the rate of ads sent to the app vs ads rendered (shown vs. delivered).
The ad serving data should be reviewed regularly, as well as each time an SDK is updated, to ensure no discrepancies suddenly arise.
Staying on top of potential discrepancies requires constantly monitoring your ad serving data for unexpected changes. When any signs of a discrepancy do arise, the demand should be paused until the integrations can be investigated.
How to fix the problem:
As there are a variety of challenges that can cause a serving discrepancy, there are an equal (or greater) number of fixes. While this won’t be an exhaustive list, we do aim to give you the steps we usually recommend to our customers:
1. Start by eliminating causes: it’s not always easily apparent but with some basic deduction you should be able to make some headway:
Single-network discrepancies: are usually related to a single network integration issue, or a network ad policy issue. For instance, if only AdMob is showing a discrepancy, it might be some ads aren’t showing for more than 2s, causing them to not count those impressions.
All networks have large discrepancies: this is usually an indication of a technology challenge, e.g. the mediation platform isn’t integrated correctly.
Technology or policy: The most straight-forward method of determining technology vs policy issues is to aim a house ad with 100% fill at the top of your waterfall. 100% ads are being counted? Then it’s like a policy problem, someone isn’t determining your ad as “countable.” Still have issues? Likely technology, since that ad should always be shown.
2. Triangulate the problem with data: Get all sources of data you can, this can help you isolate problems. The best example here is Admob, they graciously provide a metric called Matched Requests. This is the number of impressions they are trying to fill. Low Match Rate (matched requests vs impressions counted)? They aren’t seeing these impressions shown to users. Note: We’re working on some new measurement tools to help match analytics data with ad data – if you’re interested in learning more, let us know!
3. Investigate manually: here’s where it can get painful. You can isolate a network to a single test ad unit and manually request and display ads. There are a few way to do this, we recommend a line item pointed at a test ad unit. Wait for the network to update numbers and validate against your manual counts. Note: this is better done on a device, as an emulator might cause impression count problems from a legitimacy issue.
4. Investigate technically: Once you’ve identified the issue as a potential technical issue with the app displaying the ads, you’ll need someone to re-evaluate the integration to ensure the correct ad serving and rendering logic is being used.
5. Start from scratch (or call in an expert): Not kidding, sometimes the integration is old, the code is spaghetti and the team is new. Sometimes picking up the newest SDKs and starting from scratch is your best bet. Note – especially with tags, we’ve seen different mediation SDK versions need separate tags. Remember measurement is an important fraud metric, so as measurement technologies are updated, the tags need to be sure they’re rendering up to measurement code.
Conclusion:
An impression discrepancy can range from annoying to disastrous to revenue and is often very frustrating to find. Every situation is unique but we hope this gives you some guidance to help track down and eliminate challenges with your mobile app.
If you have any questions, feel free to reach out. AdLibertas tools can be very effective in diagnosing impression discrepancies.