How Developers Can Prepare Their Apps for GDPR Legislation

When GDPR is concerned, developers can’t afford to overlook app user privacy, consent and opt-in preferences. Here’s five tips that will get you compliant.

It’s a huge problem for app publishers. How can you comply with intimidating privacy legislation and maximise the number of users that are opted into your app services?

By some estimates over 50% of current apps are not compliant with the new GDPR legislation.

That’s because apps have multiple third parties and SDKs integrated. Many of these are asking for data on users.

It’s difficult for publishers to keep track of this. But it’s now the law to be in control of this data.

It shouldn’t have to be this difficult to comply with privacy regulation. And it shouldn’t be hard for your users to opt-in and out of individual preferences.

Lucky we think we’ve found a solution for developers to manage, sync and audit consent in their suite of mobile apps.

Asking for consent and getting your users to opt-in

Complying with privacy legislation isn’t the most straightforward process.

And how do you make sure that you don’t spook your users into opting out of all services? User opt-in is important to obtain as it can be a great tool in which to drive engagement and retention, not to mention monetization.

You need to ask user to opt-in at the right time. And you need to be clear that they are in control. We tried to solve this problem by designing our consent toolkit to help developers obtain and manage user consent.

Many apps get opt-in timing wrong. Don’t ask for all permissions the first time that the user opens the app. Explaining the value that users will get in return for opting in for certain permission will mean that the user is better educated about what their data is being used for.

Make sure that your opt-in process is clear and be upfront with your users.

Manage user opt-out requests respectfully

Under new legislation is just as important to ensure that users can opt out as it is to obtain consent properly in the first place. To do this publishers must have a system in place that can allow their users to opt out of some or all of the permissions that they have previously opted in for.

This was one of the fundamentals that shaped the way our consent module works. We wanted our toolkit to make it as easy for users to opt-out and it is to opt-in. This needs to be done in a way that doesn’t just put the user in control of their data but allows them to choose which kinds of data is used by publishers.

Make sure you can manage consent across devices

Consent and user opt-in management are difficult enough to get right as it is. But this can be made nigh on impossible when you consider the fact that app users are constantly deleting apps and changing devices.

Syncing user settings are important because if a user has revoked a permission on one device then to continue to use this could be a breach of privacy regulation. Also, if a user requests that all their data be deleted, this is difficult to do unless you can identify everywhere that the user has given access to data.

That’s one of the problems that the consent toolkit was built to solve to solve. By using a series of unique identifiers it’s possible for developers using the toolkit to sync consent preferences. In this way, the consent toolkit manages a users consent and opt-in/opt-out preferences whenever they interact with an app or service.

This is especially useful when a user requests their data be deleted (or in GDPR terms — right to be forgotten). Having a toolkit that syncs across devices allows publishers to remove this data and stop collecting it wherever the user is seen in the future.

Sometimes it’s a messy infrastructure. What happens if a user updates consent preferences in one app, but uses other apps from you? Make sure you can sync this preference across your real-estate.

Integrate user consent with third parties

Apps rarely run in isolation. You might have third party services, or other SDKs that have access to our user’s data.

These need to be kept in sync with the user’s opt-in preferences. If your user says no to communication, this needs to be updated with third-party advertisers for example.

At Tamoco, our consent module allows apps to instantly update third parties with new user preferences. If a user asks for all of their historical data to be deleted this information needs to be relayed to third parties.

The consent SDK communicates this to third parties automatically when a user’s preferences are updated.

Information of this is then secured in a secure audit trail. The consent module will automatically ask third parties to confirm that they have received these requests for changes in a users preferences. When this is (or is not) received this is saved in the audit trail, along with timestamps and relevant information.

This means that developers can ensure that their users’ opt-in preferences are respected in third-party integrations. It’s important to be able to follow an audit trail to prove that this information was relayed to third-party partners and integrations such as SDKs.

Make sure you have a secure audit trail

With the correct procedure in place, developers don’t need to worry about manually managing consent. But what happens if you ever need to prove that your app has protected user data.

App developers need a way of storing the history of user consent. It should be easy for developers to prove that historical consent has been obtained.

In our consent toolkit we provide developers with an audit trail to do just this. Everytime a user changes their consent preferences then the SDK automatically records this with time stamp.

This ensures that app publishers are always covered. This information is easily viewed and provided for reference. Third-party consent is also stored in the audit trail. All requests for opt-out are sent to third parties and the record of this is then stored in the audit.

The consent toolkit is available for free for a limited time to early subscribers. Head here to get access.