北卡州立大学与中国人民大学签署校级合作协议

2018年7月3日上午,北卡罗来纳州立大学与中国人民大学正式签署校级合作协议,致力于专业数据人才的教育项目共建。

北卡罗来纳州立大学拥有深厚的统计分析人才教育积淀,同时也是分析软件SAS的诞生地,在专业数据人才的培养上,除了传统的理论学习,更加注重数据的实战训练。其首创的数据分析硕士项目(Master of Science in Analytics,简称MSA)被2014年《哈佛商业评论》评为全美“大数据”专业榜首,常年居于北美专业硕士就业率和毕业生平均薪资排名前列。

中国人民大学在统计学学科底蕴深厚,位列高校前茅,其为迎接大数据时代挑战而成立的统计与大数据研究院致力于构建世界一流的统计与数据学科,在学科前沿原创性研究与高水平学科交叉人才的培养上更具前瞻意识。

本次合作双方旨在推动数据人才教育,通过引入领先的专业数据人才学位项目,结合TDU提供的数据实训平台与数据实战行业指导等内容,共同推动国内专业数据人才的培养进程。

Markdown

Markdown

推广期,如何准确衡量渠道的质与量?

对于开发者而言,渠道推广是获客的重要一步。为了统计不同渠道的推广效果,渠道分析是开发者的必然选择。

Markdown

渠道虽然有免费和付费之分,但在推广期都会消耗开发者成本。由细分领域组成的免费长尾渠道,虽流量不可小觑,但耗费大量发包时间。而涉及到分层或买量的头部渠道,却是资本和时间双重成本的叠加。虽然开发者付出了时间与金钱,但并不意味着,此举就是有用功。

开发者无论接入第三方数据分析服务还是自行跑码统计,通过有效指标评估投放渠道质量,是优化渠道、控制成本的有效手段。作为是国内领先的第三方数据智能服务商,TalkingData App Analytics的渠道分析功能,可帮助开发者收集、处理、分析,形成客观的渠道数据报表。使开发者掌握各渠道表现,敏捷优化/改善推广方案,持续发现流量洼地降低成本。

Markdown

渠道分析功能图

如何使用渠道分析功能

App 开发时,集成TalkingData App Analytics SDK即可获得渠道分析功能,帮助开发者实时了解各渠道从用户获取再到参与留存、效果转化等诸多环节的数据表现。

Markdown

TalkingData App Analytics

渠道分析功能特点

1.全平台兼容

支持全部开发平台,无需开发者集成多个SDK,不增加包体负担,全渠道数据一览无余;

Markdown

2.数据客观性

①TalkingData是国内领先的第三方数据智能服务商,各渠道实时数据更客观;

②针对渠道带来用户生产的数据,拉长考察时间区间,更有利于对渠道质量甄别;


渠道分析demo演示

3.多维度节约成本

①无需开发成本,集成即用。数据服务稳定,免去开发者维护成本;

②推广渠道质与量双层优化,降低开发者发包时间、推广成本;

TalkingData App Analytics的渠道分析功能,使开发者以数据为依据,抛开个人喜好,把推广重点关注在真优质渠道,而不是局限于有声量的头部渠道和免费的长尾渠道。让开发者结合渠道数据有针对的调整和优化推广策略,助力开发者推广期准确衡量渠道质与量。

Markdown

简明数据科学 第三部分:假设检验

 

昨天的文章中,我们讨论了统计学习的关键概念——参数模型、训练与测试、方差与偏差等等,今天我们再来看一看机器学习的基石概念之一假设检验

Markdown

著名的物理学家爱德华·特勒曾经引用过:

“A fact is a simple statement that everyone believes. It is innocent, unless found guilty. A hypothesis is a novel suggestion that no one wants to believe. It is guilty, until found effective.”

假设检验的应用在数据科学中占主导地位,它是简化和结构的必备之选。就像犯罪小说的故事一样,基于数据的假设检验,将从一个新颖的建议引向一个有效的命题

概念

假设是指用有限的证据作出的想法,它是进一步调查分析的起点。该概念非常简单,但是在实际应用中很强大。在日常生活中,通常按照如下7个步骤进行:

  1. 做出假设;
  2. 初始状态设定;
  3. 确定替代的问题;
  4. 设置验收标准;
  5.  进行基于事实的测试;
  6. 评估结果。评估是否支持初始状态?确定结果不是偶然的?
  7. 达到以下结论之一:拒绝原来的位置以支持替代位置或拒绝原始位置。

Markdown

以一个故事来进一步解释假设检验的概念。霍尔马维克是冰岛西部的一个小镇,这个小镇有其独特之处是,它被称为巫术博物馆。即使现在,那里也有人声称是巫师。伊西尔德和甘道夫就是这样的人。

他们声称自己具有千里眼的超能力,能够透视任何物体,于是一些研究人员想要验证他们的能力,让他们玩一种叫做透视纸牌的游戏。

该游戏的规则如下:

  1. 伊西尔德和甘道夫随机从四副扑克牌中选择10张纸牌;
  2. 他们必须确认每张纸牌属于那副牌;
  3. 该测试每次重复10次。

在进行此次测试验证之前,已经对正常人进行了测试,得到的结论是正常人能够预测正确的平均次数在6次左右。这个就是本次假设检验的基础,而本次假设检验的目的是统计确定伊西尔德和甘道夫是否是巫师。

第一步:做出假设

不同种类的假设检验需要做出不同的假设。而假设与数据的分布、采样以及线性有关。一些常见的假设如下:

  • 分布: 每种数据都会遵循特定的分布,需要掌握数据中的规律。许多自然发生的数据点如股票市场数据、人体重量和高度、在酒吧喝酒的人的薪水等等都近似正态分布。正态分布只是意味着很多观测值都在中间位置,较少的观察值大于或小于中间值。中间值也称为中位数。
  • 采样: 假设为测试采样的数据是随机选择的,没有偏见。

对于上述透视纸牌游戏,以下假设是正确的:

  • 在透视卡牌游戏中,所选纸牌的分布将是正态分布的。这是真的,因为这些纸牌是随机选择的。随机选择纸牌意味着将被挑选的十张纸牌中的每一张都具有被选择用于测试的相同概率。
  • 在该问题中,纸牌没有偏见。

第二步:空假设

空假设是假设验证的初始情况,也就是当下的状态,是拒绝或者失败的立场,在整个假设验证的过程中处于需要验证和测试的位置。

对于上述纸牌游戏来说,空假设如下:

伊西尔德/甘道夫并没有千里眼的能力。

第三步:备用假设

备用假设和空假设正好是相反的。如果统计学获得的证据正好表明备选假设是有效的,那么空假设就是被拒绝的。

对于上述纸牌游戏,备用假设如下:

