iPaaS将成为客户体验的抽象层

chinafgj 发布于2019-06-03 15:27 / 712人阅读

摘要：将解决这个问题，并将自己建立为客户体验的抽象层，就像容器已成为操作系统之上的抽象层一样。数据碎片化或偏斜会导致客户体验分散或扭曲。

营销就像一个巨大的钟摆。

一年前工作的东西今天可能不起作用。今天工作的东西可能在一年后不再有效。在SaaS和数字产品时代，机会变得饱和，最佳实践被过度使用，一切都突然变得高度可测，更可预测，并且过度优化。我们依赖的东西随着时间的推移变得不那么有效，它的效率逐渐消失。

营销中的一切都注定了这个规则。

在我的上一篇文章中，我概述了过去5到7年间我们目睹的过程，基本上是营销栈的深度分散。我们开始认为，不同的垂直，松散耦合的高度专业化产品，而不是传统的单片方法，营销将更好地服务。

虽然这种“微服务营销”方法相对较新并且在行业中分布不均，但它已被一些最好的软件公司广泛采用。

对于大多数这些企业来说，它真的是一个真正的游戏规则改变者。它使这些组织能够设计出更好，更相关的客户旅程，更具创造性和有效性，并带来更多收入。

使用微服务设计方法可以获得明显的好处。这些包括成本效益，更大的灵活性，没有供应商锁定的风险，以及客户体验的一般优化。

但并非所有闪闪发光的东西都是黄金。

这种大规模的权力下放导致了许多缺点，这些缺点将导致向部分市场重新集中化的过渡。

以下是营销技术领域中这些整合重点的表现：

面向客户体验的iPaaS抽象层iPaaS（集成平台即服务）是一个高度专业化的营销技术系统协调员，能够通过Web API无缝协调不同的产品，这些都将出现在技术领域。

Segment是一款早期了解这一功能的软件，它帮助企业在不传统工程爆发的情况下与不同产品无缝集成。

我们即将走得更远，更深入。

实际上，企业不仅需要系统集成，还需要协调来自堆栈中包含的各种系统的输入和输出。

iPaaS将解决这个问题，并将自己建立为客户体验的抽象层，就像Docker容器已成为操作系统之上的抽象层一样。

＃ SaaS的定价冗余
当您使用多种SaaS产品时，这些产品以各种方式收费（每个座位，每次使用，每个产生的结果，每次API调用等）。您的营销技术支出可能变得高度不可预测。

当今SaaS系统的定价方法极为互联，依赖于众多因变量。您获得的潜在客户越多，您的CRM中可用的席位越少，用于丰富这些潜在客户的API调用越多，您需要发送的电子邮件就越多。

对于每个客户运营单位，您的定价可能会以非线性方式增加。在软件产品之间找到配置平衡是一团糟。

iPaaS将通过制作捆绑包来抽象复杂的定价层，这些捆绑包包含组成堆栈所需的正确剂量的软件。

通过支付单一定价等级，您可以访问大量潜在的隐形产品。

＃ iPaaS UX共用层
工具爆炸使公司更加灵活，但它也需要在应用程序之间进行大量的来回，以完成给定的任务（浪费的时间比您想象的要多）。

使用微服务设计方法，您仍然使用各种界面，这些界面以多种不同的方式起作用和表现。

它们中的每一个都以自己的方式独特，并且需要自己的学习曲线。

光谱

组织需要高度专业化的垂直产品，以实现其最终产出及其对业务的相关影响，而不是因为他们喜欢使用多个接口。（他们希望在整个堆栈中使用“最佳”：最佳的富集产品，最佳预测分析产品，最佳电子邮件可传递性软件，用于解析文本的最佳NPL工具等。）

SaaS爆炸将我们“工作”的这些元素分散到十几个工作空间中，使得无法专注于自我限制的环境。从现在的纯粹日常角度来看，转换成本比以往更高。

我们将看到新一波的反活性使用产品将推翻传统模式。

您不一定需要使用高级产品的界面来完成任务，您只需使用输出。反活性使用产品不需要在其价值链的任何级别进行人工干预。

iPaaS方面将面临许多UX挑战，使共享的UX基线足够灵活，可以建模并适应各种第三方产品。与此同时，这些低级产品也将面临如何向自己的客户传达和展示价值的挑战。

＃ iPaaS客户数据无处不在
今天的客户数据是明天客户体验的源泉。数据碎片化或偏斜会导致客户体验分散或扭曲。

任何想要能够影响客户体验的人都需要利用共享的客户数据层，以便随时提供最透明和最新的客户环境。

无论您的“分散堆栈”多么具有创造性和灵活性，如果您无法检索和利用所有SaaS数据以及其他第三方系统数据，那么它将无效。

客户数据平台是这方面的第一个解决方案，但它们并没有在数据所有者和决策者之间架起桥梁。

结论虽然今天的现代团队将使用世界一流的，高度专业化的SaaS产品来构建堆栈，但未来的现代团队将开始在整合的工作空间中寻找更高级的编排功能，具有更可预测且更少冗余的定价系统，并且可以共享和无所不在的客户数据层。

GPU云服务器云服务器抽象层硬件抽象层使用cdn加速后的客户访问直观体验是: 使用cdn加速后的客户访问主管体验式

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/10179.html

PaaS仍旧缺席别谈云计算格局已定

摘要：而不久之后将正式登场亮相的服务商们或将成为未来改写中国云计算市场格局的一个个因素。因此，在仍旧缺席的中国云计算市场说格局已定，还为时尚早。云计算业内对IaaS和SaaS的关注度素来高涨。相比之下，关于PaaS的讨论则颇为冷清。想围绕PaaS写个三部曲的想法由来已久，年初接连完成两篇（《PaaS是位好同志，但SaaS公司搞PaaS却不大靠谱》《夹缝求生，PaaS要靠什么来刷存在感？》），第三篇...

William_Sang 2019-04-30 11:27 评论0 收藏0
数据浪潮之间的前端工程师

摘要：数据浪潮之间的前端工程师十年来，波澜壮阔的移动互联网浪潮促进了技术的迅猛发展，随着浏览器性能网络带宽等基础设施的提升，也能够承载起包含复杂交互可视化计算逻辑需求的富客户端应用。 showImg(https://segmentfault.com/img/remote/1460000016874425); 本文是架构师 2018-10 月刊的卷首语，归纳于自笔者的技术之路系列文章，也是对 ...

mdluo 2019-08-23 12:38 评论0 收藏0
Kubernetes系统架构演进过程与背后驱动的原因

摘要：本文中，我们将描述系统的架构开发演进过程，以及背后的驱动原因。应用管理层提供基本的部署和路由，包括自愈能力弹性扩容服务发现负载均衡和流量路由。带你了解Kubernetes架构的设计意图、Kubernetes系统的架构开发演进过程，以及背后的驱动原因。 showImg(https://segmentfault.com/img/remote/1460000016446636?w=1280...

wuaiqiu 2019-07-01 16:49 评论0 收藏0
读懂 SOLID 的「接口隔离」原则

摘要：接口隔离原则是什么客户端代码不应当被迫依赖于它们不需要的方法。这是理解SOLID原则，关于接口隔离原则如何帮助我们创建简单的抽象接口，并使客户端代与接口之间存在的更少的依赖关系。接口隔离原则是什么 Clients should not be forced to depend on methods that they do not use.客户端代码不应当被迫依赖于它们不需要的方法。...

wing324 2019-08-26 11:40 评论0 收藏0