If you're working with a number of different brands, you may want to isolate your recipients' unsubscribe or complaint statuses. This means they could unsubscribe from specific brands, but not others. Our domain-based unsubscribe feature lets you set this up.
When you combine this feature with the brands feature, unsubscribe and complaint statuses are tied to the brand rather than the domain. This adds an extra level of security as not only does it check the unsubscribe/complaint status against the verified domain, but it also checks for brand target group inclusion against the verified domain.
Before you begin, please note that switching to domain-based unsubscribe means that a recipient's unsubscribe status can no longer be changed using the fixed Person Data 'UNSUBSCRIBED'.
In this article, you will find information about:
- About Domain-Based Unsubscribe
- Agillic's Best Practice on Domain-Based Unsubscribe
- When Might You Want to Use Domain-Based Unsubscribe?
- What Happens After Enabling Domain-Based Unsubscribe?
About Domain-Based Unsubscribe
Domain-based unsubscribe means you can support unsubscribed and complaints per domain. As such, a recipient can unsubscribe from one domain but still receive emails from another within the same Agillic instance.
When you enable the setting, you should select which domain you wish to transfer the current unsubscribes and complaints to.
When you change your domain-based unsubscribe settings, it changes the way Agillic checks for unsubscribes or complaints before sending emails. Therefore, any Target Group or Condition using the current settings has to be changed accordingly. To do this, go into the Data module, select Person Data, and then check the 'References' section. There, you can see if the data is used.
| Method | Standard Unsubscribe | Domain-based Unsubscribe |
| Data used | Fixed Person Data: UNSUBSCRIBE (boolean) UNSUBSCRIBE_DATE COMPLAINT (boolean) COMPLAINT_DATE |
Fixed One-to-Many table: EMAIL_STATUS: FROM (list of domains or brands) TYPE (Unsubscribe or Complaint) DATE ID |
| Target Group Example | Unsubscribed population size last 2 weeks: Condition: Person Data: UNSUBSCRIBE equals True & UNSUBSCRIBE_DATE is less than 14 days in the past |
Unsubscribed population size last 2 weeks: Condition: One to Many: EMAIL_STATUS exist, where TYPE equals Unsubscribe & where DATE is less than 14 days in the past |
If you wish to return to the standard unsubscribe method, all logged unsubscribes and complaints across domains will again be stored on the standard Fixed Person Data fields. As such, no data will be lost switching between the methods.
Agillic's Best Practice on Domain Based Unsubscribe
We recommend for you to continue controlling permissions either by using a Person Data field per brand or through a dedicated One-to-Many table. We don't recommend relying solely on domain-based unsubscribe statuses for handling permissions, such as those held in a One-to-Many table named 'EMAIL_STATUS'. Instead, think of domain-based unsubscribe as an added layer of protection.
Things to Consider Before Enabling Domain-Based Unsubscribe
Before enabling the domain-based unsubscribe feature, you should consider the following:
- You may have recipients with 'UNSUBSCRIBED = true' on your domain who you'd like to keep. If you switch to domain-based unsubscribe, these recipients will receive information from all other domains but the one you initially chose to transfer statuses to. Consider a way to exclude these recipients and prevent send-outs to them.
- If you have Conditions that are currently set up to segment based on a value in the Person Data field 'UNSUBSCRIBED', you need to modify them so they're instead based on One-to-Many Conditions.
- Domain-based unsubscribe is triggered by the list-unsubscribe functionality in email clients.
- You will need to provide alternative fallback-methods for the recipient to unsubscribe or withdraw permissions through.
It's important to investigate where a Person Data field is currently being referenced as you go through this process.
When Might You Want to Use Domain-Based Unsubscribe?
Let's say you're working with several brands, each of which sends emails from a separate domain. A recipient may be subscribed to a number of the brands but, at some point, choose to list-unsubscribe via the email client. With a traditional setup, the recipient would be blocked from receiving any future communication. On the other hand, with domain-based unsubscribe, the recipient's 'Unsubscribe' status is only altered for the 'from domain' the email originated from.
Here are some examples of how this works.
Recipient is Subscribed to Multiple Newsletters
Below, you'll find an example of how the domain-based unsubscribe feature works when a recipient is subscribed to multiple newsletters.
Recipient A is subscribed to newsletters from Chocolate News (news@chocolate.agilliccandy.com) and Candy Digest (news@digest.agilliccandy.com).
- Recipient A receives an email from news@chocolate.agilliccandy.com.
- Recipient A triggers the list-unsubscribe functionality in their email client.
- Recipient A is now prevented from receiving future communication from news@chocolate.agilliccandy.com, but will continue receiving emails from news@digest.agilliccandy.com.
The Recipient is Subscribed to Multiple Types of Communication
Below, you'll find two examples of how the domain-based unsubscribe feature works when a recipient is subscribed to multiple types of domains and want to unsubscribe.
Example One
Recipient A receives Service Status emails from a website hosting provider (service@service.agilliccandy.com). Recipient A also receives marketing information about new products and unique offers from the same website hosting provider (contact@marketing.agilliccandy.com).
- Recipient A receives an email containing a seasonal offer from contact@marketing.agilliccandy.com.
- Recipient A chooses not to receive these in the future and triggers the list-unsubscribe functionality in their email client.
- Recipient A is now prevented from receiving future communication from contact@marketing.agilliccandy.com but will continue receiving emails from service@service.agilliccandy.com.
Example Two
The subdomain marketing.agilliccandy.com has the brand Target Group 'Agillic Candy Marketing' attached.
- Recipient B doesn't meet the Conditions for 'Agillic Candy Marketing'.
- An email is sent to Recipient B from the verified domain 'marketing.agilliccandy.com'.
- Recipient B is blocked on the email Flow Step as the recipient doesn't match the brand Target Group.
- Recipient B is receiving service status emails from a website hosting provider (service@service.agilliccandy.com).
- Recipient B is also receiving marketing information about new products and unique offers from the same website hosting provider (contact@marketing.agilliccandy.com).
What Happens After Enabling Domain-Based Unsubscribe?
When a recipient triggers list-unsubscribe, their status is updated in the EMAIL_STATUS One-to-Many table for the corresponding 'email from domain'. If you add an additional verified domain in the future, by default, recipients will be able to receive emails from that domain.
If you want the EMAIL_STATUS One-to-Many table to be updated by other means than a list-unsubscribe, you may choose to configure a data Flow which updates the One-to-Many record. An example of this could be an unsubscribe button in the email footer that has a 'marketing_unsubscribe' event attached. This event is set to trigger the data Flow 'marketing_unsubscribe_flow' as shown in the image below.
Data flow which updates EMAIL_STATUS.TYPE to 'Unsubscribe' for the row matching EMAIL_STATUS.FROM - marketing.agilliccandy.com