Welcome to Part 2 of our 5-Part 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.
2. Comparing SFMC & Mautic: Contact Management
SFMC requires a dedicated resource to design your contact management up front. Mautic can sync directly with your CRM database. Both platforms have powerful segmentation abilities.
About SFMC’s Lists and Data Extensions Tools
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.
|Hearts Table||Purchased Table|
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.
Contact Management in Mautic
I am really enjoying the way I can coordinate records in Mautic. There are two areas to understand for housing your data: the first is “Contacts” – I think of this as the core table; and the second is “Segments.” The Segments capability is quite powerful because I can define several different filters within one segment, and I can filter for a combination of a record’s attributes and past engagement behavior. In Contacts, I can create many different column fields just like in a SFMC Data Extension. But in Mautic, I like that I can define a complete list in one place and I don’t have to worry about additional exclusion/suppression lists at the time of send.
In addition, Mautic Segments update in real time, so if I import a list manually, if the CRM database is updated, or when a contact engages, I have that update immediately and don’t need to rely on a separate feature like I did in SFMC with Automation Studio. Using SFMC, I had queries that would take hours to complete and would often delay my email sends, to the point that my content would be delivered after my competitors’ because the automations in SFMC would fail or take too long.
Lastly, Mautic has an upcoming feature called Custom Objects which compares pretty directly with Data Extensions for making robust and flexible data tables available. More than one table can be used for filtering and segmenting, and those tables can speak to each other without the extra developer work that SFMC requires.
To sum up…
SFMC users need to acquaint themselves with how Data Extensions work (SFMC offers a 21-step guide to creating one here) and how they speak to each other. Data types, configuring automation, syntax, query builder, and filtering will become common language over time. Data Extensions are powerful and can be very agile when mastered. If your database has millions of records, you’ll need a user to know how to wrangle the data using these tables to avoid automation time-outs and errors.
By comparison, if you are using Mautic, you will have a flexible way to work with your data lists. Planning how you want to view your data and what you want your fields to do requires some work up front, which makes sense as you should be carefully considering your objectives around these efforts). However, once setup, accessing and editing is easy. No need to write additional code or bring in developers. You can stand alone as a marketer and execute your campaigns confidently.