本文 2021 年 2 月-2021 年 5 月首发于公众号【一个数据人的自留地】

概述

谈到 BI 系统，大家第一印象多半是数据指标看板、可视化、大屏。今天我们暂时抛开可视化、数据指标等等元素，谈一谈在一个 BI 看板或者 BI 报表系统中引入数据决策的模块（功能）。

设想一下，你的业务用户，经常拉着你，不再是要求看这个指标，或者新增某个趋势图，而是希望和你讨论业务数据背后的原因，他们试图与你讨论通过数据自动化的分层、计算、处理等方式，得到一些更加聚合的“内容”，这些“内容”可能不是数据本身，有可能是定性的，有些甚至看起来是无法通过数据直接就能获得的。

当你遇到这些情况的时候，可能你的 BI 需要引入数据决策模块了。

有人会问，现在业务系统本身就要会做很多决策支持，数据 BI 系统来做决策支持，有什么区别和优势吗？

我给大家举个例子：

通过监控业务流的时间周期进行告警，主要是对于那些应发生而未发生的业务操作/状态进行告警，一般是监控延迟。比如，制造生产流程，物料是否按时到达某个指定环节了，物流流程，包裹是否按时到达某个中转点了，打车流程，司机是否按时到达乘客上车点。

一般来说，业务系统传统的做法是这样：先定义好每个流程节点应该完成的最晚时间，达到这个最晚时间了，动作还未发生/状态还未改变就告警。

事实上，业务流程上约定的最晚时间，会考虑很多的因素，一般是部门之间、上下游之间妥协的结果。业务流程也会尽量去动态制定最晚时间，比如会综合考虑上一个操作已完成的时刻、考虑人员班次轮换等。

我们使用数据来做的话，可以更加适应实际情况，可以利用数据反馈出来的规律，将现有流程与同期或者同水平条件（相同业务环境）下完成时间点水平进行比较，确定基准时间（注意数据找的就不是最晚时间了），如果没到达这个时间点就进行报警。

这里我描述得比较简单，基准时间需要根据不同现实环境与历史水平之间的关系来得到，这可以通过数据分析、数据挖掘的方法来做。

现实情况之所以特别依靠人脑的决策，就是因为影响现实世界的因素有很多，因素越多，靠越刚性的办法去解决就越做不好。而数据去驱动决策、去辅助决策支持的好处是：利用数据挖掘发现各个因素之间的关系，可以考虑更多影响因素，可以通过数据去覆盖更广泛的情况。

我自己目前遇到以下 3 种数据决策的场景情况比较多：

• 风险告警

• 问题诊断

• 决策建议

风险告警

谈到风险，大家可能觉得金融场景用的多，但事实上，风险告警可以说是最接近数据的一种应用，只要有数据都可以用到这个场景。风险告警在 BI 上的典型例子就是指标波动告警。

当数据指标出现波动的时候，根据波动幅度大小，会有不同的通知方案，小波动，可能发个邮件通知到收件人，比较大幅度的波动，需要短信，更严重的需要短信+电话呼出。这种场景可以通过是规则来实现，产品经理定义好波动的幅度和对应的通知策略，系统计算波动指标，到达对应阈值范围，触发通知指令。

问题诊断

某些数据指标出现了波动，那么是什么原因造成的波动呢；订单生产的速度变慢了，是哪个环节造成的呢。这些都属于问题诊断。问题诊断是风险告警的下一步，需要先对整个流程上各个环节进行数据监控，能够发现异常（数据波动），问题诊断是回答：造成现状异常的环节在哪里发生，或者原因是什么。类似与数据分析里面的归因分析。

传统的做法，是将专家经验转化为一个个有层级的条件，通过查看数据符合哪些条件分支，最终来定位到异常环节或者原因，类比的话很像决策树的处理方法。

如果使用数据的方法，可以考虑将专家经验转化为知识图谱（注意这里就不是再使用策略了），知识图谱可以扩展专家经验，能够挖掘事物之间的联系并且可以进行推理，对于一些新出现的问题，在扩展性和覆盖面上会比专家经验要高。

