TalkingData林逸飞:私域流量运营将成为未来零售企业生存之道

近日,由36氪《零售老板内参》主办的「创鉴未来——2018 WISE 零售未来峰会」在北京成功举办,TalkingData合伙人&执行副总裁林逸飞在大会上发表了题为《零售行业私域流量构筑》的主题演讲,与众多零售业大咖与行业精英分享了TalkingData在私域零售运营方面的洞察与经验。

如今,作为零售行业不可忽视的两大巨头,阿里和腾讯分别代表着中心化和去中心化两种不同的战略,阿里通过投资持续深入产业链的各个细分领域,腾讯借助社交积聚了巨大的流量矩阵势能。而在行业大势中努力求生存的零售企业则要面临两种战略的持续博弈。

林逸飞指出,在过去的五、六年中,所有线上交易流量已经接近线上交易容量的天花板,很难再有所突破。根据数据统计,在总体消费者人群中,线上习惯消费人群占比9%,线下习惯购物人群占比15%,而全渠道购物人群占比则高达76%。对于这部分购物人群的争夺,也将成为未来零售行业的主战场。

在刚刚过去的双十一中,全网线上销售额达到了3153亿,其中天猫与京东就横扫了其中的85%。但同时我们也能在各种公开信息中看到,在过去的五年里,阿里的线上获客成本翻了6倍,而京东的也翻了1.5倍。这说明,即便自身已经掌握大量流量,如果不能精耕细作的运营,想从中获客与创收也并非易事。

注:点击查看大图,下同。

那么,面对这样的行业现状和发展趋势,零售企业应该如何应对?尤其是在如今的“新零售”、“智慧零售”时代,在零售企业积极进行数字化转型的过程当中,是否能够建立起可管理的企业自有流量,并为业务提升带来实际驱动力呢?

基于丰富的零售行业服务经验,TalkingData提出了一个概念:私域流量运营。林逸飞通过这面这张图对零售企业私域流量运营的策略进行了详细解读。

林逸飞认为,首先要做的就是整合和打通交易/会员数据这样的内部数据与行为/社交数据这样的外部数据,形成数据资产赋能企业数据中台,也就是企业私域流量池。再用私域流量去赋能品牌策略中台,借助丰富的流量运营手段去实现流量放大,再将流量沉淀回私域流量池、将数据沉淀回数据资产,形成闭环持续赋能。

其中最重要的就是构建基础数据能力,能够用数据对每个流量进行跟踪、分析、优化、沉淀,形成数据运营闭环和私域流量运营闭环,并以数据闭环驱动流量闭环实现全局闭环运营。

随后,他以实际案例介绍了私域流量运营所实现的成效。

案例一:某服饰集团基于策略中台(CDP&CEP)的私域流量运营

一家在中国有几千家门店、一年4万SKU的服饰集团,在TalkingData的帮助下构建了整体策略中台,制定全渠道私域流量建设战略,提高私域流量数字化运营能力。通过线上与线下、自有与外部数据的整合打通,针对不同目标人群、选择不同媒体矩阵进行精准的营销触达,并根据评估优化投放效果,借助上下两环的闭环,该集团在今年夏季的一次营销活动中实现了51万购买人数、近4亿GMV、64万订单量以及94倍ROI的优异成绩。

案例二:某时尚女装品牌客户数据平台(CDP)驱动的跨界社交裂变流量运营

基于合作打造的数据平台,TalkingData帮助某高端时尚女装品牌进行了深入的客户人群的探索,并针对目标客群特点选择了小众流量渠道,用小程序裂变推广和H5裂变推广等方式,在不久前的双十一预热活动中,仅仅以3万元的活动成本,就实现了800多万元的销售额。

最后,林逸飞分享了基于TalkingData技术+平台构建的私域流量运营整体方案。在TalkingData数据、数据智能市场、数据中台与策略中台以及众多数据应用的基础上,帮助企业通过数据指导业务,目前在零售、汽车等等行业已经有很多合作企业。

林逸飞总结道,孙子兵法中有“善战者求之于势”的说法,零售是一个快速变化且硝烟四起的行业,零售企业需要洞察并制定大势之下的相应策略,更需要通过数据赋能企业运营,以应对变化多端的线上线下市场发展。

崔晓波再任京东数字科技JDD大赛导师,助力数字科技创新探索

11月20日,JDD-2018 京东数字科技全球探索者大会在中国国际展览中心新馆举办,总奖金达到220万元的 JDD-2018 京东数字科技全球探索者大赛也正式拉开帷幕。TalkingData 创始人兼首席执行官崔晓波出席了此次大赛的启动仪式,并将再次担任大赛导师,为参赛团队提供指导。

在去年举办的首届 JDD 大赛上,崔晓波与国际人工智能联合会主席杨强、红杉资本中国专家合伙人车品觉以及前微软亚洲研究院城市计算领域负责人、现京东智能城市研究院院长郑宇共同担任大赛商业组导师,还为参与“登录行为识别”赛题的参赛团队提供了48小时的贴身辅导。

崔晓波表示,很荣幸再次担任 JDD 大赛导师,希望在此次大赛中与更多顶尖参赛团队碰撞出新的火花。在会后的媒体专访中,崔晓波提到:“与一些偏学术研究的算法竞赛不同,JDD 大赛更具有实战性,不仅在赛题设计上会从实际商业场景遇到的实际问题出发,还能够将大赛中产生的解决思路与算法模型应用在实际生产环境中,这也是 TalkingData 非常看重 JDD 大赛的原因”。

TalkingData 近年来在国际数据科学社区以及算法竞赛活动中非常活跃,与国际领先竞赛平台与数据科学家社区 Kaggle 达成战略合作,前后两次联合举办国际算法大赛,还在Kaggle上建立了中国数据集专区。崔晓波认为:“算法竞赛是数据科学与行业应用结合的最前沿,一方面可以加速创新算法模型的产生、行业潜在应用场景的挖掘,另外也为发现数据科学家人才提供了平台和机遇。”

崔晓波还表示,美国与欧洲在数据科学方面拥有领先科研水平和丰富人才资源,而中国拥有大量数据集资源、应用场景和实际业务问题。通过与国际数据科学社区的交流互动以及与国际前沿科技企业的合作,TalkingData 致力于连接和融合双方资源优势,产生更大、更广泛的价值。

除了 JDD 大赛的合作之外,TalkingData 还与京东数字科技(原京东金融,下同)在大数据平台以及应用数据支撑等方面进行了密切合作,在包括信贷、反欺诈、风险管理以及营销等应用场景中有成功的落地案例。

JDD-2018 京东数字科技全球探索者大会由京东集团、京东数字科技联合主办,KDD China 为学术指导单位,APEC 中国工商理事会青年企业家委员会为支持单位。大会旨在连接科技界、产业界、金融界、学术界、投资界五大圈层,搭建一个全球化的开放平台,共同探索数字科技创新之道与实体经济数字化升级之路。大会上,京东数字科技 CEO 陈生强宣布京东金融品牌正式升级成为京东数字科技,将继续保持以金融业务为核心板块,并为更多的产业提供服务。

TalkingData CEO崔晓波:赋能合作伙伴 数据核心是连接

在近日举行的 JDD-2018 京东数字科技全球探索者大会上,“京东金融”品牌正式升级为“京东数字科技”。前来为 JDD-2018 大赛揭幕并再次担任导师的 TalkingData CEO崔晓波在接受采访时表示,京东金融和 TalkingData 在大数据平台、应用数据支撑及营销获客场景等方面有着较多合作案例。

崔晓波表示,近两年科技企业和持牌机构的合作呈现出逐渐深化的发展态势,并且合作模式正在不断推陈出新。

“无论是最早发展金融业务,还是如今大数据、AI 及区块链前沿的科技赋能,开展合作都能弥补传统持牌机构在研发上的不足。”崔晓波说,此前 TalkingData 与京东云达成战略合作,并实现了数据的互联互通,在智慧城市领域打造了多个成熟应用。

在崔晓波看来,京东云作为云基础设施提供商,在政务应用、智慧城市以及营销场景结合方面拥有较为领先的技术水平,TalkingData 与京东云在智慧城市特别是文旅大数据应用等方面开展业务试点,且拓展速度较快。

“我们向京东云提供了 SaaS 级别的数据应用,包括营销云、智能选址模式等,京东云也在使用我们的模块赋能其生态上的企业。”崔晓波说。

崔晓波认为,科技企业乃至互联网持牌机构都离不开三点:一是数据,二是先进的科技平台,三是运营赋能。“从基础能力上看,有些公司会更加专注于某一点。但从整体业务模式来看,基于业务场景实现的综合能力则是大趋势。”

在今年9月举办的“T11数据智能峰会”上,崔晓波强调了对开放生态的重视,并发布了 TalkingData 数据中台。他认为,“数据中台最核心的思想和检验标准是共享能力。所谓‘中台’,就是希望把需要共同使用的能力或算法模型能够放在共用的数据平台上,从而达到分享及资源优化的目的。”

