算法工程师如何应对业务方和老板的灵魂拷问？

导读： 你是否有过来自用户、业务和老板们的 badcase “灵魂拷问”：

• 我运营的首页频道入口不可用，怎么回事呢？

• 为什么推送的消息，点进去是空白页面？

• 为何这个商品的排序是这样的？

• 这个前端改版为什么效果一般，这个频道入口为什么排在前面？

• 这个商品是我们运营 BD 了很久的商品，折扣非常低，怎么排序就这么靠后呢？

• 这个卖家最近被投诉了这么多，商品评分这么低，为什么排在第一个位置？

• 这个商品怎么会展示给我看呢？太恶心了，根本不是我喜欢的！

• 我的首页推荐的为什么有情趣相关的商品？

• 我刚刚下了一单买了个宝宝推车，怎么还在给我推荐呢？我又不会买 2 辆。

• 昨天我买了个 iphone 11 手机，怎么今天给我推送了关于 iphone 11 降价的消息？

• 首页猜你喜欢推荐怎么都是同类型的，多样性怎么这么差？用户没法逛起来的。

• 刚刚点击了一个商品，下拉刷新推荐为什么没有变，方案不是实时的吗？

• 刚买了桶食用油，怎么这么多坑位给我展示食用油啊？体验太差了！（本条来自阿里朱仰慕老师的知识图谱分享）

“知乎这个相关问题是什么鬼？”（来自知乎）

----瞬间崩溃----

潘乱老师的文章中有一段叙述，描述了 Robin 经常反馈 badcase 的情况：

李彦宏爱看互联网新闻，但手百的个性化算法满足不了需求，策略部门天天就被李彦宏报各种 badcase，比如去年底爆出的百度内 Feed 业务推荐沟通群的群聊截图，李彦宏问一条"搜狗 IPO 路演 PPT 注释"的新闻并未推送给自己。…手百团队的应对是给李彦宏私人定制一条流。手百的策略部门找到百度新闻的科技内容运营，把手百 Feed 推优平台的互联网分类做成了李彦宏专用的定制流，早 6 点到晚 12 点要有人时刻在推。算法搞不定李彦宏的口味，就靠编辑们纯人工加班加点。当然李彦宏知道后废止了这个行为，但不知他是否知道他经常搜索的花草树木搜索结果页也是优化定制的。

我觉得 Robin 反馈问题应该是真实的，毕竟信息流是百度重要的业务线，但是后面的专门定制和人工运营可能稍微有点夸张了。但是这背后是互联网激烈竞争下，老板对于产品的要求越来越高。

互联网流量红利见顶的情况下， 谁能更好地精细化地满足用户需求，谁就能在激烈竞争中胜出。而 badcase 确实是一个个的坑，用户摔跤多了，以后就不来你这条路了，挽回往往需要高昂的成本；用户开开心心使用一般不会反馈问题，一旦不开心就有可能投诉反馈。如果一个产品很久没有投诉反馈了，那倒要关心下活跃度了。如何快速地定位和识别哪些是坑 ( 有些不是坑，是看上去像坑 )，并且快速填平这些坑是重点。

本文主要从个人角度给出一些看法，如有不妥之处还望大家批评指正。

01 怎么看 badcase

1. 存在的必然性

世界上没有完美的事，也没有完美的人，人设计的产品也不可能有绝对完美；很多产品、算法模型都做不到完美，badcase 总是存在的。人工运营或设计的产品，肯定就没有那么千人千面，用一个或者几个形态去满足万千用户，肯定无法让所有人满意；就算是千人千面的产品 ( 比如淘宝已经非常智能、个性化 )，还是存在着被用户吐槽的各种问题，因为机器学习/算法，也始终是在预估一定的概率，模型最后得到的也是兼顾大部分的一个解，也不是覆盖全部用户的最优解；更何况是各类模型的训练基于的数据也是有偏的，存在一定的噪声 ( 比如网站数据中存在刷单、爬虫、恶意攻击、用户误点等各类非正常数据 )，那学习出来的模型更加有偏了。

2. 分类

Badcase 背后是对于理想态的追求，从 badcase 中可以发现：系统 Bug、逻辑漏洞、业务迭代方向。我们先对 badcase 问题进行一个分类 ( 你也可以有自己的分类 )，然后集中讨论其中若干问题。

① 功能性问题：系统 bug

