JUNE PRIORITY MAP

六项任务,一套增长系统。

六项任务围绕一套增长系统展开。任务回答“做什么”,能力回答“怎么做”,每个模块都从终态倒推到地基,看清前提、依赖和验证方式。

增长
系统
01数据工程
02广告投放
03SaaS升级
04产品管理
05羊毛小程序
06小程序优化
1看得见

数据工程

实时看数、异常监控、实验观测台。

2进得来

广告投放

归因、ROI、素材和时段放大。

3跑得动

SaaS升级

新旧迁移、体验升级、架构重构。

4管得住

产品管理

资产总表、发版流程、状态管控。

5留得住

羊毛小程序

内容供给、日活回流、公域引流。

6转得好

小程序优化

All-in-One、灰度实验、转化提升。

六项任务各自的角色

每张卡都可以点击进入对应模块,适合汇报时从全局快速切到细节。

1

数据工程

看得见

让所有动作的效果实时可见。

2

广告投放

进得来

把流量规模化地、可控地买进来。

3

SaaS升级

跑得动

底层系统撑住业务跑,不崩不卡。

4

产品管理

管得住

几十个小程序和 H5 资产不失控。

5

羊毛小程序

留得住

用户主动回来,不靠推送维持。

6

现有小程序优化

转得好

领券下单的效率最大化。

依赖结构

数据工程是验收工具和实验观测台,中间三项提供流量、基建和资产管控,产品层负责留存与转化。

地基层
① 数据工程其他五项的验收工具和实验观测台。
中间层
② 广告投放流量引擎。
③ SaaS升级基建底座。
④ 产品管理资产管控。
产品层
⑤ 羊毛小程序日活引擎 + 公域引流入口。
⑥ 现有小程序优化转化主阵地。

五项能力 × 六项任务

能力不是孤立建设,而是在任务推进里被反复使用、验证和沉淀。

能力 数据工程 广告投放 SaaS升级 产品管理 羊毛小程序 小程序优化
测试
数据驱动
设计迭代
AI协同
工程能力

原始总图

保留这张图,方便在汇报中回到老板最初看到的整体框架。

六月重点任务与关键能力总图
01 · Data Engineering

数据工程

从T+1变实时,让数据成为管理工具——当天发现异常、反推运营动作、验证实验效果。

结果倒推链路
终态:当天发现异常 + 反推运营动作 + 验证实验 + 全景交叉分析
前提4:小程序矩阵数据接入小程序日活、H5卡片访问量等接入同一套系统,和项目渠道数据产生关联
前提3:实验观测机制上策略前打标记,系统自动对比有策略 vs 无策略的数据差异
前提2:异常阈值 + 运营动作日志区分"正常波动"和"真异常";运营动作有记录可追溯
前提1:自有联盟数据实时回流迁移回自有联盟账号(已在进行),数据从T+1变为实时
地基:统一指标口径每个项目渠道到底看哪几列数,先定清楚

现状与痛点

  • 过去依赖第三方平台取链,受限于接口能力,只能T+1看数据。
  • bug跑满一整天才被发现——配置出错、小程序跳转异常、基建问题,都要等到第二天看数据才察觉。
  • 产品运营上了增长策略后,事后导数据分析来分析去得不出结论。
  • 小程序矩阵数据和渠道项目数据没有打通,无法交叉分析。

终态

一套实时数据系统,同时承担四个角色:

  • 哨兵——渠道数据异常当天发现,触发运营自查,避免bug持续一整天。
  • 黑匣子——数据涨跌自动反推运营动作,效果自动留痕,不用追着人问。
  • 实验台——增长策略上线后直接在系统里看实验组和对照的差异。
  • 全景仪——项目渠道数据和小程序矩阵数据打通,交叉分析判断问题根源。

关键认知:迁移自有联盟不只是"换个取数来源",本质上是把数据时效性从T+1拉到实时,直接解锁了四个角色——以前想做也做不了。数据工程不是六分之一的任务,而是其他五项的基础设施。

