Future of Mobile DSPs in the Post-IDFA World

By Vladimir Khudyakov, CEO and Co-Founder of hybe.io

Guest AuthorsB2B technologyPrivacy and Regulations

By Vladimir Khudyakov On Dec 4, 2020

Future of Mobile DSPs in the Post-IDFA World

There has been a lot of buzz across the mobile industry from each corner of the programmatic ecosystem except mobile DSPs. Well, it’s time to fix this and to take a look at the New Brave Privacy-Centric World that is coming in 2021 – thank God Apple for postponing the iOS 14 privacy features. This presents an opportunity for programmatic platforms to strengthen their positions. The reason is that the changes in iOS 14 equally affect all market players and largely offset the preferences of SAN (self-attributed networks), such as AEO and VO from Facebook.

What’s changing for mobile DSPs?

Attribution

App developers will have to rely on SKAdNetwork (SKADN) to attribute installs and events. Since WWDC in late June, there were several proposals from the market players on how to handle mobile attribution with SKADN, especially MMPs, given SKADN doesn’t require mediators anymore to attribute in-app events to marketing sources. Let’s take a closer look at these options.

Attribution Hash by Adjust is a granular attribution approach that doesn’t rely on SKADN and requires having an IDFA obtained on the publisher’s side to hash IDFA+IDFV. Then, in the advertiser app, the same hash is calculated locally. As a result, the permission to obtain IDFA is not mandatory to solve the advertiser-side consent problem. Adjust’s proposal increases the potential number of deterministically attributed events in the new conditions. To increase the opt-in rate to share IDFAs, Adjust suggests several steps described in this insightful guide for managing Apple’s ATT (App Transparency Tracking) framework. The main idea is that users are shown a pre-permission prompt before showing Apple’s pop-up for consent collection. The goal of this prompt is to explain to users the value of the opt-in for them in order to ultimately increase the opt-in rates.

Nobody is yet sure about the incentives Apple will allow for app developers to give for IDFAs in return and the speed of opt-in rate growth, that’s why it’s risky to rely on high opt-in rates.

Besides the above approach, Adjust’s SDK supports SKADN that allows app developers to update conversion value and handle AppTrackingTransparency flow dynamically.

Singular’s SKAN – their solution for attribution through SKADN works this way: each DSP will have to obtain a joint SKADN Identifier (e.g., Hybe.io + Singular), and SKADN’s postback will be coming first to the MMP for validation and then forwarded to a DSP.

For advertisers, it ensures that every postback is additionally validated by Singular as a

neutral party between a DSP and an advertiser because the conversion value is currently unsigned and can be potentially altered by bad players. But, I foresee that Apple will fix that and add a signature to the conversion value.

The only disadvantage I see is that each DSP has to register a shared MMP SKADNIdentifier, and eventually, DSPs will need to have 5+ ids. Still, the proposition by Mopub’s process to handle SKADN attribution will resolve this case.

AppsFlyer’s solution is very similar to Adjust’s – DSPs can use their own SKADN id and manage the conversion value flexibly through the dashboard.

Bottom line – convenient dashboard management of SKADN’s conversion value gives significant incentive to advertisers to use SKADN attribution with the help of MMPs rather than without them. Also, some of the MMPs provide other advantageous features: ATT implementation (Adjust), cohort and ROAS reporting (Singular), which is limited due to the 6-bit size of the conversion value but still doable on 3 or 7 days.

End of the user-profiling era?

Many managed-service DSPs used to leverage the unattributed event data of the mobile app users to overcome the problem of the so-called “cold start” and feed their CPI/A algorithms with this data to target the users with a higher probability of install/event.

This data was usually sent by app developers through the DSPs’ analytics SDKs or MMP integrations. Due to the introduction of the ATT framework and expected low opt-in rate in the beginning, this data will be limited, and therefore, the performance of user acquisition campaigns will be significantly affected and. DSPs have to find other ways to feed their algorithms rather than behavioural.

