Have you found yourself dedicating more and more time to making lead preference changes across your martech stack? Privacy and compliance in the era of GDPR, CCPA, and CASL have large organizations twisted up in complicated solutions such as creating new fields in each of their systems with application-specific preferences and then point-to-point integrations to share that data across applications- sound familiar?
We have three words to save your sanity – Centralized Preference Management.
What is Centralized Preference Management?
Centralized Preference Management controls privacy and preference permissions from multiple sources and synchronizes the data across your tech stack.
In addition to managing overall preferences and eliminating errors, successful preference management reconciles preference data before it enters your MAP database. This increases deliverability and customer engagement, and decreases your database size, potentially saving you money at renewal time.
A centralized preference system can also protect your company from legal risks and limits the chance your organization could violate a contact’s privacy preferences. It creates an accurate trail of preference changes that can be audited. As always, when it comes to privacy compliance, be sure to check with your organization’s legal team to make sure you’re in alignment and following your organization’s approach.
Why should companies implement Centralized Preference Management?
When you think about your current preference management problems, do you find yourself agreeing with the below questions?
- Does your lead preference information span multiple systems across your organization with no single source of truth?
- Do your contacts provide conflicting preferences through different data capture points with no way to reconcile?
- Do you struggle to determine the winning preference so you know which should remain and which is overwritten?
If this is you, it’s time for your organization to implement a centralized preference management system to manage these issues and inconsistencies.
How should you implement Centralized Preference Management?
Now that you understand WHY you need a centralized preference system, you need to decide whether an out-of-the-box or custom solution is best for your organization.
While off-the-shelf preference management solutions are available, organizations need to remember to account for the soft costs of internal time and resources it takes to integrate all required applications and assess the difficulty in switching providers if needed in the future.
Another option is developing a custom solution using an iPaaS platform, such as Workato, that can be used to build this flow as an API with managed authentication. Workato also has an event bus with pub/sub features that allow you to publish permission change events to topics. Other applications throughout the enterprise can then subscribe to this topic to receive the changes at pre-determined sync intervals.
This graph breaks down some of the pros and cons of a custom approach versus an out-of-the-box solution.
Considerations of a Custom Centralized Preference Management Solution
If you decide to pursue a custom preference management solution, there are a few things you should consider when building a new flow.
First, how often do you need your preferences to sync?
- If you DO NOT need a near-real-time preference sync, rather than using an event bus you can create a nightly job that enables each application to import any updated preferences from your central database. This will reduce network chatter as applications will always pull the latest preferences one time each day regardless of how many times a contact’s preferences may have changed.
- If you DO need real-time sync, you can also treat your database as a subscriber. Applications could subscribe directly to these changes and in parallel, you can subscribe to your database as a recipient. In this way, you’re setting up more of a parallel flow where the database and your applications are receiving the latest updates at the same time. The key here is to log each change and to store the latest record somewhere. The drawback of architecting the solution in this way is that any merging logic you have will need to be owned by each application rather than being managed centrally.
Next, pay attention to infinite loops. You’ll want to make sure that when applications receive any updated preferences from your central service, this update doesn’t trigger them to send an update to the API again. Updates that come from your central preference management service should be stamped to enable you to filter them out of triggering an update to the central database.
Finally, there are clear legal implications to any solution you implement for regulatory compliance. One of the benefits of out-of-the-box preference management systems is that legal risk is assumed by the platform provider, at least in part. That said, the benefits of a home-grown solution are lower cost, increased control, and stronger data security since you’re not sending data to a 3rd party. You should weigh the benefits of both approaches with your legal team to determine the path that works best for your organization.
One last thought to remember is that privacy laws and internal processes for complying are constantly changing. You want to ensure that you have a centralized preference management system in place that can flex to evolving needs and that gives you full control over the processing logic.
As you think about the next steps of centralizing and automating your preference management systems, think about the long term. Does an out-of-the-box solution fit your needs and will it be able to scale? Or is a custom solution with its own initial costs and set-up, be the right course for your organization?
Have questions or not sure where to start? Let us know if you need help reviewing approaches and tackling your preference management!