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

作者: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

总结

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

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

重磅丨《2018年数据生态报告》发布,5大方面助力领跑数据智能时代

近日, TalkingData联合中关村大数据产业联盟、中国国际大数据大会组委会在“2018年第五届中国国际大数据大会”主会场高峰论坛上共同发布《2018年数据智能生态报告》,TalkingData CEO助理、腾云大学校长、中关村大数据产业联盟数字生态行研中心首席研究专家杨慧博士对报告进行了详细解读,针对数据智能的发展趋势给出相应的应对策略,帮助企业更好驾驭数据智能,领跑数据智能时代。

《2018年数据智能生态报告》结合TalkingData在助力行业发展变革中积累的经验,梳理了当下中国数据智能市场的发展历程和未来走向,给出了数据智能、数据智能平台的定义和时代的特性。本报告洞察了数据智能时代的本质,分析了数据智能市场行业全景及痛点,并为不同类型的企业提供应对策略,倡议积极推动行业合作,共建数据智能平台。

现今无论是互联网企业还是传统行业的企业,都非常重视对于数据的收集、处理、算法的精炼以及最终对数据价值的应用。但是如何在这样一个以数据智能时代中,采取有效的措施和行动真正实现数据价值的提炼,利用数据智能去改变企业决策、改善人类生活?这是我们需要共同来探讨的。

一、数据智能的定义与本质

著名图灵奖得主Jim Gray提出的四大范式,可以很好地帮助我们梳理科学的演进。其中前三大范式,在人类文明发展的历史长河中帮助我们更好的记录、归纳和模拟现实世界;而进入数据智能时代,在机器学习、分布式计算等技术发展的基础上,数据逐渐呈现出高维度、高阶态、异构性的形势,能够对海量数据进行分析、处理和挖掘,并且通过建模、工程等方式来解决实际的预测和决策问题,最终实现决策的行动,则为“数据智能”。

数据智能也和数据科学、数据工程、数据分析等概念息息相关,但数据智能作为一个独立的概念,和其它几个名词最大的区别在于:

  • 数据智能的目的是“预测”和“决策”,而非“分析”或者“展示”。

  • 由于数据智能指向决策,所以用来判断数据智能的效率和价值就在于其决策的结果产生的可衡量的商业价值。
  • 数据智能产出的过程中需要一个强有力的能够承载和调动一系列智能数据、核心模型以及面向不同情境的数据处理能力的数据智能平台。
  • 最终呈现出有封装的、有交互界面的可以一定程度上替代人工决策的数据智能产品。

从商业和经济的本质上来说,数据智能平台指数级地加速了数据和人的智慧,其价值体现在两个方面:第一方面体现在聚合效应,即从数据源到数据加工、数据分析、数据应用最终形成数据产品过程中,实际上遵循价值“微笑曲线”;数据智能通过聚合各个环节的剩余价值,从而提升整条价值链的价值。

第二方面体现在加速效应。在数据的获取和应用的这些环节,数据的价值链已经从单一的线性结构逐渐演变成为模块与模块之间互相交叉融合的复杂架构。数据的每一个环节都都能够得到数据智能平台的加速,产生更多价值。综上,通过打通数据价值链,可以集中剩余价值、降低数据成本、提高资源配置,从而获得数据智能所带来的价值红利。

二、数据智能平台的使命与能力

数据智能平台/数据中台的使命有两件事:帮助企业更好的“看现在”——对现有数据的治理;帮助企业更好的“看未来”——对数据价值的挖掘对未来的预测;“看现在”的目的最终是为了更好的“看未来”,这是因为在数据智能时代,数据的量级和异构的程度都极其复杂,千里之行始于足下,因此这是企业实现数据智能的第一步,也是决定数据智能价值实现最为关键的基础。具体进一步来说,这两个能力拆开后又包括了以下这些能力要素:为了更好“看现在”连接、共享、安全;以及为了更好“看未来”的管理、科学与工程。

1、连接,提高数据维度及饱和度。连接不强调对数据的拥有,而强调能够触及和返回的数据的广度、丰富程度。将不同来源的数据汇聚和连接起来形成更丰富的数据维度,是数据智能平台的使命。

2、共享,通过OPAL实现数据价值流转。共享能力是评估一个数据智能平台是否合格的首要标准。共享不代表要完全的透明,而是通过像OPAL(Open Algorithms,开放算法库)这样的技术框架去构建一个合理的、区分权限的、能够保护数据同时让知识的价值流转的机制。

3、安全,推动数据安全合规标准的建立。安全合规是重中之重。一个数据智能平台是中立的、合法合规的,它中间涉及到的各项任务都应该是安全且合规的,具有安全管理、用户管理、平台接入与使用的审计、调优和保障高可用性和容灾的能力。

4、管理,实现企业的数据资产化、资源化。管理是数据智能平台实现价值的起步,让数据的排列有序、结构趋同,可以被进一步的分域、保存、备份、重新组合,形成更多的协同价值。

5、科学,提升决策的科学性与准确性。数据科学是探索数据价值的流程,也是数据价值被挖掘的核心过程。数据的价值不是一次成型的,数据价值的挖掘依赖与不断假设、分析、验证、校准的反复迭代过程,最终才能凝聚沉淀成模型和解决的方案。

6、工程,实现数据价值的快速转化。数据能够直接变成决策,中间需要工程来构建环境,实现汇聚、仿真和自动化。工程这个因素将数据和算法、工具和能力有机的结合起来,最终形成一个封装的、内部自成体系的数据智能产品。

有了以上六个能力因素,数据智能平台才得以成为一个独特的平台,也成为企业想要快速构成数据智能产品、实现客户价值的必需平台。

三、数据智能市场的发展与痛点

随着互联网技术、人工智能等科技的飞速进步,数据量级的增长、计算能力的提升、存储的便捷化等推动数据智能市场蓬勃发展。数据市场从以传统IT企业为代表的软件时代,到以互联网企业为代表的数据时代,再到以数据智能企业的生态时代,数据的支撑和驱动因素越发成熟。随着终端的智能化、数据异构化、商业问题复杂性的提高,数据智能市场也向着万亿级别的市场规模进发。

