php神策数据统计,php 统计

神策数据是用python写的吗

先对我们团队做个简单的介绍：团队核心成员均来自百度大数据部，从零构建了百度的日志分析大数据处理平台，有多年的大数据处理经验，以往的技术也基本构建于开源社区之上。目前，我们主要针对互联网企业提供大数据分析产品和完整解决方案，以及针对传统企业提供大数据相关咨询和完整解决方案。目前，针对互联网创业公司推出了深度数据分析产品Sensors Analytics（神策分析），支持私有部署、任意维度的交叉分析，并帮助客户搭建数据仓库基础，客户包括爱鲜蜂、多盟、AcFun、快快鱼、PP租车、51offer等。

对于 Sensors Analytics （神策分析）这个产品，主要用到了一些主流的开源社区技术，例如Hadoop/Spark/Kafka/MySQL/Redis/jQuery/Impala等，并在其中部分组件上进行了源码级的修改，当然，我们自己也开发了一些核心的业务组件。

整个 Sensors Analytics （神策分析）的技术体系，或者说技术点，可以从如下几个层面进行介绍：

数据采集：我们一直认为，采集的数据的质量是整个数据平台构建以及后续一系列数据应用的大的前提，因此，与传统的百度统计、友盟等统计工具不同，我们坚持私有化部署与全端采集，提供了PHP、python、JAVA、JavaScript、iOS和安卓等多种语言的数据采集SDK，以及 LogAgent 和批量工具等多样化的导入工具供使用者使用。不仅能够采集客户端数据，也能采集后续的服务端日志和业务数据。出于数据完整性、数据安全性、数据时效性等多个角度的考虑，更推荐使用者采集后端数据，如服务端的日志、业务数据库的数据等。同时，也按照我们对于用户行为数据的理解，对于使用者应该采集哪些数据、应该关注哪些字段，都提供了一套产品化的解决方案。

数据传输：Sensors Analytics 提供秒级的时效性保证，也即一条新传入的数据，一般几秒后就会体现在前端的查询结果中，并且这条数据中新增加的字段，也会几秒后就在前端的筛选和分组选择中体现出来，因此，如何在数据不重不漏的基础上保证数据流的时效性，也是 Sensors Analytics的一个技术难点。

数据建模：正如 Sensors Analytics的文档（数据模型 | Sensors Analytics 使用手册）上提到的那样，为了保证产品在不同行业的适应性，团队根据以往在用户行为数据方面的多年经验，抽象出了 Profile 和 Event 两个数据实体，分别描述“用户”本身的长期不变的属性，以及“用户”在某时某刻以某种形式做了某件事情。从我们目前十几个客户的经验来看，这个数据模型的抽象还是能够满足绝大部分产品对用户数据分析的需求的。

数据存储：在产品层面，我们 给使用者提供了最细力度数据上的完整的多维分析（OLAP）、漏斗、留存、回访等较为高阶的实时查询能力，并且支持 Event 数据和 Profile 数据的 join 分析，因此，为了保证查询的速度，在数据存储上，如何最好地利用列存储、分布式存储、压缩/编码等方式，加快查询速度，减少存储空间等，也是一个很大的技术挑战。

数据计算：一方面，为了保证查询的速度，后台会有一些例行的数据的预处理计算以及后续会逐步推出的数据预测计算，另一方面， Sensors Analytics 也将所有的存储和计算资源开放给了使用者，因此，计算的调度、管理等方面，也是我们一个必须要考虑的技术点。

数据可视化：作为一个数据分析产品，我们希望能够提供“自驱式”的数据分析体验，让使用者能够快速地验证、尝试自己对数据的各种猜测和假设。因此，除了计算和查询的速度必须尽可能得块以外，如何保证使用上的流畅，以及展现查询结果和数据概览时最大程度地让使用者“一眼”就能够从图表中“看到”数据的含义和价值，是一个非常大的挑战，因此，数据可视化也是我们技术攻关的重点。

权限管理：作为一个企业产品，必须能够适应企业中不同角色的使用者的使用需求，例如：有些角色，如管理员，具有完整的数据察看能力，并且可以分配其它角色的权限；有些角色，如数据分析师，有完整的数据察看和分析能力，但是并不能修改其他人的权限；有些角色，如地推经理，则只能察看分配给自己的数据概览的数据。为了满足这方面的需求，权限管理，也是我们一个重要的技术点。

数据API：从 产品 的定位可以看出，我们是将使用者的一切数据开放给使用者的，这些数据，包括使用者接入的数据，也包括经过 平台分析后的结果，因此，如何设计一套友好的数据API，与使用者的业务系统对接，让使用者方便地能够基于这些数据进行后续的数据挖掘和机器学习计算，也是对我们的一个技术挑战。

以上是我对这个问题的答复，再次感谢对我们产品和团队的关注，如果想有进一步的了解，欢迎和我们进一步联系。

相关问答

Q1: 做数据统计诸葛io、神策、growingio、C4J这些有什么区别？怎么选？