• 服务器日志打满了，造成服务阻塞

• 运营配置的链接过期了，用户无法进入活动页

② 体验性问题：

• 推荐系统中推荐买过的商品、推荐买过并且降价了的商品

• 搜索系统中搜了绿色袜子，但是红色袜子排在了绿色袜子的前面

• 首页猜你喜欢的推荐都是色情类内容、各种标题党内容

• 个性化推荐结果中都是同类型的内容或者商品，没有多样性

③ 政治正确性问题：

• 各类政治反动类的内容

④ 不明确问题：

• 为什么这个商品/内容排在第一个

• 为什么频道的排布是这样的

• 为什么运营 BD 的高折扣商品流量不大

其次我们将上述四种问题进行优先级排定，毫无疑问，①和③类问题非常致命，需要马上解决，这些问题往往决定了产品的生死。对于①类核心链路上的功能类的 badcase，随着这几年互联网的发展沉淀了一套测试和监控体系，③类问题目前内容类产品遇到的比较多，解决方案是通过自然语言、图像、流量分发算法与人力审核结合的方式解决。

而②类问题和④类问题，我们需要结合数据来做判断和优先级排定；对于②和④类的需求，构建 “badcase 收集 -> case 分析与挖掘 -> 策略尝试 -> 观察线上核心指标与 badcase 重新评估” 的闭环。

这里主要对②和④类问题进行展开，本文接下来主要会对一些偏不明确类需求来做更多的展开与介绍。我们从 case 分析开始介绍，关于 case 的收集我们在最后略做介绍。

02 分析

单 case 分析能够从若干个样本点发现用户体验问题，可以帮助算法工程师寻找迭代点，是产品经理进行需求挖掘的手段，但需求的论证还是需要与覆盖更全面的数据分析结合，特别是 case 背后问题的覆盖率 ( 比如 case 是偶发还是大面积的 ) 和一些系统性的问题 ( 全局流量分配问题，商品/卖家成长性问题等 )，这些问题需要从全局维度进行一些数据汇总和挖掘，才能发现一些问题。不要先说对错，请先用数据分析度量一下，资源有限，根据分析结论确定优先级。无法衡量就无法优化，对于互联网产品而言，系统的更新迭代必然需要建立一套度量衡，来把控整个流程优化的方向。

1. 线上问题分析的前提

通过埋点尽量多的收集数据，包括用户行为数据、线上当前环境数据、产品展现逻辑数据 ( 比如推荐召回、排序、业务逻辑流程数据 )；这些数据尽量全，尽量覆盖用户全生命周期；没有埋点和数据回流为前提的线上迭代，都是耍流氓。

2. 分析与挖掘

那怎么分析呢？我们来举几个例子，包括线上和离线 2 种，离线主要涉及模型迭代中的一些问题 ( 机器学习模型的优化可以从特征分析、样本分析、模型分析出发 )。

线上：

① 老板提了一个 case：

"刚刚猜你喜欢点击了一个商品，下拉刷新推荐为什么没有变，方案不是实时的吗？"

我们先来这个 badcase 发生时的真实情况，查看 badcase 问题的日志发现，此次点击进入商品详情页只停留了 0.5 秒就马上退出，进而在首页下拉刷新了页面，并快速再次划到了猜你喜欢。

我们再来看几个数据：下拉刷新用户占比、用户各页面停留时长、平均用户偏好衰减情况：

首先我们看到有下拉刷新的用户占比只在 0.85%，其次用户在商详页的停留时长集中在 2-17 秒之间，并且结合用户行为衰减情况，在短时间周期内，用户行为聚集程度较高。通过分析结合问题，第一个下拉刷新的问题，此功能是一个极少用的功能，更多人是下滑加载新的页面时才会再次请求推荐接口；第二个问题点击商品后，推荐过程中兼顾 2 秒内完成实时日志回流并在下次翻页请求时完成计算就可以做到一定程度上的符合，但是这个 case 中商品详情页停留时长过短，整个推荐日志流还未返回。

当然在成本可接受的范围内，实时性的提升肯定可以带来更多收益，只不过成本的上升与收益的增加是否能够相对正向是需要考量的。当然推荐策略的实时性还可以嫁接一定的分群策略，比如新用户刚进入推荐资源位，基本没有行为，快速的正负行为 ( 有点击和曝光无点击 ) 反馈收集可以帮助推荐更精准，并且产品每天有大量新用户来访，这时候可以看看是否有必要加快日志的回流。

