Consent on mobile and apps: 4 challenges

While every website and app publisher dreams of cross-device consent management, the reality is easier said than done…here’s why.

While ‘mobile first’ has become a very hot buzzword, in practice, mobiles and apps still find themselves too often second best to the web. And nowhere is this better seen than with consent management. In the wake of the GDPR (General Data Protection Regulation), attention and energy towards consent has been focused on websites, despite mobile apps being just as affected by the regulation. And what’s more, they present a bigger technical difficulty due to the pure nature of mobiles. Let’s look at 4 key challenges.

1) Dealing with an intermittent network connection

The main difficulty for mobile is designing a way to collect consent with no guarantee of a continuous internet connection for communication between the client and server. If an app can be used in offline mode, there is only option: take advantage of one of the main benefits of a mobile app…it’s ability to save data locally.

This means that, if the smartphone is offline, all the actions performed on the app must be saved. Once the connection is re-established, the consent choice (accept all, accept some or reject all) will determine whether the all or part of the data is sent to the CMP (Consent Management Platform), or if it is completely deleted. Whatever the case, the mobile app must include this buffer storage mechanism for offline data.

2) Design the consent request for the device UX

Correctly managing consent on mobile and apps is not just a technical matter. You also must ensure that you don’t compromise the user experience. Reusing the same desktop pop-ins is out of the question, even if you make them responsive. When we consider the varying extents to which obstructing the screen is tolerated on mobile and desktop (how much the pop-in covers the content), and the different methods for collecting consent, there is more than enough justification for a tailor-made UX. Even just the design of the accept and refuse buttons is worth a different approach on both formats.

When it comes to an app, you often need an entire screen dedicated to collecting consent. But when should this screen be shown? The answer is different for each publisher, because it depends entirely on the nature of the app. Who is the audience? Does the app require instructions? For example, it might not be wise to display this screen before giving the practical information needed to actually use the app. A/B testing could be put to good use to identify the scheme that best retains the user.

3) Collect specific consent

Obviously, every website and app publisher dreams of deploying a cross-device consent mechanism. The aim is pretty clear: to communicate the consent choice given on a desktop to an app, thus avoiding having to repeatedly ask the user. A praiseworthy intention, which is unfortunately beyond the limits of technical possibility for the time being. Even on the same device, ‘breaks’ in consent are inevitable: a user who gives their consent on a smartphone browser when viewing a publisher’s website will be forced to give it again if they use an app from the same publisher on the same phone.

But what if the user logs in on both ends (on the website and the app)? Yes, in this case, the consent is linked to a logged-in account, and so can be ‘retrieved’ between the app and the website. But, on one condition, which for once isn’t technical: the consent given on the website is only valid for the app if the services activated on both are the same…

Remember that the GDPR stipulates that for consent to be lawful and honest, it must be specific. In practice, the services used on an app and website — and thus the data sent to partners — are different. Adservers, for example, are rarely the same between mobile and desktop. The same goes for A/B testing solutions.

In short, for technical and legal reasons, consent must — for now — be collected separately for each device (desktop, mobile) and environment (website, app).

4) Archive consent

Another key principle of the GDPR to bear in mind is accountability. Simply put, each publisher of a website or app must not only be able to collect consent in compliance with the GDPR, but also be able to prove it. Hence the importance of archiving consent choices and the subsequent activation for all devices and environments. Incidentally, this is one of the key features of Commanders Act’s CMP: archiving consent across all devices.