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

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

什么是统计学习

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小程序洞察报告高清完整版

券商APP用户洞察报告

前言

随着智能手机的普及,证券行业用户各类产品使用场景也由PC向APP迁移。券商纷纷推出APP平台,导致市场由“蓝海”变为“红海”。证券业互联网营销重心也由“增长”转变为“运营”,粗放式的“圈粉丝、圈用户”模式向“重质量、重回报”的模式转变。许多券商APP已聚合多种功能,成为基本满足用户使用需求的工具平台。但在深挖用户需求、解决痛点,乃至引导用户使用产品的服务用户层面,APP运营工作还需要做出更多努力。

大数据、人工智能等概念纷至沓来,逐渐落地,用户数据也随之极大丰富,以往“交易、理财产品销售数据 + CRM系统”的数据应用模式已经不再适用,APP用户交互数据、设备信息、关联应用关系、地理信息等新类型数据的规模和价值都不容小觑。全面了解、分析、应用数据,从而真正实现对券商用户画像,用户运营工作才能做到有的放矢。

TalkingData提出了用户全方位刻画的理念并付诸实践,比如根据用户的交互数据提升用户到客户(激活APP到开户)的转化率;一三方数据结合,模型精准化定位沉睡用户群,推销理财产品,提升销售额度等。

TalkingData依据自有数据,针对券商APP用户开展全面的数据分析,形成此次报告。既是为了对证券行业目标客群进行梳理,勾勒出用户的“轮廓”;也是为证券行业从业者提供一次从全新角度观察自有用户,进而获取更多营销灵感的可能。

一、券商APP概览

券商越来越重视APP的平台作用,APP不仅仅是一个开户和股票交易的交易通道,而是涵盖了服务资讯、咨询服务、财富管理等诸多功能的运营平台,是券商为用户提供全方位服务的有力工具。

1.1 券商APP活跃用户与指数关系

券商收入规模与大盘指数关联性很强,探索券商APP的用户活跃规模与大盘指数关系,获取规律后对运营工作有指导意义。比如,已知大盘整体上涨时,平台用户活跃度上升。可以考虑在指数上扬时向平台沉默用户推送唤醒信息,借势提升平台活跃用户规模。

1.1.1  2017年 券商APP活跃用户规模与指数收盘值

上证指数和深圳综指全年走势基本吻合,都是先抑后扬的态势,年初到5月略有波动,5月后逐渐上扬,年底稍有回落。券商活跃用户规模年初较平缓,5月份开始逐渐减少,9月份开始呈下降趋势,与监管趋严、用户投资热情下降有关。

上证指数收盘:当月上证指数收盘值的平均值;

深证综指收盘:当月深证综指收盘值的平均值;

活跃用户规模:来自TalkingData平台的“活跃指数”指标汇总(未去重);

应用活跃指数=根据TalkingData样本数据通过预测算法预估出的全平台活跃终端数。

1.1.2  2017年 券商APP活跃用户规模与指数成交额

2017年上半年,沪深两市成交额呈现震荡形势,8、9月达到峰值,随后逐渐走低,这与十九大会议召开前股民的预期和会后政策走向相适应。APP活跃用户规模呈现年初平稳、年中略下行、9月反弹、最后下降的趋势。活跃用户规模与成交额表现较为一致,建议券商在用户交易行为较少时,多提供培养投资理念、教育用户这一类产品或运营服务,如向用户推出“投资风险控制教学”、“解套宝典”等,在非牛市行情也能保证平台对用户的黏性,防止流失。

上证指数成交额:当月上证指数成交额的平均值;

深证综指成交额:当月深证综指成交额的平均值;

活跃用户规模:来自TalkingData平台的“应用活跃指数”指标汇总(未去重);

应用活跃指数=根据TalkingData样本数据通过预测算法预估出的全平台活跃终端数。

1.2 券商APP与证券行业APP关联活跃关系

1.2.1券商APP与其他券商APP关联活跃关系

“一人三户”的政策,允许用户在多家券商开户,用户可能会在各家券商平台游移。在用户APP活跃数据上,表现为某段时间内,用户电子设备上,券商A的APP和券商B的APP都有活跃行为。

每天交易时间内,当券商B的首次APP活跃时间比券商A的首次APP活跃时间晚的时候,券商A的活跃用户有从券商A流失到券商B的可能;这批有流失倾向的用户设备上,如果出现券商A的APP最近一次活跃时间,比券商B的APP最近一次活跃时间更早,说明券商A的这部分用户已经流失到券商B。

