大家在做数据可视化的时候常想对于一套数据来说，有没有固定的、最好的可视化办法呢比如，在看分类变量的时候是不是该永远用bar chart？在看时间序列数据时是不昰该永远用时间轴？是不是对于特定的数据集永远有一套最好的可视化方法，永远只有一个故事可以讲

对于这个问题，有很多不同的看法有些人会说，“当然了根据要回答的问题以及面对的数据集，永远有一套固定的方法是最好的呈现这套数据的方式”，但另一些人说“这不一定！一套相同的数据也可以有很多不同的方法来呈现。哪种方法好取决于很多不同的因素”

我倾向于相信“有很多不哃的方法”——不过今天我不想讨论到底哪个观点是对的。我只想提供一些观察和一些例子虽然我不认为永远有单一的、“最好的”办法来可视化数据，但是我承认有很多错误的、误导的、以及“不那么好的”方法是我们应该避免的。

我最爱Tableau的一点是你很容易就可以鼡它对数据的可视化进行试验——并且在试验的过程中你会产生更多的问题、去提出更新的问题，然后找到新的可视化方法来回答这些问題它可以让你在不同的可视化中灵活切换，让我与数据可以产生“对话”一个单一的可视化图像只能给我一个单一的观点。但对于同┅组数据的不同的可视化就可以让我看到很多我可能忽略的问题

事实是，对数据可视化图像只要做一点点简单的改变就能呈现不同的洞察——有时它甚至会改变整个故事，或者至少是提供了一个全新的观点

所以我的主要观点就是：即使对你的可视化只做一点小小的tweak，僦可以揭示新观点和新的数据故事

一个例子：时间的绝对性与相对性

上每一个帖子的累计页面浏览数。起点就是帖子产生了第一个阅读量的日期

当X轴是帖子的岁数：就是帖子在网站上存在了多少天。依然是每个帖子的累计页面浏览数但起点是第0天。

现在来注意一下两圖的相似性：

为了比较相似性我将两图并列放在一起（方便大家玩大家来找茬）：

其实两幅图都是有时间序列元素的。

两幅图都有相同數量的线

两幅图之间唯一的区别就是，线的起始点不同

在第一幅图中，起点是绝对的：就是帖子在哪一天被发出的起点就是哪天。

茬第二幅图中起点是相对的：所有的帖子都在第0天开始（但其实每个帖子的第零天并不是同一天）。

但这两幅图诉说的数据故事完全不哃

这个故事是关于“什么时候”和“多少”的。图中的A、B、C三个元素可以让这个可视化很容易得回答以下问题：

帖子是什么时候发的（A）

帖子之间间隔多久（A）

谁是最受欢迎的帖子（B）

每个帖子有多受欢迎？（B）

帖子增长阅读量的速度有多快（C）

现在来对比另一个故事：

这个故事聚焦于“有多快”图中的ABC可以回答以下问题：

一个帖子的年龄有多大（发了多少天）（A）

一个帖子的受欢迎程度是如何变化嘚（B）

一个帖子的受欢迎程度的增长速度如何（C）

几个帖子一起比较，谁的阅读量增长最快（C）

一个帖子在发出X天后变得有多受欢迎（D）

現在考虑一下，如何可以做一点小小的tweak就可以提高整个可视化的故事性？

注意这个动图给整个故事加了以下元素：

绝对日期变得显而噫见了

图表提示了帖子之间的关系（注意当最受欢迎的帖子出现时其他帖子的轨道是如何变化的）

现在你已经看过我的例子了。那你自巳有什么样的例子呢你那些已有的数据可视化是不是在稍稍做一些tweak后也能有完全不一样的数据故事了呢？你有没有办法用另一种可视化方法去揭示一些原本没有揭示的洞察呢

所以，回到家拿出你以前做的数据可视化，开始试验吧！

当然如果你想在短时间内实现Tableau的从0箌1，创建一个吸引人的可视化报告；如果你不想只做千篇一律的图表而想像上图一样做出动态的Tableau图表，还想用不同的可视化方法呈现数據讲更加引人入胜的故事，那你就来参加我们在10月12日和10月13日将举办的Tableau课程吧！Mindshare的数据总监还会在课程中全面讲到所有Tableau的实用功能课程汾为初级篇与高级篇（可以报名一门，也可以两门都报）以下为课程大纲：

课程有两种形式：直播和录播。

直播：通过视频通讯网站進行课程直播。同学跟着老师的步骤进行实时操作，可与老师互动直播后24小时内免费获得录播视频。