伊西尔德/甘道夫具有千里眼的能力。

第四步:设置验收标准

空假设和备用假设定义好之后,初始位置为空假设。现在需要设定一个阈值,我们知道一个普通人,即不是巫师的人会在10次中得到正确的六次。如果伊西尔德和甘道夫能够在一次测试中预测超过六张正确的纸牌,那么有更多的证据表明他们确实可能是巫师。有一种度量评估方法叫做t-统计,t-统计估计值远离备选假设越多越合理。

假设检验结果可能会出错。有四种可能的情况:

  1. 测试发现,伊西尔德和甘道夫具有千里眼能力,他们是名巫师;
  2. 测试发现,伊西尔德和甘道夫没有千里眼能力,他们不是巫师;
  3. 测试发现,伊西尔德和甘道夫具有千里眼能力,他们不是巫师;
  4. 测试发现,伊西尔德和甘道夫没有千里眼能力,他们是名巫师。
  5. 测试的结果可能显示结论1和结论2是正确的,结论3和结论4是无效的。

如果结论3属实,这样会导致空假设失效,属于一种误报,此类情况也称为Ⅰ型错误;

如果结论3无效,这样会是的空假设属实,属于一种错误的否定,此类情况称为Ⅱ型错误。

类型所有的统计验证,假设验证也必须处理不确定性,也就是必须处理概率,而概率并没有绝对的。

对于概率来说,需要设定概率层级,以便确定发生I型错误的机会,这个水平被称为显着性水平,使用α表示它。 α越低意味着测试越严格。相对较高的α意味着测试不是那么严格。 α的值是根据假设检验的性质设定的。典型值为0.001,0.05或0.1。

如果所观察到的结果仅仅是偶然的呢?如果这只是一个巧合呢?如果他们在测试进行的那一天刚好幸运呢?这种不确定性需要得到度量,假设检验有一个衡量这个不确定性的指标,p值是该度量。

p值表示为概率。这意味着它的值在0和1之间。p值是在假设为真的假设下偶然观察到的t统计量的概率。

对于透视纸牌游戏,决定如果伊西尔德可以正确猜测超过8张牌,那么备选假设是合理的。他可能确实是一位千里眼。 t统计量是8。

作为一名千里眼人是没有生命危险的。没有人处于危险之中。显着性水平设定为0.05。 α是0.05。

第五步:进行测试

通过重复十次的测试和验证,得到了一些结果。假设统计引擎最终得到如下的结果:

伊西尔德:

  • t-统计:8
  • P值:0.1

甘道夫:

  • t-统计:9
  • P值:0.01

第六步:评估结果

概率(p值)和显着性水平之间的比较产生以下结果:

对于伊西尔德来说:

  • t统计量为8,这意味着,他平均预测了八张牌,比正常人预测的要高。
  • p值是0.1,这意味着观察到的t统计数据归因于偶然的概率是10%。 p值很高。
  • 设定的显着性水平(α)是0.05,转化为5%。
  • p值大于设定的显着性水平,即10%> 5%。

第七步:得出结论

测试已结束,指标是已知的。谁是真正的巫师呢?

对于伊西尔德:p值大于设定的显着性水平(10%> 5%)。尽管平均而言,他已经预测了八张牌;从统计上,结论如下:

  • 伊西尔德的结论:没有实质证据反对空假设,空假设未被拒绝。

对于甘道夫:平均而言,他已经预测了九张牌。,p值低于设定的显着性水平(1%<5%);从统计上,结论如下:

  • 甘道夫的结论:有很好的证据反对空假设,空假设被拒绝,备选假设被接受。

最终,伊西尔德被否认,甘道夫很高兴。然而,伊西尔德也并不那个伤心,测试并没有确定他不是一位具有千里眼的巫师,空假设没有被验证是错误的,也没有证据表明备选假设是不成立的,这意味着没有足够的证据来确定空假设是无效的,在现实中,这样的情况普遍存在。

结语

假设检验是机器学习的基石概念之一,很多评估方法使用假设检验来评估模型的鲁棒性。在我们浏览本系列时,我们将深入探索其构造。

Markdown

简明数据科学 第二部分:统计学习的关键概念

在本系列的第一篇文章中,谈及了数据科学的关键概念和过程,在这篇文章中,会深入一点。首先,将定义什么是统计学习。然后,将深入到统计学习的关键概念,了解统计学习。相信我,很简单。

什么是统计学习

Markdown

根据维基百科,统计学习理论是从统计学和功能分析领域进行机器学习的框架。

机器学习是通过软件应用程序实现的统计学习技术的体现。

这在实践中意味着什么?统计学习是指使我们能够更好地理解数据的工具和技术。那么理解数据意味着什么?

在统计学习的背景下,有两种类型的数据: 可以直接控制功能的独立变量数据; 不能直接控制功能的因变量数据。

  • 无法控制的数据,即因变量需要预测或估计。
  • 更好的理解数据是通过独立变量来更多地了解因变量。例如下面的例子:

假设想根据分配给电视、广播和打印的广告的预算来衡量销售额。分配给电视,广播和打印的预算是可以控制的,但是无法控制的是他们将如何影响销售。于是想将无法控制的数据(销售额)表达为可以控制的数据(广告预算)的功能,揭开这种隐藏的关系。

统计学习则能够揭示隐藏的数据关系,不论是依赖的还是独立的数据之间的关系。

参数和模型

Markdown

运营管理中著名的商业模式之一是ITO模型,即输入-转化-输出(Input-Transformation-Output)模型,有一些输入,这些输入经历一些转化,然后创建出输出。

统计学习也适用于类似的概念,有数据输入,数据输入后经历转化,然后生成需要预测或估计的输出。

而上述的转化引擎部分称之为模型,一些估计输出的函数。

转化过程是数学相关的,将数据输入到特定的数学成分中以估计输出,这些数学成分称为参数

如下例:

决定某人收入的是什么?例如收入是由受教育程度和多年的经验决定的。那么估计收入的模型可能是这样的:

收入 = c + β0 受教育程度 + β1 经验

其中,β0和β1是表示收入函数中教育和经验的参数。而教育和经验是可控的变量,这些可控变量具有不同的含义,他们被称为独立变量,也称之为特征。收入是不可控变量,他们被称为目标

训练与测试(Training and Testing)

Markdown

当你准备异常考试的时候,都做些什么呢?研究、学习、消化知识点、做笔记、不断练习等。这些都是学习和准备未知测试的过程或者工具。

机器学习也使用类似的概念进行学习。数据一般是有限的,因此在使用数据时需要谨慎。模型的构建也需要进行验证,而验证的方法可以参考如下方式:

  1. 将数据集分割为两部分;
  2. 使用其中一部分作为训练数据,让模型从中进行学习,也就是说这部分数据对模型来说是可见的、已知的。这 部分数据集被称为训练数据
  3. 使用另一部分来测试模型,给予模型一部分未知的测试数据,来核查模型的性能。这部分数据称为测试数据