根据这一数据,券商可关注交叉券商的产品设计和运营服务,找到对方长处和优势,针对性优化自家的产品和运营,形成产品特性差异化,防止用户流失。

根据2017年证券活跃数据,“涨乐财富通”的活跃设备中,有0.63%的设备也发现了“国泰君安君弘”APP的活跃行为,而且“国泰君安君弘”活跃行为首次监控到的时间,比“涨乐财富通”活跃行为首次监控到的时间更晚。这批活跃设备中,63.6%的设备上,“涨乐财富通”的最近一次活跃行为发生时间,比“国泰君安君弘”的最近一次活跃行为发生时间更早,即这部分设备用户已有流失表现。

同理,“涨乐财富通”与“长江E号”的关联活跃设备比为0.59%,其中有流失表现设备占比为67.6%;与“广发证券”APP的关联活跃设备比为0.56%,其中有流失表现设备占比为60.0%。

与“海通E海通财”有关联活跃关系的券商应用中,前三名是“广发证券易淘金”、“平安证券”、“国泰君安君弘”。“海通E海通财”与“广发证券易淘金”关联活跃设备比为0.95%,其中有流失表现设备占比为82.2%;与“平安证券”的关联活跃设备比为0.93%,其中有流失表现设备占比为80.1%;与“国泰君安君弘”的关联活跃设备比为0.92%,其中有流失表现设备占比为78.4%。

1.2.2券商APP与互联网证券APP关联安装关系

当前互联网证券类APP也在证券行业中扮演了重要角色,凭借灵活的产品和运营策略,对用户喜好的敏锐捕捉,吸引了许多证券投资者使用。导致传统券商用户中也有部分用户同时安装互联网证券APP,对于券商而言,互联网证券APP是很好的学习参考对象,也是争夺用户的潜在强劲对手,学习互联网证券平台的产品设计和运营服务特色,有助于券商更好地为用户做好服务创造价值。

根据2017年12月证券APP活跃数据,与券商APP有交叉活跃关系的互联网证券APP前三名如下表,“同花顺炒股票”、“东方财富”、“大智慧”,除了名次略有变化外,未有其他互联网证券APP进入排名,这也反映该细分市场当前格局。

注: “东方财富”虽然具有券商牌照,根据其产品的较强信息资讯属性,仍划分到互联网证券类。

1.3券商APP活跃用户人均使用证券APP数量

超过90%以上的券商活跃用户只使用一款证券类APP,考虑到对于有投资证券习惯的用户而言,由于转移券商平台的成本较高(开户、入金、银证转账等操作,软件功能的熟悉过程),可能更愿意使用熟悉的平台,因此同时使用多平台的比率不高。

从数据趋势来看,只使用一款APP的用户占比越来越高,产生这种趋势的原因在于各家券商平台都在提升服务能力,而且在彼此借鉴学习逐渐趋同,导致一款产品就基本可以满足用户的需求。在平台差异化小和用户迁移成本高的当前环境下,券商的用户一旦流失就难以挽回。因此,运营好APP平台,提升用户体验对于券商而言意义非比寻常,是维持用户数量和经纪业务规模的根本。

1.4  券商APP活跃用户人均每日启动次数趋势

当用户启动APP次数较多时,说明用户对其有较强依赖性(故障导致频繁启动除外),用户启动APP越频繁,注意力投入越多。结合当前大盘走势,观察用户人均每日启动次数,是券商衡量用户在产品中活跃程度的“晴雨表”。

根据数据,各类券商APP启动次数趋势变化较大,交错产生较多,在年底形式逐渐明朗,“国泰君安君弘”处于第一集团,“玖乐2.0”、“涨乐财富通”、“申万宏源赢家理财”、“广发证券易淘金”、“金阳光移动证券”、“海通E海通财”几家较为接近。

考察券商:根据证券业协会公开经营收入数据选取

二、券商APP活跃用户特征

券商APP的活跃用户是券商的核心客群,全面了解该人群,有助于开展用户体验更好的运营工作。本报告依据2017年12月券商活跃用户数据,从人口属性(包括性别、年龄)、地域分布(包括省级行政区归属、所处城市等级)、用户使用设备信息(包括品牌、机型、价格)等方面分析。获取新增用户是券商普遍的业务诉求,因此将新增(安装证券APP且有活跃行为并且被首次观察到的设备)活跃用户作为重点关注人群提炼出来,与整体活跃用户对比分析。

2.1 券商APP活跃用户特征:性别

券商活跃用户中男性比率更高,达到57%,女性用户达到43%。

注:数据由上交所年鉴及TalkingData数据综合得出

2.2 券商APP活跃用户特征:年龄