在崔晓波看来,数据中台的核心是连接,而不是拥有。数据中台用新型的技术方法把数据连接在一起,构建在满足隐私保护及数据安全需求的基础之上,这是数据中台的基础,也就是“数联网”。

来源:新华网

TalkingData高铎:展望智能营销 3.0

近日,第五届世界互联网大会·乌镇峰会成功举办,来自近百个国家和地区的政府代表、互联网企业领军人物、互联网名人、专家学者汇聚一堂,围绕“发展数字经济促进开放共享——携手共建网络空间命运共同体”的主题,积极贡献思想智慧,聚焦即将到来的互联网下半场——产业互联网,共同探讨和交流如何深化互联网和数字经济、传统产业合作。

TalkingData 副总裁高铎在《大数据与人工智能赋能实体经济——产业创新与投资专题对接会》上与现场嘉宾们分享了主题为《人工智能赋能数据营销 3.0》的演讲。

TalkingData副总裁 高铎

高铎认为,“智能营销是三个时代的共存:第一,被动式营销时代;第二,主动式营销时代,第三,全域式营销时代。在这三个时代里, Data+AI 贯穿始终,我们目前都在全域营销中寻求突破”。

智能营销1.0——PC 时代

智能营销 1.0( PC 终端为主要载体)是被动式广告为主,以搜索广告为代表。用户搜索关键词时,平台会推出相关广告,在用户体验上属于被动接受。其特点是 NLP 相关的 AI 技术和 RTB 为主导的广告技术,底层以 Cookie 为 PC 终端标识延展出在浏览器上生存的各类网盟广告。但由于 Cookie 固有的易变特征,此类广告只在短期内有效。

智能营销2.0 – 移动互联网时代

智能营销 2.0 (移动智能终端为主要载体)是主动式广告时代,以信息流广告为代表。平台根据用户阅读的内容和兴趣,主动推送广告内容。它的主要特点是结合用户使用行为,“不知不觉”地进行广告触达。其主要存在于各类内容 App 的使用场景中,由于具备相对稳定的智能终端广告标识,其广告的持久性和可拓展性都远超过 Cookie ,能持续跟踪广告的效果和根据行为特征快速锁定目标受众( TA )。

智能营销3.0 – 数据连接时代

智能营销 3.0 可以称之为全域式广告时代,它存在于用户身边的四个屏幕里:手机、PC、OTT 以及车载 AVN 屏幕。通过四屏设备的底层广告标识打通,基于人群兴趣偏好和关注点预测,在四屏的不同使用场景中进行广告推送。

其广告展示逻辑、竞价体系等方面和前两个时代都大体相当,其技术的核心在于不同终端底层广告标识的打通,通过相对安全稳定的数据连接技术,打通终端后,能够更详细、更全景的刻画人的行为特征。但是在中国,很少有设备厂商、系统厂商能够像苹果一样拥有相对完备的产品生态,TalkingData 作为数据智能公司,在底层数据连接上积淀多年,帮助很多客户构建基础的数据连接体系。

全域式广告时代的核心在于数据连接,背后需要考虑两个关键点:

其一,数据安全性,保证数据处理、传输和使用过程中是加密的、脱敏的、不可逆的。其二,数据使用灵活度,因为前端的业务在不同的屏幕,需要有足够的灵活度支持多元化业务。数据营销闭环

我们分析目前的智能营销,是 1.0、2.0、3.0 共存的。在营销的三个时代里,营销闭环的逻辑贯穿始终。具体说就是通过 TA 目标人群贯彻整个营销过程,自始至终我们简化为五个环节:

TA分析,作为一个品牌广告主,要投的时候目标人群在哪里,怎么找,怎么评估TA触达,找到了目标人群之后怎么去触达,怎么让他看到我带来品牌的感知能力和广告。TA评估,品牌广告主评估触达的效果、转换的效果。TA迭代,看到了效果,知道了哪些人群、以及哪些创意是有问题的,又有什么相应的能力去帮助迭代TA选择,迭代之后就可以进行跟进,结合原有的数据能力再一次选择新的人群。最后,高铎表示:“广告业的经典语录是,知道广告费一半浪费了,但不知道是哪一半。如果能通过数据做到全闭环透明营销,如果能通过数据连接能力实现多屏幕全域营销,就会对营销预算作出更加契合消费者行为的分配。”

举个例子丨什么是量子计算机?比常规计算机强在哪里?

作者:YK Sugi

译者:赵磊

原文链接:http://t.cn/EZAElk0

本文作者访问了加拿大温哥华的一家名为 D-Wave System 的制造尖端量子计算机的公司,并在那里学习了很多关于量子计算机的知识。

在这篇文章中,作者将通过一个简单地例子让没有物理或计算机科学知识地小伙伴也能搞懂什么是量子计算机,欢迎分享~

1什么是量子计算机

量子计算机是一种使用量子力学原理进行计算的计算机,它能比常规计算机更有效地执行特定类型的计算。

听的是不是有点云里雾里?不是说好了没有物理学或计算机科学知识也能听懂吗?别急,这里将通过一个简单的例子来告诉大家,它到底是什么。

为什么解释什么是量子计算机,首先就需要解释一下常规(非量子)计算机。

2存储信息方式有何不同

一台普通的计算机以 0 和 1 的 序列存储信息,不同类型的信息,如数字、文本和图像都可以使用这种方式表示,这种由 0 和 1 组成的序列中的每个单元都被成为比特位,所以,比特位可以设置为 0 或 1。

量子计算机不使用比特位来存储信息,相反,它使用一种叫量子位的东西,每个量子位不仅可以设置为 1 或 0,还可以设置为 1 和 0。那这到底意味着什么呢?这里用一个简单的例子来解释这个问题:

假设我们在经营一家旅行社,需要把一群人从一个地方搬到另一个地方。

为了简单起见,假设现在只需要移动3个人—— Alice、Becky 和 Chris。我们为此预定了两辆出租车,但想知道谁上了哪辆出租车。另外我们也得到了关于谁和谁是朋友,谁和谁是敌人的信息。

这里我们假设:

  • Alice 和 Becky 是朋友
  • Alice 和 Chris 是敌人
  • Becky和 Chris 是敌人

我们的目标是把这3个人分成两组并实现以下两个目标:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

这是这个问题的基本前提。我们首先考虑如何用常规计算机解决

3用常规计算机去解决问题

要用普通的非量子计算机解决这个问题,首先需要弄清楚如何用比特存储相关信息。

我们把这两个出租车标记为出租车 1 号和出租车 0 号。

然后,可以用3个比特位表示谁进入哪辆车。

例如,我们可以通过将这3位设为0、0 和 1 来表示:

  • Alice 在 0 号出租车
  • Becky 在 0 号出租车
  • Chris 在 1 号出租车

因为每个人有两种选择,所以有 2x2x2 = 8 种方法将这群人分到两辆车上。

这里列出了所有可能的情况:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

使用3个比特位,就可以表示这些组合中的任何一种。

计算每个配置的得分:

现在,使用常规计算机,我们如何确定哪种配置是最好的方案呢?

为此,我们需要定义如何计算每个配置的得分。这个分数将代表每个解决方案达到我前面提到的两个目标的程度:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

我们简单定义分数如下:

给定配置的分数 = 共享同一辆车的朋友对数 – 共享同一辆车的敌人对数

例如,假设 Alice、Becky 和 Chris 都乘坐出租车1号。用三个比特表示为 111。

在这种情况下,只有一对朋友共用一辆车—— Alice 和 Becky。

但是却有两对敌人共用一辆车——Alice 和 Chris 以及 Becky 和 Chris。

所以,这个配置的总分为 1 – 2 = -1。

解决问题:

有了这些,我们终于可以着手解决这个问题了。

对于一台普通的计算机,要找到最好的配置,需要遍历所有配置,看看哪个达到了最高分。

构建的表格如下:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最佳解决方案之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最佳解决方案

1 | 1 | 1 | -1

这里有两个正确的答案——001 和 110,都达到了 1 分。

这个问题相当简单。但是随着越来越多的人参与到这个问题中来,用一台普通的电脑很快就会变得难以解决。

可以看到如果是3个人,需要遍历8种可能的配置。

如果有4个人呢?我们需要遍历 2x2x2x2 = 16 个配置。

对于n个人,我们需要通过遍历2的n次方个配置来找到最佳解。

所以,如果有100个人,我们需要遍历:

2¹⁰⁰ ~= 10³⁰ 个配置

因此这是常规计算机根本无法解决的问题。

4用量子计算机去解决问题

那么如果我们用量子计算机来解决这个问题呢?

让我们回到把3个人分到两辆出租车的例子。

正如我们前面看到的,这个问题有8种可能的解决方案:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

