Welcome to Part 2 of our Mautic vs. Salesforce Marketing Cloud Comparison series. If you missed Part 1, you can read it here. Our second topic compares contact management capabilities between these two tools.
Comparing SFMC & Mautic: Contact Management
SFMC requires a dedicated resource to design your contact management upfront. Mautic can sync directly with your CRM database. Both platforms have powerful segmentation abilities but have key differences in how they allow users to access and activate their data.
Let’s start with SFMC. There are a lot of ways to use your contact records here. When I first started using SFMC, my team only worked with Lists. Lists is the straightforward, rudimentary contact feature in SFMC that is recommended for marketing teams whose database has fewer than 500,000 subscribers, limited subscriber attributes, slower import times (if you’re using an XML API), or for anyone who prefers “simplicity over performance.”
Very quickly, my team determined that the Lists tool was not going to be able to support us based on our marketing roadmap. Email automation really couldn’t thrive without something more powerful. The SFMC upgrade from Lists was called Data Extensions, and we decided to switch to that. But even with a dedicated Salesforce resource assigned to help us migrate, it still took us months to do so. We kept running into issues where the unique identifiers were not matching up because SFMC didn’t remove duplicates at the list level. Additionally, SFMC was erroneously modifying records, stripping out necessary account numbers and causing massive chaos for our engineering team and our customers. Because we could not afford to lose the valuable customer behavior data we had collected through all of our marketing efforts, our dedicated Salesforce resource ended up spending most of his time redesigning and mirroring our data warehouse in the SFMC tool through Data Extensions. Each week, we found we needed another Salesforce team to help because the project kept getting out of scope.
Understanding Data Extensions
In my past roles, I found that the decision to work with SFMC was made specifically because of the system’s ability to house different data tables that could be filtered off of and tied to other lists. Data Extensions and the query tool allow a user to do this. SFMC’s definition of Data Extensions is simply “a table that contains your data.” My definition of Data Extensions is relational record tables – as many as you need – that can house your customer behavior data, customer identity data, filtering and trigger data, import data, and reporting data (like an Excel document with pivot tables). Each table can have a different unique identifier, or not, which is helpful when you have millions of instances for each record and when different tables need to speak to each other. Users can filter off of Data Extensions and write SQL code in the query tool to match and pull data. Data Extensions also help to cut down on the lag time when loading new pages in the “Contacts” tab. The search capability in Data Extensions is not great, and you really need to be mindful of where you are foldering and archiving these. But in general, I found it easy to compare Data Extensions to our own data warehouse.
As mentioned above, where Lists is the appropriate tool for databases that have fewer than 500,000 subscribers, limited subscriber attributes, slower import times, Data Extensions is required for databases of 500,000+ subscribers, sending messages globally, enabling faster import speeds, and for performing SOAP or REST API calls.
Another way to think about Data Extensions is as a place where you can store multiple levels of customer behavior and history data. Think of your favorite online retailer. I like to think of Zappos. It’s intuitive and personalized. I can ‘heart’ my favorites, see past search results, see past purchases, and get recommendations based on all of that engagement. Each of these features (hearts, searches, and purchases) is a separate table within the Zappos database. I might have 10 ‘hearts’ and 3 past purchases. That means my unique identifier (email address in this case) is going to be 10 rows in one Data Extension table (for ‘hearts’) and 3 rows in another Data Extension table (for past purchases). See the images below for a visual. If Zappos wanted to promote a product based on the combination of hearts and past purchases, they would create a new Data Extension that would act as a send-list by querying the ‘Hearts’ and ‘Purchase’ tables and grabbing all the records that meet the criteria for the new product. If Zappos had a new rain boot and wanted to promote to relevant customers, they would compare the two tables to see who was interested in rain boots (the ‘Hearts’ table on the left) and who had bought something similar (the Purchased table on the right). In this example, Customer3 and I would each be getting promotions for a new rain boot because we met these criteria.
About SFMC’s Contact Builder and Data Designer
After the 2013 Salesforce acquisition of ExactTarget, features like Contact Builder and Data Designer came into the platform. Contact Builder is meant to connect records across all studios and “apps” (think of the Salesforce CRM system). Data Designer is how Contact Builder functions – it’s the tool to use within the Contact Builder “Studio.” Ultimately, if you want a single customer to be a single record across all apps, studios, and platforms, you’ll need to live in Contact Builder to make sure this performs. Every time you want to make a new cross-channel campaign, you’ll have to make sure Contact Builder is synced correctly. I usually found that connecting contacts to the different “Studios” was very cumbersome as I needed to constantly sync new or updated data extensions to the Contact Builder tool. I felt I had to act as more of a developer than a marketer just to be able to execute across the various SFMC channels that my team had paid for.