Is it possible to log an UnsubEvent via automation data import?

Question

We use Salesforce CRM as the source of truth for our contact's subscription status and preference/list statuses. We also have our preference centre hosted on a Salesforce community site, so subscribers update their data directly in Salesforce (in other words, we don't have a cloudpages-based preference page).

This works fine since we can sync All Subscribers status and other Pub List statuses via synchronised DEs, an automation and data import activities.

The only feature missing (which I think is a really important one) is the logging of UnsubEvents. If a subscriber unsubs from an email, they are essentially just unticking the optin/list checkbox in CRM that we use for that status. However, I believe we have access to the required parameters for an UnsubEvent to be able to build these into a link and pass these to Salesforce CRM at the time they unsubscribe.

It would then just be a question of how to log the UnsubEvent back in marketing cloud. Ideally for us, doing a data import would be best but it doesn't look this this is possible? Am I missing something here or is there another way to achieve this that doesn't require doing a SOAP call?

Answer 1

To my knowledge, no.

This would entail an import into the _unsubscribe data view in the relevant child BU, which is off limits. For a consistent reason as it is a kind of "system log" that is intended to just reflect what happened for 6 months - similar to _bounce data view - so that the system can "calculate" with it (>> showing the unsubscription status on the All Subscribers list).

The standard import activity would allow you to change it or insert timestamps that aren't reflecting when the unsub occurred, breaking all internal calculation. To my knowledge there are no "limited imports" with regards to the import mode.

Similarly, you cannot import bounces, which would throw off the bounce count "behind the scenes".

So: SOAP API is how this can be done - SOAP API limits your access to LogUnsubEvent, which is only "logging new events" so that problem does not pose itself. It will of course enter the time of the API call as timestamp. That's good, as that's the correct time it happened. If you do this in a later migration - it is not so good, as your migration would not populate the timestamps with the actual unsubscription times.

==

All that said - what does that mean for your process:

In my personal opinion (and how I'd build this) you'd simply want your unsubscription page to do this in near-real-time, entering the actual timestamp of the unsubscription and work from there.

In a nutshell, the limits are clear:

• You cannot insert unsubscribes post-hoc via import.

• If you do it somehow (loop a script with logUnsubEvents), that could be your next problem: you want the correct timestamps which SOAP API gives you in real time - entering real unsubscriptions, but with wrong timestamps could throw some internal calculations off.

• You generally want consistent logfiles that the system fills for you. It's of course easiest to have all unsusbcription options work the same way.

• You cannot change how list-unsubscription works.

• but: you can always eliminate an unsubscription's _effects on sendouts by importing to "active" on all subscribers in the correct context.

So: I would start with the logUnsubEvent in every unsub and then build your custom logic around changing its effects, not start with "faking logs" (strong choice of words, but that 's what importing into a data view like _unsubscribe essentially would amount to) - that can get nasty.