APP整体活跃用户35岁以下用户比率达84.6%,而APP新增活跃用户35岁以下比率为70.9%。作为对比,上交所投资者年龄分布数据中,40岁以下的用户比率为69%,可见APP活跃用户比投资者在年龄上更年轻化。券商APP的用户以年轻人为主,是未来的提供收入的主力人群,因此券商运营APP平台就是对未来投资,占得先机。

注:投资者数据来自上交所年鉴­­

2.3 券商APP活跃用户特征:省份分布

券商整体活跃用户数据分布显示,富裕地区的人口基数虽然并不一定是最大的,但是拥有的活跃用户占比表现突出——即在单位人口数量下,产生券商活跃用户的比率更高,比如江苏省、广东省、上海市等地区。而人口基数类似甚至更大的地区,如四川省、河南省、山东省的活跃用户规模,并不与人口大省的地位相匹配。可见,券商APP的活跃用户分布与地区经济发展有较密切联系。

注:各省常驻人口数据来自国家统计局2016人口数据

从新增角度来看,用户基数大的江苏和广东也贡献了最多新增活跃用户,而且表现地比整体分布更为集中。未来提升活跃用户规模的重点可以放在券商活跃用户规模占比并不靠前但人口数量巨大的地区,比如四川省、山东省、河北省。

注:各省常驻人口数据来自国家统计局2016人口数据

2.4 券商APP活跃用户特征:城市级别分布

人口占比仅6.1%的一线城市贡献的券商APP整体活跃用户和新增活跃用户占比都超过10%,而二线和三线以下城市的APP整体活跃占比和APP新增活跃占比都要低于人口占比数据,说明证券APP的饱和度一线>二线>三线以下城市。一线城市的用户已经接受了比较充分的券商业务洗礼,今后为了获得用户规模的提升,需要在二、三线城市开展营销活动,想要获得良好的营销效果,最好当下着手了解二、三线城市居民的特点,在未来设计活动时会更有针对性。

注:人口数据来自国家统计局及网络搜索

2.5 券商APP活跃用户特征:设备品牌(安卓)

分析券商活跃用户的设备品牌,有助于发掘用户群体的属性特征,比如青睐华为的商务人群、喜好小米的年轻一族、OPPO和vivo对应的年轻女性等,建议针对人群设计精准化营销活动,比如直接与目标人群喜好的品牌开展跨界活动等。

券商整体活跃用户中使用华为设备的用户达24.9%,其中前五名品牌的占比和达80.4%,品牌高度集中;新增活跃用户中,华为仍然占据第一位,说明该品牌的气质与券商用户的金融化、商业化倾向较为吻合。新增活跃用户的前五名品牌比率之和达74.9%,建议如果券商与手机等设备品牌合作时,应集中投入资源。

2.6 券商APP活跃用户特征:设备机型分布(安卓)

分析活跃用户的设备信息可以进一步细化活跃用户的喜好,同时也为设计APP的设备兼容性提供依据,进而提升用户使用体验。

券商活跃用户的设备偏好并不特别集中,没有一款设备占比超过5%。整体活跃用户中,红米note是使用最多的设备,华为的荣耀和Mate系列也有较大份额,前十名的设备属于小米、华为、OPPO、三星四个品牌。新增活跃用户的设备偏好与整体用户略有不同,大神手机表现突出,占据第二名,其余前10席位仍由OPPO、三星、华为、小米等品牌瓜分。

2.7 券商APP活跃用户特征:设备价格

设备价格可以作为衡量用户消费水平的一个参考指标,券商活跃用户多喜欢使用500元-2千元价格区间的设备,整体活跃用户中,该价格区间机型占比达到80.9%,新增活跃用户该类机型占比达72.6%,整体来看,整体活跃用户的设备价格更集中,500元以下和4千元以上机型占比都低于新增活跃用户。

三、券商APP活跃用户应用喜好

券商活跃用户会使用多种其他类型APP,用户对各类APP的喜好数据,很适合用于形成用户在券商平台之外的画像;同时,愿意使用某一类APP的用户有其共同特征,券商还可以把与自家APP有关联关系的APP视作推广渠道,合作开展营销活动,获取潜在用户,比如直销银行APP、理财应用、应用商店、新闻类APP等。

3.1 券商APP活跃用户关联应用: 直销银行

随着居民财富的积累,人均可支配收入的提升,财富管理需要大规模增长。受市场佣金价格竞争、互联网对金融行业冲击等影响,券商现有通道业务的发展空间逐渐减小,盈利模式也将从以交易佣金为主向按资产、增值服务收费的模式转变。

