活动回顾|《数驱•营销闭环 助力品牌增长》全国巡演上海站

Markdown

沙龙中,认真聆听的同学们

6月21日,TalkingData在上海成功举办了《数驱·营销闭环 助力品牌增长》全国巡演第四站营销主题的线下沙龙。在本次沙龙中,我们诚意邀请到TalkingData数据分析高级总监 王鹏加和信息科技副总裁 Jimmy Liang上海联通大数据高级项目经理 山峰眸事网CTO 曹文炯,为大家分享营销案例和经验。现在,我们一起回顾下在本次沙龙中嘉宾们分享了哪些营销干货。

01《数据助力营销 闭环驱动增长》

Markdown

分享人:王鹏 TalkingData数据分析高级总监

TalkingData数据分析高级总监 王鹏把本次分享内容分为4个模块:1.势:数据洞察行业趋势;2.道:厘清营销模式流程;3.术:数据构建营销策略;4.器:产品助力营销闭环。

我们在本篇中带大家主要回顾第1-2部分。

1、势:数据洞察行业趋势

趋势一:使用习惯逐渐固化,竞争从流量转型运营;趋势二:数字营销推广作弊态势持续激增;趋势三:信息流广告独占鳌头,地位难以撼动;趋势四:HTML5 WebApp推广进入爆发阶段;趋势五:线上线下全面融合,或成为下一个营销增长点;趋势六:数字营销走向数据营销;

2、道:厘清营销模式流程

王鹏表示行业关注和需要解决的问题为以下三个方面:

①流量质量是广告主关注焦点

流量反欺诈、流量层过滤、私有交易流量使投放更加精准,而且使流量得到保证,解决数字营销中“流量”这个关键性问题;

②数据为数字营销提供基础

数字营销离不开「数据」,利用数据对受众静态属性、动态属性、各种行为习惯的分析,使精准营销成为可能;

③闭环营销让效果持续提升

通过对用户广告行为的持续学习,实现效果的不断优化,利用机器的试错、总结、学习,逐步完成迭代式优化,基于效果投相似效果。

02《构建开放的大数据营销生态圈》

 

Markdown

分享人:Jimmy Liang 加和信息科技副总裁

Jimmy认为目前在整个数据行业里,数据并不少,而是非常多。即使这样,很多广告主还是面临“看见很多数据,但它们是割裂的,数据数量很大,但没办法流动起来”这样的一个问题。在本次分享中jimmy表示此前通过清晰的数据,可以更好的掌握营销。但在互联网时代,很多原有的评估指标变得不太确定。根据与客户交流、沟通和多年从业经验,Jimmy总结出品牌需要更开放、更灵活和更安全的智能营销解决方案。

在沙龙现场,Jimmy还为现场同学分享了,通过人群标签筛选、目标人群设定、累积选择,如何在欧锦赛期间推广一款男性眼霜的案例:

①数据策略:定向目标人群-熬夜、球迷、差旅、爱美;深夜开启/使用特定App;

②标签定制:采用TalkingData定制化标签服务,找到熬夜黑眼圈一族、时下看球一族、差旅疲惫一族;和爱美保养一族,基于设备使用时间(晚间)、Lbs地理位置、等APP个性化行为,进行标签定制;

③技术关键点:多维度的DMP数据。

03《中国联通大数据助力品牌增长》

Markdown

分享人:山峰 上海联通大数据高级项目经理

在本次沙龙分享中,山峰表示通讯运营商与互联网公司对比,互联网数据受限于本身的数据基因,运营商的数据也许更有代表性和竞争力。

1、互联网数据:
  • 数据局部性,互联网公司的数据是相互割裂的,淘宝只有阿里系的数据,没有百度搜索的数据;
  • 数据封闭性,很少有互联网公司愿意开放自己的数据,开放更多的是商业模式层面和应用层面;
  • 数据割裂性,互联网的数据整合困难,同时注册的个人账号也是短期的,不稳定的;
  • 数据全面性,互联网公司的数据受限于自身的业务,其数据的范围和深度都是有限的。
