Keys to a Healthy (Data) Relationship for Banks and Credit Unions

It’s already February, which means almost every marketing agency out there wants to remind us of the month’s biggest holiday: Valentine’s Day. Whether it’s an opportunity to cherish that romantic moment with a loved one, or perhaps a painful memory of a bad relationship that comes to mind, it’s important to remember that not all relationships have to be personal and intimate – some are downright boring.

Have you ever been on a date where the other person didn’t listen to anything you said, repeated themself, and only focused on their direction? Chances are you didn’t feel the best connection, but for whatever reason you’re still stuck with them. The same thing can happen in Salesforce Marketing Cloud if you don’t have healthy data relationships! When dealing with data, these are the keys to preventing a bad relationship with your customers.

Keys to a Healthy Relationship

key iconWhen dealing with data, you’ll run into the common task of needing to update it. It’s normal to begin to wonder “Where does this data belong? How does it relate to my customer? How can I use it?”. The Key to keeping your relationships clean and effective is by using Primary Key (PK) fields. Identifying a primary key is essential to separating your records into respective rows, ensuring that any time you perform an update on your data, you’re not creating extra rows for pre-existing records. Primary keys also allow you to keep a complete picture of your customer and all the information you have about them. It creates a “single view” of your customers. Common examples for primary keys are a contact ID from Salesforce or GUID: a random number string generated at sign-up. Upon setting up Marketing Cloud you’re asked to choose a Subscriber Key. This acts as the Primary Key for every single one of your Marketing Cloud subscribers. As you choose your Subscriber Key, the most important thing to remember is how all of your other supporting data will “tie” back to this Primary key.

Key (slanted) iconAnother challenge you’ll face is merging or relating data from different systems. If you’re lucky, you’ll be able to identify a common PK field between the two data sources and merge them into one, but rarely is it that simple. One easy solution is to create a new “staging” data table that contains the primary keys from both data sources and how they relate to each other. For example, one key as the Subscriber Key (AKA Contact Key) and another one from the system you’re trying to connect to. You can add other fields for reference to be sure you know how the two tables relate using the keys you’ve chosen. This process allows you to find the common connections between the two tables.

tilted key icon

Another way a relationship can be established is with a Foreign Key. A Foreign Key acts as a way of tying one data set to another through their respective PKs, allowing the tables to co-exist independently and yet in sync for whenever you need to scope your customer’s full portfolio. A relationship is essentially creating a shortcut to all the continuous and demanding querying of the data – a performance issue that really adds up when reaching millions of records per table and especially when timing is crucial.

The 4 Types of Relationships in Data Modeling

Now that you’ve got the keys, you’ll find when it comes to relationships, you’ll see these four types of cardinalities:

4 types of SFMC relationships

1:1 One-to-One, 1:M One-to-Many, M:1 Many-to-One, and M:M Many-to-Many.

In a 1:1 relationship, only one entity from Group X can match up with only one entity from Group Y. In a 1:M relationship (and M:1), an entity from Group X can match with multiple entities from Group Y, or vice versa. In a M:M relationship, several entities can be related to several other entities. An example would be when an employee works on multiple projects, and a project has multiple employees.

An Entity (Attribute) Relationship Diagram, or ERD, is a type of flowchart that illustrates how objects are related to each other. Conceptualizing the data model first can help recognize the logic. For example, sometimes the entities in your relationship aren’t objects, people or ‘nouns’ – instead they’re actions, ideas, or ‘verbs’ like a financial transaction between two accounts or when an artist performs a song. Mapping your relationships (using SmartDraw or LucidChart) will help you master the logistics of your entire system. Below is an example:

Example ERD Chart for Credit UnionOnce you’ve established how all the relationships operate, you’re ready to create an Attribute Group in SFMC, which allows you to link multiple Data Extensions together. The Attribute Group configuration is essential when linking contact data in Salesforce. Read more about how to apply relationships within Contact Builder’s Data Designer here. Below, you’ll see an example of what that might look like for an Insurance data structure:

Attribute Group Example

Apply Relationships to Journey Builder

A strong case for healthy relationships can be applied to your Journey’s Entry Event. Via Attribute-Relationship configuration (above), you’ll have the ability to filter your incoming records without having to restrict multiple entries – a commonly-used workaround solution when dealing with records that have previously exited your Journey.

You can also use relationships in Decision Splits for a much faster output and more safeguards to eliminate unwanted duplicates. Note that you can only use 1:1 relationships in Decision Splits – otherwise you’ll have to create a Staging DE. Read more about attribute-to-attribute comparisons here.

The Bottom Line

Credit Unions and Banks have more data than ever before and it’s not only useful but imperative to understand and model the data to truly understand the customer journey. Healthy data is the first step to setting yourself up for a healthy relationship. Creating smaller Journey data sets you up for faster results, especially when that performance means the difference between real-time data and delayed results. Creating relationships also eliminates the need to create extra Journey data and allows your Salesforce Financial Services Cloud data (or SFDC Contact data) to remain the sole source for all your master data records. In the end, allowing all parties to maintain a cohesive and unified relationship will be the keys to your success.

Written By:

Share this article