编辑导语：可能每个人的日常工作中，都或多或少地会涉及到业务分析模块，那么在社会普遍对效率有所追求的情况下，我们在日常业务中，是否可以借用工具来实现业务分析价值的最大化？也许，亚马逊云科技推出的Amazon SageMaker Canvas就属于这类型工具之一。本文作者就对其进行了测评体验，一起来看一下吧。

一、事实是，我们都在做业务分析

无论你是否意识到，我们每天的工作实际上都包含了业务分析。

试着想象以下这些场景：

1. 移动游戏运营想提升付费用户比例，会通过分析用户使用行为，得出影响付费的因素，从而采取针对性的运营手段。
2. 超市老板进货时，会综合考虑以往销售情况、地段、季节等因素，分析出每件商品要备的库存量。
3. 房屋中介在管理客户时，会根据客户的个人情况、背景资料和意向信息分类跟进，提升成交量。

尽管上述场景的主人公都并非专业的业务分析师（business analyst），但他们知道怎样让自己做出更聪明的判断。

而这恰恰就是业务分析的本质：通过收集和处理业务数据，分析得出某种趋势、模式或根本原因，并根据这些洞察做出数据驱动的业务决策 [1]。

二、可是问题是……

尽管我们都或多或少在用自己的方式，通过“业务分析”来完成工作，但是问题也在一一浮现。

1. 期望更进一步

数据量大、影响因素多、缺乏专业的建模能力等等，都会使我们在实际分析业务时往往停留在表面，而错过了挖掘背后更深的洞见。

比如，在分析影响用户付费的因素时，我们的运营同学定位到多种相关的行为指标：

• 用户来源：来源于渠道A的用户付费比例更高；
• 日均活跃时长：活跃的用户付费比例更高；
• 日均互动数：互动多的用户付费比例更高；
• 是否参与激励活动：参与过的用户付费比例更高。

以上的结论虽能帮我们判断出哪些特性的用户更具有付费意愿，但想进一步知道：哪些指标影响更大，指标间是否会相互影响，能否在下次运营活动前就能预测出最终效果，往往还是无从下手。

2. 结论对么？能不能快速验证

或许凭借业务经验，我们能觉察出某一指标是决定用户付费的关键因素，或是能预估到下一个季度的销售情况。

但问题是：能否通过数据来快速验证我们的结论；或者是否有更专业的方法来论证我们的猜想。

3. 沟通的成本

此外，当我们期望将自己的洞察分享给团队其他伙伴，又开始思考要怎样有效地阐明自己的判断。

或是当我们的洞察可以提炼出一套能长期执行的决策模型时，要如何让数据科学家或算法工程师在此基础上进一步优化并部署发布。

三、更好的方式：工具助力分析

幸运的是，很多专业的服务团队也发现了以上这些问题，从不同角度为我们提供了解决方案。

1. 入门级全能选手：Excel

Excel绝对是人手一个的必备办公软件，它简单易用，也是很多原始数据的存储格式，方便加工处理。我们可以通过简单的函数处理、数据透视以及可视化图标等功能，快速地发掘数据中一些潜在的信息。适用于数据量不大，较简单的统计、分析和预测。

2. 专精可视化分析：Tableau、PowerBI

主打拖拽操作和全程可视化，帮助我们在数据准备（包括多表合并、数据清理等）和数据展现上实现自助，大大降低普通用户与数据交互的门槛。更适合团队内共享数据洞察。

3. 分析预测大师：Python、各大公司提供的云上AI服务、专业BI软件等

相较于前2类，这一类产品我们可能比较陌生，多是数据科学家在使用。

虽然它们在海量数据处理、统计预测、数据建模、数据挖掘等方面具有绝对的优势，但也正因为专业度过高，需要编写代码或机器学习等专业知识，一般人很难上手。

所以不会写代码、零经验就真的无法享受到机器学习带来的超强助攻么？

不慌，亚马逊云科技为我们带来了解决方案：

亚马逊云科技的机器学习服务下的SageMaker Canvas平台，主打0代码机器学习预测服务，让普通从业者也能方便地构建机器学习模型来获取洞察和进行预测。

接下来，就一起来体验下 Amazon SageMaker Canvas （下面简称Canvas）的实操效果吧。

四、Canvas初体验

体验官：未接触过机器学习的产品经理。

体验场景：这里设想了2个场景，分别看看Canvas在业务获取洞察和进行预测上的表现。

场景一：获取洞察

1）背景

公司引入外部供应商承接项目时，往往会先经过竞标流程。

