初见Keen Io

这篇文章已经后台躺了快一个月,一直没有陆续完善出来.谈到初见Keen Io是一个很意外的机会,本来我是在读Growth Hacker(增长黑客)范冰写的这本书中想试用一下User Cycle这个工具,来做一个用户数据模型验证试验.但往往奇妙的事情在于总是有些你渴望东西总是能够和你不期而遇. 在注册完User Cycle后创建一个Project才发现User Cycle分析的数据来自于Keen Io:

初见Keen Io_第1张图片
Create Project For User Cycle[Via by chenkai]

于是乎就这样意外初识Keen IO.

初见Keen Io_第2张图片
Keen IO Logo [Via By keen.io]

刚开始我看到User Cycle相对于Mixpanel和KissMetrics的纯粹分析工具,它的特点极其简单-其实你并不需要大量的数据来帮你发现问题原因或寻求决策,反而数据自身也会产生很多干扰,所以你真正需要的是每次只专注一个指标,获取能够让你用来提升这个指标的目标数据,其实就足够了,这就是User Cycle要解决的问题.所以既然不是纯粹分析工具,那它分析基础数据来自哪里? 直到见到Keen Io.

Keen Io 解决什么问题?

如果你要问这个问题你会发现在Google基本上找不到任何和这个相关的资料,而涉及keen io中文更是凤毛麟角.简单来说,市面上的统计分析服务很多,类似国内的Umeng,但是未必能完全你的分析需求。这个时候你有两种选择,要么是自己从头开发系统,要么提供数据,利用第三方的分析功能组合出自己想要的结果. 其实Keen IO 说到底就能提供这种服务.

就拿Umeng来说,首先要获取到可视化数据分析,必须要做的第一件事情是集成Umeng自身的Sdk.但你可以看到:

初见Keen Io_第3张图片
Umeng SDK [Via By chenkai]

在统计分析这个层面上,你会发现支持的SDK还是非常有限的,如果要做某个一Web站点用户统计你会发现完全没有可用Sdk(javascript版本)作支持.从技术实现角度来说手机端通过设备唯一序列号来作为用户的唯一标示.类似iOS的UDID.简单轻便,而对于Web端来说我们单一通过UV量独立IP来区别用户唯一性也是不准确的,也需要和用户对应回话Cookie结合,统计数据存在一定比例的出入,但还具有参考价值.所以从某种程度来说Umeng更偏向于移动端. 对于平台支持上自身有很大限制.

Umeng其实只是基础数据通用统计分析平台,这就意味很难兼顾各个应用自身的实际应用场景个性化数据统计分析需求.打一个简单例子来说单从页面访问路径这个来看,假设A页面跳到B页面流失率是65%,我们需要采用数据分析手段来找到这个问题原因所在,这是你就发现Umeng作为通用数据统计平台让你难过地方了. 第一它不支持传递更多详细数据用来支持我们分析,第二Umeng平台数据统计规则通用且单一,而分析问题需要对数据多个维度进行交叉对比,问题在于你无法在Umeng平台上定义自己的统计分析规则,所以严格意义来说出了数据不同大家看到统计规则是都是一样的.另外不得不说是Umeng统计收集大量数据对外输出方式不太友好,需要申请然后下载数据文件,额外处理.这无疑增加额外成本,到最后让人感觉自己应用创造的数据反而不是自己的(无法自由访问).

除了这些页面层级数据统计不便之外,应用本身基于产品需求需要很多在用户操作场景中单点统计需求也比较多.Umeng做法就是常见的事件(Event).统一规则为触发这个事件的总和.Event在Sdk还提供发送这个事件附带一个message字段,这就是我要说的问题所在,很多时候在用户场景改变后,涉及统计参数数量也在或增或减,而一个单一Message字段是无论如何也是无法做到满足所有需求的.问题在于你无法通过Event事件自定义自己的数据结构,这样弊端直接导致无法采集到丹霞下统计数据.另外就是默认求总和的规则,我想说很多时候业务场景统计规则也是多变的,类似在页面当一个用户点击Button在一个时间段频率减少一定阀值(算的是一个中间值)时触发一个后台事件(更换一个新的广告源),这就意味这什么呢: 第一统计分析采集到数据能够实时在后台计算,注意这里实时,也就意味统计拿到数据后需要根据用户行为自动触发新的规则,客户端根据新的规则生成新的行为与用户交互.这些都算是更高的要求,你会发现这些事情都是Umeng做不了的.

这些场景下问题Keen IO就有了用武之地.

简单来说:Keen IO将事件存储在任意的JSON格式中,自动摄取任何新的内容并有丰富的自定义属性发送的特点,这些都是完全自定义分析解决方案的基石.

Keen Io支持那些平台?

上面章节大概为了做类比看到Umeng平台支持的非常有限,偏向于移动客户端居多,那么Keen Io支持那些平台?

目前Keen Io已有Sdk支持的平台如下:

初见Keen Io_第4张图片
支持的平台[Via by chenkai]

可见基本覆盖移动端主流平台iOS和Android,且支持JavaScript(Web端Sdk)&java&.NET&Php等主流语言.所以覆盖面算是比较全面.注意只有javascript sdk能够可以有效运用Keen io 图形可视化. 稍后在讲.

另这里不得不提到一点,Keen IO 可帮助客户收集任何来源的数据,然后存储起来,并对这些数据以客户希望的方式进行可视化。客户除了可以上传历史数据、实时访问新数据以外,还可以将该服务贴牌(白标)向自己的客户再兜售.

Keen Io如何在iOS App中集成?