举个例子：

数据库运维，如果使用专家经验策略的话，一般是根据固定的排错路径，依次查看 CPU、内存、IO 等各项指标，先看这里有没有问题，没有问题再看下一处。

如果使用知识图谱，则可以同时去计算多个排查路径中涉及到的指标，对排查路径进行优化和推荐，对于一些复杂的问题（有多项指标出问题了）或者新的问题，会得到一些专家也未必能够第一时间想到的排查路径，适应新会比较好。（但是知识图谱也是在专家经验基础上进行沉淀、转化的，知识图谱的质量决定了数据决策应用的效果，其核心在于对于所属领域内实体关系的理解）

决策建议

很多人都知道数据驱动决策，最直观的就是决策建议了。不过我们会发现能够对业务有效的建议十分少见的。这是因为业务的复杂性和数据的可得性决定的。但是我们也有应对办法——对于已经超出现有能力的情况，还是由业务专家和数据专家们去解决，系统只做系统能做到的事。

情况一：业务框架稳定，解决问题的策略已经十分成熟。

常见的场景：电子商务品类运营，对于各类反应商品销售、点击的情况，指标体系十分成熟，对于各类指标反应的情况，也有成熟的运营策略。这样的情况就十分适合进行系统化，通过数据+策略联动，实现决策建议。

情况二：业务框架稳定，有一定解决方法，但是出现的问题和解决方法不稳定、难以定性。

常见的场景：自动化生产车间在制造过程中的生产资源投入，比如机器人工作站的开启与关闭，这种情况下，虽然业务流程很明确，解决方法也有（缺少资源就增加资源），但是对问题的判断比较模糊（何时、何地、何种程度），对于出现问题之后的解决办法难以定性，比如增加资源，增加多少合适呢？

如果需要解决的业务场景能做到目标明确，就可以使用一些特定领域的建模方法（比如运筹优化），直接将问题转化为算法问题。

但是大部分情况下，都难以做到目标明确（无法收敛为一个目标函数），这是因为业务目标通常不是单一的。比如自动化车间生产过程中的资源调度问题，背后是效率和成本的平衡，这时候我们考虑用业务专家经验转化为策略，将场景拆分，对可以采取数据策略的办法进行决策建议的优先处理，我们很难计算出定量的决策建议，就先给定性的方向，建议用户应该增加资源了（暂时不建议具体数量）。这种情况下，决策建议的好坏，在于业务专家对数据及其背后代表的流程内核的深刻理解。

风险告警实例篇

什么是风险告警？

风险告警是一个我们在使用数据过程中会遇到的比较常见的场景。我们今天详细说说这类场景如何进行数据决策产品设计。

1、业务风险管理角度

从业务风险管理的角度上，一般将风险管理分为事前管理、事中管理、事后管理。

事前管理，目的是预防事情的发生；

事中管理，目的是及时介入，避免事情变得更糟糕；

事后管理，目的是缩小已发生的问题造成的影响面、降低影响程度。

从业务风险的角度，我们能够理解风险告警的目的。

2、产品角度

从产品角度上看在日常业务场景中，一般可以分为流程类风险、总量类风险。

流程类风险，是流程监控中常见的，比如事情应该做而没有做、延迟做了、出现了不应该出现的事情（流程节点）。

总量类风险，是水平监控、质量监控中常见的，比如今天应该完成多少，没有完成；平时正常水平多少，现在监控指标超过了正常水平相当比例。

从产品角度，我们能够区分出我们遇到需求的是哪一类问题。

知道了这两种分类，能够帮助我们在需求分析阶段，很快的锁定住我们的目标和大致的解决方案。

风险告警解决方案

1、举个例子：

一家车联网公司，最近想做一个用户疲劳驾驶的风险告警，业务方设想的场景是，如果超过了交通法规规定的时间，就通过车联网 APP 给用户发出告警。