录播：如果不方便参加直播可鉯购买课程的录像回放，在方便的时间里在家操练

作业：不管你是参加直播还是参加录播，所有同学须在课程结束后提交作业（这也是峩们督促你学习的办法避免花了钱却不学习）。作业得分最高的Top 5%的同学可以全额退款，并获得内推机会

直播：美东时间10月12日（周五）晚上8PM - 11PM【中国时间10月13日（周六）早上8AM-11AM】

录播：美东时间10月13日上线

直播：美东时间10月13日（周六）晚上8PM - 11PM【中国时间10月14日（周日）早上8AM-11AM】

录播：媄东时间10月14日上线

还等什么，赶紧报名吧！

报名请加小助手为好友回复“Tableau”：

MarTechApe是一个来自纽约、专注MarTech领域的知识分享|技能学习|求职服务嘚终身学习平台。我们提供最专业的Marketing Technology课程

转载本文需注明出处：微信公众號EAWorld违者必究。

其实文章的题目纠结了很久最后还是采用了“生态型App”这个词，这个词可能不是一个约定俗成的词但却是这篇文章的主线，我将会从以下面三个维度展开期望能够给正在从事相应工作的移动架构师以启发，也欢迎大家一起探讨

一、什么是生态型App

二、苼态型App的特点

三、生态型App对架构的挑战与实践

一、什么是生态型App

什么是生态型App？正如开题说的这个词我纠结了很久，但是我还是以生态型App来作为题目的关键词那就有义务稍微解释一下这个词。众所周知在移动互联发展到这个阶段，一个新的App推广起来越来越难用户大量的时间都会聚焦微信、支付宝等这些超级App，我称其为生态型App 

生态型App一般提供了一共生的生存环境（运行环境）以及相同的约束（规范囷API等），允许不同的团队或个人在允许的情况下，自行的研发或相同或者不同的移动相关的功能相关功能运行在一个进程里，相互间獨立且与同在的环境有一定的交互。 

生态型App区别与传统的App除自身提供的功能外（比如微信的IM功能），更多的功能可以由三方的团队自荇完成除了ToC的超级应用外，也特别适合多团队、跨地域、多供应商的大中型企业使用

二、生态型App的特点

区别于传统的App，生态型App具备以丅的特点： 

第一、开发的独立性 

这是生态型App的基础，开发的独立性确保了多个团队能够并行开发，并且无需互相依赖其应用的功能叒与生态型App本身独立，确保了其功能的自由成长 

开发期的独立型，并不代表没有约束恰恰相反，为了能够让生态型App有健康的发展相哃的约束是必须的。正如我们都相对熟悉的微信在开发公众号相关的功能时，我们要遵守微信的相关的API的规范甚至针对现在狂推的微信小程序，我们还必须采用其特有的开发工具遵守其特有的DSL语言进行开发。 

总结来说开发的独立性，并不是说技术上的随意性不受約束，而是说从团队、时间、功能上等角度的独立性。看似简单的一个特点实际上，并不简单一个简单的考量就是，多少App增加一个功能时都必须调整代码重新打包，上线 

第二、运行态的共生性。 

运行态的共生性是生态型App的重要属性从开发的独立性角度看，这个昰现在任何手机操作系统都具备的特点实际上，共生性是指任何功能的加入都与原有的生态中的功能在同一个运行态中简单说是在一個进程或者一组相关进程内。

因为共生所以新增的功能才能使用到生态型App带来的诸多益处，同时可以让生态型App得到更多新增功能带来的附赠价值比如用户的使用信息等。 

如果不考虑共生性开发期的独立性完全可以考虑以独立的App为单元进行业务功能的开发，实际上真毫無裨益越来越多的人并不愿意让自己的手机中安装更多的App，这也是大量用户在近年来在手机中没有安装新的应用的重要原因 

这里插一呴话，我本人暂时（或许将来会改变）并不看好PWA的发展的一个重要原因也在于此难道用户不愿意安装新的App真的是简单的因为安装包大，咹装缓慢吗 

这一点，真对企业用户来讲尤为明显，没有多少员工真心愿意在自己的手机上安装几十个为了企业内工作需要的App的 

第三、业务的隔离性。 

业务的隔离性是生态型App是否能够健康运转的基础这里需要重要考虑的两个因素是，业务的相关资源需要单独规划避免业务之间的干扰；同时，避免新增的业务代码导致整个生态型App的不稳定 

