73%用户流失？电商App转化漏斗的致命断点

　　去年十月，我蹲在京东物流园边上的小破咖啡馆改 checkout 流程，玻璃门一直没关严，风灌进来，吹得我 iPad 上的埋点图谱来回抖。当时雨下得不大，但檐口滴水声特别准，哒、哒、哒，像在给 AB 测试倒计时。

　　就那天下午三点十七分，我们切了新支付弹窗——不是全屏那个，是右下角浮层，带“一键免密”勾选框的。上线两小时，漏斗崩了。首页到商详流失率没变，商详到加购涨了五点二，但加购到下单——哗，七十三。七十三。我盯着后台曲线看了十八秒，手边那杯冰美式化了，糖浆沉底，一坨褐色淤泥。

　　我原以为是唤起逻辑问题，结果查日志发现：四千二百一十一台设备在点击“立即购买”后，根本没触发任何 native bridge call。不是失败，是静默蒸发。连 error code 都没吐出来。后来扒安卓端源码，发现 SDK 里埋了个 try-catch，catch 里只写了 Log.d("pay", "oops")——连时间戳都没打。这个我敢打包票，因为是我三年前写的，当时赶工期，写着写着外卖到了，是黄焖鸡米饭，汤洒在键盘上，Ctrl+S 键粘住了，我就顺手注释掉那行 time stamp 的代码，忘了删。

文章配图，仅供参考

　　对，就是那个被你吐槽过八百遍的 PaySDK v2.3.7。去年五月你们组重构 H5 支付页时，我说过这 SDK 里有段 JNI 调用，会在 Android 12+ 某些 OEM 系统上返回空指针却吞异常——你们不信。现在信了？王磊刚接完电话，是运维打来的，说线上 P0，他一边听一边用签字笔把奶茶吸管掰成三截，咔、咔、咔，每掰一下，我就听见后台又掉十个下单用户。

　　七十三不是事故，是筛选。你真觉得那些卡在“确认订单页”反复点“去支付”却始终不跳转的人，是潜在高价值用户？我见过他们——凌晨两点刷到“满三百减二十”，下单流程卡住，硬是切换回淘宝比价再切回来，最终清空购物车。这种人，留着干嘛？让 DAU 虚胖？让 GMV 假高？让运营写“用户行为深度参与”PPT？

　　机房空调坏了三天，风扇嗡嗡响得像拖拉机挂二档。上周四，测试环境跑回归，我趴在服务器机柜侧面看日志流，热风吹得我后颈发痒，衬衫领子都潮了。突然看到一笔交易状态从 “prepaying” 直接跳成 “timeout”，中间没有 updateOrderStatus，也没有 callback，就像一个人进电梯，关门，楼层灯不亮，但电梯井里也没坠落声。我截图发群里，没人回。后来才知道，那天 iOS 审核被拒，理由是“支付流程中缺少必要取消路径”，而我们为了保审核，把“取消支付”按钮的 touchUpInside 方法绑在了 dispatch_after(0.0) 里——0.0 秒延时，够干啥？够让按钮响应延迟到三帧之后。用户点了，屏幕没反馈，以为失灵，立刻退出。这个我说不准是不是主因，但肯定不是唯一一个。

　　昨天在地铁上看到个熟人，是拼多多做增长的，叫陈屿。他坐我斜前方，穿灰卫衣，左手捏着半块奥利奥，右手在 iPhone 上滑购物车。滑到第三页，他拇指悬停半秒，没点“结算”，直接按 Home 键切微信。我认得那款灰卫衣，是他老婆生日送的，袖口脱线了两针，他总用左手去捻。我盯着那两针脱线看了半站路，想到我们上个月重做的那个“猜你喜欢”卡片动效：入场用 springWithDamping，但 dampingRatio 设成 0.4，太飘，像纸片被风吹歪。结果呢？CTR 高了，转化低了。用户喜欢划，划得欢，划完了啥也没点。我们还庆功，说“沉浸感提升了”。现在想来，沉浸感是假的，拖延感才是真的。

　　所以别喊“73%流失”，喊“73%筛掉了”。筛掉的是一批人：网络稍差就放弃的，指纹识别失败两次就不耐烦的，收货地址编辑框焦点没自动跳到“电话号”的——对，就是那个 bug，安卓软键盘弹出时 inputMethodService 会把焦点劫持给 searchview，但我们监听的是 focus change，不是 input connection，所以地址编辑框永远不 autofocus，用户得手动点三次才能输入手机号。这个细节我们三个月前就知道，但排期表上写着“Q4 优化体验”，没人动。它和那个 JNI 空指针一样，都不致命，但它们叠加在一起，就变成漏斗断点最结实的一块砖。

　　对了，昨天行政部把旧茶水间钥匙丢了，现在大家去六楼拿水，要爬楼梯。李婷抱着保温杯上来的时候，左脚鞋带散了，她单脚跳着系，右肩背包带滑下来，手机掉进水桶里——是那种带滤网的老式饮水机水桶，水刚换的，凉，桶底还漂着半片茶叶。她捞出来擦干，屏还是亮的，正在加载“我的订单”。她没重启，也没换机，就蹲那儿等，头发湿漉漉地贴着额头。我看她手指一直悬在刷新按钮上方，没点下去。大概等了两分十一秒，她站起来，拎桶走了。我没问她最后刷出来没。

　　我现在每天早上第一件事，不是看DAU曲线，是看崩溃率告警里有没有新增的 pay-related tag。如果有，我就开终端连测试机，把 logcat 输出重定向到一个叫 /tmp/pay_noise 的文件里——名字起得随意，因为里面九成是噪点。上周四，那个文件生成了三百七十二行，真正有用的不到七行。其中有一行是：“native payment init failed: unknown error, err=666”，查文档，666 是系统预留码，意思是“你自己看着办”。我对着这行字盯了四分钟，然后关掉终端，打开钉钉，把那个“优胜劣汰”的词发给了产品总监。他回了个????。没别的。

　　下周一我要去深圳，不是开会，是帮他们修一个老接口：WXPayPrepayResponse 的 callback 里，有个 if (TextUtils.isEmpty(resp.getNonceStr())) 判断，但 resp 实际是 JSONObject，getNonceStr() 返回 null，所以整个 if 走 false 分支，后面直接 NPE。这接口已经在线上跑了四年。我打算修。但我先得确认一件事：他们那边的 build.gradle 里，com.tencent.mm.opensdk 还是不是用的 5.1.6 版——那个版本 parse 返回值时，如果字段缺失，会返回空字符串而不是 null。这事我不能光看文档，得现场抓包。所以我不带电脑，带一台刷了 LineageOS 的 Pixel 4a。它电池掉电快，但 adb 反应准。我需要准的反应。别的，再说吧。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!