How SDK and Non-SDK Traffic Differ: A Breakdown of Ad Request Mechanics

TL;DR

• An SDK is a technology layer that an app owner integrates into the product to connect advertising infrastructure: demand sources, formats, monetisation, events, measurement, and the technical exchange with the ad platform.
• SDK and non-SDK traffic differ not only in how the ad request is formed, but also in the logic behind how advertising, demand sources, formats, measurement, and monetisation are connected.
• In a web/browser environment, the ad request is usually formed by the page's code, tags, or server-side integrations, while identification can rely on cookies, first-party data, contextual signals, and other browser-based signals.
• In an app, the request is formed by the integrated SDK, which passes app signals, events, and (where consent is given) advertising identifiers.
• In adtech, SDKs are most commonly associated with in-app traffic because they are embedded directly into mobile applications. However, their real value lies not in the mobile environment itself, but in the standardisation they bring to advertising infrastructure.
• Using an SDK doesn't guarantee a larger volume of data, since it's the app owner who defines the set of signals.

According to DataReportal, browsers account for less than 6% of all the time people spend on their smartphones. Since most smartphone usage takes place inside apps, mobile applications have become one of the primary environments for digital advertising.

Web and in-app advertising differ in two ways: where the ad appears, and how each connects to the advertising infrastructure. On the web, this logic is more often built around the page, tags, and browser-based mechanics. In mobile apps, this connection is handled by the SDK, which acts as the bridge between the application and the ad platform. Let’s dive into what makes it so crucial.

What is an SDK in programmatic advertising

In programmatic, an SDK refers to a universal technology layer that an app owner integrates into their product in order to connect advertising infrastructure inside the app. This layer enables the app to communicate with ad platforms through a standardised set of technical rules. It defines how ad requests are structured, how events such as impressions and clicks are reported, and how different participants in the ecosystem interact.

How ad requests work in programmatic advertising

In open programmatic, requests are usually formed according to the OpenRTB standard. Large platforms also use proprietary extensions and, in some cases, entirely separate protocols. In video advertising, VAST and VPAID come into play as well. In practice, however, most programmatic auctions are still based on OpenRTB.

The difference between scenarios appears at the auction stage. On the web, auctions are triggered by ad tags. In apps, this role is performed by the SDK. Because the two environments provide different levels of access, they expose different types of signals.

Why SDKs are closely associated with in-app advertising

SDKs exist in both app and web environments.

In programmatic, SDKs are most often associated with mobile apps, though the logic of an SDK is broader. For example, the ad tags provided by Google Ad Manager fulfil many of the same functions on the web.

Web and mobile advertising evolved differently

The difference stems from the fact that web and mobile advertising evolved independently. The web has been selling ads since 1994, and for its first fifteen years it had no single protocol at all. Publishers and ad networks had to build integrations manually, often writing custom code for each site. The industry standard OpenRTB only appeared in 2010.

Because ready-made automated rules didn't exist for a long time, web advertising developed along the logic of the traditional press. In markets like Ukraine or Turkey, everything depended on direct relationships for years. Sites sold banners straight to brands in weekly or monthly packages, since technically that was simpler than setting up complex external connections.

Mobile advertising followed a different path. When mobile inventory began to grow rapidly, app owners needed a more scalable approach to monetisation. They needed access to a broader range of demand sources without having to build direct relationships in every market. By that time, the technological landscape had changed dramatically compared with the early 2000s. This is why the mobile ecosystem adopted the SDK model early on.

How auctions differ across web and app environments

With the broader picture in place, let's examine the two approaches separately.

How non-SDK traffic works

Non-SDK traffic is advertising traffic that is formed outside a mobile SDK, in a web/browser environment. This includes ads on regular websites, in the mobile web, and in video players on pages — anywhere the request is assembled by the page's own code.

On the web, the ad request is assembled directly in the user's browser while the page loads. This means that part of the ad system's work runs on someone else's device — one the publisher doesn't control — and the outcome depends on which browser it is and what privacy settings it has.

Because of browser limitations, the web environment has fewer stable signals for identifying users. Cookies remain one such signal, but they're tied to a specific browser and can be blocked by privacy policies, or even by users themselves in the case of iOS. We covered how this works in more detail in a separate article on advertising identifiers.

