The numbers coming out of Q3 are striking. Mobile RTB volumes grew 43 percent quarter-over-quarter, according to data from multiple exchange partners, and every major DSP is reporting mobile as a growing percentage of total impression volume. The budget shift is real. What’s less clear — and what trading desks are wrestling with right now — is whether mobile programmatic is actually delivering what buyers think they’re buying.

The central problem is identity. Desktop RTB is built on the browser cookie: a persistent identifier that, with all its limitations, enables audience matching, frequency capping, cross-site behavioral targeting, and attribution. On mobile, that infrastructure largely doesn’t exist. The mobile web browser cookie is unreliable. The in-app environment has no cookie layer. What replaces it is a patchwork of device identifiers, IP-based inferences, and contextual signals that does not yet add up to a coherent audience-targeting system.

Buyers who are transferring desktop RTB expectations directly to mobile campaigns are either getting misled by vendors or misleading themselves.

When a desktop browser loads a web page, the browser maintains a persistent cookie store. An ad exchange can set a cookie on the user’s browser during an ad impression, read it on the next impression, and build a cross-site behavioral profile over time. A data provider like BlueKai can sync its own cookie to the exchange’s cookie pool. A publisher’s first-party cookie can be matched against a buyer’s CRM data file. This is the infrastructure that makes audience targeting work.

Mobile Safari, the dominant mobile browser on iOS devices, began blocking third-party cookies in its default configuration years ago. This is not a minor limitation — it means the core cookie-sync infrastructure that enables audience segment matching and frequency capping does not function for mobile web impressions served through Safari. Android’s native browser is more permissive, but the market share reality is that a significant portion of mobile web traffic is iOS, which means a significant portion of mobile web impressions cannot be reliably targeted with behavioral audience data.

In-app inventory, which is growing rapidly as users spend more time in apps than in mobile browsers, has no cookie layer at all. App environments are sandboxed; cookies set in a mobile browser are not accessible to an app, and vice versa. The entire cookie-sync infrastructure that underpins desktop RTB audience targeting is irrelevant for in-app impressions.

Apple’s developer documentation on iOS identifier policies outlines the rules around IDFA — the Identifier for Advertisers — which is the mechanism Apple has provided as an alternative to cookies for in-app advertising. IDFA is a device-level identifier that can be used for ad targeting and attribution when users have not opted out. But IDFA-based targeting requires a new data infrastructure: DSPs and DMPs must build IDFA-based audience pools, and the match rates against existing cookie-based audience segments are limited right now because the two identifier systems don’t connect cleanly.

Device ID Fragmentation and What It Means for Targeting

Even accepting that device IDs are the path forward for mobile in-app targeting, the current landscape is fragmented in ways that limit practical utility. iOS uses IDFA. Android uses Google Advertising ID (GAID), which launched only in August of this year. Older Android devices may expose ANDROID_ID or the device hardware identifier instead, both of which carry privacy implications and are inconsistently supported by ad networks.

Cross-device identity is a genuine problem. A user who browses on an iPhone in the morning and continues on a desktop in the afternoon is, from the perspective of most ad systems, two different users. Frequency capping fails across devices. Attribution that requires seeing both an ad exposure and a conversion event cannot connect mobile exposure to desktop conversion. Retargeting lists built from desktop cookie data cannot reach those same users on mobile.

The industry knows this is a problem and is working on solutions. Probabilistic device graphs — systems that infer device associations based on IP address proximity, behavioral patterns, and timing signals — are the current best answer. They work tolerably at scale but have meaningful error rates and don’t provide the individual-level precision that cookie matching offers in favorable conditions.

In-App vs Mobile Web: A Critical Distinction Buyers Are Blurring

The in-app and mobile web inventory environments are functionally different, and buyers who treat them identically are making a category error that undermines campaign performance.

Mobile web impressions — inventory that appears when a user browses a website in a mobile browser — can run VAST video and standard display formats. They face the cookie limitations described above, but they operate within browser standards and the creative compatibility issues are relatively manageable. Mobile web inventory is available through standard exchange connections and runs through the same programmatic stack as desktop display, with adjustments for creative format and the reduced targeting data available.