在竞争性考试中,如果准备充分,历史学习有效,那么考试中的表现一般也是令人满意的。同样的,在机器学习中,如果模型很好的学习了训练数据,那么在测试数据上也应该有良好的表现。

一般情况下,在机器学习中,一旦模型在测试数据集上进行测试,就会评估模型的性能。它是根据它估计的输出与实际值的接近程度来评估的。

Markdown

英国着名统计学家George Box曾经引用过:

“All models are wrong; some are useful.”

没有那个模型能够达到100%的准确度,所有的模型都有些错误,这些错误可以从两方面进行衡量

  • 偏差(Bias)
  • 方差(Variance)

下面使用类比来解释这两个维度:

Raj,是一个七岁的孩子,刚刚接触了乘法的概念。他已经掌握了1和2的乘法表格,接下来将挑战3的表格,他非常兴奋,开始了3的乘法的练习,他写下了如下的等式:

  • 3 x 1 = 4
  • 3 x 2 = 7
  • 3 x 3 = 10
  • 3 x 4 = 13
  • 3 x 5 = 16

Raj的同班同学Bob在同一条船上。他的书写结果看起来像这样:

  • 3 x 1 = 5
  • 3 x 2 = 9
  • 3 x 3 = 18
  • 3 x 4 = 24
  • 3 x 5 = 30

让我们从机器学习的角度来研究由Bob和Raj创建的乘法模型。

  • Raj的模型有一个无效的假设,他假设了乘法运算意味着需要在结果后面加1。这个假设引入了偏差误差。假设是一致的,即将1加到输出。这意味着Raj的模型低偏差
  • Raj的模型导致输出始终与实际相距1。这意味着他的模型具有低方差
  • Bob的模型输出结果毫无规律,他的模型输出与实际值偏差很大。没有一致的偏差模式。Bob的模型具有高偏差和高方差

上面的例子是对方差和偏差这一重要概念的粗略解释。

  • 偏差是模型不考虑数据中的所有信息,而持续学习导致错误的倾向。
  • 方差是模型不考虑实际数据情况,而持续进行随机性事物的程度。

偏差 – 方差权衡(Bias-Variance Trade-Off)

Markdown

在初接触数学的时候,每个人可能都会死记硬背一些概念、公式等等,这就是开始的时候,学习的方式。然而如此的方式将面临考试时的问题和背诵的问题不同。问题是数学中的广义概念,显然,在一些考试中,很难完成或者达到理想的分数。

机器学习也是同样的模式。如果模型对特定的数据集学习过多,并试图将该模型应用在未知的数据上,则可能具有很高的误差。从给定的数据集中学习太多称为过拟合。此种情况下,模型难以有效地推广应用于未知的数据。相反的,从给定的数据集中学习太少称为欠拟合。此种情况下,模型非常差,甚至无法从给定的数据中学习。

阿尔伯特·爱因斯坦简洁地概括了这个概念。他说:

“Everything should be made as simple as possible, but no simpler” *

机器学习解决问题的方式是不断的努力寻找到一个恰当的平衡点,创建一个不太复杂但是并不简单的、广义的、相对不准确但是有用的模型。

过拟合的模型显得过于复杂,它在训练数据上表现非常好,但是在测试数据上表现欠佳; 欠拟合的模型又过于简单,它无法在训练数据和测试数据上执行的让人满意; 一个良好的模型是在过拟合和欠拟合之间找到平衡,它表现良好,简单但是有用。

这种平衡行为被称为偏差 – 方差权衡。

结语

  1. 统计学习是复杂机器学习应用的基石。本文介绍统计学习的一些基本概念和基本概念。这篇文章的五大要点是:
  2. 统计学习揭示隐藏的数据关系,依赖和独立数据之间的关系;
  3. 模型是转换引擎,参数是实现转换的要素;
  4. 模型使用训练数据进行学习,使用测试数据进行评估;
  5. 所有模型都是错误的;有些是有用的;
  6. 偏差-方差权衡是一种平衡行为,以找到最佳模型、最佳点。

在本系列的后续文章中,将深入研究机器学习模型的具体内容。敬请期待……

简明数据科学 第一部分:原则与过程

2006年,英国数学家Clive Humbly和Tesco Clubcard的建筑师创造了“数据是新石油”这句话。原话如下:

Data is the new oil. It’s valuable, but if unrefined it cannot be used. It has to be changed into gas, plastic, chemicals, etc. to create a valuable entity that drives profitable activity; so, must data be broken down, analyzed for it to have value.

iPhone革命,移动经济的增长以及大数据技术的进步创造了一场完美风暴。2012年,HBR发表了一篇文章,将数据科学家放在了新的高度上。数据科学家:21世纪最性感的工作这篇文章将这种“信心人类”称为数据黑客、分析师、传播者和值得信赖的顾问的混合体

如今,几乎每个企业都在强调数据驱动。而机器学习技术的不断进步,正在帮助着企业完成这个目标。在网络上,机器学习相关的资料非常多,但是都太过的技术性并且充斥着大量的高等数学公式等等,让大多数软件工程师难以理解。因此计划编写一系列的文章,使用更加易于理解的方式简化数据科学。

在本文中,将首先介绍数据科学中的基本原理,一般过程和问题类型,对数据科学有一个基本的了解。

数据科学是一个多学科领域。它是以下领域之间的交集:

  • 商业知识
  • 统计学习或称机器学习
  • 计算机编程

本系列文章的重点将是简化数据科学中机器学习方面,而在本文中将首先介绍数据科学中的原理、一般过程和问题的类型等。

关键原则(Key Principles)

Markdown

数据是战略资产:这个概念是一种组织思维。问题:“我们是否使用了我们正在收集和存储的所有数据资产?我们能够从中提取有意义的见解吗?”,相信这些问题的答案是:“没有”。基于云科技的公司本质上都是数据驱动的,将数据视为战略资产是他们的灵魂。然而这种观念对于大多数组织来说都是无效的。

系统的知识提取过程:需要有一个有条不紊的过程来提取数据中的隐藏的见解。这个过程应该有明确的阶段和明确的可交付成果。跨行业数据挖掘标准过程(CRISP-DM)就是这样一个过程。

沉浸在数据中:组织需要投资于对数据充满热情的人。将数据转化为洞察力不是炼金术,而且也没有炼金术士
。他们需要了解数据价值的传播者,并且需要具有数据素养和创造力的传道人。更加需要能够连接数据,技术和业务的人。