从风险管理的角度看，这个需求属于是事后管理，因为业务希望是已经发生疲劳驾驶，发出提醒。

从产品角度看，这个需求属于总量类风险（水平监控），当数据积累到一定值，发出告警，这个一定值，是交通法规规定的，所以是一个固定值。

弄清楚这两点，我们的解决方案也大概有了个轮廓，采取策略方法，通过监控持续驾驶时长这个数据指标，当数据指标到达阈值时，触发告警。那么，我们产品方案的核心就是要弄清楚持续驾驶时长这个数据指标的计算逻辑，这个和车联网采集上来的数据是什么样高度相关，数据指标逻辑选取是另一个话题，我们这里不展开了。

我用这个例子向大家说明，一个数据相关的风险告警场景的需求分析大致是怎么做的。

表面上看，这个例子不太像 BI 系统干的活，更像是一个车联网的应用场景。

事实上，如果我们要在一个 BI 看板里面进行业务决策支持的应用，他要面对的需求场景和解决方案都会更复杂一些。

之前的文章里我们提过，BI 系统数据决策之所以是一个比较难的问题，是因为现实世界存在复杂性。复杂性，决定了，我们做数据赋能和业务决策相关的数据产品设计时，要避免『一刀切』的想法，避免『毕其功于一役』，避免设想自己的设计能够『一次成功』，这是一个不断调优的过程（如果是一名策略产品经理或者算法产品经理，应该能很好理解），调整好心态，我们开始吧。

2、数据来做风险告警的几种方案

用数据来做风险告警，大概有这么几种方案：

• 数据+策略/规则

• 数据+数据挖掘/机器学习

• 数据+知识图谱

本文从产品角度，给大家介绍需求场景如何与这些解决方案相结合。

3、案例

我们看一个数据安全审计的例子。

背景

现在，平台已经有了敏感字段管理，对于用户的导出权限一般来说不做限制，但是会去监控用户的导出操作与导出量行为，如果操作行为上看用户的导出超过了正常业务需要，就属于疑似异常导出，平台要能识别这种异常并且发出风险告警。

这是一个我们通常会遇到的需求描述。表面上看，需求很明确，但仔细一琢磨，就会发现这个描述有很多模糊的地方。

这里面最大的需要明确的点，就是如何定义疑似异常导出的行为，即风险识别。

那么根据不同层次的需求，我们的解决办法有相应的不同：

业务侧说，我们有很明确需要监控的重点表，根据我们之前的业务 case，当发生这些行为的时候（同一天内多次导出不同查询条件的同一个表的数据；同一天内导出总数据量超过 xxx 条数）就是疑似异常导出。我们只要先识别出这些行为推送给我们，给我们一些日志去判断是否真的是异常就可以。

明确需求

首先判断，这是一个事后风险管控+总量类风险（水平监控）的需求，因为导出行为已经发生了；

其次，我们判断数据决策的要求水平，业务方对告警的精度要求不高，他们已经有了明确的通过实际案例积累下来的规则，

数据要做的是什么呢？帮助业务方在进行风险识别的时候提升效率、也就是筛选一个大面积的数据集，然后推送给业务人员进一步识别。

设计解决方案

• 初步方案

需求到这个程度大致明确了，我们可以使用数据+策略的产品解决方案：

统计每个用户对监控的表的单日导出次数，和每个用户对监控的表的当日单出总量，两者有一项超出阈值（或者同时发生时），将用户信息及操作日志推送给指定的管理员用户。

• 迭代

对接人反馈，第一期上线后，确实解决了我们大海捞针的问题，但是现在公司规模扩大了，数据量和数据分析人员增加，现在推送给我们的疑似异常也多了很多，我们自己已经分析审核不过来了，你们能不能把风险比较高的给我们，低风险的那些我们就先给这些用户做一些告警提示，业务对接人还提出来一些想法，比如按照导出次数大小或者按照数据量大小去分这个风险高低，低风险可以等审核人员有空的时候进行抽查。