为了避免篇幅过长,如下章节我会演示如何在iOS App中集成Keen Io 的Sdk,以及一些基本常用的用法,下篇我讲重点讲解数据采集一些技巧和针对一些特定场景采用Keen Io书分析特定场景问题的方法. 后台回事下章节的重点.

在Keen Io Sdk界面点击或者直接跳转到Github地址上找到对应Sdk版本,如下:

初见Keen Io_第5张图片
Keen Io iOS Sdk[Via By chenkai]

这里需要提一下的是,采用Keen Io 来做数据统计分析,主要分为三步,首先支持就是通过Sdk进行数据采集,Keen Io 获取数据就后台按照对应规则进行分析,生成对应数据可视化图标.

配置参数

今天这里要做就是采集一个iOS客户端App的用户行为,首先创建一个Demo Project命名为KeenIoClientDemo源码详见这里chenkai/KeenIoClientDemo · GitHub.首先采用CocoaPod方式集成KeenIo Sdk,创建Podfile 输入:

pod 'KeenClient'

集成到项目后.可以在Pods看到引用:

初见Keen Io_第6张图片
Pod KeenIo 引用[Via by chenkai]

编译通过后,需要做第一步的关于访问ProjectId和读写Key设置,首先在Keen Io创建一个Project,进入Project详情页可以看到对应的ProjectId:

初见Keen Io_第7张图片
Project Id [Via by chenkai]

在左下角点击可以查看对应API Key两个16进制读写权限的Key:Write Key 和Read Key:

初见Keen Io_第8张图片
Write Key 和Read Key [Via by chenkai]

这也是User Cycle创建一个Project 时需要从Keen Io 读取数据两个关键的Key,如果觉得当前Key不在使用,可以直接生成一个新的则自动废除原来访问Key.在项目中找到程序入口didFinishLaunchingWithOptions方法注册:

初见Keen Io_第9张图片
注册Keen Io[Via by chenkai]

WriteKey是用来把客户端Event数据发送到Keen Io,Read Key用来把请求数据分析的结果.这样基本配置就ok.

添加事件

事件是什么?

当我们在一个App或者Web交互场景中我们需要追踪用户某个点击button的行为数据时其实就是一次事件.事件-其实就是你希望跟踪和分析的行为.在Keen Io中事件对应存储在一个Event Collection中,而这个Event Collection事件的分组是在你向Keen Io接受到第一个事件时创建的,且可以自定义Collection名称.

比如我需要统计页面访问路径,添加追踪并发送事件数据方式:

初见Keen Io_第10张图片
添加事件

如上代码可见其实就是创建一个Event,这个Event中包含两个字段ViewPath(访问路径)和Action(行为),其实这段话添加Even数据会序列化成Json格式,Keen Io 目前支持Json数据类型如下:

NSString,NSNumber,NSDate,NSDictionary,NSArray, BOOL

Keen Io为json中时间数据默认情况按照ISO-8601进行编码. 添加完Event后可以根据应用场景选择上传数据时机,这里演示目的采用是实时上传.上传成功后我们直接进入后台:

初见Keen Io_第11张图片
后台数据

在后台直接可以实时看到对应Event Collection多了一个"MainView_CT"的数据集合,在来看看客户端上传数据内容都有什么:

初见Keen Io_第12张图片
Event数据内容

从数据可见,除了我们自定义的两个字段Action 和 ViewPath之外,Keen Io每次发送数据时默认会有一个Keen的数据结构,其实Keen目前数据交付机制中默认会把发送后台数据强制采用时间戳方式进行标识.注意标识数据包含id其实对应就是这个数据的唯一Id. 当然Keen数据可以自由定制,如果你觉得系统这个时间戳格式不符合自己统计需求,可以自行定义修改:

初见Keen Io_第13张图片
修改默认时间戳

定义一个KeenProperties属性Obj,把自定义时间戳传递过来即可.进入后台看一下数据:

初见Keen Io_第14张图片
修改时间戳默认数据

两条不同数据都进来,数据格式为了演示没做任何格式处理.很简单.

全局属性

当然针对移动客户端来说,我们经常会有类似通用统计参数的需求,类似针对iphone设备我们需要知道这个Event来自什么设备型号,系统版本等等,难道我们需要在每一个Event中添加对应设备信息吗? 不需要-Global Properties很好解决这个问题.

而在Keen中实现全局属性有两种不同方式,方式一基于全局属性字典方式:

全局属性字典方式

在系统Active方式调用KeenClient的globalPropertiesDictionary属性赋值即可.方式二基于Block:

初见Keen Io_第15张图片
Block方式

很明显Block方式更为灵活,可以具体到单个Event数据,全局属性变化频率不高则可以根据采用globalPropertiesDictionary即可.

更强大的实时计算因篇幅所限,这里就不做演示.

总结

Keen支持平台较多,可以定制输入数据结构,且可以自定义统计分析数据规则,Keen本身也支持实时计算, 数据也能通过其他方式进行导出和导入.完全把统计数据三个重要环节开放出来.可以自由定制和控制.随着个性化需求衍生Keen相对通用统计平台来说,完全控制数据输入&分析&可视化优势巨大.如果你问是否推荐Keen方式来做自身需求定制,我自身感受是后台目前Free版本功能太过有限,统计分析方式需要自行加工在处理,但Keen本身开放非常多的API所以这个需求完全能够满足.但成本略偏高,源于平台本身还不足够成熟.所以Keen是一个很好平台样本,但还不足以自动化到使用一个工具能够解决大部分问题地步,这个工具平台自身成熟尚需更多时间打磨,所以我的个人建议是-[推荐在去尝试(因为尚未购买付费版本不清楚后台Free版本的差异)]

Edited by ck 2015年09月25日18:18:55

你可能感兴趣的:(初见Keen Io)