ABOUT ANDY: LinkedIn  | Twitter  | Phiture  | Mobile Growth Stack




ABOUT ROCKETSHIP HQ: Website | LinkedIn  | Twitter | YouTube

KEY HIGHLIGHTS

🥰 Why the impact of iOS 14 on retention strategies for apps might not be huge.

🆔 What are scoped identifiers? They’re the reason analytics and attribution will continue to operate as they do post iOS 14 as well.

🔀 Cross-platform user tracking that currently uses the IDFA will need to change 

🔗 Deep linking will still exist. Deferred deep linking needs figuring out. 

💨 Shifting from deterministic to probabilistic methods to identify users will make some magic vanish.

👀 Using fingerprinting to identify users might be a grey area in Apple’s privacy ruling. 

🌎 Privacy changes will affect geofencing campaigns and segments that require accuracy to work.

👍 Surprisingly most CDPs are well set up with regard to user privacy; and have solutions to continue without IDFAs for most part.

📒 Account creation within apps is going to become more important.

😎 Cool stuff to look forward to in iOS 14.

📋 How to use push notification prompt strategies to get pre-permissions for IDFAs. 

📚 There are other opt-in playbooks to learn from.

KEY QUOTES

Analytics tools don’t need IDFA

The analytics tools, customer engagement platforms, or CRM, and maybe A/B testing frameworks use what are called scoped identifiers to identify users. They would typically have an SDK in the mobile app that would assign an ID to a user the first time that they see that user, and then they know that’s the same user when the user is back again. So in the case of analytics, whenever the user is back in the app, they’re sending events, they’re sending this ID along with it. And the tool or the platform—whether that’s internal or a third party solution—will use this tool-specific ID to identify that user. And there’s no reason why those tools should be using the IDFA for that. 

IDFA was always problematic as an identifier

But even before iOS 14, we saw people opting out of the IDFA. So it’s not a good universal identifier to be trying to track every user anyway.

There are good options for universal unique identifiers

You might pass into some of these tools, what’s called an external ID or a kind of a universal identifier, to say: “Well, this is actually user X and this is Andy, Andy Carvell.” In which case you can pass in that information associated with that user and say: “Hey, this Amplitude ID number 34 is Andy Carvell.” Now how you are identifying Andy Carvell, it’s kind of up to you in your system as a publisher, and some publishers will have used IDFA for that. It’s also not a great idea for that, because it’s not a cross platform identifier. Some systems would use, for example, an email address as a unique identifier, or a phone number, or just a generated unique number – that’s not the IDFA.

IDFA doesn’t affect deep links

So regular deep linking, which we would use all the time with things like push notifications, and in-app messages, and possibly emails, to link people into a specific part of the app or specific screen or feature; kind of like a web hyperlink, you get people to where you want to put them rather than just opening the app. These would typically implement a direct deep link. So basically a standard URI schema, a universal link, or key value pairs, which the application can parse, interpret and direct the user appropriately when the app is opened. Now that won’t change; none of that is affected by iOS 14. 

Deep personalization will go away

Let’s say, you’re sending someone a fairly high value, referral incentive, like a $50 voucher or something. And that’s kind of embedded in this deferred deep link, then you want to be really sure that you’ve got an exact match, and you need a deterministic method. And that’s not going to be available.

Geo campaigns will only work with explicit permissions

Geofencing is not going to be possible, from what I can see; at least not without getting exact location targeting permissions, which again, is going to be a lot tougher, because you have to ask for those explicitly. 

An example would be Burger King who ran this awesome campaign, where they were geofencing users who went within a couple of hundred metres of a McDonald’s store and offered them a free Whopper or something. You won’t be able to do stuff like that anymore.

CDPs will recover

If they’re federating stuff out to retarget people on programmatic ad networks, then that’s a use case which is going to be gone. If that’s your main use case for your CDP, then, yeah, clearly there’s an issue there also for the CDP. But I think one of their advantages as platforms though, the CDPs I’m talking about, is that they are so multifaceted. And they have a very broad range of integrations across many different types of use cases. So I think their whole purpose is to make you more adaptable and more flexible. So I think they’ll be fine. 

