来人人都是产品经理【起点学院】，BAT实战派产品总监手把手系统带你学产品、学运营。
又是一年，今年的支付宝红包口令推出使用户的参与感、存在感更强的自定义口令模式（俗称“定制口令”）。
不知，各位少侠对支付宝定制口令的看法如何？
某天，馒头混迹的群，某君提出这样一个问题：为何支付宝的定制口令这一步骤是置后的？
什么意思？来，画个简易的流程解释下这里的“置后”是什么概念。
主流程：a.打开支付宝，包群红包（金额＋个数）->b.支付验证->c.生成群红包->d.用户自定义定制口令（可选）
不知大家看完上述我画的较挫流程后，是否明白了“置后”的概念。
行！当然行！只是支付宝在这块故意弱化数字口令的入口，对于视力不太好的同学来说，几乎是隐藏掉的，不注意看，根本看不到。啥？不信！喏...见下图：
怎么说呢...其实绝大多数家公司每当有新的东西出来时，肯定是大力推动（因为大力出奇迹嘛，哈哈哈...），弱化可能吸引用户注意力的地方（说不定支付宝下线接龙红包、逗比红包，来全力支持男神女神红包、定制红包口令也是这方面的原因，不过纯属馒头yy）。当然，这不能说不好，可能在某些少侠眼里这就是QJ（不懂的同学，请自行百度“QJ”）用户，但是如果弱化甚至隐藏的点绝大多数用户并不在意，或者就是觉得新推出的功能更有趣儿，这未尝不是一件好事。既有利于公司战略的推进，也减少了一切可能干扰用户关注点的东西来优化体验。不过，以上一定是基于精确的判断。当然，产品经理的使命就是让正确的事情相继发生，对吧！（温馨提示：一旦少侠你毅然决然地选择生成了数字口令，可就不能再对该红包自定义中文口令了）
回到主题上来，为什么定制口令是置后的？哼！我就觉得置前是最优的。即当我定义好一个口令后，再去生成群红包，不挺好的么？
其实，今天的问题只是从中文口令切入，当然你也可以问数字口令为什么都是系统生成的，而不支持自定义输入呢？
我们设想一下，假如真的支持用户先自定义口令，再去生成群红包，可不可以？
举个最简单的例子。小A搞了一个群红包，定义口令“summer专属红包”，可大洋彼岸的另一头，小B也搞了一个群红包，也定义口令为“summer专属红包”。虽然，这两个看似口令一致的红包，但背后的id一定是不同的。为什么？因为这个id包含了一个重要信息，就是谁是这个群红包的主人？也就是告诉你抢的应该是谁的红包。可这个id一定是保密的，如果放出来，说不定哪个心思大大的坏的同学能够破译这个id来知道你的支付宝账户和密码，那可麻烦大了！所以需要生成一个外部id（即口令）来与这个内部id（即保密id）形成映射关系，也就是只有我们的系统可以通过外部id找到内部id是啥。
但这个时候令人蒙b的事情出现了，当馒头在支付宝红包输入口令“summer专属红包”时，我该抢谁的红包？对不起，系统无法识别！
那怎么办，有两种解决办法！一种是让用户来定义口令，但我系统要校验（置前）；另一种是不让用户来干预口令的定制，由我系统说了算（置后）。
什么意思？那另外一种就是我只能先允许群红包生成后，让系统自动给你生成一个口令，你拿去耍。不过这里开发同学也要写一串代码告诉系统，大致意思就是“生成的红包数字口令要保证唯一，千万不能有重复的，否则削死你丫的”。所以也就不难解释为什么15年春节时，大家都在吐槽8位数的支付宝口令，根本就记不下来！因为数字再怎么组合也是有限的，既然数字0-9不能改变了，所以我只能通过增加口令位数来创造更多不重样的组合口令咯（所以这个时候可能中文口令的出现也算是挽救了未来可能出现生涩难记的9位、10位支付宝口令）。否则，你叫我怎么玩。不过，这个方案就好很多了，让系统做掉“不让重复口令出现”这件事，而不是让用户输入一个再去拿给系统审查下okay不，而且相比第一种方法工作量小的太多了。但不好的地方就在于系统不是人，即便是人也没办法知道每个用户最想要、最好记忆的数字口令，比如说8个8，多好记、多吉利啊...所以也就出现了“6位口令我能忍，8位口令去尼玛”的问题了。
所以，今天的if designed like this，如果真的把“自定义口令置前”的设计看来不太可行...
既然支持用户自定义输入口令，还是要在口令屏蔽敏感词上做的好一点...比如现在居然可以自定义并生成诸如“xxx去死吧去死吧”、"xxx你妈炸了"这样的口令，对此馒头也表示醉了。毕竟大过年的，这么不雅的口令还是不要让用户放出来吧...
有槽点，当然也有亮点可言。今年的支付宝口令的背景图片支持肆意更改，也支持随意拖动口令以保证衬于背景图片上的口令清晰可见。这就像是一个情感容器，不过这种偏情感化的设计真是很讨喜的，用户会很买你的帐。不过馒头在这里还是要弱弱地提醒下支付宝的同学，既然支持用户随意更换口令的背景图片，对于违禁黄图这块的内容审核也是要好好做一下，否则...你懂得！
哦对了， 我所说的，都是错的。
