Identifying and fixing issues holding your render rate back
Render rates play a critical role in maximizing ad revenue. For demand partners, ad opportunities that don’t convert into impressions can signal poor profitability, and result in breaking relationships with demand partners/buyers that have the potential to be fruitful. On the other hand, achieving high render rates encourages demand partners to spend more campaign dollars because they are confident their campaigns will convert to billable impressions. Thus, achieving optimal render rates are pivotal to a healthy RTB ecosystem.
At TechByNimbus, we integrate with both performance-based and brand-based demand. Performance-based demand refers to ad demand that’s driven by user metrics like ad clickthrough, the duration of the ad being 100% visible to the user, the percentage of a video ad that was played for the user, etc. Brand-based demand is focused on brand-image and the quality of ad creative that’s shown to a user.
In this post, I’ll share how to identify render rate imbalances, how to correct them, and how to optimize ad rendering for your app’s user interface.
Terms to know
Before we dive in, it’s important to understand a few terms:
Ad auction: An auction where the ad exchange (e.g., Nimbus) requests an ad from all demand partners simultaneously where the highest bidder wins the ad impression.
Rendering: When an ad “renders,” it means it has been successfully served to its designated unit.
Impression: An “impression” is when an ad renders correctly on a user’s device and the user sees it.
Render rate: The percentage of impressions served out of the total number of auctions won (an auction is ‘won’ when a demand partner wins a bid for an ad impression).
Identifying Imbalances that Signal Render Rate Deficiencies
Nimbus expects ads to be requested only when the app intends to show them. The ads should not be pre-cached, as pre-caching could result in issues like missed ad impressions or ad impression pixels becoming invalid after a given time. I will talk more about these issues below as these can affect render rates negatively.
Render rates should be fairly consistent over time, and a significant fluctuation can indicate an issue. Render rates change for various reasons — from technical issues to user behaviors. The first step to correcting an imbalance is identifying it. Without the ability to track and see the metrics listed above, you may never know there’s an issue in the first place. We keep ourselves, and our partners in the know via the Nimbus dashboard, which makes all the relevant data accessible, and viewable across static, video, and native ads. When identifying imbalances, we keep a close eye on two indicators:
Render Rates Below 60%
Render rates vary for numerous reasons. Generally speaking, a healthy render rate for video ads should be anywhere between 60-80% and slightly higher for static ads between 70-100%. These numbers will be higher for blocking interstitial ads and sticky banner ads. For example, if the ad unit resides in a scrolling list, there will be some user drop-off before the ad is shown. However, if the ad unit is a rewarded video which forces the user to wait until the ad is visible, or a banner ad that is always visible, the render rates should be significantly higher.
Keeping an eye on key metrics in the Nimbus Dashboard
Impression Discrepancies Above 10%
An impression discrepancy is when the number of impressions reported by the ad exchange is significantly different from the number reported by the demand partner (SSP/DSP). For example, a static ad from a specific demand partner might trigger Nimbus’ HTTPS trackers but not the demand’s HTTPS trackers. In this case, the render rate reported on the Nimbus dashboard will continue to look normal but the impression discrepancy would be high. The first step in troubleshooting is to investigate ad rendering. The publisher can ask for an ad creative from that demand partner and try to render it within their app. If the ad creative renders successfully, then the next step is reaching out to the demand partner for further troubleshooting. It’s important to run these discrepancy reports regularly as impression discrepancies result in missed revenue.
What to do once you've identified an imbalance
Now that you’ve identified an imbalance by observing your render rate or impression discrepancies, how do you fix the issue? As mentioned above, ad rendering can fail for a variety of reasons — but there are a few usual suspects responsible a majority of the time. Below I’ll walk through some of the most common reasons ads fail to render, and what you can do to avoid these pitfalls.
Invalid html / vast
All the `static` ads sent back by Nimbus include HTML markup. Sometimes there is invalid HTML markup coming back from demand that includes multiple or missing `<html>` tags. This can happen when demand uses HTML tags that the mobile browser doesn’t understand.
For example, an ad with invalid HTML / Javascript can be debugged by opening the web inspector for mobile Safari. There are some ads that have insecure links [“HTTP” instead of “HTTPS”] which will be blocked unless the publisher has explicitly allowed insecure traffic in web content on their app [https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity)]. Any JS errors will also show up here:
These insecure links could sometimes only affect parts of the ad and not the impression pixel. In other cases, these could only affect the impression pixel even when the ad creative loads successfully which would still result in an “impression discrepancy.” There are also cases where some of the HTTP requests from the ad could result in a non-successful HTTP code.
All the video ads sent back by Nimbus include VAST / XML markup. There could be arbitrary tags that the specific VAST version doesn’t understand. For example, the video ad could contain VAST 3 markup and the client might not have the ability to parse VAST 3 (for example, if the client is handling ad rendering without our Nimbus SDK).
In these cases, the best approach is to isolate ads with specific identifiers (e.g. creative IDs and campaign IDs) that are causing the impression discrepancies and requesting examples of ad markup from the demand partner for troubleshooting. Mostly, the answer is to stop these specific campaigns until this is mitigated.
Slow CDNs
Slow CDNs are also something that needs to be looked at on the demand side. The Nimbus dashboard offers visibility into render rates and discrepancy numbers per demand which could alert the publisher about these issues. The next step is to talk to your demand partner and ask them for ad markup that you can test to see if any issues arise.
Inaccurate timing for requesting/loading an ad
A publisher should also look at user behavior specific to their app to come up with ideal locations for an ad and the timing of the ad request to ensure most requests convert into valid impressions. The simplest case is when an app shows a blocking ad, the ad request, and rendering take place at roughly the same time. For an app that has a scrollable list, requesting an ad too early might result in a missed render if the user quits the app before getting to the ad or doesn’t scroll far enough in that list where the ad is located.
Most ads have “pixel trackers” which are URLs embedded within the markup that is triggered when an ad renders successfully. Some of these pixel trackers expire after a certain time set by the demand partner after which the requests sent to these URLs stop counting towards a valid impression. There may be a case where these pixel trackers become invalid by the time an ad is rendered if it is requested too soon. In this case, the Nimbus dashboard will continue to report optimal render rates (which are measured by the Nimbus trackers) but there will be a large discrepancy in impression count between Nimbus’ and demand’s data..
There are quite a few optimizations that can be done by the publisher to maximize ad impressions. An ad that was requested should ideally be shown to the user every time. Requesting an ad and not showing it is one of the biggest contributors to missed impressions and therefore, lower render rates. There could also be duplicate ad requests made but only some of those ads were shown which would also result in missed ad impressions. If the ad is requested too late, that is, if it’s ‘not loaded’ or ‘not ready’ when the user gets to it and potentially moves on in their session, that’s an ad that was not seen by the user and therefore results in a missed impression. All these missed ad opportunities result in an increased amount of non-monetizable ad requests which affects the overall performance negatively.
To summarize, a publisher needs to ensure the following:
An ad is not requested when it’s not intended to be shown.
The ad is not requested/loaded too far ahead of when it’s going to be displayed (this timing differs depending on the App’s UX).
The ad is not loaded too late and is, therefore ‘not ready’ when the user gets to it.
Only one ad is requested and shown to the user before another ad is requested. The exception to this case would be when a publisher has an interstitial ad and a banner ad on the same screen and they intend to request both interstitial and banner ads.
Do not always request another ad when the user goes back to a screen, although this may be intentional depending on the publisher’s use case. For example, if an app’s UX is such that a user sees an ad and swipes past it, but returns to the same “screen” a few moments later, a different ad may be shown.
Putting it all together
At TechByNimbus, our team works diligently to ensure there are no demand-side issues (e.g. reporting issues, campaigns with creative that isn’t rendering properly). Ad creative / rendering issues typically come up when a new ad campaign or ad creative that goes live, a new demand partner is enabled for a publisher, or when a publisher releases a new version of their mobile app. Whenever we spot discrepancies or render rate issues, we perform an internal investigation and narrow it down to a creative or a specific demand partner.
Our next step is ensuring that our Nimbus SDK is able to render that specific creative by following the steps mentioned above. We report our findings either to the demand partner if it’s an issue with the ad creative, or the publisher if it’s a rendering issue. Additionally, we’re continuously working with our publishers to further improve and optimize render rates.
To summarize, to ensure you’re achieving your optimal render rate, you should:
Continuously monitor ad render rates on the Nimbus dashboard (or if you’re not using Nimbus, then wherever you track your metrics) to make sure that they are relatively stable and don’t dip below the percentages specified above.
Request an ad only when it is intended to be shown to a user. Avoid performing an ad request too soon to avoid a missed ad impression.
The ad should be fully visible to the user when it is presented or shown.
Learn more about render rate.