竞标时会将同样的测试任务指派给多个供应商完成，依据返回的效果判断最终哪几个供应商中标。

2）目标

哪些是决定供应商是否中标的关键因素。

3）体验过程

① 数据导入

通过业务分析筛选出可能影响供应商中标的字段包括：

• task_id：任务编号（一个任务可以指派给多个供应商）
• total_num：任务的数据总量
• task_type：任务类型
• if_standard：是否为标准任务（标准任务才有报价单价）
• unit_price：供应商报价的单价
• tech_percent：技术分占比；技术分占比高表示更注重技术评分
• busi_percent：商务分占比；商务分占比高表示更注重价格便宜
• supplier_id：供应商编号
• bid_result：是否中标
• est_time：预计任务总工期
• deliver_time：本次交付的时间
• deliver_score：本次交付的技术评分

取的是最近3个月的数据，一共是一个csv文件，共12列*1068行。

来到Canvas平台，先按指引配置了支持本地上传能力后，直接将表拖拽上传就OK了。

整体的数据导入流程还是比较顺畅的。不过因为我最开始的原始数据是中文的，而Canvas暂时不支持中文字符的显示，所以这里又返回重新处理了一遍数据。

② 创建模型

切换到【Build】模块后，可以方便地在下方预览关联的数据集字段：包括字段的缺失比例、是否有和数据类型不匹配的值、有多少唯一值、平均数/众数等等。可以很好地帮助我们快速了解整体数据情况。

当选择好目标字段“bid_result”后，系统会根据所选目标列的类型自动推荐合适的模型“2 category prediction”；当然你也可以根据实际情况进行修改。目前看到Canvas给出的模型大类包括：分类预测、数值模型和时间序列预测。

可以在quick build之前先预览模型，快速获得模型预估准确率和各个字段的影响分值。

可以看出，影响供应商是否中标的最重要的前3个因素是supplier_id、deliver_score和deliver_time，而最不重要的2个因素是task_id和if_standard。

这样的结论基本符合实际情况：

• 一些供应商的交付能力比较高，所以更容易中标。
• 供应商得分和交付时间本身就是定标时的重点考核依据。
• 而任务编号以及是否属于标准任务属于任务本身的属性，应该影响比较小。

我们可以综合Canvas给出的字段影响分值以及业务实际情况，来筛选最终用于训练的字段：

比如我尝试取消勾选了impact值最小的task_id和if_standard，更新后发现模型预测准确性反而降低了。这也许是因为在实际情况，任务编号或是否属于标准任务可能会影响供应商的选择范围。

又取消勾选了那些在试标前未知的因素（包括est_time、deliver_score和deliver_time），现在最重要的前3个因素变成了供应商编号、报价单价和任务总数据量。

有一点疑惑的是，我发现系统会自动给出字段的数据类型且不支持修改。但是有部分字段的数据类型是不符合预期的：比如supplier_id被判断为了numeric类型，但该字段本身应该属于categorical，这可能是因为supplier_id的取值是数字的原因。

想了解错误的数据类型会不会对模型准确率造成影响，所以我又新建了一个模型，将supplier_id的取值修改为了N1、N2、N3…，这时data type成功变成了categorical。但预览后发现模型的预测准确率其实没有太大的变化。

确认没有影响后，使用quick build看下最终生成的模型效果。

③ 模型分析

Quick Build得到的模型准确率和Preview Model一致，但是可以看到各个字段更详细的影响度分布和模型评分。

a）supplier_id

supplier_id的影响度是用箱型图呈现的。可以看到供应商N1最易中标，供应商N2和N3相对容易中标，供应商N5和N8则相对不容易中标。这一洞察能引导我们进一步分析这些供应商的能力或资质有哪些差异，从而更早筛选出能力优的供应商。

b）unit_price

报价这一块没有得到很好的洞察，貌似整体看都是偏向中标的。

还是之前的那个疑问，unit_price的数据类型为什么会被系统自动定义为Categorical（分类）呢，是因为它的unique取值只有46个么？

c）total_num

total_num的影响度是用散点图呈现的。粗略看，好像是任务总数据量过大时不容易中标。

不过因为过多的点集中在1~200001这个区间，不容易看出当任务总数据量少时的影响。这里如果能支持调节横坐标区间的话，可能会更加方便。

最后来看一下模型的混淆矩阵（误差矩阵）：

总体来说，生成的模型在预测未中标时的准确率更高（可能是因为原始数据里Yes的比例更高吧）。

④ 模型预测

从上面的分析模块，可以大致获得以下2个洞察：

