Hi,
When a contact unsubscribes from email, can we still send him transactional emails?
We’d like to use Mautic for transactional emails like Password reset which, of course, one should not be able to unsubscribe from.
Hi,
Try by remove the unsubscribe link in your email template.
To save someone time I tested this and it doesn’t work. It would be great if we could send transactional emails to people who unsubscribed.
Hey @micheljung! Did you solve this issue? If yes, how did you do it?
I would solve it like this:
- create a segment called “do not contact marketing”. Exclude this segment from all other marketing segment. Maybe set filer for “do not contact marketing” tag
- create a segment called “unsubscribed” where you filter for everyone who sets do not contact via unsub link.
- create a campaign, which starts with the segment you just created in step 2.
- remove do not contact
- add to “do not contact marketing tag to these people”
When you send marketing, make sure you exclude “do not contact marketing”
Good luck to you!
1 Like
Thanks for the input @joeyk. I’ll consider it!
@joeyk Funny - this was what came up when I googled this after our conversation.
I do think that this is an area of confusion for some people, especially anyone coming from Marketo where transactional emails do work this way.
I’ve just come across this issue as well, as we send all our emails via Mautic and I had assumed that transactional emails, like forgotten password, would never be included in the DNC. The suggestion put forward by @joeyk, while it would probably work, is open to human error with that last step of remembering to exclude a segment when you send the email.
I would suggest that the way “unsubscribe” in Mautic is implemented is actually incorrect. “Unsubscribe” and “Do Not Contact” have been conflated into one thing, as if they are the same, when they are not. Someone who doesn’t want to receive a particular newsletter or marketing communication from a company isn’t the same as someone saying “Do not contact me again”. Unsubscribe should remove someone either from one or all segments and mark them not to be added to them again and not marked as never to be contacted for any reason.
I’ve unsubscribed from marketing emails from plenty of places I still use and want to receive transactional emails from, like reset password or order confirmation emails, but me saying I don’t want marketing emails from them certainly isn’t me saying I don’t want any emails from them and to the best of my knowledge I don’t think any of them have taken it like that.
I would suggest DNC should be only something that an admin does explicitly on a contact in the Mautic interface or via the API and not something that is set by the unsubscribe process. It just looks like whoever implemented it just did the easiest thing for contacts to not receive emails anymore, which was to mark them as DNC, without giving it too much thought.
3 Likes
I agree with @da644, this puts you in a tough spot when it comes to transactional email. I just started using Mautic and am sending users onboarding messaging; if they hit the unsubscribe button, they get DNC’d. But, as a dating app, I still need to be able to send communication like, “you had a content report against you” or “your photo was rejected,” or whatever.
Need to re-think my plan to send transactional emails with Mautic if the DNC is so broad.
Hi, there is a feature request regarding this issue:
This doesn’t appear to address the issue with the conflation of “Unsubscribe” and “Do not Contact” which is the other issue here. You would still need the “Unsubscribe” option to NOT DNC the user.
Would you say, that DNC is more like “Bounce complaint, don’t ever wright to this person” and Unsubscribe is “don’t send marketing emails” ?
In other words:
DNC = Blacklisted, no contact ever
Unsubscribe = marketing no, transactional yes
@joeyk Thanks for the pointer to that other thread. If I understand it correctly, the proposal there is to limit the surfacing of unsubscribe information in the email if it is transactional. That’s certainly part of the broader picture, however I think the issue in this thread is more narrow.
As both @da644 and I have encountered, users who click the “Unsubscribe” link in e-mails are shown one of two very different responses, depending on site configuration:
- If the “Show Contact Preferences” option is enabled, they are shown a contact preferences page instead of direct unsubscription. (Interestingly, if you have no segments configured as public to end-users, the form is blank and you just see a Save button, which is probably the worst case for accidental misconfiguration since you’re denying any choice at all.)
- If the contact preferences option is disabled, they are DNC’d.
If we put aside the specific mechanics, the desire is to allow users to opt-out of marketing emails entirely, but not DNC them. So that is where there is some intersection with the other issue; Mautic needs to be aware in some way of the difference, and allow transactional emails continue to be sent.
I’m still new to the Mautic data model but it seems like some of the building blocks are in place for some sort of solution, but also some re-engineering.
Furthermore, the DNC flag is important; it needs to be respected for “true” DNC conditions, e.g. when I get a webhook from SendGrid that says an address has bounced or is blocked on their end. If I keep trying to send emails to it (including transactional mail) then my reputation score will suffer.
For a no-code solution, I’m thinking something a little less error-prone than the proposal above.
- Add a segment called “Receive marketing messages” which is public and exposed to the preferences center. Its only filter is contact email not null.
- When configuring marketing segments, the include membership in the above segment as a requirement.
E.g.:
Another thought, but it would require code, is that Mautic already has a concept of marketing vs. transactional emails, so perhaps that could be extended more generally to a new flag on contacts.
Finally, this and the other issue offer potential interplay with RFC 2369 (list-unsubscribe header) and RFC 8058 (one-click unsubscribe). Case #2 above is close-ish to one-click unsubscribe, though we would need to implement a specific route to handle the POST, but the action would be identical to what PublicController::getUnsubscribeMessage() does, now.
It actually appears this could be “easily” accomplished by editing the send email API controller to take an option to ignore DNC. There’s a flag in there to do just that, however it’s not exposed and currently only used by a form handler.