用一台普通的计算机,用3个比特位,一次只能表示其中一个解——例如 001。

然而,使用量子计算机,通过3个量子位,我们可以同时表示所有8个解。

关于这个说法的确切含义存在争议,但作者的看法是这样的:

首先,来看这3个量子位中的第一个量子位。当将其设置为 0 和 1 时,就好像创建了两个并行世界。

在其中一个平行世界中,量子位被设置为 0,而在另一个平行世界中为1。

现在,如果再把第二个量子位也设为 0 和 1 呢?就像是创造了4个平行世界。

在第一个平行世界中,两个量子位被设置为 00,第二个平行世界中是 01,第三个平行世界中是 10,第四个平行世界中是 11。

类似的如果将这三个量子位都设置为 0 和 1 ,就会创建8个平行世界——000、001、010、011、100、101、110 和 111。

虽然这是一种奇怪的思考方式,但它是解释量子比特在现实世界中的行为的正确方式之一。

现在,当对这三个量子位进行某种计算时,实际上是在同时对这8个平行世界进行同样的计算。

因此,我们可以同时计算所有解的分数,而不是按顺序遍历所有这些可能的解。

有了这个特殊的例子,理论上量子计算机可以在几毫秒内找到最好的解——001 或 110,正如我们之前看到的:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最优解之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最优解

1 | 1 | 1 | -1

实际上,要解决这个问题只需要让量子计算机去做两件事:

  • 所有可能的解都用量子位表示
  • 将每个可能的解转化成分数的函数。在本例中,这个函数计算共享同一辆车的朋友对和敌人对的数量。

具备了上述两个条件,量子计算机将在几毫秒内给出其中一个最好的解决方案。在本例中,分数为 1 的是 001 或 110。

现在从理论上讲量子计算机每次运行都能找到最好的解。

然而,实际上在运行量子计算机时有可能存在错误。所以,它可能会找到次优解,次次优解,等等。

随着问题变得越来越复杂,这些错误变得越来越突出。

因此,在实践中可能需要在量子计算机上运行相同的操作数十次或数百次。然后从结果中选出最优解。

量子计算机的改进之处:

即使有一些缺陷,但量子计算机也不会遇到常规计算机那样的计算规模问题。

当有3个人需要分到两辆车上时,需要在量子计算机上执行的操作数是1。这是因为量子计算机同时计算所有情况的分数。

当有4个人的时候,操作的次数仍然是 1。

当有100人的时候,操作的次数仍然是 1。仅仅一次操作,量子计算机就能同时计算出2¹⁰⁰ ~ = 10³⁰ 种情况的分数。

而正如之前所说,在实践中最好运行量子计算机几十次或几百次,然后从得到的结果中选出最好的结果。

5总结

D-Wave Systems 最近推出了一个与量子计算机交互的云环境。

如果你是一名开发人员,并且想使用量子计算机,可以尝试这种简单的方法:

  • 名称:Leap
  • 地址:https://cloud.dwavesys.com/leap

可以免费使用它来解决很多问题,并且在注册后还可以看到很多关于量子计算机的相关教程。

备注:在本文中,作者使用术语“常规计算机”来指代非量子计算机。然而,在量子计算行业中,非量子计算机通常被称为经典计算机

技术专栏丨Fabric和Sawtooth技术分析(上)

背景

Fabric 和 Sawtooth 是 Hypherlegder 的两个重要企业级项目,在国家鼓励区块链无币化的当下,受到了广泛的关注。当我们希望改造传统项目,实现多方数据自动化对账、自动化运维等功能时,它们往往成为了最佳的选择。但它们各自有什么特点,又应该如何选择呢?本文将分别分析这两个项目的结构和特点,又对它们进行了比较和总结。

区块链本身和虚拟货币(Token)没有任何关系,比特币,Ethereum 等引入虚拟货币所起的作用是费用计量,并通过费用来控制用户对资源的使用权限。在传统互联网体系结构中,访问权限的实现方式并不是只有通过货币一种。所以,区块链的应用价值本质上还是取决于它能做什么,或者说它是否可以作为一种通用技术广泛服务于商业领域,并提供现有系统无法实现的功能。

当然,有人看到 Fabric 框架的问题以后,选择自己改动其中不合理的部分。假如A看到了问题,项目开发者也看到了,随后B在新版本中进行更改,而且改法与A不同,那样就会有版本更新的风险。所以最合理的方式还是尽量不改要动现有项目的核心部分,而是搞清楚之后,再进行合理的选择。从最后的比较结果看,笔者是强烈推荐 Sawtooth ,因为从通用性,灵活性角度看,几乎找不到 Sawtooth 的缺点。

本文将分为上下两部,本篇将讲述 Fabric 的相关内容,下一篇将为小伙伴们带来 Sawtooth 的相关内容敬请期待。

一、Hypherlegder Fabric 的分析

Fabric 是 IBM 公司推出的企业级区块链,2017年 IBM 将其贡献给 Hypherlegder 项目。本文将主要从 Fabric 产生的原因,Fabric 的特点,和 Fabric 的结构及工作流程做简要介绍。

Fabric 产生的原因

Fabric 的诞生主要是因为在金融、销售、供应链等特殊应用领域中,一些机构的数据不能公开,而且并不是所有的机构都有权力发起 Transaction。而在 Fabric 诞生之前,主流的区块链结构 Ethereum 的体系结构不能满足数据的隐私与访问控制需求。正是看到这一机会,IBM 在2017年推出了 Fabric。这之前其实有个插曲,2014年美国几十家银行成立了一个 R3 区块链联盟,目的就是满足金融领域中带有特殊访问控制和隐私保护需求的区块链技术,结果2017年,R3 觉得当隐私保护和访问控制需求变为主流需求后,区块链并不是必须的,于是把自己从“区块链新创公司”改成了“受区块链启发的新创公司”。

所以,在分析 Fabric 时也不必把“区块链”这种新存储结构看得和传统结构有什么不同,因为 Fabric 主要是要弥补在它出现前的技术的不足。从体系结构角度看,Fabric 其实并不新颖。

Fabric 的特点

Fabric 把区块链分为需要许可的和不需要许可的区块链(Permissioned vs Permissionless Blockchains)。众所周知参与 Ethereum 的用户是匿名的,也就是任何人都可以参与,所以 Ethereum 是不需要许可的区块链,向 Ethereum 网络中提交一个合法的(只要有以太币即合法) Transaction,所有节点都会独立执行合约(根据数据)得到输出并生成区块。对 Ethereum 这种不需要许可的区块链来说,由于程序和数据在所有节点上执行,跟本没啥保密可言。这对很多应用是不行的,比如,做销售,供应的,哪里还有底价一说,大家知道的都一样。还有用户位置、等等隐私数据也不能全网暴露。

Fabric 针对不需要许可的(Permissionless)区块链存在的问题提出需要许可的(Permissioned)区块链,简单来说,就是在所有节点中选择一部分,形成一个个的联盟,特定 Transaction 只在联盟内的节点独立运行,这样只有经过选择的特定节点参与执行 Transaction,数据只在这部分节点范围内公开,这样隐私和访问控制就有可能缓解了(与Ethereum相比,效率提高也是自然的,虽然不是 Fabric的主要目标)。

具体怎么解呢:配置文件。在不同的配置文件里写好访问控制逻辑即可,谁可以做什么一目了然。这里 Fabric 假设,进到联盟中的就没有坏人了,不会有节点通过有问题智能合约捣乱。为此,Fabric 提供了一套 CA ,确保联盟内任何人的身份都是可以验证的,其行为,包括修改网络设置,部署智能合约等可以被记录在区块链上,并且有人为其背书。这就可以识别出捣乱的人。

Ethereum 等技术是遵循顺序执行的体系结构 (order-execute architecture) 的。需要先验证所有 Transaction 的执行顺序,然后把状态复制到所有节点上,然后每个节点各自顺序执行。简单来说就是在架构上就没考虑过 Transaction 的并行。Fabric 引入了一种称为(execute-order-validate)的架构。先执行 Transaction 然后再检查它的正确性,然后为其背书;通过可插拔的共识协议给 Transaction排序;在提交给账本前,用应用程序描述的背书策略(application-specific endorsement policy)验证 Transaction。这里所谓“程序描述的背书策略”是指哪些节点,多少节点,需要保证给定智能合约执行的正确性。这种结构允许 Transaction 并行执行,提高了效率,因为非确定性的(non-determinism)、不一致(inconsistent)的结果可以在排序(ordering)前被过滤掉,使得 Fabric 可以支持标准编程语言(standard programming languages),智能合约可以用 Go 或者 Node.js 来写,将来也支持 Java。

当我们面对隐私保护需求的时候,可能有不同的解决方法。Fabric 列出了下面几种:

