已注销用户怎么取关（用户给的最后一次机会）

“ 离开也很体面

才没辜负这些年”

01

—

场景再现

注销，是许多产品经理的避之唯恐不及的一个功能，究其原因，是因为人们下意识地用注销这个功能来抗住用户流失这个大锅，但随着法律的要求、以及用户对于信息安全管理的诉求，注销这个功能终究要抵达一线。

为了更好的了解、设计注销功能，那就应该先了解对应的场景，以下就是众多“张三”面临的注销场景：

• 某App因为公司运营状况等，告知张三暂停服务、注销账号。
• 张三的账号一年没有使用，系统给他进行了冻结、注销。
• 张三听同事推荐下载了某App，但该APP半夜推送几十条消息，张三气急败坏，想要注销账户。
• 张三隔壁的老王平时偷偷使用聊天App，开始相亲了，想要注销账号以表清白。
• 张三的儿子是一个特别注重个人信息安全的人，每次不用一个App的时候，都会把该App注销掉。
• 张三的妻子想要控制自己在双十一的购物欲望，故想要注销购物软件一段时间账户，但之后可能想要继续使用。
• 张三玩游戏，喜欢体验从开局到巅峰的征战快感，故很多游戏一段时间后就删号重来。

针对以上的情况，我们可以归类为：

被动注销：

1. 系统停运
2. 超过限定期限、违反约定规定

主动注销：

1. 糟糕的使用体验、情绪冲动等引发的不满注销
2. 安全、不再使用的清除注销
3. 新旧账号切换带来的注销

知晓了场景和原因，我们则可以初步明白我们在设计注销功能时需要满足以下的基本点：

1. 防止误触
2. 服务、权力、义务的停止和通知
3. 清空信息、不可搜索、相互独立等
4. 可以新建账号
5. 可以返回、找回

那么，接下来就是设计注销功能了。

02

—

注销功能的设计

注销功能作为一个相对独立的功能，我将其按照流程分为前、中、后三部分进行分析说明。

注销前：

被动注销时的消息告知：

该部分主要分为注册时的关于注销权利告知和关停时的提前通知。如注册时用户协议中的注销路径和注销要求、服务关停时的全服通知。

（虾米音乐、轻松互助的关停通知）

主动注销时的信息提示：

当用户主动注销时候，需要告知用户是否可以注销，需要满足哪些条件可以注销

其次需要告诉用户关于用户账号、权益、信息等等的留存状况

最后如果涉及到长期利益，应需要通知该服务的备选方案或者人工通道

（社交娱乐属性的注销:微信、微博、soul、虎牙 | 图片来源截图）

如果涉及到财产、资金等，更应该设计注销账号的功能，不然会导致因为提醒和校验的不合理而让用户来为该失误买单。

（金融类APP的注销：天天基金、招商银行 | 图片来源截图）

而在告知之后，用户仍然选择注销，则开始了关键的注销操作。

注销操作：

聊及注销操作：先普及三种注销方案：客户注销、移动端注销和系统回收。

而我们此次主要聊聊移动端注销。为了提供给用户注销的入口，但同时也应该考虑三个问题：

1. 怎么防止误触或者他人操作？
2. 用户真的到了需要关闭、注销的程度了吗？没有其他方案了吗？
3. 用户注销真正的原因是什么？

我们可以针对这三类问题，进行力所能及的设计，针对第一类问题，可以通过用户验证的方式校验，最常见为：短信、刷脸、密码验证等。

第二类问题，也是我们最该关注的。用前段时间我的同事关闭拼多多的拼小圈为例：

在我的同事关闭拼小圈的时候，针对不同的情况，进行提供其他的优解方案和快速操作通道，尽可能的解决了因为其他简单原因而导致的用户流失，可见其的产品经理在该模块有不错的认知和了解。

而同样支付宝也在注销账户时告知客户，如果是因为手机号问题，可以选择更换手机号而不是注销账户。

（拼多多的拼小圈、支付宝的注销 | 图片来源截图）

而如果我们暂时没有上述的类似情况，则最起码应该在最后的和用户沟通的机会，也就是第三类问题，留给用户足够的吐槽和对应的原因，这样也为了我们后续可以将产品做的更好。

注销后：

当用户注销后，我们需要作以下准备：

1. 用户数据的留存、告知用户恢复操作如果没有前面的设置，则可以在最后收集用户离开的理由，但更好的方案
2. 告知用户恢复的操作、期限等
3. 针对其他用户搜索关注、用户历史信息的展示。

最后，我认为的最关键的是，不是“注销难操作”的极端操作，而是给客户一个大方的告别，待产品更好之日，我们再见！