1.2　如何抽象整合活动平台

在梳理完不同的活动开发模式后，我们需要分析这些模式的相似性功能，并将这些功能抽象，促使不同规模的业务团队入驻同一平台开展活动，避免企业出现“烟囱式”的活动业务架构，导致各系统不能共享资源，形成资源孤岛和信息孤岛。

首先让我们分析一下H5活动的实际形态和最佳线上运营方式。

这些活动开发模式具备哪些共同的特性？在功能架构上，它们都具备各自的素材中心、物料中心，用于管理活动用到的媒体素材和奖品；在活动投放的链路上，也需要完善的数据监控、安全的风控系统、科学的实验系统等。分析后我们发现，最无法抽象的反而是活动的营销方案和活动组件。举例来说，同样是大转盘抽奖，有的是消耗积分获取抽奖机会，有的却是通过分享来获得抽奖机会。虽然方案和交互都类似，但是如果想用一个大转盘方案来适应所有业务需求，显然不切实际。

因此，我们期望通过一个活动平台，为所有业务团队提供统一的活动解决方案，承接企业内所有的活动需求。这听起来像是一种幻想，但通常成功的事情都是从一个不可能的假设中诞生的。

那么，我们能否构建一个“包罗万象”的活动大平台，适应所有公司活动需求，且所有配套能力都非常完善的综合活动平台？暂且不讨论该设想的可行性，假设我们已经完成了这个平台的建设，并投入使用，那么这个平台是否真的能满足所有活动需求呢？

在公司高速发展的阶段，业务数量呈指数级上升，业务需求将始终领先于平台的规划。当平台的能力不能满足业务开发需求时，就需要通过功能迭代来提供支持。

不同业务团队的活动需求有着不同的时限和紧急程度，多个活动需求并发是不可避免的，此时平台只能选择更具价值的需求进行优先支持。此外，这种支持模式在人力方面也有弊端，每当临近活动日时，平台将面临巨大的迭代压力，此时团队成员通常在执行高强度的工作，而业务团队的人力却不能得到充分利用。

很明显，这样的平台并不是最好的解决方案，它只是各业务团队妥协的结果，对业务发展并没有实际帮助，反而阻碍了业务增长。如果问题的严重性超过了业务的承受能力，团队就会毫不犹豫地抛弃平台，重新建立新的平台，以获得更大的自由来实现自身的业务目标。大型平台最终会成为关键业务方的服务工具，对其他业务方的帮助将十分有限。

既然自建小平台和统一建大平台都不是最好的办法，该怎么走出这种困境？

vivo的活动团队再一次大胆地设想，提出建立活动中台的方案。活动组件、模板不再由活动中台提供，而是将开发组件、素材、模板的能力赋予第三方业务团队，各团队可以在中台上实时开发定制，同时不同团队开发的交付件可以自由地在中台中流转，方便其他团队复用。这样的活动支持模式，不仅帮助我们解决了业务需求井喷的问题，还能将优秀的活动实践贡献给整个公司的活动体系复用。它也可以让新业务享受中台带来的红利，即新业务只需要关注活动效果，减少重复试验的成本，实现创新产品的孵化。

至此，我们很好地实现了“抽象整合”的目标，同时兼顾了不同业务团队对活动效果的追求。至于具体如何构建这样一个活动中台，且看本书后续讲解。