growingio官网从页面采集到的数据存储到哪里

埋点 growingio 数据分析 数据采集 网站分析 应用分析
去网站注册了看看,但是没找到哪里下载SDK,,,,,,找到了。。。敬请期待。。。我的理解是 不是不必埋点,而是不需要代码埋点吧。诸葛io, talking data都有类似产品。不过只能定义一个事件名称,简单地使用感觉还会不错的。但是如果要做类似GA AA那样的专业分析,能力上还是差了几个数量级的感觉。这类tracking 和 百度统计的差距倍数大概等于百度统计和GA差距的倍数。但是,他们的确很方便。
我是神策数据的创始人桑文锋,属于利益相关者,最近正好写了篇文章,聊一聊“埋点”到底要不要。原文见:&a href=&/p/?refer=sangwf& class=&internal&&在数据采集上的痛苦、幻想与失望 - 瓦利哥的机器岁月 - 知乎专栏&/a&&br&&img src=&/a521904ebafe92b427e1db_b.png& data-rawwidth=&900& data-rawheight=&500& class=&origin_image zh-lightbox-thumb& width=&900& data-original=&/a521904ebafe92b427e1db_r.png&&&br&&p&随着移动互联网时代的兴起和数据量的大规模爆发,越来越多的互联网企业开始重视数据的质量。在我创业的这一年里,接触了 200 多家创业型公司,发现如今的企业对数据的需求已经不仅仅局限于简单的 PV、UV,而是更加重视用户使用行为数据的相关分析。&/p&&br&&p&做数据的同学都知道,在数据分析的道路上,数据采集是重中之重。数据采集的质量直接决定了你的分析是否准确。而随着企业对数据的要求越来越高,埋点技术也被推到了“风口浪尖”。所谓,埋的好是高手,埋不好反倒伤了自己。而在数据采集的道路上大家经常会遇到各种各样的问题,今天我们就来分析一下埋点是否需要。&/p&&br&&p&&strong&首先我把数据采集的问题归结为三类:&/strong&&/p&&blockquote&&p&1、不知道怎么采,包括采集什么数据以及用什么技术手段采集;&/p&&p&2、埋点混乱,出现埋错、漏埋这样的问题;&/p&&p&3、数据团队和业务工程团队配合困难,往往产品升级的优先级大于数据采集的优先级。&/p&&/blockquote&&p&上面这三类问题让数据团队相当痛苦,进而幻想弃用数据采集,而尝试新方案后,进而迎来的是更大的失望。这里我对这三类问题的现状及应对之策做一下分析。&/p&&br&&p&&b&? 不知道怎么采&/b&&/p&&br&&p&一般创业公司的数据采集,分为&strong&三种方式&/strong&:&/p&&br&&p&第一种直接使用友盟、百度统计这样的第三方统计工具,通过嵌入 App SDK 或 JS SDK,来直接查看统计数据。这种方式的好处是简单、免费,因此使用非常普及。对于看一些网站访问量、活跃用户量这样的宏观数据需求,基本能够满足。&/p&&br&&p&但是,对于现在一些涉及订单交易类型的产品,仅仅宏观的简单统计数据已经不能满足用户的需求了,他们更加关注一些深度的关键指标分析,例如:用户渠道转化、新增、留存、多维度交叉分析等。这个时候才发现第三方统计工具很难满足对数据的需求,而出现这样的问题并不是因为工具的分析能力薄弱,而是因为这类工具对于数据采集的不完整。 通过这种方式 SDK 只能够采集到一些基本的用户行为数据,比如设备的基本信息,用户执行的基本操作等。但是服务端和数据库中的数据并没有采集,一些提交操作,比如提交订单对应的成本价格、折扣情况等信息也没有采集,这就导致后续的分析成了“巧妇难为无米之炊”。&/p&&br&&p&通过客户端 SDK 采集数据还有一个问题就是经常觉得统计不准,和自己的业务数据库数据对不上,出现丢数据的情况。这是前端数据采集的先天缺陷,因为网络异常,或者统计口径不一致,都会导致数据对不上。&/p&&br&&p&第二种是直接使用业务数据库做统计分析。一般的互联网产品,后端都有自己的业务数据库,里面存储了订单、用户注册信息等数据,基于这些数据,一些常用的统计分析都能够搞定。这种方式天然的就能分析业务数据,并且是实时、准确的。&/p&&br&&p&但不足之处有两点:一是业务数据库在设计之初就是为了满足正常的业务运转,给机器读写访问的。为了提升性能,会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表,这些表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时间搞懂了,隔天工程师又告诉你因为性能问题拆表了,你就崩溃了。另一个不足之处是业务数据表的设计是针对高并发低延迟的小操作,而数据分析常常是针对大数据进行批量操作的,这样就导致性能很差。&/p&&br&&p&第三种是通过 Web 日志进行统计分析。这种方式相较于第二种,完成了数据的解耦,使业务数据和统计分析数据相互分离。然而,这种方式的问题是“目的不纯”。Web 日志往往是工程师为了方便 Debug 顺便搞搞,这样的日志对于业务层面的分析,常常“缺斤少两”。并且从打印日志到处理日志再到输出结果,整个过程很容易出错,我在百度就花了几年的时间解决这一问题。&/p&&br&&p&所以,以上三种方式虽然都多多少少解决了一部分数据采集的问题,但又都解决的不彻底。&/p&&br&&p&&b&? 埋点混乱&/b&&/p&&br&&p&聊完采集方法,再来说说关于埋点的管理。我曾经接触了一家做了七八年的老牌互联网公司,他们的数据采集有 400 多个点。每次数据产品经理提出数据采集的需求后,工程师就会按照要求增加埋点,然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常,可等产品上线之后,才发现埋的不对,再进行升级发版操作,整个过程效率极低。我们发现,一个公司发展到了一定程度,没有专人去负责埋点管理工作,数据采集就完全没有准确性可据采集就完全没有准确性可言。甚至有时产品上线之后,才发现数据采集的工作没有做,也就是漏埋了。&/p&&br&&p&于是数据团队又开始幻想,既然埋点这么容易出问题,有没有可能不埋点?这就像寻找可以祈求风调雨顺的神灵。&/p&&br&&p&在 2010 年,百度 MP3 团队曾经做了一个叫 ClickMonkey 的产品,只要页面上嵌入 SDK,就可以采集页面上所有的点击行为,然后就可以绘制出用户点击的热力图,这种方式对于一些探索式的调研还是比较有用的。到了2013 年,国外有家数据分析公司 Heap Analytics,把这种方式更近一步,将 App 的操作尽量多的采集下来,然后通过界面配置的方式对关键行为进行定义,这样便完成了所谓的“无埋点”数据采集。使用这种方案,必须在产品中嵌入 SDK,等于做了一个统一的埋点,所以“无埋点”的叫法实际上是“全埋点”的代名词。&/p&&br&&p&另外,这种方式同样也只能采集前端数据,后端服务器和数据库中的数据,依旧是无可奈何的。并且,即便进行前端数据采集,也无法深入到更细粒度。比如提交订单操作,订单运费、成本价格之类的维度信息,都丢失掉了,只剩下“提交”这一个行为类型。&br&&/p&&br&&p&对于非技术人员,容易被这种方式的名称和直接优势所吸引,但很快又会发现许多深度数据分析需求无法直接满足,进而有种被忽悠的感觉,会感到失望。其实不止是非技术人员,即使是技术人员,也都会让我解释一下“可视化埋点”的原理,说明“无埋点”真是个有迷惑性又不甚清晰的概念,难以细究。&/p&&br&&p&这里说一下关键点:一是事先在产品上埋一个 SDK,二是通过可视化的方式,生成配置信息,也就是事件名称之类的定义,三是将采集的数据按照配置重命名,进而就能做分析了。&/p&&br&&p&&b&? 数据团队和业务工程团队的配合问题&/b&&/p&&br&&p&最后,我们再聊一聊数据采集中遇到的非技术性问题。一般来说,公司到了 A 轮以后,都会有专门的数据团队或者兼职数据人员,对公司的一些业务指标负责。即使为了拿到这些基本的业务指标,一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了,天下武功唯快不破。于是所有事情都要给产品迭代升级让路,快的都没有时间做数据采集了。殊不知没有数据指标的支撑,又怎么衡量这个功能升级是不是合理的呢?互联网产品并不是功能越多就越好,产品是否经得起用户考验,还是要基于数据说话的,然后学习新知识,用于下一轮的迭代。&/p&&br&&p&数据团队和业务工程团队是平级的团队,而数据团队看起来总是给业务工程团队增加麻烦事儿,似乎也不能直接提升工程团队的 KPI,所以就导致需求不被重视,总是被更高优先级的事情挤掉,数据的事情难有进展。&/p&&br&&p&&strong&解决之道&/strong&&/p&&br&&p&前面给大家抛出了数据采集中常见的三类问题,下面我们来看一下应对之道。&/p&&br&&p&对于不知道数据怎么采的问题,首先从意识上要重视数据采集工作。数据的事情归结起来就两点:数据采集和数据分析。可不能只看到数据分析而忽略了数据采集。事实上我个人在百度做数据的几年里,最大的心得就是数据这个事情要做好,最重要的是数据源,数据源收集得好,就成功了一大半。数据采集的基本原则是全和细。全就是把多种数据源都进行采集,而不只是客户端的用户数据。细就是强调多维度,把事件发生的一系列维度信息,比如订单运费、成本价格等,尽量多的记录下来,方便后续交叉分析。&/p&&br&&p&其次,要有一个数据架构师,对数据采集工作负责,每次数据采集点的增加或变更,都要经过系统化的审核管理,不能顺便搞搞。最后,我这里要推荐 Event 数据模型(有兴趣的可阅读:&a href=&///?target=https%3A///manual/data_model.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&数据模型 | Sensors Analytics 使用手册&i class=&icon-external&&&/i&&/a&),针对用户行为数据,简化成一张宽表,将用户的操作归结为一系列的事件。&/p&&br&&p&对于埋点混乱的问题,前面提到的数据架构师的角色,要对这块的管理负责。如果前面完成对 Event 的梳理,这里的埋点就会清晰很多。另外还要推荐尽量从后端进行埋点,这样便无需多客户端埋点了。当然,如果有行为只在客户端发生,还是要在客户端进行埋点的。对于业务复杂的情况,只有负责人还不够。目前我们神策分析针对这个问题,推出了埋点管理功能,对于每个采集点的数据收集情况,都能够做到全盘监控,并且可以针对一些无效采集点进行禁用。总之是希望把这个问题尽量好的解决掉。&/p&&br&&p&对于数据团队和工程团队的配合问题,我这里是想说给创业公司的创始人听的。两个平行部门间的推动,是很难的。数据的事情一定要自上而下的推动,也就是创始人一定要重视数据,把数据需求的优先级提升,这样在项目排期时,能够把数据的需求同时做了。我们知道两军对战,情报收集工作的重要性。做产品也是一样,数据收集工作的重要性不言而喻。&/p&&br&&p&最后,期望越来越多的创始人,从拍脑袋决策逐步向数据驱动决策做出转变。&/p&
我是神策数据的创始人桑文锋,属于利益相关者,最近正好写了篇文章,聊一聊“埋点”到底要不要。原文见: 随着移动互联网时代的兴起和数据量的大规模爆发,越来越多的互联网企业开始重视数据…
然而growing io只能做到对某个按钮进行设置,如果你的APP页面较多,按钮较多,你会因为想看这些字段的报表而设置疯掉。数据统计一直都是以从“宏观→微观,从局部→全面”反复推演才能得出较为精准的分析结果。如果要像Growing io一样把所有的细节点完全拆开,那么为了某个键位转化后对应的金字塔式接口,我相信你会被大量的数据路径弄疯。
然而growing io只能做到对某个按钮进行设置,如果你的APP页面较多,按钮较多,你会因为想看这些字段的报表而设置疯掉。数据统计一直都是以从“宏观→微观,从局部→全面”反复推演才能得出较为精准的分析结果。如果要像Growing io一样把所有的细节点完全拆…
已有帐号?
无法登录?
社交帐号登录
明白四达能无知乎| 时间排序
两个Saas服务都很优秀,都是国内顶级的用户数据分析服务。&br&如何选择可以从两个方面来考虑:&br&&br&1. 考察两个公司的产品功能,稳定性,准确性,数据安全性。但是这个方法有明显的问题,就是耗费大量的精力和时间后也不一定得到准确的结果。而产品的稳定性和安全性有需要长时间的考验,所以作为一个使用者来说根本没法评价。&br&&br&2. 从这些服务的真实用户来考察。SaaS的客户多且和你类似就从侧面证明了这个服务可能适合你。&br&&br&我从拉勾和IT橘子抓去了大约5万 家互联网公司,分析了这些公司的官网使用了那些数据分析产品,GrowingIO大约300+, 诸葛IO大约30+。 受到统计方法的局限,只分析了官网的数据,而且绝对数字都还比较小不能完全说明问题,但也有一定的参考意义。至少看看和你类似的公司都选择了那个服务。&br&&br&具体结果如下。&br&GrowingIO:&a href=&///?target=http%3A///product/growingio& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/product/grow&/span&&span class=&invisible&&ingio&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&诸葛IO:&a href=&///?target=http%3A///product/zhugeio& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/product/zhug&/span&&span class=&invisible&&eio&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&其他数据分析产品:&a href=&///?target=http%3A///category/analytics& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/category/ana&/span&&span class=&invisible&&lytics&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
两个Saas服务都很优秀,都是国内顶级的用户数据分析服务。 如何选择可以从两个方面来考虑: 1. 考察两个公司的产品功能,稳定性,准确性,数据安全性。但是这个方法有明显的问题,就是耗费大量的精力和时间后也不一定得到准确的结果。而产品的稳定性和安全…
使用第三方平台一般情况是还要用到这第三方的部分数据吧,而这部分数据又是涉及用户隐私,无法明文给出的,如运营商的数据,你的模型必须部署在他们平台上,他们还要先审核。
使用第三方平台一般情况是还要用到这第三方的部分数据吧,而这部分数据又是涉及用户隐私,无法明文给出的,如运营商的数据,你的模型必须部署在他们平台上,他们还要先审核。
GrowingIO 全站都没有任何收费提示,等你使用了15天后,自动停了你的分析,发个邮件跟你说收费的, 关键还影响了 GA的统计。
GrowingIO 全站都没有任何收费提示,等你使用了15天后,自动停了你的分析,发个邮件跟你说收费的, 关键还影响了 GA的统计。
刚刚做growth工作不久,从目前的理解来说,我觉得growth的工具主要分三类。&br&&br&第一类是growth hack-获取用户,这个过程本身的工具。这些工具是用来直接做growth工作本身的。&br&&br&包括但不限于&br&1,一个能够attract潜在用户的博客系统。&br&2,edm邮件营销或其他outbound营销的工具,例如sendcloud等。&br&3,自动化营销工具,例如marketo,hubspot,mautic等&br&4,adwords,facebook等广告投放系统&br&&br&第二类是统计,获取数据的工具&br&growth工作需要对做的一切事情用key metric数据来评价推动。&br&&br&包括但不限于&br&1,google analytics,kissmetrics等网站流量统计分析工具&br&2,基本的sql查询&br&3,基本的js能力,可以利用google tag来方便地埋点统计。&br&&br&第三类是数据分析,数据可视化的工具&br&将数据呈现出来,分析总结,并利用这些数据和他人沟通。&br&&br&包括但不限于&br&1,excel,numbers图表。&br&2,tableau或者plotly等数据可视化工具&br&3,ppt 或者其他将数据呈现给他人的工具&br&&br&其实工具有很多,推荐大家一个论坛&br&&a href=&///?target=https%3A///growth-studies& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/growt&/span&&span class=&invisible&&h-studies&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&有很多国外的growth在上面讨论&br&关于inbound营销,这里有两篇文章也可以给大家参考&br&&a href=&/p/& class=&internal&&&span class=&invisible&&http://&/span&&span class=&visible&&/p/21&/span&&span class=&invisible&&572442&/span&&span class=&ellipsis&&&/span&&/a&
刚刚做growth工作不久,从目前的理解来说,我觉得growth的工具主要分三类。 第一类是growth hack-获取用户,这个过程本身的工具。这些工具是用来直接做growth工作本身的。 包括但不限于 1,一个能够attract潜在用户的博客系统。 2,edm邮件营销或其他outbou…
我是神策数据的创始人桑文锋,属于利益相关者,最近正好写了篇文章,聊一聊“埋点”到底要不要。原文见:&a href=&/p/?refer=sangwf& class=&internal&&在数据采集上的痛苦、幻想与失望 - 瓦利哥的机器岁月 - 知乎专栏&/a&&br&&img src=&/a521904ebafe92b427e1db_b.png& data-rawwidth=&900& data-rawheight=&500& class=&origin_image zh-lightbox-thumb& width=&900& data-original=&/a521904ebafe92b427e1db_r.png&&&br&&p&随着移动互联网时代的兴起和数据量的大规模爆发,越来越多的互联网企业开始重视数据的质量。在我创业的这一年里,接触了 200 多家创业型公司,发现如今的企业对数据的需求已经不仅仅局限于简单的 PV、UV,而是更加重视用户使用行为数据的相关分析。&/p&&br&&p&做数据的同学都知道,在数据分析的道路上,数据采集是重中之重。数据采集的质量直接决定了你的分析是否准确。而随着企业对数据的要求越来越高,埋点技术也被推到了“风口浪尖”。所谓,埋的好是高手,埋不好反倒伤了自己。而在数据采集的道路上大家经常会遇到各种各样的问题,今天我们就来分析一下埋点是否需要。&/p&&br&&p&&strong&首先我把数据采集的问题归结为三类:&/strong&&/p&&blockquote&&p&1、不知道怎么采,包括采集什么数据以及用什么技术手段采集;&/p&&p&2、埋点混乱,出现埋错、漏埋这样的问题;&/p&&p&3、数据团队和业务工程团队配合困难,往往产品升级的优先级大于数据采集的优先级。&/p&&/blockquote&&p&上面这三类问题让数据团队相当痛苦,进而幻想弃用数据采集,而尝试新方案后,进而迎来的是更大的失望。这里我对这三类问题的现状及应对之策做一下分析。&/p&&br&&p&&b&? 不知道怎么采&/b&&/p&&br&&p&一般创业公司的数据采集,分为&strong&三种方式&/strong&:&/p&&br&&p&第一种直接使用友盟、百度统计这样的第三方统计工具,通过嵌入 App SDK 或 JS SDK,来直接查看统计数据。这种方式的好处是简单、免费,因此使用非常普及。对于看一些网站访问量、活跃用户量这样的宏观数据需求,基本能够满足。&/p&&br&&p&但是,对于现在一些涉及订单交易类型的产品,仅仅宏观的简单统计数据已经不能满足用户的需求了,他们更加关注一些深度的关键指标分析,例如:用户渠道转化、新增、留存、多维度交叉分析等。这个时候才发现第三方统计工具很难满足对数据的需求,而出现这样的问题并不是因为工具的分析能力薄弱,而是因为这类工具对于数据采集的不完整。 通过这种方式 SDK 只能够采集到一些基本的用户行为数据,比如设备的基本信息,用户执行的基本操作等。但是服务端和数据库中的数据并没有采集,一些提交操作,比如提交订单对应的成本价格、折扣情况等信息也没有采集,这就导致后续的分析成了“巧妇难为无米之炊”。&/p&&br&&p&通过客户端 SDK 采集数据还有一个问题就是经常觉得统计不准,和自己的业务数据库数据对不上,出现丢数据的情况。这是前端数据采集的先天缺陷,因为网络异常,或者统计口径不一致,都会导致数据对不上。&/p&&br&&p&第二种是直接使用业务数据库做统计分析。一般的互联网产品,后端都有自己的业务数据库,里面存储了订单、用户注册信息等数据,基于这些数据,一些常用的统计分析都能够搞定。这种方式天然的就能分析业务数据,并且是实时、准确的。&/p&&br&&p&但不足之处有两点:一是业务数据库在设计之初就是为了满足正常的业务运转,给机器读写访问的。为了提升性能,会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表,这些表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时间搞懂了,隔天工程师又告诉你因为性能问题拆表了,你就崩溃了。另一个不足之处是业务数据表的设计是针对高并发低延迟的小操作,而数据分析常常是针对大数据进行批量操作的,这样就导致性能很差。&/p&&br&&p&第三种是通过 Web 日志进行统计分析。这种方式相较于第二种,完成了数据的解耦,使业务数据和统计分析数据相互分离。然而,这种方式的问题是“目的不纯”。Web 日志往往是工程师为了方便 Debug 顺便搞搞,这样的日志对于业务层面的分析,常常“缺斤少两”。并且从打印日志到处理日志再到输出结果,整个过程很容易出错,我在百度就花了几年的时间解决这一问题。&/p&&br&&p&所以,以上三种方式虽然都多多少少解决了一部分数据采集的问题,但又都解决的不彻底。&/p&&br&&p&&b&? 埋点混乱&/b&&/p&&br&&p&聊完采集方法,再来说说关于埋点的管理。我曾经接触了一家做了七八年的老牌互联网公司,他们的数据采集有 400 多个点。每次数据产品经理提出数据采集的需求后,工程师就会按照要求增加埋点,然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常,可等产品上线之后,才发现埋的不对,再进行升级发版操作,整个过程效率极低。我们发现,一个公司发展到了一定程度,没有专人去负责埋点管理工作,数据采集就完全没有准确性可据采集就完全没有准确性可言。甚至有时产品上线之后,才发现数据采集的工作没有做,也就是漏埋了。&/p&&br&&p&于是数据团队又开始幻想,既然埋点这么容易出问题,有没有可能不埋点?这就像寻找可以祈求风调雨顺的神灵。&/p&&br&&p&在 2010 年,百度 MP3 团队曾经做了一个叫 ClickMonkey 的产品,只要页面上嵌入 SDK,就可以采集页面上所有的点击行为,然后就可以绘制出用户点击的热力图,这种方式对于一些探索式的调研还是比较有用的。到了2013 年,国外有家数据分析公司 Heap Analytics,把这种方式更近一步,将 App 的操作尽量多的采集下来,然后通过界面配置的方式对关键行为进行定义,这样便完成了所谓的“无埋点”数据采集。使用这种方案,必须在产品中嵌入 SDK,等于做了一个统一的埋点,所以“无埋点”的叫法实际上是“全埋点”的代名词。&/p&&br&&p&另外,这种方式同样也只能采集前端数据,后端服务器和数据库中的数据,依旧是无可奈何的。并且,即便进行前端数据采集,也无法深入到更细粒度。比如提交订单操作,订单运费、成本价格之类的维度信息,都丢失掉了,只剩下“提交”这一个行为类型。&br&&/p&&br&&p&对于非技术人员,容易被这种方式的名称和直接优势所吸引,但很快又会发现许多深度数据分析需求无法直接满足,进而有种被忽悠的感觉,会感到失望。其实不止是非技术人员,即使是技术人员,也都会让我解释一下“可视化埋点”的原理,说明“无埋点”真是个有迷惑性又不甚清晰的概念,难以细究。&/p&&br&&p&这里说一下关键点:一是事先在产品上埋一个 SDK,二是通过可视化的方式,生成配置信息,也就是事件名称之类的定义,三是将采集的数据按照配置重命名,进而就能做分析了。&/p&&br&&p&&b&? 数据团队和业务工程团队的配合问题&/b&&/p&&br&&p&最后,我们再聊一聊数据采集中遇到的非技术性问题。一般来说,公司到了 A 轮以后,都会有专门的数据团队或者兼职数据人员,对公司的一些业务指标负责。即使为了拿到这些基本的业务指标,一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了,天下武功唯快不破。于是所有事情都要给产品迭代升级让路,快的都没有时间做数据采集了。殊不知没有数据指标的支撑,又怎么衡量这个功能升级是不是合理的呢?互联网产品并不是功能越多就越好,产品是否经得起用户考验,还是要基于数据说话的,然后学习新知识,用于下一轮的迭代。&/p&&br&&p&数据团队和业务工程团队是平级的团队,而数据团队看起来总是给业务工程团队增加麻烦事儿,似乎也不能直接提升工程团队的 KPI,所以就导致需求不被重视,总是被更高优先级的事情挤掉,数据的事情难有进展。&/p&&br&&p&&strong&解决之道&/strong&&/p&&br&&p&前面给大家抛出了数据采集中常见的三类问题,下面我们来看一下应对之道。&/p&&br&&p&对于不知道数据怎么采的问题,首先从意识上要重视数据采集工作。数据的事情归结起来就两点:数据采集和数据分析。可不能只看到数据分析而忽略了数据采集。事实上我个人在百度做数据的几年里,最大的心得就是数据这个事情要做好,最重要的是数据源,数据源收集得好,就成功了一大半。数据采集的基本原则是全和细。全就是把多种数据源都进行采集,而不只是客户端的用户数据。细就是强调多维度,把事件发生的一系列维度信息,比如订单运费、成本价格等,尽量多的记录下来,方便后续交叉分析。&/p&&br&&p&其次,要有一个数据架构师,对数据采集工作负责,每次数据采集点的增加或变更,都要经过系统化的审核管理,不能顺便搞搞。最后,我这里要推荐 Event 数据模型(有兴趣的可阅读:&a href=&///?target=https%3A///manual/data_model.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&数据模型 | Sensors Analytics 使用手册&i class=&icon-external&&&/i&&/a&),针对用户行为数据,简化成一张宽表,将用户的操作归结为一系列的事件。&/p&&br&&p&对于埋点混乱的问题,前面提到的数据架构师的角色,要对这块的管理负责。如果前面完成对 Event 的梳理,这里的埋点就会清晰很多。另外还要推荐尽量从后端进行埋点,这样便无需多客户端埋点了。当然,如果有行为只在客户端发生,还是要在客户端进行埋点的。对于业务复杂的情况,只有负责人还不够。目前我们神策分析针对这个问题,推出了埋点管理功能,对于每个采集点的数据收集情况,都能够做到全盘监控,并且可以针对一些无效采集点进行禁用。总之是希望把这个问题尽量好的解决掉。&/p&&br&&p&对于数据团队和工程团队的配合问题,我这里是想说给创业公司的创始人听的。两个平行部门间的推动,是很难的。数据的事情一定要自上而下的推动,也就是创始人一定要重视数据,把数据需求的优先级提升,这样在项目排期时,能够把数据的需求同时做了。我们知道两军对战,情报收集工作的重要性。做产品也是一样,数据收集工作的重要性不言而喻。&/p&&br&&p&最后,期望越来越多的创始人,从拍脑袋决策逐步向数据驱动决策做出转变。&/p&
我是神策数据的创始人桑文锋,属于利益相关者,最近正好写了篇文章,聊一聊“埋点”到底要不要。原文见: 随着移动互联网时代的兴起和数据量的大规模爆发,越来越多的互联网企业开始重视数据…
功能先不说,先说这个公司做业务的方法有点奇葩。&br&收费标准隐藏极深,官网无明显链接,会误导用户这是免费服务。&br&在安装完之后,客服会发邮件说他们要收费。&br&就很想知道这么重要的事情为什么不早说?
功能先不说,先说这个公司做业务的方法有点奇葩。 收费标准隐藏极深,官网无明显链接,会误导用户这是免费服务。 在安装完之后,客服会发邮件说他们要收费。 就很想知道这么重要的事情为什么不早说?
正在使用诸葛IO。&br&之前也在这两家之间选择哪个纠结,但GrowingIO主打的无埋点技术,一看就是给小白数据分析师的....还是选了诸葛IO。&br&GrowingIO不至于那么low,只是市场主打卖点太『平民化』
正在使用诸葛IO。 之前也在这两家之间选择哪个纠结,但GrowingIO主打的无埋点技术,一看就是给小白数据分析师的....还是选了诸葛IO。 GrowingIO不至于那么low,只是市场主打卖点太『平民化』
我其实想说, 在互联网行业上,linkedin,比起国内BAT,差挺远的。 数据分析更是。
我其实想说, 在互联网行业上,linkedin,比起国内BAT,差挺远的。 数据分析更是。
自己的后端统计可以更好的结合业务逻辑。&br&第三方统计更多的是通用的模型。&br&但如果第三方统计模型足以覆盖分析需求可以考虑第三方统计,毕竟维护一套统计系统或数据仓库还是比较麻烦的事情,比如数据量的增长可能会使自己后端统计模块变复杂、模块耦合不易维护,以及以后需要更多的统计需求的时候,之前的数据是否还有效。&br&第三方分析推荐试用诸葛io或神策分析还有growingio。&br&诸葛io是国内较早开始做数据分析的公司,主要是手机端的数据分析,价格也比较实惠。&br&神策的分析模型很通用,前端行为后端业务数据都可以接入打通分析,并且支持私有部署,适合长期使用。&br&growingio的无埋点分析理念很简单易用,主要是分析页面展示,控件触发等,容易上手,但也因此分析能力有限。
自己的后端统计可以更好的结合业务逻辑。 第三方统计更多的是通用的模型。 但如果第三方统计模型足以覆盖分析需求可以考虑第三方统计,毕竟维护一套统计系统或数据仓库还是比较麻烦的事情,比如数据量的增长可能会使自己后端统计模块变复杂、模块耦合不易维…
乱入混答,不满意请见谅。&br&&br&首先,结合企业实际拥有的数据,配合什么样的分析模型,想得到什么样的结果,这才是数据分析的难点,也是真正的价值点,第三方的平台一般提供不了这个。假设第三方能够提供咨询服务和解决方案,那么最难的问题已经解决了,基本上已经不存在接入第三方的需求。&br&&br&其次,作为一个企业,出于数据展现需要的话,如果拥有能力通过MDM,ETL等清洗出合适的数据,市面上有很多现成的工具可供操作。如微软的powerBI,sharepoint,开源的各种js chart,没有数据外泄的风险,而且可以跟企业权限体系OA等等的无缝连接。&br&&br&此外,有能力自己搭建自主掌控的平台对企业来说,远比选择一个第三方平台在降低技术风险角度更具可持续性。
乱入混答,不满意请见谅。 首先,结合企业实际拥有的数据,配合什么样的分析模型,想得到什么样的结果,这才是数据分析的难点,也是真正的价值点,第三方的平台一般提供不了这个。假设第三方能够提供咨询服务和解决方案,那么最难的问题已经解决了,基本上…
我说几点实际应用之后的体验&br&GrowingIO来讲非常整体功能比较合理,可自定义组合的方式很多。上手比较容易能带给用户很好的体验。但是在注册之后检测SDK和数据生成速度上还是需要改进。我等一个小时验证没成功,睡了一觉起来才好。&br&诸葛IO 帮助内容和SDK集成开发指导做的很好,便于新手能在指导下完成独立操作,功能都是大同小异, 比较倾向与APP端,推送功能略显鸡肋,不知道是不是为了弥补APP自身不能采集推送内容数据的而做的。并且值得一提的是,在注册的时候,整整等了10分钟没收到验证码。以为手机坏了,发给同事去注册,他也说没收到,后来才发现在右下角有个移动图片验证码,好尴尬
我说几点实际应用之后的体验 GrowingIO来讲非常整体功能比较合理,可自定义组合的方式很多。上手比较容易能带给用户很好的体验。但是在注册之后检测SDK和数据生成速度上还是需要改进。我等一个小时验证没成功,睡了一觉起来才好。 诸葛IO 帮助内容和SDK集成…
随着加入的门槛越来越低,会有很多人感兴趣的。国内来讲这种就是一专多能复合型技术人员&br&我的看法是可以把这个职业看成是网游里的吟游诗人,在副本中进行指挥和辅助工作,增加团队总体质量,弥补各种短板,并作出正确指导。
随着加入的门槛越来越低,会有很多人感兴趣的。国内来讲这种就是一专多能复合型技术人员 我的看法是可以把这个职业看成是网游里的吟游诗人,在副本中进行指挥和辅助工作,增加团队总体质量,弥补各种短板,并作出正确指导。
为啥在GrowingIO的问题下面推荐其他软件的,都要匿名呀。&br&软件用得好好的,你是怎么找到这个问题下面来的呀……&br&&br&GrowingIO在招人,可以过来聊聊,有兴趣私信。
为啥在GrowingIO的问题下面推荐其他软件的,都要匿名呀。 软件用得好好的,你是怎么找到这个问题下面来的呀…… GrowingIO在招人,可以过来聊聊,有兴趣私信。
以营利为目的的企业法人,成本不应该是首要考虑的吗?
以营利为目的的企业法人,成本不应该是首要考虑的吗?
有没有可视化的埋点设置?
有没有可视化的埋点设置?
&img src=&/5e7e93d3649381ecbbed69_b.png& data-rawwidth=&992& data-rawheight=&788& class=&origin_image zh-lightbox-thumb& width=&992& data-original=&/5e7e93d3649381ecbbed69_r.png&&
已有帐号?
无法登录?
社交帐号登录

我要回帖

更多关于 growingio博客 的文章

 

随机推荐