Data Management for Marketers: 101 – Know What You’ve Got

February 22, 2021February 22, 2021 Stan

Marketing used to be simple. Think back to the golden era of advertising and ‘Mad Men.’ Don Draper would be lounging back, sipping an Old Fashioned, and crafting the perfect slogan to capture the hearts and minds of the country. Businesses placed their faith in these modern-day bards and put their businesses on the line, based on the ‘buzz’ created by advertising then BOOM – money!

In today’s world, data is the lifeblood of marketing, and modern marketers use data for everything from crafting a message, targeting an audience, and measuring results. Gone are the days of marketers trusting their gut, blasting generalized messages to broad audiences, and determining effectiveness based on reach instead of on results. Modern marketing needs to be data driven, but many marketers do not have a good understanding of their data.

Write It Down

In many businesses, people will come and go as they change roles or leave the organization, but the department, systems, and processes remain the same. This fact alone should be enough to understand the importance of documentation. That said, I’ve lost count of how many times I’ve asked clients a question they can’t answer and their response is that ‘so-and-so set it up, but they are no longer here.’ Institutional knowledge about core systems and processes should not be a secret. We even see this in our private lives, people share their relationship status to make it ‘Facebook official,’ or ‘post pics or it didn’t happen.’ Knowing something or saying that something happened isn’t sufficient, we demand proof. This is the same in marketing, and business in general; if it’s important, then it should be written down.

I’ll get off my soap box. If you’ve read this far, then you’re already nodding your head and saying to yourself, ‘yeah, this is great, but HOW?’

Three Tools for Marketers to Know Their Data

There are countless tools to help marketers manage their data and there’s a literal alphabet soup of acronyms: DMP, MDM, CDP, EDW – and the list continues to grow. While these tools are great, they also require a certain existing level of understanding of your data and are out of reach for many organizations due to resource limitations. There are however, three simple tools that every marketer can use.

Data Dictionary

A data dictionary is exactly what it sounds like, a dictionary of your data. This can be a text document or a spreadsheet that defines every data point that is important to your marketing processes. A great data dictionary will include the following for every data point:

Internal field name, also referred to as the ‘display name.’. This is the name of a data field as it is shown in the associated application used by marketers.
Database field name, this can sometimes be called the ‘integration field name.’ IT and technical naming processes are generally not very user friendly, but work better for computers.
Data type, the type of data stored in a field. Common data types include text, date, and numeric and depending on the platform, have a multitude of other options.
Field values, the expected information to be stored in the field. In some cases, the values can be anything that match the data type of the field, or in other cases, the values restricted to a specific set of values as defined by a lookup table or pick list.
Character limit, the number of characters that can be stored in a field. This can be especially important for text fields where data could be lost or rejected if a value has more characters than are allowed in the field.
Data source, where the data comes from. Is it provided via import or integration from another system, or maybe it’s system generated, or user provided? Knowing the different paths that data can be provided to the field can be very useful for understanding what the data means and how trustworthy it is depending on the source.
Data requirement, this indicates if data is required in the field for a record to be stored in the database, or if the value is optional. In the case of an email marketing platform, email address should be required for all contact records, as an example, but data may not be required for the contact’s state, though you may want to have the ability to store and use that data when possible.

Martech Stack Diagram

A martech (marketing technology) stack diagram provides a high-level overview of the various tools used by marketing to communicate to their customers at different stages of their customer journey across multiple digital channels (CMS, CRM, Web Analytics, Advertising Platforms, etc.). Martech stack diagrams can range from having a very technical focus, focusing on integrations between different tools, to identifying the type of tools available as well as where gaps exist, to the part the tools play in a customer’s journey. Martech stack diagrams have even become so popular that you could win an award, the Stackie, for a great martech stack diagram.

Entity Relationship Diagram

An entity relationship diagram, or ERD, is similar to a martech stack diagram, but is much more technical, typically going deeper than the platform or application level to identify the specific data tables or objects used by a platform and not only how they relate to each other, but also to the data objects in other platforms. There are three primary types of ERD models for data and software:

Conceptual, this is the highest level and least granular and is pretty similar in concept and purpose to a technical martech stack diagram, where the different tools or platforms are indicated and connected with lines to other platforms on the diagram to indicate data integrations. A conceptual model is often the starting point for more granular types of ERD models.
Logical ERDs go deeper than the platform level to identify the different data tables or objects in a system and the fields, called a primary key, used by each object to link data from one object to another.
Physical ERDs take it to the most granular level, indicating not only the objects and primary keys in a system, but also all of the other details to create a database including the other fields in each object, the data types, and other technical details about how the database is architected. (You would also have much of this same information in your data dictionary, which could serve as a compliment to the ERD.)

I won’t lie, developing these tools takes a lot of time and effort, but this will lay the groundwork for your organization to gain a better understanding of the data you have available today, what systems it is available to, and where you have gaps in data or integrations. Over time, these tools will help you evaluate what changes are to be made – what systems and data are redundant, which are unused, which are critical and what new tools and integrations are needed to fill the gaps.

If you have a question as you prepare your documentation, give us a call. Relationship One is always here to help.

Thank you for subscribing!