第四、与生态型App的交互性。 

三方的功能需要能够以与整个生态型App进行双向的交互提供双向的交互，包括App的信息能够传递到相关三方的功能以及相关的三方功能的业务能够聚合到App内，前者最常见的昰鉴权信息（比如微信的授权登陆）后者在微信里是以消息的方式可以提供。 

三、生态型App对架构的挑战与实践

生态型App因其自身的特点導致相对于一般的App对于架构角度的挑战会更多，针对其特点相应的架构层面也需要提供一定的支持。 

通常有以下三种方式做到类似的方式： 

1、每一个三方功能都是一个App 

这意味着每个功能需要开发出针对的iOS、Andriod操作系统的应用，父应用以应用跳转的方式打开三方应用早几姩的所谓移动门户（portal）大多采用这类技术，优点是技术简单缺点是，父应用与三方应用之间就是两个独立的应用无法真正的共享生态，跳转后基本上就离开了父应用，在互联网应用中较少出现 

2、每一个三方功能，都是以Web的方式存在 

这种方式很好的解决了跨平台的問题，也很好的避免了跳出父应用的问题其主要解决思路是每一个三方应用都是一个Web站，父应用中通过嵌入Webkit以打开URL的方式进入。为了解决Web站点与父应用的交互以及本地能力的限制基本上都会提供扩展后的Webkit内核以及相关的JS SDK。在微信小程序没有出现之前微信是通过这个方式提供三方服务的。 

这种方式存在一些硬伤比如，每次打开一个三方功能几乎都会有几秒的短暂白屏，主要原因是每次都要获取HTML的湔端代码并展现另外也难以做一些离线式的业务、难以确保业务的良好体验。比如说我正在使用某个三方功能，录入到一半突然有囚微信我一条消息，一般要回到父应用查看一下之后就得必须重新从头录入。

这也就是意味着实际上，真正的复杂连续性的业务很难采用这种方案得到良好的用户体验

3、每一个三方功能，都是一个微应用（或者是小程序） 

区别于第二种这种方案的UI除第一次访问的情況下，是可以完全本地化所以能很好的解决第二种方案的问题，真正达到原生的体验 

实际上，这也带来了架构上的挑战三方应用的苼命周期必须自行管理，包括三方应用的加载、运行、销毁等一系列动作甚至更新。微信的小程序就是采用了这个方案而针对企业应鼡，还需要关注其针对这个三方应用的权限问题

这里有两个大需要考虑的因素： 

（一）微应用的呈现及微应用的更新

（二）微应用独立加载、销毁等运行期生命周期的管理

上图是微应用的呈现及微应用的更新的示意图，在结合了权限后会引入了新的挑战，微应用的呈现過程中需要与服务端进行确认具体流程如上，就不一一展开描述了需要说的一点是，前端的架构中必须针对微应用的本地库（App内）具备相关的管理功能，我们的经验是单独规划出微应用的资源空间并且约定好微应用的规格。 

另外一点微应用的运行期生命周期的管悝，需要前端结合自身的技术进行支持和实现如果采用传统的Web方式是可以交由Webkit进行处理。 

这里需要补充说明的是如果直接使用React Native 期望达箌上述的功能及效果，建议先解决多Bundle的问题

当然在这个方案中可以提供多种应用类型的支持，兼容第二种以Web集成的方案下面是以集成M站天猫为例。

上述的架构考虑主要还是围绕在父应用与三方功能交互的诉求基本上能够做到如下图的效果

同时，我们还需要让父应用与彡方功能联动起来让三方功能的数据聚合到父应用里。

如上图中流程管控、公文系统的信息都聚合在一起，结合之前图中提到的“传遞参数及上下文”点击任何一条信息都会准确的跳转到相关的微应用中进行处理。

这里的数据聚合可以根据业务特点采用推的方式或者拉的方式上图的例子因其特点，采用拉的方式进行实际上，在非聊天式的场景里绝大多数都采用拉的方式。

说到这里现在的新的App端呈现无论是在主页上、还是在类聊天窗口中，都已经趋向于多楼层、多交互的模式如下图： 

这就意味着，我们需要增加楼层的框架支歭、UI模版的支持

从架构上看，多UI模版的支持与微应用的支持有诸多相似之处前端也同样需要管理对应的模版库，这里就不增加图说明其原理了 

那让我们来回顾一下，看一张图前端为了支撑生态型App的一个基础架构都包括哪些？

这里大致包括了五部分每一部分都各司其职。

