ABOUT DAVID: LinkedIn  | Twitter | Dataseat




ABOUT ROCKETSHIP HQ: Website | LinkedIn  | Twitter | YouTube

KEY HIGHLIGHTS

🔧 How the attribution is going to change under-the-hood

🎬 The journey of value starts with the bid request

⌛ Then and now: what has changed with the bid request

🖋️ Why every DSP has to have a unique signature

2️⃣ Tale of two SKAdNetwork variables

🙃 We will still have last touch attribution

⏲️ Delay in the SKAdNetwork timer is detrimental to advertising

🦴 The anatomy of a postback

🎁 Attribution data is stored on the device

👍 MMPs will still have value; it’ll be different

🔍 Why granular postback data is important

🔙 There is a precedent for aggregate reporting

🙋 What is info.plist

🌸 How info.plist is central to attribution

3️⃣ 3 things publishers need to become SKAdNetwork compatible

🧐 The questions to ask when trialling a DSP

🏝️ No man’s land: The current state of attribution

🦋 What has changed in the bid request logic

🌐 How the web can provide a template for mobile marketing

🐝 Why cross pollination of data couldn’t happen on the web

🏆 Who has the most data used to win

🦸🏻‍♂️ The move towards privacy is a good one

🔭 The unexplored potential of mobile web

🌁 How to estimate your mobile web results without precise attribution

KEY QUOTES

The new user experience is great

Whilst in the past there may have been a click redirect to Adjust, Appsflyer, Kochava, etc. That is no longer happening. Actually the user experience looks pretty slick compared to days in the past: user clicks on the advert, and then the App Store on the iPhone just slickly moves up, so UX-wise is pretty slick. Click on the advert, App Store appears on their phone. 

How attribution will work on iOS 14

Let’s assume that the user then downloads the advertiser app. The advertiser app’s engineering team would have configured some code within it, some iOS 14 code which says: “Fetch attribution.” What it actually is doing when the app first launches, it queries the StoreKit to say: “Who was the last click?”

Be mindful of tracking events

Every time an event is tracked, the countdown timer is reset. This is the very reason why Facebook and other ad networks—we agree with them—are advising advertisers not to track in-app events for more than 24 hours for the first 24 hours. Why? Because every time you track an event, it resets the countdown timer. So the longer you’re tracking in-app events for, the longer and longer the delay is. Now I can’t stress how detrimental delay is to advertising campaigns.

What you DO get from SKAdNetwork

You get region for free, because from the IP address, you’ll know that it’s USA, New York; you won’t know it’s downtown Manhattan, but you get some data for free, almost, from SKA. 

The new role of MMPs

How ad networks will be judged, certainly in the short term I believe, will be: “Right you’ve driven 100 installs. How many conversion events, one, two, and three, have you driven?” 

Now for the MMPs to represent that, they actually need that granular data given to them; not just the weekly aggregate report sent to them. So it’s the granular level data that will allow better understanding of a very limited new attribution system.

The mechanics of info.plist

Each of the ad networks would have provided the supply side SDKs—MoPub and Google—with their signature. Now that signature goes into the ad-serving SDK, which actually puts each signature in the info.plist configuration file within that app. 

I’ll give you an example. If a publisher, maybe SKA-compatible, and they may have five ad networks in their plist; that means that they will be able to track SKA for those four or five ad networks only. It is actually important that the supply side publishers are ensuring that their latest SDK from Fyber or MoPub or whatever, is the latest one, because the latest one will include all of the ad networks SKA signatures in the plist. So what the plist is is a list of registered demand side ad networks.

3 questions to ask when trying out a new DSP

For one of your audience members, who is thinking of running with a new DSP, they must ask them currently: what percentage of your traffic is SKA compatible? And which SSPs have implemented your signature in their plist? These two things are important now. In 6, 12 months time, it will be less so because everything will propagate.

Publishers need to get SKAdNetwork compatible too

They have to make sure they’ve got the latest supply side SDK that includes those plists. As long as they’ve done that, then every ad impression they have, that is going through to the exchanges, that then goes through to the demand side auctions, they will all appear as SKA compatible. And what does compatible mean in the bid request, we will just see an SKA parameter, which tells us that we can bid on it and that we are trackable. 