② 类目或者行业运营提出了一个 case：

"首页猜你喜欢在鞋子类目分发到的流量占总流量的 7%，而搜索却有 15%；搜索代表了主动意图，更能够代表全站用户的意图，理应猜你喜欢也是这样的类目分布？"

因为问题是类目在商品粒度的曝光量问题，我们可以先看几个数据，2 个场景曝光的商品在商品画像维度有啥区别吗？对于有区分性的特征，展开进行二次分析。

上图的分值是通过曝光商品的曝光量与商品特征中的特征值加权平均后的值，描述曝光情况的。从上图我们可以看到在评分和客单上搜索明显低于猜你喜欢，但是 CVR 上明显高于猜你喜欢。

那我们逐个再做分析，评分我们拉取了推荐和搜索的数据，发现原来推荐场景 3 分以下的商品没有曝光；恍然大悟，之前推荐场景为了提升产品调性，对于低评分的商品不做展示，所以天然推荐场景就少了一波商品；在看价格那栏，搜索 3 分以下的价格明显较低，那也一定程度上说明了上面图中搜索客单价低的一个点；最后我们再看看 CVR 猜你喜欢低的很多的原因，其实我们分析各个类目都会发现搜索要高很多，为什么呢？因为搜索场景天然是用户主动意图场景，而猜你喜欢场景意图更弱，所以天然就是高的，所以 CVR 这个的差异是正常的。

我们还可以对其它维度再进行拆解分析，但是你已经发现了评分带来的问题，这时候，可以在低评分是否展现 ( 调性诉求 ) 上与类目流量上进行权衡，也可以通过 AB 实验观测相关指标。

上面问题延伸出来还有一个问题是，用户冷启动时，冷启动的商品列表如何分配类目流量，可以参考下图，通过点击、订单、gmv 贡献率三者给予不同的权重，来进行配比。

③ 我们再来看一个 case：

"首页猜你喜欢怎么类目这么单一，用户没法逛起来，多样的话用户长期留存会好。"

这里隐含了几个问题：用户可能喜欢看到多类目的猜你喜欢推荐列表，才会逛起来；用户看到的类目多了，长期来说可以增加其粘性。这里我们可以通过捞取历史的用户日志，分析用户的购物路径下的商品浏览情况；其次我们可以通过历史数据分析用户浏览类目数多的情况下，未来回访和留存是否好。

首先我们将全站用户进行区分和筛选，画出了全局用户在类目维度随着浏览时间的衰减曲线，说明在 2.5 分钟后用户行为类目集中在原有类目的概率下降非常快。但是不管时间多短怎么样，在二级类目平均的类目数都在 2 个以上的。我们再通过一些业务规则，区分用户为强弱意图用户，分析这两类用户，发现强意图用户在非常长的时间段内都维持着较高的同类目浏览，而弱意图用户则出现了随着时间快速衰减的情况。这时候可以在推荐或者搜索模块架设意图预测子模块，对于强弱意图明显的用户进行不同类目的干预，并且初期可以根据用户分群选择在每 20 个出 N 中选择一定区间，配合负反馈/EE 策略，进行类目衰减来做类目坑位更替，做到多样性。

第二个问题，我们可以通过分析，发现如果过少的类目浏览确实长期来说回访不足，当然这个可能只是相关，不是因果关系，但是这个已经可以说明在策略上是可以增加一定类目多样性来保证回访的。

稍微扩展一下，还可以分析消费折扣商品的用户未来留存和回访是否提升。这里想说的是当你的排序模型无法优化长期指标 ( LTV、回访、留存 ) 时，你可以考虑建立长期指标和短期指标的相关性，从而保证留存应有的良好前提。做了 ( 保证曝光有类目多样性 ) 不一定能提升长期留存，但是不做 ( 推荐结果让用户没机会看到更多的类目 ) 肯定会让长期留存变低。短期实验上线全量时，还可以考虑切小流量做反向 AB 实验，来做最终的长期指标因果关系观察。

离线：

排序模型迭代两个模型架构设计差异大，但是离线 AUC 接近，如何选取和优化；或者深度学习模型排序结果有 badcase，如何找出其中不足的地方进行优化？

