Programmatic Monetization: The cheat sheet for app publishers

Excel Formulas Cheat Sheet for Beginners - Excel University

We studied how programmatic advertisers buy ads on display.io and found that the more ‘discoverable’ a bid request is, the more ad revenue a publisher generates.

The cheat sheet below highlights the most effective ways for monetization teams to improve the discoverability of their ad inventory today.

1. Are you passing viewability signals on the ad request?

Viewability is a digital advertising metric that measures “seen” impressions.

If you are not passing a viewability signal in your bid requests then you are automatically cutting your apps out of $30B+ in online ad spend from Consumer Packaged Goods (CPG’s) including brands like Heinz, Pampers and Kraft. 

Here’s how to support viewability in apps

In 2020 the IAB developed Open Measurement SDK (OMSDK) as a way for app publishers to communicate that their inventory is measurable for viewability by vendors like MOAT, Integral Ad Science and Double Verify.

The Display.io SDK already contains OMSDK and has been certified by the IAB.

But publishers can also integrate OM directly with IAB and apply for certification here.

Pricing depends on how many ad units / formats you will want to certify but expect pay a few thousand dollars.

Here’s what OMSDK appends to your bid request:

bidRequest.sourse.ext.omidvp
bidRequest.sourse.ext.omidvn
bidRequest.imp.video/banner.api:{7}

2. Do you support SKAdnework?

Most iOS bid requests are missing IDFA after Apple kneecapped the performance marketing industry by introducing ATT in iOS 14.5.

iOS app advertisers, who account for ~50% of $200bn in annual app spend,  have turned to SKAdnetwork (SKAN) as a way to measure the performance of their ad spend on iOS.

SKAN is a probabilistic methodology of attributing post click events (e.g install) to a cohort of impressions, effectively letting advertisers know what inventory is performing and what isn’t.

SKAN is far from perfect but as an app publisher if you don’t support it your inventory won’t perform.

Here’s how to support SKAN

  1. Add SKAdNetwork IDs of all network partners to the app’s Info.plist file
  2. Pass the raw skadnetids, IABTL max and/ or exclto to your ad vendors SDK at runtime

Tips:
Ensure all inputs on the pinfo list are done in lower case characters 
Keep info.plist file updated with new entries when publishing new app versions to App Store
Implement SKAN for all ad vendors you work with

Click here to read more on how display.io supports SKAN in our SDK

3. Are you leveraging additional data in your bid requests?

Savvy programmatic buyers look for additional data signals in every bid request and use it to make more informed bid decisions.

Here are 4 types of data to add to your bid requests that could mean the difference between monetizing or missing an opportunity.

Location

Where the user permission exists location data must be added to all bid requests. It will lead to significantly higher bid density and bid CPMs from location based campaigns.

Here is an example of a properly configured bid request for location, including the lat:long – a key signal for buyers.

geo: {
country: "USA",
region: "NY",
type: 2,
city: "New York",
zip: "10016",
ipservice: 3,
lat: 40.7428,
lon: -73.9712
},

Category

When the IAB created its Category Taxonomy one of the main intentions was to give bid requests more context.

The taxonomy is very limited in scope, but we’ve found some of major programmatic advertisers use it in thier targeting criteria.

Category signals include App category, Page category, Section category and Blocked categories among others. Below is an example of how a correctly categorized bid request should look. 

app: {
cat: [
"IAB19"
],
pagecat: [
"IAB16",
],
sectioncat: [
"IAB16",
"IAB18-1"
],
bcat: [
"IAB25"]}

Privacy

Major programmatic advertisers are risk averse companies. We’ve learned that they avoid (“Throttle”) bidding on inventory coming from EU or California that does not contain the appropriate consent signals.

For EU traffic monetization publishers must supporting the IAB Transparency and Consent Framework which requires inventory to contain regs.ext.gdpr and user.ext.consent signals in order to comply with GDPR.

Here’s an example of a privacy compliant bid request from within the EU, where “1” communicates to the buyer that the bid request is subject to GDPR. The alternative is “0” in which case the buyer knows that GDPR should not apply.

regs: {
ext: {
gdpr: 1
},
...
user: {
ext: {
consent: [string goes here]

For monetizing inventory from the state of California this means supporting the California Consumer Privacy Act (“CCPA”).

Here’s an example of a privacy compliant bid request from within the California, where “1” communicates to the buyer that the bid request is subject to CCPA. The alternative is “0” in which case the buyer know thats CCPA does not apply.

ext: {
us_privacy: "1---"
}
},

Context

Many of our DSP partners have told us that publishers should start adding contextual signals to the bid requests. To date we haven’t seen a strict correlation between adding these signals and increases in CPM or bid rate.

However, we think providing context will become more important in a programmatic environment once android identifiers are finally deprecated.

Below is an example of how our publishers use year of birth (“YOB”) and contextual keywords extracted from the content surrounding the ad placement and inserted into the “keywords” parameter in the bid request.

user: {
yob: 2000,
keywords: "rottmnt,art,my art,doodle,digital art,artists,sketchbook,illustration,artists,superheroes",

}

Let’s get started!

Request a Demo