我在淘宝做弹窗，2022 年初的回顾与展望
作者：空堂
出品：大淘宝技术
本篇文章作者向各位介绍了自己加入 PopLayer 项目一年多时间以来，为产品所贡献的一份力量，既包含了站在产品视角对产品功能，易用性和未来发展的考量，也包括了站在技术视角，对技术架构，编程范式和功能实现上的思考。
前言
在我刚入职大淘宝技术用户增长团队时，弹窗作为用增站外触达的一种有效手段，需要一种系统的解决方案来提升弹窗的开发效率，扩展弹窗的使用场景，并通过结合唤端能力，扩大使用人群，为大盘贡献 AAC 增量。经内部反复讨论，我们初步确定了由「弹窗编辑器」产出「弹窗描述数据」，搭配 H5，小程序侧「数据渲染引擎」在终端即时渲染弹窗的技术架构，产品名暂定为「全域 POP 搭投平台」。
淘宝老牌弹窗搭投平台 PopLayer 团队成员在听闻该想法后，主动提出合作，希望将淘宝端内外弹窗搭投能力统一收口于 PopLayer 平台，为用户提供一站式端内外弹窗搭投体验。经过反复的沟通交流，我们最终评估通过了这一方案的可行性。我从此成为 PopLayer 团队的一员，并作为产品设计（后期）和开发者推动 PopLayer 平台从 3.0 版本到 4.0 版本的升级改造工作。
在下文中，我将详细地介绍我在此次平台升级的过程中，面临的问题，对应的思考以及最终的解决方案。
面临的问题
工作的价值在于解决问题，在加入 PopLayer 团队后，首先要做的事是了解情况，「明确当下的问题」。了解了项目背景的读者已经知道，我们已经有一个明确待完成的目标「使弹窗搭建能力复用至端内外场景」。但由于我们采用基于现有产品改造升级的策略，就不可避免的需要在此之前，先解决一些历史包袱，轻装上阵。与此同时，跨团队合作也使得团队成员能够从不同角度重新审视平台现状，从而对平台的升级注入更多期待和想法。
通过积极与团队成员沟通交流，我们最终归纳总结出如下 4 个本次升级迭代亟待的问题：
- 平台不易扩展的问题：PopLayer 平台作为淘宝老牌的弹窗搭投平台，在弹窗域积累了丰富的领域经验，但平台本身几经团队轮替，其代码也日益变得不易扩展和维护。但另一方面，我们能显著的观察到，近些年行业内弹窗的视觉和交互体验正在不断提升，业务方对弹窗的功能也提出了更多要求，因此，使 PopLayer 平台具备高扩展性以满足行业发展需要，是平台需首要解决的问题；
- 平台使用体验不佳的问题：平台使用体验差，会导致平台答疑成本提升，更有可能会使一些用户由于较高的使用成本对平台望而却步，这对于平台和用户都会造成损失：更少的用户意味着更少的需求输入，会导致平台自身发展遭遇瓶颈，而用户也会因为选择手动开发而浪费不必要的人力；
- 平台数据缺乏归纳整理的问题：PopLayer 平台作为线上稳定运行多年，支撑亿级业务量的淘宝核心产品，积年累月积攒了大量的弹窗域相关数据，如何将这些数据有效地利用起来，从而指导一次弹窗投放活动拿到更好的业务结果，也是平台顺应精细化运营时代趋势不得不考虑的问题；
- 平台现有架构未充分利用的问题：在进一步了解 PopLayer 产品技术架构时，我们发现 PopLayer 的技术架构与之前我们初步确定的「通过弹窗描述数据（一段 JSON 格式的 DSL 数据）解耦弹窗生产和渲染」的思路不谋而合。该架构的好处有以下三点：
- 通过将弹窗的生产与渲染分离，可以将弹窗的生产通过无代码或低代码的方式转交给创建弹窗活动的需求
方，从而在大幅降低弹窗开发成本的同时，保障弹窗迭代效率满足业务灵活性需要；
- 通过「弹窗描述数据」作为弹窗生产的标注输出，弹窗渲染的标准输入，使得弹窗在渲染侧可以不拘泥于特定的技术选型，从而适配各类需求场景，例如为端外开发 H5 渲染引擎，为端内开发 Native 渲染引擎，为小程序开发小程序渲染引擎等，从而在各场景用最适合的技术做一件事，实现业务收益的最大化；
- 当业务提出新的业务场景时，可以通过在 DSL 层快速迭代，渲染层快速实现的方式，高效地满足业务的敏捷需要；
然而，目前 PopLayer 平台虽然基于此种技术架构，却因为种种原因仅提供端侧 Weex 弹窗渲染能力，没有将该技术方案的价值最大化，有待进一步拓展。
带你读《2022技术人的百宝黑皮书》——我在淘宝做弹窗，2022 年初的回顾与展望（2）https://developer.aliyun.com/article/1340422?groupCode=taobaotech