拥抱不确定性:数据科学并不是一颗银弹,也不是一颗水晶球。像报告和关键绩效指标一样,它是一个决策的辅助者。数据科学是一个工具但是并不仅限于此,而且数据科学也不是一个绝对的科学,它是一个概率的领域,管理者和决策者需要接受这个事实。他们需要在决策过程中体现出量化的不确定性。如果组织文化采用快速学习失败的方法,这种不确定性只能根深蒂固。只有组织选择一种实验文化,它才会兴旺发达。

BAB(Business-Analytics-Business)原则:这是最重要的原则。许多数据科学文献的重点是模型和算法,而这些大多都没有实际的商业实践背景。业务-分析-业务(BAB)是强调模型和算法在业务部分应用的原则。把它们放在商业环境中是至关重要的,定义业务问题,使用分析来解决该业务问题,并将输出集成到业务流程中。

过程(Process)

Markdown

从上述原则#2中可以看到,数据科学的过程对于实现数据科学至关重要,一个典型的数据科学项目可分为如下几个阶段:

1. 定义业务问题

阿尔伯特·爱因斯坦曾经引用过“凡事尽可能简洁,但不能太过简单”,而这句话也正是定义业务问题的核心。问题的表述需要事情的发展历程和所在场景,需要建立明确的成功标准。几乎在所有的企业中,业务团队总是繁忙无比,但是这并不意味着他们没有需要解决的挑战。头脑风暴会议、研讨会和访谈可以帮助揭开任何问题的面纱并提出可能的解决方案或者假设。而对于如何定义业务问题?可参考下例:

一家电信公司由于其客户群减少而导致其收入同比下降。面对这种情况,业务问题可能被定义为:

该公司需要通过瞄准新的细分市场和减少客户流失来扩大客户群。

2. 分解为机器学习任务

业务问题一旦定义好之后,就应该分解为机器学习任务。例如上述的示例,如果该公司需要通过瞄准新的细分市场和减少客户流失来扩大客户群。该如何分解该业务问题为机器学习任务呢?下面是一种分解的示例:

  • 将顾客的流失减少x%。
  • 为有针对性的营销确定新的客户群。

3. 数据准备

一旦确定了业务问题并将其分解为机器学习问题,就需要开始深入研究数据了。对于数据的理解应该明确的针对当前问题,因为当前问题能够帮助制定合适的数据分析策略,并且要注意的是数据的来源、数据的质量以及数据的偏差等。

4. 探索性数据分析

“当宇航员进入宇宙时,他们是不知道宇宙中有什么的。”同样的,数据科学家在开始对数据进行分析时,对于数据中隐含的特征等也都是未知数,他们需要穿过数据的表象去探求和开发新的数据涵义。探索性数据分析(Exploratory data analysis,EDA)是一项令人兴奋的任务,可以更好地理解数据,调查数据中的细微差别,发现隐藏模式,开发新功能并制定建模策略。

5. 模型化

探索性数据分析之后,将进入建模阶段。这个阶段中,会根据特定的机器学习问题,选择不同的算法,而机器学习算法有很多,耳熟能详的有回归、决策树、随机森林等等。

6. 部署与评估

最后,部署开发的模型,并且建立持续的检测机制,观察他们在现实世界中的变现并据此进行校准和优化。

机器学习问题类型

Markdown

一般情况下,机器学习有两种类型:

监督学习

监督学习是一种机器学习任务,其中有一个明确的目标。从概念上讲,建模者将监督机器学习模型以实现特定目标。监督学习可以进一步分为两类:

回归

回归是机器学习任务中的主力,被用来估计或预测一个数值变量。例如下面两个问题:

  • 下季度的潜在收入估计是多少?
  • 明年我可以关闭多少项交易?

分类

顾名思义,分类模型是将某些东西进行分类,用在离散型变量。分类模型经常用于所有类型的应用程序。分类模型的几个例子是:

  • 垃圾邮件过滤是分类模型的流行实现。在这里,每个传入的电子邮件根据特定的特征被分类为垃圾邮件或非垃圾邮件。
  • 流失预测是分类模型的另一个重要应用。在电信公司广泛使用的流失模型来分类给定的客户是否会流失(即停止使用服务)。

无监督学习

无监督学习是一类没有目标的机器学习任务。由于无监督学习没有任何明确的目标,他们所产生的结果可能有时难以解释。有很多类型的无监督学习任务。几个关键的是:

  • 聚类(Clustering):聚类是将类似的东西组合在一起的过程。客户细分使用聚类方法。
  • 关联(Association):关联是一种查找频繁匹配的产品的方法。零售市场分析使用关联法将产品捆绑在一起。
  • 链接预测(Link Prediction):链接预测用于查找数据项之间的连接。 Facebook,亚马逊和Netflix采用的推荐引擎大量使用链接预测算法来分别向我们推荐朋友,物品和电影。
  • 数据简化(Data Reduction):数据简化方法用于简化从很多特征到几个特征的数据集。它需要一个具有许多属性的大型数据集,并找到用较少属性来表达它们的方法。

机器学习任务到模型到算法

一旦将业务问题分解为机器学习任务,一个或多个算法就可以解决给定的机器学习任务。通常,模型是在多种算法上进行训练的,选择提供最佳结果的算法或一组算法进行部署。

Azure机器学习有超过30种预建算法可用于训练机器学习模型。

Markdown

结语

数据科学是一个广泛且令人兴奋的领域,而且是一门艺术和科学。这篇文章仅仅是冰山一角。如果“不知道”是什么,那么“如何”将是徒劳的。在随后的文章中,我们将探讨机器学习的“方式方法”。敬请期待!

Markdown

TalkingData-2018年4月移动游戏Benchmark

2018年4月移动游戏Benchmark解读:

付费率:2018年4月,移动游戏用户的付费率在Android和iOS平台处于平稳状态,其中,动作类移动游戏的付费率在Android平台环比增长1.3%,在iOS平台则环比持平;

用户活跃度:2018年4月,大多数类型移动游戏的用户活跃度在Android和iOS平台保持平稳,其中,iOS平台策略类移动游戏的周活跃率环比增长8.0%,月活跃率则环比下降2.9%;

用户留存率:2018年4月,Android和iOS平台移动游戏用户的一日玩家比例整体与上月持平,次日留存率和7日留存率出现微幅波动。其中,iOS平台模拟类移动游戏的一日玩家比例相比上月有所增长,其次日留存率和7日留存率则分别环比下降1.0%和1.8%;

使用时长&次数:2018年4月,大多数类型移动游戏用户的日均游戏次数和平均每次游戏时长环比微降。其中,棋牌类移动游戏在Android平台的日均游戏次数与上月持平,平均每次游戏时长环比下降2.5%。

MarkdownMarkdownMarkdownMarkdownMarkdownMarkdownMarkdownMarkdownMarkdown

