GDPR brought an excessive amount of changes to the world of digital marketing automation. Along with new rules, new opt-ins came new approaches - privacy first, privacy by design and need for robust data security. Most of those changes were directly related to redesigning subscription centre from the ground. Let's take a look at my journey.


Marketing Challenge

The first step was to write down all the business and legal decisions that would shape the preference management experience for our users.

The plan - create a solution that would:

1. be created with privacy by design and privacy first approach. That meant we must build the new tool in a way that makes sure that everyone has access only to his data and cannot modify anyone's else data,

2. work even without cookies enabled,

3. present only the required minimum of data and subscriptions for each user,

4. allow for easy management of not only topic subscriptions but also opt-ins - with a possibility for the client to become blacklisted on demand.

With the above points, the goal was to both get less GDPR based inquires by mail by helping users manage their preferences on their own and steer clients from blacklisting into editing their subscriptions and opt-ins accordingly, as it allows to keep contact with them on new terms.


My company's existing Subscription Center was using standard Eloqua field merges based on visitor cookie linkage which could be violated by abusing Eloqua profile priority (you can find more on problems related to it in B2B: Profile & Target). We already implemented best practice of using e-mail groups for subscription management (see B2B: Relevance and Retention) but wasn't controlling the visibility of groups based on the client data. Finally, we had quite a big problem with the reliability of visitor profile data allowing users the even see their current preferences. Which, in many cases, led them to opt for the most comfortable option - writing to us manually. Not the experience we wanted to give to our customers.


New approach required me to work from the ground. New landing pages, new forms, new e-mail footers, new Eloqua functions to make it all work.


E-mail Footers

The new approach to e-mail footers was the first and necessary element to make the whole approach achievable. I created a few dozens of footers, each containing two links. One that would unsubscribe from this particular e-mail group (by leveraging Eloqua system action) with appropriate description of that e-mail group. That system action is redirecting to a sorry-to-see-you-go LP set within the e-mail setup panel (dive deeper into all the possibilities with B2B: Configure & Calculate ROI).  It's nifty solution, as it is much easier to set up than our previous approach of (ab)using blind form submits for that. Such a thank-you landing page is excellent because of two reasons. You can become sure that customer did what he precisely wanted by giving him the option to resubscribe to the e-mail group he just left right next to strong copy saying what he lost due to unsubscription. You can also put there a link to the new preference management page where he can go even deeper with aligning communication to his needs. Two possible wins from a theoretically very sad redirect.


The second link goes directly to the new Subscription Centre. However, this time it was not a regular link. I needed something that would trump the cookie problem mentioned earlier. I had to be sure that it always shows the user his current preference data. Thankfully there is a straightforward and powerful solution baked right into Oracle's Eloqua - the PURL field merge. Adding just <span class="eloquaemail">PURL_NAME1</span> after the base URL in an e-mail link leading to any Eloqua based landing page gives you confidence that field merges, and dynamic content won't fail. On sending, it automatically changes to a unique code (for example https://website.com/MateuszDabrowski1234) that overwrites cookies and works even with stringent privacy settings of the browser. Perfect not only for preference centre but actually for any case of linking from e-mail to an Eloqua LP with personalisation.


Two Subscription Centre Forms

I decided to create two separate Eloqua forms for the new Subscription Centre - one for the preference and consent management and second only for global unsubscription. Why? It doesn't add much work to build but allows for a few niceties on both visual UX/CX (separation of the edition and deletion processes) and automation (more accessible to segment and automate based on different forms).


Global Unsubscription Form is very straightforward. Thanks to PURL in a link leading to this page, we always have the e-mail address. Thanks to it, we neither need to gather it nor even show it. Therefore, this form for the user looks like a simple button (however, it is not a standard blind-form). I also surround it with a robust copy convincing to manage subscriptions instead of blacklisting. This approach allows minimising the number of global unsubscribes. I also hide e-mail field and make it uneditable with javascript. Less distraction and a smaller possibility of malicious unsubscribing of other users. With another snippet of js code (learn more on how to leverage query strings with marketing automation: https://mateuszdabrowski.pl/posts/capturing-tracking-parameters.html) I also automatically fill hidden fields capturing both base URL and all query links. I plan on improving this approach with the use of built-in query string field merges which in this particular case are even better and simpler solution (more on them in Oracle Docs). The processing steps are explicit - globally unsubscribe the user and pass that information to external systems.


Much more interesting is the second form containing opt-ins and subscription statuses. I also use hidden query string fields and lock e-mail field from being edited for the same reasons stated above, but also show personal data processing and e-mail communication opt-ins along with all the e-mail groups used by my company as checkbox fields. Thanks to two options of Eloqua, this approach is potent for e-mail group subscription. Firstly, on the Design tab of Form, in filling tab of form field settings, I chose to set checkbox status using email group subscription value. This option makes user quickly see whether he is currently subscribed or not to each type of communication. You can find the second part that makes it even better in processing steps. There, you can control email group subscribe/unsubscribe with the state of the form field. Adding both tools means that form shows current status and any change (checking or unchecking of the checkbox) directly impacts subscription over submission.


It is a bit harder to do a similar thing with opt-ins based on data model fields rather than e-mail subscription (data processing and e-mail communication in our case). However, even for that, there is a solution – create a hidden field merge of those fields somewhere on the landing page and with small javascript snippet check or uncheck appropriate checkbox depending on the field merged value. Of course, remember always to subscribe user globally, as the filling of subscription centre form is the best way to regain your blacklisted contacts.


Landing Page

As for the main Subscription Centre Landing Page - it is easy. Just consider all the above elements (requires quite some javascript) and be sure it works nicely on mobile and done. The rest is leveraging your brand aesthetic and working on a compelling copy that that help your customers decide what communication they need. Don't limit the customers – you don't need them subscribed to everything as they may pass on the number of e-mails quickly. Instead, help them focus on what is essential for them and use that knowledge for segmentation.


P.S. If you plan on giving access to your Subscription Centre from other places (like footer of your websites) be sure to link there not SC directly, but rather a small landing page with a short form asking only for e-mail. Its only purpose is to send a mail with a link to your SC with PURL field merge. Why?  With this small action, you become sure that only the owner of the e-mail address gets to preference management tool and that all data is correctly field merged thanks to the power of PURL.


The Sum Up

Implementation of the above approach to Subscription Center allowed us not only to improve the user experience for our clients greatly but also made our lives easier. Thanks to this approach we receive over 70% fewer e-mails from our clients because they started to manage preferences on their own. And that means quite a lot of people in our company having more time for other tasks. That change also transformed around 50% blacklists into subscription tailoring, which - of course - is huge for digital marketing. In the future, I want to personalize the experience further and keep minimising negative impact and maximising the positive experience.


Thanks for reading and if you have any questions - feel free to ask. I found a tremendous amount of helpful ideas - especially on various scripts mentioned above - on Topliners and would love to give back to the community.