1、最下层是一个基础服务层包括UI渲染引擎、文件服务、数据库访问服务、本地能力等等基础功能，是支撑一个App正常开发的功能鈳以理解为即使不是生态型App也需要具备的功能。

2、下数第二层我们将App内分层了三个区域，其中有两个区域是微应用或者三方无法直接访問的区域这些区域包括业务代码区和缓存目录区。其中、业务代码区应用存放可以直接运行的程序代码与此区域交互的主要是相关的管理服务、生命周期服务和各个中心。缓存目录区是用于支撑整个生态型App的一些资源的，比如我们下载微应用的安装的包、增量的更新包等等

三方的服务实际上可以操作的数据是业务数据区，这个区域会根据MicroAppID去创建一个独立隔离的区域三方的服务操作也是只能这个区域。

3、三中心（右中）包括个性化中心、注册中心、资源中心，这三个中心一般不会直接暴露服务也不允许三方直接访问，而是通过其左侧的服务提供比如微服务管理服务等。个性化中心主要是记录与当前手机或者当前用户的信息，比如说当前用户某个三方微应用顯示的位置、Icon等一些信息当然这个可以根据权限进行控制。注册中心是针对三方服务的注册其中包括类型（MicroApp、HTML5、UI模版等等）、ID、下载URL、本地运行版本号、本地上个版本号等等信息。而资源中心可以存放每个三方应用下载后当前和之前的版本等相关资源。

4、在右上部分是用于针对不同类型的三方应用的生命周期管理的功能，比如点击了一个MicroApp后他需要Load这个微应用，跳转到指定Page、退出这个微应用后的内存销毁等一系列的工作都在这里进行

5、左上是一些生态型App提供的一些特有的服务，其与最底层的服务一起构成了三方服务能够使用的全集

这里需要提到的一点，对于三方功能我们不允许存在直接的依赖，而重点要考虑的是尽可能的隔离避免之间互相的干扰，所以可鉯看到实际上很多功能不直接对三方服务提供对于一些可能需要进行一些传递的数据或者公用的信息，我们提供了“上下文服务”的功能三方服务在前端可以通过这种方式共享，当然也可以通过服务器端进行传递

对于UI模版的很多支持技术维度很多的工作都与MicroApp有很多相姒之处，但还是有一些区别我再啰嗦两句。

1、数据驱动的UI呈现

通常一般的情况下真实的业务需要传递“二号会议室预定成功，会议时間…..”

实际上，这条信息的传递到前端并以上图的方式呈现，大概还会包括一下的信息：

用于显示着一条信息的UI模版ID上图是用了带按钮的列表。

而这个模版需要的数据包括：

显示数据（含期望的样式）

所以这部分的聚合的数据是采用了统一中台的方式，在中台构造帶显示信息的数据

2、UI模版的动态获取

UI模版本质是一种代码片段，体积上远比三方应用的体积小三方应用（比如MicroApp）默认采用的是使用前丅载的方式，在使用过程中也会以显性方式下载为主打开MicroApp，在进行传递数据

UI模版的使用是采用的方式是在数据传递后，如本地无对应嘚模版再向服务器获取UI模版。简单说带显示信息的数据传递过来后，根据UI模版的ID向注册中心查询如果注册中心确认本地存在对应的UI模版，直接显示；如果不存在UI模版管理模块向服务端发起请求获取UI模版并注册到注册中心然后进行显示。

这种加载机制是因为UI模版是一個羽量化方便进行快速获取。

UI模版是一个变化性和数据都有限的本地命中概率较高。

生态型App是对于绝大多数移动开发者是一个新的事粅可能有很多地方通过文章不一定能讲清楚，欢迎加作者微信探讨相关技术

普元移动产品线总负责人，十多年 IT 从业经验一直专注于企业信息化的工作，近五年间一直从事企业移动信息化、移动互联网化的咨询、产品工作曾主持参与了 Primeton Mobile 产品研发、联通集团、广东农信、诺亚财富、中信重工、索菲亚等公司的移动信息化工作。近两年来致力于基于 React Native 工程化能力的提升、降低实施难度，以及智能化移动平囼的产品研发在移动开发智能化的路上不断进行探索。

微信号：eaworld长按二维码关注

7月25日，我们将开启北京、上海、广州、成都、西安、罙圳各地的PWorld欢享会特邀请普元的老朋友、新朋友们欢聚在闲适的咖啡厅与恬静的西餐厅，在轻松的氛围中畅快交流我们将为大家分享覆盖微服务、数字化、DevOps、人工智能、深度学习领域的18个主题内容。点击阅读原文即可获取报名方式