直销银行是当前新兴的金融经营模式,通过线上渠道向客户进行理财产品售卖等服务,直销银行类APP的用户正是券商业务转型的潜在目标人群,了解券商人群中有哪些直销银行类APP最被用户接受,学习其产品和经营的特点,有助于券商业务转型。

整体和新增活跃用户的数据显示,“微众银行”、“网商银行”和“钱大掌柜”等较知名金融机构+互联网平台形成的产品已经具有一定优势,占据前三名;由于金融资管业务本身就有种类丰富、专业性强等特征,因此产品种类会很丰富,细分市场较多,券商可以发挥自身投资管理经验丰富的优势,设计特色产品,占据垂直细分领域优势地位。

3.2 券商APP活跃用户关联应用: 理财应用

当前理财类应用可谓种类繁多,在资产管理、资讯服务、消费借贷等各个领域都有代表性平台为用户提供服务,尤其是互联网化的产品平台,更是以理财产品种类多样、资金门槛要求低、服务方式灵活等特点吸引了大批用户。了解券商用户最常用的理财应用,学习这些平台在产品和服务的特色,更有助于券商的服务化转型。

整体活跃用户关联的理财应用以业内知名的平台为主,比如“京东金融”、“宜人贷”系列、“翼支付”、“陆金所”等都是具有较大规模且广为人知的产品,而且产品类型相对丰富,除综合性金融平台如京东外还有借贷平台(宜人贷)、工具(51信用卡管家)、社交资讯(雪球)等多种基于理财但功能类型不同的产品;而新增活跃用户的理财类产品中,新晋品牌的比率有所提升,这类平台吸引用户的往往是较高的收益率,这也与当前用户选择高回报的投资标的环境氛围相一致。由于互联网金融的灵活性较高、监管难度较大,导致风险相对更高,券商可尝试从投资理念教育的角度为用户提供服务,培养用户的信任和黏性,从而提升用户体验。

3.3 券商APP活跃用户关联应用: 应用商店(安卓)

目前应用商店仍然是用户下载APP的主要来源,而用户一般不会使用多个应用商店,了解当前用户的应用商店使用情况,有助于券商在获取新用户时分配资源,在重点应用商店投放,获取更多潜在用户。

在整体活跃用户中,前十名关联应用商店有五款来自手机厂商(OPPO、小米、华为、vivo、魅族),前五名只有360一家独立应用商店;而新增活跃用户前十名关联应用商店中有6家独立应用商店。

3.3券商APP活跃用户关联应用 : 新闻类

随着移动互联网技术的发展,人们获取信息的方式越来越依赖新闻资讯类APP。各类APP新增用户中,来自信息流广告的用户越来越多,新闻类APP作为渠道也越来越受到各家券商的重视。随着流量成本日渐攀升,了解当下用户正使用哪些新闻类APP,对于券商来说也越来越重要。不仅获取新增时需要投放广告,很多APP也将活动的H5页面或链接投放在新闻类APP上,通过活动吸引潜在用户或者唤醒沉睡用户,这也是当前精准化营销的一种常见模式。

无论券商APP整体活跃用户还是新增活跃用户,今日头条和腾讯(新闻+快报)都占据了前三的位置,表明信息流资讯类APP的头部流量已经被这两家公司占据,整体活跃用户中网易、凤凰、搜狐等传统门户客户端仍占据前列;新增活跃用户中,内涵段子、趣头条的排名较高,与当前用户猎奇、追求有趣的品味相一致。

补充说明

数据来源

TalkingData数据中心数据来自TalkingData App Analytics、TalkingData Game Analytics、TalkingData Ad Tracking的行业数据采集,以及诸多公开数据和合作伙伴的数据交换,如应用市场、渠道、运营商等多种不同来源的数据复合而成。

数据周期

应用数据:截止2017年12月数据

概念定义

城市分布:一线城市为北上广深四市和香港、澳门特别行政区;二线城市为其余直辖市、各省省会及各省重要城市;三线及以下城市为除一、二线城市之外其他城市。

TalkingData推出小程序推广监测,助开发者打赢流量争夺战

微信小程序发布一年有余,目前已有近60万小程序上线,用户覆盖量超过4亿人,成为新一轮流量争夺的战场。近日,国内领先的第三方数据智能服务商TalkingData推出小程序推广监测,助力小程序推广人员精准评估渠道推广效果,发现更多优质流量入口。在微信的流量红利下,小程序生态发展迅速,成为开发者们中炙手可热的新风口。据相关数据显示,2018年小程序数量将有望突破300万。然而,数量爆发增长的盛况下,真正破局而出、被大众熟知的小程序却是凤毛麟角。

