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

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

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

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

主要的页面形式主要也就分为购课用的页面 俗称落地页,简单导流的静态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。

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

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注