Timing is key for opt-ins

One is to ask people to opt in for stuff like this at a sort of a happy moment. When they’ve just had a really good experience, you can kind of infer that they really love the app, and hence, it’s a great time to ask them.

Lay the groundwork

What I found to work better is first of all, using a pre-permission. It’s basically an in-app dialog, which you control as a marketer or as a developer, where you ask the user: “Hey, would you like to opt in for this?” And you can test, of course, with that different benefits and things to optimise the click rate. And when people say yes, then you show them the system dialog, which Apple only allows you to show once. 

FULL TRANSCRIPT BELOW

Shamanth: I’m very excited to welcome Andy Carvell to the Mobile User Acquisition Show. Andy, welcome to the show.

Andy: Thanks, Shamanth. Pleasure to be back.

Shamanth: Yeah, excited to have you again. Definitely, I think your last episode was a crowd favourite. And, of course, you are among the folks that we and a lot of folks in the mobile space look to for a lot of expertise, especially around retention, especially around CRM, and especially about growth holistically. 

So I’m excited to have you on the show today to talk about some parts of iOS 14 that aren’t necessarily front and centre, just because a lot of iOS 14 conversations tend to be around UA. And I would love to talk to you about aspects that don’t directly touch upon UA, but would be just as important and just as critical. So, you know, on the surface, it would appear look, iOS 14 is about tracking, it’s about attribution, and therefore it impacts acquisition. There’s like no impact on retention strategies whatsoever. So at a high level, how do you see it impacting retention strategies that growth teams or marketing teams might be working on?

Andy: Yeah, so at a high level, the deprecation of IDFA, and the increased privacy changes that are coming in with iOS 14, shouldn’t be a huge impact to most people doing engagement and retention work, mostly because—I’ll get into some of the detail on this—but like most of the tools that they’re typically using: their analytics tools, customer engagement platforms, or CRM, and maybe A/B testing frameworks. Typically,

these tools use what are called scoped identifiers to identify users. They would typically have an SDK in the mobile app that would assign an ID to a user the first time that they see that user, and then they know that’s the same user when the user is back again. So in the case of analytics, whenever the user is back in the app, they’re sending events, they’re sending this ID along with it. And the tool or the platform—whether that’s internal or a third party solution—will use this tool-specific ID to identify that user. And there’s no reason why those tools should be using the IDFA for that. 

However, some tools, just the way that they’ve been engineered—or possibly there are internal tools—they may have been built using the IDFA; for whatever engineering decision was behind that. And maybe they thought that this is always going to be there, and it’s the perfect thing to use to identify the user. I think it would have been a bad engineering choice actually, particularly in retrospect.

But even before iOS 14, we saw people opting out of the IDFA. So it’s not a good universal identifier to be trying to track every user anyway.

And certainly, now, it’s not something you should use to generate those sort of scoped identifiers. But the good news is that there are lots of other ways that you can create an ID and assign it to a person for a specific use case like analytics, and all of the commercial tools are releasing new SDKs if they need to rework anything. 

So that’s my sort of long rambling answer for high level: it’s not going to change that much. However, if you’ve got implementations which are using the IDFA to identify the user in these internal scoped situations, those need to be reworked; that will be a pretty serious bit of homework. And secondly, there are some specific use cases which are going to be affected, and are either going to be less impactful or will need a sort of an updated approach. Or maybe it’s just not going to work at all. So we can cover those as well.

Shamanth: Yeah. And I think that’s helpful to start off by mentioning, because I think the question mark that many people would have is just like: “Look, my analytics systems are tracking individual users, is that not going to work?” But from what you’re saying, it will absolutely work because they’ll probably, even right now, they have an internal identifier of some sort.

Andy: Exactly right. So just to put it in an example, let’s say I’m using Amplitude for my analytics. That’s gonna have an Amplitude ID associated with every user in the system. And that’s an internal ID, which Amplitude uses. If I’m using Braze for my customer engagement, they’ll have a Braze ID attached to all of those. And so each of these individual tools is going to know who these users are and track them. And that’s got nothing to do with IDFA. And not much changes there. 