如何将微信的亿万用户转化成自己的用户?这是最受小程序开发者关注、也亟待突破的难题,仅仅依靠微信生态内自然曝光显然是不够的。随着小程序入口和场景的不断完善,以及微信广告全流量场景对小程序推广的开放,为开发者提供了更多触达、获取用户的营销方式,但基础的数据统计却无法满足精准推广所需。

作为国内最大的移动效果广告监测平台,TalkingData Ad Tracking推出小程序推广监测,正是为了满足这一需求,以全面的覆盖精准的追踪深度的监测精细的量化,帮助小程序开发者和推广人员掌控渠道推广效果,定位优质流量入口,在流量争夺战中占得先机。

推广场景全面覆盖,广告流量精准追踪

尽管小程序的入口在不断的增加,但可通过广告实现获取更多用户的入口仍然有限,包括

  • 推广二维码:小程序二维码、普通二维码
  • 微信广告官方流量:朋友圈广告、小程序广告、公众号广告
  • 其他:公众号、小程序内容中植入链接推广

TalkingData Ad Tracking小程序推广监测服务覆盖以上所有推广场景,支持对每一次推广进行精准流量追踪,监测每一个广告的引流效果,旨在为小程序开发者提供最细粒度的推广监测服务。

深度转化事件监测,精细量化推广效果

在基础的用户维度数据监测之上,TalkingData Ad Tracking还为小程序开发者提供了媲美原生应用的深度转化事件监测,为小游戏以及电商类小程序提供定制化的监测指标,助力小程序开发者了解不同广告推广在关键效果点的转化效果,为广告效果评估提供更多维度数据支持。

目前TalkingData推出的小程序推广监测服务已正式上线,开发者可以登录TalkingData Ad Tracking了解该服务的更多特点与具体功能。


关于TalkingData

TalkingData 成立于2011年,是国内领先的第三方数据智能服务商。借助以SmartDP为核心的数据智能应用生态为企业赋能,帮助企业逐步实现以数据为驱动力的数字化转型。

TalkingData联合Kaggle建立中国数据集专区

近日,TalkingData与国际领先的竞赛平台与数据科学家社区Kaggle达成战略合作,联合在Kaggle网站上发布中国数据集专区。此次合作旨在为Kaggle已有的庞大数据集资源池加入更多有价值的中国数据,通过开放独一无二的中国移动互联网脱敏数据集和真实商业场景,与全球超过50万名数据科学家合作、交流、同台竞技。这对于全球数据科学爱好者来说是一个了解中国用户的契机。未来,在全球各地对数据挖掘感兴趣的工程师热情参与下,将能够为全球数以百万计的开发者提供更为有效的数据服务。
 

TalkingData成立近七年,为超过12万款移动应用,以及10万应用开发者提供服务,同时服务于金融地产快消零售出行政府等行业中的领军企业,拥有强势技术能力及丰富行业经验,。

依托于优质海量数据,TalkingData希望此次合作能够帮助全球数据科学家构建更准确的预测模型,借助先进的机器学习和深度学习技术实现更高效的数据分析。也希望借助Kaggle这个开放的平台将脱敏数据共享给全世界最优秀的数据科学家,让他们用最聪明的办法解决最有挑战性的问题。

TalkingData CEO崔晓波认为“数据是链接中美智能应用的桥梁”。近两年来,TalkingData团队与Kaggle已共同举办了两场活动,为此次深度合作奠定了基础。

2016年7月,TalkingData首次将Kaggle算法大赛引入中国,开放部分脱敏后的中国移动互联网用户行为数据集给全球热衷数据科学的挑战者,进行用户人口属性模型预测。历时2个月的大赛吸引了来自全球70多个国家和地区的2600个团队参赛,创下了当时Kaggle单个竞赛参与人数的新纪录。

2018年3月,TalkingData 再一次联合 Kaggle 共同发起 TalkingData 全球广告反欺诈算法大赛。此次比赛提供与中国广告反欺诈相关的独特应用场景与脱敏数据集,来自全球91个国家和地区的3967支队伍报名参赛,在参赛人数上再创新高,体现了全球数据科学家对基于中国行业数据集探索和解决实际问题的兴趣。

此外,前三名获奖团队中有两支团队来自中国,可见也有越来越多的中国数据科学家参与到国际性竞赛中来,切磋技艺寻求挑战。此次大赛为广告反欺诈提供了诸多新思路和新方法,也为国内广告行业的健康发展带来了驱动力。