快生活 - 生活常识大全

给我的三个哲学启发


  许多互联网公司都会以A/B Test的形式来进行产品决策——通过展现A方案和B方案,通过最终结果来判断哪个方案更好。本文笔者将与大家分享自己对于这种决策方式的一些思考。
  A/B Test,这是如今互联网行业开发中常用的方法。它的做法很简单,某个问题如果有A和B两个方案,却无法决定哪个更好。那么不要争论,直接投入生产进行测试,把用户分成两群(划分标准可以是时间、地域、消费能力等等各种因素,但要样本足够大,足够有代表性),分别展现A方案和B方案,通过最终结果来判断哪个方案更好。
  这看起来简单粗暴,但是一种相当有效的方法。据说:今日头条就大量使用A/B Test来进行产品决策,所以迭代速度很快,效率也很高。不过,今天我想换个角度,谈谈A/B Test给我的哲学启发。
  我接触A/B Test是许多年前,那时候A/B Test的概念还没有流行,当时我甚至没听说过这个概念。但是,这不妨碍我用它的思想来解决问题。
  当时我们开发的系统里的单据管理页面有个"大一统"搜索框,设计初衷很好,希望用户"一站式"搜索到想看的内容。
  但是,单据的属性太多,原有系统的设计又很糟糕,用户在搜索框输入信息之后,程序要对所有属性进行逐一匹配检索,查询的效率特别低。如果遇上多个用户同时查询,系统基本就失去响应了。这个问题让客户非常不满,抱怨声此起彼伏。
  我们在仔细分析了用户的搜索行为之后发现:用户搜索时,大量输入的只有三个属性——客户代码、日期、订单编号。
  这三个属性的特征很明显,匹配检索也可以专门优化,速度会大大提升。所以,改进方案也很简单:收到用户提交的搜索请求时,先判断一下是否这三个属性,如果是就走专门优化的渠道。如果检索不到则弹出另一个界面,引导用户进行"完整搜索"。
  据测试:这个方案很有效,响应速度提升很多,我们也非常有信心。但是,临到要上线,却被业务(销售)给叫停了。他们的理由也很充分:这样改动看起来有道理,但是客户已经习惯了原来的逻辑,行为结果会变化("你怎么知道我的大客户没有特殊习惯呢?")。而且,这个行业的客户大多专注于生意,文化水平不高,最怕的就是系统改了要重新适应。这种改动肯定不会受用户欢迎。
  一边是系统的运行压力和技术人员的责任心,一边是销售描述的客户的惯性阻力。两边看起来都有道理,到底应该怎么抉择?
  当时我有了A/B Test的模糊想法——不进行整体硬切换,让不同的用户走不同的逻辑,甚至可以动态调整大客户的搜索逻辑,如果客户不满意随时复原。好说歹说,终于说服了销售,可以上线测试。
  测试结果显示:绝大部分客户都满意改进之后的搜索逻辑,能感知到速度大大提升,即便有少数客户感觉怪异。但是耐心加以解释,对比了常用搜索的表现之后,他们都比较愿意"花一点时间学习和适应"。所以,最终,这次改进的结果相当令人满意。
  这是A/B Test给我的第一个启发:
  在解决问题之前,如果有多种方案需要抉择,很可能每种方案都有理由,都有支持的声音,而且理由严密完整,声音铿锵有力。自说自话,总是能自圆其说。但是,评价决策的最终标准不应当是这些理由和声音,而是实际的结果。
  看看我们周围,有无数热闹的文章在解释世界,在把某种抉择描绘得无比英明。但是,支持真实世界运转的并不是这些炫目的解释,而是现实的逻辑。所以,也才会有"不看广告看疗效"的说法。
  扯远点说,卡尔·波普尔很早就发现:许多炫目的理论之所以让人着迷,是因为它们"从来都不可能出错",即便出了错也能自圆其说。
  波普尔认为:这些理论其实不是科学的理论,因为科学理论包含必须有出错的风险,只有不断通过"惊心动魄"的事实检验,理论的科学性才能得到证明。
  许多人大概会记得,在前些年小米春风得意的时候,有无数专家在宣称。小米掌握了"互联网方法论",当然能在手机市场上所向披靡,这是致胜的法宝。
  然后,小米出货量下滑,而oppo和vivo崛起了,于是大家的口风瞬间转变,"线下胜过线上"、"互联网企业做实业根基不稳"的论调开始大行其道。之后小米扭转了下跌的趋势,为小米歌功颂德的声音又开始躲起来。
  按照IDC最新的数据:2019年1季度,主攻线下的oppo手机出货量出现了6%的下跌,不知道这些专家又要说什么……
  不过不管他们说什么,都无法改变一个事实。那就是,如果你只看这些专家的说法,必然会有和许多人同样的困惑——"看书看来了许多道理,自己仍然不会做决策"。
  去年我看了《命运攸关的选择:1940-1941年间改变世界的十个决策》,也很有这方面的意思。比如:对于不列颠之战,如今许多人都在歌颂丘吉尔毫不屈服的坚定意志。但作者要分析的是:当时丘吉尔面临的情境是怎样的?他是如何决策的?如果他不选择抗战,结果大概会是什么样?…… 必须承认,这样的分析视角,会给人更多的启发和收获。
  回头来说A/B Test,还是许多年前,还是在系统开发中,我又遇到过另一件事。
  那时候,客户往往需要整批提交格式化的数据。按照日常经验,这种数据显然应当用Excel的格式最合适。用户按照我们给定的模板把数据分门别类录入好,最后在浏览器里上传到作业系统即可。
  但是这样操作也会有问题。Excel文件的交互能力比较弱,如果一次提交几百上千条记录,某一条又出了错,很难告知准确告知客户错误的位置和类型,修改起来也很不方便。
  另外,许多客户是一天提交一次Excel的,如果在Excel制作的过程中电脑死机或者文件损坏,很可能前功尽弃,之前的工作成果要全部重新来过。
  在尝试了几次优化上传界面之后,我们决定彻底废弃之前的做法,直接给客户提供一个客户端软件。客户登录之后,可以逐一录入数据,数据录入时软件会直接和服务器交互进行验证-保存,出错了则即时提示。
  这种软件开发起来不难,但也很好玩,里面有不少设计需要花点心思,大家也乐在其中。开发完之后,我们信心满满地介绍给销售同事,希望他们能推动客户使用。在我们看来,这是三赢的局面:技术不必反复查错,客户不必反复提交,销售不必反复沟通。
  不出意外,销售同事第一反应就是质疑,因为客户已经习惯了原有的操作,让他们改变操作习惯,成本太高。不过,因为之前的搜索栏改进的例子,质疑并没有成为反对,大家约定这个改进也来实地测试一番。
  这次的测试结果大大出乎我们的意料,绝大部分客户在试用新软件之后都不满意,又回到老的Excel的操作方式上来。"怎么样,说了客户的操作习惯不是那么容易改变的吧!" 这一次,获胜的是销售同事了。
  但是我们并不满意,一方面,对自己开发的软件有足够的信心(和期望),另一方面,"用户操作习惯不那么容易改变"并不能成为万金油,总有那么强的说服力。
  可是,A/B Test的结果又分明证明,确实我们想错了。那么,问题到底出在哪里呢?
  不甘心的技术人员走出办公室,深入到客户的使用场景去调查,真相才浮出水面:原来,开发时犯了想当然的错误。
  开发人员的电脑配置比较好,开发使用的是.Net技术框架,而客户的电脑并没有那么新潮,许多仍然在用Windows XP,并没有自带.Net Framework,这就让许多客户望而却步了。即便知道要下载.Net Framework,又面临版本问题,国内各种下载站捆绑其它软件的问题。安装好之后,因为电脑配置低,程序运行起来响应也很缓慢,反而不如Excel干脆利落。
  找到问题之后就好办了。把软件原有的操作逻辑都保留,.Net实现都废掉,以原生的Visual Basic重写。虽然这样有点折腾,新时代的程序员大多不会写VB了,要重新学习,但结果是非常好的。重新下发的版本在客户的机器上跑得很快,甚至比Excel还要快,迅速赢得了客户的信任,也在销售同事那里找回了面子。
  这是A/B Test给我的第二个启发:
  即便一个问题有了最终答案,也不能单纯相信最终答案所依附的那种解释,因为它可能是不对的。尽管这些解释能自圆其说,但也只是牵强附会,或者流于表面。换句话说,A/B Test这样的测试只能证明"哪种方案好",而不能说明"为什么好",不能替代人工的分析。要认清真相,我们不应忘记细致探寻其中的理由。
  我的第三个例子不是来自自己,而是来自朋友。
  近些年,A/B Test已经大为流行,会用A/B Test的人也越来越多。对应的,愿意讨论的人也越来越多了。一次吃饭时,有位朋友跟我说了这么个故事。
  这个朋友开发的用户登录界面里面临一个问题:输入手机号接收短信验证码的界面,是否需要用户先输入图形验证码?如果不要求,则这个界面可能被滥用,别有用心的人可以利用这个界面给其他人发送垃圾骚扰信息。如果要求,正常的用户流程又不够顺畅,凭空多了一重阻拦。
  因为单纯凭讨论无法决定,他们采用了A/B Test。最终发现:如今大概黑产肆虐,羊毛党猖獗,如果要求输入图形验证码,每天的无效和风险登录次数少了很多,正常用户的登录次数却没有太大的波动。从结果来看,安排图形验证码显然是一个更好的选择。
  听完这个故事,我现场给他展示了一下登录流程。在输入手机号,满心期待可以等来短信之前,硬生生弹出一个"请输入图形验证码"的界面。
  我问他:"你作为普通用户,你的体验好吗?"
  他老老实实回答说:"不好。"
  所以,从概率上看,A/B Test的结果确实防住了很大一部分黑产、羊毛党,但如果你不幸处于"不需要防住"的那一部分,对你来说这个结果就非常悲剧了。
  你说这个问题确实存在,但是要怎么改进A/B Test呢?
  实际上,所有这类决策都会有决策成本。按照80-20原则,你抓住了80%,就放弃了20%。何况现实中未必处处都是80-20,有时候你抓住的只是60%,放弃的是40%,甚至抓住的是55%,放弃的是45%。虽然从总数上看是不错的,但实际成本太高,放弃的太多。
  那么,怎么解决这种问题呢?
  解决这种问题并不是靠A/B Test,而需要输入更多的信息。
  如果你的登录界面只输入一个手机号,让用户收一个短信验证码,就是把A/B Test做出花来,也没有什么用。如果你输入的不只有用户的手机号,还有用户的IP、浏览器版本等等信息,如果是在专属App里登录,还可以加上Wi-Fi网络、地理位置、设备ID等等信息……
  你的信息更丰富了,决策逻辑就可以更复杂,可以调整的空间也更大。如果要做A/B Test也可以做更细致,可以从多层次、多角度来做A/B Test。
  这位朋友听了之后若有所思,回头找安全、风控等等行业的朋友聊了一圈,得到了更完整的方案。再过几个月我去看他们的系统,已经基本做到了"对正常用户勿打扰,对风险用户自动验证"的水平,用户体验比之前粗暴弹出图形验证码好了很多。
  实际上,这是我前些年思考的结果,也是A/B Test给我的第三个启发:
  A/B Test不是万能的,不能迷信。
  它只能教我们如何从给定的选项中择优,但许多时候选项本身的层面不对,或者粒度太粗。所以,即便做了A/B Test,结果也未必尽如人意。许多时候我们需要跳出来,输入更多的信息,或者改进A/B的粒度,往往能取得更理想的结果。
  如果你有印象大概会记得:2002年8月12日,公安部在北京、天津、深圳、杭州四个城市推行了个性化车牌。个性化车牌有6位,前三位可以由用户自行选择数字或者字母。这种给予极大自由的政策,一经推出就引发民众热捧。不幸的是,政策公布之后还不到两周,就因为"技术原因"叫停了。
  据媒体报道:这项政策被叫停的真正原因在于,许多用户自定的车牌有争议,比如BWM-001、FBI-001、USA-911、PLA-081之类,甚至还有SEX-001等等"出格"现象,被认为"不符合精神文明建设"。后来还有不少"专家"引用这个例子,证明"社会现阶段不能太过自由,否则就会出各种幺蛾子,影响稳定"之类的结论。
  在我看来,这恰恰是个典型的因为粒度过粗、层次不当的例子。如果只是粗放规定"用户可以选择/不选择个性化车牌",对"个性化车牌中不容许哪些内容"又没有任何细致的规定,结果当然五花八门,出乎意料。
  拿它当例子来证明"社会不能太过自由,否则就会影响稳定",就更是匪夷所思——自由从来都是和规定相联系的,没有什么正经的人主张社会需要毫无约束的自由。
  系统智能与否,体现在它能动用多少信息,对多少情况进行细致的分析,给出对应的处理,而不是一两条简单的if-else万事。
  同样的道理,解决问题水平的高低,也体现在问题的解决者能够动用多少信息,事先制定多少分门别类的规则,事后依据多少细致的分析,而不是简单粗放得到一个结论了事。
  最后做个简短总结:
  A/B Test很好,可以用来戳穿各种貌似合理的奇谈怪论。
  做A/B Test不只是技术上做点事情就完了,没有细致认真的分析,还是可能走弯路。
  要想给出更优的解决方案,并不能完全依赖A/B Test,输入更多的信息,掌握更多的计算能力,才可能得到更优的解决方案。
网站目录投稿:迎蕊