The LogUnsubEvent api call allows you to unsubscribe a subscriber and log an ‘UnsubEvent’ that is tracked against a specific job. This is mostly used for custom preference centers or unsubscribe pages.

By using this call, you are able to track back the unsubscribe to the job that the email was sent, instead of just a general non-trackable unsubscribe.

The LogUnsubEvent call uses the following parameters:

• SubscriberID – The Marketing Cloud generated ID that uniuely 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.

This basically can be divided into 3 sections, Subscriber context, Job context and Unsub reason.

Subscriber Context is defined by SubscriberID, Key and EmailAddress. You must provide at least one of these parameters or the call will error. If you have your subscriberkey set to not use email address, you will need to provide SubscriberID or Key along with EmailAddress to unsubscribe.

Job Context is defined by JobID, ListID and BatchID. You don’t need to supply all 3 values, but the more values supplied the higher the level of specificity. Remove the ListID to address the All Subscribers list in an account.

1. If the JobID is supplied, we can lookup a missing ListID and/or BatchID.
2. If the ListID is supplied, we can lookup a missing JobID and/or BatchID.
   1. If the JobID is missing, we use the most recent JobID that the subscriber was sent to.
   2. This may not be the Job that the Subscriber is acting upon.
3. If only the BatchID is supplied, we cannot lookup the remaining information and the job context is not defined.

If job context cannot be established, the UnsubEvent is not created. The subscriber is also Master Unsubscribed from the system instead of only from a particular list.

Unsub Reason is the specified reason provided and stored in the system for the person unsubscribing. If the reason is not supplied, a default value of ‘Unsubscribed via Log Unsub Event Execute Call’ will be used.

Sample via Raw SOAP:

<soap-ENV:Body>
    <ExecuteRequestMsg xmlns="http://exacttarget.com/wsdl/partnerAPI">
        <Requests>
            <Name>LogUnsubEvent</Name>
            <Parameters>
                <Name>SubscriberID</Name>
                <Value>123456</Value>
            </Parameters>
            <Parameters>
                <Name>SubscriberKey</Name>
                <Value>Key for [email protected]</Value>
            </Parameters>
            <Parameters>
                <Name>EmailAddress</Name>
                <Value>[email protected]</Value>
            </Parameters>
            <Parameters>
                <Name>JobID</Name>
                <Value>18099</Value>
            </Parameters>
            <Parameters>
                <Name>ListID</Name>
                <Value>17914</Value>
            </Parameters>
            <Parameters>
                <Name>BatchID</Name>
                <Value>0</Value>
            </Parameters>
        </Requests>
    </ExecuteRequestMsg>
</SOAP-ENV:Body>

This is a significant sized envelope to use inside of a page and will run fairly slowly in comparison to WSProxy.

Outside of that, you can use the SSJS Unsubscribe() function, but this won’t log it to tracking or specify which list/job the unsubscribe initiated on. The closest you can come to this inside of SSJS is the List Function Subscribers.Unsubscribe() function. This will let you specify the list you want them unsubscribed from (not DE), but it still will not add them into the tracking data nor provide anything other than generic unsub reason.

WSProxy Solution:

<script runat="server">
        var mid = XXXXXX;
	var prox = new Script.Util.WSProxy();

	/* Set ClientID */
	prox.setClientId({ "ID": mid}); //Impersonates the BU

	var props = [
	   { Name: "SubscriberKey", Value: "[email protected]" },
	   { Name: "EmailAddress", Value: "[email protected]" },
	   { Name: "JobID", Value: XXXXX },
	   { Name: "ListID", Value: XXXXXXXX },
	   { Name: "BatchID", Value: XXXX }
	];
	var data = prox.execute(props, "LogUnsubEvent");
</script>

This is a much simpler and faster solution to utilize the LogUnsubEvent API call. I feel this is much more scalable and has the potential to become a function, allowing for reuse in multiple locations.

<script runat="server">
    function LogUnsubEvent(mid,skey,emailaddr,jId,lId,bId,unsubReason) {
	var prox = new Script.Util.WSProxy();

	/* Set ClientID */
        if(mid) {
	  prox.setClientId({ "ID": mid}); //Impersonates the BU
        }

	var props = [
	   { Name: "SubscriberKey", Value: sKey },
	   { Name: "EmailAddress", Value: emailAddr },
	   { Name: "JobID", Value: jId },
	   { Name: "ListID", Value: lId },
	   { Name: "BatchID", Value: bId },
           { Name: "Reason", Value: unsubReason }

	];
	var data = prox.execute(props, "LogUnsubEvent");
        return data;
    }
</script>