How SDK traffic works

The process begins inside the app when an ad opportunity becomes available. The SDK detects the event and determines that an ad should be served. It then communicates with the ad platform through a predefined set of functions responsible for different actions:

• requesting a creative for a specific ad slot,
• impression tracking,
• click tracking,
• video completion tracking.

Developers don't need to implement these actions manually. Instead, they rely on predefined functions that provide predictable behaviour. In most large apps, the publisher works with a dozen ad networks at once, so between the SDK and the buyers sits an intermediate layer called mediation. It collects bids from multiple ad networks and allocates each impression to the highest bidder.

User identification deserves separate attention. Apps can use advertising identifiers — notably IDFA (Identifier for Advertisers) on iOS or GAID (Google Advertising ID) on Android — but an SDK on its own doesn't guarantee access to these IDs. When an SDK builds an ad request, the availability of the identifier depends on the operating system, consent mechanics, privacy policies, user settings, and the specific SDK implementation. The technical details of how the library works are described in the Google Mobile Ads SDK documentation.

SDK and non-SDK traffic: key differences

Why an SDK doesn't mean more data

An SDK can pass data along, but it doesn't create it. What actually goes into the request depends on two things:

1. What information the publisher actually has access to (a small app knows far less about a user than a large platform with millions of active people does).
2. How much of that information the publisher chooses to share with advertising platforms. 

Ultimately, publishers decide which signals are exposed through the SDK:

• the device's advertising identifier, or a refusal to share it,
• precise geolocation, or only an approximate region,
• in-app behavioural data, such as which screens the user opened,
• the device's technical parameters and the app version,
• session signals (that is, how recently and how often the person opens the app).

This is why two apps using the same SDK may expose very different amounts of information. One shares almost everything on the list; another limits itself to an identifier and a couple of technical fields.

What advertisers should consider

These technical differences only become meaningful once a campaign goes live. In real campaigns, these technical differences have the greatest impact on three particular areas of work.

User identification

In the browser environment, user identification mostly leans on cookies and standard web signals. The catch is that custom browser settings, cleared caches, and strict privacy policies constantly limit their reach. This makes straightforward tasks far less reliable than they should be. Mobile apps, by contrast, can tap into app-specific signals and advertising IDs, though their availability still hinges on user consent, platform rules, and the actual SDK setup. Ultimately, when enough of these data points do come together, advertisers gain the clarity needed to control ad frequency and manage audience exposure with real precision.

Geotargeting

The accuracy of location detection depends entirely on the type of data in a given environment.

• On the web, geotargeting usually relies on the IP address, so accuracy can be limited to the city or regional level.
• In apps, user consent may allow access to more precise location data — which is especially critical for local ad campaigns.

Fraud

Fraud patterns also vary across environments: on the web, the Achilles' heel is bot networks and spoofed domains, while in apps it's fake installs, device emulators, and manipulation of SDK signals.

This is where DSPs play an important role. Fusify assesses traffic quality across both web and in-app environments on a daily basis. It lets us identify the characteristics of each source and help brands allocate their ad budget effectively.

Which ad formats work best in apps, and why

Certain ad formats have traditionally performed better in mobile apps. Most of these formats are technically available on the web as well, but they generally perform less effectively.

These formats blend naturally into the user experience, appearing right when the user's attention is fully on the screen.

Conclusion

Neither traffic type has an inherent advantage. SDK and non-SDK inventory ultimately compete in the same auction, albeit through different technical paths.

The real value of an SDK lies in the standardisation and efficiency it brings to the exchange process. For a publisher, it offers a simple way to connect internal advertising infrastructure. For a DSP, it opens up standardised access to thousands of apps through a single connection.

That said, advertisers do not need to understand every technical detail themselves. Determining which traffic type best supports a specific objective, setting up the campaign, and keeping an eye on inventory quality is best handled by a specialised partner. Fusify takes the technical side off your hands, so you can focus on your business.

If you're planning a campaign and want to determine which traffic type best aligns with your objectives, we'd be glad to talk through the details with our team.