2.1　“将平台交出去”的创新设计

通过上述的平台假设，我们发现将模板、组件、素材等开发能力交给业务团队，可以走出现有活动开发模式陷入的困境，达到快速拉齐企业整体活动开发能力的目的。接下来我们将详细说明如何设计具备这种能力的活动平台。

1. 聚焦底层

第1章介绍的3种活动开发模式，都需要经历需求策划、开发、运营上线等环节，这些环节都会用到最基础的平台能力，包括可视化搭建、模板与组件、素材管理、权限管理、统一登录、活动生命周期管理等。我们可以将这些底层能力统一、合并、收拢，让业务只关注活动本身的效果，让活动轻装上阵。当我们设计的活动平台可以实现上述功能时，它就可以轻松满足绝大多数的活动需求。

通过聚焦底层打造的活动平台同时也具备了通用配套的能力。例如，当我们需要找到一种有效提高活动页面转化率的方法时，A/B测试实验是必不可少的解决方案，我们可以通过该平台直接集成公司现有的实验能力，让上层业务活动直接享受实验的能力。类似的能力还包括活动数据反垃圾、线上活动加载性能跟踪、BI数据统计分析等，我们都可以基于平台去收集这些通用能力，再将其转化为统一的平台能力来为用户端赋能。这也是中台架构的关键特征。

2. 系统解耦

在之前的设想中，第三方业务可以自由入驻平台，并且平台支持第三方业务的定制化开发。业务方与平台直接相交的部分是活动组件与活动任务。活动组件主要负责呈现活动效果，并与用户进行完整的交互；活动任务是负责调整活动的配置信息和营销策略。活动组件和活动任务在后文中统称为活动制品，活动制品是中台产生大量定制化需求的真正来源。

传统活动平台的形式是将活动产品的代码直接集成到平台代码中，然后根据各种上游业务的需求来定制开发。这些活动制品的开发停留于完整的平台代码中，完成开发后升级整个平台，再将制品功能提供给用户去使用。从活动需求的生命周期来看，上线的活动强依赖于平台；从编码的角度来看，活动产品代码也与平台代码紧密耦合。当活动制品的需求发生变更，活动平台需要整体发版升级，需要投入大量的开发和测试人力。

系统解耦的概念是将活动产品代码与平台系统代码分开，但是制品使用场景将返回到平台本身，这意味着活动制品可以在线集成到平台中以供用户直接使用且互不影响。

第三方如何根据自身需求完成功能定制？难道开放平台代码给业务研发团队维护？或者线下开发需求，再将功能合入主线软件版本吗？这样肯定是行不通的。先不论庞大的底层的系统需要大量人力去了解掌握，仅仅是一个制品功能，不同的业务方都会有不同的想法和诉求。在极端情况下，接入的业务方越多，发版上线就越加频繁，业务方会互相影响。

平台需要具备功能级别的解耦能力，不仅可以实现功能解耦，还可以被业务方离线二次定制开发。活动开发完成后，可以热集成至平台且无须再次发布。该扩展开发行为对平台是无损的，业务方不仅可以复用平台搭建，而且大大缩短了定制化活动上线的周期，提高了二次复用的效率。这种架构相当于在一棵参天大树上生长出的一个分支，可以在主干的基础上向着自己的方向发展，同时还可以源源不断地从大树主干中汲取营养。后续章节将会详细地对这种架构实现进行阐述。

3. 共享创意

随着各业务产生的个性化制品日益增多，平台会积累大量优秀的活动制品。如果这些制品仅服务于创建的业务方，那这无疑是一种对优质活动制品的浪费。我们需要在平台上设计一个类似市场的系统，以便让每个业务的创造力在平台上流动，更好地为平台用户提供服务。当平台发展成熟后，开发人员在面对营销活动需求时，不再像过去一样第一时间进行个性化开发，而是会优先在海量创意产品中，选择符合活动定位的活动插件进行组装上线，快速响应互联网用户的需求。

为了让入驻的业务在平台里互不打扰，我们需要对业务进行虚拟隔离，在平台上设计了个人空间和共享空间。默认情况下，业务属于私有空间。私有空间具备所有通用功能，所有业务自有的个性化互动玩法、活动制品、素材、权限等与其他业务隔离，互不干扰；在共享空间中，与活动相关的模板、玩法、素材、制品都可以进行二次分享。用户可以在公共市场中，浏览其他业务方共享的优秀玩法和素材，并将其引用到本地进行二次开发或直接复用。

我们设计的平台不仅是活动创建发布平台，还是创意交流的平台，让创意碰撞，释放更多的想象力。总体而言，这三个能力是相对独立的，但同时也是可以互相促进增长的，它们共同实现了上层入驻业务、中层共享服务、底层夯实系统的功能。

到目前为止，我们已经对平台的功能进行了充分的研究和设计，明确了平台的功能要求。打造一款可共享也能定制的活动平台，迫在眉睫。