The current state of attribution affairs

The no man’s land is, today, we’ve got a mix of SKA trackable, non SKA trackable, and we have multiple attribution methods. Today we’ve got IDFA matching, deterministic, you’ve got fingerprinting, and you’ve got SKA. This is why I call it no man’s land, because we don’t really know—we’re using all three combinations today. What I strongly expect will happen—that we’ve discussed about in the past; you’ve probably seen articles for me—is we strongly expect that fingerprinting will disappear pretty quickly after ATT rolls out. It is not this mix anymore. Very quickly, the whole world will become SKA only. 

What changes in the bid request

So what’s the new norm? The bid request comes in. And the logic behind the demand side is going to be: “Right. What have we learned from our one advertiser for this one campaign?” And the type of things that you learn contextually is which publishers have the best conversion rates; what day of the week; what time of the day; which creative; what geography: is it Idaho, New York or California? So these are contextual variables. So what does change is that bidding logic, and within milliseconds, you get a bid request, within milliseconds, our algorithms will run, and my peers and competitors that have got this right will do the same. They’ll go: “Right. Well, because this is this publisher on a Saturday at 8pm on WiFi, in New York, I’m willing to bid $18.” So it’s the logic on the demand side that has changed. Not really the bid stream itself.

Whoever controlled the data was the winner

What wasn’t ever discussed was what’s often in the fine print: whatever data is derived from using our platform, we are the data controller. That’s legal language that says: “If you send me a suppression list, it’s ours. We own it.” And that is what led to the situation we’re in.

A way to estimate performance

My view on mobile web is advertisers should to try and get as high an opt-in as possible. They should run on mobile web, they should fingerprint those users that have opted in, and then you extrapolate up. So let’s just say, they’re running a mobile web campaign, they have 20%, opt-in, that lead to 100 installs. It is a completely fair statistical method to say: “Well, 20% lead to my 100 installs, therefore, I 5x that, and that was my total performance.”

FULL TRANSCRIPT BELOW

Shamanth: I’m very excited to welcome David Philippson back to the Mobile User Acquisition Show. David, welcome back.

David: Thanks for inviting me.

Shamanth: Yeah, I’m thrilled to have you because the last time we spoke—I think this was two weeks before WWDC, and you’re like: “We’re very likely to have the IDFA go away, so let’s talk about what happened in the past decade.” It was a fascinating episode for myself and for everybody, just to set historical context for everything that has happened since, and understanding and explaining exactly why it happened. And of course, a lot has happened since then. So I’m excited to dive into some of the implications of what is unfolding, and what could happen next. 

A good place to start would perhaps be to understand how the world of attribution is going to change. Pre-iOS 14, in a deterministic world, the MMP would look at IDFA pre-install, compare with IDFA’s of event completers post install, and do a match. So with SKAdNetwork—of course, there’s a postback signature involved and the postback is structured in a way that’s very different from what was the case before. So help us understand how that impacts attribution going forward, and just how even the notion of attribution changes going forward?

David: Sure, I think the best thing I can do for you and then your audience is to try and verbally describe how SKAdNetwork attribution works. I think if people can understand that, they can then begin to understand the limitations of it, and the value that they can get from their existing MMP. Because, although the attribution itself doesn’t include the MMP, the MMPs can still add value there. So I think the best thing I can do is try and describe to your audience how SKA attribution works. The best way to do it is for me to share a schematic diagram: I describe it from there. So I think the best thing for me to do is to verbally describe it, and then we can put this in your podcast, a PDF or a schematic for your audience. Please look for the schematic diagram that Shamanth will share. 

So I’ll describe it from a bid request, because that’s when all the value starts. There is a publisher, and that has a—might be a Flappy Bird from Voodoo or whatever—bid request coming up. Everything they’ll be describing up until the attribution is done remains the same. So a bid request goes to the SSP that could be MoPub or Fyber, the mediation platform. 