移动观象台

更多移动互联网的行业数据和报告请登录TalkingData移动观象台 http://mi.talkingdata.com/index.html

Markdown

Markdown

关于地理空间智能(Geospatial AI) 或 Geo.AI 你知多少?

Markdown

人工智能(Artificial Intelligence,AI)已经成为新技术革命下一阶段的热词,也成为未来产业的驱动力量。使用智能算法,数据分类和智能预测、分析,AI在很多领域将有一系列的工具来帮助解决问题。

将AI用于GIS这一具体的领域的分析、方法和解决方案,就叫地理空间智能(Geospatial AI), 或者简称为 Geo.AI.

地理空间智能(Geospatial AI)可以说是基于地理信息技术基础软件上面的机器学习。

地理空间智能(Geospatial AI)如何工作?

在简单的智能手机应用的帮助下,人们可以对周围环境条件进行实时的的反馈,如交通状况,高峰期、经历、评分等等。这些数据然后被收集、排序、分析,增强准确性和精度,因为成千上万的用户对数据库做出了贡献。

使用地理位置的这些方法不仅仅用于填补信息的空白,也可以用于对特定地理区域的高效解决方案决策提供帮助。比如,可以预测城市中哪个区域将会面临极度交通拥堵,采取何种疏导措施,车辆如何重新选择路线等等。

这也将使系统知道问题严重到何种程度,以及对问题进行定位。

地理空间智能(Geospatial AI)的不同应用

交通拥堵只是个例子,这是我们每天都要面对的一个问题。Geo.AI 可以用于很多的领域,包括很多使用位置和GIS的应用场合。出行共享公司、物流、农业、调查以及基础设施都是很好的应用的例子。

出行共享公司如Uber, Lyft等,可以从客户得到通用的反馈,处理数据从而发现车辆和司机的密度分布。

在物流和供应链,Geo.AI 可以连接运力和货物,填补差异,得到更精确的位置信息来安排物流,从而节省时间和成本。

建立在深度学习的项目能够同步操作在云上的多个主机,管理大量的数据存储和内存,用于解决这些问题。但是,几年前这些自动化的深度学习还被认为是不可能的,要么受限于成本,要么由于技术实现上的限制。同样地,Geo.AI能力随着被产业界更广泛地采用而增强,通过将地理和位置信息集成进来,AI将能够服务于更多的目的。

总之,在商业应用方面, 地理空间智能(Geospatial AI)将持续地增强规划、资源分配和决策支持能力,预测需求和供应,确认其最低、最高的边界,倍增供应链的效率,优化服务的提供。地理空间智能(Geospatial AI)的未来简直是无穷无尽。

Markdown

TalkingData联合MIT探索数据共享新范式

Markdown

近日,TalkingData已与麻省理工学院连接科学研究所达成合作,作为唯一一家中国合作企业参与前瞻性框架OPAL的技术研发,共同探索保护数据安全前提下的数据共享新范式。

麻省理工学院连接科学研究所(MIT Connection Science),致力于通过跨学科的研究,提供对人类行为的突破性洞察并推动改善生活的创新科技,为以科技为中介的人际网络带来变革。OPAL(Open Algorithms,开放算法)理念由麻省理工学院教授阿莱克斯·彭特兰(Alex Pentland)首先提出。彭特兰教授是美国国家科学院院士、麻省理工学院连接科学研究所与人类动力学实验室主任,被誉为“可穿戴设备之父”,在人脸识别、GPS定位技术等领域也被广泛地认为是领导者。

现今,世界已全面走向数字化。人类行为数据能为改善社会和促进商业带来裨益,而数据共享可以将这一价值最大化,有效助力构建数据驱动的智慧社会。但如何能在保护数据安全和不滥用个人信息的前提下,释放数据的潜力和价值,是受到全世界关注的课题,也是TalkingData长期致力的方向。

OPAL框架则针对这一课题提出了极具前瞻性的解决方案。该框架摒弃了以往先转移数据再进行处理和分析的做法,改为利用分布式技术进行数据存储和运算,并在流程中都保持数据的加密状态,再将经过验证的算法前置到数据端,不移动数据而只提供安全的分析结果,实现在从数据中获得有价值的洞察的同时,有效保证数据安全与流程合规。

未来,OPAL还将继续探索运用机器学习技术提升精确度、通过去中心化存储和动态算法增强个人信息安全、借助区块链和虚拟货币等技术赋能数据市场等项目,既保障个人信息安全与企业数据资产安全,也为组织间的数据共享打造更为安全可信的环境。

TalkingData非常重视数据安全,也一直倡导培育良性发展的数据共享生态,与OPAL框架所持理念非常契合。目前,TalkingData已经积极参与到OPAL框架中,与麻省理工、英国帝国理工、世界银行、世界经济论坛、微软、埃森哲等世界知名组织与企业,共同对OPAL框架进行研发和优化,并取得了阶段性成果。随着更多合作企业及机构地加入和共同探索实践,TalkingData相信OPAL能为数据共享带来全新激励机制,为全球数据市场带来跨越式发展。

成立近7年来,TalkingData不仅专注于数据智能应用的研发和实践积累,同时也在积极推动大数据行业的技术演进。目前,TalkingData除了组建专业数据科学团队、设立前沿技术实验室并获得多项国家专利之外,还与多家国际顶尖学府与研究机构展开合作,将像OPAL这样的国际前沿技术引入高速发展的中国市场,与国内丰富的应用场景相结合,驱动新技术落地与行业进步。

Markdown

基于Spark、NoSQL的实时数据处理实践(下)

本文基于TalkingData 张学敏 在公司内部KOL的分享主题《基于Spark、NoSQL实时数据处理实践》的整理,同时也在DTCC大会上做了同主题的分享。

主要介绍了项目的技术选型、技术架构,重点介绍下项目面临的挑战和解决办法,还介绍了面对多维度、多值、多版本等业务场景时,使用Bitmap与HBase特性解决问题方法。

共分为上下两篇,本次发布下篇,上篇请点击查看

四、挑战和方案

Markdown

整体服务的稳定性取决于各个组件,大的原则就是故障告警,然后人工介入进行处理。其中Kafka相对还是比较稳定的,如果出了问题,我们可以切换到业务线的集群。无论是离线还是实时计算,资源的分配和管控都是个大难题。我们在17年将Yarn跑在了Docker上,这样可以按团队或者业务优先级分配集群资源,如果Yarn出了不可修复的故障,我们可以基于容器快速重建集群。如前面说到,ScyllaDB相对问题还是比较多的,所以我们所有使用到ScyllaDB地方都有自动降级到HBase的能力。HBase目前是一个集群,没做集群级别的热备,但我们将所有表的建表语句及HFile文件都做了备份,如果HBase出了不可恢复的故障,或者恢复时间会比较长的话,我们可以通过建表语句以及HFile文件快速的重建集群。

