Mistakes can be made when using any enterprise platform and Marketing Cloud is no exception to the rule. Most user-based mistakes are caused by taking shortcuts, like an inadequate implementation, failing to invest in training, or not testing. However there are always some mistakes that are inevitable and all part of the learning process. Someone once helpfully explained to me that “you learn Marketing Cloud by making mistakes — the bigger the mistake, the more you learn.” And he was right.
In this post, I’ve identified the top ten mistakes in Marketing Cloud that I see users regularly make, so you can avoid them.
But there’s a lot of ambiguity on what this feature actually does. Some assume that simply by adding email addresses or domains to this feature, you can send emails from the email address or domain. And that’s right, but you’ll also experience deliverability issues. To understand why, it’s first necessary to explain how a mail server works.
When a mail server receives emails, it validates that the outgoing server (which sent the email) has permission to send emails on behalf of the domain. Simply put, it uses a set of security mechanisms to prevent ‘bad guys’ from sending emails on your behalf. This includes checking published DNS (Domain Name System) records for an SPF (Sender Policy Framework) record to validate that the IP address of the server used to send the email has permission to do so. Additionally, most mail servers also check for the presence of a DKIM (DomainKeys Identified Mail) signature header in the email and compare this against the sender’s public DKIM key in the published DNS records, which is a method to sign your emails in a way that will allow the recipient’s server to check if the sender was really you or not. Additionally, some mail servers also use DMARC (or Domain-based Message Authentication, Reporting, and Conformance), which is an email authentication method that checks whether the message’s ‘From’ header matches the sending domain, when SPF or DKIM checks the message (referred to as ‘alignment’).
Email Address Update Behavior
When sending emails from Content Builder or from a Send Email activity in an automation, the email address used to send an email to a Subscriber will not be updated based on the value of your email address field in your Data Extension. That’s because by default, this email address is only used when creating a new Subscriber record at send time.
Viewing Activities in an Automation
Once an automation has been activated in Automation Studio, it can’t be modified and activities can’t be viewed on the automation canvas without pausing the automation. And there are many scenarios when you would need to view an existing activity in an automation—perhaps you want to review SQL code in query activities or check an activities’ configuration.
Activities can be viewed without pausing an automation by identifying the activity name in the automation then opening the corresponding activity from the Activities page in Automation Studio, but I see most users opt to pause the automation and view the activities directly in the automation, out of convenience. The danger with this practice is that it’s all too easy to forget to re-activate the automation after viewing (or editing) activities. And I’ve seen entire cross-platform architecture processes stall or break due to users absentmindedly forgetting to reactivate automations after pausing them.
However inconvenient it may seem, you should only open active automations to review the activity names, then locate the corresponding activity on the Activities page, where you can safely view them without impacting active automations.
Contact Ejection in Journeys
When a Contact reaches an Email activity in a Journey, the platform evaluates whether the email should be sent to the Contact. And there are several scenarios why emails aren’t sent, which includes unsubscribes, List Detective related reasons, or the Subscriber is on a suppression list. But in all of these scenarios, the Contact is ejected from the journey.
This behavior can be validated by reviewing the Contact Details for an email activity, which provides details on ‘Hard Errors’. Then using the Health feature, you can search for individual Contacts to review the paths and activities they were routed through.
While this behavior might be unexpected, it’s clearly intentional. And because a Contact was ejected from the Journey, then any other activities won’t apply to the Contact, like Update Contact, or a different messaging activity (like Push Notification or SMS).
While there isn’t a perfect solution to this problem, if you have multiple messaging activities in your journey other than email, then you may want to create mini-journeys instead, with separate journeys for different messaging channels.