比如你有 NN 类模型和 GBDT 2 类模型，离线指标差异小如何选取和融合呢？我们先看看数据，取出两类模型测试样本集的预测结果与真实结果，分别对预测结果高度一致和非高度一致的取出分析 ( 分类模型可以取出错分样本或者分类正确样本 )，通过样本背后的特征做分析，如下图：

从上面的表格中，我们看到 GBDT 模型错分的样本相对 NN 模型在平均商品周曝光量上要高，用户活跃度也相对较低；我们通过平均商品周曝光量这个维度，进行切分，将全站周平均曝光量的 25 分位和 75 分位作为曝光量高低的切分点，分别分析，出现下面的表格，以及右边的图表；最终在结合同样样本集上，两个模型 AUC 接近，得出在现有的样本、特征下 NN 模型在长尾商品上表现更好，GBDT 在头部商品上表现更好；这样可以尝试在 NN 模型中加入一些先验统计类特征，或者在 GBDT 类模型中加入泛化类特征，或者可以做模型的融合。

这里还有几个点需要注意，就是 GBDT 模型也可以和 LR 类模型进行对比，模型迭代升级过程中也可以自己做对比，比如错分与正确的样本也可以做对比分析，或者高错误率的与低错误率的进行对比。

基于分析结果，我们可以对需求有大致地一个判断，到底是否非常用户体验的情况还是个例，还是非典型用户的 YY，大致预估出迭代能够带来的影响。但数据不是总能描述全部的真实世界，或者不是所有的事情都是可以用数据描述的，这时候往往还需要结合其它方法，比如用户访谈和调研，当然这里面需要设计可靠的人群选取和调研内容设计，倾听利益相关方的诉求，也可能可以从用户口中了解到竞对的优缺点，进行对比和迭代点挖掘。

03 如何处理与干预

1. 基础和快速版本

先策略规则、然后通过分析找出漏洞发生的点，进而通过算法和模型的方式进行弥补和修复。基础、简单快速类版本，往往希望在系统设计和方案选型的时候就要考虑到如何才能低成本、无其他副作用、快速准确地修复 badcase。

比如搜索引擎中通过有个搜索干预平台，某个搜索词搜不到结果或者结果不准，在搜索的 QP ( query process ) 阶段嵌入一个规则逻辑，对用户 Query 在配置的词库中的查找，如果命中则直接将其映射为配置词 ( 比如把搜索结果不准的非常见词通过规则映射为同义的常见词 )，对前面各个模块处理的结果能进行干预以快速响应 badcase 处理。

比如首页猜你喜欢不允许有黄图、或者色情类内容出现，可以在类目 id、商品 id 维度进行干预，比如对召回模块后，截断和过滤模块对命中黑名单类目 id 和商品 id 的商品进行过滤，或者通过敏感词库对召回候选内容标题进行检测是否包含，避免较明显的 badcase，从而优化用户体验。

2. 复杂逻辑迭代

上述方式往往在问题可枚举，或者可枚举方案可以覆盖 80%-90%问题的时候被使用和长期维护，这类方案简单、快速地解决线上问题。但长期来说，不会配置大量的逻辑在策略中，可维护性差，可能解决了这个 badcase 又引入了另一个 badcase， 线上一堆修修补补的规则，未来问题的定位和调优变成了比较困难的一件事。除了兜底策略以外，需要时常对规则收口分析，最终落地为通用的模块。根据规则所覆盖的逻辑进行抽象，抽取出背后所代表的问题，从 badcase 中学习总结规律持续寻找更优雅的方式解决。

通过将问题背后的遗漏点融入原有体系，比如对模型依赖的样本进行清洗和去噪，构建相关特征纳入到模型中，将 badcase 背后欠考虑的目标融入原有目标，或者通过业务干预层的方案设计收口等，前三种都是在模型效果维度进行干预：特征，样本，模型。

① 搜索中场景的相关问题

搜索中常见的一些相关性问题，可以归纳为词汇的同义、多义问题 ( 苹果 )，语言表达差异 ( 袜子男，男袜 )、输入错误 ( 背带库 )、泛语义/非常用词召回 ( BTS->防弹少年团 )，无供给问题 ( 没有匹配搜索词的商品/内容 )、误召回问题 ( 相关性问题 )、展示问题 ( 真正意图商品排序靠后 ) 等。语义/非常用词召回可以考虑引入领域词库，训练的 NLP 模型 ( 比如 Embeding )，自动建立非常见词与常见词的关系，并在用户搜索词调用搜索扩展和归一。

