果肉场景下落地页演进过程

此处的过程更多的是在前端的思考

此处描述我们做落地页的演进过程。

一般我们业务场景，低价课的导流模式一般通过公域流量 或者我们社区运营的私域流量。

主要的页面形式主要也就分为购课用的页面 俗称落地页，简单导流的静态H5页。

落地页的业务形态应该在数字化营销场景下是十分常见的。

而且在正常使用上，不同的使用方看待落地页的模式可能也有所不一。

以下是假想多场景下不同方对落地页的看法

产品：关注点在落地页的可用性以及流程完整性上，如何设计出精简符合端上传播的模式的落地页等等等等...

运营：关注每个操作节点的转化比，关注素材的投放转化率，对此也就衍生出更多可插拔素材的场景等等等等...

开发：让整个研发节奏更快捷，更能符合各位使用大佬的功能要求，让整个落地页实际使用时，技术不成为卡点，完善整体的页面，包括代码可用性 可维护，很直观的当然还包括页面的打开速度等等等等...

外部运营同学：希望能接入更多的业务方，在更多的平台上做联动。（私域自有 APP 投放，更多端的平台 APP， OPPO的应用市场开屏等等等等...

原有落地页：

我们原先的落地页场景是在单场景下投放（巨量引擎投放），素材以及文案统统 hardcode 在代码中。

我们与传统的落地页可能有一些不一样的地方是，我们不是真正意义上以“活动”来划分代码的。

常见的落地页模型可能是：

A活动周期一个月，新做一个页面，设置好开启结束时间，让这个A活动的代码跑上线到了下线活动停止维护。

B活动周期两个月，完全新的页面与代码，设置好开启结束时间，让这个B活动的代码跑上线到了下线活动停止维护。

这种模式下，可复用的内容有 1. 搭建脚手架 2. 相似的物料 3. 通用的函数库 sdk

这种模型下复用的元素很容易定义，也更符合直观。

但我们过往的落地页模式是

一套落地页兼容 N 个活动，我是后来接手这一套落地页的（原先的同学觉得实在太难以维护就提离职了）

原先暂定的兼容逻辑是 hardcode，例如 version A/B/C 我们就在不同的场景下对某些组件做一些文案上的修改，以及通过一个 json config 做到一些素材的可配置。

我们计划用了一个月的时间将我们落地页某种程度上可配置（2人力/月）。

我主要是前端这一块，主要是两个地方，一个是 C 端的渲染，一个是 B 端的表单配置化 JSON。

首先是原有的业务是在跑的，我们只能通过一些扩展来根据以前的模式来做这块的逻辑。

1. 根据业务侧参数获取配置值（我们用的是activity + version + sell_type）
   1. 这部分设计是复用原有字段，实际上后面activity是无用的，我们是用sell_type+version 决定一份配置json。
   2. 这部分是存在一部分原有的限制导致我们不能大刀阔斧的砍
   3. 以及一部分的产品与技术的over design 过度设计。
2. 后台表单设计用了个简单策略
   1. 根据 json key 自然拆分子表单， 一个 key-value 即为一个子表单
   2. 总揽表单也是根据 key-value 做拆分
      1. 分成 set to form + get to server
      2. 每个字段自己定义插入表单前以及提交服务器前的数据转化。
      3. 组件自身只要关注自己的value + onchange即可，数据不一致的转换统一处理。
   3. 数据处理逻辑抽象（ image data 转换，optiondata 转化等等）
   4. 统一处理通用逻辑（编辑态每种 multi radios 切换时候都需要保留原有状态）
3. C 端的渲染
   1. 首先是将组件抽离，至少是基于原有的做分割，把组件逻辑内聚一下。
   2. 应用我们的整个配置
      1. 对 data 里面的某个 key， get Value 出来自行消费。
      2. key 对应一个组件 消费一份 data.

必须吐槽一下，原有系统内的组件设计简直都是 anti design，以"过度的复用"，间接导致基本是不可用的，而且整个系统的逻辑调用完全是反人类的。。。

