小程序留存，别只盯着签到

做了几年小程序，我越来越觉得「留存」这个词被讲烂了。打开各种运营课，翻来覆去就是签到、积分、push、优惠券。这些东西有用吗？有用，但它们是止疼药，不是治病。真正决定用户第二天还愿不愿意点开你小程序的，往往在开发阶段就埋下伏笔了。

先搞清楚：你的留存是「被动」还是「主动」

我接过一个本地生活类的小程序，日活看着还行，但细看数据，80% 的访问来自微信会话卡片的二次点击——用户是被朋友分享的链接拽回来的，不是自己想起来的。这种留存是假的，一旦分享停止，数据立刻塌。

怎么区分？看两个指标：

• 主动打开占比：从「最近使用的小程序」列表、搜索、桌面图标进入的比例。低于 30% 就要警惕。
• 无触达回访率：关掉所有模板消息和订阅消息推送后，自然回访的用户有多少。

被动留存靠运营活动堆，主动留存靠产品本身。前者烧钱，后者省钱。我一般建议客户先别急着做签到，先把主动打开占比拉起来。

第一刀：砍掉首屏的「加载等待」

微信小程序的启动体验比 App 更脆弱。用户从聊天界面点进来，心理预期是「秒开」，超过 1.5 秒没看到内容，手指就往左上角滑了。

几个我反复验证有效的做法：

• 骨架屏 + 本地缓存首屏数据。列表页先用 wx.getStorageSync 读上次的数据渲染出来，再静默请求更新。用户感知是「立刻有内容」。
• 分包加载。主包只放首页和核心流程，非核心页面拆到分包，app.json 里配置 subpackages，首屏包体积能压到 1MB 以内。
• 图片别用原图。列表缩略图走 CDN 的 ?imageView2 裁剪参数，别把 2MB 的图直接塞进 image 标签。

// app.json 分包示例
{
  "pages": ["pages/index/index"],
  "subpackages": [
    {
      "root": "packageA",
      "pages": ["pages/detail/detail", "pages/order/order"]
    }
  ],
  "preloadRule": {
    "pages/index/index": {
      "network": "all",
      "packages": ["packageA"]
    }
  }
}

这三件事做完，很多小程序的次日留存能涨 5 到 10 个百分点。不是我夸张，是启动体验对小程序太关键了。

第二刀：让用户「有事可做」

留存差的另一个重灾区是：用户进来逛了一圈，发现没什么可干的，就走了。下次再想起来，也不知道进来干嘛。

我的经验是给小程序设计一个「轻任务闭环」。注意，不是签到那种机械任务，而是跟业务真正相关的动作。比如：

• 工具类：上次没算完的账单、没保存的模板，下次进来直接续上。
• 内容类：收藏、阅读进度、未读完的列表，做成「继续看」入口。
• 电商类：浏览过的商品、加购未付款的提醒，放在首屏显眼位置。

核心逻辑是把用户的上一次行为状态存下来，下次进来一眼看到「你还有事没做完」。这个心理钩子比任何积分都管用。实现上不复杂，wx.setStorage 存个轻量状态对象就行，注意别存大对象，微信本地存储有 10MB 上限。

第三刀：订阅消息要「克制地精准」

很多人一上来就狂发订阅消息，结果用户直接关通知，甚至拉黑小程序。我见过最离谱的，一天发三条促销，第二天留存直接腰斩。

我的原则是：一条消息必须对应一个用户已经表达过的意图。用户下单了，发发货通知；用户收藏了，降价提醒；用户设置了提醒，到点通知。没有意图支撑的推送，一律不发。

技术上注意两点：

• 订阅消息是「一次授权一次发送」，别指望长期授权，模板要选跟业务强相关的。
• 发送时机做延迟合并，同一用户 24 小时内最多一条，避免打扰。

最后说个反常识的

有时候留存低，不是产品问题，是用户根本不需要高频使用你。比如查社保、交罚款这类小程序，一年用一次很正常。这种场景硬做留存是自欺欺人，不如把单次体验做到极致，让用户下次有需求时第一个想到你。留存率这个指标，得先看业务属性，别被行业平均值绑架。

说到底，小程序留存是个系统工程：启动快、有事做、推送准，三件事做到位，数据自然会说话。别迷信签到，那玩意儿救不了产品。