對于微信的全面封殺，15年2月紅包口令的推出，讓支付寶在2015年與微信的紅包戰(zhàn)役中扳回一城。配以接龍紅包、逗比紅包有趣兒的紅包玩法（可饅頭還是不知為何今年突然下線…），支付寶創(chuàng)造了一種圍繞紅包的互動新模式。

又是一年，今年的支付寶紅包口令推出使用戶的參與感、存在感更強的自定義口令模式（俗稱“定制口令”）。

不知，各位少俠對支付寶定制口令的看法如何？

某天，饅頭混跡的群，某君提出這樣一個問題：為何支付寶的定制口令這一步驟是置后的？

什么意思？來，畫個簡易的流程解釋下這里的“置后”是什么概念。

主流程：a.打開支付寶，包群紅包（金額＋個數）->b.支付驗證->c.生成群紅包->d.用戶自定義定制口令（可選）

不知大家看完上述我畫的較挫流程后，是否明白了“置后”的概念。

就是說，其實b->c的過程，這個群紅包已經生成了，并不是說用戶自定義完中文口令后這個群紅包才生成。所以這里的講的前后概念就是說c和d哪一步驟在先。這里請大家注意，雖然d步驟我標注了是“可選”步驟，但僅適用于這個群紅包分享到支付寶的朋友、生活圈或釘釘的阿里系app。如果你想分享到微信，口令這步一定是必選的，否則是沒有一個媒介渠道去分享的。至于為什么？想想支付寶紅包口令推出的背景就懂了。

插個話題。#有的少俠就問了，我不想用中文口令，太麻煩。我就想用數字口令，可以不？#

行！當然行！只是支付寶在這塊故意弱化數字口令的入口，對于視力不太好的同學來說，幾乎是隱藏掉的，不注意看，根本看不到。啥？不信！喏…見下圖：

怎么說呢…其實絕大多數家公司每當有新的東西出來時，肯定是大力推動（因為大力出奇跡嘛，哈哈哈…），弱化可能吸引用戶注意力的地方（說不定支付寶下線接龍紅包、逗比紅包，來全力支持男神女神紅包、定制紅包口令也是這方面的原因，不過純屬饅頭yy）。當然，這不能說不好，可能在某些少俠眼里這就是QJ（不懂的同學，請自行百度“QJ”）用戶，但是如果弱化甚至隱藏的點絕大多數用戶并不在意，或者就是覺得新推出的功能更有趣兒，這未嘗不是一件好事。既有利于公司戰(zhàn)略的推進，也減少了一切可能干擾用戶關注點的東西來優(yōu)化體驗。不過，以上一定是基于精確的判斷。當然，產品經理的使命就是讓正確的事情相繼發(fā)生，對吧！（溫馨提示：一旦少俠你毅然決然地選擇生成了數字口令，可就不能再對該紅包自定義中文口令了）

回到主題上來，為什么定制口令是置后的？哼！我就覺得置前是最優(yōu)的。即當我定義好一個口令后，再去生成群紅包，不挺好的么？

再談這個問題前，說下“口令”。其實，15年的數字紅包口令的生成也是置后的，只不過相對來說無感知罷了。再往深了點說，口令就是一個攻破敵城防御從而進行有效傳播的媒介。你見過微信紅包有口令么？沒有！為啥，因為人家在自己家里玩的好好的，也不會到外面撒歡兒。

換句話說，今天微信你能屏蔽我支付寶來自阿里域名的分享鏈接，但是一張附帶數字口令序列號的圖片（圖片只是一個傳輸媒介，不用在意。為啥？不用圖片直接在朋友圈發(fā)串口令數字也可以）你屏蔽不來，也屏蔽不起。

其實，今天的問題只是從中文口令切入，當然你也可以問數字口令為什么都是系統生成的，而不支持自定義輸入呢？

我們設想一下，假如真的支持用戶先自定義口令，再去生成群紅包，可不可以？

舉個最簡單的例子。小A搞了一個群紅包，定義口令“summer專屬紅包”，可大洋彼岸的另一頭，小B也搞了一個群紅包，也定義口令為“summer專屬紅包”。雖然，這兩個看似口令一致的紅包，但背后的id一定是不同的。為什么？因為這個id包含了一個重要信息，就是誰是這個群紅包的主人？也就是告訴你搶的應該是誰的紅包。可這個id一定是保密的，如果放出來，說不定哪個心思大大的壞的同學能夠破譯這個id來知道你的支付寶賬戶和密碼，那可麻煩大了！所以需要生成一個外部id（即口令）來與這個內部id（即保密id）形成映射關系，也就是只有我們的系統可以通過外部id找到內部id是啥。

但這個時候令人蒙b的事情出現了，當饅頭在支付寶紅包輸入口令“summer專屬紅包”時，我該搶誰的紅包？對不起，系統無法識別！

那怎么辦，有兩種解決辦法！一種是讓用戶來定義口令，但我系統要校驗（置前）；另一種是不讓用戶來干預口令的定制，由我系統說了算（置后）。

什么意思？