对企业客户来说,企业数字化转型的不同阶段面临着不同痛点问题,但是总结来说会有如下几类:

第一、业务管理者或高管不知道怎么构建数据业务 / 数据能力;

第二、缺人,缺人,还是缺人;不知道从哪里获取这类人才,或者人才掌握的是上一阶段发展所需的知识;

第三、客户没有透彻地理解数据能力和企业业务能力之间的关系:无法与客户商业决策所对应的商业指标绑定;

第四、相应数据虽形成闭环但是数据闭环本身太小或者太过封闭,能够解决的问题过少、过小。

客户侧出现的问题,体现了整个数据行业目前面对的深层次问题。那么为什么要有数据智能平台呢?有数据智能平台的在位企业才能帮助客户解决上述问题。对于数据行业的从业者来说,数据获取已经不是问题,但是单一数据源的维度价值有限、数据需要共享才有价值;其次,数字业务推陈出新速度非常快,各数据源及应用厂商各自造轮子,很难形成规模优势,缺少行业的分工和合作;法律法规包括网络安全法、个人信息保护规范等还在不断完善,数据安全成为桎梏所有数据价值共享的主要鸿沟;数据与商业场景割裂,缺乏行业洞察,很难进行有效转化;最后,专业数据人才缺乏,大多数都集中在数据行业的从业企业中,留给传统企业进行数字化转型和提升的人才十分有限。目前高校等培养机构供给还处在缓慢加速的过程中,行业人才空缺加大。因而需要这样一个数据智能平台来通过能力的共创、复用、沉淀等,促进企业前端业务或者数据智能产品的效率、协同和创新。

为了解决以上的痛点问题,无论是对于客户企业还是对于数据行业的在位企业来说,都需要出现一家企业、一个团队来主导数据智能平台/数据中台的建设,这个新的数据智能平台/数据中台的存在,才能打破传统价值分工、重构数据行业的生态全景,全面提高行业的价值产生的能力。

四、数据智能行业全景与玩家分类

数据行业诞生以来,大多数企业在不同的商业模式上进行试水。如果把整个行业分为标准化/产品化、客制化/服务化的纵向坐标以及数据和软件工具的横向坐标,究竟是将数据作为护城河,还是产出成型高效的软件应用工具,如何在数据加工程度和软件工具、客制化和标准化中找到一个平衡,也是当下数据企业思考与探索的问题。我们可以以此为维度,分为以下六种商业模式:数据源、数据交易、市场智能、SaaS、数据产品和解决方案。处于不同商业模式的企业在整个数据智能行业中的身份与角色也不尽相同,他们有着不同的速赢关键因素和策略(见报告详解);但是在智能数据时代,这些不同类型的企业都在不约而同的自主发展数据智能平台,或者与行业中的数据智能平台形成深度的合作。

更多的合作呼唤更灵活的合作方式。不同于普通的平台类企业,数据智能平台需要同时包含数据、工具、算法和服务多个要素,不同要素的组合需要用不同的商业模式进行变现,甚至会改变价值分布、突破传统的、单向的客户关系甚至是竞争关系。因此数据智能平台需要更加开放和灵活的商业模式支持不同行业、不同业务和不同定位的合作伙伴进行合作,形成协同作用。突破传统的技术合作伙伴或者是联合建模合作伙伴、数据智能产品合作伙伴的合作方式,真正跨越简单的客户的概念的新型客户类型,与数据智能平台/数据中台类企业构建按照效果分成的成效合作伙伴关系。

五、数据智能的发展趋势与应对策略

数据智能还有很多需要研究和解决的问题。但是在变道初期如果不能快速跟上,必将会错失在一次新的产业革命(甚至是一个新的文明时代)中的赶超良机。因此,必须要认清形势,把握趋势,积极谋划,推动发展。具体来说,未来中国数据智能行业的发展会呈“两化”趋势——生态化和开源化。

只有集中了生态化和开源化的力量,数据智能才会开放互联的打通与连接各个维度的数据,进而打造成中国最大的智能数据中台。如此才能更好的去解决面向不同商业决策的痛点问题,支持多渠道多场景的数据分析与运营,产出包括智慧金融、智能营销、商业洞察等等行业成熟的解决方案与应用组合,将数据智能潮流推向新的高潮。

TalkingData崔晓波:砥砺七年,仍志在突破

本文转自:数字观察

从互联网到传统行业

在成立TalkingData之前,崔晓波曾任Oracle、BEA中国区高管,其创始团队成员皆来自Oracle。整个团队深耕toB数十年,都具有传统IT企业中从事数据挖掘、数据分析工作的经验。

最初,TalkingData主要面向互联网企业客户以及为APP开发者提供SaaS服务。但随着行业的发展,越来越多的友商也提供工具,TalkingData如何才能展开差异化竞争?如何满足客户的需求?只提供工具就够了吗?

带着这种思考,TalkingData开始为客户提供工具、数据、服务一整套解决方案,除了满足其工具需求,还教会客户分析数据的方法。

到了2014年,TalkingData发现大量实体产业开始做移动化和数据化转型,一些拥有远见卓识的企业开始在数据化和移动化方向勇敢探索,并获得了丰厚的回报。

在此过程中,TalkingData注意到传统行业和互联网公司的不同之处:第一,基础设施不足。第二,缺乏运营能力。

TalkingData将传统企业数字化转型视为其发展的第三次机遇。TalkingData借助移动互联网的高速发展积累了海量数据,用数据+咨询方式服务于传统企业客户。

一方面,TalkingData升级了原有业务模式,将数据交易、数据合作伙伴生态放到了和数据商业化同等重要的位置,形成三个事业单元,每个单元自成体系。另一方面,TalkingData打造了咨询服务、数据运营团队,为传统企业提供数字化转型的定制化咨询服务。

