Part 2: Telemetry & Remote Configuration

When we were discussing Ad Monetization Stack Optimizations (link to the actual blog post, so they are connected) we went through a lot of options on how ad stacks could work. When trying out new things it’s important to know what is actually happening, hence telemetry is a crucial feature to have implemented.

Telemetry 

Telemetry in this context means in-app events that track exactly what’s actually happening across your ad monetization flows. There are two sides to telemetry that are worth understanding separately. 

The first is the client ad lifecycle. Events like when you initiated a specific SDK, when a request was fired, an ad loaded and when the exact impression happened give you a map of your mediation stack in action. Once you know what a healthy flow looks like for your setup, you can monitor anything that falls outside it, from broken requests, to failed loads and gaps where impressions should be. It’s also your best friend when you make a change and want to verify you haven’t accidentally broken something. Combined with your broader in-app event data this gives you a genuinely useful picture of the full user journey. 

The second is ad performance data. Impression Level Revenue (ILR) is the main one, with most mediation platforms providing it as part of the integration, cross referencing it against your network's data is a solid way to catch discrepancies. It’s worth knowing that ILR is usually only available for networks participating in bidding. For non-bidding networks, you’re working from historical CPMs instead. While this is less precise, it’s still a useful reference. MDN11 brings all of this data out of the box - you can hook up to any event and send it to your data storage or decide to monitor everything from our dashboards. This way you don’t have to worry about correctly implementing each and every event, debugging it if needed and making sure you can trust this data. We’ve already done that part.

Remote Configuration  

The  problem with hardcoding your ad parameters is that every change from a cooldown timer to a frequency cap or a placement you want to test needs a full development cycle, an app store submission and then a gradual rollout as users update. This means you could be sitting on something that isn’t working for weeks before a fix reaches everyone. 

Remote configuration moves those parameters to a backend system where changes go live immediately. Firebase is the obvious starting point if you want something up and running quickly with a decent dashboard. Building your own gives you more control but does need more upfront investment, which is worth it if the engineering capacity is there. 

What’s actually worth putting behind remote configuration? 

• The things with the most direct impact. 

• Ad frequency: interstitial cooldown timers, frequency caps for interstitials and rewarded video, banner refresh rates.

• Placement management: toggling specific ad positions on or off, enabling or disabling interstitial triggers. 

• If you're running custom mediation logic: waterfall configs and floor prices, enabling or disabling specific networks. 

• Telemetry settings: adjusting how many events you are collecting and where.

• A/B testing parameters: running experiments across user segments while not needing to make a new app release

If seasonality hits, you can adjust in real time. If there’s a new hypothesis to test you don’t need to wait for a release window. It turns monetization from something you react to into something you can actively monitor and optimize With MDN11 you can remotely configure any aspect of your ad mediation stack - from changing placement IDs to switching from one mediation platform to another - it offers you greater freedom and the capability to adapt to new situations on the spot.