1) Fabric 认为,一种是数据加密。但由于加密数据被部署到每个节点上,只要给定足够的时间和计算资源,加密可以被破解。(这显然是Fabirc的设计者想当然,但 Fabric 把它作为 Permissioned 体系结构存在意义的证据)。

2) Fabric 认为,另一种是零知识证明,但零知识证明需要相当可观的时间和计算资源。

所以,为了解决数据的访问控制与隐私保护问题,Fabric提出了一种称为 channel 的体系结构,只有参加 channel 的 nodes 有权访问 smart contract(Fabric 称为 chaincode)和数据。(在我印象中,76年现代密码学的开山之作就是说怎么干这事,说是 Fabric 提出的,不太合适,但 Fabric 确实是用这种方法在网络中隔离出一个个的联盟)。

Fabric 的网络结构

下面是一个 Fabric 示例网络结构图。图中的字母:R代表 organizations,图中共有 R1、R2、R3 和 R4四个组织(organizations)。P代表 Peer node,P1 隶属于 R1。S 代表 Smart Contract,L 代表 Ledger,图中 L1,S5 物理部署于 P1 上。C 代表 channel。NC 是n etwork configuration。CC 是 channel configuration。CA 是 Certificate Authority。A 代表 Client application,这里是用户操作的界面。O 是 ordering service,或者叫 orderer。

放眼过去,是不是觉得很杂乱?不要急,接下来 Fabric 会告诉我们怎么一步步形成这样的复杂体系结构。先来看图中的 R4 以及它的网络配置文件 NC4,以及排序服务O4,和提供身份服务的 CA4。NC4 包含初始网络管理能力设置的策略。简单点说,就是 R4 有权配置网络。CA 的功能比较简单,基本上众所周知,就不再赘述了。

接下来增加一个新的组织 R1 和为 R1 内用户提供身份服务的 CA1。此时,可以由 R4 修改配置文件 NC4,令 R1 具有和 R4 一样的管理权限。

在联盟的基础上,就可以创建 channel 了。C1 表示 channel ,根据CC1 创建。它是联盟内部成员之间的主要通信机制。这里联盟内有 R1 和 R2,CC1 由它们控制,R4 不能参与。注意,C1 需要与 O4 相连。这样的目的是,只要能连上 O4,就能与 C1 连接的节点通信。

接下来,Peer node P1 连接到 channel,它可以通过 C1 与 O4 通信。注意,L1 物理部署在P1上,从数据存储角度,可以把 L1 看做待访问资源。逻辑上,L1 可以被所有能够连接到 C1 的节点访问。加入过程是通过 P1 发送一个连接 C1 的请求给 O4,然后 O4 根据 CC1 的策略设置决定 P1 可否连接 C1。

接下来,智能合约 S5 可以被安装到 P1 上,P1 可以看到 S5 的代码。R1 中的一个 Client Application A1 可以加入 C1,并通过 P1 执行 S5 来访问 L1。这时,由于 A1 是 R1 的成员,它可以选择连接O4 或者 R1,通过它们中的哪个都可以连接上 P1。S5 由 R1 实现,并在 P1 上安装。而且 S5 还要在 C1 上安装,以便别的 Client Application 可以找到它。

我们可以继续加入资源P2到C1上:

把上图中的C1简化掉,得到下图:

然后可以再增加一个联盟如下图:

然后再在新联盟内建立一个 channel 如下图:

在新 channel 上连接新的资源 P3 如下图:

此时,P2 既可以被 C1 内节点访问,也可以被 C2 内节点访问,可以把 P3 上的资源同步到 P2 上,如下图:

这样就得到了开始看到的网络结构图。

通过上述网络结构可以看到,Fabric 的访问控制机制大体上分为两层,一层是关于安全的,或者叫成员服务,也就是说画个圈,把成员划进来。另一层是关于隐私的,意思是一个 Transaction 可以指定由所有成员中的一部分来执行,这样别人就看不到程序和数据了。

Fabric 的通信流程

我们先看看Client Application请求资源的流程,如下图:

首先,通过 orderers ,Peers 确保 Ledger 总是保持最新状态。以 A调用 S1 来查询或者更像 L1 为例,P1 收到合法调用请求后,调用 S1 生成一个应答。A 在收到应答。如果是查询请求就结束了。如果是更新请求,A 在它收到的所有应答基础上构造 Transaction 发给 O1 。O1 收集网络上的 Transactions,并且分发给所有 peers,包括P1 。peers 验证 Transaction,通过后更新 L1,然后生成一个事件。

接下来,我们再看看通信的具体流程:

endorsing peer 主要是给 client 背书的。它的功能是验证,然后再签名,有些 endorsing peer 可能不在线,有些可能不理 client。client 在收集到足够的(达到背书策略要求的)背书 endorsing peer 后,把 transaction 发给 orderer。orderer 再把 transaction 发给具体执行智能合约的 committing peers。这里 Fabric 说得不够细致,orderer 在这样的通信流程中是很重要的,如何保证 orderer 在处理这些来自不同节点的信息的时序性呢。Fabric 没说清楚,我们只能假设它做到了。但这是隐患,在分布式系统中保持全局时序一致性并不容易。

我们知道,更新 Transaction 和查询 Transaction 是不同的,更新涉及到写入操作,需要所有相关节点达成共识后才能执行,一个 peer 是不能更新 Ledger 的。所以,为了实现共识,Fabric 更新涉及到3个阶段。

Phase 1: Proposal:Transaction proposals 被每个返回背书 proposal 的 peer 独立执行。

A1生成 Transaction T1 带 proposal P,然后发给 channel C 上的 P1 和 P2 。P1 执行 S1 使用 T1 带 P,以 R1 带 E1 相应。P2 执行 S1 使用 T1 带 P,以 R2 带 E2 相应。A1 收到这两个响应。

Phase 2: Packaging:orderer 的第一个角色是给 proposed ledger updates 打包。

A1 发送由 E1 和 E2 背书的 Transaction T1 给O1。并行的 A2 发送由 E1 背书的 Transaction T2 给 O1。O1 把来自 A1 的 T1 和来自 A2 的 T2,以及其它可能得 Transactions 打包 到 Block B2 中。我们可以看到 transaction order 是T1、T2、T3、T4、T6、T5。

Phase 3: Validation:orderer 的第二个角色是把 Block 分发给 peers。

O1 把 block B2 发给 peer P1 和 P2 。P1 处理 B2,添加一个新的 block 到 P1 的 L1 上。并行地,P2 也处理 B2 ,添加一个新的 block 到 P2 的 L1 上。一旦这一过程完成,L1 就在 P1 和 P2 上被一致更新了。然后它们分别通知自己连接的 applications ,Transaction就被处理了。

账本示例:fabcar

fabcar 是一个 Fabric 的例子应用,执行它会创建如下 Ledger 。该例子创建一个 car 的集合,有不同的颜色、制造商、牌子、所有者。

账本 L 包括一个 world state W 和一个区块链 B 。W 包含4个状态,key 是 CAR1、CAR2、CAR3 和 CAR4。B包含两个blocks:0 和 1。Block 1 包含4个 Transactions T1、T2、T3、T4。

总结

看完 Fabric 结构流程等介绍,笔者的第一个感觉是 Fabric 对标的是 Ethereum ,它所有的技术、结构等的设计都是为了解决 Ethereum 中的问题,可以看到它确实做到了。

所以,给人一种直观的感觉是 Fabric 不像是一个通用企业级架构,而是一个企业级的解决方案。Fabric 定义的 Transactions 有两类,一种叫 Deploy transactions,是用来部署 chaincode 的。另一种叫 Invoke transactions,是用来执行已经部署的 chaincode 的。从这里的 Deploy transactions 设计可以看出,Fabric 已经有把 Transaction 本身作为 on-chain 的设计思想了,但总体上却大量依赖配置文件,并未充分利用区块链本身实现对区块链的配置。

因此让人感觉虽然 Fabric 可以实现预设的功能,但如果想稍作改动(实际情况中的常态),配置文件的管理可能隐藏很多潜在问题。Fabric 中的 Ordering service 是一个关键。它为 clients 和 peers 提供了共享的通信 channel,为包含 Transaction 的消息提供广播服务。Client 连接 channel ,可以广播消息到所有 peers 。换句话说,channel以相同的逻辑顺序将同样的消息发送给所有与其相连的 peers 。

简单来说它的功能就是按照当前配置文件中设定的网络结构,或者说控制结构规则将收到的消息或者交易转发给相应的节点。order 非常像现在网络中的路由器,或者说入口网关。Fabric 的并行化更像是传统电脑中的进程级的并行,针对的改进对象是单用户没有并行功能的系统。

TalkingData CTO 到任,快来认识下吧

大家好,我是TalkingData的程序员小D。是的,我又来客串小编啦!今天呢,主要是想跟大家分享一个我司的大新闻——