同时,从2015到2017年,TalkingData开始进入传统产业,包括金融、零售、地产、快销、航旅、制造等等。这样,TalkingData集工具、数据、服务等一整套方案服务了如招行、平安、银联等大量优质标杆客户。

优化业务模式

崔晓波认为,过去十年,智能手机和移动互联网带动了整个大数据领域的发展。传感器和物联网设备也飞速发展,大量生物特征数据与物联网数据将呈指数级增长,手机和物体互相感知,对场景还原和场景预测的各种需求也将不断增加。如何管理这些非结构化数据、并将其与结构化数据整合使用依然是目前所面临的一大挑战。

(TalkingData创始人崔晓波)

同时,数据体量、产业规模以及云计算高速发展所推动的基础设施成本都已不再是问题,而大数据能否创造真实的商业价值和回报才是企业真正关心的核心。

“过去一年,整个大数据市场非常好,不断涌现新的客户和新的需求,同时,我们整体团队从300多人增加到500多人。随后,我们发现自己的产能还有待提升,第一,受困于人力,太多项目接不过来,不能支撑多个行业业务同时迅猛发展。

第二,我们在2015、2016年时是项目驱动,解决方案就是客户提需求,我们做项目,解决问题。但所有人都在做项目,无法将更多的精力和资源能力投放到沉淀产品和平台上。

比如,很多共用数据服务没有把它服务化、产品化,很多产品要做重复的动作。其后发现的问题,还是得有专门的团队能够把能力,特别是数据能力,沉淀成数据产品。

所以,从去年下半年开始,我们主动收缩战线,优化项目配置,将重心放在数据产品上,聚焦于金融、互联网、零售、政府这四个数据能发挥最大价值的行业。

我认为,行业聚焦的一个主要目的是要产品化,只有这样才能提升整个公司的产能,引进更多合作伙伴,快速发展壮大。在开源大趋势背景下,传统软件产品这条路已经很难走通,只有数据产品才能构建核心壁垒。”

据悉,TalkingData的数据产品有三层:数据集、数据模型和数据应用。最底层是数据集,这是基础数据服务。数据集不是简单的卖数据,而是使数据加工方法和交易方法发生了巨大的改变。以前是对数据打标签,现在需要做各种各样的评分,对数据本身的分布,波动性等要做多方面评价。

“TalkingData有一个专门的数据治理团队,会连接和聚合很多数据,但它的核心是把数据做粗加工,加工成一层原子标签,不丢掉任何主要的信息。原子标签是更偏事实类的标签,这一层不包括业务属性,不会对照某一个行业,就是把数据加工成一个真实的日志或者描述即可。”

再上一层是数据模型,也就是算法+数据集,比如营销领域的销量预测、选品。最上层是数据应用,这是对数据能力和软件能力的重新封装,提供一个真正的应用给到最终客户,比如零售业里的智能选址、价值管理等。

“数据产品最核心能力是数据能力,而交互、体验不是最重要的,但数据一定要准,要辅助选址决策,要计算竞争品牌范围。这些如果错了,决策就会是一个灾难。”

简单来说,TalkingData数据产品的服务模式是要先把客户分层,一类是行业聚焦。公司有解决方案部门,他们直接服务客户,提供数据应用和解决方案,针对领域业务需求做探索。

“如果没有这块,只有数据中台就会对业务毫无感觉,积累不出那层业务数据,就不知道他们要什么。所以,解决方案团队更多的是探索行业需求,并对行业和客户进行评估。”

另一类是客户聚焦,也就是KA客户(关键客户)。其实,在TalkingData 关键客户不超过10个。“我们把KA客户(关键客户)定义就是探索,可以先不注重收入,但我们看重的是跟客户合作过程中,我们能探索出各种各样数据产品和数据服务来,能够沉淀到数据中台给更多的客户和合作伙伴去用。”

打造多场景产品

如何让头部企业探索出来的能力和方法,更多更好地去赋能整个产业链中的中小企业,是未来几年所面临的难题之一。在价值成立的基础上,怎么让价值更好地传递,需要数据中台去解决。数据中台是今年的热门概念,很多企业在打造自己的数据中台,但大家对数据中台的理解各不相同。

“数据中台关键两个因素,第一,数据中台必须有非常强的数据运营团队,很多企业没有这个概念,往往被一个IT部门或者技术部门主导,不存在运营的概念。

但我们一上来就有数据运营团队,运营团队根据指标做计划,有多少调用来自于自身,多少来自于外部,哪些行业需要做服务,要做规划,所以运营团队很重要,如果没有运营团队变成像一个软件平台一样。

第二,就是分层,因为以前大家做数据中台时,非常容易走端到端的方式,但效率低下。为什么?比如说要沟通一个业务需求时,需要最上面的数据应用和数据服务的人来谈需求,谈着谈着,再跟下层数据治理的人谈,但下层不懂上层业务,可能会产生误解和矛盾。所以内部得有一个非常强的平台。

我们鼓励的首先是自服务,其次是自动化,更多都靠系统解决。很多企业的主要误区就是两个,首先是没有运营的概念,其次在数据治理上没有分层,没有分层的话这两件事是做不成的。”

TalkingData对数据中台的定义是指基于数据智能应用探索商业价值的平台,它需要具有数据管理、数据工程和数据科学的能力。而SmartDP数据智能平台就是为企业提供数据管理、数据工程以及数据科学的核心能力。

为了更好满足行业对数据中台需求的变迁,2018年9月,TalkingData从战略层面对平台能力进行了全面升级,将SmartDP升级到2.0,内部称之为TalkingData数据中台。SmartDP 2.0拥有管理、工程、科学以及安全、连接、共享六大核心能力。

这样,TalkingData可以突破传统的数据源公司、数据软件公司、咨询公司模式,探索创新发展路径,以“数据智能服务商”为定位,打造基于开放连接的理念构建整合数据产业链各方资源的平台生态。

