AI 爬虫访问与 AI 带来的访客
网页脚本只能看到会执行脚本的访问，不执行脚本的爬虫要另接服务端事件或日志才会出现。做完后，爬虫请求在机器人页，从 AI 产品点进来的人在来源页，都不混进人类概览。
前提
网站脚本已安装。要看完整抓取，还需要一把勾选了「写入服务端事件」或「导入日志」的密钥。不要把完整密钥写进仓库。
步骤
先看脚本能识别的机器人
打开 控制台网站统计机器人。页签在中文界面里也是
AI & agents和All bots。前者按运营商看抓取和带回的访问，后者列出全部已识别机器人。补上不执行脚本的抓取
用 服务端事件与日志导入 的服务端事件或日志导入把访问记录送进来，再回到机器人页。这条通道只保存识别为机器人的请求，不能用来记订单。
看来源里的人类访客
打开 控制台网站统计来源，页签选「AI 来源」。这里是人从 AI 产品点进来的会话，不是爬虫请求列表。
验证
有抓取进来后，机器人页不再是空的。有人从 AI 产品点进来后，「AI 来源」出现会话。两边数字不必相等：一边是程序读取，一边是人。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 机器人页一直是空的 | 抓取没有执行脚本，也没有服务端或日志 | 按服务端事件或日志导入补抓取 |
| 把来源当成爬虫量 | 「AI 来源」统计的是人类会话 | 爬虫次数以机器人页为准 |
| 人类概览被抬高 | 「机器人统计模式」被改成了「不识别」 | 改回默认的「识别并单独统计（默认）」 |
性能与 JS 错误对转化的影响
没有一张表会直接算出「慢了多少、转化掉了多少」。做完后，你手上有慢路径、能打开的出错会话、目标次数和旅程阶段上的错误会话率，由你判断它们是否落在同一步。
前提
当前版本的统计脚本已安装，并且真实访问已经发生。性能采集默认开着，除非脚本标签写了 data-vitals="false"。脚本错误要求安装片段带 data-errors="true"，默认片段已带上。还没有目标时，先在目标页建一条。
步骤
按页面看加载
打开 控制台监测性能，先看各指标「良好」的占比，再在「分组明细」里按「页面」分组，记下慢的路径。分组还可以选国家、设备、浏览器和操作系统。
从错误打开那次访问
打开 控制台监测错误，展开一组，点「打开会话」。会话详情里同时有这次访问的错误和加载指标，它只说明这一次访问里发生了什么。
对照目标和旅程
在 控制台网站统计目标 看转化次数有没有掉。打开 控制台全端分析经营分析旅程地图，看同一阶段的「错误会话率」和「流失」。目标不会按有没有错误再拆一列。
验证
性能按页面分组后能找到慢路径。错误组能打开会话，会话里看得到错误。旅程阶段上，错误会话率和流失是并排的两项，不是一个相除的结果。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 性能页是空的 | 旧脚本，或写了 data-vitals="false" | 换上当前片段，等真实访问 |
| 错误页没有脚本异常 | 「JavaScript 错误」开关被关掉，片段里因此没有 data-errors="true" | 在 SDK 代码页打开开关，并换上新片段 |
| 想要一条转化下降率 | 产品没有把加载指标连到目标 | 用路径、会话和旅程阶段对照 |
上报 App 版本与渠道并对比留存
版本和渠道要先写在事件上，留存表才有东西可筛。「新增留存」按日看时读的是站点汇总表，不吃版本和渠道筛选，所以按版本对比要换口径。
前提
应用已在 控制台应用统计配置SDK 代码 登记，实时里能看到启动。你能改客户端初始化参数。
步骤
写入版本
初始化时填写
appVersion。它会写成事件上的$app_version，版本分布读的就是这个字段。写入渠道
在
track的属性里带上$channel，例如安装包渠道名。registerSuperProps会丢掉以$开头的键，所以渠道不能只放在超级属性里。没有该字段的人归到「(无渠道)」。看次留，再换留存口径
打开 控制台应用统计用户分析渠道分析，用「次留」列比较渠道。要按版本或渠道看更长的留存，打开 控制台应用统计用户分析留存，把粒度改成周或月，或改成「活跃留存」，再用页头的版本或渠道筛选。
验证
版本分布出现你填的版本，渠道表出现渠道名和次留。换成周、月或「活跃留存」后，页头筛选会改变表里的人。还没有一天的次留到期时，渠道矩阵会是空的。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 渠道全是「(无渠道)」 | 只放进了超级属性，或键名不是 $channel | 在 track 属性里带 $channel |
| 新增留存按日不随筛选变化 | 这一档读的是按站点汇总的日表，不含版本和渠道 | 改用周、月或「活跃留存」；次留以渠道页为准 |
| 版本对不上安装包 | 初始化没有填 appVersion | 发版时写入与安装包一致的版本 |
接收 MMP 归因字段
TapCub 不判断点击和安装是否匹配，只接收归因平台算好的结果。做完后，每条回传都是一个 $app_install 事件，并在 控制台全端分析经营分析渠道 ROI 的「安装归因」页签按来源汇总。
前提
归因平台能向一个 HTTPS 地址发送 JSON。重置令牌需要所有者或管理员。不要把接收地址里的令牌贴到公开文档。
步骤
复制接收地址
打开 控制台应用统计配置经营设置 的「MMP 接入」页签，复制「接收地址」。路径是
POST /api/v1/mmp/加上本项目的令牌。点「重置 token」后，旧地址立即失效。让回传带上这些字段
建议包含
media_source、campaign、install_source_status、match_type、platform和install_time。install_source_status填organic或non-organic。不写event_name时，事件名是$app_install；改了事件名，就不会进安装归因。非自然量会同时把media_source写入utm_source，媒介为mmp。在安装归因里看
打开渠道 ROI 的「安装归因」页签。行按
utm_source和是否付费来源汇总。这里用的是回传写上的来源字段，不是渠道包的$channel。
验证
回传之后，安装归因不再提示所选范围内没有安装归因数据，并能看到媒体来源。事件分析里应有 $app_install。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 营销归因仍是空的 | 该页读取带 $ 前缀的 $media_source 等属性，接收端写入的是不带前缀的同名字段 | 以渠道 ROI 的安装归因为准，不要等营销归因自动填满 |
| 安装归因没有行 | 令牌不对，或回传改了 event_name | 核对地址，去掉自定义事件名 |
| 全部归到 organic | 回传没带 media_source，或状态是 organic | 带上 media_source 和 install_source_status |
| 和渠道分析对不上 | 渠道分析读的是 $channel | 安装包渠道和媒体来源是两套字段 |