Hi @rbastien92,

The process that you are asking is actually an enhancement request, you can post this as an idea and our product team will look into it.

But there is a workaround that you may use, the details are in this community post, ideally the post is about KC Bot, but it has reference to email engagement opt out as well. Hope this helps.

@srinivas myakala Thank you for the response, however will this go out if users already unsubscribed to all e-mails already? And won’t there still be the opt out option at the end of the e-mail we sent out? It’s a nice workaround, just have some concerns

Hi @rbastien92 
If a user unsubscribe they wouldn’t receive any email from Gainsight, where you would need to update the email unsubscribe option in user profile if you want the user to receive emails again. Adding a community post below for your reference for re-subscribing the users.

Yes, all emails will have unsubscribe option by default, but by controlling what content user prefers to receive as per their preferences we should be able to reduce the unsubscribe clicks.

Hope this helps.

@Surendra thanks for the information!  Is the email opt out completed per aptrinsic id, or per email address?  We have multiple product tags, and therefore the potential for the same person (and same email address) to be associated with multiple aptrinsic ids.  Understanding how the opt out works in the backend will help us in knowing will an opt out of email comms be at the product level, or if at the email level, will opt them out of all comms for any aptrinsic id sharing that email address.

Thanks!

​

@Stuart  Opt-out functionality is managed based on unique user IDs. If each product associates a user/email with a distinct user ID, you can control opt-out preferences for each product using the respective user ID.

If a user has the same Aptrinsic ID across all products, we need to collect product-level preferences and manage them accordingly.

Attached is an example of an engagement where we collected roles and goals from our customers. Users could select multiple options (such as email preferences in our use case), and these selections were stored in attributes.

You can later use these attributes in email audience logic to ensure that only users who opted for specific email preferences receive those communications.

Thank you!

@Surendra am I correct that the only way the same aptrinsic id would be across all poroducts would be to have the same tag installed across all products? We have multiple tags, so for example if tag1 and tag2 both have the same user.id, these would still create 2 aptrinsic ids, and therefore two sets of email opt-out preferences to manage accordingly?

@Stuart  If a user has the same user ID across multiple tags, they are likely to have the same Aptrinsic ID as well. Conversely, if they have multiple user IDs across tags, they will have multiple Aptrinsic IDs. The best practice is to track the user consistently across all products, which can be achieved by assigning the same user ID across all product tags.

To ensure the same user ID is used across all products, the identifier call setup should trigger the same user ID whenever a user logs into multiple products. This does not require the same tag, but rather the same user ID in the identifier call when a user accesses your applications.

For product-level email preferences, companies need to create product-specific preferences. If preferences are to be managed at the company level, a single set of preferences can be maintained.