That bid request goes through to a number of the demand side platforms, so a number of DSPs. Now, one thing to note, and this is where it becomes different, is each of the demand side partners have registered with Apple. So they’ve registered with SKAdNetwork, they’re registered with SKA, and each of the demand partners has their own unique signature. So Dataseat has an SKA signature. 

Okay, so bid request comes through to us; we’ll then be using our contextual algorithms to decide how much to bid on that particular impression. Let’s say we decide to bid $12 for that video impression. What is different now is our bid response, we will be including two new variables: one is our SKA signature, that is identifying this bid is from this demand source. It’s unique to Dataseat. And also we’ve got the opportunity to add another SKA parameter, which is campaign ID. It’s a terribly named thing because everyone just thinks: “Oh I can measure 100 campaigns!” Later on, I’ll describe the limitations of campaign ID. 

But let’s assume we bid, we win. Within that one bid request is our SKA signature and a campaign ID. That advert is served again as usual by MoPub or Fyber or whoever served the advert. The user themselves then click on the ad. This is where it does actually act a bit different.

Whilst in the past there may have been a click redirect to Adjust, Appsflyer, Kochava, etc. That is no longer happening. Actually the user experience looks pretty slick compared to days in the past: user clicks on the advert, and then the App Store on the iPhone just slickly moves up, so UX-wise is pretty slick. Click on the advert, App Store appears on their phone. 

Once a click has occurred, there is a unique new bit of storage on an iOS 14 device which is part of the StoreKit. But within the StoreKit, there is the SKAdNetwork client. Now on that device, every SKA-ready click is stored on the device, so it will sort of be Dataseat’s signature with a timestamp now actually stored on the device—not with the MMP. If there’s other campaigns with Facebook and Google, equally their clicks will be registered actually on the device itself. 

So

let’s assume that the user then downloads the advertiser app. The advertiser app’s engineering team would have configured some code within it, some iOS 14 code which says: “Fetch attribution.” What it actually is doing when the app first launches, it queries the StoreKit to say: “Who was the last click?”

So there’s two important things here to note: one, it is still first launch of the app, same as MMP attribution; and it is still last click wins, which is similar to the attribution we’re used to. 

So let’s say: Launch –> who was the last click –> it’s DataSeat. Okay, so the attribution there is for DataSeat, however, we don’t receive the postback. Yet. A countdown timer is set. The initial countdown timer, when you won’t receive any postback, is for 24 hours. After the 24 hours, an additional random 24-hour countdown timer is set, which is where you can expect, between hour 24 and hour 48, to receive the postback. It will be randomly between hours 24 and 48. 

There’s another variable here, which is if the advertiser is tracking in-app events, with the six-bit conversion value,

every time an event is tracked, the countdown timer is reset. This is the very reason why Facebook and other ad networks—we agree with them—are advising advertisers not to track in-app events for more than 24 hours for the first 24 hours. Why? Because every time you track an event, it resets the countdown timer. So the longer you’re tracking in-app events for, the longer and longer the delay is. Now I can’t stress how detrimental delay is to advertising campaigns.

So even if you’re tracking events within D0, at best, you receive the post back on D2, at worst D4. So that’s why these are being restricted in that way. 

We receive the postback after the delay, and within the postback there are three significant variables—there’s a few actually. First of all, the source app ID is included in it, the publisher app, really important and very powerful. That means that you can analyze and go: “Well, this publisher is converting well for me.” Now I must point out, it is subject to a privacy threshold. And that’s a whole other conversation, and if we have time later, we can talk about privacy threshold. So do not expect every postback to contain this publisher app. It’s frustrating, but it’s Apple’s way to try and stop people from backward engineering, and trying to figure out who the user is. 

Then you get the conversion value, which is configured by the advertiser. They may have done a tutorial completion, reached level 5; or more advanced advertisers will be using PLTV buckets that will represent the conversion value. 

And the other variable is what is set by the ad network, which is campaign ID. So that should mean something to the ad network. Each ad network will be having different uses of the campaign ID. And the other important thing to note when that device sends a postback to the ad network or DSP, the recipient sees the connection, which means you do see the IP address. And this isn’t for the uses of fingerprinting—no one can fingerprint from SKA because of the delay. So another benefit of the delay IP address won’t be useful for attribution. But what it does allow you to do is to do region. So

