TalkingData灵动分析背后的产品故事

来源:互联网 发布:剑三成男脸型数据网盘 编辑:程序博客网 时间:2024/04/30 15:18
把简单留给用户,把复杂留给自己。谷歌千万人的智慧汇聚起来,给用户看到的只是一个小小的搜索框——这个简单的搜索框改变了世界。TalkingData作为一个创业团队,我们也一直在向往着改变世界,一直在努力用数据改变企业做决定的方式,同时帮助人们了解周围的环境。在TalkingData所处的大数据分析领域,目前对数据的理解和使用依然还有很高的门槛,而灵动分析只是TalkingData数据产品从复杂到简化的第一步。

2015年8月11日TalkingData正式发布“灵动分析”,成为移动分析新时代到来的标志。




“灵动分析”的特点在于“无码”,其功能创意始于2014年中,距离我们推出第一代移动统计分析平台已过去了3年多。当时我们想了解客户在使用TalkingData产品的遇到的各种问题,因此做了很多客户回访,结果如下:



从结果可以看出,遇到问题的客户中,有59%是在集成(包含SDK的导入、初始化、埋点、数据测试等)的时候,同时36%对于一些功能和指标不太理解。后来深入沟通以后发现,导致集成出现问题的原因有很多,既包括我们产品的原因,比如文档描述不清晰、API设计较复杂等,也包括客户侧的问题,比如研发人员编程经验不足、运营对指标的理解有偏差、研发和产品/运营的沟通不充分等。


【用户的痛点】

移动应用的产品运营过程中,通用的统计分析功能只能提供诸如新增、留存、日活等通用指标,如果想要更加精细化的优化功能模块,还是需要自定义埋点。我第一次创业的时候做过App,在360也负责几个移动端产品线,深刻了解埋点的痛苦。

正常情况下,App开发中一次埋点的过程大致是这样的:

1. 运营团队有专门的人负责埋点的id号管理和分配,长期积累下来,这是一个包含可能上万条记录的长列表——老的埋点并未完全删除,新的埋点不断增加,而且还需要区分功能模块,维护起来工作量相当不小。

2. 当产品人员需要埋点的时候,先要设计埋点的模块和触发的逻辑,然后向id管理员申请id号。

3. 在下个版本发版之前,产品人员需要把埋点作为一项功能加入功能列表(有时候研发人员忙不过来,可能就需要延迟到下个迭代才能加进来),然后要向对应的研发和测试人员做宣讲,讲清楚埋点的目标和逻辑。

4. 研发人员开始设计和开发,同时测试人员写测试用例(触发埋点逻辑)。

5. 研发人员开发完成,打包应用,提交测试人员进行功能测试。

6. 准备上线之前,需要提交埋点设计给法务部门做数据隐私审核,同时也需要在沙箱中扫描以确认所有数据包都是安全的。

7. 上线,数据收集上来,运营人员整理成报表发布给大家。

8. 产品人员研究报表的时候,才发现曲线不对,数据和设想的差很远,于是产品人员回过头来找研发确认,才发现一个对话框的埋点因为理解偏差埋错了——本来是弹出对话框点击确认的时候计数一次,研发理解成弹出对话框就计数一次。产品说你们怎么犯这样的低级错误,研发/测试却认为是产品文档没有说清楚导致的,并且把产品文档拿出来作证,才发现措辞上确实容易让人误解,很难说谁对谁错。

9. 于是产品和研发/测试商量,看是否可以紧急修改一个版本尽快上线,但是研发和测试人员说新版上线以后,大家已经开始下个迭代的开发工作,下次发版要等两周以后了。

10. 产品人员说你们看只是一个埋点工作量看似也不算大,大家伙几行代码就完成了,能不能通融一下。

11. 研发和测试急了,你以为工作量小,看似几行代码,但是除了回归测试,整个发版流程还需要重新再走一遍,法务运营都需要涉及到,至少要耽误一天,兄弟们啥都不干就发版了,下个版本延迟就不要怪我们。

12. 产品没脾气了,谁都负担不起版本发布延迟的责任,只好等4周以后的版本再把埋点功能重新修正,于是要等真正可用的数据进来,已经延迟至少4周了,这还没有算上因为研发的bug和测试的疏漏造成的延误。