Now, typically, you might also want to create a broader understanding of the identity of this user.

You might pass into some of these tools, what’s called an external ID or a kind of a universal identifier, to say: “Well, this is actually user X and this is Andy, Andy Carvell.” In which case you can pass in that information associated with that user and say: “Hey, this Amplitude ID number 34 is Andy Carvell.” Now how you are identifying Andy Carvell, it’s kind of up to you in your system as a publisher, and some publishers will have used IDFA for that. It’s also not a great idea for that, because it’s not a cross platform identifier. Some systems would use, for example, an email address as a unique identifier, or a phone number, or just a generated unique number – that’s not the IDFA.

In which case again, they’re kind of safe. 

Shamanth: Got it. Yeah. And do you think that could be problematic, because Apple says no tracking whatsoever? I don’t think Apple says: “Oh, no tracking using IDFA.”

Andy: No, I don’t think it’s going to be a problem to be storing email addresses and things like that. As long as you’re clear, you still have to be in compliance with all the necessary privacy regulations, like GDPR. If you’re going to use an email address, to track people in various tools and things, then you need to be explicit about that in your privacy policy.

Shamanth: Sure. And what happens to deep links and deferred deep links? How does growth via virality or referrals change as a result of this?

Andy: Yeah, that’s going to change for sure, but maybe not drastically.  

So regular deep linking, which we would use all the time with things like push notifications, and in-app messages, and possibly emails, to link people into a specific part of the app or specific screen or feature; kind of like a web hyperlink, you get people to where you want to put them rather than just opening the app. These would typically implement a direct deep link. So basically a standard URI schema, a universal link, or key value pairs, which the application can parse, interpret and direct the user appropriately when the app is opened. Now that won’t change; none of that is affected by iOS 14.

What would change is this thing called deferred deep linking, which is what you’re referring to here with  virality, right? Like if you actually do send a link, and you don’t know who’s going to click on that link. I used to work at SoundCloud. SoundCloud used to use these a lot. You’d send a link to somebody for sharing a track that you like, post it on Facebook, or you know, send it by email or WhatsApp. You don’t know if the person who’s clicking on that is going to have the app installed or not. 

So the ideal flow and what deferred deep linking opens up, is that if they’ve got the app installed, it’s going to bring them into the app. And it’s working essentially to reengage that user from the publisher perspective. And if they don’t have the app, it’ll take them to the App Store. And they’ll download it and install it. And if they install that, the deep link will then kick in and take them to the original track that you shared. It’s almost like magic, right? That’s a beautiful piece of technology, which will be less effective, because it’s now going to have to rely on what they call non-deterministic or probabilistic methods. So in other words, fingerprinting. 

So Branch seems to be fairly buoyant that they have a solution for this, that’s not using IDFA. There are ways to do this. And I think for things like content shares, or kind of really non-critical stuff, where if it doesn’t get an exact match, and it has to fall back to a generic experience, like just opening the app, it’s not really the end of the world. Even for invites, like I’m inviting my friends; if it can’t make that match, your app is going to need to basically fall back to a generic experience. Now, that’s fine I think for most use cases, actually, in most virality use cases will still work. But if you’ve got something like an auto login link that logs people in automatically, or automatically creates them an account, that’s really required to know that this is the same user who clicked on the link. Or

let’s say, you’re sending someone a fairly high value, referral incentive, like a $50 voucher or something. And that’s kind of embedded in this deferred deep link, then you want to be really sure that you’ve got an exact match, and you need a deterministic method. And that’s not going to be available.

Shamanth: Yeah. And I think that is a very important thing that gets impacted. So I understand this becomes problematic, just because with the referral flow, you’re essentially saying: “This user came exactly via this link, therefore, I will give them $50.” Plus, you can’t pinpoint as to where users are coming from under the new policy.

Andy: Yeah, in many cases, the probabilistic match will work, but it’s not going to be 100% of the time.

Shamanth: Yeah. And if you’re doing that probabilistic attribution via fingerprinting, is that not out of bounds of Apple’s privacy laws?

