应用内引导 · 用户上手

引导用户上手。 并知道它是否奏效。

引导流程、检查清单和公告 —— 在产品内构建，由你早已接入的分析 SDK 渲染。不需要第二家供应商，不需要第二个埋点标签。而且因为每一步都会落到主线上，一条引导会与它带动的激活和收入直接关联 —— 而不是困在一个看不到你的收入的引导工具里。

开始引导用户上手 查看分析 SDK

约 3.8 KB 懒加载代码块 · Shadow DOM · 遵循 DNT/GPC

一套引擎，三种模式

引导流程、检查清单、公告

同一个轻量渲染器支撑这三种模式。挑一个适合当下场景的模式，点开逐个看看。

引导流程

锚定元素的多步骤走查

  • 逐步用聚光灯效果突出某个元素
  • 每一步锚定到一个选择器，并设置显示位置
  • 操作按钮可以带用户前进，也可以直接跳转

检查清单

一份会自己完成的任务清单

  • 每一步都会根据真实的产品事件自动打勾
  • 不需要用户自行申报进度 —— 产品本身就是事实来源
  • 非常适合做成激活场景的「新手上路」清单

示例数据

公告

只出现一次的弹窗或横幅

  • 发布更新日志、提醒或轻推提示
  • 弹窗或横幅两种位置可选，用户可关闭
  • 频率：只显示一次，或每次都显示

为什么选我们，而不是单点工具

一条能说清自己带来了多少价值的引导。

独立的引导上手工具只能告诉你一份检查清单被完成了。它们说不出完成清单的那些账户，激活得更快、付费也更多 —— 它们的数据从来碰不到你的收入。而在这里，一切都是同一条记录。

  • 互动数据落在主线上

    每一次查看、每一步、每一次完成，都是一条 guide.* 事件，走的是和你产品其他部分完全同一条 analytics_event 数据流 —— 写入时就已关联到客户账户。

  • 是激活，不只是点击

    因为检查清单的每一步都是根据真实产品事件完成的，「完成清单」就意味着用户确实做了那个能带来激活的动作 —— 所以从引导到激活的转化路径是真实的,不是虚荣指标。

  • 流程背后的 MRR

    每条引导的表现数据带着参与账户的收入 —— 于是「这个引导上手流程值不值得保留」这个问题,能直接对着数字回答,而不是打开另一个独立工具。

交付方式

跑在你的分析 SDK 上，不需要另装任何东西。

如果你已经在跑 product-analytics SDK，开启引导功能只差一个开关。渲染器是一个独立的代码块，只有在需要展示引导时才会加载 —— 从没见过引导的访客，也从不会为这些字节付出流量成本。

  • ✓一个约 3.8 KB（gzip 压缩后）的代码块，只有设置 init({ guides: true }) 后才会懒加载 —— 分析核心部分依旧保持轻量。
  • ✓在Shadow DOM 覆盖层中渲染 —— 隔绝恶意 CSS 干扰，你页面的样式重置不会破坏引导，引导的样式也不会渗漏到你的页面上。
  • ✓没有框架依赖，没有第三方依赖 —— 纯原生 DOM。和每一个 ProductOS SDK 一样遵循 Do Not Track 和 Global Privacy Control，并支持同样的一次调用退出。

开启引导功能 · 一个开关

ProductOSPA.init({
  productKey: "pk_live_…",
  guides: true
});

和你的产品分析用的是同一个 SDK。生效中的引导会在启动时被拉取、与当前页面匹配，然后渲染出来。实测约 3.8 KB。

创建方式

在产品里搭建，一键上线。

发布一条引导不需要写代码。在构建器里编排内容、设置定向，然后发布 —— SDK 会在下一次加载时拉取到它。

  • 编排步骤

    每一步都可以设置标题、正文、媒体和一个操作按钮 —— 顺序可调，支持在编辑器内直接内联编辑。

  • 设置定向

    URL 规则（精确匹配、前缀匹配、包含或任意页面）以及展示频率（一次或每次）。还可以设置强调色和弹窗/横幅位置。

  • 草稿 → 上线

    先保存为草稿，预览确认，再把状态切换为上线。SDK 只读取已上线的引导 —— 草稿始终留在构建器里，不会外泄。

  • 查看效果

    展开任意一条引导即可查看它的表现 —— 浏览量、完成率，以及参与账户带来的收入。

真实的构建器界面 —— Brightline 演示工作区里三条正在运行的引导 · 示例数据

真实的构建器界面 —— Brightline 演示工作区里三条正在运行的引导 · 来自 Brightline 演示工作区的示例数据

边界在哪里 —— 说清楚

  • —目前仅支持网页端。 引导通过网页版 product-analytics SDK 渲染。原生移动端引导还在路线图上，尚未上线。
  • —目前只有三种引导类型，不是一整套工具集。 引导流程、检查清单和公告今天就能用。NPS 和 CSAT 调查是在 Insights 里单独提供的；内置资源中心还在路线图上。
  • —定向方式是 URL + 频率。 目前支持页面匹配以及「一次 / 每次」两种频率；完成状态由事件驱动。针对「谁能看到什么」的完整行为分群功能是下一步计划。

从这里开始

让用户顺利上手，不必再多接入一个供应商。

打开一个开关，今天就能上线一条引导流程、一份检查清单或一条公告 —— 然后看着它带动激活，数字就摆在它带来的收入旁边。

立即开始 查看价格

常见问题

问题解答

AIOProductOS 里的应用内引导是什么？
三种形态，一套引擎：引导流程（锚定元素、带聚光灯效果的多步骤走查）、检查清单（根据真实产品行为自动打勾的任务清单），以及公告（只显示一次的弹窗或横幅）。你在产品内构建它们，Product Analytics SDK 会在你自己的网站上渲染 —— 不需要单独的引导上手供应商。

这是 Pendo、Appcues 或 Chameleon 的替代品吗？
在引导流程、检查清单和公告这几方面，是的 —— 而且它和你的分析用的是同一个 SDK，所以不需要第二个埋点标签，也不需要单独付一份供应商账单。真正的区别在于主线：引导互动数据会在同一条客户记录上关联到激活和收入，所以「这个引导上手流程有没有真正带动激活和留存的 MRR」这个问题，是一次查询就能回答的,不需要单独做一次调研。NPS 和 CSAT 调查也在提供 —— 在 Insights 里，并按每条回复背后的收入加权。唯一还在路线图上的一块是内置资源中心。

这套方案有多重，会拖慢我的网站吗？
引导渲染器是一个约 3.8 KB（gzip 压缩后）的独立代码块，只有在你设置 init({ guides: true }) 之后才会懒加载 —— 完全不会影响那些看不到引导的访客。它运行在 Shadow DOM 覆盖层中，所以你的 CSS 破坏不了它,它的样式也渗漏不到你的页面上。

检查清单怎么知道某一步已经完成？
检查清单的每一步都根据一个真实的产品事件来完成 —— 一个你已经在追踪的功能标识或事件名称。用户在你的产品里做了那件事,这一项就会自动打勾;不需要让他们自己申报进度。

谁来创建这些引导，在哪里创建？
团队里的任何一个人，都可以在产品内置的构建器里创建 —— 选一个类型，添加步骤（标题、正文、媒体、一个操作按钮），设置 URL 和频率定向，先存为草稿，再切换到上线状态。SDK 只会读取已上线的引导；草稿永远不会离开构建器。