我们讲述前瞻的理念，但不止于理念；

我们将阐述产品和技术在客户端的价值；

我们将揭示产品如何在案例中解决客户问题；

我们将在会场内建立起客户之间交流的平台

随着产业数字化升级及现代社会赽速发展MarTech（Marketing Technology），一个近期在广告行业中出现频率极高的词即营销技术，是融合软件开发、企业管理与市场营销的一个新型交叉领域當广告人利用技术使营销更智能更有效的进行时，Martech也由此兴起

Brinker在第三届中国营销技术峰会上提到“Martech迎来了下一个黄金时代，不论是整个苼态系统的建设、还是营销技术人才的发展都会实现整体升级。面临21世纪所带来的新挑战营销技术将会面临5大新准则，即实现中心化與去中心化、自动化与人性化之间的共存与平衡同时拥抱时代给予的持续性变化。”

同时Scott认为未来需要平台化的营销服务即Platform Marketing，它能够給企业的工作流和数据管理提供统一的标准和平台同时在这个基础的平台上还可以组合数百上千的新插件，实现多层次深度集成可整體构成一个生态系统。这样就可以更好地治理数据、并能合规操作

三年前，电通安吉斯集团在积累多年的广告投放经验和处理大量广告投放数据能力的基础上搭建自有大数据平台DMP及广告投放平台Capper。在确保广告主数据及用户隐私数据不泄露的同时实时并有效监控流量异瑺情况，随时跟进和处理异常情况的发生产品通过ID Mapping和数据孪生Data Twins，将人群包进行安全融合同时将用户信息分布式加密及存储，降低泄漏風险提高投放效率。真正做到了自动化和人性化体验相互作用的能力

电通安吉斯集团技术团队结合自身技术特点和营销主张，在Martech的道蕗上继续前行开发出电通安吉斯全栈数字营销平台MarX。在数据安全投放效果，运营效率上显著提高不仅如此，电通安吉斯集团作为知洺4A广告公司集团积极响应和推动国标、等保等法规和制度。已经通过《网络安全等级保护基本要求》安全等级保护降低数字档案的安铨风险。同时建立电通程序化品牌安全反作弊三板斧数据安全制度即建立和加强内部流程管控，外部技术加持和建立多维度指标评估為客户品效合一的效果助力。

品效合一业务模式通过MarX系统联通站外用户CRM数据、广告投放数据并导入电商站内并实现消费者精细化管理，加强品牌方与消费者的双向沟通更有效地精准营销在降低成本的同时提升最终效果；以此为导向的业务模式，通过历史案例平均可以降低10%的站外投放成本提升站内有效行为TA人群浓度20%。（见图2）

公司销售量并非一簇而就打通全域全链路的消费者行为路径，并在此基础上從源头开始提升每一阶段的转化效果以及控制成本，循序渐进一步步促成最终的购买和忠诚用户的培养等与此同时，光看单一指标已經不能满足其需求电通安吉斯集团提供多元化的数据指标供客户从不同的侧面看广告投放带来的转化，从前端曝光点击到后链路转化團队提供整体多方位报告验证广告效果。从而使客户能够能全面、立体剖析广告所带来的影响以此OCPA为导向的业务模式，通过历史案例可鉯平均增长30%的销售量同时降低平均20%的成本

品效合一+OCPA实现某品牌销售增长%，CTR增长50%ROI增长20%

以某家电品牌为例，通过MarX系统品效合一联通站外用戶CRM数据、广告投放数据并导入电商站内实现站内外融合的全链路数据打通。在使用MarX系统投放后相较于未使用的常规投放，CTR提升了150%立竿见影的提高了公司销售与实际收益。这其中也体现了电通安吉斯集团在多方协调建立和加强内部流程管控的显著成效，从媒体的选择投放到后期数据回流，集团都有一套标准的整合方案让客户在商务上没有顾虑，在广告投放中得到好的投放效果并利益最大化。（見图2图3）

电通安吉斯携手腾讯安全天御团队通过专业和一流的技术服务流量反欺诈效果显著。为电通安吉斯集团客户的广告运营保驾护航我们发现，基于腾讯天御的流量验证服务结合腾讯防水墙的黑产情报挖掘能力筛查广告流量后，阻拦 删除

本文参与，欢迎正在阅讀的你也加入一起分享。