Unified subscription
This page provides you with information on unified subscription.
The Unified subscription introduces additional configurations and serves as an additional layer atop the existing subscription logic, Single, Restricted, and Double. This enables it to analyze subscription permissions across source profiles and make decisions on whether to send communications. For details about Single, Restricted, and Double subscription types, please refer to our Subscription managementdocumentation and search for 'Single,' 'Restricted,' or 'Double'.
Note:
All existing subscription settings remain in effect when you enable unified subscription. For example, if you've configured synchronization of subscription status across OUs, this setting will also be applied to the unified subscription.
With Unified subscription configuration, you can set up additional configurations as follows:
- Recently Granted Consent: The most recent consent given by the customer is considered to decide whether a communication can be sent. This is the default unified subscription settings.
Note:
If no consent is present (consent status is not-set on all sources), the existing subscription type (single, restricted single, or double) is used to make this decision.
Example: The below table explains a scenario where unified subscription status is enabled with the type "Recently granted consent":
Date | Source profile & recent consent status | Existing subscription type | Can communication be sent? |
---|---|---|---|
Today | Instore: Not set WebEngage: Not set | Single | Yes The existing subscription type is considered as the recent unified subscription type is not available. |
Today | Instore: Not set WebEngage: Not set | Restricted | No The existing subscription type is considered as the recent unified subscription type is not available. |
Tomorrow | Instore: Not set WebEngage: Opt-out | Single | No The existing subscription type is ignored here as the recent unified subscription type is available. |
Day After Tomorrow | Instore: Opt-in WebEngage: Opt-out | Single | No The existing subscription type is ignored here as the recent unified subscription type is available. |
- Liberal Approach: Communication will be sent if the customer has agreed to receive communications on any of the source profiles. If the communication status is marked as "Yes" on at least one profile, messages will be allowed to be sent.
Example: The below table explains a scenario where unified subscription status is enabled with the type "Liberal":
Source profile & consent status | Existing subscription type | Can communication be sent? |
---|---|---|
Instore: Not set WebEngage: Not set | Single | Yes The existing subscription type is considered as consent statuses are not available. |
Instore: Not set WebEngage: Not set | Restricted | No The existing subscription type is considered as consent statuses are not available. |
Instore: Not set WebEngage: Opt-out | Single | Yes. The consent status on Instore is considered as Yes. The existing subscription type is ignored here as the consent statuses are available |
Instore: Opt-in WebEngage: Opt-out | Single | Yes. The consent status of the Instore profile is Yes. The existing subscription type is ignored here as the recent unified subscription type is available |
- Strict approach: Communication will be sent only if the customer has agreed to receive communications on all source profiles. Messages will be allowed to be sent only if the communication status is marked as "Yes" on all profiles.
The below table explains a scenario where unified subscription status is enabled with the type "Strict". The existing subscription type is ignored.
Source profile & consent status | Existing subscription type | Can communication be sent? |
---|---|---|
Instore: Not set WebEngage: Not set | Single | Yes, because both consent statuses are Not set and the system considers the existing subscription type. In Single, Not set is considered as 'Yes' |
Instore: Not set WebEngage: Not set | Restricted | No, because both consent statuses are Not set and the system considers the existing subscription type. In Restricted, only Opt-in is considered as 'Yes'. |
Instore: Not set WebEngage: Opt-out | Single | No, because one of the consent statuses is No. The existing subscription type is ignored here as the consent statuses are available. |
Instore: Opt-in WebEngage: Opt-out | Single | No, because one of the consent statuses is No. The existing subscription type is ignored here as the consent statuses are available. |
Enabling unified subscription
You can raise a ticket with the sustenance team and enable configuration CONF_UNIFIED_SUBSCRIPTION_ENABLED
to enable the unified subscription.
Sample tickets:
The turnaround time is five days.
How this is different from the existing subscription setup?
In the current subscription setup, complications arise when subscription settings vary across source profiles. Refer to the image below for an illustration:
In the above image, you can see that subscription permission for each source is different.
The Unified subscription resolves this complexity and makes informed decisions regarding the sending of promotional or transactional messages.
Updated about 1 year ago