# Don’t Let GDPR Kill Your Marketing Automation - Link: https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/ - Published: 2018-03-15T12:03:55+01:00 - Author: Ed Burrows #### Some practical guidance for US-based apps on approaching email and mobile marketing automation post GDPR. ⌊Don’t Let GDPR Kill Your Marketing Automation ⌉⌊Don’t Let GDPR Kill Your Marketing Automation ⌉ **Disclaimer_: _**_This post is not legal advice and should be considered only as guidelines in your GDPR planning. You should work with your legal counsel to make the right decisions based on your business needs and circumstances._ I’ve read a lot of general perspectives on GDPR out there, but not a whole lot that’s practical, especially for those of us handling marketing automation. As a growth practitioner who has lived and worked both in the US and now the EU, I’m well aware of the challenges that US apps face when it comes to adhering to EU protection laws. The consumer web and mobile app space has its own set of considerations that differ to say a publisher, adtech provider or lead gen for B2B services. There’s a number of choices that you have to make especially around consent, and I intend to address them one by one. This post is intended for marketers and product managers that already have a general idea about GDPR and want more practical information on changes to your product. Table of Contents * [Should you comply?](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#should_you_comply) * [Determine your legal basis for consent](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#determine_your_legal_basis_for_consent) * [Option 1: (Explicit) Consent](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#option_1_explicit_consent) * [Option 2: Legitimate Interest](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#option_2_legitimate_interest) * [Legitimate Interest Assessment Test](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#legitimate_interest_assessment_test) * [Right to be forgotten](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#right_to_be_forgotten) * [Email notifications](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#email_notifications) * [Final thoughts](https://phiture.com/mobilegrowthstack/dont-let-gdpr-kill-your-marketing-automation-ba127877f011/#final_thoughts) ## **Should you comply?** If you’re a US-based company with an international user base, this does not automatically mean that you’ll have to divert precious engineering resources to changing your product and sign up experience. While what you’ve heard is true in that [Article 3](https://gdpr-info.eu/art-3-gdpr/) on territorial scope specifically protects EU citizens even if your app has no local presence in the EU, [Recital 23](https://gdpr-info.eu/recitals/no-23/) is clear in that users in the EU **must clearly be targeted**. In practice this means if your app is not language localized in the EU, you don’t allow users to purchase in euros/GBP and specifically don’t mention EU countries in your product or marketing, then you likely don’t need to comply. That’s not to say that if you intend to drive revenue and growth in the EU that you should try to dodge compliance, don’t do that, it’s a fast way to get fined and apart from anything else is unethical. But it does mean you have options. A caveat to the above is that if you track EU users, even if you have not specifically targeted them, then you must also comply. For practical purposes, this would mean tracking their activity in your app with an event tracking service (e.g. analytics suite or AB testing tool) or CRM. To avoid this you would need to adopt an approach whereby you ceased tracking these users once you knew they were EU-based and purge the data from your internal data warehouse, retaining only a unique identifier as a signal not to retain any data on that user. ⌊Breather example⌉⌊Breather example⌉ _Even though Breather doesn’t offer services anywhere on the EU continent, it does offer locations in London that are listed in £GBP. Therefore they would likely have to comply with GDPR._ The above is important in that some simple product roadmap decisions for the coming year could save you significant resources. For example, you could delay or avoid localizing marketing to EU territories or even remove euros from your payment pages. Resist the knee-jerk temptation to comply with GDPR requirements if you have a genuine case that you do not envisage offering goods or services to EU users. #### **Model the impact** So you’ve decided you have a case to either comply or not to comply. Which way should you go? Like every good growth practitioner, we need to model the impact against other growth priorities. Here’s an approach that I’ve recently run through with a [Phiture](https://phiture.com/) client. * Break out EU users * Break out users by funnel stage * Apply baseline conversion rates to key metrics * Estimate likely impact If you are a US-based app, you likely already know how many users you have in the EU and if your app is in English then it’s a good bet that a significant number of your EU users are in the UK (sidenote: Brexit outcome will not affect GDPR compliance for the UK). By breaking out your users by the funnel stage you will be able to apply the appropriate conversion rate uplift that your campaigns are driving for each group. Your metric obviously depends on your business and how deep you want to go, but in a freemium app, you’ll be using a retention metric and a paid conversion metric. In an ideal scenario, you have a global hold out group so that you know exactly how much impact your marketing automation is driving for each segment. In this case, it is fairly easy to calculate exactly how much drop off in retention/ engagement/paid conversion you would have if you simply turned notifications off for your EU base. ![EU users by funnel stage example](https://phiture.com/wp-content/uploads/2018/ 03/EU-users-by-funnel-stage-example-min.png) Without a global hold out-group, it will be more complicated, you’ll need to calculate the reach of your notifications taking into account push/email/channel opt-in rates at a campaign (or series level). So for new users, you’ll have your onboarding, for active users your engagement and upsell campaigns and win-backs for inactive users. ![Addressable audience by channel example](https://phiture.com/wp-content/uploads/ 2018/03/Addressable-audience-by-channel-example-min.png) I could do a whole post on just this part but will leave it here for now. The important thing is to have at least some data which you can take with you to your stakeholder meeting to make a case for compliance or non-compliance based on impact and org goals. ## **Determine your legal basis for consent** This is where there appears to be the most confusion around GDPR and marketing automation. It is **not** necessary to obtain explicit consent from users in all cases, as there are actually 6 different legal basis’ for consent. An area where I see the most confusion is email marketing, where every GDPR post would have you believe that explicit opt-in is necessary. This is not necessarily true as this may be covered by legitimate interests. The 6 legal basis for consent are: * **Consent** * **Legitimate interests** * Contractual necessity * Compliance with legal obligations * Vital interests * Public interest For the purposes of this post, we are only going to be concerned with the first two, (explicit) consent and legitimate interests. While the others are also important, these are the most pertinent for most marketing automation. ## **Option 1: (Explicit) Consent** In a practical sense, obtaining consent involves asking a user if you can use their personal information for the purposes you intend, clearly and upfront. That means your sign up page and database where you store this information is going to be the most important area to consider changes. This also extends to any third-party services which are processing this data for you, so marketing automation services such as Braze or Leanplum, multiplexers like Segment or mParticle and ESPs like Sendgrid. You also need to get permission from your existing users assuming you don’t have GDPR compliant consent and/or proof of it. #### **Proof of consent** One of the most important tasks if deciding to capture consent is recording that consent so that you can prove when, how, and what users were told when they gave their consent. In practical terms, this is likely going to mean a new table in your database to record timestamped consent along with the exact message and place that it was taken. You’ll want to include your signup page messaging at the time of consent for new signups or in the case of existing users, whatever mechanism you use to repermission them. **Acquiring consent** Grounds for consent are very clear in [Article 7](https://gdpr-info.eu/art-7-gdpr/), in that unless the request is “presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form” the consent is invalid. That rules out burying the language in terms and conditions. Consent must be an affirmative act and [Recital 32](https://gdpr-info.eu/recitals/no-32/) goes even further to describe that “silence, pre-ticked boxes or inactivity should not, therefore, constitute consent”. Immediately we can see the UX and conversion- related problems with this approach as most people do not read long small bits of copy, especially when requiring them to check a box. “Consent should be given by a clear affirmative act… silence, pre-ticked boxes or inactivity should not, therefore, constitute consent”. So while obtaining consent is the safest and arguably the best implementation in terms of putting the user firmly in charge of the use of their data, when it comes to receiving highly relevant and personalized marketing notifications by using their data, it is not ideal. To continue sending notifications to users that did not give consent to have their data used for that purpose would mean sending them unpersonalized notifications which in today’s world, feel like spam. This would result in the users ignoring them at best and at worst, getting frustrated and turning off notifications or churning. This is why another legal basis for consent may be preferable for both marketers and users alike. ## **Option 2: Legitimate Interest** While Legitimate Interest takes more work to substantiate, it is the most flexible basis on which you can choose to process data. Essentially you can make use of a user’s data for the purpose of a legitimate interest, which can be your own interest. In fact, [Recital 47](https://gdpr-info.eu/recitals/no-47/) specifically states that “The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest”. As long as a user’s interests or rights do not outweigh your legitimate interest then you have a case (sidenote: if you are dealing with children’s data in any way then you need to be extra careful here). “The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest” To think about this in practice, it is helpful to ask if your use of the data fits the reasonable expectations of a user based on their relationship with you. This is where many companies are getting confused and are taking a complete risk-free approach when it is not absolutely necessary. Think about the case of taking an email on signup, is it reasonable for a user to expect you would use their email address to send them a welcome email and use their location to set the language of the message? Many would argue yes. If choosing Legitimate Interest as your legal basis for marketing to users, then it’s vital that you conduct a thorough assessment of your marketing data use not only to make sure you are compliant but to substantiate in the event of a dispute why you used a user’s data in that way. ## **Legitimate Interest Assessment Test** Probably the most practical guidance out there on reasoning a legitimate interest case is the [LIA recommended by the UK ICO](https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/legitimate-interests/). Head over there to get the complete questions they recommend. Essentially you want to objectively think about and write down your results to ensure you have a robust reason for using legitimate interest. One of the kickers in the necessity test is whether there is another reasonable and less intrusive way to achieve the same result. This is the biggest grey area for marketing automation and is where you will want to decide with your legal counsel whether explicit consent is required. Obviously, legitimate interest can be a tricky thing to assess, but the important thing here is to not take a one size fits all approach. To conduct the LIA I suggest breaking your users up into funnel stages in order to individually score what each user might reasonably expect from you. You will likely end up with a sheet that looks something like this: ⌊Legitimate Interest Assessment Test ⌉⌊Legitimate Interest Assessment Test ⌉ [_Questions source _](https://ico.org.uk/) You may have more user types than this but this would be the baseline for most consumer apps. You can already see some problem areas here. While we could assume an active engaged user or even a new user would have a reasonable expectation to have their data used in certain ways, this is less true of churned users or users invited through a referral loop sent by your app. In particular, churned users call into play the final part of GDPR that we will discuss in relation to marketing automation. ## **Right to be forgotten** The right to erasure is a core piece of the GDPR code and most people understand it in terms of a user requesting that their data be deleted. This comes with its own set of challenges in terms of purging data from CRMs, data warehouses, martech vendors, and remote backups. But what is also stated in the code is that “a data subject should have the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary in relation to the purposes for which they are collected or otherwise processed”. If you have a pool of inactive or churned users (which you most certainly do) and you run win back campaigns, then you could very easily be infringing a user’s right to be forgotten. Unfortunately, there is no real rule of thumb here but given the right to erasure and a user’s reasonable expectations for the use of their data, you can see that inactive users start to become a problem area when consent has not been obtained. You will want to work with your legal counsel to establish a timeframe for when you should cease sending users notifications and purge their data from your CRM and data warehouse. ## **Email notifications** Having run email marketing at SoundCloud for two years, I understand the intricacies of international email law. Email is its own special case as it is not only affected by GDPR but also has a set of legal requirements as a result of the EU eprivacy directive (equivalent to US CAN SPAM law). Growth practitioners that run email seem to be getting confused between these two sets of laws. ⌊How GDPR and PECR work together in email marketing⌉⌊How GDPR and PECR work together in email marketing⌉ _[Source](https://www.communicatorcorp.com/) _ The GDPR affects email marketing insofar as personal data is generally required to perform the email marketing itself. The most obvious personal data is the email address, but location data, name personalization and other associated data, when used to personalize, is all data required to segment, trigger and send the email. The EU ePrivacy directive on the other hand is interpreted and legislated by each country differently, but essentially requires some level of consent to send email to a user. This is where I see a lot of people getting the interpretation of consent wrong around GDPR. While countries such as France and Germany require explicit opt- in (think unchecked checkboxes) for email permission, the UK and some other countries only require implicit consent. Although some might argue for explicit opt-in for email as best practice, it is not necessary for legal compliance across the entire EU (yet). An in-depth discussion of email law is beyond the scope of this post but there is already a [selection](https://litmus.com/blog/the-ultimate-guide-to-international-email-law-infographic) of [great resources](https://blog.chamaileon.io/ultimate-email-spam-law-collection/) out there if you are a US company looking to start email marketing in the EU. The important thing is to be aware of, and factor these into your planning for GDPR so that your product changes are compliant and address ePrivacy as well as GDPR. ## **Final thoughts** GDPR is as much a matter of interpretation, doing objective assessment and building a proper case for marketing to your users as it is a strict set of rules to abide by. Until we have a defined set of case law to go from, you are essentially making decisions based on your comfort level with risk when it comes to using personal data for marketing automation. Avoid the temptation of letting fear dictate your strategy for GDPR and make informed decisions that not only abide by the ethics that the code was built for, but also balance it with the need to perform valuable marketing automation that drives the engagement of your users.