值得一提的是,TalkingData的数据产品是通用型的产品,可以根据不同行业客户的需求,提供适配的模块产品。这样,通过SmartDP和SDMK数据智能市场作为双核心驱动,在安全合规的前提下,一方面,TalkingData的平台接入各渠道数据源,打破各企业间的数据孤岛;另一方面基于强大的平台能力,为各方开放提供面向业务场景的数据智能应用与服务。

其实,在数据中台的基础上,TalkingData与合作伙伴一起打造了多款产品,助力智能城市建设与传统企业数字化转型。例如,TalkingData与腾讯云联合发布了针对线下商业场景的智能商业选址产品——智选。

据悉,智选有机整合了海量数据与机器学习技术,旨在解决实体门店的选址、商圈经营等场景问题,为智慧零售及多元化线下产业提供帮助。

首先,智选综合考量全城市每个区块区位的客流和人口规模、意向客群浓度、区位商业浓度氛围、周边临近竞争形势,量化为模型评分,将原本需要几个月完成的工作秒级一键输出。然后,智选推荐选址点精确至百米街道级别。

这样,企业可以在新消费环境下打破时空信息的不对称,打破过去被动评估模式,让品牌联营商在城市进驻时的门店覆盖战略,能够做到有的放矢。以前费时费人力的选址工作,借助智选只需几分钟即可通过可视化、数据化的方法快速做出决策,获得竞争先机。

读懂新生代,游戏玩跨界

几个关键词“游戏、新生代、品牌、跨界”将在这里碰撞出火花。

10月17日,金投赏17173游戏分论坛圆桌讨论邀请到了TalkingData合伙人兼副总裁高铎麦当劳市场部副总裁汤俊章腾讯互娱市场部市场总监张戈以及资深95后玩家代表九折,为来宾们分享了精彩的观点 。

从左至右分别为:TalkingData合伙人兼副总裁高铎、腾讯互娱市场部市场总监张戈、资深95后玩家代表九折、麦当劳市场部副总裁汤俊章

在分享前,我们先通过数据的视角,来看看新生代人群的行为特征:

新生代人群(95后)行为特征

——线上应用及线下消费偏好分析

首先我们将新生代游戏人群定义为三类,

其一“爆肝到天亮”,他们晚9点-凌晨2点活跃度高,日均游戏时长5小时以上,是游戏的高粘性玩家,不过还是要对他们说一句“小心肝~”;

第二类人群称之为“规律性夜猫子”,晚18点-20点游戏活跃度高,每天有较规律的游戏时间,日均游戏时长2小时;

其三,“云游戏玩家”,他们游戏时间不规律,但他们对游戏类直播的热衷度较高,且有一定的时间规律性。我们来看看新生代游戏人群的线上APP 使用行为偏好和线下消费偏好:

新生代游戏人群的线上APP 使用行为TGI偏好

新生代游戏人群的线下消费TGI偏好

将两个图表结合来看,通过交叉分析能够看到更多的信息,首先学生族在各类线上娱乐方式的关注度分配上比较均衡;刚刚进入职场的95后在应用类型方面对于房产、出行、旅游、理财、生活信息等的应用关注度明显提高,而对于娱乐方式当中的游戏、视频、音乐、商店类应用关注度走低;而进入职场稳定期的游戏属性人群,对游戏内容的关注度明显回升刚进入职场的95后在线下消费层面,对外在颜值和配饰方面的关注度走高,在结婚、金融、亲子方面的消费关注度增加;职场进入稳定期,则对物质消费类关注度走低,母婴、线下折扣、汽车服务消费关注度增加。

另外从中我们也能看到三类人群的差异化特征,比如“规律性夜猫子”人群,游戏的规律性暗示了生活上的规律性,上班族面对生活的压力对于房产类应用(或租房、或买房)有着更强的需求,而“肝爆”人群一方面还没到考虑房产的人生阶段,另一方面他们关注点更聚焦于游戏本身。综合来看,规律性夜猫子人群相对更懂生活与品质,在医疗、旅游、金融理财、智能硬件方面有着更突出的偏好,同时在线下消费上,对于箱包、家用电器以及结婚等也有着较高的关注度。

对于“云游戏玩家”,虽然他们游戏玩的频率不高,但对游戏和视频有着较强偏好度,属于游戏直播的看客。同时,我们发现该类人群对于母婴和汽车服务有较强的线下消费偏好,或许他们是曾经的叱咤游戏江湖的高玩,因为有了家庭的压力渐渐“隐退”于游戏江湖,但还依然关注着游戏圈里的那些事。

新生代人群行为特征

——品牌人群与游戏偏好对比

基于品牌人群的游戏偏好探索我们选取了四个行业,分别为美妆、快餐、汽车4S店、服饰连锁,从中筛选相对具有代表的品牌,美妆为莎莎SASA、快餐分别为麦当劳、肯德基,汽车为相对高净值的宝马品牌,而服饰连锁则选择的相对大众化的优衣库。下面我们来看看这五个品牌人群在游戏方面的共性与差异化。

先来看看麦当劳与肯德基,两个品牌同为快餐连锁,它们人群对于游戏品类的偏好却有着较大的差异化,两者对于移动游戏均有较强的偏好,但麦当劳人群电竞游戏属性更强。例如王者荣耀、掌上英雄联盟、网易UU加速器,这三款都是能展现出他们对电竞游戏有一定兴趣偏好的应用。而对于肯德基人群来说,他们更倾向棋牌及休闲类游戏,例如开心消消乐、斗地主类游戏。

美妆零售及宝马汽车人群对游戏偏好相对较低,相比移动互联网人群,对游戏偏好TGI均在80左右(图中未标)。由于美妆零售人群以女性为主,她们更偏好休闲类、棋牌类游戏,以开心消消乐、斗地主、麻将为主。宝马车主/潜客,整体对游戏偏好不高,以大众化游戏为主,但更爱王者荣耀。同时,我们发现优衣库人群对射击游戏偏好度相对较高,更喜欢吃鸡类游戏。