先判断，这是一个迭代需求，需求还是事后风险管控+水平监控。

然后我们分析，这些新增的内容，是对于告警的精度要求提升了，说白了，就是要降燥。

业务方给的解决方案是：通过对识别出的异常进行分级，不同的级别对应不同的处理办法。怎么判断我们能不能按照业务提出这个解决方案去做呢？

我们从产品发展的角度分析一下：

这个解决方案进行了风险分级处理，不同级别风险，告警方式不同。这个思路肯定没有问题。

分级需求细化

那么我们在再进一步看，如何分级，用什么原则去分级呢？我们发现业务提供的这个分级的策略比较刚性，如果用一个固定的数据指标值，可能会有两个问题：

1.导出数据量和次数与风险阈值的关系，是和表本身存储的内容和数据量有关，也许不同的表阈值是不同的（意味着有巨大的维护规则的工作）。

2. 随着业务规模发展，存储的数据量规模也会变化，即使同一个表，风险告警阈值很容易就会需要变更。

那么这个规则从扩展性来说，阈值不适合使用一个固定的值了，而是一个受到一些影响因素会发生变化的数。

经过一番需求分析，我们发现业务对接人提供的解决方案思路是 ok 的，但是细节还需要我们进一步去设计。那么这次产品迭代的目标是就是需要在数据监控的基础上，动态的去进行风险分级。

有些小伙伴会说，这个时候该算法工程师上啦！应该让算法同学出解决方案了。

我要说，这个时候其实产品的核心逻辑还没思考清楚，算法同学接到需求，只会丢给你一个白眼好嘛！

梳理核心逻辑

那么我们怎么去梳理这个核心逻辑呢？

我的答案是，我们要去思考这件事情的本质是什么，抽象出来。

我们要理解的事情是---风险告警推送给审核人员，他们到底在审核什么？

带着这个问题和业务人员交流，假如我们沟通后发现，审核要找出用户是不是真的出于不好的目的（盗取数据）在进行数据导出。那么，我们风险识别，就是去能够识别用户行为的恶意程度，而风险的分级，就是恶意程度的分级。

现在，需求转化成为了一个相对定量的，评估用户在平台进行数据导出或者查询等一系列行为的恶意程度。恶意程度，如何量化？可以从结果去倒推，用户操作得到的数据结果整合后，如果这些内容流出，对公司造成损失程度。

现在，在我们把恶意程度，和损失程度做了一个对等变换，如何看损失程度呢？我们又去和业务方调研。了解到泄露出去的数据，包含的内容以及内容的组合，如果会推算出一些我们不公开的数据，或者通过单元数据加工可得到一些财务数据，这种就属于损失比较高的了。

原来如此，不同损失程度其实和疑似泄露的数据集的特征有关系。这个数据集不一定是从有一个表导出的，也有可能是好几个表数据组合的。和数据量明细也许不一定高相关（不同特征的权重是不一样的）。

到了这一步，我们的核心逻辑就整理出一个大概轮廓了：找到某个用户一系列操作行为组合出的数据集的特征，与我们的目标值（损失程度较高的数据集）特征，他们的相似程度，相似度越高，风险越高。

明确详细方案

现在，产品思路理清楚了，我们可以去和算法同学讨论，使用什么样数据挖掘/机器学习的算法能够达成需求目标。当然，我们还会遇到算法同学提出的一些别的问题，需要共同讨论再进一步得出更详细的解决方案。

好了，这个例子对于需求分析说的比较详细，通过对需求不断抽丝剥茧，一步一步深入，最后得到一个解决方案。

说明：我用了一个虚拟的案例，或者说一个思想实验，与实际上数据安全审计的类似场景会有不同的地方。

问题诊断篇

什么是问题诊断

所谓问题诊断，就是找到在什么环节出现了问题，即定位问题，他有两层含义：

第一，有没有问题？

第二，问题出现在什么地方？

第一个问题好理解，第二个问题，大家的看法则会有差异，下面我将用例子来说明自己的理解，欢迎大家留言探讨。

