前端早早聊大会，由前端早早聊与掘金联合举办。
第七届 - 微前端在中后台等场景的落地实践/qiankun 的设计方法，5 月 30 日举行，7 位讲师，报名地址：huodongxing.com/go/tl7
第八届 - 如何面试进大厂，来自阿里等大厂的候选人与面试官亲自分享，5 月 31 日举行，15 位讲师（本文作者：霸天小姐姐就在本届 1688 讲师的团队中哦），报名地址：huodongxing.com/go/tl8
想了解早早聊大会动态，或围观 Scott 朋友圈，果断加微信: codingdreamer
本文为第五届 - 前端监控体系建设专场讲师 - 霸天小姐姐的分享：
正文开始
嗨各位同学大家好，我是来自阿里巴巴 CBU 的霸天。我是去年和前年的 D2 主持人，同时我也是一名前端，我们部门主要做 B 类电商的业务，可能有些同学不太清楚 B 类是什么，如果我说 “批发采购平台” 你们可能更好理解哦，我们的代表业务是 1688，我们的买家也是商家，他们来拿货去卖，当然因为价格真的便宜，也有很多的个人用户，就比如我虽然不做生意，但是我会在我们平台去买袜子，垃圾袋这一类日常消耗品。
话题介绍
我日常在 1688 负责导购营销场景的开发，日常开发过程中我们除了需要保证我们的营销场景的稳定性外，还需要关注开发场景带来的价值。今天这个话题，会比较偏向业务侧的思考，从赋能业务的角度出发，希望能够给大家带来一定的启发。
我们每天加班加点开发组件，开发新功能，但是不知道做这些事情，对这些场景是不是真的有用，开发出来的功能又带来了多少价值，我们最开始我们想要做场景度量，也正式奔着这个痛点去的。我们希望知道开发出来的场景为业务带来了多少价值，甚至当合作方的下一个需求来的时候，我可以有依据的去衡量我到底要不要做这个开发工作。如果不好，我干嘛不剩下时间去做更有意义的事情。
所以在去年，去认领的技术课题是场景度量这一块。接下里，我们一起来看下我们的分享大纲，可以分为两部分。
分享提纲
| 业务监控背景 | 技术实现过程（场景的数据监控） |
|---|---|
| 1、业务背景 2、痛点及解决思路🤔 3、场景度量功能演示 |
1、场景采集 2、场景指标清洗 3、场景数据数据流转 4、未来的规划 |
业务背景
在 1688 之前，导购场景都是小二搭建的页面，小二去圈选的一波品，选了一波组件。看起来有很多的导购场景，但是却也说不出他们的差异在哪里，导购场景的人群重叠度和货品的重叠度非常的高，并没有做到货品高效的分发，导致卖的好的商品卖的就是一直好，最开始卖的不好的商品也很难发现他们的机会。
导购场景的任何改变和运营的目的都是希望让用户能够买到心仪的货，我们希望用户能有更多的场景逛起来，每个场景都能精准的匹配到用户。从买家侧来说，提升买家购买效率，使得买家能够在短时间内匹配到自己所需要的商品。从卖家侧来说，提升卖家的交易流通效率，以需求为核心，迅速匹配到合适的买家，并且按照市场的热度生产商品。
所以我们希望我们的导购场景能更细粒度地覆盖我们的用户，把每一个买家都当作一个超级 VIP 买家（不同的人他的采购力，偏好商品的类目，关注的商品属性都不一样）。通过记录下他的偏好，我们需要给他推荐私人定制的导购场景。在业务快速发展阶段，需要进行不断的尝试和探索，转而我们做技术的同学就会接到各种各样的导购场景的开发需求。
【精细化运营，丰富的差异化心智场景】
去年，我们通过打造不同 “心智” 的场景，我们通过调整不同的推品策略和组件，去定制开发了非常多不同 “心智” 的场景，例如我们主打 “低价” 的必采清单，通过算法比对全网价格做的推品排序，同时在心智上去透传价格曲线，利润分等信息，触近价格敏感人群去下单购买。
我们孵化了主打收藏加购的 “发现好货” 的场景，通过下游趋势 / 热点的好货的数据清洗，为买家推荐有趣好玩的 “好货”。此外我们还有按照销量 / 加购赛马的 “榜单” 导购场景。有针对人群投放的 “淘宝专供”，“weishang 专供”，“跨境专供” 等。
痛点 & 解决思路
我们开发了这么多的导购场景，随之而来的是我们对场景的度量问题。
我们开发了这么多的导购场景，随之而来的是我们对场景的度量问题。
痛点
- 第一个问题，场景开发后，场景的 边界依旧难以划分，虽然我们开发了不同心智的组件和推品策略，但是运营的同学也还是经常会按照他自己的预期去圈商品去投放，导致了 场景的重叠度高， 同质化严重。
- 第二个问题，场景上线之后，需要观察业务的 数据指标波动，基于集团最基础的页面分析报告（只能基于单个页面 / 单个场景，最基础的 PV、UV、点击转化、成交转化、跳失率）， 运营同学分析成本高， 打击分析积极性。同时场景的业务数据指标（例如：PV、UV、跳失率等）也会随着商品池的变动，或者运营同学的一些干预而变动，但是业务的同学不会实时地关注我们的数据
这样就会导致两类问题。
- 第一类， 场景的优秀的干预策略没有沉淀
- 第二类， 场景的异常没有及时发现
- 第三个问题，场景投放之后，场景的 流量公平问题也需要考虑，场景的流量多，意味着场景有更多曝光的机会，会达成更多的转化，运营的同学都想要流量，那么流量到底给谁。
解决思路
【痛点到解决思路】
- 场景的重叠度高，没有体现出心智
场景的重叠度高，是因为场景的边界不够清晰，所以我们就需要去数据化地描述这个场景。场景最通用的模型 “人货场” 三角效率模型，一个导购场景的心智是由出现在这个场景里的商品和投放的人群来定义，我们需要清洗商品及人群的指标。于是我们做了场景的人群下钻分析和商品下钻分析。
有了人群和商品的基础指标，我们就能让业务同学按照这些指标维度去圈品和投放，同时我们可以通过这些指标设置场景目标，将场景目标和线上的人货数据进行对比，能够快速得发现场景的投放和目标的差异，进行调整。
同时通过比对场景的 “来访人群” 和 “曝光商品” 的重叠度，监测场景细分的健康度，调整重叠度高的场景，从而达到我们精细化运营的目的。
- 场景上线后波动难以监测
场景投放之后难免会有数据波动，我们希望能够沉淀优秀的运营策略，发现场景的异常问题，同时希望能够为业务看数据这块做提效，所以我们做了场景组配置的功能。将同类型的场景，或者同业务的场景圈选一起，便于小二去对比看数据。
有了场景分组，就可以针运营同学比较关心的指标（例如 PV、UV、购买转化、跳失率）的周期变动输出可视化的报表。方便运营同学，查看他场景组中哪个场景的哪个指标在哪个时间段有波动，再结合他的运营策略，分析沉淀有效的运营方式。对于负向的变动（例如跳失率突然增，UV 突然降低），我们需要能够及时的通知相应的业务和开发去做调整。
- 场景的流量分配难
不同的场景效能不一样，投入的流量应该也需要做区分。相同的场景曝光量，为不同的场景带来的成交转化也不一样。我们就要把我们的流量给转化更多的场景。通过赛马的方式分配场景流量，能够在保证场景效果的情况下去促进业务同学的竞争。
基于上面的痛点的思考，我们做了场景定制化的 “度量” 分析。开发了场景的人货下钻，场景的心智报告，场景的周期波动报告，重叠度分析等功能。通过数据分析，来描述场景心智，检测场景的健康情况及异常告警功能，从而辅助我们的运营同学去有依据的调整场景，通过数据发现人肉难以发现的场景问题及机会。
功能展示
下面是我们的场景度量功能展示
1. 场景的人货下钻
【人货下钻模型】
基于电商导购场景的 “人货场” 三角效率模型，我们将商品和人群的指标进行清洗，可视化的 “将抽象化的场景心智” 进行 “数据化的描述”。
【商品模型及人群模型指标】
在商品模型上，我们有了商品价格带，商品趋势力，商品价格力等指标。
- 商品的价格带：通过算法模型的清洗，来分为高中低三档（不同的商品类目，高中低的价格带不同，例如配饰的 60 元已经是高价格带的商品了，但是在电器这个行业是数据低价格带）。
- 商品的趋势力：代表商品的热卖趋势（通过上下游的电商售卖信息，国家统计局、百度指数等社会指数，得出商品的预期分数）。
- 商品的价格力：代表了这个商品的价格优势（算法会进行全网数据进行同款比价，通过原价，成交价等多维度价格属性和商品的材质产地等属性得出商品的价格力分数）。
人群下钻上，我们有买家身份，买家等级，买家状态，买家偏好等指标。
- 买家身份：指的是否是淘卖人群，weishang人群，跨境人群这一类。
- 买家等级：则是根据用户在平台采购的量，与采购价格和采购订单量都会有关。
- 买家状态：买家是活跃的，沉睡的，还是流失的。
- 买家偏好：指的是买家偏好的类目是女装、配饰、百货、电器等等。
通过这些指标可以将场景十分清晰的进行描述，再结合业务的层层口径（多少人来了这个场景，浏览了多少的商品，商品的点击转化率，商品的购买转化率等）从每一个切面上去仔细的看场景的模型，进行场景分析优化。
【商品下钻】 【人群下钻】
但是要去查看场景心智和场景目标是否匹配还是需要一定的工作量，既然这些都是确定性的指标对比，那么我们就可以将这些进行产品化，通过让业务同学在组建搭建的时候去录入场景的心智，再与线上的数据进行比对，如果不匹配，我们就可以去做相应的调整。
2. 场景的心智报告
通过在搭建侧配置场景的核心人群和货品的指标来定义场景的画像，货品这边我们的指标是商品力、趋势力、价格力，价格带等与我们的下钻维度保持一致，同样人群我们也抽取了最重要的最能够描述场景心智的指标。
配置完场景的目标（心智）之后，通过线上采集的数据进行可视化的对比，就能比较明显的发现场景的货品结构及访问场景的人群结构的 gap，如果人群上有出入就去检查调整人群的投放策略和组件的智能文案、心智等。如果商品的出入比较大，检查我们场景圈的商品有没有问题，场景的推品策略又是如何的。
同时通过数据链路漏斗，比如上面这个例子，有多少人访问了这个场景，有多少人点击了商品，有多少人购买了商品，每一个口径上的货品结构是怎么样的，出现出入的地方具体又是哪一层，更精准的去定位到问题。
就比如上面这个商品分布情况的图（内部数据敏感，截取了设计稿上的图），我们设置了我们的场景目标，金冠商品占比 44.4%，线上的场景金冠商品 44.4%，说明了场景的目标和真实线上数据非常吻合（这种情况通常出现在设计稿偷懒的情况，而线上分析的数据来看或多或少，场景都会存在一些出入）得到场景的心智差异报告之后，就可以通知我们的运营同学去调整他们的货品结构。
3. 场景的重叠度报告
此外我们还开发了场景的人货重叠度的分析的功能，通过比对分析两个场景的来访人群的重叠度和商品曝光的重叠度，来更进一步的衡量场景的心智是否重叠，去发现同质化的场景，从而去调整人群或则是商品重叠度高的场景。
从上面这张图中，我们就可以看出，访问了某场景的人群有 33.2% 去了必采清单场景，这两个场景的人群重叠度就是 33.2%。类似的我们通过比对 A 场景曝光的商品有多少和 B 场景重叠（在 A 场景曝光的商品，又有多少在 B 场景曝光来）可以得出 AB 场景的商品重叠度。
4. 场景的业务波动报告
除了场景心智的监控外，场景上线之后我们往往会更关心业务数据的波动，通过可视化的数据折线图，我们能够去发现场景的业务波动，通过监测场景的业务数据的波动，去做沉淀和调整。场景的波动可以是正向的，也可以是负向的。设想下，如果有一个场景在某一天的 UV 突然降低或者跳失率飙升，那么这个场景肯定有问题，需要我们赶紧去查看下。反之，如果小二在这一天做了什么操作，让我们的场景效能有一个明显的提升，也能非常可视化的表现出来，进而沉淀下这些优秀的操作，去其他的场景上优化。
和集团通用的指标分析不同的是，我们做了场景组的功能，这样同一个小二运营的场景或者是同类型的导购场景就可以在一个周期中对比业务指标的波动。一方面便于运营同学查看自己场景的数据波动情况，一方面也可以激发运营同学的竞争意识。
5. 场景的异常告警
再通过把场景的异常波动推给我们的场景负责人（包括这个场景的开发和业务），让他们及时地去调整和修正异常。当然也不是所有的数据波动都发给我们的小二，我们的小二通过配置一些业务指标的阀值（例如 UV < 100 的情况或者是跳失率大于 80% 的情况），当数据异常超过指标的时候会在钉钉上推送告警。
6. 功能关系大图
好了，接下来我们再来回顾下我们个整体功能图，我们为场景的度量按照报告的维度一共做了：
- “ 人货下钻” 报告：通过场景的人群和商品的指标清洗，可视化描绘场景每个业务切面的模型
- 场景心智报告：通过录入目标和线上对比发现场景的目标和真实线上投放的数据差异
- 重叠度报告：通过访问场景的人货被曝光的货品的重叠度，更进一步发现场景的重叠问题
- 业务指标波动报告：监控场景的正向的和负向的波动，沉淀好的策略，优化和及时发现场景问题
当然这些功能离不开很多前置条件，需要通过持续数据采集，数据清洗加工，数据监控才能得到我们场景度量的输入。
系统架构
image.png
下面来看下我们的系统架构图，一共分为了采集数据、清洗数据、消费数据三部分。
业务方确定场景心智，经过场景的开发，场景投放上线之后，将用户的点击、收藏、购买的行为采集到我们的 ODPS（大数据计算服务） 离线表里，数据引擎每天按照提前设定的规则自动同步清洗 1688 的打点数据，为我们提供多维度实时数据查询能力。当需要使用到数据的时候，去动态地查询清洗过的数据。
从数据流看功能实现
怎么采集的（无埋点采集，有埋点采集），采集了什么，怎么分析的（整个分析过程）
在数据采集这块，集团内有两套通用的数据采集服务，也是大家熟知的 “无埋点采集” 和 “有埋点采集”。
- 无埋点采集：是通过提前在框架侧预置 SDK 的方式，在框架层监听通用的事件，当用户的行为促发了相应的事件就自动上报。例如
pageApper，pageDisapper，这两个事件就可以告诉我们页面是什么时候载入和离开的。 - 有埋点采集：是基于用户浏览日志没有办法满足的场景，需要定制采集的内容和促发的时机，是一种主动上报的采集方式。
此外，我们还有一个 SPM 超级位置模型的标准约定，SPM 全称超级位置模型系统，可实现统计站点、页面、以及区块的流量和统一的打点日志模块。
SPM 结构
SPM 为 a.b.c.d.logId，5 层编码结构组成 a 为站点 id，标识某一个站点或产品，例如：裹裹 App b 为页面 id，标识具体的一张页面，例如：裹裹中的首页 c 为模块 id，页面有多个模块组合而成，例如：裹裹首页中的 banner 区域 d 为位置 id，d 一般是模块中的链接，其所在的位置（序号），例如：banner 区域中的具体第几个 banner logId，这个是 SPM 自动生成的 id，我们不用去管
运行在客户端上的日志采集代码，如果发现页面上做了 SPM 相关埋点，除了会采集当前页面的 SPM 编码，还会监测页面上的点击。如果用户点击触发一次跳转，则会在跳转前修改目标页面地址的 URL，向其中追加上一个名为 SPM 的跟踪参数，来标识被点击的位置。
如此以来，打开一个页面时，只需要看到 URL 内的 spm 参数，就能倒查出这次页面浏览的来源是哪里.。这个参数的传递和解析机制，就是整个 SPM 模型和 A+ 产品的核心逻辑。
无埋点采集示例
我们来看个例子。我们假设两个页面命名为 A、B。那么这个场景的意思是，从 A 这个页面点击一个区块（Button）C，进入到页面 B。当点击区块 C 时，我们将 C 的 spm-url 传递到下一个页面中，即 B 页面。当 A 页面离开时，更新当前页面的 spm-cnt，这样 A 页面离开时，页面埋点的 args 参数就会记录 spm-cnt 的值。如果还有一个下游页面，通过解析 B 页面的 URL 我们也能继续找到 A 页面，实现了前推两步的点击位置追踪。
通过 SPM 将数据链路串联起来，存储用户的每一步点击行为，为我们的数据分析做了很大的提效。如果没有 SPM 的话，也能将用户的数据链路串起来，但是需要花费非常多的时间去做 URL 的匹配，在多 URL 和短链 URL 的时候，就需要去整理非常多的正则表达式集合，会特别心累。所以 SPM 这块如果有没有理解的同学，可以回头在仔细看下我们的 PPT 和文章。
有埋点采集示例
好了，再回来。刚刚说了 SPM 在 UT 中的运用。系统自动采集的页面浏览（PV：Page View）日志。这部分日志在页面被浏览器打开时自动发送, 一般不需要用户和前端开发干预。
其他自定义日志。其实在有埋点采集，也就是一些业务定制化的埋点采集的时候，这部分日志不会自动发出，而是由开发同学自己编写代码，在用户执行了某些交互（如点击、滑动、键盘输入）或者触发某些条件（如游戏通关播放过场动画，视频播放到某个特殊时点）时，通过调用黄金令箭日志接口主动上报日志（或直接发送日志到令箭日志服务器）。
我们还是举个简单例子：
小明同学上了一个活动营销页面，他这个时候需要去统计每个按钮上的点击量和点击人数。那他就需要先到我们的采集平台上去注册一个 key，用来标示这个业务，然后按照他的业务逻辑区分每个按钮的参数（每个按钮的位置是不一样的，SPM 的 D 位不一样，每个按钮的利益点也是不一样的），然后在页面上去监听用户的 click 事件，当用户点击按钮的时候，就可以执行上报操作了。
多端数据采集统一
讲到这边，基本大家都应该了解我们的数据上报的通用解决方案和工具，这样的采集能够让我们更准确、更高效、更稳定的采集和分析数据。
但是每个 BU 的业务不一样，甚至同一个 BU 里，不同小组的业务对数据的诉求也不一样。早前我们部门每个业务都是自行打点，这样就常常会导致数据的重复采集，通用的基础数据清洗过程不能被复用，也会有很多通用逻辑的冗余中间表产生。（比如商品曝光数据采集，有些采集的是 offerId，有些采集的是 itemId，不规范的采集导致了很多重复性的工作，打点问题排查困难）。
通过规范数据采集字段，在服务端配置收口打点参数配置，前端渲染层处理上报逻辑，让业务开发对这块透明，从接口中把需要埋的参数，注册到 DOM 节点上，高效统一的进行数据上报。
说完数据采集，我们来说下场景报告的数据清洗，通过采集上报，我们能获取最基础的打点数据（点击曝光、分享、自定义埋点），通过固定的规则进行清洗同步，通过沉淀和复用离线的通用指标清洗规则（例如 PV、UV、点击率、跳失率），进行动态关联查询，得到我们组件级、页面级相关的业务报表。
场景心智报告的实现
业务链路的数据报告，通常还需要一些更多的额外数据清洗，就比如我们的 “场景心智报告”。场景心智报告的实现是通过对比我们的目标场景和线上真实场景的画像差异，从而发现场景的问题和机会。
比如我们有一个摩登女装场景，录入目标的人群偏好女装占比 80%，商品趋势力分数 80～100 分占 80%。通过场景上线之后的数据清洗，发现访问场景（也就是 PV 这个指标）的人群偏好女装只占了 60%，曝光商品的趋势力分数在 80～100 分的占比 60%，就说明场景没有达到我们的目标。
通过对比每个业务漏斗（PV、UV、点击转化率、成交转化率）的心智差异，我们就能更加准确的发现场景的问题，从而去做一些相应的调整。上面讲的埋点采集，通常采集的是场景上线之后的一些用户行为，商品的画像指标和人群画像指标又是怎么来的呢，也是通过采集的数据来的吗？除了和用户行为相关外，我们的这些指标当然也依赖了我们其他平台的数据回流。有的时候看起来是一个简单的标签，他背后可能通过很复杂的逻辑清洗和结合算法打标才得到的。
举个例子，我们先来说说我们的商品指标，就比如 “商品模型” 这些指标（价格力、趋势力、价格带等），在最后的可视化报告里，我们可能看到是是一个 0 到 100 分，每个分数区间占百分之多少的的饼图，但是在商品表上打上这个商品力分数，需要经过一个比较复杂的处理。在我们的商品表里，每个商品都有他的商品力分数，业务小二会根据这些分数和场景的心智去圈品投放，并且设置商品结构目标，比如趋势力分在 60～80 这个区间的商品占 50%，80～100 的商品占 40%。当页面投放出去之后呢，我们会对这些数据进行回流，自动化的生产场景带趋势指标拆解的心智报告。
通过「1688 / 淘宝」下游什么商品卖的好？同类型的电商公司他们又是什么卖的好？小红书、快手、微博网红都在推荐什么？等资讯会带来下一波的卖货趋势（接下来一段时间天气变热带来女装连衣裙的销售增长，疫情的爆发口罩的趋势力相应的增加）。这些资讯能够为我们带来趋势的一个大致的预测方向，但是同类别的商品，甚至是看起来一致的商品，他们材质、价格、产地可能会不一样，他们的趋势力分数肯定也不一样。
所以我们（算法小哥哥）除了采集清洗全网的趋势信息外，还需要对 1688 站内的商品做结构化的拆解，从商品的文案、图片、视频、商品的优惠信息进行同款匹配，分析商品的趋势雷达，为商品打上趋势分。
从 ODPS 离线数据引擎中清洗我们需要的历史数据，我们可以得到我们 1688 的全量商品表，再结合 1688 及外部的资讯信息回流，用户行为等数据实时增量同步。
结合下游采集的电商销售数据，行业数据，算法模型的数据等实时的数据引擎清洗，给我们的商品打上相应的趋势分。相同的道理，通过对比全网的最低价（定价、成交价）的方式，在平台内根据商品的属性根据相应的算法规则的过滤为每个商品打上价格力分数。
在人群的画像指标上，我们积累了我们的买家库，通过用户在 1688 和淘宝的行为数据，ODPS 上做了定期清洗同步，获得买家的偏好类型（女装、童装、饰品），买家等级（采购量），买家身份（淘卖、weishang、跨境），是否活跃等信息，为用户打上相应的标签。
有了这些商品和人群的标签，我们能很好的描述我们的用户模型和商品模型，基于人货场的概念，我们能够用这些指标来清晰的定义我们的导购场景，于是通过在搭建侧根据这些指标录入场景的心智（也就是这些场景是卖什么商品的？场景给哪些人逛的）和场景上线之后的采集数据对比，我们就能得到我们的场景数据报告，从而去指导我们的运营同学，根据人货指标的出入去做相应的调整。
整体数据清洗大图
我们来继续看下我们的数据分析大图，刚刚讲的趋势力分析只是我们商品力模型力的一部分，通过将 1688 站内的商品力模型、场景数据、品效管理、商机助手等数据回流，结合用户行为数据去做定期增量清洗，得到我们场景度量的基础物料商品表，人群表和场景效能表相关数据，清洗出我们场景度量的相关可视化数据报表。
数据清洗的过程中有很多可以被复用，所以在中间过程中，我们还清洗了非常多的中间数据，通过沉淀下来可以被其他有复用这方面清洗规则的业务复用。例如我们在场景度量的数据分析中，其实是聚合了我们的场景列表数据，买家的浏览行为数据，买家订单数据，核心买家数据等等。
当然能够自动化的去生产场景报告是能够辅助我们业务去做运营的一种手段，但是在技术赋能业务的路上我们还是有很多路要走，通过数据化的指导运营，再将运营的经验乃至每一步试验性的干预策略数据化的沉淀下来，从中筛选出有效的策略，才能更好的服务我们的导购场景。
上面的几个功能是度量领域的场景自身是否健康，场景上线之后是否符合预期，场景的重叠度如何，场景的业务指标变化，场景业务指标异常波动等。在场景的监控度量上，除了业务监控外，还有体验监控、流量监控、算法策略监控等等，我们也将一步一步得去探索，去丰富场景的度量维度，更好的赋能业务。
总结&规划
1. 场景流量报告
当增长红利逐渐消失的时候，我们需要充分利用我们的流量。将相同类型场景的流量进行数据化，结合场景的转化效能，监控场景流量的投入产出比。
一方面能够把流量充分调控给我们转化好的场景，另一方面可以激发运营小二们的竞争意识，从而良性的促进场景的发展。
2. 场景的体验报告
除了业务指标的度量，场景的体验度量也一样重要。有的时候场景的秒开率提升会带来业务的大幅增长，在阿里内部，现在也有着比较多的体验度量工具，通过接入度量工具并且结合场景分组的功能，场景体验赛马让技术的同学更加重视体验，让我们的场景更好的服务业务。
3. 场景的策略健康
场景的推品策略的健康，“天下没有难做的生意”，除了让买家能够快速买到他心仪的商品外，我们也希望商家的商品能够得到充分的曝光，给优质的商品曝光机会，让他们有机会成长起来。
结合场景的心智，场景的圈品规则，以及场景的曝光商品数据，进行推品策略的度量。（如果有很多的商品进入了这个场景，但是没有被充分曝光，我们可以适当的质疑场景的推品策略）
4. 用户体验健康
用户调研，给用户发问卷的形式，以上的所有度量维度都是从场景的客观因素出发。我们也不能少了对场景参与最多的人的感受调研。
通过在场景投放问答机器人的方式，收集客户对场景的感官体验，为他们开发提出建议的通道，让我们的场景迭代，加上真实的客户感受，让场景的交互更具用户温度。
快速收尾
团队介绍**
最后能我也来打个广告把，再来展示下我们的团队风采，我们是阿里巴巴 CBU 前端团队。我们团队的 Slogan 是 “唯用户 无边界 重体验”，时刻保持着好奇心，热爱探索新事物，快乐工作，认真生活。我们团队支持业务的同时，我们快速孵化出了很多技术项目。
“以技术会友”，我们注重团队之间的交流，我们内部有一个方凳会的组织，每个月会定期举办内部分享，我们也时常会邀请集团的技术大牛来分享，也支持团队的成员走出去，思想的碰撞，往往能够激荡出更美妙有趣的事情。
当然，除了集团，我们和滨江的高新企业前端同学也保持着紧密的联系。去年10月，我们联合了（网易、微医、丁香园、海康、大华、税友）一起举办了缤纷沙龙，不知道你是否在现场。
有需要内推的同学，请一定要联系我哟～
本文使用 mdnice 排版
来源：oschina
链接：https://my.oschina.net/u/4409965/blog/4281046