you get region for free, because from the IP address, you’ll know that it’s USA, New York; you won’t know it’s downtown Manhattan, but you get some data for free, almost, from SKA. 

So that’s the entire cycle of attribution. At no point was the MMP involved, so where the MMPs do add value is each of the ad networks can pass the SKA conversion data to the MMP to then stop trying to gather and represent that data in a meaningful way to the marketers. Does that make sense? 

Shamanth: Yeah, from what you’re saying, correct me if I’m wrong, but a lot of the matching for attribution purposes of the clicks happens on the device, by the SKAdNetwork code. And attribution gets sent to the advertiser. The MMP could be a front for the advertiser to pick up the postback and aggregated across multiple advertisers. Is that understanding correct?

David: That is correct. I have one slight fine tune to what you’ve said. So the attribution is done on the device by the Apple operating system. It figures out who was the last click and who should I send the postback to; the postback is sent to the ad network, not to the advertiser. Because of that variable, we’ve got another dynamic, which is: are all ad networks willing to share their postback data with an MMP? Of course we are. But there’s a bigger question: Is Google and Facebook willing to share their granular SKA data with the MMPs? At the moment, it seems no, but we’re hoping that they are, otherwise it’s very hard to build value about gathering all everyone’s data if the two gorillas don’t share.

Shamanth: It’s my understanding that you can see SKAdNetwork data from Google and Facebook in the MMP dashboards, or are you saying the individual postbacks—are you referencing to those? 

David: Yes, to granular. What I understand at the moment, high level, Facebook believes they have driven 1000 installs from that campaign ID without showing how it is split out, I believe at the moment. Now I’m sure that MMPs got different views, and they’re probably progressing each day. The industry and all of us will definitely want the SRNs to share granular data, either with the MMPs or with the advertisers themselves; some advertisers are going to be in and out with SKA data. My point is it should be granular: in every single postback, we’ll share that with Singular and then Appsflyer. Question is: will Facebook share each level of data? 

Shamanth: Yeah, help folks understand what difference that’s going to make? 

David: It’s a good question. So it all comes down to how a marketer is going to be comparing. Because compared to what we all do today, we’ve got finite granularity, finite LTV forecast; so you know, every single cohort that’s going in every different kind of performance direction. What we’re limited to now is ad networks: A, B, and C, are going to be compared—let’s just say they’ve driven 100 installs each, what is important is that you actually understand what of the conversion values they’ve driven. 

Now, those conversion values will mean different things to different advertisers, but let’s just imagine that one is tutorial completion, level 5, level 10, deposit—those who are my different conversion values.

How ad networks will be judged, certainly in the short term I believe, will be: “Right you’ve driven 100 installs. How many conversion events, one, two, and three, have you driven?” 

Now for the MMPs to represent that, they actually need that granular data given to them; not just the weekly aggregate report sent to them. So it’s the granular level data that will allow better understanding of a very limited new attribution system.

So the limitations are significant. And the point is that we hope that every ad network will share that granular data. So a limited world can actually be sliced and diced, as well as it can be.

Shamanth: I see, and you’re saying Facebook and Google go could get away with giving aggregate data?

David: This doesn’t come from first hand knowledge, today. I’m just aware that in the past, and it’s usually been the SRNs that are far more sensitive about sharing any of what they consider their data. Because the SKA postback is sent to them, arguably, it is their data. Even just looking at impression tracking, Facebook and Google have never allowed any third party impression tracking. There’s a precedent or a history of SRNs not providing the granularity that the industry needs. I was highlighting that there’s this other—I wouldn’t quite call it an elephant in the room, because we’re all talking about it. This is very early, but I suspect that they will be sharing that granular data with the MMPs. And if they don’t, well, maybe they’ll share it with the advertiser that is spending all their money with them. It’s certainly a topic to be tracked: will the SRNs share granular SKA data?