举个例子：

在观测网站活跃用户数的过程中，发现本周的活跃用户数比上周的活跃用户数有了一个较大幅度的下降，通过分析数据后，发现原来是某 1 天的活跃用户数下降引起的，询问了 IT 部门后发现这一天网站有问题，某几个重要的页面有 2 个小时不能访问。

在这个案例中，『某 1 天的活跃用户数下降』就是问题诊断，而页面出现问题不能访问则是问题产生的原因。

问题诊断绝对不是简单看数据指标的表现，简单的数据增减幅度、趋势展示，是属于传统 BI 看板的范围，只能回答第一个问题——有没有问题，但是并不能回答哪里出了问题。

问题诊断的种类

问题诊断的场景一般可以分为两类：

第一类是数据统计量的异常问题诊断；

第二类是独立个体的异常问题诊断。

下面分别这对两种类型的问题诊断，结合具体事例来进一步讲解。

数据统计量的异常问题判断

如在文章开头提到的那个例子，数据统计量的问题诊断，是指问题会通过指标统计值反应出来，我们通过数据本身的增减幅度、趋势变化、逐层拆解，最后可以发现数据变化是在哪个环节发生。这种问题一般都是由于数据之外的原因产生的，这类问题诊断，可以帮助业务用户缩小问题的范围，大家感受一下，你和朋友讨论去哪吃饭，是在全城的 5 星餐馆中做出选择，和在公司附近 5 公里的餐馆中做出选择，哪一个更容易？

要实现与数据统计量相关的问题诊断，一个比较常见方法，就是选择出数据观察的各个维度，通过度量值在各个维度上的变化情况（与历史比较、与平均值比较等），找到变化的那个维度的值。

这种处理方法在 BI 系统里面最典型的案例就是 tableau 的 explain data 功能，这个功能会自动针对所选值提供由 AI 驱动的解释。

图 1 tableau 的 explain Data 功能

在 tableau 的 2020.2 new feature 网络研讨会上对 explain data 性能增强的介绍下让可以大概知道运行原理：

当你点击某个数据值进行 explain data 时，系统会自动对数据集的每一个维度、每一个度量都进行交叉计算，判断需要解释的数据值是高于还是低于预期（均值）。

以高于预期为例，explain data 会尝试做以下几类解释：

先去扫描所有的维度信息，看是否有显著的维度（这个维度的值普遍偏高）；

然后去考察记录数（数据条数），是否是由于数据记录数较高导致；

再次，考虑极端值的情况，是否是因为某个极端值造成了偏高。

但是这种处理方法，需要较大的计算资源，数据集较大或者维度偏多 explain data 会比较慢的问题。并且很有可能，大部分的计算都未必是必须的。

在新版的 explain data 中，对计算的维度范围进行了限制(不再对所有维度进行解析，有一些明显值过多的维度、包含了平均值的维度都会默认被忽略)。在数据集较大的情况下或者维度较多的情况，计算速度有了改进。

这就是通用 BI 的处理办法，面对多种多样的数据集，内容和业务都各异的情况下，剔除掉出那些不太可能导致异常，或者值本身并不能定位问题的情况。

如果你在做一些垂直领域的 BI，引入业务理解会是更好的办法，通过业务逻辑，将你的维度排上优先级，关联下钻策略，避免从最小维度开始遍历，都是不错的办法。

还是用文章本篇开头的案例，本周的活跃用户数比上周的活跃用户数有了一个较大幅度的下降的问题定位：通过两种类型维度的切分，第一种：时间维度下钻，计算下一层维度上（在这个案例中，是天）的活跃用户数的变化；第二种，计算对重要维度的度量值的变化，在这个案例中，与活跃用户数相关的重要维度可能是：用户注册渠道、用户访问页面等。

在这个案例中，通过第一种维度切分，发现原来是某 1 天的活跃用户数下降引起的。经验上，一般来说，会优先进行第一种维度计算，再进行第二种。

独立个体的异常问题判断

这种异常的特点是，并不一定能通过数据统计值的宏观变化来发现，这有 2 个原因：

第一，这种异常的表现大部分并不会影响到整体数据，从整体上看数量占比上很少；

第二，这种异常是非数据的，是从流程上定义的异常（SOP 规范之外的）。

不管是第一种还是第二种原因的异常问题，如果一旦发生了，影响会比较大，我们应该及时定位到。

这种独立个体的问题，一般在智能制造（智慧工厂）的场景见到的比较多，比如某机器宕机了，影响到了生产线；机器上某个关键部件磨损了，造成产品的良品率下降；日常业务也会有这种场景，比如入库环节的延迟造成了后续流程整体延后；在公司内部公共空间分享的文档明文密码增加了安全风险。

这类问题诊断的解决方案挺多，我们介绍下在日常业务场景中两种比较常见的方案。

第一，规则策略。

如果是由于流程上定义的异常，可以通过抽象出非正常的数据表现，形成规则集，用策略的方法识别出问题。比如，在公司内部公共空间分享的文档明文密码识别，可以通过常见的密码出现场景，整理成规则集合，扫描所有文档内容与这个规则集合进行匹配。

举例：一般密码出现都会以”密码”/“pw”一串英文数字字符的一形式，这个就是一条规则，列出多个规则形成规则集合。

这种方案相对比较简单，特别适合产品 0 到 1 阶段。

第二，知识图谱。

知识图谱的方案适合流程分支比较多、环节与环节之间的影响关系复杂的情况（这种情况也可以用规则策略，但规则会特别多，效果未必好）。

比如，最近我们常用的健康码，背后识别机制，就可以通过知识图谱方式来做。

用户申请健康码时，会授权 app 调取你得个人信息（包括手机号、社交账号、出行信息、定位信息等），通过大数据挖掘可以构造出一个『人-时间-地理位置』的关系，用户数量多了，这个关系交织在一起就成了一张巨大的网络。不管是人还是地理位置，某个属性发生了更新（异常）后，产生的影响会在图谱中蔓延。

再举一个例子：

大数据平台的各类表生产任务有很多上下游依赖，当其中有一个任务故障或者变更时，可能会对众多下游任务产生影响，一般来说，生产者最多会通知自己的下游任务，而很难去主动去通知下游的下游，更别说在庞大的数据集市中，还有更多层次的引用和依赖了。

我们把各个数据开发任务之间的关系制作出【数据表-数据字段】的元数据知识图谱，通过元数据之间的图谱关系，这样可以很快定位到受影响的表及其任务，如果多个下游任务出现异常了，也可以通过知识图谱找到影响自己的上游。

补充说明：关于智能制造（智慧工厂）场景下的问题诊断，方案会更具备垂直领域的特点，也会比日常运营中遇到的场景更复杂一些。有机会再继续探讨。

决策建议篇

什么是决策建议？

有决策建议的 BI 系统常常被冠以 “决策支持系统” 的光环。决策建议也是让业务方能够最直接感知数据驱动的功能。

决策建议，是能够告诉用户【在何种情况下，应该如何做】。

我们谈了风险告警、问题诊断，现在通过一个例子看看他们和决策建议产品形态的区别：

• 风险告警：全站活跃用户数比昨日降低 10%；

• 问题诊断：今日全站活跃用户数比昨日降低 10%，可能原因：10 点-11 点 APP 活跃用户数比昨日降低 50%（减少 10000 人）；

• 决策建议：今日活跃用户数比昨日降低 10%，可能原因：今日 10 点- 11 点 APP 注册用户数比昨日降低 50%（减少 10000 人），建议持续关注未来 48 小时内 APP 每小时注册用户数趋势和分布，点击订阅此数据。

决策建议的产品设计思路

决策建议可以有多种实现路径：

• 模型驱动：以算法模型为核心，常见的场景是，用户输入参数值或一些数据，来得到预测结果或者仿真模拟结果；

