Hi Roman,
I think the best way to look at this is to look at what the outcome of each is:
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:
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:
Szenario 2:
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.
On an account with list-specific unsubscribe lists:
On an account with global unsubscribes configured:
Notes:
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.
I’m currently working on an Optimizely integration with our marketing product and have some questions regarding how to handle opt-outs (and re-optins) with the REST API.
When we get an opt-out it seems we have 3 options to forward this:
Which one should I use? Does this depend on the accounts configuration (global vs. list specific unsubscribes)?
When someone opts in again then I need to remove the address from all matching unsubscribe lists. This would mean to add another API-call after adding the recipient to the list, to make sure there is no entry on any unsubscribe list. Should this be done per list? Does this depend on the account configuration?
I couldn’t find any guidance on this in the documentation. Sorry if I overlooked it, and thanks in advance for any help.