You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, we don’t really handle unsubscribes from Telegram or email:
When a Telegram contributor deactivates the bot, the next time we try to send them a message, Telegram will raise an error. We then flag that message as blocked, and I think we’ll try to send them messages again and again.
When an email contributor clicks on an unsubscribe link in an email, we won’t be able to send them emails via Postmark anymore, i.e. the email jobs will fail.
Robert has implemented an option to manually deactivate a user in #464. Deactivated users then won’t receive broadcast messages anymore.
I’d suggest that we implement a generic solution that allows us to handle unsubscribes on any channel, in order to have a single unsubscribe implementation across all channels, and to unify the UX.
Implement a new /unsubscribe?jwt=abc route. The JWT encodes the user id. Opening the URL deactivates the user (and optionally allows to ask for a reason why they unsubscribed).
The confirmation page should include a link to reactivate the user in case of a mistake.
Every email includes the new unsubscribe link instead of the link dynamically injected by Postmark. We would need to contact Postmark support to get approval to use our own unsubscribe process.
Telegram already has an option to block bots, but I’m not sure if every contributor is aware. Also, contributors might simply want to opt-out of broadcast messages, but may still wish to receive direct messages from editors. Plus, we aren’t able to ask for feedback/a reason when they use Telegrams built-in block feature.
I’m not 100% sure how we could implement this for Telegram, but one option would be to include an unsubscribe link in the welcome message we send to every user.
The text was updated successfully, but these errors were encountered:
@tillprochaska we introduced a way to unsubscribe for WhatsApp where a contributor just sends the keyword Abbestellen and they are marked as inactive. They can resubscribe by sending Bestellen
For Postmark, we have a newer issue New unsubscribe screen for mail #1620, where I found the same information as you passed here, that we could include our own link and just inform Postmark so that they don't include the link by default.
Right now, we don’t really handle unsubscribes from Telegram or email:
When a Telegram contributor deactivates the bot, the next time we try to send them a message, Telegram will raise an error. We then flag that message as blocked, and I think we’ll try to send them messages again and again.
When an email contributor clicks on an unsubscribe link in an email, we won’t be able to send them emails via Postmark anymore, i.e. the email jobs will fail.
Robert has implemented an option to manually deactivate a user in #464. Deactivated users then won’t receive broadcast messages anymore.
I’d suggest that we implement a generic solution that allows us to handle unsubscribes on any channel, in order to have a single unsubscribe implementation across all channels, and to unify the UX.
Implement a new
/unsubscribe?jwt=abc
route. The JWT encodes the user id. Opening the URL deactivates the user (and optionally allows to ask for a reason why they unsubscribed).The confirmation page should include a link to reactivate the user in case of a mistake.
Every email includes the new unsubscribe link instead of the link dynamically injected by Postmark. We would need to contact Postmark support to get approval to use our own unsubscribe process.
Telegram already has an option to block bots, but I’m not sure if every contributor is aware. Also, contributors might simply want to opt-out of broadcast messages, but may still wish to receive direct messages from editors. Plus, we aren’t able to ask for feedback/a reason when they use Telegrams built-in block feature.
I’m not 100% sure how we could implement this for Telegram, but one option would be to include an unsubscribe link in the welcome message we send to every user.
The text was updated successfully, but these errors were encountered: