本文笔者将根据客流轨迹分析产品的用户群定义、查询器组件的设计的实践经验来与大家分享：如何快速实现用户群定义以及查询器设计？
关键词
最近，笔者指导果果同学完成了一个客流轨迹分析产品的用户群定义、查询器组件的设计。在这个过程中，果果同学表显出了这样几个问题：
对于组件的套路缺少本质的认识（这是最关键的）；
组件逻辑不清晰，设计存在歧义；
依壶画瓢，组件流程不闭环，查询场景不能全覆盖；
粗枝大叶，字段未做明确，开发无从下手。
今天咱们就来说说“客群定义”与“筛选”的设计方法和规范！
应用范围
三大板块说清设计套路
（查询器组件设计框架）
什么是对象？
——作为一款用户分析产品，对象当然是人！只要不涉及到人的范围变小，都是对象定义的一部分。时间或是其它的条件，只是分析同一群人在不同时间的变化，并没有改变用户群的范围。
什么是分析项？
——就是要对已选择人群，进行何种分析。分析项与具体的功能模块紧密相关，例如漏斗分析，那么分析项就是不同的漏斗实例。
什么是筛选？
——对指定的用户群进行指定的分析项分析后，如果人群范围依然过大，则需要通过筛选，缩小用户群范围。
什么是细分？
——对指定的用户群进行指定的分析项分析后，如果粒度依然过高，则需要向下钻取。例如我们看到的是全年龄段的用户数趋势图，如果按年龄细分，将会看到不同年龄段的趋势图。
举一个鲜活的例子：
张三去医院体检，查了心电、验了血，不满服务态度，打了医生。
在这个语义中明确了：
对象：张三
检查项：心电、验身
行为：打医生
解析诸葛IO
接下来咱们就用这个套路来分析一下诸葛IO，看看他们是怎么实现的。
“优秀者抄袭、伟大者偷窃”
明确结构
先别着急去分析诸葛IO的查询场景、逻辑以及设计理念，在你没有深入的去了解组件的每一个细节前，得出的结论都不会太准确。对于这类数据较多，结构较复杂的组件先进行拆解，使用思维导图工具十分方便。
接下来，我们使用套路中的组件四要素来绘制每个要素的思维导图。
这个过程的要点是：
不要放过每一个细节，对每一个状态、字段、数据都需要分析其来源、用处（当然，明显同一类的选一个代表就可以，节省时间）；
将每一个要素内的逻辑整理成更为简洁清晰的逻辑表达式。
自定义用户群（对象）
在分析框架中，组件的第一要素就是分析对象，诸葛IO是一款用户行为分析产品，因此将对象实例化后就是“用户群”。
（诸葛IO自定义用户群 产品截图）
（诸葛IO 客群定义信息结构）
通过对前述结构的理解，我们可以用如下的表达式来进行归纳：
每一类表达式的详情如下：
用户定义设计的要点是：
可以将用户定义理解为用户画像，用一组画像信息来定义一个客群；
画像信息能够实现用户描述的全场景覆盖；
表达式的逻辑是闭环的，且利于开发的实现。
分析项
诸葛IO分析项较为全面，有如下的一些大项：
大项下会有实例可选择，例如指标分析举有：
分析项目来源于产品的需求，PM 需要根据自身产品的分析需求，建立分析项体系。
筛选
在多维的数据中，增加新的维度进行筛选，本质上是对数据的分片。诸葛IO通过长期的产品演进，已经具备丰富的、成体系的筛选条件。对于新产品，可以不用着急上全，逐步演进，PM的对产品的理解也需要在演进的过程中去提升。
（诸葛IO 筛选 产品截图）
（诸葛IO 筛选 功能信息结构）
从思维导图的折解中我们查看到可以统一归纳为如下表中的表达式：
在这里有一个很重要的细节，也是一个在我们自己工作时，细化方案的一个重要部分——事件的属性！
诸葛IO事件中定义了多种行为：
每一类行为也有着不同的属性：
这些定义好的行为及行为属性在自定义用户群中的事件中也会使用到。因此，在自身产品过程中，定义清晰的行为及属性是PRD中十分重要的组成部分，需要产品经理结合自身业务的需要，制订具有意义的用户行为。
筛选设计的要点是：
不同的分析项可能会存在不同的筛选条件，需要对每一类分析项进行单独的思考。
不同的行为，一般都会有不同的属性，需要为每一行为建立属性。
细分
细分的本质是对数据的钻取，这是数据分析领域的一个名词，前提是产品的数据具e有足够的厚度，而不止于太过于扁平。注意是厚数据，而不是宽数据，宽数据在数据分析领域中使用的方法是切片！
（诸葛IO查询器-细分 功能信息结构）
“细分”的功能信息结构与”筛选“相似，就不再详细的讲解。
在没有进行细分的时候，趋势图上只有一根曲线，但是当我们选择了按性别进行细分时，在趋势图会出现三根曲线——男性一根、女性一根、总量一根。
当我们掌握了这些事实后，我们要来寻找其中的逻辑关系
清晰的定义是团队协作的保障
在完成了信息的采集及归纳后，咱们要开始下定义了，明确的定义既有利于PM不断的思考问题，升华认识。也有利于团队内部的沟通，保证理解一致性。
这个过程的要点是：
保持用语的在全文一致性；
对每一个名词进行详细的定义及举例说明；
诸葛IO对于用户的理解是从三个维度：用户属性、用户行为序列、频次。
事件
用户在产品上的行为，简单的说就是点击在不同页面功能中不同的意义，例如，在登陆功能中的点击就是”登陆行为“，在支付页面，就是”付款“行为，但页面停留不是一种行为，因为用户实际上什么也没有做。
时长、频次
——属于用户的属性而非行为。
功能和数据中找到逻辑：
（诸葛IO 查询操作 流程图）
（逻辑图）
在诸葛IO的组件设计中，选择用户群对象作为流程的第一步，但在处理时并不是展开与其它的查询条件同时运算。而是将用户群中选择的条件进行运算得到用户群，再分析中间用户群在具体分析项中的表显。
同时，咱们还需要理解数据关系：
在查询器及自定义客群的设计中，本质上就三部分数据：用户属性、行为序列及属性、触发环境。
触发环境是与用户无关的数据，因此只会出现在查询器功能中，不会出现在自定义客群中。
用户属性、行为序列及属性会出现在自定义客群及查询器中。
在整个查询的过程中需要注意分析的对象只能有一个，如果在同一个分析功能中存在多个分析对象，则会存在歧意，无法清晰的理解行为等的作用对象。
理解参考品的设计理念
我们可以看到一些其它的互联网用户分析产品（如易观方舟）对于自定义客群也采用了“用户属性+事件+频次”的设计方式。我们可以这样来理解：对用户的描述不仅只是行为和属性，与用户密切相关并且对分析者十分关注的信息都可以，并且应当用于描述用户。
始终将”人“作为分析的对象；
用户的定义本质上就是用户的画像，因此不局限于属性+事件，可以加入更多与业务相关的数据进行描述；
减少误操作，提高心理预期，高耗时操作通过按钮触发。
查询器与用户群定义设计的总结
说说我们自己的实践过程吧！
查询器的设计的核心是：根据业务的需求构建全场景覆盖的条件表达式，以及构建没有歧义的运算逻辑。
根据咱们的实践经验，具体的设计要点有：
理清对象 |在设计的初期我们将客群与空间混为一谈，导致同时出现空间对象与客群对象；
运算逻辑要可行| 构建一个可行无歧义的表达式，否则程序猿会和你急；
确定对象的画像 |在设计的过程中，我们一段时间未能完全清晰的理解，从那些维度描述对象，盲目抄袭；
根据查询场景构建查询维度 |我们的产品既需要以空间为对象也需要以人为对象；
闭环的表达式 | 查询最终都是通过表达式落地，对于表达式及其属性、值的设计一定要是闭环的。
这些都是 PM 工作过程中常见的坑，需要PM在交付成果前反复的盘它。
对象定义的要点是：
从行业中去寻找共识 | 先别花太多的时间去思考，去看看行业里大家如何制订对象的画像；
找出差异进行订制 | 世间没有完全一样东西，我们需要理解自己分析对明与其它产品的差异，寻找适合自己的定义方法。
在初期咱们使用属性、事件行为进地客群的定义，在过程中，我们逐步理解到客群的定义本质就是客群的画像，通过画像来筛选出所需的客群。因此，我们开始将关心的顾客信息加入到画像中，形成了我们自己即有共性，又独特的对象定义体系。
我们是一款客流轨迹分析产品，就叫“CK”吧，产品含盖三个板块：看板、场分析、顾客洞察。
（功能需求示意表）
不同于互联网产品，“CK”是一款面向线下商业体的分析产品，面向的是实体，存在：“人”、“货”、“场”三个维度的分析需求。对于“货”的分析超过了我们现在的能力，因此“CK”即需要从“场”的角度出发（商场分析），也需要从“人”的角度出发（用户洞察）。
当我们心有了这个框架套路，一切就简单了
明确查询场景
建立明确的查询场景是设计查询器的起点。
明确的查询场景可以用来验证设计是否能够满足，但这只是事后验证，在事前指导设计上，查询场景的价值在于：通过归纳得到满足需求，系统中需要的查询条件。
(需要具备的查询项示例)
About 客群定义
在模板中我们给出了：属性、行为，做为用户群描述的两个维度，在参考品诸葛IO中，增加了频次这个维度。
对于线下商业体有一条准则：吸引顾客多来商场、增加在场内的停留时间，以达到增加消费的目标。试想：逛10分钟和逛两小时，谁更容易产生消费行为？
将这个准则翻译过来就是：到访频次、驻留时长，这是描述顾客的关键要素，因此，我们定义的顾客群包含四个维度：属性、行为、频次、时长。
About 对象
“CK“的查询器设计有一些差异，主要集中在对象上。
当进行商场分析时，分析的对象是”场“的要素：商场、楼层、店铺、POI、业态；
如果不进行区分，在”CK“产品中将会同时出现两个对象，顾客群对象、场内空间对象。
About项
两个板块都根据自身的需求，拥有不同的分析项。商场分析以空间分析为主，包含：动线分析、热力分布、路径分析等。
About筛选
在互联网产品中，筛选往往有触发环境、用户属性、事件属性等多维数据。出于对我们自身技术特性的考虑，无法获了到触发环境，因此我们仅从用户属性、事件属性上去设计筛选。
About 细分
当前我们的数据层级并不深，数据较为扁平，不需要再进地细分。因此未考虑此功能，待”CK“产品将来更上一层楼，数据层次更加丰富时再进行设计。
