Einstein Engagement Frequency - How important are unsubscribes to this feature?

Question

We are about to get Einstein Engagement Frequency and I can see one potential hiccup with us using it.

We have Salesforce CRM and the Marketing Cloud Connector configured. Our source of truth for subscription management sits within CRM. We have a custom profile centre in Marketing Cloud that directly updates CRM for, amongst other things, unsubscribes.

Because of this, we no longer change subscribers' statuses on All Subscribers in MC. Everyone is marked as Active (unless they make a spam complaint) and we manage their status for marketing emails purely via the Marketing Cloud Connector and automations. This works well.

From what I can gather regarding Einstein Engagement Frequency, it does look at unsubscribes when building it's recommendations. I am assuming this unsubscribe data comes from the _Unsubscribe data view?

In our case, the _Unsubscribe data view is basically empty (since, as I mentioned, we manage all this via CRM and a custom profile centre).

Does anyone know what, if any, impact this will have on Einstein Engagement Frequency producing reliable recommendations?

(I know that might be difficult or impossible to answer as it's a black box to some degree. But worth a shot.)

Thanks

Answer 1

The default recommendation does not take unsub into consideration, unless you choose to adjust the recommendation by using the advanced option, where you can adjust how much unsub should be considered for the recommendations will unsubs be used.

Answer 2

This will definitely have an impact, meaning that for the Einstein logics, unsubscription likelihood is 0.

Your custom profile center has to be aligned to the standard behaviour of marketing cloud a bit more closely to allow the Einstein logic to function:

You would want to change your custom profile center so that it "logs unsub events" under the correct circumstances. (LogUnsubEvent: https://developer.salesforce.com/docs/atlas.en-us.noversion.mc-programmatic-content.meta/mc-programmatic-content/unsubEvent.htm ).

This produces a record in the _Unsubscribe table. Which is great, as it is what Einstein looks at. But of course, this also has the "side effect" that it also changes the status in _Subscribers table to "Unsubscribed", which leads to sendout exclusions through marketing cloud at send time for Commercial sendouts. So Marketing Cloud essentially by default usurps the position of unsubscription master, even though you want to do this is in your CRM.

As both things (unsubscribe and subscribers table update) happen simultaneously through LogUnsubEvent, your only chance here is to revert 50% of the action: change the status on all subscribers back to "Active" after the unsub event has been logged.

here is an example how to do this with ampscript and the SOAP api.

%%[ VAR
@Subscriber,
@SubscriberKey,
@Email,
@Status,
@createErrDesc,
@createErrNo,
@createOpts

SET @Subscriber = CreateObject("Subscriber")
SetObjectProperty( @Subscriber, "SubscriberKey", @SubscriberKey)
SetObjectProperty( @Subscriber, "EmailAddress", @Email)
SetObjectProperty( @Subscriber, "Status", "Active" )
SET @Status = InvokeUpdate( @Subscriber, @createErrDesc, @createErrNo, 
@createOpts)
]%%
%%=v(@Status)=%%

Edit: note, we found in our own projects that the two steps do not work right after each other, so I am not implying that the logunsubevent & re-activation can happen right after each other in your code, you are better off separating the steps.