看看这个过程,头脑已经发麻,可以清楚看到,埋点可能遇到的问题至少包括以下:

1. 埋点id管理混乱,埋点使用错误id,导致统计结果失效;
2. 研发人员带宽不足,而埋点常常排不上优先级,导致埋点不能及时增加或调整;
3. 产品/运营和研发/测试人员沟通不清晰,理解错误,导致埋错点;
4. 研发人员针对每次埋点需要单独写埋点代码,而且和应用正常逻辑交织在一起,容易出bug;

5. 测试人员出现疏漏,导致埋点功能失常无法及时发现。


【我们的解决方案】

于是产品和研发开始考虑如何解决这些问题,考虑的重点在于如何减少SDK集成代码和步骤,以及如何减少产品/运营和研发的沟通成本。从这个角度来看,无代码集成和埋点云配置化是一个比较直接的方案,但是也确实存在一定的局限性,除了技术和产品需要进一步润色以外,还包括自定义事件的参数处理、以及对于界面控件的过度依赖等。当时大家在技术和产品上都做了一些调研,初步完善了方案,并于2014年底灵动分析项目启动,到2015年6月才开发完成并进入内测,最终在8月份正式推出。






有了灵动分析,一个埋点的过程就变成这样了:

1. 研发人员集成TalkingData灵动分析SDK,提交测试人员和法务人员验证,因为只需要1行代码,所以几乎不可能出错,很快就能上线,上线以后就再也不需要研发/测试人员的介入了;

2. 当产品/运营人员需要埋点的时候,先在测试手机上安装集成了灵动分析SDK的应用并打开,登陆灵动分析管理后台,通过“摇一摇”完成手机和管理后台的连接。

3. 产品/运营人员在手机上操作应用,切换到需要埋点的页面,然后在管理后台上通过鼠标操作即可完成相关页面元素(比如按钮)的埋点配置。

4. 然后产品/运营人员可以在当前页面进行埋点测试,确保埋点符合预期——此时埋点配置仅对连接到管理后台的测试手机生效。

5. 产品/运营人员对埋点配置做“全部生效”操作,即可将埋点配置同步到所有安装了应用的手机端,到此埋点操作全部完成,立马就可以等着看数据了。

对比此前的各种移动应用统计分析产品,灵动分析的最大特点是大幅简化了数据集成过程,只需在App中加入分析SDK,无需再编写任何代码和更新App版本,即可实现事件跟踪、增删数据点等操作,做到完全零代码数据跟踪。这极大的简化了研发人员工作,同时也能让产品和数据分析人员任何的天马行空数据需求瞬间得到满足,大幅提高运营效率。

对于研发人员:

1. 不再需要理解产品、运营人员的业务逻辑,降低了沟通成本;

2. 几乎没有代码,也不用在功能代码中插入埋点代码,对功能影响很小,不容易出错;

3. 可以专注于实现功能开发,提高开发效率;

4. 一次集成,永久生效,无维护成本;

对于产品/运营人员:

1. 不再需要管理冗长的埋点id列表;

2. 不再需要向研发/测试解释埋点的业务逻辑,降低了沟通成本,也降低了出错的可能性;

3. 埋点的增加、删除和修改,随时线上可配,无需等待下次发新版,也无需消耗额外的法务和运营资源,提高了灵活性和反应速度;

4. 可以专注于埋点的数据分析,提升了产品运营效率;

未来我们会继续优化灵动分析的用户体验,增加更多的功能,最大程度简化客户的操作,降低学习成本,让客户能够真正聚焦于数据,而不是消耗精力在数据工具上。


【后记】





谷歌以“把简单留给用户,把复杂留给自己”为信仰,千万人的智慧汇聚起来,给用户看到的只是一个小小的搜索框——这个简单的搜索框改变了世界。

TalkingData作为一个创业团队,我们也一直在向往着改变世界,一直在努力用数据改变企业做决定的方式,同时帮助人们了解周围的环境。在TalkingData所处的大数据分析领域,目前对数据的理解和使用依然还有很高的门槛。灵动分析吹响了移动数据分析新时代的号角,我们希望它能为业界带来更多的积极变化,激发出更多的有益创新,和生态中的伙伴和战友们一起把客户服务提升到新的水平。


更多内容,请关注我的知乎专栏:【峰言峰语



0 0