下面为搜索模块图，相关可参见：万字长文解读电商搜索——如何让你买得又快又好

② 流量分发中的内容不合规 ( 黄图、色情文字 )

内容不合规问题 ( 黄图、色情文章 )，可以通过图像和 NLP 模型进行识别，结合用户的行为数据来做干预的方式来解决 ( 我们发现电商中色情类商品，往往点击率高 ( 前 25%分位 )，但是同样的转化率很低 ( 后 25%分位 ))，可以大大减小 badcase 的情况。

③ 多目标/多阶段问题

比如建模过程中希望兼顾多目标时，算法模型不是离线 AUC 提升就可以上了，你的建模是有偏的 ( 比如 point wise 的建模 )，样本无法描述用户真实的情况。推荐场景中往往需要考虑点击率、转化率、客单价、回访、留存等。你需要做的事情是，模型的目标如果没有涉及 badcase 背后的东西，那模型只会考虑当前指标，带来 badcase。当然第一步是需要给出指标的度量方式，比如很多时候产品调性是一个常被提及的词，那什么叫产品调性呢，如何度量是关键，如果可以度量，被模型纳入进行才能成为可能。

比如推荐中的多样性问题，只通过 point wise 的 CTR 预估，很容易丧失多样性。这时候你最后还有打散的功能，这个功能无法被 AUC 指标所描述；这时候可以考虑引入 listwise 的排序策略，或多样性干预及建模 ( DPP 或 MRR ) 方式。当然多样性也可能不是最后模型的问题，而是推荐的前置模块出现了问题 ( 如下图 )，导致如何修正目标和数据，都无法在排序阶段拿到很好的多样性。进行充分的埋点完成日志收集，如果按类目和主题在排序漏斗上快速收缩，则需要优化前置逻辑 ( 比如召回 )，否则无法在精排层完成多样性的提升。

当然这里需要设计一套合理的方案去尝试评估前后依赖的模块。文章可以参见：

https://engineering.linkedin.com/blog/2019/06/community-focused-feed-optimization

04 总结

细节决定成败，从 badcase 出发，充分分析过后可以带来全新的世界。

1. 分析例行化

先找到核心指标背后的若干可度量指标，并建立起与短期可观测指标的联系 ( 因为往往每个产品的核心指标都是长期的 )。比如用户回访、单次 session 内转化率与长期留存和 LTV 相关的指标，单次 session 内转化率好评估，但是用户未来的回访怎么在每次用户来访时度量？这个可以结合之前长短期指标关系出出发，通过分析相关性建立两者的联系，假设最终我们分析到用户单次浏览的类目数和折扣商品数均会带来用户回访的提升，那我们就可以从这两个指标出发构建一个自动报表提升。

① Badcase 提取器

通过 badcase 寻找优化迭代点，不失为一种好的方法，那如何收集和挖掘呢？如何找典型样本点？

比如通过每天或者每周自动化统计各个场景高流低转的商品 ( 曝光量属于类目 25 分位，转化率属于类目 75 分位的商品 )，通过商品 A 的 id 查找当日的行为日志，随机挑选若干用户作为 case；将这些用户在场景内推荐、搜索、分发置顶策略的执行过程日志捞取，并做分析，分析为什么这些商品能够被召回和排序出来，可能是召回问题，可能是特征问题，可能是模型问题；找到一定规律后就可以针对性的优化了。

上述问题还可以通过 badcase 找到对应的人群，分析人群的效果。比如对上述商品 A 的所有曝光，我们拉取后根据用户维度进行聚合，发现都是这个商品相对于全局，被分发到了非常高比例的新用户，那可以看看推荐逻辑中是否有跟新用户相关的逻辑，有可能是你的冷启动列表问题；你也可能发现这个商品的近期转化数据异常高 ( 背后可能是商家的刷单 )，导致流量在某个时间节点突然变多，那你就找到了如何对作弊商家和商品的处理方向；也可能是发现这些商品同属于一个类目 ( 情趣用品 )，这类商品往往点击率高，转化低。

分群还可以发现新上策略的问题，比如 B 策略在 ABtest 中表现较好，很快就全量上线了，但是通过高流低转 badcase，发现原来 B 策略在人群 1 ( 老用户 ) 上效果翻倍，人群 2 ( 新用户 ) 上效果减半，但是最终效果只提升了 25%；这时候你可能在人群 2 上沿用老策略，人群 1 上使用 B 策略，效果就又有了一个很高的提升。

