I have been working with Sitecore EXM 9.3 for a while now. I have worked on a project with some pretty advanced requirements. EXM has some pretty great capabilities and those are easy to find as that is what all the marketing focuses on. But what are some core capabilities it is still missing? Here is my list. If you have more please leave a comment.
.jpg)
Limited Subject line personalization
Ok, yes it does have the ability to personalize a subject line. You can put tokens into the subject line like first name and last name. You can even create your own custom tokens. But what if you want the subject line to change more than just by a token? This is something you cannot do, at least not out of the box. This can cause a challenge when you have a marketing automation campaign that sends a series of emails. The content gets personalized based on the series of emails they are getting. But it means the subject line for that email is pretty much the same. This is not ideal when talking about high levels of personalization.
Recurring Scheduling for defined times
This is a huge one for me. You can schedule emails to be reoccurring, but given a huge limitation in Sitecore after the first send all other reoccurring sends will always happen at midnight even if you scheduled it to go every day at 3pm! This one is really frustrating to me. If you schedule an email to send every Tuesday at 3pm the first Tuesday after you set this up will send the email at 3 pm. However, every Tuesday after that the email will be sent right after midnight! To make things even worse once the email has been sent the first time the email is also removed from the list of "scheduled" emails in the EXM dashboard! So even though you still have scheduled emails you can't see them anymore. These two issues have reference numbers 443849 and 450635 to be addressed hopefully. This is a big miss that makes it hard to say EXM is in a space that can compete with other platforms out there.
Compress the email HTML on send
In my opinion, this is a miss. It is pretty easy to implement and impacts your email's deliverability. Now, depending on what you are doing with your emails this may not matter much. In fact, you can argue that the smaller your email the better. So, with a short brief email, there may be no need for compression. However, almost all marketing emails are HTML emails. HTML has a lot of wasted space in it with all the white space between tags and the like. A lot of email size can be saved simply by compressing the email. This can be done easily by adding a processor to the SendEmail pipeline. Before you say it, yes, you are correct, this will create additional processing and slow down your email generation. So, like most things you have to weigh the trade-offs.
Inline CSS that is in a referenced stylesheet
The value of this one really depends on your workflow for creating emails. If the emails are designed, developed, and deployed in isolation from other assets there is probably not much value in this to you. However, if your emails shared styling with other assets you manage, like your corporate website, it can help. It makes managed of styles easier if emails and the website can both reference the same stylesheets. This way everything updates with one change. However, most email clients will not work with referenced stylesheets. Having a processor that can take all the referenced styles in an email and moved them from the external stylesheet to inline in the email solves this problem. Out of the box you don't have this capability. Litmus and MailChimp have some online tools where you can do this conversion but at scale tools like this don't really work. PreMailer has an online version but also a Python and C# port of this code you can bring into your solutions. Again, this comes with processing time tradeoffs you need to evaluate as this can be an expensive process.
Storing custom information about a send
This is a more advanced need, but if you are customizing pipelines to push additional information to your emails and/or the rendering process this can be a challenge. Sitecore's Pipeline and process architecture is amazing and goes a long way here. You can use the pipeline arguments custom data property to store and pass information down the pipeline. However, with EXM this process eventually makes its way into the dispatch task. This is an in-memory process. The challenge here is this dispatch task can be aborted (when sending an email, the send can be paused by the user or paused by the system if it detects too many exceptions). When an abort happens the task is canceled and the pipeline finishes. This means all the data stored in the pipeline arguments is disposed of once the pipeline finishes. Resuming the send does not recreate all the same pipeline arguments. You have also lost any state you may have tried to store in those arguments. To make this work you have to do some overriding to get at task data which can be tricky. I hope to get into some options here in a future post.
Summary
These are the biggest gotchas we have found in regards to EXM. Your mileage on some of these may vary. If you have other ones please leave a comment and let me know.
Comments