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.
It happens because + equates to a space when the email address is URL encoded.
Your custom preference center will need to be updated to replace all spaces with + characters.
emailAddress = emailAddress.replace(" ","+");
set @emailAddress = replace(@emailAddress," ","+")
You really need SQL Queries to get the data from the _subscribers Data View and link it to the entry Data Extension of the journey so you can check who of them unsubscribed or not.
Depending on the aim of the journey, you can also use measures to filter by unsubscribes from the main entry audience (no journey needed in this case).
The code above doesn't specify a publication list at all, so it is unsubbing at the child BU level and flowing down to the publist automatically.
This example will work (but will not log an unsub event).
SET @ll_sub = CreateObject("Subscriber")
No - This will most definitely affect your deliverability and might even block your sender with some ISPs, who simply refuse letting emails through without this header.
No - Using a transactional send classification to send non-transactional mail would result in marketing mail being sent to recipients whose status is set to Unsubscribed in All subs. This is ...
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 ...
Your best option is to configure journey exit criteria to check for the subscription status. These will be evaluated when contacts moves on from each wait step. Your object holding subscription status must of course be synced to SFMC, and connected in an attribute group. Please do observe, if you are using your consent/opt-in records in a one-to-many ...
single org behavior is linked in the comment above.
Multi-Org SFMC setups, as well as multiple BUs in Single Org (there is no difference in this regard) simply do not work with the standard MC Connect offering.
In the words of the documentation
"Marketing Cloud Connect does not support business unit-level unsubscribes for Enterprise 2.0 accounts. ...
_Unsubscribe holds unsubscribe events that are tied to a specific send job. These occur when a subscriber uses an unsubscribe/profile center link from an email or when the LogUnsubEvent API request is made.
_Unsubscribe will not log an event when a subscriber's status is changed due to import, Subscriber update API request, or when changed via UI.
Run a script in Automation Studio in SSJS:
Then in the Content Area, run a lookup in AMPscript of unsubscribes and use UpdateSalesforceObjects.
Has to do with clicks.
Unique is a counter that will only count the first time that the link is clicked. Unsubscribes counts how many times the link was clicked in total. You might double click that link for example and the unsubscribes column would count it as two clicks.
This is what I would do in your case. Not knowing if your system of record (SOR) for consent data is within SFMC itself (e.g. in a Consent data extension) or outside, this solution will differ slightly.
Firstly, a job needs to be set up in Automation Studio (in parent BU) to query your Complaint and Bounce data views. Once a day you (or more frequent, ...
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 ...
Yes, you need to take care of them. Nothing is deleted from Sales Cloud - you would have to create a process for this. The only things "visible" in Sales Cloud, would be the status of the email send in Individual Email Results and the EmailOptOut flag on a Contact/Lead (if you're using it).
Also, nothing is deleted in Marketing Cloud - here is how this ...
You can also extract and import the Status Change tracking data, which would be much less data than maintaining two data extensions of every subscriber.
The most recent record for a subscriber is the current status.
Your approach is pretty straightforward and simple to execute.
You could think that the _Subscribers data view could be used for this, but it would only allow you to identify people that:
are subscribed currently
are unsubscribed currently
You will not be able to identify people who were unsubscribed and and decided to resubscribe as those records will ...
LogUnsubEvent and the connector can be considered integrated. Every "real" marketing cloud unsubscription leverages LogUnsubEvent including your examples.
Sales Cloud to Marketing Cloud unsubscribe synching
Did you check the documentation for Marketing Cloud Connect?
There are multiple ways to unsubscribe a subscriber from receiving communications.
A subscriber opts out by clicking the link to the profile center included in each email. The user is unsubscribed in the Marketing Cloud and the Email Opt Out flag is checked in the CRM.
A subscriber can click a ...
In SFMC there is a Data View that contains all the Unsubcribed records. This is the _Unsubscribe data view.
You can use a report that extract this information or use a custom report if You want something different from the out of the box functionality.
If someone unsubscribed in Marketing Cloud, then will be there.
Regarded the second part, as best practice, ...
I think, based on your question, that you may have duplicate subscribers and wish to unsubscribe all matching email addresses (across different subscriber keys)?
If so, when an unsubscribe takes place for a subscriber, you're able to also unsubscribe any other subscriber keys that share the same email address using a four-step automation:
SQL query ...
I'd recommend logging an unsub event instead of toggling the status. Logging unsub events ensures that all of the tracking data relating to the subscriber is recorded properly. The system personalization strings in the send context will ensure your page has all of the necessary info. This method also supports the unsubscribe granularity if your send is ...
If you are using a custom profile center, you can use UpdateSingleSalesforceObject to update your custom field once the contact is on your landing page.
PS: if you go with this option, keep in mind that some contacts that complaint about your email ,by ...
From past experience, support will not be able to change this setting. We raised it through Account Executives who raised it through their internal contacts, but we were told it's not possible. Never hurts to try on your side though.
We explored the path of having the current Parent 'transformed' into a child business unit and replaced with a new clean ...
To get the statuses from a child business unit, run a tracking extract and include 'Extract Subscribers' and 'Include All Subscribers'. Typically I'll add this to an automation that then imports the extract file into a data extension that you can then query/filter from easily.
Your extract should include the following fields:
I don't believe you are going to have much luck implementing this using a smart capture form on a CloudPage. You are going to have to execute a logUnsubEvent in order to update a subscriber's status within the platform, but the smart capture form is made to capture data and not execute functions on it (without some scripting anyway).
So, in order to ...
+1 for Atilla's answer. See also this: Email Subscriber Lists and Journey Builder
Knowledge Article Number 000213370
Since the Contacts framework used by Journey Builder only supports records stored in Data Extensions, Journey Builder does not support the use of lists created ...
A publication list wouldn't be associated to a Journey itself, it would be associated to each individual email.
So in the email configuration screen within your Journey, on tab 2 - "Email Send Configuration" - you would select which Publication List is associated to that email, meaning if they are unsubscribed it won't be sent to them. Just make sure to ...