In-app inventory is a different channel. Creative serves through the app’s ad network SDK, not a browser. Standard VAST-based video and HTML5 display can work, but the implementation path runs through app developer SDK integrations — MoPub, InMobi, Millennial Media are major mobile ad network providers with significant in-app supply. The DSP connectivity to in-app supply is less mature than to mobile web or desktop supply. Targeting parameters in in-app bid requests often contain less data than desktop bid requests — the audience data enrichment that happens at the exchange level on desktop doesn’t always happen in the in-app SDK pipeline.

For brand safety and measurement, in-app is currently more opaque. Third-party verification tags have compatibility issues in some SDK environments. Click attribution in-app requires SDK-level integration for accurate measurement. Buyers setting up mobile programmatic campaigns without distinguishing in-app and mobile web targeting are getting blended performance metrics that mask very different dynamics underneath.

What Mobile Targeting Actually Looks Like Without Reliable Identifiers

Given all of the above, what does competent mobile programmatic targeting actually look like right now? The answer is a combination of approaches that each solve part of the problem.

Device and OS targeting is reliable. You can target iOS vs Android users, target specific device generations as proxies for income demographics (targeting users on current-generation iPhones skews higher-income), and set separate bid rules and creative for different device environments.

Contextual targeting works in mobile as well as it works anywhere — app category targeting lets you reach users in gaming apps, news apps, finance apps, or other content environments that proxy for audience interests. Site-list targeting (in mobile web) against curated publisher environments provides placement quality controls.

Geo targeting is more precise in mobile than desktop, because mobile devices report location at high accuracy levels when location permissions are granted by the user. Geo-fencing campaigns around retail locations, competitors’ stores, or event venues are a genuine mobile-specific capability that desktop RTB can’t match.

Time-of-day targeting is more meaningful in mobile because mobile usage patterns differ significantly by daypart. Commute hours, lunch, and evening show different app usage and engagement patterns than desktop browsing.

The IAB Mobile Marketing Center of Excellence has published mobile-specific measurement guidelines that are worth reviewing for teams standardizing their mobile campaign metrics, even though many of the standards are still in development.

Where This Channel Goes From Here

The mobile programmatic market will not stay in its current state for long. Google’s advertising ID standardizes in-app targeting on Android. The IDFA ecosystem on iOS will develop richer audience data pools as DSPs invest in mobile-specific data partnerships. Cross-device matching will improve as probabilistic graph technology matures and as logged-in environments (Google, Facebook, Twitter) offer deterministic identity signals to buyers on their platforms.

The teams building mobile programmatic expertise now — developing the testing discipline, the creative formats, the targeting frameworks appropriate for a cookieless environment — will have a genuine advantage as the channel matures. The teams waiting for mobile to look more like desktop before taking it seriously will find that the buying patterns and inventory relationships have already been established by the time they arrive.

Mobile RTB’s 43% quarterly growth is not a bubble. It reflects a real shift in where users are spending time. The channel’s current limitations are real but solvable. Build toward them.

Frequently Asked Questions

Why doesn’t the browser cookie work for mobile targeting? Mobile Safari, used on all Apple iOS devices, blocks third-party cookies by default. This prevents the cookie-sync infrastructure that desktop RTB relies on for audience matching and frequency capping. In-app environments have no browser cookie layer at all, as apps are sandboxed from browser cookie stores.

What is IDFA and how does it compare to cookies for advertising purposes? IDFA (Identifier for Advertisers) is Apple’s device-level identifier for ad targeting and attribution in iOS apps. Unlike a cookie, it is a single persistent identifier per device (until reset by the user), which makes cross-app frequency capping more reliable than cross-site cookie syncing. However, the data ecosystem built around IDFA is still nascent compared to the mature cookie-based infrastructure.

How should buyers distinguish between in-app and mobile web campaigns? Treat them as separate channels with separate targeting strategies, creative specs, and measurement approaches. Mobile web can use modified desktop programmatic approaches with contextual and device targeting compensating for reduced cookie coverage. In-app requires SDK-connected supply sources, device ID-based targeting, and separate brand safety verification approaches. Blending them in a single campaign makes meaningful optimization impossible.

What is the current state of cross-device attribution for mobile campaigns? Cross-device attribution — connecting a mobile ad exposure to a desktop conversion or vice versa — is a significant unsolved problem for most buyers. Probabilistic device graph vendors can provide estimated cross-device connection, but error rates are meaningful. Buyers should set realistic expectations about attribution completeness for mobile campaigns and build KPI frameworks that account for mobile-assisted conversions rather than requiring direct attribution.