这种模式下我们能支持最基本的运营与产品侧需求

1. 文案 素材可自行配置。
2. 可根据活动版本归类各种落地页。

在果肉做增长有一些很烦的事情，所有的需求都是累加式的，所有的迭代你都不知道下一次能复用啥。真的没时间阿阿阿阿

后者在 C 端的场景下其实也是合理的，但是对研发角度简直不可理喻

但是我要来说说这个累加式。

这整一套落地页的表单化配置系统的模式，一直就没有迭代过了。。。是一直就没有迭代过了。。。（后面我会说这套模型的问题是啥）（产品以及老大还“骗”我会继续迭代。。。）

2020年是在线教育投放广告的井喷年。各家广告引擎的广告投放，教育行业的投放量都有明显的增加，这间接导致了投放广告竞价的内卷，基本家家都是客单价爆炸，ROI 根本达不到盈利点，就在烧钱。

2020年前期我们接入了更多家的投放引擎（巨量/腾讯/花生），也就意味着我们的页面也需要更多的在不同的投放端的个性化展示，例如A页面需要在巨量有个倒计时，B页面不需要在巨量有个倒计时。

因为我们是同一套落地页，也就是同一套落地页的渲染，但我们并没有增加类似端的特殊配置，我们还是在原有的基础上，要么加个子表单，要么加个 radio 来控制该版本的落地页某些部件是否显示。如果同一个版本增加了端的检测，从而增加配置，那原则上各个选项在各个端都可以另外配置。那就完蛋了。

这个数量级分分钟是 m * n 的可配置项在一个版本中。对运营简直是灾难。

由于投放竞价的内卷（我们没那么有钱呀），我们将目光转移到了私域上，以及定点的落地页模式（短信打开/直播用户打开/ APP 开屏打开/ OPPO 应用商城曝光）。

ps： 这里好难说清楚。

总的就是我们需要增加更多平台的适配，包括操作逻辑的适配（操作逻辑是很麻烦的适配方式）。

可以看到 上面整一套的配置化，其实只是渲染时候展示的可配置化，可一丁点都没有涉及逻辑啊。达咩达咩。

那我们也没时间做啊。就拢共就我一个人。

那咋办呢。hardcode 有的时候是很好的，人为约定也不是不行。

首先是新功能时候触发点收敛，就一个配置用来决定整一条操作逻辑路径（正常的是逻辑路径也可组合），但是我们这里达咩达咩不行不行，运营不行 我也不行。

这样子的话，最低成本的解决了这种问题。用一个配置决定一条逻辑路径，正常的UI渲染还是在那，但是逻辑的路径就是一个字段包含了这个含义（是否展示这个部件/是否触发这个部件）。

这种看起来还挺好的。。。

一晃就是半年。

再过来就是我们彻底不怎么玩投放竞价了。我们成立了自己的直播部门，招主播 KOL 来带货低价课。

这种的成本价比公域流量来的便宜的多。所以落地页就不怎么耍了。

但是在 Q2-Q3 我们还是有投放的需求。

并且我们需要用小程序，用于更快的获取到用户的手机号以及信息资料。

也就是整一套模型就得搬到小程序上了（其实我是真的讨厌小程序）。

搬上去的过程中，顺便做了个批量化的表单配置（支持多个版本的配置），用了 antd4 重新做了一边，因为 antd3 全量触发表单项刷新在后面的时候，input输入已经有点卡顿了。

稍微总结一下：

1. 页面的渲染通过配置出的json 对应的k-v字段来表示渲染
2. 组件的展示仅仅是一个radio or 一个表单
3. 落地页不同逻辑的不同由一个k-v表示 或者 是一个radio来表示
   1. 相当于是一个总的开关，掌控着整个大楼的电灯。。。
4. 支持批量亦或者单独配置落地页
5. 由 sell_type + version 确定一个 json config。

其实省略掉了很多业务上的需求实际落地的效果，但是总的模式大概就是这么一个模式...

Comments