• 供应商N1相对容易中标，供应商N5和N8则相对不容易中标；
• 任务总数据量过大时不容易中标（相对影响较小）。

我们可以通过【Predict】这个模块快速验证一下。

预测方式包括2种：批量预测和单行预测。

a）单行预测

各个字段的默认值应该取的是平均数/众数。右侧显示当前输入值下的中标结果预测以及平均预测结果。

当修改supplier_id到N8后，可以看到当前场景中标结果预测是No，与猜测一致。

当修改total_num到1000000后，预测结果没变。但是新的预测值相对于平均预测结果来说，No的概率变高了一点。

可以看到，单行预测能方便地更改输入值来更新对应的预测结果，以及观察新的预测值相对于平均预测结果的变化情况。

b）批量预测

可以选择一个字段匹配的数据集来批量生成预测值以及对应的概率。因为这里我用的是已有数据，可以对比看到准确率还是挺高的，并且和洞察基本吻合。

场景二：预测

1）背景

超市老板进货时，会综合考虑以往销售情况、店铺位置、季节等因素，来预估未来各个商品的销售情况，从而提前准备合适的库存。

2）目标

预测未来7天各个店铺不同类别商品的销售量。

3）体验过程

① 数据导入

这里用的数据来源是kaggle上的store sales数据 [2]。

影响物品销售量的因素包括：

• 时间——季节或周期性波动
• 是否有促销活动
• 店铺位置
• 商品种类
• 历史销售情况
• 一些其他可能的影响：比如工资涨幅、地震、油价等。

由于Canvas的免费测试单元格只有100w，所以先线下对数据做了简化处理。

最终选择了3个表。

train.csv

• prod_id：商品编号（包含店铺信息和商品类别）
• sell_date：销售日期
• store_nbr：店铺编号
• prod_family：商品类别；共6个
• prod_sales：商品销售额
• onpromotion：打折幅度

一共是6列*32670行。

stores.csv

• store_nbr：店铺编号
• store_city：店铺所在城市；共6个
• store_type：店铺分类；共4类

一共是3列*15行。

holidays_events.csv

• sell_date：销售日期
• holiday_type：节假日类型；共2类

一共是2列*84行。

因为数据来源于3个不同的表，所以这次尝试了一下Canvas的join功能。

Join预览这里的统计只是显示前100个的，这里给体验造成了2个阻碍：

• 当我看到holiday_type的Distinct values为0时，一开始以为3个表join没有成功。
• 不能直观看到不同的join方式所形成的数据集差异。

字段名这里是可编辑框，但实际是不支持修改的。如果像Tableau那样支持修改的话，会更方便。

数据导入这里还有一个问题是后来发现的：到了生成模型的时候，遇到了一个这样的错误提示“Field state should not contains a reserved word”。

上网搜索后才发现预测模型对上传的数据集字段名有一些限制，所以又要返回第一步进行修改。这个如果能在一开始导入的时候做好提醒，或者出错后能直接修改字段名就好了。

最终join完成后，3张表变成了一个9列*33660行的大表，可以进入下一步了。

② 创建模型

这里的数据集字段预览出现了一个提示：onpromotion这个字段有“Missing Values”，提示说源数据集中的某些字段缺少未来值，可能会造成预测准确度偏低，建议更新数据集。

这个提示还是有点疑惑的：比如为什么只有onpromotion需要给出未来值，返回后更新数据集的入口在哪里。在查询了使用手册 [3]后也没有得到很好的说明，所以暂时没有做处理。

看了一下目标字段prod_sales有42%的值为0，总体分布图呈现右偏斜。

这里还发现了新功能“数据清洗”，可以快速为一些缺少值的数据设置默认值。

最后为时间序列预测模型配置好参数后，直接standard build（暂仅支持）就好了。

③ 模型分析

可能是因为没有处理missing value的问题，最后生成的模型准确率比较低。

时间序列预测模型的分析维度和二分类预测不太一致，它主要是选取了2个维度：

• 模型整体的WAPE准确度（加权绝对百分比误差 [4]）
• 各字段对预测值的影响度：onpromotion、holiday_type和store_city会提升预测值；而prod_family和store_type会降低预测值。

可以理解打折促销以及节假日能提升商品的销量；但是为何店铺所在地能提升销量，而商品类型和店铺类型会降低销量，就需要进一步分析了。

④ 模型预测

最后来看看模型预测的效果吧。

预测方式也包括2种：全部预测和单行预测。

a）单行预测

这里只需要选择待预测的字段值（某个店铺的某类商品）就可以自动生成相应的时间序列预测模型。