搜索中则可以分析热搜词中低点击率的 Query，同样可以分类目来看。可能可以找到问题，是在这个 Query 下，QP 逻辑处理不好，导致召回商品不相关，可以优化 QP 问题；或者这个 Query 下根本没有相关的商品，比如用户搜了 BTS ( 防弹少年团 )，你根本没有相关的周边产品，可以做类目和商品扩展。还可以在搜索词维度区分并分析，比如下图中的一些维度。

上述溯源过程中，需要强调的是分析过程不要仅仅只关注全局均值，需要做细粒度拆分 ( 比如分类目 )，考虑分位数、众数，甚至考虑观察方差情况，并且进行对比分析。

2. 迭代闭环

业务方、算法、产品、老板反馈，收集 badcase 信息；通过数据分析，将分析结论通过规则或模块快速应用，并结合 ABtest 进行观测；定期梳理规则、干预模块，通过样本、特征、模型融合，并结合 ABtest 进行观测；分析跟踪发现新一轮的问题。

3. 架构

① 推荐、搜索预览平台

除了离线指标的评估，往往算法工程师上线前，可以通过随机挑选一些用户请求即将上线 AB 的策略，通过用户画像及历史行为来主观观测和评估效果，相当于抽样统计来反映整体情况的分析方法。先从用户表中随机抽取用户，通过用户 id 查询用户最近的行为 ( 包括搜索、点击、加购、收藏、购买等行为 )，再请求待评估场景策略，最终使用用户行为与策略结果进行比对，主观判断是否有不妥和直观 bug 存在。比如下面的猜你喜欢推荐和商品详情页推荐：

② 系统拆解与日志上报

除了日常前后端系统的日志上报以外，推荐各模块逻辑也需要尽量埋点记录过程 ( 包括规则逻辑，记录每个规则被触发的条件和使用的频率 ) 这个被使用的定义是：被命中，且结果和 ML 模型结果不同。规则从增加到过期下线的整个生存期都应该被仔细管理。

快速定位问题的能力，抗风险能力。一条明显的推荐的 badcase 是否能够很快找出错误的原因？是召回 i2i、c2i 等等 x2i 数据没有 dump，还是特征数据有问题，还是排序模型更新的问题？这里关乎监控和报警，能否从监控和日志中快速定位原因？前端、后端、算法引擎、推荐策略 ( 召回、过滤、粗排、精排、业务逻辑等模块 ) 各个模块，如何协作才能使团队合作的成本最低而整体利益最大化？

总之，通过监控做到早于老板发现问题，通过清洗的架构快速修复问题。

4. Badcase 可以帮助你加深业务理解

Badcase 可以帮助理解用户，通过亲自体验、badcase 收集、分析挖掘、实验迭代反馈验证等环节，构建用户模型；把产品用得比任何人都熟，典型用户能够熟练地说出重点标签，负责场景核心数据非常了解，并能注意到和总结出优秀竞品的细节差异、和规律性内容，再对场景进行迭代的时候就更加顺手了。至于其它常规工具和技能的学习，那不是问题。

算法工程师需要多看数据、多做分析，养成 badcase review 的好习惯；判断一个事情是否应该投入，投入多少资源去做，在什么时候做，最终收益如何。

数据无法度量所有，由于原有机制的逻辑，非全面覆盖用户情况，所以存在实验的必要性。需要上线 A/B Testing 验证优化效果，根据指标评估项目收益，效果正向则扩量，负向则分析调整或下线，并继续迭代优化。

很多算法工程师执着于算法模型迭代，没有抽离出来，对业务及迭代优先级排定，反而会事倍功半。

今天的分享就到这里，谢谢大家。

作者介绍：

姚凯飞，出海方向创业者。前 Club Factory 推荐 &风控算法负责人，前阿里推荐算法工程师，多年电商及视频推荐经验，硕士毕业于上海交通大学，目前在跨境电商方向创业。

本文来自 DataFunTalk

原文链接：

https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247501830&idx=1&sn=70809ee69329f38f33f6f3a8162e179c&chksm=fbd77a6acca0f37c4d9516f2a8e820e0f18a9e13dad0dc3fc41829f41bab02842bd0d98e9a9a&scene=27#wechat_redirect