要么我支持你先定義好口令再生成紅包（稱心如意了吧？），但這個時候開發(fā)同學一定要寫一串代碼告訴系統，大致意思就是說“當用戶自定義口令后，去跑一遍口令數據庫去做唯一性校驗，if一旦數據庫里有相同的口令，攔截并提示用戶該口令已存在，請重新輸入其他口令；else，通過”。但這個問題太大了！先不談系統去run一遍口令數據庫累不累？即便跑得動，需不需要時間？好，如果這個過程需要時間，用戶需不需要等待，哪怕用戶耐心好等得起，等你個無感知的幾毫秒或者無所謂的幾秒又如何，但是一旦跑完了，用戶等也等了，你突然告訴他“對不起，口令已存在了呢…您得再想一個口令試試看”。我勒個槽，用戶不得噴死你丫的。好，即便這個用戶超級nice（耐撕），一次不行我來兩次，兩次不行我來三次，那假如10次，100次，1000次呢？用戶真的有耐心么？幾次不行人家就不陪你玩了，這么麻煩不如發(fā)微信紅包。另外，這里還有一個隱性問題也很重要，也就是我系統run完了，發(fā)現沒有重復口令，執(zhí)行“通過”把這個口令推上去再告訴前端可以把這個口令給用戶看了。這是個過程，但有過程一定需要時間。問題就出在這里，一旦這個微乎其微的時間段有人輸入一摸一樣的口令了，但此時唯一性校驗已經做完了，同樣避免不了最開始所說的那個問題，系統無法識別！你們可能會說這種情況可能性很小的，好吧！雖然可能性很小，但一旦有這樣的情況出現，那可問題大了！所以，無論是從用戶體驗還是實現的可行性上考慮，這種方法都不現實！

那另外一種就是我只能先允許群紅包生成后，讓系統自動給你生成一個口令，你拿去耍。不過這里開發(fā)同學也要寫一串代碼告訴系統，大致意思就是“生成的紅包數字口令要保證唯一，千萬不能有重復的，否則削死你丫的”。所以也就不難解釋為什么15年春節(jié)時，大家都在吐槽8位數的支付寶口令，根本就記不下來！因為數字再怎么組合也是有限的，既然數字0-9不能改變了，所以我只能通過增加口令位數來創(chuàng)造更多不重樣的組合口令咯（所以這個時候可能中文口令的出現也算是挽救了未來可能出現生澀難記的9位、10位支付寶口令）。否則，你叫我怎么玩。不過，這個方案就好很多了，讓系統做掉“不讓重復口令出現”這件事，而不是讓用戶輸入一個再去拿給系統審查下okay不，而且相比第一種方法工作量小的太多了。但不好的地方就在于系統不是人，即便是人也沒辦法知道每個用戶最想要、最好記憶的數字口令，比如說8個8，多好記、多吉利啊…所以也就出現了“6位口令我能忍，8位口令去尼瑪”的問題了。

但大家又會說了，現在群紅包生成了，你再去自定義紅包口令，不也會出現一樣的問題么？還得做一次唯一性校驗，看看是否有重復的口令。不過這樣的情況要好很多了，為什么？一是用支付寶發(fā)紅包的人未必全都是分享到微信的，這個時候口令就完全不需要，直接分享到支付寶群分掉就好了。二是即便用戶輸入了一遍遍口令都是重復的，但我支付寶留了退路啊！那不是有個系統可以自動生成不重復的數字口令入口嘛（雖然小且難以發(fā)現，但是我存在）…另外，用戶輸入中文口令重復的可能性不會太高，我支付寶可以縮小口令唯一性校驗的范圍，只和“進行中”狀態(tài)的紅包口令作校驗，已結束失效的群紅包的就不做校驗了，因為沒意義。那操心的同學又會問了，那假如一個紅包發(fā)出去大家一直不領，可怎么辦，難道一直占著坑？明確告訴你不會的，無論是支付寶紅包還是微信紅包，都會設置一個相對有效期，一旦紅包過了有效期，未領取完的紅包余額會自動退回到你的賬戶上并置為失效狀態(tài)的（如果我沒記錯，支付寶群紅包的有效期是生成后的24小時內）。

所以，今天的if designed like this，如果真的把“自定義口令置前”的設計看來不太可行…

#插個話題#另外，關于支付寶的紅包口令，還有一個槽點要講一下：

既然支持用戶自定義輸入口令，還是要在口令屏蔽敏感詞上做的好一點…

有槽點，當然也有亮點可言。今年的支付寶口令的背景圖片支持肆意更改，也支持隨意拖動口令以保證襯于背景圖片上的口令清晰可見。這就像是一個情感容器，不過這種偏情感化的設計真是很討喜的，用戶會很買你的帳。不過饅頭在這里還是要弱弱地提醒下支付寶的同學，既然支持用戶隨意更換口令的背景圖片，對于違禁黃圖這塊的內容審核也是要好好做一下，否則…你懂得！

哦對了，

我所說的，都是錯的。

作者信息：饅頭（微信公眾號PRODUCTER），阿里巴巴產品經理，0.5年互聯網產品設計經驗。

本文由 @饅頭 原創(chuàng)發(fā)布于人人都是產品經理?，未經許可，禁止轉載。