19 Replies Latest reply on Sep 28, 2018 7:46 AM by Tammy Sims Coan

    GDPR handling of consent to marketing

    Carly Stevens

      Another GDPR related question from me!


      How are you dealing with consent if someone does not consent to marketing comms/opt-in? I.e. Are you linking this up with the unsubscribe field?


      If not, how are you implementing it so that those preferences are respected?

        • Re: GDPR handling of consent to marketing
          Dan Stevens.

          We are not associating "not opt-in" to "unsubscribe".  Rather, we're just making sure that - unless the person has "opt-in = true" - they won't receive marketing emails.  Actually, in our case, our main opt-in field - the one that appears on all of our forms - is an opt-in to all marketing emails.  We also have a preference center that we drive folks to from the "unsubscribe" link in our emails - where they can opt-in/out of specific types of content, instead of unsubscribing fully. 


          So what we have done is create a series of "master" opt-in smart lists in our global/default partition (we have 23 country lead partitions) - which are then shared across all workspaces.  Each smart list is aligned to our preference center groups, along with an all-up opt-in smart list:


          • Opted-in to all marketing emails
          • Opted-in to campaign-related emails
          • Opted-in to event invitations
          • Opted-in to country newsletters
          • Opted-in to blog updates


          Then for every email send, we must filter against the appropriate audience smart list (in addition to whatever other filters are necessary).  These filters are baked into all of our program templates to ensure no one forgets to include them.  And since the country partitions only have access to their country data, there's no need to create these smart lists within each partition.  Only those people within those countries will be exposed and qualify for any send campaign in each country workspace.

          4 of 4 people found this helpful
          • Re: GDPR handling of consent to marketing
            Grégoire Michel

            Unlike Dan, we prefer to associate the 2 fields, so that we are sure that we remain error proof in case a local user forgets to use an opt-in list.


            But we do that association with some JS at form level, not with smart campaigns.


            We also have a some preference centers that enable people to fine tune their opt-in.


            So in fact, the "Opt-in" field is only used on lead capture forms such as event registration, content download or contact forms. And it is shown only for new comers (unknown leads). In these forms, if the person opts in, the in the form background, the unsubscribed field will be unchecked.


            The preference center does not show the "global" opt-in field but rather the options and the unsubscribe field (which corresponds to the "subscribe from all communications" option). in the PC, if the person opts out, in the form background, the opt-in field will be unchecked.



            1 of 1 people found this helpful
            • Re: GDPR handling of consent to marketing
              Christina Zuniga

              Don't unsubscribe someone just because they don't opt in, that should only be used for an affirmative "don't talk to me anymore". Use a separate field to track what level of permission you have (mine is called "permission status"). That way you can have "affirmatively opted in", "affirmatively opted out", "nebulous gray area where they didn't say yes or no and two groups of this, one where I have the right to talk to people (ex: USA people) and one where I don't have the right to talk to people (ex: Italian people).

              I can't show you my full workflow (sorry) that tells me logically how each person falls into each bucket, but here's the bottom of that decision tree and the colored boxes are my permission statuses. I made it pretty straightforward in terms of color what is good vs. what is bad , but mostly because this document is for non-Marketo people to understand what our permission means.


              I'd recommend something like this so you can logically group people.


              2 of 2 people found this helpful
              • Re: GDPR handling of consent to marketing
                Michael Collins

                Hi guys,

                but surely this is GDPR non-compliance...? You say that you add a person's record to your database and if they don't opt in then you don't email them...right?

                But surely the Opt-in relating to GDPR isn't about whether you can email them or not, it's about whether you have their consent to process their data - which if they don't opt in, then you don't have their consent, so you can't store/process the data - whether you send emails to it or not. So surely the people who do not opt-in - after a certain number of tries, or a certain period of time passes - must be deleted...not flagged as suspended or unsubbed...

                  • Re: GDPR handling of consent to marketing
                    Christina Zuniga

                    Michael Collins, I have a separate way to processing data opt in so someone can be in my database in any permission level and be opted out of data processing. That's a separate issue.


                    As for being in the database at all, it depends on your data retention policy. My point in getting to a permission level depending on their requests and their actions actually helps me determine how long I can keep the record. If they are marketing suspended and came in via a Salesforce contact from international sales but aren't in a current opportunity, I have far less time to keep them in my database than if they fill out a form and request sales information. So I'm using my permission status to help me determine how long I'm allowed to keep those records in my database.


                    You need to review (or create!) a data retention policy that makes sense for your business. If your average deal takes 1 month to close, is it reasonable to keep a new prospect record for 3 days? Probably (#IAmNotALawyer). 1 year? Probably not. Depends on what your lawyers and company decide to do.

                      • Re: GDPR handling of consent to marketing
                        Michael Collins

                        Ok - maybe I got confused then because I thought this post was about gaining consent, so storing data and emailing it might be 2 different things. Our lawyers have been discussing this for almost a year now! - I think we will end up with a '3 strikes and you're out' policy - so we will attempt opt-in 3 times and if we don't get it then we will delete...

                          • Re: GDPR handling of consent to marketing
                            Grégoire Michel

                            Hi Michael,


                            1. Opt-in to store and opt-in to send emails are indeed 2 different things, indeed, and both are required
                            2. No one can fill out an online form without being stored in a database somehow, even if only for a few seconds. Therefore, in theory, it should not be possible to fill out a form without optin-in for data storage
                            3. some companies (including Salesforce BTW) have resolved this in having a mention one the forms that say that, by filling out the form, people agree with the data privacy policy. Others prefer to have one opt-in field but end up with some huge complexity about removing (which kills reporting) or anonymizing (which cannot be totally done) the data



                              • Re: GDPR handling of consent to marketing
                                Tammy Sims Coan

                                Great information here around the flows for consent. Is the opt-in data being stored in SF as the system of record? We are debating whether we need to create new fields in SF to store the opt-in acceptance and date. By default, if they fill out the form with the opt-in checkbox, we know they opted-in. But there is a sense this should be captured and stored in SF.  And the SF admin does not want additional fields unless really necessary. Any recommendations would be greatly appreciated.