能力体现

  • 数据驱动
  • 工程能力
  • AI协同
  • 测试
02 · Acquisition

广告投放

把买量从碰运气变成可计算的生意。规模化的前提不是钱多,是敢花钱——敢花钱的前提是知道每一块钱多久能回来。

结果倒推链路
终态:按ROI阈值放心加预算,规模化上量
能算账:每个渠道/素材/时段的ROI清晰可比
短线 + 长线分别跑通短线:口令投放当天算清消耗vs佣金,下一步素材/时段A/B对比机制化
长线:加粉投放的7天归因跑通,依赖数据工程打通
地基:投放动作标准化每次投放必须带渠道标记、素材标记,否则事后归因无从做起

现状与痛点

  • 两种投放形态并存:加粉投放(长线,看LTV能否覆盖获客成本)和口令/链接投放(短线,当天能算ROI)。
  • 短线数据基础已有(能按时段拆漏斗),但没有机制化地做A/B对比和放大。
  • 长线缺7天归因,算不清加粉投放的LTV,导致不敢放量。

终态

一台可预测的买量机器:短线知道什么时段、什么素材/口令类型效果最好,按ROI阈值调预算;长线能算清单粉成本的上限;两种互补——口令赚现金流养活团队,加粉积累用户资产做长期价值。

关键认知:PM看投放不看投手技巧,看可度量性和可复制性——素材能不能模板化、时段策略能不能规则化、归因能不能自动化。两种投放不是二选一:口令养现金流,加粉积累资产。

能力体现

  • 数据驱动
  • 测试
  • 设计迭代
  • AI协同
03 · Platform

SaaS升级

把对外服务的平台从"能用但难用"变成"好用且可持续迭代",同时安全完成新旧切换不丢客户。

结果倒推链路
终态:新系统全量承接,旧系统下线,客户无感迁移
全量切换:最后一批客户迁完,旧系统只读→关停
灰度迁移:分批切客户,新旧并行跑,逐批验证数据一致性
功能对齐:新系统覆盖旧系统所有在用功能砍掉没人用的功能,避免搬屎山
迁移方案:定义"迁什么"客户数据、配置、历史订单/佣金记录、模板等
地基:盘清旧系统哪些功能客户真正在用

现状与痛点

  • SaaS是对外商业产品——给其他CPS从业者提供联盟能力(美团联盟等)、H5推广模板、小程序入驻等服务。
  • 旧系统用电商模板代码框架堆砌,功能堆砌、交互体验极差、技术债严重。
  • 现在正在重新编写一套新代码进行重构。

终态

  • 新系统上线,旧系统平滑退役,客户无感迁移(数据不丢、功能不断、体验升级)。
  • 新架构支撑后续产品迭代——加新功能不再像以前一样在屎山上堆。
  • 用户交互体验显著提升。

核心风险:风险不在"新系统写得好不好",在迁移过渡期——新旧并行时客户出问题、数据对不上、功能缺失,任何一个都可能丢客户。"迁移"本身要当一个产品项目来管,有自己的里程碑、验收标准和回滚方案。

能力体现

  • 工程能力
  • 测试
  • 数据驱动
  • 设计迭代
04 · Product Ops

产品管理

资产可管控、发版规范化——打开一张表看全所有端,每次变更走同一条流程,不再野蛮发版。

结果倒推链路
终态:一张资产总表 + 一套发版流程所有端的状态、主体、负责人一眼看全;不管小程序还是H5,走同一条发版流程
常态运转:每次发版自动走流程,资产表自动更新状态
流程统一:小程序和H5的发版流程合并为一套
废弃清理:盘点后明确标记哪些端废弃、排期下线
地基:全量盘点把近50个端的真实使用状态搞清楚——哪些有流量、哪些是空壳、哪些功能重复

现状与痛点

  • 近50个端:小程序"双享版"约20个 + "旧系统"约20个 + H5资产8个。
  • 分属不同主体、不同系统、不同状态,信息散落——哪个在用、哪个该废弃、谁负责、最近更新了什么,没有统一视图。
  • 发版流程已有雏形(小程序11步、H5 8步),但分两套表管理,规范程度不一。

