交易数据是一个公司最核心的数据，领导层会十分关注，一线的运营的kpi也是围绕交易额展开。领导层和一线的运营还是有些不同，公司领导层关注的是大盘，是不会看一些明细数据，而运营需要大量的明细数据来分析数据上升或者下降的原因。
交易分析设计原则
交易数据是一个公司最核心的数据，领导层会十分关注，一线的运营的kpi也是围绕交易额展开。领导层和一线的运营还是有些不同，公司领导层关注的是大盘，是不会看一些明细数据，而运营需要大量的明细数据来分析数据上升或者下降的原因。
所以给领导层看的功能都是计算好的看板，给运营看的数据的是可以各种维度拆解的数据，所以交易分析模块针对领导层和运营要分开设计。
给领导层看的交易分析数据我们先看下领导层关注的指标有哪些。需要对公司的领导层做一个调研，ceo的视角和每条业务线老大的视角还是有些不同。
针对领导层的交易指标还是要围绕着公司的全年计划来定义，作为高层他们是公司全局的视野，需要一眼能看到公司全年的交易额、收入、每日的交易额、每日的收入。其次就是公司总用户数，每日新增用户数。还有就是每条产品线都有交易额、收入的kpi，可以针对总的交易额做一个拆解，每条线的交易额、收入、完成率。这些指标的口径要向公司高层确定好，然后邮件同步确认，因为交易的数据是每条业务线很敏感的数据，口径必须一致。
1. 交易指标的口径我们也约了公司的几个领导层共同确定了一下，基本确定领导层关注的数据指标，主要分为三块：交易额、收入、用户数。
交易额没什么歧义，口径比较清晰，就是按下单金额（用户看到的包含优惠的原价）、下单时间来统计。为了防止刷单，我们又加了一个规则，所有未支付、已取消的单不算进交易额，这个也和领导层、各个产品线的负责人做的一个进一步的确认。
公司总用户数是以手机号为唯一ID，业务中台总体中心有多少手机号，公司就有多少用户数，这个十分明确。各个产品线的用户数就有一些小问题，因为我们的用户都在用户中心，用户只有一个平台标识，注册了产品线A的用户平台标识就是产品线A，不可能是产品线B。所以我们和产品线的运营同事定了一个规则，比如产品线A的用户的定义是，平台标识为产品线A或者注册了产品线A又登陆产品线B的用户。
关于收入这个指标，数据中台统一取订单中的佣金来计算，这就要求各个业务线都要接入中台的交易中心，提交订单时，已经把佣金算好记录到订单中。和业务中台的产品经理沟通后，除了某些产品线会有一些线下订单，这些是没有直接进入业务中台的，他们的运营会每隔一段时间补录进入系统，这样会会导致交易数据的显示没那么及时，其他产品线交易模块都已经接入业务中台。这样看来问题不大。
2. 技术选型接下来还有一个问题是这些指标的计算是到底采用离线计算还是实时计算，目前公司产品线的数据量还是比较大。我拉上技术评估了一下需求，因为数据比较重要而且是领导层看，如果做成离线计算体验很不好，今天只能看到昨天的交易情况，领导想了解今天的交易情况我们还得找我们处理，为了解决后顾之忧，我们决定采用实时计算，每5秒算出整个公司的交易额。
这些指标怎么展示给领导层呢？
我们决定采用3个渠道：
第一是移动端需要做一版，让高层能够随时随地通过手机查看这些关键指标。
第二是关键的指标如完成率要每天推给各个业务线的负责人及公司CEO，督促业务部门完成业务目标。
第三是要做大屏，一方面大屏的展示会更加清晰全面，让领导层到了公司就能一眼看到公司的健康状态，另外一方面也是对外展示公司实力的一种手段。
3. 移动端设计先说移动端，为了降低开发成本，和前端开发工程师啊沟通了一下，让他研究一下微信小程序，最终我们选择小程序内嵌H5的形式，这样前端只用前端开发工程师开发代码，而且维护起来比较方便，只用修改H5的代码，部署更新就好。
功能层面统计维度是按年的，高层那几个人登陆后可一眼看到公司最核心的那几个指标。我们采用的是实时计算的技术，每五秒能计算并汇总公司各个产品线的交易额和收入指标。数据会自动刷新，区别于传统的离线计算，只能看到昨天的数据。这些关键性数据，实时性越高，体验就越好。