前Splunk全球工程副总裁王亭先生加入TalkingData并担任CTO(首席技术官),全面负责产品研发管理工作。

就是这位,快来认识下吧!

TalkingData首席技术官 王亭

王亭先生在企业软件产品研发、技术创新及团队管理方面有着非常丰富的实践经验,曾在多家世界500强公司及北美知名大数据公司承担重要管理工作。

在加入TalkingData前,王亭先生就任于大数据业内首家上市的知名创新公司Splunk,担任高级工程总监以及全球工程副总裁,主导Splunk首个美国以外的上海研发中心从0到1的组建,打造起一支世界级研发团队,成功交付SaaS分析产品以及移动解决方案创新;后又调任硅谷总部负责Splunk数据生态产品和解决方案研发。

此外,王亭先生还曾担任SAP Business Intelligence Group全球副总裁,主导Business Objects Dashboards和Crystal Reports两项关键产品研发以及新一代SAP数据可视化平台创新;并曾任EMC Documentum Group中国研发负责人,管理企业搜索、核心工程及内容管理创新的研发团队。

对于这一重要的人事任命,TalkingData CEO崔晓波先生可谓信心满满,他在内部信中提到:“王亭先生的加入将显著提升TalkingData在数据工程、数据科学、数据产品等方面的核心能力。王亭先生拥有深厚的行业经验以及管理经验,也将帮助TalkingData提升研发管理水平以及团队效率。”

在9月举办的T11 2018暨TalkingData数据智能峰会上,我们重磅发布了SmartDP 2.0——TalkingData数据中台。此次王亭先生就任CTO,不仅将强化TalkingData的产品研发能力,也将重点推动数据中台战略后续的发展和落地。

小D代表全体TDer热烈欢迎王亭先生加入!在王亭先生的带领下,小D和TalkingData全体产品研发小伙伴们也会更加努力,为大家带来更高更快更强的数据能力,敬请大家拭目以待。

新闻播报完毕,我们下回再见!

备受瞩目的智能营销到底带来了什么?营销人才会被替代吗?

营销是最常见的经济活动之一,因为有商品,就得有营销。

在商业活动和科技不断发展的过程中,营销也在不断发展变化。从最简单的招牌、广告,再到广告植入、热点营销、社群营销……营销无处不在,变化多端。

随着移动互联网和大数据技术的日益广泛应用,这个古老的行业正在嬗变:人类历史上从未出现过的大规模精准营销正在成为现实。

信息不对称一直是经济活动中的重要问题。正如在营销领域,人们经常抱怨:“我知道我一半的广告投放费用是在浪费,可是我不知道哪一半是在浪费。”在商品极大丰富、人群需求日益多元的今天,这一问题更为突出。智能营销的发展,使得精准营销正成为可能,将商品信息精准推送给有需求的消费者,这不仅将改变诸多企业,也将改变消费者的生活。

智能营销能带来什么

随着数据维度的不断丰富,应用场景的不断增多,尤其是移动化所带来的位置数据、物联网数据的日趋丰富,数据营销也在快速演进,中国的智能营销时代正在到来。

宝洁首席品牌官Marc Pritchard曾感慨:“尽管在美国市场我们的广告花费就达到了惊人的2000亿美元,但是我们行业的整体增长却严重贫血。”

清华大学经济管理学院营销系助理教授梁屹天说,传统的广告投放方法最大的问题是广告主不知道自己投的广告是否有用,“我知道我一半的广告投放费用是在浪费,可是我不知道哪一半是在浪费。”

但随着科技的发展,这种状况正在被改变。最近几年,在营销行业最火的概念,非MarTech莫属。这一新营销方式不仅在改变诸多行业,也在改变广大消费者的生活。

MarTech是什么

假设,一位老人在某搜索引擎上搜索“健康险”,B保险公司出现在首位,老人点击进入浏览了该公司的各种保险品种,并在“老年健康险”的页面停留最久,填写注册了自己的手机号,但在输入身份证号的时候放弃了。

与此同时,这位老人的行为已被B保险公司所使用的数据公司提供的平台监测到,并通过分析为老人打一个标签,也就是所谓的用户分群。通过特殊标签打包分析后,平台就会给包括这位老人在内的同一标签用户推送“老年健康险”优惠券,这种精准推送就是智能营销的一种。

上述过程就可以被看作是MarTech的一个应用场景。

梁屹天解释,通俗地讲,MarTech就是以数据和多场景的落地能力作为驱动去做营销方案,把推送的内容和消费者作一个匹配,也就是说找到适合的人,推送给他们可能会喜欢的服务,而不仅限于内容。

关于MarTech,要从9年前说起。彼时,Google发布了首个实时竞价广告系统AdEx 2.0,Adobe收购分析工具公司Omniture,开始在数字营销领域开展业务。这两个事件,被业界认为是营销技术出现的标志。

在营销行业的专家看来,在此前后,大数据技术的发展,为MarTech奠定了基础。随着大数据的应用日益广泛,营销人员不再需要按照以往的营销路数去猜客户喜欢什么,而是利用大数据去预测客户需要什么。

当前,开展MarTech业务的公司无不竭尽全力进行数据搜集与整合应用。

TalkingData合伙人兼副总裁高铎表示,拥有足够广度和深度的数据是进入MarTech行业的第一道壁垒,第二道壁垒是如何使用和分析这些数据的技术,第三道壁垒是将数据和技术结合,进而应用在一些场景里解决问题。

TalkingData基于大数据能力推出的“智

营销人才会被取代吗

当MarTech技术发展到一定程度,是否就不需要专业的营销人才了呢?

梁屹天表示,现在一些拥有海量规模大数据的公司并不擅于使用数据。“比如国内某知名游戏公司,尽管拥有庞大的数据,但我惊讶地发现这家企业的很多重要决策都是团队拍脑袋决定的,比如网游里面道具的定价。”

“尽管这家公司可以通过MarTech来给用户进行画像,了解玩游戏的人是哪些群体,有什么特征,进而可以利用这个群体的画像做精准的推送广告内容,但也仅到这个层面。”梁屹天说,“道具如何定价更合理还是没有科学的解决方案。”

梁屹天认为,在未来五到十年,甚至在更长的时间,无论MarTech技术成熟到哪一步,他认为对于经济、营销等专业的复合型人才的需求不会减少反而会增加。

高铎也持相同的观点:“数据公司可以使用计算机自动对某个产品的用户群体画像,但营销的目的不是画像,而是如何增加新客户以及做好老客户的运营,所以如何使用画像才是关键,这不是单纯用技术就能解决的,还要有专业的人才参与。”

中国更有潜力

全球数据营销行业的领军人物、MarTech发起人Scott Brinker用每年的营销科技全景图记录了这一行业的变迁。

2011年,全球仅有150家数据营销公司,包括网站管理、早期的广告技术、搜索营销、邮件营销等公司。

此后,这一领域的公司几乎每年都以翻倍的速度快速增长。2018年,全球从事数据营销业务的企业数量已达7000家。这些公司涵盖了广告和促销、内容和体验、社交与关系、商业和销售、数据、管理等不同领域。

据媒体统计,目前,中国数字经济规模达到22万亿元人民币,预计未来10年会增长到100万亿元,还有大约80万亿元的增长空间。

在8亿网民的推动下,中国的数据营销亦发展迅速。RTBChina发布的报告显示,仅程序化广告技术企业,国内就已经超过200家。

除了备受资本青睐,MarTech也受到互联网巨头的重视。2017年,腾讯在上海举办2017腾讯智慧峰会上就邀请了MarTech概念创始人Scott Brinker发表主题为“MarTech推动智慧营销”的演讲。

随着数据维度的不断丰富,应用场景的不断增多,尤其是移动化所带来的位置数据、物联网数据的日趋丰富,数据营销也在快速演进,中国的智能营销时代正在到来。

高铎认为,MarTech在中国发展更有潜力,因为中国的营销场景是最丰富的,尽管在技术上可能会和国际先进水平有差距,但在应用上中国应该会做得更好。

比如TalkingData与腾讯云联合发布的针对线下商业场景的智能商业选址产品——智选。这是一款将海量数据与机器学习有机整合,旨在解决实体门店的选址、商圈经营等场景问题,为智慧零售及多元化线下产业助力的数据智能产品,帮助企业选择出最合适的地址,而原来开店选址需要大量人力跑到现场,测算车流,了解房屋价格,以及周边消费水平等。

TalkingData 智选

本文转自:《瞭望东方周刊》

作者:徐颖

注:本文略有删改

咨询专栏丨三张PPT讲清如何搭建App数据管理体系

在券商互联网+的浪潮之下,越来越多的证券公司主动拥抱了互联网。互联网的发展给传统券商业务带来了机遇,同时也带来了一些挑战,促使业务部门不得不改变自己原有的工作方式。

