In our most recent report, The App Environment Verification Blind Spot, our team analyzed how inventory in app platforms is identified and verified across mobile and connected TV.
Our goal was pretty straightforward: we wanted to follow what’s being declared in the bidstream back to something buyers can independently confirm. What we found is that, in many cases, that chain simply doesn’t hold.
The IAB laid out what app identification and verification should look like back in 2019. Those requirements just haven’t been consistently enforced at onboarding.
Building on that report, I wanted to sketch out my wishlist for what platforms should require during onboarding, a baseline, if you will, that could start to close the gap between declaration and verification across mobile and CTV.
The gap between declaration and verification
One number from the report helps frame the problem I’m describing:
849,617 app-instances in our dataset point to low-trust hosting infrastructure.
At a glance, these apps look compliant: they’ve got developer URLs and privacy policies. They also appear to meet the requirements most systems check for.
But following those links tells a different story:
- 269,186 apps use Blogspot as their developer identity URL
- 125,198 Android apps list a Google Doc as their privacy policy
- 82,966 apps point to app-ads-txt.com or similar services
- 37,926 of those use those services as their developer URL
Each of these resolves and checks the right box, but none of them establish ownership or accountability. The signal is there. It just doesn’t connect to anything verifiable.
My app onboarding wishlist
What should app platforms require upfront to prevent this? Thinking about this question, I’ve come up with four small, nonexhaustive changes that I think would shift the system toward signals that can actually be verified.
1. Use the most specific identifier available
A lot of ambiguity is the result of how apps are identified in the bidstream. Some identifiers overlap across ecosystems. For example, iOS bundle IDs can intersect with Android and Amazon environments, and Roku’s smaller integer IDs can overlap with LG.
Better options already exist. Apple’s Track ID and Roku’s store ID (the one embedded in the store URL) are both stable and unique. Using these consistently would remove ambiguity at the start of the chain.
2. Ensure app store URLs resolve without modification
If a bid request includes an app store URL, it should work as-is.
Unfortunately, in practice, we see URLs that don’t resolve, point to incomplete listings, or require manual fixes to load correctly. When that happens, the verification step is skipped and the system defaults to whatever signals are already available.
The store page is the one place where buyers should be able to independently confirm what an app is and who operates it. If that link fails, everything else is noise.
3. Pass region and language context when required
Some apps are only accessible in specific regions, and their store pages reflect that.
Without the right parameters, a valid app store URL can fail depending on where the request originates. Put simply, a buyer in one market may not be able to load a listing that exists in another.
Including region and language context alongside the URL would ensure that the page is consistently accessible for verification by anyone, anywhere.
4. Require first-party domains for developer identity
The most consistent issue in our report’s dataset wasn’t missing fields, but what those fields were pointing to.
Right now, a developer can anchor their identity to:
- a Blogspot page
- a Google Doc
- a generic hosting service
- or a domain that mimics ads.txt infrastructure
While all technically resolve, none establish durable ownership.
A first-party domain, on the other hand, introduces continuity by creating a surface where identity can be observed over time. That persistence becomes a signal in itself.
More than half of the low-trust URLs we analyzed come from free hosting platforms. Requiring developers to use infrastructure they control would raise the baseline without introducing additional complexity.
Observing (and closing) the gap
None of these requirements are especially complicated. They don’t introduce new standards or new systems. Instead, they’re aimed at raising the baseline for what counts as a valid signal at the point where supply enters the ecosystem.
If app platforms were to enforce them consistently, I truly believe that we’d wind up with fewer ambiguous identifiers, fewer broken verification paths, and far fewer cases where a signal exists without anything concrete behind it. The gap between what sellers declare and what buyers can confirm would narrow significantly in ways that would be immediately visible in the data.
That gap is precisely what we measured in The App Environment Verification Blind Spot. If you want to see how these dynamics are showing up across platforms, including where verification breaks down and what fills the space when it does, download the full report today.
What’s more is that DeepSee.io now surfaces app-level compliance signals for mobile and CTV apps, including ads.txt status, developer URL trust, and privacy policy infrastructure, using the same signal structure applied on the web. You can check out how it works in the portal, contact us for a demo and free trial.