2、运营商数据:
  • 运营商是数据管道,任何个人、企业的上网和通话的行为都流淌在运营商的管道里,移动运营商拥有个人、企业的上网和通话行为、位置记录,上网记录等数据,数据规模优势明显;
  • 运营商以号码为唯一的ID来整合各类数据,因业务属性的特殊性,刻画客户数据完整是运行商得天独厚的优势一般企业难以企及,而且还有终端ID作为移动通信网天生的业务属性而存在;
  • 运营商数据解决移动互联网时代最为关注的三个问题,我是谁,我在哪里,我在干什么,这是很多企业的数据难以比拟的。运营商承担着相当大的社会责任,数据不分享,不外流,数据安全得到保障。
04《大数据人工智能平台驱动商业价值》

Markdown

分享人:曹文炯 眸事网CTO

曹文炯在本次分享中,就企业如何最大化发挥DMP价值阐述了以下观点,企业自建DMP是基于消费升级带来的用户精细化运营的必然趋势;企业自有DMP的运维核心需可追溯、全流程、可触达;全流程整合业务-产品-用户矩阵,才能最大化发挥企业DMP的价值。在沙龙现场,曹文炯还为现场同学分享了多个教育案例。

《数驱·营销闭环 助力品牌增长》全国巡演第五站将在7月份登陆北京,请大家关注TalkingData微信公众号,关于北京站活动的最新动态!

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这样的国际前沿技术引入高速发展的中国市场,与国内丰富的应用场景相结合,驱动新技术落地与行业进步。

基于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的可用性,所以后续我们会进行该功能的测试、上线的工作。

小程序UI组件库iView Weapp发布,开源、免费、分分钟上手!

TalkingData温馨提示:文末有彩蛋哟

过去的两年里,iView 开源项目已经帮助成千上万的开发者快速完成网站开发,大幅度提高了开发效率,成为 Vue.js 生态里重要的一部分。

与此同时,我们也在思考,除了服务 PC Web,iView 还能提供什么。可能是 Mobile Web?但同类产品已经太过丰富,所以 iView 一直没有探索 Mobile 端。但是,我们注意到,微信小程序正在崛起,这将是移动端新的一种开发模式。