Andy: Well, this seems to be a bit of a grey area. I mean, I’m not working exactly on that side of things, in the tool space, but I see tools providers, like Branch, for example, saying that they’re going to use fingerprinting-type techniques. So they obviously seem to think that that’s possible. So I’m kind of working on the assumption that they’ve done their homework there. But it could be that they’re being optimistic. And it could be that they get slapped down by Apple. I think there’s a lot of grey areas still at the moment. And if you’re not even able to use these non-deterministic methods, then yeah, that really, that channel is going to be massively affected for virality. 

Shamanth: Yeah, because if you can’t even do that probabilistically, like you said, you’re giving users a generic experience. And that will erode a lot of the metrics and the efficiency of those channels.

And something else that’s very critical to the performance of a lot of CRM campaigns and retention initiatives is just to be able to segment users, you know, like being high value users or users that consume content versus the rest. Does that get impacted at all as a result of the new privacy changes? How do you see that at all? 

Andy: So, some quite specific segmentation approaches are going to be challenged. In general, segmenting users based on behaviour is not going to change because you’re going to do your segmentation in your analytics platform or your CRM platform. And these will have a way of identifying users with these internal IDs, as I mentioned, so you still be able to segment users based on their behaviour, based on events that you’re tracking within your ecosystem, your app, and the tools that you’re using. 

What’s going away is that ability to segment users across multiple apps and define them in other places. However, there are some caveats to that.

Geofencing is not going to be possible, from what I can see; at least not without getting exact location targeting permissions, which again, is going to be a lot tougher, because you have to ask for those explicitly.

And so I’ve seen some of the customer engagement platforms are basically pulling out features from iOS, like the ability to geofence. Because you’re going to have instead this very vague location-based targeting, which is going to be a lot less specific. 

Now, from a human point of view, I think that’s great. I don’t really want every company on the planet being able to target me on my precise location to a few metres. So I think it’s great from a privacy perspective, and I’m all for it. If I was doing location-based marketing, however, this would present some challenges to me. And we work with clients on location-based solutions, where some of these are going to have to adapt. Now, if it’s like a broad location-based to a state level, for example, or county level, or maybe even a bit closer. But I’ve heard it can be sort of several miles out from your exact location. 

We implemented a nice weather location-based system that pulls weather data from where the user was approximately, and gives them personalised push notifications about weather with a client of ours. That’s gonna work just fine. Because the weather doesn’t change within a couple of miles, not typically.

Another example would be Burger King who ran this awesome campaign, where they were geofencing users who went within a couple of hundred metres of a McDonald’s store and offered them a free Whopper or something. You won’t be able to do stuff like that anymore.

Shamanth: Right. Yeah, laser targeting just becomes impossible at the location-level. And another component of the growth stack of a lot of marketers are CDPs, and many apps marketers basically use them to aggregate the data, use this data for retention. How are CDPs positioned post iOS 14? How does their usage change?

Andy: Yeah, so I think CDPs definitely have some challenges, because they work as a kind of a central hub, and then multiplex data to federate data to a lot of other integrations. And I do need to chat more with some of the CDPs to get a deeper perspective on this. But from what I can see that they’re actually pretty well set up. They’ve kind of always been thinking about things like privacy, actually, for quite a long time. And actually, they helped to manage that process and helped to manage identity across multiple platforms. They’ve been thinking about this a lot longer than everybody else. I’ve seen that, for example, and mParticle’s no longer collecting IDFA by default, and requires the app to explicitly set that if they want to collect that from users. 

And let’s come back to that, by the way, the fact that you will still be able to collect IDFA, if you ask permission. So let’s come back to the permissioning aspect of it before I forget it. 

But in principle, you’ll still be able to use these CDPs; they’re going to be compliant. And you know, that they’re putting on a brave face and saying: “Well, actually, most of our integrations are not going to be affected by this.” This is the bit which I’m not so clear on. I guess it depends on your individual setup, where you’re federating that data and how you’re using it, as to how much you’re going to be affected. I imagine some folks will be highly affected and find that their current CDP configuration is going to be considerably less useful, whereas others probably will have very little impact. 

But it really depends on the use cases.

