Revenue is the lifeblood of a mobile app. Mobile teams either thrive or collapse based on their ability to effectively monetize their apps without sacrificing user experience. If your app runs ads and ad revenue makes up a large chunk of your revenue, ad failures could be a leading cause of revenue loss.
In this blog post, we’ll cover the following:
- How do ad failures cause revenue loss?
- How can ad failures impact performance and stability?
- How can mobile teams track ad failures and why?
- How can mobile teams quickly respond to ad failures?
- What can mobile teams do about bad actor ad SDKs?
How Do Ad Failures Cause Revenue Loss?
Some mobile teams might think: well, I’m paid to simply host the ad in my app, right? And as long as that code is there, I’m getting paid.
Unfortunately, ad vendors are tracking their own metrics, too. If you run ads and those ads aren’t displaying correctly, these ad failures eat into your company’s revenue. If 40% of ads are failing to load correctly, that’s 40% of your potential ad revenue down the drain.
Ad failures can also lead to reduced engagement from your users. If ad calls are slow or take some time to load, your users may become impatient and force quit the app. If your startup times are ballooning as a result of ads, your users may begin abandoning your app and citing the reason that it’s slow or unresponsive.
Churn caused by repeated ad failures will exacerbate your revenue loss. Those hard-earned users are abandoning your app as a result of ad vendors, which has nothing to do with your own app’s technical stability.
How Can Ad Failures Impact Performance and Stability?
There are many moments where ad failures can ruin the user experience.
Startup — If an ad SDK fails or loads slowly, users will abandon the app. Ad SDKs are notorious resource hogs that do not play nice with other SDKs. They compete for network call priority and can block first party calls that your app needs to complete to allow users to interact.
Check out our eBook for tips and tricks on improving your mobile app startup time!
ANRs — Whether it’s collecting or sending attribution data, checking a database for the best ad to serve, downloading heavy assets, or any number of other things, ad loads can freeze the UI and leave your users wondering why your app isn’t responding. You don’t want ANRs to be caused by ad vendors because not only are you delivering a poor user experience while losing revenue, but you are also losing ranking on the Play Store.
Read this post to learn more about Embrace’s approach to solving ANRs.
OOMs — Are you loading too many ads on certain screens? Are they downloading too many heavy assets, or not managing the memory of the webviews efficiently, leading to memory leaks? If your users are seeing OOMs because of ad vendors, you need to know where the system is exceeding memory limits so you can either fix your bad code or contact the ad vendor.
Failed Loading — Ads can and do fail to load, and sometimes for reasons far beyond your control. Perhaps the ad vendors themselves gave you faulty code or their own servers aren’t responding to their network calls. Unfortunately, users don’t make the distinction because they are seeing the blank or glitchy screens on your app, and this does not improve their opinion of your mobile app.
All of these ad failures will negatively impact your revenue. But the first step is to know whether it’s even happening in your app.
How Can Mobile Teams Track Ad Failures and Why?
It’s one thing to know that ad failures might be the cause of revenue leaks — it’s another to know for sure if it’s happening and more importantly: how bad is it?
To track ad failures, your mobile team needs to do the following:
Monitor both device-side and backend network traffic
Ad vendor calls do not go to your backend. If you don’t have a way to audit them, you are trusting a third party with the performance and stability of your mobile app. Put simply, you’re inviting a person into your carefully maintained house then giving them a room and access to all your facilities… while hoping they don’t trash it.
Unfortunately, we often find that ad vendors have their own priorities, and they cannot be trusted to not have outages that break your app. Remember how in the span of one year, Facebook had two outages that completely prevented users from launching apps? Or how with iOS 14’s changes to privacy rules, apps with the Adjust SDK were blocked from releasing new app versions?
You must be able to track what exactly these SDKs are doing in your app. Otherwise, your users might start churning and you won’t know the cause at all.
Track performance issues and how they intersect with ad failures
Users have many expectations when it comes to app performance, and a speedy and responsive app is easily at the top of that list. If you’ve managed your app well, crashes are relatively rare. A slow app is an agonizing experience for users, evidenced by the fact that users uninstall apps that are slow, glitchy, freeze, or have broken UIs.
If your ad loads cause screen freezes for 15 seconds, how long will users stick around? If your startup time balloons because of an outage in an ad vendor’s backend, how quickly do users abandon your app? Are you loading ad SDKs in the way that least affects user experience?
By tracking ad failures and how they impact your app performance, you can better know if the issue is on your end or a result of ad vendors.
Know when your ad vendors are 100% failing
Shine a light on your ad vendors. After all, you’re giving them a room and access to your facilities…don’t you have a right to know everything they’re doing?
Your mobile team should have dashboards that track crashes and performance issues caused directly by ad vendors. Your engineering team should have proactive alerts that let you know when network calls are failing during startup. Track freezes and use stack trace flamegraphs to spot whether the problem is your code or a bad actor ad vendor. Your team can’t fix what they don’t know, so make sure they always know!
How Can Mobile Teams Quickly Respond to Ad Failures?
Your mobile team should be able to swiftly act on this information and get it in front of those who need it. Remember that ad failures are unlikely to be a one-time issue — if it’s not fixed, it is an on-going issue that is causing revenue leaks until it’s fixed. Understanding the impact of these issues will help you prioritize whether to pull team members off other projects and address an issue immediately. This is why having full observability to provide metrics and insight into the causes and impact of your ad failures can better help the mobile team make decisions.
This involves building a proactive alert system, backend kill switches, and dashboards that easily display the most critical metrics to teams that are designated as “need to know.”
First, the proactive alert system. This alert system should be robust enough to pick up on performance issues related to ad failures long before your users start to send in bug reports, if they even do so. Keep in mind that your users do not like ads and generally have no incentive to tell you if your ads are failing to load, so you will only get bug reports if your ads are causing performance issues. Ensuring your proactive alert system will quickly notify you about an outage is critical to navigating social media complaints and minimizing negative reviews that can hurt your business.
Of course, any proactive alert system comes with the potential for noisy alerts. Your team needs the ability to configure the system to minimize these outcomes. This can take the form of having specific slack channels that alerts are sent to, and allowing those teams to customize the thresholds for various failure types. It will be a terrible moment to realize you had an alerting system set up that was turned off because irate team members were constantly being pinged!
Finally, have dashboards designed for the team that cares about these issues. Each team should have their own dashboards that keep track of the metrics they need to know about, including real-time metrics and comparisons over time.
Here are a few guiding questions for dashboard monitoring:
- Are you monetizing different parts of the app in different ways?
- Can the product owner for a feature have dashboards that highlight errors and failures for ads that run in their section of the app?
- Who is responsible for load times?
- Are they tracking the metric over time and responding to regressions?
- Are you A/B testing different ad providers and measuring their impact on key performance and stability metrics?
What Can Mobile Teams Do About Bad Actor Ad SDKs?
Then finally, the possible solutions when you have discovered, tracked, and measured the impact of ad failures causing revenue leaks: an internal adjustment, an external fix, or complete abandonment of the ad SDK entirely.
Internal fix — If you opt for an internal fix, that means your mobile team needs to configure the app to work around the ad failure. This requires visibility into exactly what is breaking and why. This option should only be attractive if it requires relatively little resources to do the fix and the revenue provided by that ad SDK is too important to lose.
External fix — The ad SDK might be broken in ways that you cannot work around, and at this point you will need to communicate the problem with the ad vendor. Let them know about the problem, why it’s happening, and perhaps get them to share information from their side. This will involve a back and forth conversation between you and the vendor to facilitate a solution. Definitely don’t pass up on this chance to talk to them about any other concerns you have about their SDK.
Abandonment — If it’s not an issue that can be easily fixed internally and the ad vendor isn’t being communicative, you might need to abandon the SDK entirely. Perhaps the revenue from fixing it still won’t be worth the resources necessary to get it working. All is not lost though, where one SDK slot opens, another SDK can easily take its place, right?
Ultimately, any issue with ad vendors should be immediately actionable. Your team shouldn’t guess at the source or ignore issues because they don’t have the full picture. Even if it’s temporarily disabling a bad SDK with a backend config, you want to put processes and tooling in place so that when something bad happens, your team has the visibility they need to take action.
The faster you can act, the more you can reduce the impact on your users and business.
For a deeper dive into how Embrace helps best-in-class mobile teams put a stop of costly revenue leaks, check out our on-demand webinar:
How Embrace Helps Mobile Teams
Embrace is a mobile data platform that provides observability, debugging, and proactive alerting for mobile teams. We are a comprehensive solution that fully reproduces every user experience from every single session. Your team gets the data it needs to proactively identify, prioritize, and solve any issue that’s costing you users or revenue.
We're hiring for many different roles! Check out our openings and see if you'd be a good fit for our growing team!
Want to see how Embrace can help your team grow your mobile applications with best-in-class tooling and world-class support? Request a customized demo and see how we help teams set and exceed the KPIs that matter for their business!
Need help improving the performance and stability of your Unity games? Take our SDK for a spin!
Want to learn best practices for scaling your mobile applications? Check out these helpful eBooks!