Shamanth: Certainly, I think that’s going to be an important thing to look out for going forward. To switch gears a bit. Can you tell us what is info.plist? Why is that important? Where does that lead? Why should people care?

David: Absolutely. It was good that I described the mechanics of attribution beforehand, because there’s different requirements. Now, where I mentioned the demand side has got to register with Apple to get their SKA signature; what the demand side also has to do is provide their signature to the SSPs on the supply side. I’ll just take MoPub as an example; they’re a great mediation SSP. So

each of the ad networks would have provided the supply side SDKs—MoPub and Google—with their signature. Now that signature goes into the ad-serving SDK, which actually puts each signature in the info.plist configuration file within that app. 

I’ll give you an example. If a publisher, maybe SKA-compatible, and they may have five ad networks in their plist; that means that they will be able to track SKA for those four or five ad networks only. It is actually important that the supply side publishers are ensuring that their latest SDK from Fyber or MoPub or whatever, is the latest one, because the latest one will include all of the ad networks SKA signatures in the plist. So what the plist is is a list of registered demand side ad networks.

Shamanth: I see, and let’s say you had to test a new ad network or a DSP, should you assume it is already registered by the SSP? And for folks who may not be familiar, an SSP is an exchange; there you’re talking about the same thing. If I as an advertiser was onboarding a new DSP, is there anything I would have to do?

David: Yes, there’s certainly far more considerations than what we’re used to today. But also the considerations today, I’m sure, they’re going to normalise over the coming months, but the status we’re in at the moment. 

First of all, not all publishers are SKA compatible, yet. We see about 35% of the bids that we’re receiving are SKA compatible. Now, even within that 35%, there’s another variable, which is well how many of that 35% have included Dataseat in the plist? 

So those are the two major variables that equals: “Well, how much of the traffic is trackable by SKA?” So just because we were predicting this, we were early on to registering with SKA; we’ve ensured that our signature is in all of the exchange SSPs. So I know that our SKA signatures are in the plist for all of them. But

for one of your audience members, who is thinking of running with a new DSP, they must ask them currently: what percentage of your traffic is SKA compatible? And which SSPs have implemented your signature in their plist? These two things are important now. In 6, 12 months time, it will be less so because everything will propagate.

It will just take time for the percentages to increase. But this is an issue now it should go away in a month’s time.

Shamanth: Certainly, certainly. And when you say bids are SKAdNetwork compatible, what has to happen for an impression, or a traffic source to be SKAdNetwork compatible?

David: It’s a broader question—excuse me, I’m not the actual coding engineer that’s implementing this, but I know the principle. So there’s two things that they’ll have to do: one is make sure that their app itself is iOS 14 compatible. Every developer, whether a publisher and advertiser or both, would have been going through that process. That’s the first thing. And most of them either have, or are already doing it. 

But the second thing is what we’ve mentioned already, is that if they’re monetizing,

they have to make sure they’ve got the latest supply side SDK that includes those plists. As long as they’ve done that, then every ad impression they have, that is going through to the exchanges, that then goes through to the demand side auctions, they will all appear as SKA compatible. And what does compatible mean in the bid request, we will just see an SKA parameter, which tells us that we can bid on it and that we are trackable. 

So it’s not much different in the bid stream itself, other than as a variable that allows us to identify that that publisher and impression is trackable by SKA. And when iOS 14 rolls out, a far higher percentage of those bids won’t have an IDFA. But there’s not much difference between a bid yesterday, compared to a bid in a couple of weeks time, other than a very significant proportion will have no IDFA, which is the same as LAT traffic today.

Shamanth: Yeah, exactly. With the distinction that there’s a flag if I might say so that says: “This is SKAdNetwork compatible” which means the DSP is populated in the plist, and it means this impression can be tracked via SKAdNetwork.

David: It is and we’re in this interesting period, which I called no man’s land, really because we all know this is happening. But it hasn’t happened yet. We’re all scrambling to get ready. The supply side from our perspective is 35% ready, but it’s increasing at a fast, steeper rate now—which is a positive thing. Yeah, it was concerning a couple of weeks ago, when it was at 20%, but it’s taken a big jump recently, as the supply side’s have been pushing their publishers to upgrade. 

