Unsubscribe for 90 days

[Franky_Ruyssch2]

In our preference center we have a checkbox "unsubscribe for 90 days", linked to a boolean custom field.

Defining a Smart List for a campaign should always include this field ( unsubscribe for 90 days should be false ).

We also have a Smart Campaign running that is triggered on a data value change, who sets the value to false after the 90 days period.

My questions:

1) If someone unchecked this value I can imagine that the 90 days counter is still running? Should the campaign be stopped? if so how?

2) If someone unchecked after a period, wait for 20 days, and set the value again true, will the counting restart completely?

[ChristinaZuniga]

1. I have another smart campaign running that says "Remove Temporary Suspended Request Early" with a smart list looking at the previous value changing from true (they are suspended) to false (they are no longer suspended). Then I update their information so they can receive emails because they indicated they no longer want to be temporarily suspended. An important note is access to this field- I don't want Sales people to have the ability to change this...they'll just uncheck it so they can send emails. Le sigh.

Then in my original smart campaign I remove from flow anyone who already has their settings properly set as suspended = false.

2. That I'm not sure about, but maybe Josh Hill​ or Grégoire Michel​ would know what would happen in that case. It would at least partially be dependent on your Schedule settings about how many times someone can flow through, but if a record is already in a wait step in a smart campaign, I don't know what happens if they get added to the campaign again - great question!

[Rachel_Noble]

Love this approach - and especially that it's using a different field than the native Unsubscribe. You could even us Marketing Suspended if you want to use a system-level field. It keeps things cleaner.

[Anne_Angele1]

I like to change the value of unsubscribed reason to something like "requested 90 day unsubscribe". If someone were to uncheck that box, you could run a smart campaign that looked like:

Smart list:

• Trigger: Unsubscribe for 90 Days changed from True to False
• Filter: Unsubscribe Reason is "Requested 90 Day Unsubscribe"

Flow:

• Remove from flow, campaign is [Unsubscribe for 90 days campaign]
• Change Unsubscribe Reason to [Null]

I would remove them from the flow to be safe, just in case they were to request another 90 day suspension before the original one was up. I also like this as a safety net when removing the unsubscribe - I verify that the unsubscribe reason is still "requested 90 day unsubscribe" just in case they unsubscribed permanently during their 90 day break for some reason.

[Grégoire_Miche2]

I would recommend that you do not use long waits in a flow The risk are high that the leads are "forgotten" here while for instance they decide to resubscribe elsewhere during the period.

One should not use "data value changed" filters either, simply because these activities are erased from Marketo after precisely 90 days...

We always set these up with a dedicated "suspension requested until" date field. We compute the field value in the "fills out form" triggered campaign when the person fills out the preference center. use {{system.date}}+90 as a new value. We also add these people to a static list, for easier selection in other campaigns.

Then, we set up various campaigns:

• one that permanently checks that the "marketing suspended" remains checked while the "suspension requested until" is not over or the person is in the list. We do that with "data value changes" trigger (field is "marketing suspended", "new value is false") + a "member of list" filter
• a Batch one that processes everyone whose "suspension requested until" is passed. This one runs every day. it set the marekting suspended to false,  nullifies the "suspension requested until" field and remove the person from the static list.

You should not use the unsubscribe field for this either. The "Marketing suspended" field is better for this usage and has the same effect. I keep the unsubscribe field for the "unsubscribe from all communications" that has to be present (legally speaking) at the bottom of your preference center form.

-Greg

[Nicholas_Manojl]

Bit of a gotcha here, but I'd have to test to be sure.

I don't reckon Change Data Value on a date value with an argument of {{system.date}}+90 will work as expected when moving from null to populated. I reckon it will just set it as {{system.date}}.

Not 100% it will work on subsequent runs either. Does that definitely work for you?

[Grégoire_Miche2]

Hi Nicholas,

and yet, {{system.date}}+90 works Tested and retested.

-Greg

[ss-arplus]

I suspect I'm going about this the wrong way - but I'm trying to build the snooze end date into the form itself. The field is updating, but not correctly. Any ideas?

FYI the snooze field was created in SFDC and setup as a date field.

Selecting 90 days, I expect to see 3/5/22 - but it's showing 29/1/22 (5 days ago)

[SanfordWhiteman]

Date math isn’t processed there. Only in Flows. You need to do the same computation in JS.

Also: you don’t want to use {{system.date}} as the base in any case, because that’ll start from the time they viewed the form — not when they submitted the form, which is what you want.