Let people unsubscribe from emails without logging in

[chrifro]

Problem:

• Currently, users need to login in before there are able to unsubscribe from emails. The unsubscribe link links to https://gitpod.io/notifications. Legally we must provide a way to unsubscribe within a single page [1].
• With the new newsletter widget, people that don't have a Gitpod account can also sign up for emails. They need to have an option to unsubscribe from emails as well.

Solution:
Creating an API where people can unsubscribe without logging in

Acceptance criteria:

• Create an "Unsubscribed successful" page on website
• Create a new API on the server
• Change links in the email campaigns to redirect to the new API

Note: changes in /notification are already automatically forwarded and updated in customer.io

Context:
customer.io docs
internal discussion

cc @jakobhero @atduarte

[csweichel]

/schedule

[JanKoehnlein]

/assign @laushinka

[chrifro]

Summary of the internal discussion:

Going forward we want to have two links in the email footer:

1. update preferences (users needs to log in -> link already exists, no action needed)
2. unsubscribe (user is automatically removed from the current mailing list and sees a "you have been successfully unsubscribed" page)

Next action:
create mockup @ChristinFrohne
technical implementation @laushinka

[chrifro]

The unsubscribe page can be a copy of the submitted contact form and would look similar to this:

[svenefftinge]

We can create a REST API on the server (e.g. /unsubscribe?userid=293z4h34r7334743d?type=newsletter) that would do the change and redirect to the "Unsubscribed" website page that Christin shared above.

That API wouldn't require a login, of course, so anyone can unsubscribe any user if they know the userid. I believe there's not a lot of harm done in that case and the user ids are not publicly visible.

@csweichel @leodido any concerns with such a simple approach from a security angle?

[csweichel]

A few thoughts on this:

1. Where does the userID come from? The user isn't logged in anymore, so how does the system know which userID to use? Would we send this as an unsubscribe link in the email?
2. userID's are not secret, i.e. we don't specifically protect them and there's a very good chance that we "leak" them somewhere. That said, if the "REST API" always redirects to the page and returns no user-specific information there would indeed be little harm done from an information leakage perspective. We should definitely monitor that endpoint closely from a call rate perspective and have an alert if it exceeds a sensible value (tbd).

[laushinka]

The unsubscribe page can be a copy of the submitted contact form and would look similar to this:

@ChristinFrohne PR done here

[laushinka]

@svenefftinge @csweichel After investigating with @jakobhero, we realized that not every newsletter subscriber is a user on Gitpod, e.g. the blog and the DevX newsletter. Therefore it seems that we will have to use the email address for the API.

@ChristinFrohne We will have to change the links manually in customer.io, therefore could you tell @jakobhero or I in which email campaigns we want to have the changes in?

[chrifro]

We will have to change the links manually in customer.io, therefore could you tell @jakobhero or I in which email campaigns we want to have the changes in?

It will only affect new emails that we are sending e.g. Changelog, DevX Digest or Newsletter. You can just send me the link and I'll update the templates.
Later this evening we will send a newsletter, but the new logic won't be live until then, right?

FYI, the existing onboarding campaign uses the unsubscribe logic from customer.io which works fine. When unsubscribing from the onboarding campaign, only the campaign will stop. The user notification preferences are not influenced by it.

I'm very excited to see this working. Thank you so much for fixing it @laushinka 🧡

[jakobhero]

FYI, the existing onboarding campaign uses the unsubscribe logic from customer.io which works fine. When unsubscribing from the onboarding campaign, only the campaign will stop. The user notification preferences are not influenced by it.

Maintaining the preference for the onboarding campaign in customer.io is fine for now, but we will look to move ALL subscription preferences back to the subscription centre in the dashboard to 1) have the DB as only source of truth for all signed up users and 2) provide signed up users a better UX (if there is a dedicated area for managing subscriptions for any service that I have signed up for, I would expect that I manage all subscriptions in this one place, including the onboarding campaign). However, the logic of the onboarding campaign works fine for now, so we will handle this once we have got the basic changes of the new (un)subscription logic up and running.

For now, in order for @laushinka to design the options in the endpoint, it is sufficient to know which subscription options exist (e.g. product, newsletter, onboarding) as this will have to be passed along to the request along with the user's identifier so that we know which list to unsubscribe the user from. This also means that in the footer of each email sent, the link to unsubscribe will have to specify the mailing list too.