Share on LinkedIn
Share on XDesktop App Supply is Booming, Transparency Needs to Keep Pace
Ad-supported desktop applications, particularly in gaming and media categories, have rapidly become a meaningful source of supply in the programmatic ecosystem. In aggregate, these environments generate some of the highest volumes of bid requests observed across channels.
That scale makes them impossible to ignore. But it also raises important questions about how this inventory is generated, represented, and evaluated.
Desktop apps are fundamentally different from traditional web environments. They rely on embedded browsers, can run continuously in the background, and often generate ad requests outside of standard user navigation flows. Over the past several months, IAS analyzed a broad set of these applications to better understand how they behave in practice.
What we found was not a single pattern, but a spectrum ranging from highly transparent, standards-aligned implementations to others that introduce ambiguity into how supply is represented. This report focuses on those patterns and outlines what we believe are best practices for this growing channel.
A Hybrid Environment That Blurs App and Web
Desktop applications sit in an unusual position within the ecosystem. While they are clearly non-browser environments, many render ads through embedded Chromium or Edge webviews. This can make their traffic appear, at least superficially, like standard web traffic.
In well structured implementations, this distinction is preserved. Inventory is clearly declared as originating from an application, with device signals that reflect a desktop environment. In other cases, inventory is declared as web even though impressions are primarily generated within the application itself. The associated domain often functions more as a download entry point than a destination users actively visit.
There are also environments where both the desktop app and the website generate traffic under the same domain. In these cases, app-driven and browser-driven impressions become difficult to distinguish, creating ambiguity for buyers trying to understand the true context of the inventory.
This is more than a technical nuance. OpenRTB distinguishes between app and web environments because buyers may price, target, and measure those environments differently. That signal helps them understand the context of the inventory they are buying. When a desktop app inventory is misclassified as web, buyers lose transparency into the environment they are bidding on, creating unnecessary ambiguity in the supply chain.
The path forward is straightforward. Desktop applications should be declared as applications, with signals that accurately reflect their rendering environment. Clarity at this layer benefits both buyers and sellers.
When App Traffic Spans Multiple Domains
One of the more interesting patterns we observed relates to how domains are used within desktop applications.
Because ads are often rendered through webviews, impressions are typically associated with domains. In some cases, this is simple and consistent. A single domain is used across the application, providing a stable signal to the bidstream.
In other cases, however, the picture becomes more complex. We observed implementations where a single application generated ad requests across multiple domains, including one primary domain and four associated secondary domains, each appearing as a standalone web property. In another instance, traffic was distributed across a primary domain, several associated secondary domains, and at least one domain with no apparent association.
While these domains may correspond to real websites, traffic patterns and testing indicate that the associated ad requests are not driven by users actively navigating to those sites. Instead, they are solely generated from within the application itself.
This creates a disconnect. For buyers, domains are a key signal used for brand safety, contextual targeting and supply path optimization. When a single application presents itself as multiple unrelated sites, it becomes difficult to accurately interpret the context of the impression. In some cases, this pattern may resemble domain spoofing and can be flagged as invalid traffic by platforms monitoring for misrepresented supply.
A more transparent approach is to ensure that domain signals reflect actual user experience. If inventory originates from a desktop application, that context should be clear, rather than distributed across domains that may obscure its source.
Ad Rendering Beyond the User’s View
Another area where desktop applications differ from traditional environments is persistence. Unlike a browser tab, an application can continue running even when it is minimized, backgrounded, or when the device is locked.
In many of the apps we reviewed, ad behavior was aligned with user activity. When the application was not visible, ad rendering slowed or stopped. This mirrors expectations from both a user experience and measurement perspective.
However, we also identified cases where ad rendering continued regardless of visibility. Through runtime inspection and code analysis, we observed implementations where ads were refreshed even when:
In one such implementation, this behavior was not incidental, it was explicitly enforced in code by disabling Chromium’s built-in background throttling:
This logic was applied selectively to webviews responsible for loading ad content, ensuring that timers and refresh cycles continued uninterrupted even when the user could not see the ads.
From a measurement standpoint, this raises clear concerns. Ad delivery should be tied to user visibility. When impressions are generated outside of that context, it challenges the integrity of the supply and complicates performance evaluation. From the buyer’s standpoint, it also means paying for impressions that may never have had a meaningful chance to be seen.
Making an App Look Like a Browser
Signal integrity is another area where we observed meaningful variation.
Desktop applications using embedded browsers naturally inherit User-Agent strings and Client Hints. In many cases, these include identifiable markers that allow platforms to distinguish app-originated traffic from standard browser traffic. This is a healthy and transparent approach.
In other cases, however, we observed active modification of these signals. Specifically, some implementations intercept outbound requests and rewrite headers to closely mimic mainstream browser environments.
For example, we identified logic that conditionally rewrites Client Hint headers to align with standard Chrome values:
The effect of this approach is to make traffic originating from a desktop application appear indistinguishable from traffic generated by a typical Chrome browser.
While this may improve compatibility in some cases, it also removes an important layer of transparency. Accurate device and browser signals are foundational to fraud detection, measurement, and targeting. When those signals are altered to mask the true environment, it becomes more difficult for downstream systems to interpret the traffic correctly.
Building Toward a More Transparent Standard
Desktop applications represent a valuable and growing segment of the advertising ecosystem. They offer highly engaged users, persistent environments, and new opportunities for monetization.
What our analysis shows, however, is that implementation choices matter.
Across the applications we reviewed, the highest-quality environments shared a consistent set of characteristics: they clearly declared themselves as applications, used domain signals that aligned with real user context, tied ad rendering to visibility, and preserved the integrity of device and browser signals.
These are not new principles. They are extensions of long-standing expectations across web and mobile. But as desktop apps continue to scale, adhering to these principles will be critical to ensuring that this supply is trusted, understood, and valued appropriately.
The opportunity is clear. With the right standards in place, desktop applications can continue to grow as a high-quality, transparent channel within the programmatic ecosystem.