神策和C4J是主打私有化部署的，growingio这些多是saas产品，C4J成本低，性价比较高，应该几千块就可以搞定，部门就可以决策，不需要层层上报审批，其他的功能方面都差不多的

Q2: 神策数据-用户行为分析

行为分析三步骤：

1）. 提出业务问题

2）. 定位问题的分析对象，具体是哪几个行为

3）. 对行为进行统计和分析

其中2到3 涉及到数据的采集，后期逐步学习

what：以字段的方式记录用户所做的事件的具体内容。不同的事件需要记录的信息不同，下面给出一些典型的例子：

对于一个“购买”类型的事件，则可能需要记录的字段有：商品名称、商品类型、购买数量、购买金额、 付款方式等；

对于一个“搜索”类型的事件，则可能需要记录的字段有：搜索关键词、搜索类型等；

对于一个“点击”类型的事件，则可能需要记录的字段有：点击 URL、点击 title、点击位置等；

对于一个“用户注册”类型的事件，则可能需要记录的字段有：注册渠道、注册邀请码等；

对于一个“用户投诉”类型的事件，则可能需要记录的字段有：投诉内容、投诉对象、投诉渠道、投诉方式等；

对于一个“申请退货”类型的事件，则可能需要记录的字段有：退货金额、退货原因、退货方式等。

描述事件的任意一个字段，都是一个事件属性。应该采集哪些事件，以及每个事件采集哪些事件属性，完全取决于产品形态以及分析需求。

后续章节将针对”神策如何采集用户行为“进行解答。

Q3: 神策大数据用户行为分析-1-入门知识

神策大数据用户行为分析入门，主要涉及的知识点：

神策分析是针对 企业级客户 推出的 深度用户行为分析产品 ，有以下特点：

产品角色作为产品规划者，重点关注产品

数据驱动产品优化

运营角色重点关注

渠道角色重点关注

技术角色重点关注

电商用户通常会经历以下 核心行为流程 ：

产品核心流程可描述为

查看新客总数，同时按照日期、渠道等维度拆分下钻

查看各渠道新客的核心流程总转化率及各步骤间的转化率，寻找总转化率提升空间

神策支持查看特定用户群的历史行为序列，找到提交订单行为，对此之后的行为进行人工标注，以推测后续未进行支付环节的原因

解各渠道来源用户的活跃程度，以及目标行为——支付订单行为发生的频率

针对特定人群实现精准营销，支持将特定用户设备 List 同步到极光/小米，向流失用户进行 App 内的精准推送，以期重新激活挽回流失。

神策支持将分析结果添加到概览，使业务分析人员无需配置快速获得所关注的指标现状

神策分析中的所有数据均来自于客户的自有数据接入 。

神策分析主要支持采集客户的自有数据有三类，分别是 前端操作、后端日志及业务数据(包括历史数据) ，接入的方式主要是有3种：

日常工作中，我们遇到的实际问题：

为了回答以上问题，需要对产品上的各种行为进行分析和统计。

对上述的行为进行统计，得到的如下指标：

神策分析使用事件模型来描述（Event 模型）用户行为，描述用户行为的关键要素： 是谁、什么时间、什么地点、以什么方式、干了什么

主要是涉及到两个核心事件：

一个完成的事件包含几个关键要素：

每个 User 实体对应一个真实的用户

每个用户有各种属性，常见的属性例如： 年龄、性别 ，和业务相关的属性则可能有： 会员等级、当前积分、好友数 等。这些描述用户的字段，就是用户属性。

简单来说，在用户 未登录 的情况下，神策会 选取设备 ID 作为唯一标识

登录状态 下选取 登录 ID 或者 userid ，一个用户既有设备ID（亦称作“匿名ID”）又有登录ID

通过 用户关联 将同一个用户的设备ID 和登录 ID 关联到一起，这样不管用户是匿名和登录的状态发生的行为，我们都能准确识别到是同一个用户。

神策分析使用 神策 ID (即 events 表里的 user_id 和 users 表里的 id )来对每个产品的用户进行唯一的标识。

神策 ID 是基于 distinct_id 按照一定规则生成的，两种典型的 distinct_id ：

users表中的fisrts_id指的是设备ID，second_id指的是登陆ID

1.特点

只要设备不变，那么设备ID不变，神策ID不变

2.案例说明

案例解释说明

关联设备 ID 和登录 ID 的方法虽然实现了更准确的用户追踪，但是也会增加埋点接入的复杂度。

1.适用场景

2. 局限性 *

3.案例说明

案例具体解释

1.使用场景

一个登陆ID绑定多个设备，比如 Web 端和 App 端可能都需要进行登录。

支持一个登录 ID 下关联多设备 ID 之后，用户在多设备下的行为就会贯通，被认为是一个神策 ID 发生的。

2.局限性

3.案例说明

操作同上面的流程，重点关注第七条记录

由于设备 Y 被关联到登录 ID A 下，修复设备 Y 上登录之前的数据：神策 ID 3 -神策 ID 1