• 知识驱动：也可以叫做经验驱动，将专家领域知识（方法论）沉淀到系统里；

• 数据驱动：通过对数据的挖掘分析（通常是时间序列数据）。

不管用什么实现路径，产品设计核心是对现状、目标、执行措施三者关系的本质理解，将模型、知识（业务方法论）、数据转化为建议。

这里先不谈需求调研和确认需求范围这些工作，重点介绍当确定需求后，输出产品方案的方法。

决策建议的解决方案思路遵从策略或者算法的产品设计原则，即产品经理要明确：输入、输出、计算逻辑。

• 输入：触发条件

• 计算逻辑：策略或者算法要做些什么

• 输出：具体决策建议

如果你没有做过这方面的需求，可以按照这个套路去拆解你需求内的元素。

第一步，确定输出：把决策建议进行分类

一般来说，决策建议可以划分为以下几种类型：

1、建议做线上操作——设置阈值、操作功能等，需要提供建议值、建议条件、具体功能，比如：新零售场景，发现店铺会员进店率降低了 50%，建议增加会员触达，点击设置会员运营策略；

2、建议做数据分析——观察数据分布、数据趋势等，需要提供具体观察对象的内容/指标或者指向具体的数据分析功能，比如：电商场景下，发现件单价（成交订单中平均每件商品的价格）近 10 天内降低了 50%，建议关注高价商品的供给与销售，查看定价合理性分析。

3、建议做线下操作——提供解决方案方向，需要提供定性的建议或者知识文档，比如：物流场景，发现目前分拣中心包裹数量是历史峰值的 80%，建议增加分拣格口。

第二步，确认输入：将触发条件转化为数据需求

触发条件有这么几类：

1、阈值触发：数据指标达到某个指定的数值，比如：店铺会员进店率阈值，低于这个阈值会触发计算决策建议；

2、事件触发：当出现某个状态时触发，比如：当包裹派送状态为分配快递员，且客户的另一个包裹将在 1 小时内到站，触发提示快递员是否将已分配包裹标记为等到齐包裹后一起配送；

3、时间触发：指定时间时触发，或者达到一定的时间周期时触发，比如：每天早上 9 点，提供建议巡检设备清单。

第三步，计算逻辑：确定计算的精度和方式

我们需要什么样的结果，决定了我们采取什么样的逻辑。

这里不涉及到算法模型和策略的具体设计方法，产品经理需要大致确认计算逻辑的大方向：用算法还是用简单的规则集？

可以按建议内容分为 2 类：

1、定量建议，需要给出具体的数字或者数据清单，比如增加 10% 库存，巡检设备的具体设备编号；

定量建议一般考虑采取算法模型的方式，产品经理要重点整理清楚算法的输入输出和逻辑，整理好算法需求，强调设定合理的评价方式和评价指标，对算法调优可以提供一个明确的目标值。这个过程中，和算法工程师的反复沟通比较重要。

2、定性建议，需要给出具体的指向目的（文档、文字说明、功能等），比如查看定价合理性分析、建议关注粉丝新增率、建议把系统切换成节能模式。

定性建议一般考虑给出建议的规则集（策略），规则策略可以由产品经理输出，设计要点是，力求对业务场景状态进行全面分类，让规则可以尽可能多覆盖较多的场景。这个过程中，和业务方反复沟通比较重要。

小结

在数据产品目标主要是数据可视化、业务模型建设的情况下，决策建议确实是大多数据产品经理比较少接触到的业务场景，但随着数据对业务越来越重要，要求数据能够发挥更大价值，产品经理应该多思考如何能够提供更加智能化产品给用户。

写在最后

我们常说，解决方案本身其实是术，产品 PRD 里面写的是策略规则、模型需求，其实多做几个 case 积累一些经验就能够熟练，但是对于产品经理的个人能力来说，我们要锤炼的，是一种你去解决一个陌生问题的方法论，当接到需求时，能够快速拆解要点，快速判断出解决方案设计中要解决的核心问题是什么。