Unsubscribe tracking for custom unsubscribe page

Question

I am pretty new to Marketing Cloud so I am sorry if it is a dumb question. On our Account we use a custom unsubscribe link which forwards the customer to a set of cloud pages used as unsubscribe pages. This link contains the customers email and subscriber key as variables. Once on the first page the customers email is prefilled into a field an he has to click on unsubscribe. Once he does that the "UpdateSingleSalesforceObject" action is used to update his record (Email Opt Out Field) in the Sales Cloud and a triggered send is initiated to the customer service center to unsubscribe the customer in an external backend system.

Due to these unsubscribes being done via the Sales Cloud action they are not tracked in the Marketing Cloud Journey which is used to send out the mail.

Is there any way to make it so that these unsubscribes are also included in the Journey Reporting? (Information displayed when you click on a e-mail send activity of an already running journey)

Thanks for your Feedback.

Best Regards, Felix

Answer 1

Familiarize yourself with LogUnsubEvent, and replace the UpdateSalesforceObject function with it.

LogUnsubEvent through the MC connector automatically sets the "Email Opt Out" field in Sales Cloud for you (often this is more cause for concern than anything, but for your usecase it seems to be what you want) and produces Marketing Cloud statistics at the same time. Your current solution does only the first part of the story.

https://developer.salesforce.com/docs/atlas.en-us.noversion.mc-programmatic-content.meta/mc-programmatic-content/unsubEvent.htm

Once you know the term, you can also easily google sample implementations with AMPScript, SSJS etc.

As a general rule, any custom unsubscription taking a pass on LogUnsubEvent will lead to problems with the statistics, and everything consuming those statistics (journey dashboards, einstein). So best practice in my book is to always make sure to use it as intended. Even if it means you have to deal with potential side effects or even inconsistencies (e.g. due to multiple types of unsubs from the same BU) that this general rule produces afterwards. You want to feed meaningful statistics into the system or you block product capabilities.