That’s where contextual parameters come into play. At this point, many SSPs are already sending a lot of insightful information about a user and placement in a bid request. Then, these data points are used as features in the algorithms for better targeting. Amongst the most common and helpful bid request parameters are device model, location (city or lat/long), connection type, and carrier.

However, there are some less adopted signals in OpenRTB protocol that can let the DSPs optimize towards installs and lower-funnel events in the absence of IDFA, such as session depth, app page keywords, placement ids, loss notifications. Some of the forefront SSPs already support and pass the mentioned parameters, but they haven’t yet become a commodity. For example, session depth allows the targeting of users who aren’t yet deep in their user session in an app and therefore have higher receptiveness to ads. Some of the SSPs, e.g., Fyber, add even deeper contextual signals through OpenRTB extension attributes like disk space left, battery level, and session length. To provide an alternative when IDFA is not available, Mopub, for example, will send IDFV or their Mopub id, so DSPs can leverage this data for frequency capping, fraud detection and analytics.

Loss notifications give insights on why a DSP is losing in the auctions. The reasons might be: you’re bidding with a competitor app on publisher’s inventory, you were outbid, an advertiser category isn’t allowed, etc.

Creative optimization is another direction that is going to be under scrutiny due to the release of Apple’s iOS 14 privacy features. As many of you know, Apple limits the number of campaigns to 100 for the combination of Ad network (DSP in our case) + App in SKADN. For example, even to do a proper A/B testing, app developers would need to use two separate campaigns to be able to measure the performance. App developers need to pay close attention to the quality of creatives they run programmatically and move away entirely from old-school low-quality creatives that are run on ad networks. I’m talking about low-res and outdated aspect ratios creatives like 320×480.

OpenRTB implementation of SKAdNetwork

SKADN is designed initially to solve the problem of attribution in the absence of IDFA solely for ad networks that own an SDK. For DSPs to get an attribution, they have to rely on signals coming from SSPs and have their SKADN id(s) added to info.plist of a corresponding SSP’s SDK.

Then, an SSP can start sending SKADN-enabled bid requests to a DSP. To handle that, various SSPs offer special bid request and response extensions. Bid requests with SKADN support are flagged, so DSPs can bid accordingly. Cases, where a DSP has several SKADN ids, are also handled by this OpenRTB extension, so shared MMP-DSP ids will also work.

A DSP can choose whether it wants to get only bid requests with relevant SKADN ids or all. Then, in the bid response, a DSP replies also through the SKADN-specific extension object where it passes the parameters required for Apple’s attribution to work, such as campaign id and signature. Then, if the SKADN determines that a DSP’s click led to an install, it sends the postback to the DSP’s endpoint with all the relevant data like source app, target app, campaign, and conversion value (if provided).

Opt-in rates to share IDFA

Given the current state of the internet, where you have to give consent to be tracked on almost every website in order to access the content. It’s likely we can expect something similar with iOS – users will be restricted to view certain content or be given less features if they don’t give access to their IDFA, and incentivized to share it for perks inside the app. As a result, we can expect the percentage of IDFA in the bid requests to increase within the next two years.

Adikteev, for example, did a great job and conducted a proper live experiment on opt-in rates. The results have shown that only Apple’s pop-up shows significantly better opt-in rates – 73% compared to custom + Apple’s pop-ups – 36-39%. The results sound interesting because the rationale for pre-Apple pop-ups was to explain to the user why they should share their IDFA. I can explain such results by users being eager to complete all of the permissions after they have installed the app as soon as possible and not paying enough attention to standard Apple pop-ups. But custom pop-up breaks this cognitive habit to accept everything, and that’s why the opt-in rates drop.

Anyways, there is a big field for experiments for app developers to find a perfect solution to increase the opt-in rates, and there is no place here for assumptions. They will rely on data and continuously test and iterate.

Apple’s privacy change will heavily impact the state of mobile marketing but DSPs have all the required tech at their disposal to continue successfully operate. Yes, it will be harder to optimize for the performance without deterministic signals, but over time, this might be improved with the development of SKADN, the increase of opt-in rates and more opportunities for contextual targeting.