How to improve app monetization (improved ad targeting)

Monetizing apps by adding ads is a popular way for creators to fund their efforts. Consumers are more likely to install an app which doesn’t have an up-front fee, so in-app advertising is a natural fit for both parties.

However, as apps don’t function the same way as browsers do, the default exchange between the device and the ad server sometimes contains very little in the way of useful device identifying information.

Let’s take a brief look at the advertising ecosystem and how it interacts with devices, and how app creators can improve their ad targeting to increase their returns.

Real-Time Bidding (RTB)

The RTB spec as defined by the IAB provides a framework for Real Time Bidding (RTB) by which advertisers, publishers, exchanges, ad platforms and consumers interact.

The IAB state “The mission of the OpenRTB project is to spur greater growth in the RTB marketplace by providing open industry standards for communication between buyers of advertising and sellers of publisher inventory.“

As part of the RTB spec, there are lists of bid request object specifications. An exchange or other supply source sends a bid request to bidders. Bid requests contain the top-level bid request object (BidRequest) and one Imp request which shows what type of impression the bid request is (e.g. Banner, Video, etc.).

However, there are lots of optional objects specified too. The more information available on the bid request, the higher the potential to maximize bid value, since there are fewer unknowns. More details also mean that more DSPs in general will take part in bidding, since the request can match more campaigns and be more precisely targeted. In an industry categorised by small edges in performance meaning large dollar rewards, every advantage is crucial.

Apps and User Agents

By default, apps don’t give much information away, certainly nothing that could help gain additional insight into the device it’s running on.

The problem

When an app presents a User Agent string which doesn’t include any device model information, it could be significantly diminishing the monetization potential.

However, If the device and its capabilities can be identified, the value of each impression grows thanks to the increased potential for optimization and ad targeting.

In effect, if the app UA strings resemble the examples below, with no device identifying token, an opportunity is being missed:

• MyAppName/3.6 (Linux;Android 7.0)
• MyAppName/1232 CFNetwork/893.14 Darwin/17.4.0

As well as monetization, this scenario also affects other services that use the UA string, such as analytics. For more details, referencing the HTTP specification as background to the recommendations, see the Webviews and User-Agent strings article here on mobiForge.

By amending the UA string your app presents to follow the HTTP specification, a user agent parsing solution as used by ad tech platforms will automatically return detailed information about the devices, enabling, for example, the effective population of the device object in the bid stream. This enabled improved targeting by DSPs.

How and where to make the changes

Option 1 – Within the App itself (i.e. under App publisher control).

Option 2 – Within the Service Provider SDK that interfaces with the external service, such as an advertising or analytics service (i.e. under service provider control, typically the ad exchange or SSP).

When the change is made within the app, all third party services used by the app provide better results.

When the change is made by the Service Provider in their SDK, this improves results across all apps leveraging the Service Provider SDK, without needing any changes to be made by the app publisher.

Change recommendations per OS

1. Android

Instead of capturing the custom UA in the form MyAppName /3.6 (Linux;Android 7.0), which contains no device identifying information, it is recommended to retrieve the system user agent string.

Java coding in the app or SDK:

The resulting UA string is of the form:

This form of UA string can be used as is with the DeviceAtlas APIs to provide full device information. An App name and version can be appended if desired, as follows:

Alternatively, a webview user agent string could be captured, if this is preferred.

2. iOS

Example string: MyAppName/1232 CFNetwork/893.14 Darwin/17.4.0

This contains no device identifying information, and the most that can be discerned is that it is an iOS device. However, it could be iPhone or iPad; no granularity is possible using the UA string alone.

To address this:

Step 1: retrieve internal model string (either in the app or SDK).

Objective C:

This results in the internal model string of the form iPhone7,1.

This string can be used as is, and will return the correct Apple device and hardware version. Appending further information such as app name is also possible.

If the OS version is also required, the system user agent string should be retrieved, and modified to provide the exact h/w version, as described below.

Retrieving the system user agent string:

This returns a UA string of the form:

Note: this does not include hardware version information, so an iPhone 8 is indistinguishable from an iPhone 6, for example. However, the UA can be modified to add the exact model (previously retrieved) as follows:

This can be used with DeviceAtlas APIs to return exact model, OS and full device details. App details can be appended to the UA if desired, per example below.

How to check results

Submit the UA string on the page below:

User-Agent tester (now with Client Hints support)

If your UA string returns device information here, you should see a material improvement in app monetization.

Contact support@deviceatlas.com for any questions, or if a result is not as expected.