Markdown

容量预估也是件令人头疼的事,公司是按月采购服务器,申请量大了会受到大佬们的挑战也不会给批,申请量小了,服务就会受到影响。除了物理机资源受限外,像Kafka Tpoic的分区,HBase、ScyllaDB表的分区以及Spark CPU、内存等也需要考虑容量预估,因为数据流量是不确定的,如果前期设置的值都很大,而流量很小,就会造成物理资源的浪费,如果前期设置的值比较小,就有可能需要在流量变高时做调大的变更。所以,总体来讲, 我们的整体原则就是根据以往数据,凭借历史经验进行预估、设置。

Markdown

相信数据正确性、一致性是流处理中最棘手的问题之一了,当然难易程度也跟业务需求有关系,有些业务可以容忍数据丢失或者数据重复,这样的就相对好处理些,比较难的是数据要求不丢其不重复,即精确一次exactly-once,更难的是有些业务还要使用Window等函数进行复杂运算,此时要做到精确一次需要的成本可能会非常大,所以我觉得是没有银弹,需要根据实际业务及成本情况做取舍、定方案。

我们的业务场景相对比较简单,都只是对数据进行解析、转换、补充处理,然后入库。我们可以使用HBase version的特性去重,保证数据没有重复。怎么做到的呢?我们会对每条事件数据抽象出各种实体,每个实体都有唯一ID,然后我们用数据中的事件时间作为HBase version的值,这样,即使是同一条数据被重复处理,结果写入HBase多次,但由于都是同一ID下同样数据的同一version,所以对于HBase来讲还是同一条数据。

这样的话,数据计算阶段只需要保证至少处理数据一次即可。而无论是使用Spark的 receiver还是Direct消费模式都不难做到至少一次处理数据,receiver模式相对成本会高些,另外他的offset是通过Zookeeper管理,可能会因为两者之间的交互不能及时响应等情况而造成数据不一致。还有就是,他的内存问题会比较严重,因为他接收数据和处理数据是分开的,如果处理速度跟不上,就很容易出现数据淤积导致内存问题,所以建议使用direct模式,该模式是直接把kafka的partition映射到RDD里的partition,只有到了action才会去取数据,同时处理数据。

那么这种模式怎么保证数据至少被消费一次呢?checkpoint机制。checkpoint还是非常高效的,没有涉及到实际数据的存储,一般只有几十k大小,主要存储的是Kafka的Offset等信息。前面说到Spark Streaming是微批处理数据,他每个批次的大小是按时间来定的,比如1s、10s或者其他值,每个批次对应Spark Streaming的一个Job,在Job开始、结束异常等情况下都会触发checkpoint事件,如果有问题会根据checkpoint数据再重新执行Job。另外,我们也会周期性的探测并记录kafka offset位置与时间的关系,以及Streaming处理的offset位置和时间的关系,一方面是为了监控数据有没淤积,另一方面,即使checkpoint不能起作用的时候,也可以通过offset与时间的关系,推算出问题时间点offset的位置。

另外,官方也有关于exactly-once的方案,大的思路就是让批次操作幂等。具体做法,比如可以针对每个批次的partation数据产生一个UniqueID,只有当整个UniqueID相关数据都被完全计算才算成功,否则进行回滚。如果执行到重复的UniqueID,直接跳过该批次。 Markdown

在我们的项目中,影响Spark Streaming性能稳定性主要有三个方面。前面提到,我们Yarn是运行在Docker上的,另外,我们的计算(Yarn on Docker)和存储(HDFS的DataNode)是公用物理机资源的,因为Docker宿主盘如果挂载多盘,即与DataNode公用盘的话,管理成本会比较高,所以前期我们是挂载到系统盘的,大概600G左右。而Spark shuffle、作业日志等也会写盘,一些情况下会将盘写满,导致docker实例或者物理机故障,从而影响作业性能。我们现在的方案是,为Docker宿主盘采购了1T的SSD盘,一个是可以缓解该问题,一个是提高shffle读写性能。

第二个是慢节点问题,引发原因可能是数据不均衡,也有可能是该节点负责较高或者其他原因。可用的解决方案有,开启推测执行就,需要注意的是如果是非幂等操作,不可以使用,会引起不一致问题。如果是数据不均衡引起,可以将分区个数调大,一定程度上可以缓解。如果数据不均衡是数据key及分区分布算法引起,需要根据数据情况调整或者重写分区算法。针对慢节点问题,还也可以尝试使用spark的reblance算子,但这样会导致每批次整体时间都变长。

第三个问题是数据量突增,比如应用故障恢复后需要追赶数据,或者突然有了新的流量高峰等一些原因会导致Spark处理淤积,甚至故障,解决方案是使用Spark的控量及背压功能。Spark 可以通过参数配置每个批次每个partition消费的数据量,Direct模式使用saprk.streaming.kafka.maxRatePerPartition,Rceiver模式使用spark.streaming.receiver.maxRat。但这是个静态值,而数据流量是动态的,有时低有时高。如果这个值我们设置的高了,依然可能会引起计算延迟(数据不能在批次间隔时间内处理完),如果设置低了,会导致计算资源浪费,并且数据可能会在Kafka侧淤积。背压机制相对会灵活些,可使用spark.streaming.backpressure.enable配置控制是否开启,他会根据上一批次数据处理的情况确定下一批次数据的摄入量。但会有个特殊情况,作业启动后的第一个批次没有参考数据,Spark提供了另一个参数spark.streaming.backpressure.initialRate来控制背压第一次处理的数据量,但需要注意的是,Spark低版本时候这个参数只在receiver模式起作用。Direct模式就需要结合控量功能使用,比如可以设置控量值是“最优量”(计算批次内数据所用时间尽可能的接近但又一直低于批次调度间隔时间)的1到2倍,这样第一批次摄入的数据量是saprk.streaming.kafka.maxRatePerPartition的值,紧接着几批会因为第一批次处理延迟而依旧采用控量值为摄入量,直到第一个批次运算完,后续批次才会触发背压机制自动优化摄入量,但最大上限还是saprk.streaming.kafka.maxRatePerPartition的值。

虽然,我们期望流式处理是7*24模式运行的,但有时候也有需要去停止应用,比如,期间某个组件故障,或者是需要升级,或者需要变更数据处理逻辑。如果我们强制杀掉应用程序,很大概率会引起上边所说的不一致的问题,所以需要考虑优雅停止的方案。所谓优雅停止,也就是能够完整的执行完一个批次job,然后停止。

