轉化率的問題就像啃一塊塊硬骨頭，不過每啃掉一塊，就能多吃一大份肉，并且熟悉這根骨頭的裂縫所在。

前幾日，渠道部門的小Y突然靈光乍現，跑去讓數據部門拉取了一個詭異數據——點擊【獲取驗證碼】按鈕的未成功注冊人數。

為什么說這個數據詭異呢？

因為平常大家的關注點都在“H5注冊-app登陸”的轉化率，或是“APP激活-app注冊”的轉化，很少有想到說，我單獨去看看這批走了大半路程又放棄的人。

然后，我發現這個驚天巨坑落到了我這只菜鳥身上，因為沒有拜錦鯉，掉的如此不偏不倚。

這個問題把我折磨的不輕，并且確實關系到轉化和運營成本，于是想著把自己整理的內容分享出來，能得到看官們的指點更是感激不盡。

一、問題剖析

首先，這個數據可能來源于哪些場景呢？

• 第一種：用戶在萬千信息流廣告中進入H5注冊頁，填了手機號，但是正好隊友叫我去吃雞，于是注冊中斷，用戶未進入注冊庫。
• 第二種：用戶已經下載了APP，進到登錄頁，填了手機號碼，圖形驗證碼輸錯3次，怒了，直接放棄注冊?；蛘遖pp設置登錄前置，用戶在不能看到內容的情況下，放棄注冊。
• 第三種：用戶完全按正常的流程走，但注冊短信未成功下發或到達時間滯后，導致注冊未果?；蛘?，在注冊的根本就不是個人（歐～我沒有講鬼故事），它可以夜以繼日地發服務器發起請求。

二、原因解析

場景剖析過后，原因其實可以分為幾個大類：

1. 刷注冊，業務攻擊

我們采集了10天的該項數據，發現單個手機號最多點擊次數為3475次。10天內點擊次數>1000次的有425個手機號，>100次的有1068個手機號。

點擊3475次是什么概念呢？

按驗證碼每隔1分鐘才能發送的頻率，這個號碼如果能每天不停歇地發驗證碼，那平均每日需要發11.6個小時，感受一下。并且這種都是程序自動生成一批手機號，一則你封了它可以生成新的，二則你也不能封，萬一誤傷了目標用戶，反而影響了自己的業務。

什么樣的下載包容易被刷呢？

• 長久不上新包的APP（長期未通過ios審核或安卓審核），接口比較老，容易被刷；
• 沒有圖形驗證碼攔截的，容易被刷。

2.?個人問題，中斷注冊

找不到核心原因的那會，無知無畏的我無奈選擇了電話回訪，然后發現各種稀奇古怪的中斷理由：

1. 那會兒太忙后面就給忘了；
2. 我是在今日頭條上看到的，也就隨便看看，后面直接刷過去了；
3. 先瀏覽了一下內頁，沒有特別強的注冊欲望，回頭就忘了。

3. 圖形驗證碼不清晰/登錄前置

如果為了防刷圖形驗證碼設計的過于復雜，或者g/q等字母容易混淆，也有可能影響到用戶的注冊意愿。此外，除了社交聊天/共享單車等特殊的類別，普通APP如果選擇先登錄才能瀏覽的話，很可能影響用戶的注冊意愿，從而造成部分流失。

4. 通道問題，未收到/延遲收到短信

這一部分也會占一個小的比例，但目前市場上通道資源緊張，到達率60%-70%也不是什么稀奇事。同時，如果下發的時候用戶手機有問題，導致無法成功下發，這些失敗短信會在網關保存一段時間再嘗試下發，時間按當地網關不同，有些立即返回，有些要72小時再次下發。

這時，用戶有幾種可能放棄注冊：等待時間過久放棄注冊；收到時間大于驗證碼有效時間（一般>30分鐘）；多次觸發，多個驗證碼造成混淆。

三、對策大全

那么，有哪些可以改進的措施可以采納呢？

1. app版本更新/技術提升

這個方向能解決60%關于今天討論的流失問題，但受限于應用市場審核，很多包都是提交了1年多都不見通過。這種情況下，除了繼續提交申請外，我們只能從其他方向先做改良。

2. 通道下發限制

目前設置了每個手機號最多成功下發3條短信，那么，即使他每天申請1000次，我們也只是發了3條注冊短信，控制了短信成本。

3. 短信召回

實踐中我們發現：召回短信發送的越及時，召回效果越好。具體表現在統計短信發出后的次日數據時，這批用戶的注冊率和申請率明顯提升。此外，為了降低召回短信成本，獲取更真實的召回數據，不妨把當日獲取驗證碼次數>10的手機號剔除。

這部分用戶的召回還是非常有必要的：

• 一則，這批都是有強需求的目標用戶；
• 二則，渠道部門拉一個新注冊的成本是15元/人，現在短信召回的話只需4元不到的成本，為什么不做呢？

4. 驗證碼調整

如果APP目前在用特別復雜的驗證碼，可以考慮增強一些辨識度（影響到用戶注冊的情況下），或者換成滑動式圖形驗證碼。

5. 通道評估與比較

分析這個問題的時候，我找我們的短信通道商要了一份到達時間的數據。數據顯示，平均每日已到達的短信時間分布如下：

0-3秒 19%，4-5秒 43%，6-7秒 17%，8-10秒 13%， >10秒 7%，>100秒 2%。

顯然，還是有不少用戶延遲收到短信的，那么，可以橫向比較幾個通道的數據，擇優選取。

結語

混跡互金行業，用戶運營初涉水，若得指點，高興異常。

本文由 @江南朱七七 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議