在分享数据的同时,17173媒体集团总经理赵佳也发表了“玩家HCC状态”的观点:核心玩家其实不是一类人,而是一类人的某种状态。这种状态包括了不同的社会角色、玩家所处的不同的平台,乃至不同的生活状态,这些都可能会影响玩家在游戏中的状态,简单的细分方式已经很难解决目前游戏营销所面临的问题。需要针对不同的状态,去重新构建玩家的画像。

下面我们回顾一下圆桌论坛上嘉宾们的观点:

TalkingData高铎:大家下午好,虽然说我们分享的标题是新生代的趋势,但是我们新生代的趋势讨论一定要扣主题,扣什么主题呢?第一扣金投赏,第二扣游戏。金投赏是一个品牌行业的大聚会,17173是一个游戏群体主要关注的媒体,所以我们今天的分享主要是讲游戏与品牌的跨界趋势。

第一个问题先问一下腾讯的张总,我们发现无论在品牌行业,还是游戏行业,现在对品效合一的诉求越来越强,腾讯作为在游戏这个行业里面,玩得风生水起的企业,如何去通过你的品牌塑造,通过IP的长期运营,去直接的降低游戏获客的成本?

话题:如何通过品牌塑造以及IP的长期运营,降低游戏获客成本?

腾讯张戈:腾讯算不算全球最领先的游戏公司,这话我真的不敢接。我们确实是在不断进取的一家游戏公司,刚才说到关于品效合一这个事情,我可以很有信心的说一句话,腾讯应该是在游戏产品品牌上面走得最坚定的一家游戏公司。我们其实会看到,从08年开始的一些PC端产品,做到现在都应该算是成功的品牌,不管是QQ飞车,还是QQ炫舞,抑或DNF、CF、《英雄联盟》,还有我们最近上线比较成功的手游,尤其像《王者荣耀》,我们觉得腾讯但凡做得比较成功的游戏,在公司内都能够算是一个比较成功的品牌。

而在这个品牌之下,我可以给大家分享一下的是,我最近比较集中在负责的一个产品是DNF,我们最开始拿到DNF这个游戏的时候,并不能指望它能做成一个好品牌,我们在思考这个品牌的未来到底是什么?我们在09年到10年的时间段,就是我们为这个品牌梳理了一个属于这个品牌的价值观,我们叫fight,我们花了迄今为止8、9年的时间,一直在打磨fight这个品牌,而用户对这个品牌的接受度,尤其对fight价值观的接受度非常高。

举个例子,之前有一个关于“死肥宅”的事情,应该是游戏圈或者KOL圈都知道。死肥宅是一个街头采访的受访群众说玩DNF的玩家都是死肥宅,一般游戏的玩家就会骂了。但是DNF的玩家不会骂,他会调侃自己:就有人说我们是死肥宅,怎么办?我们用属于我们自己的方式回应这个事情。于是他们出了一个「西装打团」,这是玩家自主的,主播也在参与,他们穿上西装坐在镜头前,号召其他的玩家一起穿上西装在游戏里玩游戏,然后来证明我们是一群有fight精神的玩家,他们认同了这个品牌理念。在这个品牌理念之下,我们现在做DNF的IP,去年起我们做DNF的圈层文化,这里面有非常多的内容,我不能讲太多。但是这个换来了什么?我们只是在品牌上投入,换来了从14年开始DNF的活跃数据持续增长,一直到18年DNF第十年的时候,活跃数据依然在增长。我们每年都在优化我们的用户回流成本,也就是我们的获客成本。而我们最终汇报给老板的数据,他看到我们每年的回流成本也确实都在下降。这就是一个耕耘了十年的品牌,在十年之后它依然能够给我们换来更强的商业价值,由这些商业价值我们能够去换来的新的价值,我们是这样理解的。关于品效合一这件事情,腾讯是坚决赞成的。DNF只是我们其中的一个案例,在这个案例之下,我刚才提到所有的品牌都在做这样一个事情。我们在耕耘一个忠诚用户池,在这样的用户池之下,不管产品未来的大迭代,还是出手游,这些用户都能够在你的品牌,在你的IP之下,我们布局更远的未来。

TalkingData高铎表示:“在今年的ChinaJoy上我们做了一个报告,发现具有IP元素的游戏从数据上呈现出冰火两重天的态势,有些IP注重于品牌运营,注重玩家的维护及运营,会发现它的人群活跃有两次高峰期,而它的用户活跃和付费是逐渐的很缓的下降,换句话说,它的收益是最大化的。另一种态势发展则是,上线后只有一次高峰,之后快速跌入“谷底”,用户严重流失,我们戏称为这是“割韭菜”的IP.”

说到九折的时候,我很纳闷,游戏,尤其是重度游戏,一般是汉子的事,怎么突然进来一个女汉子,我很想知道你进入这个坑多久多深,为什么?作为女性玩家体验的游戏快感到底来自于哪里?

资深95后玩家代表九折:感觉很多人有这样的疑问,其实我很简单,就是一款游戏,如果它有个亮点,它在剧情方面,或者社交性方面,或者说它有给我什么感觉,就有一个点吸引人的话,我觉得不管是女性玩家,还是男性玩家,不管是什么年龄阶段,肯定都会有人喜欢它的。我也是比较肤浅,我一开始玩游戏也是别人带我入坑的,我发现这个游戏的魅力之后才有兴趣了解它,深挖它有哪些出色的地方。包括以前的老游戏《魔兽世界》,包括最近的《守望先锋》,有些热门的吃鸡的游戏,有些游戏内容方面很吸引我,它们有内涵,有内容,有剧情。像吃鸡、《王者荣耀》有社交性,我可以在游戏里面认识新的朋友,甚至这款游戏给我很大的满足感,我吃鸡胜利的时候,满足了我胜利的心理。

TalkingData高铎:感谢九折的分享,我们从数据的角度来看,14-18年女性玩家的比例在逐年增长。大家看到的是游戏行业似乎整体停滞了,但是在很多垂直的领域中,譬如女性玩家,95后年轻的女性玩家是一个增长点。如果一些游戏公司,更愿意花精力在这个垂直领域挖掘出来让九折更喜欢,更投入的游戏,相信增长会很快的。

