The LogUnsubEvent provides a convenient way of handling unsubscribes when you create your own unsubscribe landing page or profile center functionality. This call allows you to unsubscribe a subscriber and log an UnsubEvent that is tracked against a specific Job, which means that you will be able to track from which email they unsubscribed and see the results on the tracking dashboard. You can configure the call to either unsubscribe a subscriber from a specific list, publication list, or all subscribers, which will effectively unsubscribe them from receiving any emails.
What’s more important, if you’re using Marketing Cloud Connect to connect with your Salesforce Sales or Service Cloud org, the unsubscribe will be captured on the subscriber record in Sales/Service Cloud. It will automatically check the Email Opt Out (HasOptedOutOfEmail) flag and will also be visible in the Individual Email Results for the corresponding email send.
The LogUnsubEvent Execute call uses the following parameters:
- SubscriberID – The Marketing Cloud generated ID that uniquely identifies a subscriber.
- SubscriberKey – The client supplied ID that uniquely identifies a subscriber.
- EmailAddress – The email address of the subscriber.
- JobID – The ID of the Job that sent the message.
- ListID – The ID of the List that the subscriber belonged to. You can use subscriber or publication lists (not suppression lists).
- BatchID – The ID of the Batch within the Job.
- Reason – (Optional) The reason the subscriber is being unsubscribed.
The parameters can be divided into 3 sections:
- Subscriber context
- Job context
- Unsub reason
If you make this call from the parent unit of an Enterprise 2.0 account, ensure that you include the ClientID of the child business account to return information specific to that business unit.
The Subscriber Context is defined by the SubscriberID, SubscriberKey and EmailAddress parameters. You must supply at least one of these parameters. If you provide more than one of these parameters, we retrieve the Subscriber using one of the values and validate that the other values match the retrieved Subscriber. If they don’t match, an error returns.
If the SubscriberKey permission is turned on and you supply the EmailAddress parameter, you must supply either the SubscriberID or the SubscriberKey.
The Job Context is defined by the JobID, ListID and BatchID parameters. These values are used to determine which Job the UnsubEvent is tracked against. The subscriber is also unsubscribed from the List that the Job was sent to. You don’t need to supply all three values. The system looks up any missing values using the following rules:
- If the JobID is supplied, we can lookup a missing ListID and/or BatchID.
- If the ListID is supplied, we can lookup a missing JobID and/or BatchID.
- If the JobID is missing, we use the most recent JobID that the subscriber was sent to.
- This may not be the Job that the Subscriber is acting upon.
- If only the BatchID is supplied, we cannot lookup the remaining information and the job context is not defined.
If the job context cannot be established because you did not supply any of these parameters or only supplied the BatchID, the UnsubEvent is not created. The subscriber is also Master Unsubscribed from the system of being unsubscribed from a particular list. Remove the ListID to address the All Subscribers list in an account.
This is used to specify the reason the subscriber is being unsubscribed from the system. If the reason is not supplied, the default value is used: Unsubscribed via Log Unsub Event Execute call.
Here is an example SOAP Request envelope:
We will now look at three different ways to implement this solution on a CloudPage.
LogUnsubEvent using AMPscript
This is probably the most common way to use the LogUnsubEvent call. Below script will retrieve the SubscriberKey, JobId, ListId and BatchId if you link to the unsubscribe page from your email using the CloudPagesURL function. Depending on whether a list/publication list was selected for the send, it will unsubscribe a subscriber from that particular list, or it will unsubscribe the subscriber from all emails if you used All Subscribers.
The implementation of the LogUnsubEvent call in SSJS will be almost identical to the AMPscript solution, as the methods for accessing SOAP object data with SSJS are primarily wrappers around AMPScript functions.
Like in the previous example, the script will retrieve the SubscriberKey, JobId, ListId and BatchId if you link to the unsubscribe page from your email using the CloudPagesURL function and will unsubscribe a subscriber either from a list or All Subscribers, depending on which one you use at send time.
LogUnsubEvent using WSProxy
Therefore, the below script is the most simple, and what’s more important, the fastest way to execute the LogUnsubEvent API call. In a speed test ran using the Chrome DevTools, it proved to be the fastest one to load on a CloudPage, with AMPscript just slightly slower and SSJS the slowest one, taking twice as much time to load.
Just like in the previous examples, the script will retrieve the SubscriberKey, JobId, ListId and BatchId if you link to the unsubscribe page from your email using the CloudPagesURL function and will unsubscribe a subscriber either from a list or All Subscribers, depending on which one you use at send time.
If you would like to find out more about logging an UnsubEvent or WSProxy, check out the following articles:
- Marketing Cloud API documentation: Unsubscribe and Log an UnsubEvent with a LogUnsubEvent Execute Call
- One-Click Unsubscribe with AMPscript by Adam Spriggs
- Introducing WSProxy for Salesforce Marketing Cloud by Eliot Harper
- LogUnsubEvent And How To Do It In WSProxy by Gortonington