对于微信小程序,iView 团队并不陌生,在微信最早发布小程序时,TalkingData就上线了小程序统计分析服务(https://www.talkingdata.com/weApp/weApp.jsp)近期又推出了小程序推广检测服务

现在,微信对小程序越来越开放,提供的入口也越来越多,这让很多开发者投入到小程序的开发上。

经过一个月的探索,我们明确了能针对微信小程序开发提供怎样的服务。于是, iVew团队基于在UI组件方面的2年积累,推出了这套高质量的 UI 组件库——iView Weapp。相信 iView 的开发者也会喜欢。

GitHub地址:https://github.com/TalkingData/iview-weapp

开发文档:https://weapp.iviewui.com/

欢迎 Star 和 PR !

iView Weapp 是什么?

微信小程序提供了自定义组件的功能,这使得 iView Weapp 成为了可能。小程序已经提供了很多组件和 API,但它们过于基础,实际开发时仍需要一定的封装和 UI 调整。iView Weapp 提供了与 iView 一致的 UI 和尽可能相同的接口名称,大幅度降低了学习成本,使用起来如鱼得水。如果你是 iView 的核心用户,用起 iView Weapp 来甚至不用看文档!当然,我们对新用户也很友好,事无巨细的文档、友好的 API 和完整的示例,几分钟就可以上手啦。

iView Weapp 1.0 提供了 30 个组件,并会不断丰富:

Markdown

先睹为快

使用微信扫一扫,体验 iView Weapp 小程序组件示例:

(注:单击下图后长按即可识别。)

Markdown

当然,你也可以在微信开发者工具中查看:

# 从 GitHub 下载后,安装依赖

npm install

# 编译组件

npm run dev

然后,将 examples 目录在微信开发者工具中打开即可。

1.0 目前提供的都是基础组件,能够满足大部分常用的布局和交互。接下来,我们还会提供更为丰富的基础组件及典型业务组件,比如刮刮乐,旨在为小程序开发降低门槛,并带来出色的用户体验。

开源协议

iView Weapp 使用 MIT 开源协议,并 100% 开放源码。查看开源协议(https://github.com/TalkingData/iview-weapp/blob/master/LICENSE)。

这里是彩蛋

我们预计在本季度发布 iView 3.0 以及 5 款神秘新产品,届时会举办线下发布会并进行线上同步直播,敬请关注iView 官网。感谢大家长久以来对 iView 的支持,我们将持续维护,投入更多的人力和精力完善生态,让 iView 成为全球最好用的组件库!

硅谷线下 DTalk | AI在”移动优先”的互联网金融商业模式中的应用:关于两个“循环”的讲述

Markdown

一场高质量的分享会应该具备哪些特征?

一位在某个领域足够资深的演讲者,

就一个值得探讨的行业话题,

用一套逻辑严密的演讲框架,

在可以充分表达的2个小时里,

向近千位专业听众完整分享他的看法与见解。

这就是 DTalk。

DTalk是机器之心联合TalkingData共同推出的全球化精品海外活动品牌及演讲系列活动,专注于数据科学与人工智能领域的前沿技术、工程实践与应用落地。 DTalk旨在为相关业内人士、以及对行业感兴趣人士带来深度有价值的业界话题分享,并提供观点交流平台。DTalk将在北美多个科技重镇举办线下分享会,每期精选一个行业话题,邀请资深行业人士分享,并进行全球同步线上直播。

Dtalk 第一期主题

AI在”移动优先”的互联网金融商业模式中的应用

关于两个“循环”的讲述

活动简介

互联网时代下金融市场风起云涌,人工智能技术的助力使互联网金融更加加速了规模化的智能金融服务,并形成良性的商业循环。首期DTalks将着眼于互联网金融,并邀请到Acorns首席数据科学家种骥科先生,为大家深度解析互联网金融当下存在两类基本循环:获取用户与留存用户;并通过案例分析点出人工智能技术可以为互联网金融带来的六大机会。

嘉宾介绍

Markdown

种骥科 Acorns首席数据科学家

目前就职于Acorns任首席数据科学家,拥有多年互联网、大数据及金融创新经验。曾担任宜人贷首席数据科学家,美国Silver Lake 私募公司任Kraftwerk基金数据科学架构师,负责大数据技术应用,并应邀为白宫科技办公室参谋大数据技术产品设计。学术方面,种骥科先生曾于清华大学交叉信息研究院开设“量化金融信用与风控分析”研究生课程,并曾担任卡内基梅隆大学教授与博士生导师,开设高性能计算研究教学中心,任联席总监。

演讲概要

  1. 互联网金融背景简述
  2. 两个循环:“获取用户”与“留存用户”
  3. 人工智能带来的机会:六个机会
  • 数源创新
  • 精准转换
  • 废数利用
  • 盈利底蕴
  • 自我保护
  • 长期信任

活动流程

时间:美西时间 2018年6月21日 18:30 —20:30

  • 8:30 签到入场
  • 19:00 – 19:30 嘉宾分享
  • 19:30 – 20:00 炉边对话 Q&A

温馨提示:

活动举办的北京时间为

6月22日 上午9:30—11:30

地点:中关村硅谷创新中心(4500 Great America Pkwy, Santa Clara, CA 95054, USA)

Markdown

报名方式

点击即可报名参与现场活动,我们为到场听众准备了饮料小食,相聚硅谷,畅谈FinTech。

观看全球直播

方法一:扫描下方二维码添加微信TUD小助手(ID:TDU2018)进入DTalk 交流群;

Markdown

方法二:扫描下方二维码,填写Google报名表,进入Dtalk Slack群组。

Markdown

主办方介绍

Markdown

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

Markdown

机器之心全球化子品牌旗下英文站 Synced Review (Medium:@Synced) 为全球读者提供机器智能领域领先的技术及行业动态报道,专业分析师报告等优质原创英文内容,举办海外活动,开展跨国产业服务。

高效、快速、准确、动态的人口统计新实践

前言

作为社会的主体,人口是影响社会发展的基本力量,人口规模的变化是决定城市空间规模的重要影响因素。我国正处在城市高速发展时期,城市规划的重要性日益凸显,人口的量化分析占有越发重要的地位。 城市人口数量每时每刻都在变化,自身增长规律十分复杂。目前,人口统计方法基本分为静态统计和动态统计两种。静态统计一般广泛应用于统计局、公安局等部门,以普查、抽查、登记等传统手段为主,有耗时高、成本大、效率低等特点。

Markdown

近几年,随着大数据和数据科学的兴起,基于信令、手机APP、GIS应用的移动位置大数据动态人口统计方法正在迅速发展,补充了传统人口统计数据来源,可以作为动态人口统计结果的参考标准。

基于移动数据的动态人口统计

TalkingData覆盖数据具有来源丰富、种类齐全、数据体量大等特点。目前,TalkingData除了自有移动互联网数据,还整合了运营商等合作伙伴的数据,包含GPS、基站、WiFi等位置信息。 下图以计算年度数据为例,介绍TalkingData动态人口统计的主体逻辑:

Markdown

TalkingData人口统计团队提取一年内的所有移动设备数据,基于用户群体出现天数、驻留时长、时间间隔维度建立评估模型,同时根据静态统计结果,建立了判定稳定用户的阈值。基于阈值对设备进行过滤去重之后,即可建立稳定用户基础库。之后的各项指标计算都是基于稳定用户基础库进行的。 对获得的稳定用户基础库从时间、空间维度上进行聚类筛选,可得到更丰富的统计结果。比如对省市聚类,可以获得全国各省份全年的相关结果;对时间聚类,可以获得某一段特定时间的数据统计结果;考虑相邻两个月的人口迁移,可以得到省份的人口流入流出情况。

人口统计实践

下面展示TalkingData人口统计的部分实践。

① 2018年4月北京市十六区常住人口占比:

TalkingData人口统计团队用2016年8月份移动运营商常住人口占比与2016年北京城十六区年鉴常住人口占比作为参考。对比发现,TalkingData计算得出的北京市区县常住人口中,占比前四的区县分别为朝阳区、海淀区、丰台区和昌平区,与运营商数据和统计年鉴一致,但TalkingData和运营商计算的朝阳区常住人口占比都高于统计年鉴中的人口比例。

Markdown

为了衡量TalkingData的计算准确度,我们以2016年北京城十六区年鉴常住 人口占比为基准,对比TalkingData计算的人口占比的偏差程度。对比发现,TalkingData与年鉴数据误差的均值为0.98%,标准差为1.61%。移动运营商数据与年鉴数据误差的均值为0.90%,标准差为1.47%。

② 2017年11月深圳区域常住人口占比:

TalkingData人口统计团队用2017年11月份移动运营商计算的深圳常住人口占比与深圳统计局年鉴中的2016年常住人口占比作为参考。对比发现,三份数据整体趋势非常接近。

Markdown

我们以年鉴的人口占比为基准,对比TalkingData计算的人口占比的偏差程度。对比发现,TalkingData与年鉴数据误差的均值为1.24%,标准差为1.61%。移动运营商数据与年鉴数据误差的均值为1.57%,标准差为1.81%,二者很接近,TalkingData略优于移动运营商数据。

Markdown

③ 2017年11至2018年4月北京市常住人口变化:

上图为从2017年11至2018年4月份,北京的常住人口变化趋势。我们发现二月北京常住人口稍有减少,我们认为这是由“春运”造成的,符合常识认知。

Markdown

Markdown

上图分别展示了2017年11至2018年4月北京常住人口的环比变化趋势。北京常住人口总体在2017年11月份到2018年1月份体现出了下降趋势。2018年2、3月份受春节影响,常住人口有超过7%的下降和回流。2018年3、4月份数据基本持平,有轻微的上升。

④ 2018年4月全国人口统计:

Markdown

上图以2017年年鉴的全国省份数据为标准,对比了TalkingData计算的2018年4月的全国人口统计结果。我们发现误差平均值为0.90%,标准差为1.21%,TalkingData计算结果与年鉴占比相似程度较高,具有较强的参考价值。 TalkingData 《2017年移动互联网行业发展报告》指出,截至2017年12月,我国移动智能终端规模达到14.2亿台,且逐渐向三线及以下城市下沉,移动互联网已全面普及。基于移动位置大数据动态人口统计方法将是未来人口统计的发展趋势,与传统人口统计相结合,能够更好地帮助政府实现智慧的城市规划与管理,实现人民生活环境的整体改善。

重磅!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支宝才:金融科技驱动券商财富管理业务转型

近日,TalkingData 高级副总裁支宝才受邀出席由国泰君安证券、山西证券共同举办的 2018年度互联网证券业务专项研讨会,并做了题为《金融科技驱动券商财富管理业务转型》的主题演讲。

招商银行和贝恩联合发布的报告称, 2016年中国高净值客户(AUM超过1000万RMB)规模已达到158万人,持有的可投资资产达到165万亿人民币。另外根据福布斯的预测,到2020年中国富裕人群(可投资金融资产100万到500万人民币之间)的规模将达到3000万,这些客户的资产总额也将超过40万亿人民币。另外据BCG的估算,2017年国内线上财富管理(全部通过线上的方式完成交易)规模占比已经达到34.6%,如果考虑到券商服务的客户类型和提供产品的范围,证券行业财富管理线上的比例会更高。

财富管理市场规模庞大,增长快速,无疑蕴藏着无限商机。而随着佣金费率的不断降低,券商经纪业务从传统通道服务向财富管理模式转型已成为国内证券公司战略转型的重要方向。随着大数据、智能投顾等金融科技手段开始广泛运用于财富管理的各个方面,国内券商积极探索在互联网证券的大背景下,如何利用金融科技实现财富管理业务的转型。

互联网证券的下半场应该如何来做?如何更好地利用金融科技的手段助力线上财富管理转型和提升业务运营和客户服务的能力?在研讨会上,TalkingData 高级副总裁支宝才从几个方面为数十家券商做了分享。

一、互联网化证券财富管理市场的四个发展阶段

支宝才指出,从全球来看,互联网背景下证券财富管理业务发展主要经历了四个阶段。分别为以证券交易互联网化为标志的第一阶段,把传统的线下交易迁移到线上,极大的提升了交易效率,但是投资管理、客户服务等环节还是在线下进行。接下来是以互联网开户为标志的第二阶段,券商实现了全业务流程的线上操作,摆脱了物理网点的限制,线下渠道轻型化,这个阶段的关注重点是客户规模、佣金业务收入和运营成本。第三个阶段的标志是互联网化投融资,这个阶段券商开始发力线上财富管理,通过拓展产品和服务的范围,提升管理客户的资产规模,更关注客户的综合贡献,多元化业务收入来源,而不是单纯依靠佣金业务收入;最后一个阶段是实现以综合账户管理为基础的一体化金融服务,这需要通过金融混业手段,实现客户的多账户打通。

支宝才认为,这个四个阶段在美国市场大概花了40年时间才完成,但是国内证券互联网化和经纪业务向财富管理业务转型同时发生,目前国内的券商大多数在从第二阶段和第二阶段向第三阶段过渡的时期。

二、国外互联网证券拓展财富管理业务的三种路径

接下来,支宝才分析了国外互联网券商拓展财富管理业务的路径,并分享了其对国内券商互联网财富管理业务转型的启示。

  • 第一种路径是从传统券商向O2O财富管理平台转型。这里包括多数的传统线下证券经纪商。如嘉信理财,由最开始的佣金折扣经纪商模式,到资产集合商模式,再到O2O财富管理模式,通过发展互联网财富管理,在吸引了中小投资者后拓展中高端客户市场,最后向全面金融服务商模式迁移,最后发展成集证券经纪、资产管理、银行、金融咨询为一体的综合金融服务商。通过发展财富管理业务,嘉信理财的经纪业务收入占比从1991年的65%,到2014年下降到不足18%。
  • 第二种路径是从网络折扣经济商发展成为线上综合财富管理服务提供商。一个典型的案例就是E-Trade。E-Trade 1994年开设网站直接为客户服务,成为一家纯线上网络折扣经纪商,利用市场推广、低佣加便捷服务快速的获取了大量的客户,高峰时近一半的营收都投入到市场推广。而后逐步向资产增值服务转型,例如收购互联网银行Telebank,进入互联网银行业,联合E-Loan将业务拓展到抵押贷款领域,收购金融媒体网站,利用网站门户为投资者提供原创金融信息。
  • 第三种路径是新兴金融科技公司利用金融科技能力在传统市场以差异化的模式切入财富管理市场。例如Betterment,它是第一家通过自动化在线服务为客户进行资产管理的投资理财公司,也是美国最大的、增长最快的智能投资顾问公司之一。Betterment利用财富管理平台及资产聚合工具,为客户定制个性化的储蓄和投资方案,其定位的客户类型是20万美元以上的个人财富管理客户,近年来逐步向低端客户输出财富增长服务。这个类型的公司增长很快,在美国智能投顾管理的资产管理规模占比已经接近财富管理市场总规模的20%。

支宝才认为不管通过哪种路径进行转型,最终券商要思考的课题都是如何为客户提供满足其需求的金融产品、提供更优质的服务,同时有效控制运营成本,而互联网和金融科技的发展无疑为转型提供了更多的选择空间。对国内券商而言,发展财富管理业务是佣金自由化驱动的经纪业务转型的必然趋势,并且因为国内市场竞争结构形态和美国不同,国内券商的起点其实都比较类似,但可选的路径可以多种多样,目前我们看的转型实践很多都同时带有以上三种路径的某些特点。

三、金融科技如何推动券商财富管理业务转型

支宝才认为金融科技将使得券商有机会重新定位财富管理业务,并将深刻改变券商开展财富管理业务的模式。首先金融科技使的券商财富管理能力下移,使得能够用传统服务私人银行、中高端客户的方式服务更多的“低”端客户,他将这种趋势称为财富管理业务下沉。例如过去投资顾问服务成本很高,在一定交易额度或AUM值以下的客户很难获得财务规划、投资建议和投资管理的服务。现在机器人投顾(Robo-Advisory)完全可以代替一般的投资经理和财务顾问,并且服务水平更加可控,使得更多偏低金融资产水平的客户也能获得相应的服务。其次金融科技有助于打破财富管理市场产品服务同质化的竞争态势,使得券商有可能利用金融科技的赋能获取差异化的竞争能力,从而在竞争中获胜。可能是更高效的移动互联网运营能力、更个性化的资讯服务能力,更精准的智能产品推荐引擎、或更强大的量化投资模型等。

针对券商具体如何利用金融科技提升财富管理能力,支宝才结合TalkingData在大数据领域的经验,重点和大家分享了如何利用大数据升级客户洞察(KYC)能力。

他分享的一个的重要应用场景是如何利用大数据精准定位高净值客户。定位高净值客户的方法和定位普通客户有比较大的差异。高净值客户数量少,营销成本高,营销难度高,所以需要有更深的客户洞察和更精准的定位方式。TalkingData通过分析中高端客户的行为特征,发现他们在特定兴趣、社会团体、特定消费服务场所、居住地、人群关系等方面比普通客户有更明显的聚集效应。支宝才介绍了TalkingData如何成功帮助一家金融机构利用一方数据和TD设备的位置(LBS)数据建模,成功定位潜在的财富管理客户的案例。

支宝才认为利用客户关系图谱升级客户洞察对于券商开展财富管理业务也是可以思考的一个方向。他举例说,高净值客户中很多是企业主,在大多数私人银行机构的客户中企业主的占比是超过50%的。传统方式我们比较关心单个客户的人口信息,资产情况,交易信息,当然现在还有客户行为信息。但是其实财富管理客户,特别是高净值客户,对于财富管理机构来说更有价值的信息是客户关系信息:例如他拥有的企业的信息——很多小企业主投融资行为是个人企业分不开的;又例如他的家庭的信息——很多高净值人群投资在家庭有分工,仅仅分析个人信息很难做出有价值的判断。个人客户关系图谱的构建不仅对营销、客户服务有价值,对风险管理也同样有价值。在会上支宝才分享了TalkingData如何利用大数据帮助某金融机构构建客户关系图谱的实践案例。

在会议中,支宝才还给各家券商介绍了几家在国外市场比较有特色的金融科技公司,展示他们如何利用大数据改变投资行业。如大数据公司Kensho,利用机器学习判断国际事件对交易市场指数和股价的影响,他们的模型成功预测了英国脱欧后英镑对美元的走势,不仅是长期趋势,还包括未来几个月的大的波动情况,结果非常准确,在当时震惊了市场。Sqreem公司致力于分析人们的数字活动和行为来预测他们可能最想要的产品和服务,利用爬虫软件获取公开大数据, 分析了美国3亿人线上行为活动。富国银行、BlackRock、瑞士联合银行和德意志银行都是他们的用户。

最后支宝才总结道,互联网的发展,特别是大数据和人工智能的发展对券商财富管理业务来说,并不是意味着颠覆,而是提供了更多的转型手段和业务模型选择的可能性。回到前面Betterment的案例,其实现在行业最大的智能投顾资产管理者是传统投行Vanguard,Vanguard虽然开发智能投顾比Betterment晚了很多年,但是其利用其对客户的深刻理解和对传统金融能力的有效结合,现在其智能投顾产品管理的资产是Betterment的近五倍。

最后支宝才简要介绍了TalkingData的解决方案和产品服务,他表示TalkingData愿意以其在数据智能领域的能力和经验,帮助国内券商实现财富管理业务转型和升级。

TalkingData落地苏州,赋能苏州大数据产业发展

 

苏州移动大数据新媒体创新基地(七月知著空间)是由国内领先的第三方数据智能服务商TalkingData与新媒体公司WeMedia联合和悦资本、丛蓉资本共同打造。基地将充分发挥TalkingData和WeMedia在大数据领域和新媒体领域的巨型平台实力,致力于在园区进行新媒体和大数据领域的产业布局,引进一批行业领军企业,打造国内一流大数据新媒体产业集聚区。

开幕式上,TalkingData创始人兼首席执行官崔晓波表示,TalkingData认为大数据和新媒体必然会慢慢走向融合,构成产业热点,互相间会有非常多的协同效应,今年也看到市场中已经形成了非常多的实际案例。他说,将把苏州当成自己的一个家、当成TalkingData的一个基地。接下来,希望与WeMedia一起,用TalkingData积累的能力、知识、数据、人才,来赋能苏州工业园区。

TalkingData创始人兼首席执行官 崔晓波

苏州独墅湖科教创新区管委会主任蒋卫明为开幕式进行了致辞。他表示,相信随着基础设施和整体环境的不断优化,基地必定能吸引更多的行业精英聚集到苏州工业园区这块沃土。大数据的应用,也将从新媒体产业拓展到金融、交通、教育等不同领域。

苏州独墅湖科教创新区管委会主任 蒋卫明

WeMeida董事长兼CEO李岩也参加了此次开幕式,他表示WeMeida时刻在拥抱整个时代的变化。他提到,WeMeida已与TalkingData共同成立了数据公司,希望在大数据的支撑之下,为新媒体内容提供一个更好、更准确的价值输出平台。

WeMeida董事长兼CEO  李岩

现场,TalkingData创始人兼首席执行官崔晓波与苏州工业园区科技和信息化局局长许文清共同为TalkingData苏州分公司揭牌,还与苏州工业园区科技、苏州独墅湖科教创新区、WeMeida、和悦资本、七月知著空间等合作伙伴共同为大数据新媒体产业基地成立剪彩。

关于TalkingData

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