ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

推荐系统AB测试实战拆解:从分流到点击率提升的完整指南

推荐系统AB测试实战拆解:从分流到点击率提升的完整指南 做推荐系统的人基本都听过这句话“算法好不好得上线AB一下才知道。”可真到自己动手很多人会发现AB测试这套东西听着简单做起来全是坑。从分流不均匀、指标口径打架到实验跑了两周还不敢下结论每一步都在考验你的耐心和判断力。这篇文章我想从自己的实操经验出发把推荐系统里的AB测试完整拆一遍讲清楚为什么要做、怎么做、怎么判断结果以及“点击率提升30%”这种目标背后到底意味着什么。这篇文章适合三类人一是刚接触推荐系统、想搞明白算法怎么评估效果的算法工程师二是正在搭建数据实验平台的数据工程师或数据分析师三是想通过实验思维优化产品的产品经理。文章里不会有太多玄学都是可以直接落地参考的思路和方法。1. 先把问题拆清楚为什么推荐算法优化必须靠AB测试1.1 离线评估的天然盲区离线指标涨了线上却崩了推荐系统最常见的评估方式是离线评估也就是拿历史日志数据把用户过去的行为当作“标准答案”去衡量模型预测得准不准。常用指标包括AUC、GAUC、NDCG、精确率、召回率等等。离线评估的好处是成本低、速度快、可以反复调试模型但它的缺点也很致命离线指标和线上真实效果之间永远隔着一层窗户纸。我经历过很多次这样的情况模型离线AUC提升了两个点召回率涨了5%看起来是个大胜利结果一上线线上点击率反而跌了。为什么会这样因为离线评估是基于历史数据做的模拟而线上环境是实时变化的。用户今天的行为模式、场景的上下文信息、商品池的组成结构可能和两三天前的数据已经不一样了。更关键的是推荐系统的离线和在线存在“反馈循环”线下数据是旧策略下的产物而新策略的目标是改变用户行为一旦策略变了线上用户的行为分布也会跟着变这个变化在离线数据里是看不出来的。以点击率预估模型为例离线评估时我们假设“曝光了但没有点击”的样本代表用户不喜欢。但线上真实情况可能是这个位置太靠下用户没看到、卡片加载太慢用户已经划走了、或者用户今天根本没心情购物。这些样本在离线dataset里都被统一打上“负样本”的标签模型学到的是一个被严重噪声污染的分布。这就是离线指标的局限性——它能告诉我们“模型从历史数据中学到了多少规律”但很难告诉我们“策略投入真实场景后会产生什么连锁反应”。AB测试的价值就在这里。它把新旧策略同时部署到真实流量上用严格的实验分组机制隔离变量让数据自己说话。分层流量、随机分组、双样本检验……这些听起来复杂的术语本质上都是在回答一个最简单的问题用户行为的变化到底是我们的改动带来的还是随机波动造成的1.2 AB测试在大数据推荐场景里到底在测什么很多人会觉得AB测试就是“分两组一组用老算法一组用新算法看哪组点击率高就选哪组”。这个思路方向没错但真到了大数据推荐场景里事情没那么简单。第一个要搞清楚的是“测什么”。表面上看测的是算法模型但实际上测的是“策略组合”。一次推荐系统的改动往往不只是换一个模型权重可能同时改了召回逻辑、排序融合方式、多样性控制参数、甚至前端展示样式。如果一次上线同时变了太多东西实验出来了也说不清楚是哪个改动带来的提升。所以我在实际工程中强烈建议一次实验中只改动一个核心变量其他保持完全不变。比如这次只改排序融合的权重那召回和重排逻辑就都不要动。第二个要搞清楚的是“用户粒度”。推荐系统的指标模型往往以用户的实时行为为粒度但是AB测试的分组却通常以用户ID为粒度。这意味着同一个用户在所有实验中都只能落在同一个桶里不能今天看见的是新算法明天又切回旧算法。原因很简单推荐系统是有记忆的用户对个性化推荐的反馈是连续累积的。如果用户在同一次请求中混合看到新旧两种算法的结果我们根本没法区分某个点击是哪个算法带来的。第三个要搞清楚的是“指标的目标”。点击率确实是推荐系统最核心的交互指标但它不是唯一指标。一个算法把点击率从2%提升到3%但如果用户点进去之后发现内容根本不是自己想要的停留时间大幅下降那这个点击率提升就是“虚火”。所以推荐系统的AB测试往往需要建立一个“指标树”既有核心指标也有护栏指标这点我后面会专门拆开讲。2. 设计指标体系点击率不是唯一指标但它是第一道拦路虎2.1 点击率CTR的口径怎么定才不会被数据骗了点击率的计算很简单公式就是“点击数除以曝光数”。但如果不对“曝光”和“点击”做严格定义这个数字可以轻松被各种因素“污染”。以一个大促活动场景为例用户打开APP首页首屏加载出6个推荐卡片这个过程叫一次“曝光”。如果他在这个会话里点了一个商品、刷走了、又滑回来点了另一个商品这两个点击都算在同一个曝光里吗很多团队的日志系统并不严格区分“一次曝光下的多次点击”导致点击率可能超过100%这是数据口径混乱的典型症状。我在设计推荐系统点击率指标体系时通常会定义三个层级曝光点击率PV CTR公式是“总点击PV / 总曝光PV”。这个指标反映了整体流量效率但容易被曝光深度稀释。比如用户刷得越深曝光次数越多CTR往往越低。用户点击率UV CTR公式是“点击用户数 / 曝光用户数”。这个指标体现的是用户渗透率适合衡量算法对用户兴趣捕捉的广度。会话内点击率Session CTR公式是“有效点击会话数 / 总会话数”。这个指标适合衡量推荐结果对用户需求的即时满足能力。到底用哪个口径取决于实验目的。如果做的是首页信息流推荐优化我通常用PV CTR做主指标因为信息流推荐最看重的是“流量利用效率”如果做的是冷启动算法优化那UV CTR可能更重要因为冷启动阶段的核心目标是“让更多用户愿意点一下试试”。但不管你选哪个口径都要先对数据埋点做一次DP数据稽核检查。我踩过一个坑前端的曝光埋点逻辑是“卡片滑动到可视区50%以上才上报”但老版本的APP没有这个限制导致新旧版本的曝光基数不一致实验结果完全没法对比。后来我们花了整整一周做埋点统一的迁移才把口径拉齐。在AB实验开始之前花时间把数据埋点核对清楚永远是性价比最高的投入。2.2 除了点击率这些指标必须一起看做推荐系统的AB测试千万不要只看点击率一个数。我建议设计指标体系时参考下面这张表指标类型指标名称计算方式用途说明核心指标曝光点击率PV CTR点击PV/曝光PV衡量流量利用效率是主实验判断指标核心指标有效点击率Valid CTR有效点击PV/曝光PV过滤掉误点、恶意点击更具业务含义辅助指标人均深度点击次数总有效点击次数/活跃用户数衡量召回和多样性是否让用户持续感兴趣护栏指标次均停留时长总有效观看时长/总点击次数防止点击率提升但内容劣化护栏指标曝光深度分布用户平均请求次数、滑动深度衡量算法是否导致体验疲劳业务指标转化率CVR订单数/点击数连接推荐结果和业务GMV目标体验指标负反馈率不感兴趣/举报次数/总曝光防止算法引发用户反感拿“有效点击率”来说这个指标是我后来才重视起来的。很多推荐场景里用户会误点、测试机反复点击、甚至被羊毛党刷量。如果不做有效点击过滤实验组点击率可能被虚假点击抬高真实业务效果却一塌糊涂。有效点击的判定可以结合点击后在页面停留是否超过1秒、点击是否导致后续浏览行为、设备是否有异常行为模式。另一个特别容易忽略的是“次均停留时长”。我见过一个改版把推荐卡片从大图改成了双列小图曝光点击率飙升了15%但次均停留时长几乎腰斩。后来用户访谈才知道小图展示让用户失去了判断信息价值的耐心基本是看到标题就点点进去发现内容不对就退。这种“浅层点击”对算法模型的训练反馈也是有害的因为模型会把“用户点击了”当成“用户喜欢”继续推送类似内容形成恶性循环。所以我在每次AB实验上线前都会先写一份指标口径文档明确哪个是主指标、哪几个是护栏指标、每个指标在什么条件下算胜利。没有护栏指标的实验我一般不建议上线因为它的结果不可信。2.3 样本量计算与实验时长估算这一点是很多推荐系统团队最容易犯错误的地方实验没跑够样本量和时间就急急忙忙下了结论。点击率提升1个百分点到底是真的有效还是随机波动这个问题必须靠统计学回答。以点击率这个二值指标为例我们做AB实验时一般用双样本比例检验z检验。样本量估算公式大致如下n (z_{1-α/2} z_{1-β})^2 × [p1×(1-p1) p2×(1-p2)] / (p1 - p2)^2其中p1是基线点击率p2是预期实验组点击率α是显著性水平通常取0.051-β是统计功效通常取0.8。z_{1-α/2}和z_{1-β}是对应的z分布分位数α0.05时z_{1-α/2}1.96β0.2时z_{1-β}0.84。举个具体的例子。假设推荐位当前点击率是2%我们希望检测出“点击率相对提升10%”也就是从2%提升到2.2%的效果那么p10.02p20.022。代入公式估算分子部分(1.960.84)^2 ≈ 7.84分母部分0.02×0.98 0.022×0.978 ≈ 0.0196 0.0215 ≈ 0.0411样本量7.84 × 0.0411 / (0.002)^2 ≈ 80,600也就是说每组至少需要约8万个曝光样本两组合计约16万个曝光。如果你的产品日活跃用户只有10万每个人每天平均刷20次推荐一天就能产生200万曝光跑一天其实就够量了。但注意这里计算的是“曝光样本量”不是“用户量量”。如果产品流量很小曝光总量不够实验时长就得拉长。还有一个很多人忽略的点实验时长最少要覆盖一个完整的业务周期。如果你做的是电商推荐至少要覆盖一周因为周末和工作日的用户行为差异巨大如果做的是内容推荐至少要覆盖一个完整的刷屏时段。我见过一个团队只跑了6小时的实验就宣布新算法胜出结果第二天发现上午时段推荐的是新闻资讯下午用户变成了刷短视频的行为模式结论完全反转了。另外样本量计算还要考虑一个因素实验组和对照组的流量是否完全独立。在复杂的重叠实验架构里如果两层实验之间有交互效应有效样本量会打折扣。不过这个我们下一节展开讲。3. 实验分流架构不搞清分层与隔离AB测了也白测3.1 基于Hash的分流策略与层内正交推荐系统场景里最常用的分流策略是基于用户ID的哈希分桶。你可以把用户ID用某种哈希函数映射到一个整数空间比如0到9999然后按余数或区间划分到不同的实验组。这样做的好处是同一个用户的ID永远落在同一个桶里不需要额外的分流状态存储几乎不增加线上延迟。但这里有一个关键概念层Layer与正交Orthogonal。成熟的推荐系统一天可能会同时跑几十个AB实验有的改召回策略有的改排序策略有的改UI展示。如果每个实验都独立分一次桶可能会出现同一个请求同时命中多个实验组的情况实验之间互相污染。Google的实践经验是将实验分成若干层每层内的流量正交划分即同一个用户ID在每层的哈希盐值不同这样同一用户会以独立的随机方式进入各层的实验组互不影响。在我负责的推荐系统平台里实验分层的设计大致长这样第1层召回策略层。这里改动的是候选集生成逻辑流量分桶后实验组用新召回路对照组用老召回路。第2层排序策略层。这里改动的是CTR预估模型或排序融合逻辑与召回层独立正交。第3层展示策略层。这里改动的是卡面元素、标题长度、图片比例测试的是前端展示对点击率的影响。每层之间的哈希盐值设计为不同的常量比如召回层用“recall_v1”作为hash盐排序层用“rank_v2”作为hash盐。因为哈希函数的雪崩效应同一个用户ID在不同盐值下会均匀散落到不同分桶这样就实现了各层正交。简单理解就是用户在召回层的分组和他排序层、展示层的分组没有相关性这样可以同时跑几个实验而互不干扰。3.2 实验数据管道与埋点一致性分流解决了“用户怎么分”的问题接下来要解决“实验结果怎么数”的问题。很多团队重金搭建了实验平台结果每次实验的结果都是分析同学用SQL手动数出来的不同人不同口径每次数完还要对半天数。在我的团队里我们做了一套相对规范的实验数据管道第一层是埋点数据接入。客户端上报的曝光、点击、停留等行为数据通过消息队列进入数据仓库。这里有一个注意点消息队列的topic要按行为类型分开曝光、点击、滑动、负反馈各自独立不要混在一个topic里。混在一起会导致下游消费者逻辑复杂还容易丢数据。第二层是实验分流日志接入。线上分流服务在每次请求时除了返回实验策略配置还要把用户ID、请求时间、实验ID、分组信息写入一条分流日志。实验分析时用这条分流日志去关联用户行为才能准确知道“哪些用户属于哪个实验组”。这里最容易出现的问题是分流日志和行为日志的时区不一致。比如分流日志记录的是UTC8时间行为日志记录的可能是UTC时间导致关联时出现一天偏移。第三层是指标聚合层。我们一般会使用Spark或者Flink对实验数据做按天粒度的预聚合形成“用户日粒度行为汇总表”。这样做的好处是日常分析不需要每次都扫描原始日志大大节约计算成本。聚合表主要包含用户ID、实验ID、分组标识、曝光数、点击数、有效点击数、停留时长总和、负反馈次数等。3.3 从离线评估到线上AB漏了这一环策略上线就悬很多团队在做完离线评估后就直接把模型部署上线连AB实验都不做。我觉得这绝对不行。离线评估最大的问题在于它没法验证“实时性”和“反馈闭环”。但如果你做的是深度推荐模型我建议至少走一趟“影子模式”或者“放量观察模式”。影子模式的具体做法是线上请求进来后同时用老模型和新模型做预测但线上展示的仍然以老模型结果为准。新模型的预测结果只记录下来不真正影响用户。这样可以在真实流量上积累新模型的“虚拟预测日志”然后离线对比“如果当时用了新模型用户行为会有什么不同”。影子模式的好处是没有任何试错成本但缺点也很明显它低估了真实反馈闭环的价值。因为用户没有真实看到新模型的结果他的点击行为不会被新模型影响所以影子模式下评估的指标更像是一个“半在线”的评估。它适合做模型上线前的安全检测不适合替代AB测试。真正可靠的上线路径还是离线评估 → 影子模式或小流量灰度 → AB实验 → 全量上线。每走一步数据验证的严格程度都在提高风险逐步降低。4. 实操案例一次把推荐点击率提升22%的完整迭代4.1 基线问题定位为什么老策略太平庸有一年我被安排去做信息流推荐场景的优化当时负责的推荐位点击率已经连续几个月徘徊在1.8%左右几乎没有任何起色。我们在做离线分析时发现点击率低的很大原因不是模型不够好而是推荐内容的同质化太严重。怎么发现这个问题的我们把用户点击过的Item再拿去做语义聚类发现用户点击的内容集中在少数几个主题的头部。也就是说用户对推荐位的第一屏内容还比较感兴趣但刷到第二屏、第三屏时算法推送的还是类似的头部内容重复度极高用户很快就腻了。那会儿我们用的排序模型是一个双塔模型加上一些融合规则。双塔模型负责产出点击率预估分数融合规则负责把新鲜的、但分数没那么高的内容抬上来。问题就出在融合权重太保守新鲜内容几乎很少有机会进入前20名。我们从日志中抽取了一个样本用户反复看了8个同一IP题材的电影推荐但都没有点击然后离开了推荐位。这就说明即使预估分数都不低但如果多样性控制做得不好用户同样会流失。4.2 策略改动方案加实时行为特征调整融合权重定位到问题之后我们制定了两个改动策略。第一个是加入实时行为特征把用户过去5分钟内的实时点击序列编码成向量拼接到推荐模型的输入特征里。这样做的好处是用户的短期兴趣偏移能被即时捕捉增强了推荐结果的时效性。举个例子用户刚点击了一篇关于减脂的健身文章系统马上就能在下面几帧推荐更多健身相关内容而不是继续推他两小时前看过的时政新闻。第二个改动是调整融合权重在排序阶段我们给“内容新鲜度得分”和“同质惩罚系数”各加了一部分权重。内容新鲜度得分来源于稿件的发布时间和实时热度同质惩罚系数则基于当前推荐列表里已经展示过的Item主题分布对与已展示内容过于相似的候选进行降权。这个权重我们用离线历史数据扫了一遍参数选用“新鲜度相对权重提高3倍时离线NDCG还能保持不降”的阈值作为实验参数。听起来不难对吧但真正做起来要小心一个静态特征陷阱如果我们只是简单地把实时行为特征拼接进双塔模型会发现训练和推理阶段不一致。训练时用的是用户过去5分钟的“真实历史行为”推理时如果线上获取不到实时的行为序列比如用户在服务端有缓存延迟模型拿到的特征就是空值或过期的。我们在上线前做了一个特征对齐检查发现实时行为特征在推理链路上的P99延迟高达800ms如果不优化会导致排序请求超时。于是我们把这个特征的实时路径改成“特征服务异步更新、读时合并”的方式确保推理时拿到的是尽可能新鲜的数据。4.3 实验配置与上线过程我们上线了一个排序策略层的AB实验。实验组用的是“加实时行为特征新融合权重”的新策略对照组是老的双塔模型加老融合权重。分组方式是用户ID哈希到100个桶实验组占50个桶对照组占50个桶互斥隔离不做重叠实验。实验开始前我们先做了一轮AA检验。AA检验的意思是不改变任何策略只是把用户随机分成两组验证这两组的点击率、曝光量等指标在统计上无显著差异。如果AA检验都不通过说明分流逻辑本身就存在问题后面的实验都不可信。我们的AA检验结果是点击率差异0.03个百分点显著性p值为0.62说明分流是均匀的。正式实验跑了5天前3天我们按兵不动只做数据监控防止出现突发的数据异常或者线上报错。第3天的时候看着实验组的实时点击率比对照组高了大概18%我心里已经有点激动了但忍住没有下结论因为要等样本量跑足。第5天准备结束实验前我们用双样本比例检验算了p值。基线点击率1.8%实验组点击率2.2%整整提升了22%。因为流量足够大两组日均曝光都过百万p值小于0.00195%置信区间也明显不跨越0。同时护栏指标里次均停留时长不降反升了5%负反馈率也下降了说明这个点击率提升不是靠“标题党”带来的虚火。整个实验从确认方案到拿到可下结论的结果一共花了两周半。包括特征开发、离线调参、线上灰度、AA检验、正式实验和数据分析。4.4 结果分析方法与显著性判定实验结束后的数据分析我建议至少分三步走第一步是总体验证。看主指标点击率在实验组和对照组之间有没有显著差异。这里不能只看简单的“差的百分比”要用假设检验和置信区间。点击率这种比例型指标可以使用z检验也可以用boostrap等重采样方法估算置信区间。在数据量足够大的时候两者的结论一般一致。第二步是分维度拆解。只看整体往往看不清问题。按用户新增/存量、设备平台、地域、流量位等维度分别看实验效应经常能看到“实验组整体显著提升但新用户群体呈现下降”这种复杂情况。举个例子我们当时拆解就发现实时行为特征对冷启动的新用户几乎没有帮助因为新用户没有足够的历史行为数据模型里这个特征接近于空。但对于存量用户提升非常显著。第三步是时间趋势看稳定性。把实验期间的指标按天绘制趋势观察提升幅度是否每天都在稳定出现。如果某一天的提升主要靠一个大促活动拉起来其他天都是持平甚至微降那就说明这个策略带有较大的偶然性不足以支撑全量上线。我们当时注意到实验组和对照组的指标差距在整个实验周期里是持续且稳定的没有出现“头两天大涨后面就衰”的现象。提示在实验结果判断时除了看p值和置信区间一定要同时检查“提升幅度的实际业务意义”。统计学显著不等于业务上值得上线有些改动虽然统计显著但提升幅度过小比如只提升0.1%的正向效果但带来了明显更高的计算成本或延迟那就需要算一算性价比。5. 常见问题与排查技巧实录5.1 AA检验不通过分流不均匀碰到这个问题不要急着重新跑实验先查三件事第一分流依据的用户ID是否稳定有的客户端上报的ID会变比如未登录用户的临时ID会因设备重启而改变导致同一个用户被分到不同组污染实验第二分桶的哈希盐值是否冲突前面说过每层实验要用不同的盐值避免层间实验串流第三样本量是否足够稀疏如果某些分桶的样本量很少AA检验出现了肉眼可见的差异其实不奇怪。有一次我们做AA检验不通过查了一整天发现是一个线上缓存害的分流服务在本地缓存了用户ID到组别的映射但缓存过期时间不一致导致同一个用户进来时有时分到A组有时分到B组。清理掉缓存重新做了一遍AA马上通过了。5.2 实验组点击率涨了但整个业务大盘没涨这种“局部胜利、全局失利”的情况通常有三种解释。第一种是新鲜感效应新策略刚上线时用户感到新奇点击率短暂上升但过一段时间效果衰减。针对这种解释最好把实验拉长或者提前设计好重复观测的办法。第二种是流量挤兑效应实验组用户点击率确实升了但他们的点击是在页面其他位置上“抢”来的整体APP的时长和转化并没有改变。第三种是辛普森悖论整体数据看起来没涨但拆分各层用户后实验组在各种用户群里都显著上涨只是实验组的流量分配了更多低活跃用户拖低了总体数据。解决这类问题的方法是建立一个统一的“实验效果归因表”把实验的关键指标和其他业务指标放在同一个维度下去对比不要只看单指标。我曾经在一次实验中遇到点击率显著上涨但GMV几乎无变化的情况最后发现是推荐算法把用户导到了低价商品上点击率自然高但客单价低了。我们把指标从CTR切换成“点击GMV价值”后结论反转为实验策略不佳。5.3 新用户与老用户的效果分化推荐系统的实验经常出现“老用户效果显著提升新用户效果反而变差”。这个问题的根源在于新用户没有历史行为个性化特征形同虚设。解决思路之一是给新用户单独设置一个冷启动策略层实验组的改动只影响老用户新用户仍然走保守策略。当然如果你就是想验证冷启动算法那就应该把实验流量集中到新用户上指标拆分也要按用户群分开看。我之前做过一次实时特征实验数据拆解后看到新用户组的AUC下降了0.3%细查原因发现实时特征模块在缺少历史行为时会用热门Item的全局embedding代替这在部分低活跃用户身上反而拉低了偏好匹配度。后来我们把冷启动用户归入全库热门兜底策略实验组提升才稳定下来。5.4 实验收敛慢、显著性不足实验跑了一周p值一直在0.05上下波动就是过不了置信线。这种情况建议先做一个“观察功效”分析按当前的样本量我们能够检测出的最小效应量是多少。如果最小可检测效应是30%而实际提升只有10%说明样本量不够继续跑下去大概率也得不到显著结果不如加量。另一种情况是指标方差太大。点击率这个指标在用户粒度上方差极大因为有的用户一天刷100次有的用户只曝光一次。解决办法是将指标从“曝光点击率”改为“用户点击率”或者对实验组按用户活跃度做分层stratifification降低方差。我见过一个团队以前做实验总是测不出显著结果改成按活跃度分层后同样的实验提升幅度从“不明显”变成了“显著为正”。5.5 实验之间的相互污染当公司的业务线很多、推荐位很多时实验之间最容易被忽略的问题就是“效应串门”。A实验组改进了首页信息流的点击率B实验组在详情页测新的推荐算法结果A实验带来的“点击增长”改变了用户进入详情页的行为分布从而间接影响了B实验组的结果。针对这个问题靠“注意”是不够的要建立实验的互斥或者正交机制。在同一用户会话内不同层级实验可以正交但如果是同一个页面同时参与多个实验必须做到互斥。另外实验平台最好维护一个“生效实验清单”当新的实验申请上线时平台自动检查它涉及的流量范围是否与其他实验冲突如果有冲突就强制拒绝。这一步看似是流程问题其实对实验结论可信度非常关键。最后再分享一个小技巧在我做推荐系统AB测试的这几年里最深的体会就是AB测试真正要验证的不是“改动是否有效”而是“我们对用户行为的理解是否正确”。你要对你推荐策略背后的假设足够敏锐然后用严谨的AB实验去证实或者推翻它。最后给一个非常实用的小建议每次实验结束后不管胜出还是失败都写一份简短的实验复盘报告。报告里不仅写结果更要写下当时的假设、数据观察、踩过的坑、下一轮的想法。很多团队做实验都是“出了结果就扔”完全不积累知识资产这样即使做了十次实验成长速度也非常慢。而那些持续在做推荐系统优化的团队往往就是靠着一份份实验复盘报告把对用户、对算法的理解一点点沉淀下来的。这一点我个人强烈建议你上手去做。因为等你实验做得多了会发现AB测试最有价值的产出往往不是“提升了某几个百分点”而是“我知道了哪个方向不应该再浪费时间去尝试”。
返回列表