还有一个问题抛给麦当劳的汤总,我先分享一个好玩的事情,中欧一个教授上个月给我们上课的时候说,他太太不让他讲在哪里求婚的。上个世纪当地第一家麦当劳开业的时候,他和太太是大二的同学,他说那时候麦当劳代表他们内心对年轻时尚国际化的认知,所以很兴奋的在麦当劳求婚。现在我们再去麦当劳,每天看到有一堆小孩在那儿写作业,麦当劳的消费者群体在发生变迁。换句话讲麦当劳也面临消费者升级或降级的问题。麦当劳在消费者的升级或降级的变化中,有哪些相对应的策略?

话题:麦当劳在消费者升级或降级的变化中,有哪些相对应的策略?

麦当劳汤俊章与现场来宾分享了这样的观点:消费升级跟降级,降级是最近大家谈的话题,升级,所谓的消费变形是我们每年都要花很多很多的经费,包含大数据去挖掘一些洞察。我觉得很有趣的几个点,跟大家分享一下,我们发现现在的消费者有几个特性,第一个就是说,大家越来越对,我们叫方便的重新定义。

因为现在的互联网时代,新生代造成大家现在是没有耐心的,就是我现在想要得到一个东西,我立马要得到。麦当劳从你刚才说26年前到现在我们做了很多的调整,各位有去麦当劳用餐会看到有一个很大的点餐屏,因为我们发现年轻人不喜欢跟人家交流的,他就进去一句话不讲把餐给点了,然后就想走了,在这过程里不想跟任何人讲话,他可能就想玩个游戏或者干嘛的,有个自己的时间点,面对这些东西我们的确是需要一些改变,这个过程我们又发现,我们给了一群人方便,但同时我们带给另一群人不方便,就是家长的群体,因为有小孩在旁边闹,他其实很需要有人服务,我们就在里面加了一个功能Table service,其实你点好餐马上找好一个位置坐下来,像麦当劳基本上都是点餐,拿到餐才去找位置,你可以先坐下来,有人会把点好的餐送到你手上。这些都是根据用户的洞察,每年我们会做一些服务的变更满足不同的消费者。

不管在定位上,还是服务上,不可能是一成不变的,每年必须要调整。包括消费升级的部分,麦当劳大家熟悉的产品是巨无霸这些产品,我们做很多调研发现,消费者说我真的很喜欢这产品,但可不可以有些别的产品。去年我们推出比较高档的星厨系列,跟时下比较年轻的偶像群体,比如谢霆锋会做我们的新厨师代言,开发新的产品,变成我们新厨的代言人,推出高端的产品汉堡,满足消费升级的部分。

消费降级的部分,在我们现在的观察里面不觉得它已经成为一个趋势,但它是一种现象,在这个现象的背后,很多人并不是完全为了省多少钱,而是觉得在过程里面很有趣。

TalkingData高铎:我也想分享一下关于消费升级和降级的观点,我的观点不存在消费降级,消费降级是大家的一个误区,认知的误区。从整体来看,整个的社会阶层都是在消费升级的,只是说原来我们都生活在一线城市,我们关注的是一线城市、二线城市的消费,三四线城市的人不触网,他的很多消费习惯你是不知道的,所以你会发现,一线城市的人消费在升级,突然你发现74%的不知道世界突然冒出来了,三四五六线城市的人,他们有了移动互联网,能够上网买东西,他们在里面买的东西很便宜,他们在抖音、快手、B站里面发的东西你觉得很low。实际上这与他们原有的生活相比,还是升级的。

譬如我去一个地方旅游,那个地方只卖老干爹;你去买泡面,那是康帅傅。但现在由于有了这些电商平台,一堆人一起拼了一个单,单价可能是13.99元,20.99元,在我们一线城市生活的人看来,这个品牌可能卖100多块钱,那么低的价格你就买了,消费降级了。这就是不一样的视角看事情,你天天过这个圈子的生活,你看那个圈子好像降级了。但是对于那拨人来说,他的生活更便利了,他买的东西更有品牌保证了,更有质量了,是升级了。

所以群体身处的场景与站的角度不同,看待事物的观点也不尽相同,这就导致了消费降级的误区。总体来看,消费者整体是在升级的,互联网的发展改变了这个社会信息的透明度和传递的路径,和传统商业的经营方式,让我们很多的认知产生了很大变化。

话题:如何去构思跨界营销,以及想在其中收获到什么价值?

腾讯张戈:这个问题有点大,腾讯在跨界这块我们也在摸索。我是觉得要谈跨界,我们最好先对“界”有个定义。在腾讯的营销体系之间这种理解之下,我们认为营销的本质,是正确的渠道上用正确的内容跟用户正确的沟通。在这其中,出现了一个问题,关于“界”,我们现在理解它更像是圈层,是跨圈层的,而不是说我跨产业、或者是跨行业,它更像跨圈层的,这是从营销的角度看这个问题。

在这个圈层之下,我们看到不管是B站、抖音、朋友圈、微博,所有的这种产品都存在自己不同渠道领域上面的一种文化氛围。基于用户本身年龄不断的向下的下沉,会看到00后、95后,这样的人群,他们对于圈层文化的热爱和兴趣,远高于我们这一代人,我们这一代人可能就是赚钱、工作、买车、买房,他们却是享受生活,活在当下,投入自己的注意力在自己兴趣的东西上。在营销的层面上我们要想办法理解和认知他们所处的圈层,在他们圈层之下,我们再来思考跨界这个东西,我们怎么能够打动,并且影响到他们。他们在游戏端的热爱,换到另外一个文化圈层,另外一个行业的圈层里面能不能还有一种热爱,这两种热爱进行融合,之后出现新的跨界营销的创意思路。

因为汤总也在,不知道您怎么评价《王者荣耀》五五开黑节和麦当劳的合作。五五开黑节是在做一个用户的文化,就是他们的节日,专属于《王者荣耀》用户的节日,这就是他们的文化,他们的热爱。五五开黑节我们会发现年轻人群他们想要的是社交,第二他们线下的需求比我们这代人往往还要更胜一点。他们想要在他们希望的环境之下,用他们热爱的东西进行交流,这是年轻人想要的东西。

