Opt-in forms are an important part of your list environment, but just as importantly, opt-out forms are too. AKA unsubscribe forms, you can look at the unsubscribe request or process as being an opt-out action.
Instead of using a generic unsub landing page provided by your ESP, and assuming your ESP can handle various types of inbound emails related to your account (yes, we do!), using a contact form on your website can accomplish several things.
First, you keep the recipient in your world (i.e., on your website) versus being redirected to a sterile looking landing page managed by someone else.
Second, you can collect lots of information about the overall request by including query parameters, along with a bonus of being able to pre-populate form data. And, the form is your form, so you can customize it as need be.
Third, not only is the unsub recorded in our system, its data can stay in yours as well – a couple of ways. One is achieved by storing form submissions, and the other is sending a notification email to another address apart from the one being sent to us.
The framework for this example is based on using a WordPress website, where you create an “unsubscribe” page, add whatever text or images to the page, and embed a “contact” form. The purpose of this particular contact form (as the forms are commonly referred to) is to unsubscribe.
Two things to consider first, related to your hosting provider. Some allow you to send using any email address as the FROM address (case 1), and others require the FROM address to be registered with the provider (case 2).
Case 1
This is the simplest of the two cases. On your contact form, you can prepopulate the email address, or let the user enter it. You can even prepopulate as a hidden field (in either case, you do need to capture the person’s address). You’ll use that address in the form settings as the FROM address. Send to the form to <your_username>@jangomail.com, with a subject line of Unsubscribe. Send a notification elsewhere if need be. Show a message on the page after submission, or redirect the person to a “rescue” or upsell page, or whatever page you want.
From there, JangoMail processes the incoming email that was sent to your account’s internal email address, and we unsubscribe the recipient based on the FROM address that was used for the form submission. You’ll see the address appear in Reports -> Unsubscribes.
Here is an example using a Forminator form from WPMU DEV, showing basic form fields, a select list for reasons why, and prepopulating the email address field.
The form notification – allows embedding the recipient’s email address as the FROM address (the FROM name doesn’t matter for us), and adding extra data into the message body (when used to send the notification, aka, the unsub, to someone else). Note that the subject is Unsubscribe.
Example of a landing page with the data pre-populated.
Case 2
This takes advantage of our new opt-in form process, where you tag a list as being an opt-in list and then use the generated token value as part of your form submission (in the message body). The FROM address doesn’t matter, but it has to be an address that your hosting provider will let you send with, if sending natively. You can also use an SMTP plugin and send through that relay using any legal/valid address you want, but some SMTP plugins will lock down the FROM address mail from the website uses, so you’re back to square one with Case 2 – you still can’t use the recipient’s email address as the FROM address since this will applied for every unsub submission – and on other forms you may be using. The form still gets sent to your username at jangomail.com address, and you embed the required form fields within the message body (minimum being the jangotoken and jangoemailaddress values).
In this case, the recipient is opting in to the list you made based on the token. The twist here is that you alter the list settings and make the list a suppression list. But since it is your list, you can add additional fields, such as date, IP, and the reason why (if you collected via a select list).
When your account has a suppression list, JangoMail uses it during campaign preprocessing to scrub out the email addresses in your suppression list – which basically does the same thing as when we scrub out your unsubscribes.
This example is based on creating a new list and getting the token value for the list being an opt-in type of list. Create the list, and turn it into an opt-in list.
Create an opt-in token, then copy the “jango” lines that appear afterwards. You can come back to this page/screen later if need be to get the string values.
Select your new opt-in list, go to its Settings, and make it a suppression list.
Add the token strings to your message body and update the recipient to be your JangoMail username account.
The link URL is only going to include the email address this time.
<p>Click <a data-notrack="true" href="http://your-website.com/unsubscribe/?emailaddress=%%emailaddress%%" target="_blank">here</a> to unsubscribe</p>
My revised unsubscribe page with just email address showing now, and after submitting, I’m in the new opt-in list used as a suppression list.
Let’s send an email to my recipient and see what happens during campaign processing. Apply the suppression list in campaign settings.
What to send to your site’s unsubscribe page/form?
Well, that’s largely up to you. As a bare bones case, just sent the recipient to the unsub page and let him enter his address. Capture that address via the form field, depending on your form provider, something like {email-1}, and use {email-1} as the FROM address if you are in Case 1. Otherwise, you’ll include the email address as jangoemailaddress=”{email-1}” in the message body.
You can (mostly easily) pass in whatever you want to your landing page. A personalization variable of %%emailaddress%%, added to your message’s URL to get to the unsub page (e.g., https://your_website.com/unsub/?emailaddress=%%emailaddress%%), and then use the form’s feature to pick off query parameters to populate the relevant form field. Any non-reserved WordPress parameter name/term can be used.
Note: if you use our ***uniqued**** variable in the message’s URL, you can get the job number (j=xxxx) and a message hash (m=….). If you do use that (not a recommendation to do so, just showing what is possible in case you want the job ID), “m” is reserved by WordPress, so you’ll have to (at least) add a function to have your site’s WordPress installation ignore “m” as a query name component.
function wpd_request_filter( $request ){
if( isset( $request['m'] ) ){
unset( $request['m'] );
}
return $request;
}
add_filter( 'request', 'wpd_request_filter' );Since the recipient is clicking on your own unsub link, this brings up two additional points.
You can use your own unsub link where JangoMail will not force in one for you if we don’t detect our native unsub URL/code. Contact Support to have that check removed from your account (along with us verifying everything works).
The second relates to clicktracking. Clicks on regular unsub links are not counted as part of clicktracking metrics for a campaign. You can tell JangoMail to not count the click for your unsub link by adding data-notrack in your “a” tag.
<p>Click <a data-notrack="true" href="https://your-website.com/unsubscribe/?emailaddress=%%emailaddress%%&***uniqueid****" target="_blank">here</a> to unsubscribe</p>
If your form allows the pre-populated email address to be overwritten, you can make that field hidden, or just in case, add a second email address field that is hidden and use its value for the unsub address (to prevent someone from entering random addresses on your form, aka spam submissions).
Let us know what you think!! We appreciate your feedback.
Send us an email with any questions, feedback, or suggestions.