But

the no man’s land is, today, we’ve got a mix of SKA trackable, non SKA trackable, and we have multiple attribution methods. Today we’ve got IDFA matching, deterministic, you’ve got fingerprinting, and you’ve got SKA. This is why I call it no man’s land, because we don’t really know—we’re using all three combinations today. What I strongly expect will happen—that we’ve discussed about in the past; you’ve probably seen articles for me—is we strongly expect that fingerprinting will disappear pretty quickly after ATT rolls out. It is not this mix anymore. Very quickly, the whole world will become SKA only. 

Actually, I’d say bring it on because this period of uncertainty, and using these three different methods, and they don’t dedupe—really we just need to get to the new standard as quickly as possible is my perspective.

Shamanth: Yeah, in a programmatic bid, there’s a bid request and a bid response, and there are a number of variables that are currently passed. What changes in those bid requests and responses post-iOS 14?

David: It is a really interesting question, because there’s two parts of it. In the first part of it, not much has changed in the bid request. But what happened on the demand side logic has changed hugely. So the first part of my statement: not much has changed. All that’s changing the bid request is there’ll be a lot less IDFAs, and the percentage that is SKA trackable is going to go up. Essentially, the bid request looks the same, apart from one or two small variables. Not much changes from what’s incoming. 

What has changed drastically is the logic that the demand side will be using to bid. Now, what has been happening for the majority of the past 5-10 years is that the bidding logic has been based on behavioural data—that the majority of ad networks and DSPs out there would have been collecting: IDFA data from the bid stream, from suppression lists, or if you’re lucky enough with the SRN, you’re sent everyone’s device IDs. So the status quo in the industry has pretty much been whoever has most data wins. 

For example, a bid request comes in. If that ad network or DSP is running a match three campaign for an advertiser, they’re trying to say: “Well, what do we know about this bid? Oh, it’s a match three whale! We know it because we’ve learned that from our other clients.” They’ll bid super high. That’s what I call behavioural based bidding. That’s over, or rather it’s going to drastically reduce from the majority to the very small minority—which then means it’s not scalable and not lucrative, so it’ll probably fizzle out to nothing. 

So what’s the new norm? The bid request comes in. And the logic behind the demand side is going to be: “Right. What have we learned from our one advertiser for this one campaign?” And the type of things that you learn contextually is which publishers have the best conversion rates; what day of the week; what time of the day; which creative; what geography: is it Idaho, New York or California? So these are contextual variables. So what does change is that bidding logic, and within milliseconds, you get a bid request, within milliseconds, our algorithms will run, and my peers and competitors that have got this right will do the same. They’ll go: “Right. Well, because this is this publisher on a Saturday at 8pm on WiFi, in New York, I’m willing to bid $18.” So it’s the logic on the demand side that has changed. Not really the bid stream itself.

Shamanth: Yeah. And is that a change that’s already happened for web programmatic, or is there still some model behavioural bidding happening right there? And I ask to understand if there’s a precedent that mobile advertisers can use to understand and model the potential impact of what this might mean to them.

David: It’s a good question, because actually my previous business, AD-X Tracking was an MMP, which was acquired by Criteo. So I was at Criteo for 4 years, building their mobile business. But actually, my experience there was: ITP happened! Intelligent Tracking Prevention on Safari, which was ITP 1 and then ITP 2, which is even worse. So I’ve experienced them. 

Now, on the web, the similar thing with cookies had a very detrimental effect on retargeting. But on the web, user acquisition wasn’t driven by the same device graph, cross pollinating, that in-app is. In the web, it was unheard of—or rather, it was deemed criminal—to cross pollinate one advertiser’s data with another. It was unheard of. If a company did it, they would get banned, audited or punished. What’s matured in the in-app world, it just became normal. And then it was the SRNs that drove it. SRNs all got sent device IDs from everyone. Well, if you’re an ad network or DSP that had to compete with Facebook or Google, well guess what? You also have to gather similar amounts of data. Now, actually, the detrimental effects of ITP on web are far smaller than the detrimental effects of IDFA deprecation on UA in-app, because UA in-app is all about whoever has the most data wins. That wasn’t the case on the web.