传统的证券业务部门在互联网+的进程中,要获得更高的数据赋能,除了转变思路,学习互联网的渠道和运营营销方式,也需要主动习得互联网公司的数据能力。同时,也存在一些仍然不知道应该看什么指标、不同团队如何在关注不同指标的同时协调工作,也不知道如何去拆解指标如何把跟踪数据这件事融入到日常的工作中去的现象。

针对这个问题,本文给出三个自己的思考:

• 应该关心什么数据指标

• 如何开展数据工作

• 提升这些指标的一些要点

No.1 我们应该关心什么指标——搭建三级立体指标体系

一个业务会涉及诸多部门,各部门也有不同的层级。大家关心的点不同,但又需要统一方向,统一目标,向着同一个方向前进。同时,不同岗位的工作的落脚点也是不一样的,不同的工作内容需要有明确可以评估和据此改进的指标。这就需要我们日常跟踪的数据指标是有统有分、有层次,能落到不同的岗位职务上。

利用这个叫做“指标金字塔”的指标分层概念可以帮助解决这个问题。“指标金字塔”将我们平时需要关心的指标分为三个等级,每个等级在工作中有不同的意义和指导作用。

1、基础核心指标:

KPI、OKR 相关(一级指标)

位于最顶端的指标是核心指标,通常与整体业务线的年度目标一致。它可能是营收、月活人数、日活人数、交易活跃人数、AUM、新开户人数等等。通常这个指标是高层业务决策人经过一系列深思熟虑后制定的,服务于公司整体发展需要,也最能体现用户的核心需求,反映整个业务的走向。一段时期内只有一个工作重心,而这个工作重心评估的标准就是我们的核心指标,指标最好不要超过三个。

一级指标的提升是整个部门乃至公司配合的结果,涉及到产品、运营、开发和设计所有相关团队。这是所有相关人员都应该知悉及不断跟进的数据,是各个部门的负责人一起沟通、讨论的话题中心。同时,广大的各层级员工也需要认可这个目标。

基础核心指标跟踪的周期通常以季度为计,季度结束后做全面的总结和预估。

2、重点业务指标:

重要功能、业务目标相关(二级指标)

第二级指标通常涉及的人更少,但可能也是跨团队的指标。为支撑核心目标完成,通常我们会规划在一段时间内做几个重点业务,如理财商城或融资融券业务的使用人数、次数、交易额等。产品功能/业务涉及的产品、开发人员以及上线推广的运营人员负责这个业务指标的不同环节,需要跨团队的配合,从前期基础业务流程的梳理和准备,到产品流程的设计和开发,最后由运营推广人员进行上线相应的推广、客户服务,此后产品团队还需要对产品上线后的数据和用户反馈进行迭代,持续优化。

重点业务指标可以由多个部门共同承担,或者进行相应拆分,也可根据不同的业务内容由单一部门负责。

此等级指标的跟踪周期通常是月,各部门可根据每月完成进度调整下月的工作节奏。

3、常规操作指标:

产品、运营单次效果指标(三级指标)

第三级指标通常与我们日常工作内容相关,跟踪常规的迭代和运营效果,服务核心业务,也可能只是为了维护日常的产品功能和用户服务。这类指标是我们最常见的数据,如单个版本上线后的 DAU,或某次运营推广活动的 PV、UV、转化率等。

常规操作指标与一个项目的管理人员和执行人员的相关,用于优化具体的执行细节或者执行方案,通常每天由不同的人来跟进。

对产品经理来说,任何一个小的版本的产品优化都可以在上线后一周至两周内监测其产品使用人数、产品留存人数、点击率,用以验证这个小的产品优化是否真的有效。这是一个操作指标的跟进。

下面举个例子,指标金字塔如何进行拆解:

指标的拆解更多的需要我们先理解业务的逻辑,跟着理想用户行为路线将大指标拆解为小指标。以上图为例,如一个 App 目前的核心指标是客户人数,在这个路线上,从用户下载到成为活跃用户,再到转化成我们真正的客户,其经历的两个重要环节,就可以大致分为产品转化和运营转化。产品转化,通过刺激用户首次使用产品,持续使用产品,将用户变成一个活跃用户。在运营转化环节,运营通过产品运营、用户运营、活动运营等多种运营手段,将一个活跃用户转化成客户。在一系列活动运营的设置中,单次的活动转化客户人数就是一个可操作指标。

层层分解和落地,就能让最核心的高高在上的指标和我们日常的工作联系起来。

No.2 如何开展数据工作——建立数据流程

建立数据的工作流程的目的不是要一定按照固定的规范行事,流程只是个形式,流程的目的是为了让一线工作人员们有意识、有安排、有节奏的去开展工作,也更能方便团队内部和外部的配合。

数据工作流程大致为:提出业务需求——拆解数据需求——数据预处理——数据跟踪反馈——分析总结这五个环节。每个环节的时间节点和负责人都要一一明确。

以典型的互联网公司为例,通常一个版本的迭代涉及到需求确认、排期、设计、前后端开发、埋点、测试等工作。

版本需求大约提前一个月确定,包括产品和运营的需求。需求确定之后,进入到开发期,产品经理需要将其中的数据需求进行拆解,统一规划并部署,在上线前将需要检测的数据和提取方式、相应的埋点规则与开发人员沟通好,并测试埋点是否按照要求完成。上线后能看到指定的数据,如果数据出现异常,负责埋点的数据工作人员需要及时与开发人员进行沟通修正。

埋点工作通常是由产品经理在综合考虑业务需求后,纳入产品需求和规划开发的一部分一起做的。但如果是运营活动的 H5 页面、帖子页面,此时拆解数据需求和做数据预处理的就可能是运营人员自己。在一些分工更细的公司,从承接数据需求,到数据处理和数据展示可能都由专门的数据团队负责。虽然流程各环节实施的人和时间节点都可以依据具体的业务而定,但一定要明确达成共识的流程可以落地。

同样用一个新产品上线的案例来说明:

  • App 计划上线一个新的功能,叫 AI 智能选股。产品经理将此产品的各项需求收集在一起,进行规划和流程设计,出具产品文档,详细到具体的实现方式,并说明埋点和数据监测方式。
  • 全团队进行需求评估,AI 智能选股是否满足业务和用户的需求,优先级是否高,是否安排开发资源等。
  • 通过需求评估后,将此功能纳入产品开发排期,确定上线版本,同时评估是否有足够开发资源和运营资源。
  • 进入开发期,设计——开发(包括数据埋点及监测开发)——测试(包括数据埋点及监测测试)。
  • AI 选股产品上线后,在首页设置 icon 入口,检测其点击数据,如两周内的点击率是多少、比之前同位置 icon 点击更高还是更低、相较于这个首页流量的点击占比提高还是降低,看是否有异常。监测其他入口和各路径、流程的转化率。
  • 总结、分析,包括 AI 选股产品的整体使用人数、使用时长、留存情况等数量和趋势、以后的迭代方向、用户反馈等等。

No.3 如何提高业务指标——培养数据思维和数据习惯

1、从上到下培养数据习惯

从每天的站会、每周的周会,到每一次部门会议、业务会议,把数据表现的回顾挂在嘴边是培养大家关注数据结果的习惯的开始。这个习惯一定要领导们身体力行。

数据是我们一切工作结果的衡量标准,也是我们优化工作的参考,更是我们决策的依据。指标无大小,大会议分析大指标,小会议分析小指标。当我们都习惯了以客观的数据为依据去评估工作的时候,整个公司才会有统一的判断标准和方向。

2、时时反馈,事事反馈

要有定期的数据汇报,可以是每周正式的周报,也可以是非正式的通告。数据反馈能让从开发人员到运营人员都清楚自己工作的成果是什么。不断增长和向好的数据,会让大家认可自己日常琐碎和重复的工作。

如果数据表现不好,也会促使大家去思考原因何在以及如何改进。这会极大地增加全体员工的意义感和参与感,哪怕只是上线一个小功能的点击走势,也能让大家对自己工作的结果心中有数。数据结果是一种纽带,把大家串联在一起,这是可以随时随地、非正式的地进行分享的。

3、明确工作职责,落实到指标上

虽然提升业务指标的要点其实已经完全融入到了平时对核心指标的关注、数据工作流程和团队间工作协调上,但还是需要明确不同的团队和个人的工作职责,并且落实到相关指标上。

单个指标有诸多可控和不可控的因素,但可以用更多元化的考核机制来灵活的处理这个问题。例如新转化用户这个指标,可以拆分成转化率和流量两个细分指标,流量*转化率=新转化用户。产品和运营可以共同对新转化用户这个指标负责,但在不同的环节上有各自的侧重。

4、建设一个强大的数据中台