If they’re federating stuff out to retarget people on programmatic ad networks, then that’s a use case which is going to be gone. If that’s your main use case for your CDP, then, yeah, clearly there’s an issue there also for the CDP. But I think one of their advantages as platforms though, the CDPs I’m talking about, is that they are so multifaceted. And they have a very broad range of integrations across many different types of use cases. So I think their whole purpose is to make you more adaptable and more flexible. So I think they’ll be fine.

And I think actually, if you’ve got a CDP, you’re actually probably well positioned to adapt to these changes, even if you do need to change up your current setup.

Shamanth: Got it. You talked about scoped identifiers earlier. You probably have scoped identifiers in your analytics, in your PN system and your email system. So because the CDP is basically collecting a lot of these scoped identifiers, aggregating these—as long as it’s collecting a lot of non IDFA identifiers—it’s good. But if IDFA is sort of part of that mix, then it becomes a challenge. Would that be a fair understanding of how things are done?

Andy: So that’s my current understanding. I’m not sure if it’s the correct one, to be honest. But yes, it is also my understanding. So yes, I see that it works like that. Everyone’s trying to avoid the IDFA like the plague now. And if they were relying on it, they’re looking for other deterministic solutions to identify people. 

One thing which I didn’t touch on yet, apart from the permissioning, is, I think that one of the big kinds of themes is that it’s going to push more account creation activity within apps. I think there’s going to be less anonymous usage experiences designed and implemented; a lot more push towards getting users to explicitly sign up for accounts and contribute. As I said, with the appropriate permissions, the personal information that they’re willing to share, which allows you to build a unique identifier which you can use universally, and also cross-platform, which then potentially you can even then use for retargeting these users. I’ve heard that Facebook is going to allow retargeting, or lookalikes even to be built with a few email addresses or phone numbers, if those things are collected explicitly with permission. So yeah, I think there’s going to be a big move towards more logged in experiences.

Shamanth: Yeah, right. And that’s, in some ways, getting users to opt-in to giving that info in other ways, so that you can essentially target them as well. Of course, there’s more to iOS 14 than just the privacy changes, so what are some other new features within iOS 14 that you’re most excited about? And that could be most impactful for retention strategies for apps?

Andy: For retention strategies for apps. I think one of the big ones is the widgets, actually, the widgets are really cool. Put a lot of work into upgrading those, making those look a lot more sexy, and hopefully a lot more usable. I think it’s a bit too early to say how that’s gonna affect engagement and retention. And obviously, it’s also very app-specific.

Shamanth: Sorry, what’s a widget?

Andy: So it’s something that can sit on your home screen, which provides a view into your app. You can have, for example, I don’t know, stats on there, things like this from fitness apps or something like this, how much you’ve been running over the last few days. So widgets have existed for a long time, particularly on Android; they’ve been there for a long time as home screen widgets. But I really like the new implementation on iOS 14. I think iOS is doing it a nice way. And I’ve already seen some nice implementations from apps that have got that out for launch. 

But yeah, in terms of the other stuff, there’s a lot of features in iOS 14; I’m still exploring some of them. But I actually like some of the privacy features. Like there’s this little orange dot thing, which shows up if an app is currently using your camera or microphone, or has been using it recently. And stuff like this, that kind of puts the user a lot more in control and gives them more transparency on what their phone is doing and what the apps are doing. And I think that’s a good thing.

Shamanth: Very cool. Yeah. That also underscores—definitely for marketers, the IDFA privacy changes have been top of mind—there’s a lot more that’s coming that could be exciting for consumers. And for privacy broadly, just as well. As you have expressed, Andy, I think just from a retention perspective, for app managers using a CRM, the impact is going to be less dramatic than it is on the acquisition side.

Andy: Yeah, I think so. So just before I forget, let’s just quickly revisit the permissioning thing. As another caveat to all of that, as I said that there are certain things that you’re going to be totally impossible. No, they won’t be impossible; as far as I understand it, they won’t be impossible for users who have explicitly consented for you to use their IDFA. 

