导读：
首购用户和用户首购是互联网公司运营中最简单、最常遇到、也最容易混淆的两个概念。运营人员与BI经常在首购用户和用户首购上沟通不畅，信息不对称造成理解偏差，导致数据仓库模型或者BI仪表板一改再改。本文归纳总结了三种常见运营场景来解释首购用户与用户首购的区别，并讲述如何应用Quick BI制作满足三种场景的监控仪表板，希望能对运营和数据分析同行有所启发。
一、虚拟公司经营模式：
我们首先来虚拟一家O2O公司——X电商公司，这家公司主要经营水果、快餐和药品三个产品大类的线上下单线下送货上门服务，主要销售渠道是PC和移动端，其中移动端除了自主开发的APP之外还在手淘开个店。经营模式如下图：
组织架构和经营模式相一致，层级从高到低为总监—经理—主管，如下图：
二、 三种运营场景：
1. 场景一：首购用户的产品和渠道
从CEO和总监的视角出发，看公司整体的新用户来源，哪个产品大类贡献的多（产品总监关注），哪个销售渠道贡献的多（渠道总监关注）。这里“首购用户”的概念即，在X电商公司，每个用户的一生中只有一次首购，就是注册后第一次购买的产品和渠道。
2. 场景二：用户首购的产品大类
从水果经理的视角出发，扩展水果品类的用户量，水果的用户首购哪个产品来的最多？是苹果、香蕉还是西瓜？此处“用户首购”水果的概念即，用户第一次购买水果类产品，之前可能买过快餐或药品，但买水果是第一次。
3. 场景三：用户首购的渠道
从移动端经理的视角出发，拓展使用移动端购物的用户量，用户第一次在移动端购物，即“用户首购”移动端的概念，用户之前可能在PC端购买过产品，但在移动端购买是第一次。移动端经理会关注哪个渠道多——APP还是手淘店？哪个产品大类多——水果、快餐还是药品？
接下来，我们在数据仓库建一张表来满足以上三种场景的运营监控需求。
三、 数据仓库建模：
首先我们需要构造一张包含产品大类、销售端类型的订单明细表，如下图：
注：订单时间和支付时间用递增的不重复数字代替（懒得编╮(╯_╰)╭）
我们将此用户订单表按照以上三种场景的需求排序打标，如下图：
这样三种排序打好标之后，取rn_all_fst=1对应首购用户订单，rn_prod_fst=1对应用户首购某产品大类订单，rn_channel_fst=1对应用户首购某销售渠道订单。
四、 应用Quick BI制作仪表板：
1. 首购用户和用户首购的业务形式比较适合使用 树图
2. 看样例图的数据结构，由父节点、子节点、数据值三部分组成。其中同一值（如收红包）同时出现在父节点和子节点就可以构造出上下延展的效果
3. 构造场景一的数据和仪表板
根据树图的数据结构构造场景一仪表板所用表fst_user_ord_mod_sample_qbi_01
将此表导入数据集，然后将父节点parent_node和子节点child_node字段拖入“维度”，将用户数user_cnt拖入“度量”
样式如下图选择，注意高亮主路径可以突出显示占比最高的子节点
增加作用于数据集fst_user_ord_mod_sample_qbi_01的查询条件，将buy_type字段选入，选择单选枚举，这样可以避免人工输入导致的偏差。这个buy_type字段是设计来区分首购用户监控的两个层次，监控首购用户从什么产品来的，选择buy_type=‘首购用户-产品’；监控首购用户从什么渠道来的，及什么渠道下的什么产品来的，选择buy_type=’首购用户-渠道-产品’。
至此，适用于场景一的首购用户监控仪表板就做好了，让我们来看看效果。
选择“首购用户-产品”：
站在CEO和产品销售总监的角度，公司一共有224个用户，他们注册后的首购大部分来自快餐类，快餐类里最多的又是拉面，看来快餐经理和他的下属拉面主管
可以多领些奖金了。
选择“首购用户-渠道-产品”
站在CEO和渠道总监的角度，公司的224个首购用户中185个来自移动端，且其中手淘达到115个。看来移动端经理和其下属手淘主管要升职加薪了。
4. 构造场景二、三的数据和仪表板
根据树图的数据结构构造场景二、三仪表板所用表 fst_user_ord_mod_sample_qbi_02
仪表板构造思路同场景一，不再赘述，效果如下。
场景二：
选择 用户首购-产品大类 且 产品大类为水果
站在产品销售总监和水果经理的角度，假设水果是O2O市场新兴的品类，各大O2O公司都在抢夺水果市场，那么从上图可以看出，用户首购水果品类的来源主要在西瓜，苹果相差无几排第二，可进行针对性的用户调研分析用户首购水果主要源自西瓜的原因，从而实施针对性的营销策略。
快餐经理和药品经理的视角同上，筛选产品类型即可，如下图
场景三：
选择 用户首购-销售渠道，且销售渠道为 移动端
站在渠道总监和移动端经理的角度，假设目前O2O市场各公司都在转移动互联网，扩大移动端客群，那么从上图可看出，为X电商公司移动化转型贡献做大的移动端是手淘，用户首购移动端来源大部分是手淘（140人），且购买最多的品类是快餐（拉面最多），那么移动端经理应该与手淘经理沟通，令其思考如何与快餐经理及其拉面主管合作，扩大用户向移动端转移的战果。
五、 灵活调整
以上虚拟的经营模式比较简单，实际运营要复杂的多，但万变不离其宗，根据业务变化情况在用户订单表增加产品大类和销售端类型重新排序即可。以上案例的首购用户和用户首购的口径均为用户下单即可，订单状态已支付和未支付均包含，实际业务情况是某一天运营人员可能告知数据分析师，所有首购的口径改为“已支付”的，这时数据分析师将用户订单明细排序表加一个 where pay_status=‘已支付’即可。Quick BI在整个仪表板制作过程中可以灵活的应对变化，快速变更上线。猛戳以下链接可观看 Quick BI 教学视频
http://data.aliyun.com/product/bi