最后一点是,一个强大的数据中台能够让数据工作更有条理、更直接、更快捷。对有开发能力的公司来说,定制化一个能实时看到数据反馈、可视化指标结果以及为运营和产品同事提供一些便捷的数据工具的强大数据中台,是一个非常值得投入的事情。甚至可以将营销平台、埋点管理、用户管理系统作为这个数据平台的联动系统,实时的对营销活动、产品热力度、推送效果等运营产品数据效果给出效果展示和数据分析。这也能极大地为运营和产品团队赋予数据能力。

作为国内领先的数据智能服务商,TalkingData为各行业企业提供全面的数据应用和数据解决方案。全新升级的TalkingData 移动运营平台5.0即涵盖数据指标体系、智能路径分析等多种分析报表平台,还提供可视化营销策略分析、客群分组测试等多种智能营销支持。

结语

搭建数据指标体系、建立数据流程、培养数据思维和数据习惯,是业务部门构建数据管理体系的“基础三件套”。数据是管理工具,也是业务工具。数据的基础工作更值得好好投入,让我们的管理和业务都在数据助力之下走入快车道。

必须收藏丨万字长文,带你了解跨平台移动应用开发工具

TalkingData 张永超 译

原文链接:
https://instabug.com/blog/cross-platform-development/?utm_source=reddit&utm_medium=social&utm_content=cross_platform_development

在如今的电子世界当中,运行着各类操作系统,如何让应用适配每个操作系统平台,是开发者们一直在思考的问题。因为平台、技术、工具的有多样性,让适配变得无比的困难与繁杂,甚至需要花费大量的时间和资金去进行研究。本文将介绍目前比较流行的可以开发跨平台应用的开发工具,希望能够帮助开发者们实现全平台覆盖。

本文较长,其中大量资源网址值得收藏!

移动应用开发概述

Web应用

Web应用是运行在网页上并存储在远端服务器上的应用,此类应用通过设备上的网页浏览器加载与展示。

即便在某些情况下网页应用运行良好,但仍无法避免会出现一些问题,比如需要连接到网络才能在设备上运行,因为所需的资源并未存储在本地设备上,而是在远端服务器上。另外,此类应用无法在移动商店上直接使用,导致用户很难找到和下载使用。

Hybrid跨平台应用

Hybrid应用又称为混合应用,此类应用基本上使用每个平台的浏览器内置组件进行包装和打包,以达到在每个平台上运行的目的,应用就像该平台上的Native应用一样。混合应用主要使用的语言为HTML5、JavaScript和CSS。

混合跨平台应用解决了Web应用面临的问题,因为混合应用在本地运行时无需网络连接,而且还能在应用商店上发布,可以让用户轻松找到,从而增强应用的可发现性、增加用户量等。

混合跨平台应用开发工具:Apache Cordova、Ionic、Adobe PhoneGap等。

Native应用

原生应用是为了在特定平台或操作系统上工作而开发的应用。

对于iOS来说,开发者使用的是Swift或Objective-C编写iOS应用,而对于Android来说,开发者使用的是Java或Kotlin编写Android应用。从移动开发工具来看,iOS开发者经常使用Apple的Xcode或者第三方的AppCode等工具,而Android开发者经常使用Android Studio作为它们的主力开发IDE。

Native 跨平台应用

原生跨平台工具允许开发者编写一次代码,然后将该代码转换为适配多个操作系统的本地代码,让开发者以最小的成本在不同的平台上发布移动应用。原生跨平台应用是混合应用和本地应用的完美结合,不仅提供了混合应用的代码重用功能,而且性能也与本地应用类似。

原生跨平台应用开发工具:React Native、Xamarin、Titanium等。

跨平台移动应用开发

跨平台移动应用开发是创建可以使用单个代码库,在多个平台上部署或发布的移动应用开发过程,跨平台移动应用开发无需使用每个平台的对应的本地技术去进行多次开发。

跨平台开发有以下优点:

  • 可重用代码:跨平台开发工具允许只编写一次代码,然后将代码导出到需要操作的系统和平台上,无需为每个平台单独编写创建代码;
  • 便利性:跨平台开发工具能够省去学习许多编程语言的麻烦,开发者只需要理解领会一种语言即可;
  • 可维护代码:当需要修改或更新应用时,开发者只需更新一个代码库,就可以将更新同步反映在平台所有的应用上;
  • 成本效率:跨平台开发可以让单个开发团队能够在多个平台上进行工作,且大多数的跨平台开发工具都是免费的。
  • 市场覆盖率:通过多平台发布应用,可以让其增加曝光量,提升用户基数,从而提高投资回报率和经济利益。

虽然跨平台开发工具拥有很多优势,但在某些场景下的缺点也相当明显:

  • 性能:即便一些跨平台开发工具提供了接近本地应用的性能,但仍有不足,如果所开发的应用属于最高优先级,不建议使用跨平台开发工具。
  • 3D和图形:与性能上的缺点类似,跨平台开发工具无法提供最佳图形和最佳的用户体验,且无法访问核心OS库(如图形),如果所开发的应用严重依赖于图形,比如移动游戏类应用就不建议使用跨平台开发工具。
  • 单平台应用:如果所开发的应用尽在单一平台(如iOS或Android)上发布,那么还是应该使用本地开发的应用,在这种场景下,只需要一个团队使用一种技术即可,没有必要去损失性能。
  • 特定与平台的功能:虽然跨平台开发工具提供了不同平台之间共享的许多基本功能,但它们可能缺少Apple、Google和Microsoft的操作系统上提供的某些特定功能。
  • 特定与设备的功能:跨平台开发工具可以让开发者访问的不同功能,如相机或GPS,但如果所开发的应用需要直接访问和处理设备的硬件,本地开发应用是更好的选择。
  • 更新延迟:在一些特定平台发布更新时,可能需要等一段时间才能在所有平台开发工具中反应这些更新。

跨平台开发技术栈

虽然跨平台开发工具可以帮助开发者节省学习不同技术的时间和工作量,但仍然需要熟练掌握每种工具,使用的技术有:

  • React Native:JavaScript(JSX)、ES6、React.JS
  • Xamarin: C#
  • Cordova: HTML、CSS 、JavaScript

常用跨平台开发工具

  • Ionic
    地址:https://ionicframework.com/
  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Titanium
    地址:
    https://www.appcelerator.com/Titanium/
  • Framework7
    地址:http://framework7.io/
  • Apache Weex
    地址:https://weex.apache.org/
  • Flutter
    地址:https://flutter.io/
  • Native Script
    地址:https://www.nativescript.org/
  • Jasonette
    地址:http://jasonette.com/
  • ManifoldJS
    地址:https://github.com/pwa-builder/ManifoldJS

三大主流跨平台开发工具

React Native

React Native是由Facebook基于其React JavaScript库创建的跨平台本地移动应用开发框架。主要使用JavaScript与JSX(JavaScript的扩展),ES6(ECMAScript 6),JavaScript的主要更新(包括许多新功能)和React.JS(用于构建用户界面的JavaScript库)。

React Native允许开发者使用React Native组件构建移动应用,然后再将其编译为本地应用,这些应用几乎与使用本地工具编写的应用完全相同。

React Native的优点

使用React Native进行跨平台移动应用开发的优点包括:

  • 可重用代码:可开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店: 可以在各个平台的应用商店中发布应用。
  • 性能:React Native可将应用编译为本地应用,这与使用本地工具创建的应用几乎完全相同,使其比必须在特定于平台的Web组件中运行代码的混合应用更快。
  • 本地UI组件:React Native允许开发者使用React Native UI组件创建视图,这些组件被编译为特定于平台的UI组件,与使用HTML标记的其他跨平台工具不同。通过现成的组件,可以节省大量的时间。
  • 热重新加载:React Native中提供一项允许更改代码在iOS和Android应用中立即生效的功能,可以进行可视化更改。
  • 测试:调试React Native应用非常容易,因为它发布了本地应用版本,可以使用Expo这样的工具在物理设备上进行测试,无需在Xcode或Android Studio中打开它们。
  • 本地代码:与大多数其他跨平台开发工具不同,React Native允许开发者单独修改已发布的本地应用,它可以选择在React Native代码和本地代码之间进行组合,无论是Swift,Objective-C,或者是Java。如果想使用特定于平台的代码为不同平台实现单独的可视组件,就非常有用。
  • 可靠性:React Native由Facebook创建,许多世界顶级移动应用都在使用React Native,比如Facebook,Instagram,SoundCloud和Skype。
  • 免费:开源。

React Native的缺点

虽然React Native是目前最好的跨平台开发工具之一,但React Native仍然具有一些缺点:

  • 新技术:学习JSX和ECMAScript并不是一件容易的事,可能比其他熟悉的技术(如HTML和CSS)要花费更多时间。
  • 原生UI组件:虽然UI组件是React Native的最大优势之一,但目前只有少数几种现成的可用。
  • 本地代码:在某些情况下,开发者可能需要在移动应用中编写本地或平台特定的代码,特别是如需访问设备硬件(如相机或GPS),会破坏跨平台开发的目的,对小型团队来说React Native的作用不大。
  • 性能:虽然与大多数其他跨平台开发框架相比,React Native在性能方面表现优异,但比起使用特定于平台的工具和语言的本地应用进行开发来说仍有不足。