It’s a pretty tough dialog, which Apple shows up: “Hey, do you want to let this app track you across other apps?” It’s a pretty scary dialogue. But I think if you really have use cases, which really, really need people to contribute that permission; maybe you’ve got some users who are going to be super high value to retarget on other networks, or whatever. And you can get them to give that permission by optimising the hell out of your pre-permission dialogs using in-app messages, for example, or directing loyal users to go back to settings and turn that IDFA sharing back on, which we call a win-back. These are the techniques which actually we’ve used for a long time very effectively, and helped our customers to implement these kinds of flows for push notification opt-in. So like, there definitely are ways to increase opt-in rates for stuff and apps will have to work a lot harder to get people to opt in for IDFA, I think than push, but it will still be possible for at least some segment of the user base.

Shamanth: Yeah, definitely. I think prior to iOS 14, push opt-in rate optimisation was underappreciated by a lot of folks. But I think that can be enormously impactful and I expect from what you’re saying that getting the iOS opt-in rate up, the IDFA opt-in rate up, is going to be a very, very important lever that a lot of apps will have to pull.

Andy: If they can find a better way to do things than using IDFA, I think a lot of apps will just abandon it. But those that are really, really like relying on it and finding it actually incredibly valuable to their business, I think they’re going to at least probably have a go at increasing that opt-in rate. And I can tell you from experience, from actually years of working with apps to improve push notification opt-in, and email opt-in, there are a lot of techniques there. And you can always optimise it, but you can always get some uplift from whatever the baseline is.

Shamanth: Yeah, what might be some of the strategies they could borrow from the push notification or email opt-in playbook that you think could be applicable for improving opt-in rates here?

Andy: So there’s a couple of sort of textbook techniques, right.

One is to ask people to opt in for stuff like this at a sort of a happy moment. When they’ve just had a really good experience, you can kind of infer that they really love the app, and hence, it’s a great time to ask them.

Yeah, that works to some extent. 

But actually,

what I found to work better is first of all, using a pre-permission. It’s basically an in-app dialog, which you control as a marketer or as a developer, where you ask the user: “Hey, would you like to opt in for this?” And you can test, of course, with that different benefits and things to optimise the click rate. And when people say yes, then you show them the system dialog, which Apple only allows you to show once. 

If they say no, you can try again a bit later at a happy moment or with different benefits that you’re offering. So you can keep trying. And then you sort of save that one shot system dialog for a time when you really think that the user is going to say yes. So that’s very effective. That’s what we call pre-permissioning. And then on the other side, what are called win-backs, is going back to your loyal users, the users who are still in the app after two or three weeks, but they’re opted out. And you ask them: “Hey, actually, now would you consider opting in and we can take you straight over to settings.” And you can actually, like link them straight over to the settings menu and have them turn it back on. That’s actually crazy effective.

Shamanth: Yeah, yeah, you would think that has a lot of friction. But it sounds like, if you show that to sufficiently loyal users, you can still get them to opt back in.

Andy: Yeah, you can, at least with push. Not all of them will look back in, but very few of them will churn just because you asked them.

Shamanth: Right. So at the very least you want them to not churn, and the best case scenario is they opt in, worst case they can don’t but stay in the app. That makes a lot of sense. And certainly I think there’s quite a bit, as you said, somewhat textbook stuff for PNs and emails, but can definitely be applied directly to IDFA updates. 

Andy, I think this has been incredibly instructive. Both to also know and understand what the lay of the land looks like on the retention front, and also to understand the implications of all of this on the holistic growth strategies for many apps. This has been great. This is perhaps a good place for us to start to wrap up. But before we do that, can you tell folks how they can find out more about you and everything you do?

Andy: Yeah, absolutely. So I’m co-founder at Phiture and we’re a mobile growth consultancy based in Berlin, but I’m working with B2C apps worldwide. We help apps to grow. You can find out all about Phiture and get in touch with us there. We spell it with a PH. Or you can find me on LinkedIn, Andy Carvell with two Ls. 

Shamanth: Excellent, excellent. We will link to all of that in the show notes. But for now, this is a good place for us to wrap. Thank you so much for being on the show. Andy. 

Andy: Thank you Shamanth. Pleasure, as always.

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!