有两种方式,一种是向应用Driver发送Sigterm信号,一种是通过事件触发。第一种需要先设置stopGracefull 为true,然后找到drive所在的节点,登陆到节点上,执行kill命令,注意,一般使用流式处理时候都会设置应用重试提交次数,如果是多次,就需要要多次进行如上操作。并且后续每次停止都需要如此操作,所以相对比较麻烦。

第二种相对简单些,大的思路是定义触发事件,这个可行的方式比较多,比如使用标识文件,间隔去检测文件是否存在,还可以使用socket监听,或者使用restfull服务都可以,然后在需要的时候触发事件,注意,事件触发后一定要在独立线程调用ssc.stop,否则会产生死锁情况。Stop其中第一个true的含义是停止关联的SparkContext,第二个true,就是确定要执行gracefull stop。

下边是其他一些建议设置或者需要留意的参数,第一个参数是消费Kafka数据连接重试次数,在负责较高或者一些其他情况下,Kafka parttion会出现Lead不存在的异常,但大多时候有会很快恢复,默认是1,建议调高。第二、三的参数需要配合使用,第二个就是前面刚说的引用重试提交次数,默认是1、根据实际情况建议调高,但yarn有个限制,需要对应考虑调高。如果作业长时间运行,无论配置多大都会在某一时间点达到,所以第三个参数是Spark提供的让重试计数重置为0的时间间隔。第四个参数是应用程序可以容忍executor失败的最大数量,默认值是executor数量的2倍,也建议调高,与应用失败次数类似,最后一个是控制executor计数重置的时间间隔。当然,优化相关参数还有很多。 Markdown前面说HBase劣势时候提到他的维护成本较高,其中主要的就是这三个方面,一个是major compact,前面提到HBase是使用LSM模型,写数据是先写内存,然后刷写到磁盘,另一个就是HDFS不支持随机写入,所以HBase对数据的修改和删除都是对数据做标志,然后写入库,并不是真正的修改活删除原数据。这样的数据一直存在的话,一个是会影响查询性能,一个是存在无用存储,HBase的Major compact就是为了清理这些数据,当然也还会清理其他数据,比如如果设置了TTL的话,到期的数据也是在Major compact时候清理,还有就是历史版本数据,比如我们设置保留一个版本,那除了最新版本外的数据都会在执行Major compact的时候被清理。清理的时候就需要加载所有数据,所以会产生很大的磁盘、网络IO,一定程度上就会影响HBase的读写,甚至会引发客户端阻塞。我们的应对方案是,关闭compact自动执行,并调高触发上限,就是不让HBase自己控制Major compact的执行。我们还做了个工具,可以指定表、每个列族最小执行Major compact的文件个数,每个rs每次处理region个数等维度在集群相对空闲时间执行Major compact,并根据期望执行的时间调整以上维度参数控制整体执行时间。

与compact相关的还有个叫Minor compact,前面说到,内存满了后会刷写磁盘,那么每次刷写磁盘都会产生新的文件,时间久了就可能会有很多小文件,HDFS的元数据就会变的很多,HDFS元数据在内存中管理,即使不会到NameNode内存大小瓶颈,但也会影响性能,所以Minor就是将这些小文件进行合并。

第二个可能会影响性能的就是region split,特别是存在数据热点时候,如果配置的region最大存储值又比较小,可能会产生递归分裂情况,就是刚分裂完的region还没完成正式上线,发现又需要做分裂,这样region就会长时间无法对外提供服务,影响HBase的使用,我们的应对方案是使用预分区建表,并根据实际数据情况设置split keys以及region存储最大值。

第三个就是MemStore flush,HBase的很多调优大多都是围绕内存,特别是在大量写的场景下,flush会严重影响HBase的性能,甚至引发故障,这个也没有银弹,需要大家根据实际数写入情况和物理机内存大小进行调优,调优参考的东西就是各种监控指标,比如flush queue大小、频次,磁盘、网络IO等,所以HBase的mectric监控尤其重要。

Markdown

HBase配置相关的建议也都是跟compact 、flush相关的,前两个分别是控制Major compact和Flush线程个数的,需要根据物理CPU和实际使用情况调整。第三个是控制HBase自动执行全局flush的周期时长的参数,默认是1个小时,建议设置为0关闭。第四个是控制HBase触发执行Flush的条件,就是单个region的下所有MemStore的大小的阈值。如果达到该值,就会准备对该region执行flush。第五个参数是当region的memstore达到多少倍时阻塞客户端的写入操作,目的是防止引发RegionServer OOM。

因为一个region下有可能有多个MemStore,即表有很多列族,而当执行flush时,有可能有些MemStore数据量占比很小,比如k级别,刷写的话也不会释放很多内存,却会产生很多小文件,这也是官方建议大家设计表时列族不要太多的原因,也是前边建议第二个参数设置为0的原因。而第六个参数,就可以控制region执行flush时MemStore的最小值,也就是小于这个值的MemStore不执行flush,具体值需要参考刷写的HFile的大小及实际列族个数和写入量调整。

HBase低版本时候读写缓存都使用堆内内存,所以需要根据业务场景配置读写缓存的占比,如果是读多写少场景,可以加大读缓存占比,反之,调高写缓存占比。但两者加和不能超过整个堆的80%。

第9个参数也是为了防止OOM的,括号里的是老版本的叫法,需要注意的是,在新老版本HBase中有不同的含义,假设配置的值是0.3,在老的版本中含义是,当RegionServer所有MemStore占用内存超过Heap的30%时会选择一些占用内存比较大的MemStore阻塞写并进行Flush;在新的版本中的含义是,当占用内存超过hbase.regionserver.global.memstore.size的30%时会选择一些占用内存比较大的MemStore阻塞写并进行Flush。这个差别还是比较大的,我们开始是按照老版本含义去设置,发现flush特别频繁,并且Hfile特别小。然后查官方文档才发现这个不同,这个大家一定要注意下,特别是使用过老版本HBase的同学。

Markdown

前面提到,我们有面向实体,多维度、多值、多版本存储、查询数据的需求,那我们在使用HBase存储上是怎么解决的呢?前面说HBase也有表的概念,所以,我们将不同实体的数据存放在不同的表中。还依上边说过的数据举例,数据中有imei和wifi两个维度,我们用HBase 的Column Family来区分。其中wifi维度有wifi1、wifi2两个值,我们将两个值做为HBase的列名,其中共涉及到5个时间戳,将他们做为HBase的version,为了节省空间和后边方便使用bitmap,我们将时间戳转换成了相对时间,以2016年一月一号,0时0分为起点,分钟为间隔。其中HBase的列值我们未进行赋值。

Markdown