Shamanth: Yeah. And I’m reminded of what you said in our last episode, which is that—and paraphrasing, of course, but I think you said—a lot of web advertisers are shocked at the amount of cross pollination of data, because all UA on mobile is like retargeting on the web, very deterministic in ways that a lot of advertisers would still find shocking.

David: I think they would, but it’s interesting if you’d witnessed how this has matured, because ad networks and DSPs didn’t ever go to an advertiser and say: “Can you share all your device IDs with me, so I can put them in my device graph and drive profitable campaigns to your competitors?” If they said that, the marketer would go: “I’m pretty sure I can’t do that, or I’m gonna get in trouble.” If you said that to the chief privacy officer, they’d red card you and say no chance. But those discussions never happened. 

What did happen: “I’m an SRN. Drag and drop in your MMP. Woohoo! I’ve got all the data.” And you’ve signed the Google and Facebook terms, which means that they can clearly do whatever they like with the data. The ad networks and DSPs, well they just said: “Send us a suppression list.” You’re working with us on an arbitrage, they’re selling installs, it’s only fair that that arbitrage ad network doesn’t serve adverts to existing users that they’re not going to get paid for. So the suppression lists were easy. Yeah, I can send you a suppression list.

What wasn’t ever discussed was what’s often in the fine print: whatever data is derived from using our platform, we are the data controller. That’s legal language that says: “If you send me a suppression list, it’s ours. We own it.” And that is what led to the situation we’re in. 

My view is that this is Apple’s biggest issue with IDFA. IDFA was created for attribution in 2012, and that was a legitimate use for IDFA. What happened was SRNs, suppression lists, whoever has most data wins, and, those that did win, made tens of billions of dollars. And that is what Apple dislikes. That’s my view. And I do think it’s a huge breach of consumer privacy. Consumers never said to an advertiser: “You can share my device ID with 10-20-100 different ad networks. I do believe Apple’s position is right, albeit to the detriment of every mobile marketer.

Shamanth: Yeah. And I think you’re also right to point out the role of SRN or SAN, as you will, because Facebook’s and Google’s position has always been: “This is our data. Advertiser data is our data; we own the data.” They treated it as first party data that they were free to use to cross target users across different apps. For whatever reason, that has never been questioned until now. And I can see why all of that will have led us to this point.

David: It is a classic example of where I actually think self regulation—capitalist self regulation—doesn’t work. Don’t get me wrong; I am a capitalist. I’d rather self regulate myself than have a clueless government body do it. But there’s two examples: Facebook, Google that set this data standard: whoever has most data wins. That’s a terrible example. Or a good example of where capitalism and self regulation doesn’t work. That wasn’t GDPR- and CCPA-legal. It isn’t. 

But then what Apple have now imposed, I believe, actually goes beyond GDPR and CCPA. So actually, we then see another—one of the most successful in the world—capitalist organisation now imposing privacy—apparently law. But I see that that’s what is happening with all of the delays and the privacy thresholds. It goes way beyond GDPR and CCPA. In fact, the whole pop-up I think, is a bit too aggressive, that they are actually going to be law enforcing. But still, I think it’s better than the environment that we were in.

Shamanth: Certainly, you’re right to point out that Apple is a capitalist, profit-making organisation driven by its own incentives, and I think that’s certainly a larger conversation. But to our broader discussion that we were having earlier, in one aspect that is a bit of a question mark, for a lot of people is mobile web. Mobile web, especially on programmatic has always been a part of the inventory, and that’s not governed by SKAdNetwork. So what happens to mobile web inventory or impressions that come in, as a part of DSP traffic going forward?

David: I actually see this is an opportunity, and mobile web is an underbought inventory source. It has actually been an opportunity, even today. It can’t be tracked with IDFA, so it would be fingerprinted. And actually, we run some campaigns for clients on mobile web and the performance is good. It’s tracked by fingerprinting. Let’s just say ATT rolls out, SKA, as you rightly point out is not compatible, cannot track mobile web traffic. It can only track a download that comes from an in-app publisher, not a mobile web publisher. 

