Hi Roman,

I think the best way to look at this is to look at what the outcome of each is:

1. User data is preserved and not removed from the system. If they re-subscribe / opt back in marketing emails you won't have lost that data.
2. User data is preserved as per the global unsubscribe and you are able to still market the user just not for the specified topic.
3. User data is removed, if user was to opt back in you would need to start from fresh.

There is also the added complexity of Data Protection Laws that you need to considered.

There is no guidance as to how this should function, however more you have flexibility that allows you to accomplish your outcomes.

There is a lot to consider here and I think you should take some time to think about the factors above before making a decisions that suits your needs.

Paul

Hi Paul,

thanks for your answers. There are still a few open questions:

• If the account is set up for a global unsubscribe list and I use list specific API-calls: Does it have any effect? What effect does it have?
• If the account is set up for list specific unsubscribe lists and I add/remove recipients to the global list: Does it have any effect? What effect does it have?

The API docs only give the hint, that the account setting somehow makes a difference but not how.

Hi Roman,

If the account is setup for global unsubscribe and you use a list specific api call I imagine this will have no effect to the under-lying data, and vice versa for the opposite setup.

Which begins the question back to you outcomes, what way do you want to to work.

Once you know this you will then know how to configure the setup and also which api's you need to use, which in turn will drive your solution to achieve the outcome you wish.

Thanks

Paul

Hi Paul,

I’m developing an integration of our product with Optimizely Campaigns. The question of the desired outcome will not have a single answer as this will depend on the client. As such I need this product to work with both configurations of accounts. Also I must know what the options are and how to implement them properly and then being able to explain them to or clients.

By default I would use the unsubscribe lists in accordance to the account’s configuration as this seems to be also the default for Optimzely as a whole.

> I imagine this will have no effect to the under-lying data, and vice versa for the opposite setup.

I’d prefer to not build the integration based on guesses. This is important information that I can’t find anywhere in the API docs.

Worst case is that I have to store a configuration with each API account that tells my code which mode this particular account is operating at. Then I need to implement both the API calls for global / list specific unsubscribes. As this would complicate our onboarding process as well (eg. make our product worse) I’d rather have one code path that works for both configurations. Whether that’s possible depends on the question I’ve asked above: What is the semantic of the global / list-specific unsubscribe list account setting wrt to the API calls.

Hi Roman,

From the information above it sounds like you need it to work both ways as you will never know what the client has setup?

I think you are best looking at this documentation that explains the unsubscribe process in campaign.

Esseniatial if a user unsubscribes they get added to an internal system unsubscribe list and when you try to send a campaign it looks at the unsubscribes and excludes them from the campaign. This is the OOTB functionality. With this process you wouldn't need to do anything as it is all OOTB.

If you want to do it differently, then that would be the only reason I can see for making calls to the recipients api to delete the recipinet from a specifc list. You would also need to implement an interface to display the lists they are subscribed to to remove themselves from so this is all custom development.

Does this help with your question?

Paul

Hi Paul,

I see this more from the other perspective. If I want to use unsubscribe lists (which I would prefer) this means I have to ask the client for how the account is set up and then use the API calls accordingly.

In this case I still need to know what happens if the client inadverdently gives us the wrong information or the setting is changed later on without notifying us. If there is a chance that with the wrong configuration unsubscribes will be simply/silently ignored then this poses a big risk that I can’t ignore.

The question about whether I want it to work differently is hard to answer without knowing how it works in the first place. Which circles back to my question: How does the account setting interact with the API calls?

Roman

Perhaps it’s simpler to ask questions about very specific szenarios:

Szenario 1:

1. The account is set up to use a global unsubscribe list.
2. test-user is subscribed to “list A”
3. I add test-user to the list specific unsubscribe list for ”list A” using the API.
   
   • Will the API call receive a HTTP 2xx response?
   • Will test-user receive mailings for “list A” after this?
4. The account setting is changed to use list specifc unsubscribe lists.
   • Will test-user receive mailings for “list A“ after this?
5. The account setting is changed back to use the global unsubscrie list.
   • Will test-user receive mailings for “list A“ after this?

Szenario 2:

1. The account is set up to use a list specific unsubscribe lists.
2. test-user is subscribed to “list A”
3. I add test-user to the global unsubscribe list for ”list A” using the API. 
   • Will the API call receive a 2xx response?
   • Will test-user receive mailings for “list A” after this?
4. The account setting is changed back to use the global unsubscribe list.
   • Will test-user receive mailings for “list A“ after this?
5. The account setting is changed to use list specifc unsubscribe lists.
   • Will test-user receive mailings for “list A“ after this?

Hi Roman,

Yes I think you are right it will be best to ask the client how the account is setup.

Your product needs to cater for all scenarios, so some form of configuration per client will be needed by the sounds of it.

Paul

Hi Paul,

I think without any more concrete information about how the API behaves under specific circumstances (=direct and knowledge based answers to my questions) this conversation is only going to be frustrating for the both of us.

Thank you for trying to help!

Roman

So I’ve tested the API now and got myself some answers. I’m posting them here so maybe someone else missing this information in the docs can find it here.

Test results

On an account with list-specific unsubscribe lists:

1. On an account with list-specific unsubscribes configured a POST /unsubscribes without passing the recipientListId fails (HTTP 400). → This is a way to find out the account’s configuration

On an account with global unsubscribes configured:

1. The API allows adding both list specific and global unsubscribes, but any unsubscribe is counted for all lists. → All unsubscribes act as global unsubscribes.
2. Deleting any unsubscribe for an email address also deletes all other unsubscribes (the recipientListId parameter of DELETE /unsubscribes is ignored).

Notes:

• The effect of unsubscribes was tested using GET /recipients/<list>/<email>/valid — assuming that this is consistent with actual email sending.
• The effect of managing the unsubscribes was tested using GET /unsubscribes?recipientIds=<email>

Conclusion

An integration with the API can simply use list-specific unsubscribes. This will work with both account settings and will have the expected behavior. To users I would recommend to always set their account to use list-specific unsubscribes as this avoids surprising side-effects of the global unsubscribe list.