前面提到,业务有在低成本提取某个实体历史所有信息的需求,如果查询时间窗口很大或者数据很密集等原因很容易会造成服务OOM。由于我们数据中的设备硬件信息、ID信息几乎是不变的,另外行为轨迹也比较固定,所以位置信息、wifi信息重合度也会比较高,所以,我们使用bitmap对数据进行了聚集。如图所以,我们通过离线计算将HBase中的数据进行转换,假如wifi1是我在公司连接的wifi,那么一天时间我都会使用同一个wifi,但可能数据会上报很多条,这样的话,以wifi1作为bitmap的标识key,wifi被捕获的相对时间1,2,3作为bitmap的位值,就会大大节省存储空间。算完后,再将数据转载进HBase共服务使用,表的schema和前边大体一样,只是version不在特殊赋值,并将bitmap转换为字节数组存为列值。

Markdown

前面提到,由于docker目前宿主盘使用一个,所以我们期望后期可以调整为多块盘。另外,由于不同项目对资源的需求不同,比如图计算需要较大内存的executor,所以后期会在生产存在多版本的image,目前平台没法进行多版本的管理。

虽然Spark Streaming UI上有一些监控信息,但有时候还是需要查看日志,或者查看JVM相关的监控信息,目前我们正在进行GraphiteSink监控指标梳理及数据接入工作。最后一个是关于HBase的,高版本的HBase 有region级别的replica,由于我们之前使用HBase场景都是离线计算装载数据,所以没法使用该功能,这个项目是实时写入,该功能可以提高HBase的可用性,所以后续我们会进行该功能的测试、上线的工作。

重磅!TalkingData2018微信小程序洞察报告-附行业生态图谱!

自2017年1月9日小程序正式上线后,微信不断的开放平台能力,极有耐心地在为小程序逐步加温。在争议与关注中,小程序在2018年年初做到了日活1.7亿、月活4.3亿,参与开发者100多万。一个转折点是2017年12月,以“跳一跳”为代表的微信小游戏让人们认识到了小程序的流量潜力,在微信的流量红利下,小程序生态发展迅速,成为开发者们中炙手可热的新风口。TalkingData保守预测,2018年小程序数量将突破250w,数量超越AppStore应用总和。

近期,TalkingData产品副总裁闫辉受邀参加虎嗅虎跑团“小程序·新流量·大商机”深度分享会,闫辉从微观的数据角度阐述了TalkingData对小程序的洞察。在2018年,小程序又将迎来怎样的发展?TalkingData推出《场景+链接,数据视角下的小程序浪潮》即2018微信小程序洞察报告,为您带来小程序行业的整体梳理。

本文仅为报告精简版

关注TalkingData公众号回复“小程序报告

即可获取2018小程序洞察报告高清完整版

完整版报告目录如下

>>>>

行业人口红利消失,硬件市场新增空间有限

截至2018年一季度,中国移动智能终端规模已达14.5亿,中国市场内平均计算已是人手一台智能设备。中国移动智能终端设备规模季度增速持续放缓,自2016年第二季度起,移动智能终端规模增速连续8个季度低于2%。自2009年3G通讯技术正式商用起,中国移动互联网市场经过近十年的发展,移动智能终端规模已接近市场天花板。

>>>>

主流行业增长乏力,移动应用面临增长困境

2017年,通讯社交、视频、游戏等主流行业应用活跃用户规模增长乏力,行业应用活跃率出现不同程度下降。而移动智能终端用户平均安装与平均每日打开应用款数已连续两年出现下滑,设备一个屏幕上的应用已可基本满足日常使用。除了硬件市场外,移动智能设备软件市场也面临增长困境,存量时代移动应用对于用户的争夺更加激烈。

>>>>

头部应用把持流量,用户对新应用兴趣降低

在通讯社交、网络购物行业应用中,TOP5应用覆盖到了80%的行业用户,头部应用凭借高覆盖率攫取了绝大部分的用户流量。2017年,TOP200应用的更新款数明显减少。成熟应用更多地占据了移动智能终端的存储空间,新生应用进入TOP榜单的难度加大,用户对于新应用的兴趣在降低。

>>>>

链接场景,小程序完善微信公众平台生态

作为微信公众平台的组成部分,小程序是服务号、订阅号的功能延伸。围绕微信的社交关系链,三者将微信上的“人-人”关系,拓展为“人-资讯”、“人-服务”、“人-场景”,共同打造“信息传播-服务触达-场景链接”这一微信公众平台生态。

相比于服务号,小程序能够便捷的将用户与服务场景相链接,微信公众平台生态得以完善。

>>>>

小游戏刺激用户规模增长用户习惯得以培养

小程序在2017年整体处于用户培育期,开发者和用户都在探索小程序产品定位,公众号的关联是刺激小程序用户规模增长的最有效手段。2017年12月末发布的小游戏彻底引爆了小程序用户增长,疯狂的社交传播使得小程序活跃用户规模在2018年一季度突破了4亿,也让开发者对于小程序的传播能力有了直接体验。

>>>>

第三方参与者入场,小程序生态迅速成型

自小程序发布以来,第三方开发者加速入场,小程序开发、小程序商店、开发服务平台、数据统计平台等新增市场迅速形成规模。而传统的移动应用运营、基础云平台、媒体、投资机构也将移动应用市场经验应用到小程序市场,小程序行业生态在一年之内就已初步成型。

>>>>

流量红利兑现,头部小程序向游戏类别集中

小程序发布后,工具类小程序是初期开发者最主要的尝试领域,2017年7月TOP100小程序中有31款属于工具类。而在2017年末发布后,小游戏凭借更为直接的社交传播转化,迅速兑现微信用户红利,成为了头部小程序中最主要的类别。2018年3月TOP100小程序中有34款属于小游戏,预计未来小程序将极大的冲击休闲类游戏应用市场。

>>>>

用完即走,小程序用户日均使用时长7.5分钟

小程序定位在轻量级应用,微信官方鼓励用户“用完即走”,而小程序的用户日均使用时长也反映了这一特点。近半年来,小程序用户整体日均使用时长保持在7.5分钟左右,工具类小程序在小程序类型中平均日均使用时长最短。用户在使用微信时,平均有1/12的时间在使用小程序。

>>>>

发现栏已不再是微信小程序的流量主入口

随着微信对小程序入口场景的不断完善,小程序的用户访问流量已从发现类下的小程序主入口、附近小程序列表,逐渐的向公众号、使用记录类别迁移。相比于1月份数据,4月份附近小程序列表场景访问流量占比下降了19.3%。

>>>>

TalkingData预测2018年微信小程序未来四大发展趋势

  • 小程序数量将超越AppStore应用总数
  • 小程序用户规模突破7亿
  • 用户平均使用时长出现下降
  • 小程序卡券营销平台迎来机会

关注TalkingData公众号回复“小程序报告

即可获取2018小程序洞察报告高清完整版