麦当劳现在在讲家庭,讲小朋友之间在麦当劳里面的社交,包括table service在内,其实都是讲怎么在店里做创新,让用户怎么能够交流和社交起来。而王者荣耀做五五开黑节,我们要做的东西是开黑,与麦当劳的需求是完全契合的。对汤总来讲是麦当劳的品牌方向,对王者荣耀来讲是整个文化圈层的打造方向,从这个角度上我们做跨界。我们内部认为五五开黑节和麦当劳的合作是非常成功的,为整个的《王者荣耀》文化圈层带来了新生的关注度和一些我们未来的文化沉淀,我们是这么思考的。

在整个腾讯里面我们目前整体的思维都是这样,我们怎么去做能够沉淀下来的一种关于用户圈层文化,再和其他的文化圈层做跨界,让用户热爱,让他喜欢,让他对我们的品牌忠诚,这就是我们的思考。

麦当劳汤俊章:“我们跟很多游戏业者都有合作,包括腾讯说的《王者荣耀》,网易的《梦幻西游》,还有《魔兽世界》我们都合作过,我自己有过游戏的经验,我刚来到麦当劳,发现游戏的个族群这么庞大。他们也是人,基本上他不只是一个ID,他是一个活生生的人,他要吃饭的,食衣住行都要具备。麦当劳为什么不能成为他这一个人里面其中的一个元素呢?所以这是一个刚性的需求。

我发现过去的游戏业者很关注在线上,但是线下也是有需求的,在这里面很自然的就可以有一个很好的结合点。我们在评估怎么样是我们合适的跨界品牌,有几个要素,第一个要素门当户对,我们一定找这个量级,可以跟我们在同一个量级的游戏,不管是当时的《魔兽世界》《王者荣耀》《梦幻西游》都觉得这个量级是跟我们,双方跨界的时候都是双赢的。

第二个消费者是人,他线上线下需求的点,我们要找到有趣的洞察,这个洞察结合起来双方是很有趣的,才觉得这个跨界不是硬跨。我们跟《王者荣耀》有一款产品叫巨无霸,巨无霸讲的王者的概念,就是说它的品牌形象是“唯一”。我自己是《王者荣耀》玩家,所以我对王者的精神很清楚,每场里面都有一个MVP。我们觉得每个消费者,或许我们在不同的时节,不同的场合里面,都可以成为我们自己的MVP,成为我们自己的王者,就像巨无霸的精神是一样的。所以我们觉得在两个品牌跟游戏的契合点里面有一个很好的交集点,那时候我并不知道它的改版内容,但是我们觉得这两个品牌在这个基数之上,又是这么有趣的结合,因为我每年都要必须对我的巨无霸产生一个投吃,我们可不可以玩一个不一样的东西?我的用户族群又是这么贴近,是很年轻的人。麦当劳也是一个餐厅,也是一个place,希望年轻的用户群在线下有些交流。包含腾讯介绍我们有五五开黑,在线下也有活动,也是符合用户的体验。所以线上线下刚好有一个很好的结合。

就回到你的问题,怎么衡量这是成功的跨界标准?第一个来自于很强的用户洞察,第二是双方可以互利的,不只是单纯的,我们麦当劳有很多合作,跟我们合作过就知道,我们不喜欢谈钱,我们谈的是品牌,钱是后面的事情,在前面的事情做对了,钱就会来了。我们一定是,就是说双方除了流量的转换之外,最主要是顾客在这个体验里面,过程里面是觉得有趣的,而不是单纯的一个行为。

TalkingData高铎:感谢汤总的分享,我能从他的分享里提炼两个观点,第一个想跨界就要对人群做洞察,知己才能知彼。第二跨界是一个谈钱伤感情的事,但是跨界之后两个品牌要有互相溢价,品牌能获得价值增长。当然这是汤总的观点,张总的跨界本质上也是不同的圈层打通,打通也是想做到价值最大化。但是,一个是做游戏的,一个是做餐饮的,都想做跨界,割的韭菜是九折。比如说九折是腾讯的游戏玩家,还喜欢麦当劳,你就是那个“界”;我就是界外,因为我不玩游戏,麦当劳我倒是常吃。

我觉得在我这儿,吃麦当劳你想给我整游戏优惠券什么的让我玩游戏基本上没戏,跨不通。但是这个界应该在九折这儿,我就在想,作为一个资深的游戏玩家,你在玩一个游戏的时候,比如麦当劳在你的游戏里面植入了什么元素,能让你,或者其他品牌能让你产生情感共鸣,能让你既在游戏这儿玩一点,花这个钱,说不定也去麦当劳买东西,双方达到了品牌的共同增长?虽然你是一个韭菜,但是我想大家都会喜欢。

95后玩家代表九折:对于一款游戏,我喜欢它,会在我心中建立一份游戏的形象,这时候麦当劳推出一款很戳我心的东西,能和我心中那一部分产生共鸣,就很心甘情愿为你们掏钱,有的时候不仅仅是游戏,其中也包括套餐里面附赠的玩具。

TalkingData高铎:通过TalkingData的数据探索发现,喜欢麦当劳的人更喜欢的游戏是电竞类,其他的一些重度的,如《王者荣耀》、《英雄联盟》。肯德基的人群更多的是棋牌类,休闲类的游戏。由于这两家企业运营手法不同,消费群体慢慢在产生变化。反过来看《王者荣耀》和《绝地求生》的玩家偏好,你会发现玩《王者荣耀》的人,更喜欢宝马,《绝地求生》的玩家更偏向于买优衣库等。

对于跨界运营与营销策略,我的观点比较明确,第一找到“界”在哪里,就是发现共同点,第二找到“界外“在哪里,就是挖掘差异点,基于共同点定策略,基于差异点提升各自价值。

干货分享丨研发代码质量管理技术最佳实践