React Native 开发工具

  • Atom
    地址:https://atom.io/
  • Nuclide
    地址:https://nuclide.io/
  • Visual Studio Code
    地址:https://code.visualstudio.com/
  • React Native Tools
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native

React Native 开发组件

  • Redux
    地址:https://redux.js.org/
  • Expo
    地址:https://expo.io/
  • Ignite
    地址:https://infinite.red/ignite
  • Flow
    地址:https://flow.org/
  • ESLint
    地址:https://eslint.org/
  • ReduxSauce
    地址:
    https://github.com/infinitered/reduxsauce

React Native UI组件

  • Snowflake
    地址:
    https://github.com/bartonhammond/snowflake
  • NativeBase
    地址:https://nativebase.io/

React Native 测试工具

  • Enzyme
    地址:
    https://github.com/airbnb/enzyme
  • Reactotron
    地址:https://infinite.red/reactotron
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Xamarin

Xamarin是一个跨平台的移动应用开发框架,由微软基于Mono(一个免费的开源.NET框架),使用C#创建本地应用。

Xamarin 优点

Xamarin跨平台移动应用开发具有多个优势,包括:

  • 可重用代码:开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 完整的开发堆栈:许多开发者认为Xamarin是最完整的跨平台移动应用开发框架。拥有自己的专用堆栈,C#作为编程语言;Visual Studio作为IDE,与Xamarin完全集成;.NET作为开发平台;Xamarin测试云进行测试;以及Xamarin.Insights用于分析。
  • 性能:Xamarin在性能方面也几乎与本地应用相同。 Xamarin比混合应用更快,因为混合应用必须在特定于平台的Web组件中运行代码。
  • 本地UI组件:使用Xamarin Native UI组件创建视图,这些组件通过Xamarin.Forms编译为特定于平台的UI组件,Xamarin.Forms包含面向.NET开发者的完整跨平台UI工具包,或可以通过Native UI开发。
  • 插件和API:Xamarin提供了一组允许访问硬件功能的插件和API。它还支持通过链接本地库进行自定义。 测试:通过在物理设备上安装Xamarin.Forms Live Player应用,开发者可以使用实时预览立即测试和调试应用,并可以实时同步应用与设备。
  • 可靠性:Xamarin于2016年被微软收购,截至目前,已在120多个国家/地区拥有超过140万名开发者。所以它绝对可靠且拥有良好的维护。
  • Xamarin大学:Xamarin提供由Xamarin专家指导的实时、互动的移动开发培训,涵盖10个方面的80多个课程,让开发者可以轻松地学习。
  • 免费:开源。

Xamarin 缺点

虽然Xamarin可以应用许多场景,但它也是有一些缺点的:

  • 应用大小:通常已知Xamarin应用大小比本地应用更大,因此在内存管理方面不是很理想。
  • 更新延迟:Xamarin的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 本地代码:当使用Xamarin.iOS或Xamarin.Android开发具有原生外观的移动应用时,将需要一些本地语言的基本知识,如Objective-C、Swift和Java。
  • 图形:虽然Xamarin使用单个代码库为多个平台构建应用,但它主要在平台之间共享代码逻辑,而UI组件又是特定于平台的。这使得Xamarin并不适合严重依赖图形的应用,比如手机游戏。

Xamarin开发工具

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/vs/mac/
  • XCode
    地址:
    https://developer.apple.com/xcode/

Xamarin 开发组件

  • NuGet
    地址:https://www.nuget.org/
  • Xamarin Inspector
    地址:
    https://docs.microsoft.com/zh-cn/xamarin/tools/inspector/install?tabs=windows
  • Prism
    地址:
    https://github.com/PrismLibrary/Prism
  • MFractor
    地址:https://www.mfractor.com/
  • Resharper
    地址:
    https://www.jetbrains.com/resharper/

Xamarin 测试工具

  • NUnit
    地址:http://nunit.org/
  • xUnit.net
    地址:https://xunit.github.io/
  • Visual Studio Unit Testing Framework
    地址:
    https://docs.microsoft.com/zh-cn/visualstudio/test/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Apache Cordova

Apache Cordova是一个跨平台的移动应用开发框架,用于使用包括HTML,CSS和JavaScript在内的Web技术,构建混合移动应用。

Apache Cordova 优点

使用Apache Cordova进行跨平台移动应用开发的一些优势包括:

  • 可重用代码:可以开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 多平台支持:Apache Cordova支持大多数开发者所使用的移动平台和操作系统,包括Android,iOS,Windows 8.1,iPhone 8.1和10,OS X,几乎可以覆盖所有移动用户。
  • 大量插件:Cordova提供各种插件。
  • 所用技术:Cordova不是一种编程语言,因此开发者可以使用已知的Web技术(如HTML,CSS和JavaScript)进行应用开发。还可以使用自身熟悉的工具,包括所使用的编辑器。
  • 免费:开源。

Apache Cordova 缺点

和任何跨平台移动应用开发工具一样,Cordova也缺点,包括:

  • 性能:使用Apache Cordova创建的移动应用,会因性能问题而受到影响,因为它是一种混合的跨平台移动应用开发工具。
  • 开发工具:由于Apache Cordova使用HTML,CSS和JavaScript等Web技术,因此用于Apache Cordova的大多数开发工具都针对Web开发进行了优化,而非移动应用开发。
  • 测试:在Apache Cordova中调试代码会比较繁琐,虽然可以使用开发工具修复任何代码上的bug,但需要使用特定于平台的工具来修复特定平台中发生的问题。
  • 技术:即便开发者可能熟练掌握了HTML,CSS和JavaScript等网络技术,但仍需要具备Web和移动应用的经验才能创建Cordova移动应用。
  • 支持的平台:Cordova多年来已经弃用了许多支持的平台,包括BlackBerry,Firefox OS,Symbian,Ubuntu Touch,webOS,Windows Phone 8.1和Windows Phone 10.虽然Cordova可能很难弃用iOS和Android,但仍然无法保证它继续支持任何其他当前所有平台。
  • 更新延迟:Cordova的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 插件:虽然Cordova提供了比其他任何跨平台开发工具中都多的插件,但它仍然无法与本机移动应用开发工具相比。

Apache Cordova 框架

  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Monaca
    地址:https://monaca.io/
  • Onsen UI
    地址:https://onsen.io/
  • Cocoon
    地址:https://cocoon.io/
  • Framework7
    地址:http://framework7.io/
  • Evothings Studio
    地址:https://evothings.com/
  • Mobiscroll
    地址:https://mobiscroll.com/

Apache Cordova IDES

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/zh-hans/vs/features/cordova/
  • Cordova Tools Visual Studio Extensions
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.cordova-tools
  • App Builder
    地址:
    https://www.davidesperalta.com/appbuilder
  • NSB/AppStudio
    地址:https://www.nsbasic.com/

Apache Cordova CLIS

  • Cordova CLI
    地址:
    https://github.com/apache/cordova-cli
  • Node.js
    地址:https://nodejs.org/en/
  • NPM
    地址:
    https://www.npmjs.com/package/cordova
  • Cordova Plugman
    地址:
    https://github.com/apache/cordova-plugman
  • Cordova Coho
    地址:
    https://github.com/apache/cordova-coho

Apache Cordova 类库

  • Apache Cordova JS
    地址:
    https://github.com/apache/cordova-js
  • Apache Cordova Lib
    地址:
    https://github.com/apache/cordova-lib
  • Apache Cordova Common
    地址:
    https://github.com/apache/cordova-common
  • Apache Cordova Create
    地址:
    https://github.com/apache/cordova-create
  • Apache Cordova Fetch
    地址:
    https://github.com/apache/cordova-fetch
  • Apache Cordova Serve
    地址:
    https://github.com/apache/cordova-serve

Apache Cordova 测试工具

  • Apache Cordova Plugin Test Framework
    地址:
    https://github.com/apache/cordova-plugin-test-framework
  • Apache Cordova Paramedic
    地址:
    https://github.com/apache/cordova-paramedic
  • Apache Cordova Mobile Spec Suite
    地址:
    https://github.com/apache/cordova-mobile-spec
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

总结

跨平台开发工具在开发周期中可以为开发者节省大量的时间,并可以使用最少的资源在不同的平台上发布应用,最大程度的去覆盖用户。但即便如此,它也无法替代本地开发应用的替代品,鱼和熊掌不可得兼,需要根据自身实际情况与场景去衡量利弊。

如何确定最适合的跨平台开发工具呢?最好的方法就是每个工具都去尝试一遍,如果时间有限,那么对一些顶级跨平台开发工具进行研究就足够了,比如本文例举的这些,希望对您有用。