终态

  • 一张资产总表——所有小程序+H5,每个端的状态、归属主体、负责人、最近发版时间,一眼看全。
  • 一套发版流程——不管小程序还是H5,走同一条流程。每次变更有记录、有验收、可追溯。

关键认知:价值不是"管理更规范"这种抽象好处,而是降低其他任务的执行风险——数据工程接数据得知道接哪个、优化改东西得知道改哪个版本、羊毛上线得走什么流程、SaaS升级涉及H5模板得知道哪些可以砍。

能力体现

  • 工程能力
  • 测试
  • 数据驱动
  • 设计迭代
05 · Retention

羊毛小程序

用羊毛内容养活小程序日活,日活反哺外卖CPS转化,同时羊毛内容在公域有传播力能引流进私域。一石三鸟:日活、收入、获客。

结果倒推链路
终态:每天稳定上架N条高质量羊毛活动,用户形成每天打开的习惯
筛选机制:从候选池里筛出"真正能薅到"的过期的、门槛太高的、套路的要过滤掉
候选池:每天有足够量的原始活动信息汇入
数据源建设(当前卡点)已有源:扩大覆盖、提高抓取频率
新增源:对标同行在用的数据源,补缺
地基:摸清同行供给量同行每天上多少活动、从哪来,倒推自己需要多少数据源

现状与痛点

  • 项目已在做,但面临数据源短缺、时效性慢的问题。
  • 核心命题:每天要上多少有吸引力的活动,倒推就是要找到多少数据源来进行筛选。
  • 同行都在做,模式已验证,竞争在于供给效率——谁的活动更新更快、筛选更准、薅到的概率更高。

终态

  • 每天稳定上架足量高质量羊毛活动,用户形成每天打开的习惯。
  • 用户因羊毛进来,顺带看到外卖券自然转化——羊毛是流量入口,外卖CPS是变现引擎。
  • 优质羊毛内容成为公域引流素材(小红书/社群等)。

关键认知:成败不取决于小程序好不好看,取决于供给能不能撑住日更。如果数据源不够,上线后内容干枯,用户来一次就不来了。羊毛是"高频低利",外卖CPS是"中频有利",两者嵌套形成闭环。

能力体现

  • 数据驱动
  • AI协同
  • 设计迭代
  • 工程能力
06 · Conversion

现有小程序优化

从"一堆体验差的小程序各自为战"收拢成"一款体验好的主力小程序",并建立灰度实验机制让每次改版有数据结论,不靠猜。

结果倒推链路
终态:一款主力小程序 + 实验机制常态化运转
常态运转:每次迭代走"假设→多版本→灰度→数据回收→结论"闭环
实验机制跑通具备同时灰度多个版本、按用户分组放量、回收对比数据的能力
All-in-One MVP上线把矩阵里高频功能合并进一款小程序,体验重新设计,小流量验证
功能收拢决策:定义"哪些功能进主力、哪些废弃"
地基:盘清每个小程序的真实日活和功能使用率和产品管理的资产盘点联动

现状与痛点

  • 小程序矩阵用户体验都不好,各自为战。
  • 改版靠猜,没有数据验证机制——改了不知道有没有效,无法形成迭代闭环。

终态

  • All-in-One主力小程序——承接矩阵里分散的核心功能,交互体验统一且优质。矩阵继续存在分散风控风险——矩阵是防御,主力是进攻。
  • 灰度实验闭环——一次上N个版本,走"假设→多版本→灰度→数据回收→最优全量"闭环。

关键认知:灰度实验机制的价值远超这一个项目——羊毛小程序的功能迭代、投放落地页优化、推送文案对比都能复用。与羊毛的分工:小程序优化管"转化",羊毛管"留存和回流",两者嵌套在同一款All-in-One里但职责不同。

能力体现

  • 测试
  • 数据驱动
  • 设计迭代
  • 工程能力
首页