因为我之前配置的预测天数是7，这里展示了14天的数据（包括预测前7天）。

紫色的线为给出的预测值，还有对应的上下限。预测结果总体还是比较直观的，但是由于之前未处理missing数据的原因，预测准确度不高。

b）全部预测

点击后需要运行的时间比较久，而且这里没有限制多次预测，不知道会不会影响预测速度。

耐心等待后发现最后效果如下：P50应该是给出的预测结果，p10和p90是对应的上下限。

整体评价

整体来说，作为一个小白用户能全靠自己摸索走完整个模型创建、分析和预测的流程，实际体会一下机器学习在业务分析中的作用，还是很有成就感的。

当然出于对产品能不断优化完善的期望，这里从用户体验和产品功能2个角度给出了个人评价。

1）用户体验

① 加分项

1. 易用性强：点击式、可视化界面操作，小白用户也能快速上手。
2. 流程易学：能一步步引导用户完成 数据选择 – 创建模型 – 模型分析 – 模型预测 4个步骤。
3. 布局合理：页面设计（图标、提示文案、按钮等）十分清晰合理，能快速找到所需的信息和功能。

② 待提升项

a）提示不够及时

• 比如模型已经开始运行了，等待几分钟后却提示要新增配置forecast。
• 或者模型运行后告知字段和系统保留字段有冲突，要返回第一步修改数据。

b）容错性一般

比如误点了standard build或多次点击prediction后不支持取消，需要等待几小时。

c）有一定的学习成本

• 对于非专业数据分析人员，一些提示或说明比较迷惑。
• 普通用户可能不知道如何通过箱型图、散点图、混淆矩阵等进行分析获取洞察。

d）对中文的支持度不够好

• 平台目前全英文展示，部分提示或说明理解起来比较困难。
• 不支持带中文字符的源数据。
• 时间序列模型的节假日模式也不支持中国。

e）延迟感偏强

部分操作响应速度比较慢，也遇到过几次长时间loading的情况。

2）产品功能

① 超预期

a）数据导入

灵活度高：可支持多个数据表自由join。

b）创建模型

• 可视化程度高：用户可以方便地预览数据集字段的各项统计指标。
• 自动化程度高：可以根据用户所选的预测目标列准确推荐最合适的训练模型。
• 模型预览能力：能快速获得模型预估准确率和各个字段的影响分值。
• 支持Quick build和Standard build2种方式，满足不同场景的模型创建需求。

c）模型分析

• 可视化指标丰富：包括各个字段的影响度分布箱型图、散点图、模型整体的混淆矩阵等。
• 能方便地复制或下载数据图表，与他人共享。

d）模型预测

支持批量和单行2种方式，满足不同场景的预测需求。

② 待满足

a）数据导入

没有发现支持更新数据的入口。

b）创建模型

• 对已导入数据的处理能力较弱。
• 缺少不同模型对原数据要求的说明。
• 不支持设置目标预测对象为组合列。

c）模型分析

• 不能给出进一步优化预测准确率的建议。
• 支持用户自定义分析的配置较少。
• 一些专业的统计图表缺少像Tableau数据解释 [5] 类似的功能，帮助用户更好地发现洞察。

d）模型预测

• 预测失败时缺乏解释或指引，只能重试。
• 缺少对预测结果较为详细的说明，比如一些新增的字段含义是什么、为什么批量预测表最后有多行空值等。

五、总结

回归最开始的问题，Canvas真的能使普通从业者进行专业的业务分析，方便地构建机器学习模型来获取洞察和进行预测么？

从体验结果来看，能，但也不全能。

现阶段，Canvas的确能做到让普通用户也能0代码通过机器学习从已有数据分析生成可用的预测模型。但最终能否获取有价值的洞察，预测是否准确，仍会受很多因素的影响：比如输入数据的质量、用户自身的统计学知识和分析能力等等。

从普通业务人员到真正的业务分析师，工具只是我们强大的助手，正如Amazon SageMaker Canvas 并非智者本身而是其引路人。

引用

[1] https://www.oracle.com/cn/business-analytics/what-is-business-analytics/

[2] https://www.kaggle.com/competitions/store-sales-time-series-forecasting/data

[3] https://docs.aws.amazon.com/sagemaker/latest/dg/canvas-make-time-series-forecast.html

[4] https://aws.amazon.com/cn/blogs/china/measuring-forecast-model-accuracy-to-optimize-your-business-objectives-with-amazon-forecast/

[5] https://help.tableau.com/current/pro/desktop/zh-cn/explain_data_basics.htm

本文由 @咯咯咯 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Pexels，基于CC0协议。