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
11 thoughts on “Unsubscribe and Log an UnsubEvent with a LogUnsubEvent Execute Call”
thank you for this piece of documentation that helped me understand a customer’s use case.
Yet, I do struggle to understand how LogUnsubEvent Execute Call interacts with Salesforce field “EmailOptOut”.
Hi Zuzanna, thank you for this.
I have the same query as Stefano, how exactly does this interact with HasOptedOutOfEmail on the salesforce lead and contact objects? (I am using the connector) Is this just inbuilt?
Hi Clare, this is a connector feature and is not controlled by this script
Thanks for clarifying
Dziękuję Zuzanna! 🙂
LikeLiked by 1 person
Hi Zuzanna, thank you for the article! So just to be sure I understand. As long as Connect is feeding HasOptedOutOfEmail into Marketing Cloud contacts it will automatically suppress all commercial sends to those emails? I set up our CloudPage preference center to change HasOptedOutOfEmail to True, so want to be sure that works.
Hi Koozie. In Sales/Service Cloud, you need to use the “Marketing Cloud Unsubscribe” button to make sure sends are suppressed. Take a look at the documentation: Enabling the Email Opt Out field only in Sales or Service Cloud does not synchronize the subscriber status in the Marketing Cloud. Always click Marketing Cloud Unsubscribe on the record. (https://help.salesforce.com/articleView?id=sf.mc_co_unsubscribes.htm&type=5). So in the direction Sales Cloud –> Marketing Cloud, it won’t suppress anything unless you click “Marketing Cloud Unsubscribe” for a given person.
In the other direction, Marketing Cloud –> Sales Cloud, if you use LogUnsubEvent, the status in All Subscribers list will be changed to “unsubscribed” (which will suppress from sending) and it will sync back to Sales Cloud (the Email Opt Out field will be checked for that person).
Thank you for the blog. In one of my use case, we have custom preference center by which we unsubscribe from different fields in sales cloud as per the selection. We do not have any “unsubscribe from all” in the cloud page and we would like to track the un-subscription of the different individual fields in Journey reporting. Any approach I can take on this!!
Hi Zuzanna, thank you for the article, awesome content !
In the ampscript section, I guess it would be better to use “AttributeValue” function rather than “RequestParameter” for JobId, ListID and BatchID variables (as CloudPagesUrl function would probably not provide values this way, unless you add them as additional parameters in the function, which is not necessary as they are provided by default)
So basically this part…
SET @jid = RequestParameter(“jobid”)
SET @listid = RequestParameter(“listid”)
SET @batchid = RequestParameter(“batchid”)
…should probably rather look like something like this 🙂
SET @jid = AttributeValue(“jobid”)
SET @listid = AttributeValue(“listid”)
SET @batchid = AttributeValue(“_JobSubscriberBatchID”)
I have one question regarding unsublog event, can anyone confirm on the exact working of unsubevent?
When i run this within Child BU it only unsubscribe a record from child BU which is because we have setup to unsub a record at BU level
but when runnign this event on ent account, it again does not unsubscribes it from all the child BUs.
Is there a way to mark a particular record unsubscribed for some specific BUs? consider there are 5 BUs then running the unsub log event should unsubscribe records from only 4 Business units ?
Thanks for your response in advance
A lot of the records on our seed lists for b2c email sends are being unsubscribed by an API Call. These records are not clicking the unsubscribe button at the bottom of the emails. Have you come across this at all or do you know how this can be prevented?