So the question is: can app advertisers still run on mobile web? The answer is yes, they can. Next question is: can it be tracked by SKA? No, it can’t. Right, well, can it be tracked by anything else? So just looking at the web—whether it’s desktop or mobile—it doesn’t actually matter. There’s two ways that you can track any web traffic to an outcome, and that is with a cookie or by fingerprinting. 

So my view is that advertisers should—and I know the majority are—try and get a percentage opt-in. Because let’s just say the advertiser A gets 20% opt-in. That actually means that 20% can be fingerprinted. So opt-in isn’t just for IDFA; the ATT opt-in option is to say: “You can track me from other sites and apps not owned by this company.” So ‘track me’ does mean fingerprinting, it means IDFA traffic, email matches, or whatever. 

So

my view on mobile web is advertisers should to try and get as high an opt-in as possible. They should run on mobile web, they should fingerprint those users that have opted in, and then you extrapolate up. So let’s just say, they’re running a mobile web campaign, they have 20%, opt-in, that lead to 100 installs. It is a completely fair statistical method to say: “Well, 20% lead to my 100 installs, therefore, I 5x that, and that was my total performance.”

Shamanth: I see, that still requires some amount of estimation and good faith, I imagine. 

David: For sure. My point is your choices are: don’t run on it; run on it blind; or run on it with some opted in traffic that gets fingerprinted. You’ve at least got some data that you can then weight up based on the percentages. But I think it is an opportunity because it is underbought, cheaper inventory. So there are good quality users out there. And I think it is worth advertisers experimenting with.

Shamanth: I see. Would you say it’s going to be cheaper than contextual bias, after Apple pulls the trigger? It will be cheaper, because I would expect the contextual CPMs also to crash.

David: So CPMs, in-app and on mobile web, I do believe will be lower in a post ATT world. I’m expecting in-app CPMs to drop more significantly in the mobile web. Why? Because it’s that in-app inventory that’s had the device graph—what I call the $50 snipers—if you know it’s the match three whale, you bid 50 bucks, right? That’s all app to app. 

What’s been disrupted most is the demand into app inventory. Those device graphs were rarely bidding on the mobile web, because there wasn’t an IDFA to identify them. Now, some smart companies have done a cross device graph, which is to match an IDFA to a cookie, so actually, when they saw a cookie on mobile web, they were like: “Oh, that’s the IDFA—it’s my match 3 whale.” But that was a lot less prolific, than in-app. So I’m expecting in-app CPMs to drop more than mobile web, but mobile web CPMs were a lot lower in the first place.

Shamanth: I see, interesting. This is all very fascinating, David, and I think we have come up on time. This is perhaps a good place for us to wrap. But before we do that, could you tell folks how they can find out more about you and everything you do?

David: Sure, I’ll just introduce myself. My name is David Philippson, I’m CEO and co-founder of Dataseat. We are in-app, in-house DSP. We’re focused predominantly in the gaming space. Look us up: dataseat.com or on LinkedIn, or listen to the numerous podcasts, and my big mouth that likes to talk about these subjects in such detail. Shamanth, thank you for inviting me to your podcast. I’ve enjoyed contributing. Thank you. 

Shamanth: Certainly, thank you for your fabulous insights, certainly very unique perspectives. Excited to put these out into the world very soon.

A REQUEST BEFORE YOU GO

I have a very important favor to ask, which as those of you who know me know I don’t do often. If you get any pleasure or inspiration from this episode, could you PLEASE leave a review on your favorite podcasting platform – be it iTunes, Overcast, Spotify or wherever you get your podcast fix. This podcast is very much a labor of love – and each episode takes many many hours to put together. When you write a review, it will not only be a great deal of encouragement to us, but it will also support getting the word out about the Mobile User Acquisition Show.

Constructive criticism and suggestions for improvement are welcome, whether on podcasting platforms – or by email to shamanth at rocketshiphq.com. We read all reviews & I want to make this podcast better.

Thank you – and I look forward to seeing you with the next episode!