來人人都是産品經理【起點學院】，BAT實戰派産品總監手把手系統帶你學産品、學運營。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

什麼意思？

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

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

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

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

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

既然支持用戶自定義輸入口令，還是要在口令屏蔽敏感詞上做的好一點...比如現在居然可以自定義并生成諸如“xxx去死吧去死吧”、"xxx你媽炸了"這樣的口令，對此饅頭也表示醉了。畢竟大過年的，這麼不雅的口令還是不要讓用戶放出來吧...

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

哦對了，

我所說的，都是錯的。

作者信息：饅頭（微信公衆号PRODUCTER），阿裡巴巴産品經理，0.5年互聯網産品設計經驗。

本文由 @饅頭原創發布于人人都是産品經理 ，未經許可，禁止轉載。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!