如何高质量快速交付研发产品是每一位技术研发永恒追求的目标,如何在快速迭代发布下保障研发产品质量是每一位技术研发要共同思考的问题。

近日,在“安卓巴士全球开发者论坛·北京站”会议上,TalkingData SDK技术研发经理韩广利做了题为《研发代码质量管理最佳实践》的主题分享,将TalkingData SDK完整的质量保障体系的创建过程和最佳实践分享给所有开发者,希望能够对大家有帮助和借鉴。

TalkingData SDK技术研发经理 韩广利

以下是韩广利的分享精粹:

在演讲之初,韩广利首先分析了移动端平台发展趋势,包括以下三个方向:

  • 首先,双卡是移动端平台的主要趋势,今年9月发布的iPhone最新机型已经支持了双卡,这对于市场将起到很大的驱动作用。
  • 其次,由于人工智能的不断演进,两大平台也不断对其进行技术跟进,比如安卓平台的TensorFlow,以及iOS平台的CoreML。
  • 第三,用户隐私政策会越来越严格,不仅用户自身非常重视隐私,国家相关法规也日益完善,移动端平台的行为权限将逐步受到严格约束。

TalkingData基于相关政策为不同平台提供相应的适配和支持,也正因如此,就需要一个良好的代码质量管理体系去保证TalkingData SDK的质量和稳定性。

回顾TalkingData SDK整体架构的演进史,可以简单分为三个阶段:

  • 简单分层:只支持一条业务线;
  • 多服务:满足不同业务线逐渐增加的需求;
  • 微服务&模块化:满足不同开发者打包定制化的需求。

在功能叠加的过程中,需要对代码架构进行调整,那么此时应该思考两个问题:架构调整的原因什么?调整的目标是什么?

带着这两个问题,韩广利从四个部分进行了阐述。

代码分支管理

当代码分支不断增加,现有的人力和技术框架将无法支持功能的快速迭代。即便在某一个分支上解决了bug,但还需根据不同的场景将其添加到不同的分支上,分支的代码就会产生很大的差异,又需要投入更多的精力和时间去解决相关问题。

为此,TalkingData SDK进行了改造,将分支分为:对外发布交付分支、开发测试分支、以及个人创建分支。同时,也对原有的直接拉取分支的原因进行了一些反思:在架构设计之初,代码之间的耦合性较强,同时没有从业务或数据角度去进行独立设计,在打包的参数上没有进行动态配置。

为了改变现状,TalkingData制定了三个目标,一是改变模块之间的通讯方式;二是重新设计代码功能模块;三是约束代码之间的边界,尽量消除耦合性。

解决方案主要采用了微服务的思想——服务之间相互独立,随意调用或组合;对功能模块和数据模块进行了拆分;改变通讯方式做到解耦的效果,又将动态的配置参数分离出来,实现了支持多条业务线,并且可以满足定制化的需求。

在打包上进行了标签化的管理,同时配合标签检查脚本,达到定制化勾选和服务的打包功能。

韩广利表示,在架构重构时,需要进行一些取舍和选择,其核心思想是:架构在于目的而非框架,因为架构最终是要服务于业务的。他还提供了5大原则作为参考:

  • 独立于框架
  • 可测试性
  • 独立于UI
  • 独立于数据库
  • 独立于任何外部代理

而在选择架构时应从易于维护、易于测试、内聚以及最核心的解耦出发,要让模块之间互相独立。

SDK功能打包管理

TalkingData SDK提供不同业务线打包的定制化开发需求。在庞大的体量中,如何保证打包的功能正常、方便测试?为此,在设计目标当中加入了分层的考量,首先是用户输入信息:邮箱、业务线以及所需平台,然后是整个平台的业务处理、输出的用户申请功能包,最后通过邮件发送给申请的开发者。

逻辑流程如下图:

在打包管理中,比较常用的工具有 GitLab、Jenkins、Server。

代码review规则及流程

在代码review中设置人为检查和脚本检查两种机制。

在人为检查中,负责review的人员必须要参与最初的需求和设计的审核,不仅要了解整个功能需求的细节,还需要对功能或测试负责,撰写review checklist,最后要交付review 模板,在出现问题时可以进行问题追踪。

在脚本检查中,需要进行编译和制定代码规范、静态代码检查,以及安全漏洞等方面的工作。

以上两种机制可以让代码review真正起到作用,而避免沦为形式化流程。

TalkingData SDK在代码review时有几种方式:

  • 1对1:改动较小的bug、需求和优化
  • 1对多:改动较大的bug、需求和优化

与其他公司选用技术主管或特定人员作为代码review人员不同的是,TalkingData SDK 的代码review主要由组内成员相互之间进行,这样对于个人的技术和框架理解会有所帮助。

代码review模板主要有三个部分:谁做的review?发现了什么问题?如何解决整个问题?好的代码review模板要做到问题可记录、问题可追踪。

代码质量管理的工具

在代码质量管理的流程中,TalkingData SDK在代码托管上使用了GitLab,在项目管理上使用了JIRA。之所以选择这两个工具是因为两者可以互相打通,方便后续在遇到问题时可以根据记录进行排查。

研发流程如下图:

其中,单元测试在研发中是非常重要的,开发者写完一个功能模块的主流程通常没有问题,可以做到自测;但是分支的一些处理流程,即便交给测试人员也很难测试出来。因此单元测试就显得尤为重要,它可以覆盖很多异常分支,所输入的条件在参数当中可以动态设置。

QA测试流程如下图:

在前期,会由研发和QA整理一些测试用例,分为高中低等不同的级别,研发在提测时会有测试通过率,以保证测试的效率。

另外,TalkingData SDK 在上线后也需要去做一些监测,比如交付质量、对不需要功能做删减、打包的完整性等等。

总体来说,即采用微服务的思想,尽量让功能模块化管理,利用工具管理流程,进行单元测试,同时上线前后都要设置一些检查策略,做到万无一失。

最后,韩广利表示,流程并非形式,需要真正地落地执行,长此以往,就会对效率有很大地提升。