统计注册按钮与表单提交
做完后，按钮点击是你命名的 signup_click，表单提交是自动事件 __form，两者各有一条事件目标计数。
前提
网站已经装上统计脚本，实时里能看到你自己的访问。改自动事件开关需要所有者或管理员；建目标需要分析师及以上。
步骤
打开表单采集
打开 控制台网站统计配置SDK 代码，在「自动事件采集」里打开「表单提交」，开关即时保存。再在页面的脚本标签上手动加
data-forms="true"，安装片段不会自动带上它。两处缺一处，提交都不会计入。给按钮一个事件名
在注册按钮的点击处理里调用
webcount.track('signup_click', { id: 'hero-signup' })。事件名要和后面的目标一致。脚本还没加载完时，先推进window.__wcq。按事件建目标
打开 控制台网站统计目标，点「新建目标」。类型选「事件」，事件名填
signup_click。事件目标按事件名精确匹配，没有匹配方式可选。表单另建一条，事件名填__form。「属性过滤（可选）」可写id=hero-signup，只有属性相符才算转化。
验证
打开 控制台网站统计实时，类型选「自定义事件」，点一次按钮，应出现 signup_click。提交表单后，类型选「表单提交」，应出现 __form。再到 控制台网站统计事件 和目标页，次数应增加。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 没有表单事件 | 开关没开，或脚本标签上没有 data-forms="true" | 两处都补上 |
| 目标一直是零 | 类型选成了「页面」，或事件名不一致 | 改成「事件」，名字与 track 的第一个参数相同 |
| 实时没有点击 | 调用发生在脚本赋值之前，且没有进队列 | 把调用放进 window.__wcq，或等 webcount 存在后再调 |
下一步
还没想好名字的点击，可以先开全埋点，再到收件箱里认领，见 自动采集与事后定义。
用 insert_id 避免前后端重复统计
浏览器、小程序和 App 的 track 都不带 insert_id，它只对服务端的重试去重，不会让前后端两条自动对消。所以订单、注册、退款这类事实只从服务端上报一次。
前提
你有一把勾选了「服务端 Track」的密钥。前端可以报点击，支付结果和金额只从服务器发。
步骤
只在服务端上报这笔事实
向
POST /api/v1/track发送 JSON，Authorization用Bearer wck_…。事件名用你们真实的业务名，例如purchase。每次重试沿用同一个键
insert_id最长 36 个字符，用订单号这类稳定值，不要用每次变化的随机数。同一批里的重复键会被丢掉。已经入库的同键，若新事件时间落在已存时间前后一天内，也不会再插入一行。前端不要再报同一笔
若浏览器也发了同名购买事件，会多出一行。金额只保留服务端这一条。
验证
用同一个 insert_id 提交两次，事件只记一次。两次响应的接受数都会计入，因为去重发生在入库时，以报表为准。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 重试变成两行 | 两次的键不同，或第二次的事件时间超出前后一天 | 重试沿用原键和原事件时间 |
| 前端和后端各一笔 | 前端 track 不发送这个键 | 金额只从服务端上报 |
更新返回 missing_insert_id | track_update 或 track_overwrite 没有带键 | 更新和覆盖必须带上原来的键 |
认领收件箱事件并加入埋点方案
做完后，你确认过的名字是状态为「生效」的事件定义，埋点方案里有对应条目。从候选接受时，还会在后台回溯最近 90 天的全埋点记录。
前提
你是分析师及以上。全埋点候选还要求套餐包含收件箱，并且站点已开启全埋点。代码里已经 track、但还没登记的名字，不依赖这条开关。
步骤
看页顶提示
打开 控制台全端分析数据管理事件收件箱。若提示本站尚未开启全埋点，「待处理」里不会出现新的点击候选。卡片「未规划事件」仍会统计代码里出现过、却没有定义的名字。
接受一条候选
在「待处理」里打开一条，点「接受」。事件名用字母开头的蛇形，不超过 40 个字符，确定后不建议再改。接受后成为定义，并在后台回溯 90 天，量大时要等几分钟。
登记未规划的名字
打开「事件定义」页签。状态为「未规划」的行，点「登记」，状态变为「生效」。
加入埋点方案
打开 控制台全端分析数据管理埋点方案，点「从事件定义生成」。还不在方案里的事件定义会补进来：状态为「生效」的记为「已上线」，其余记为「开发中」。以
__开头的自动事件和隐藏的定义不会补入。
验证
「已接受」或「事件定义」里能看到该名字；登记过的状态为「生效」。埋点方案里出现同名条目，状态为「已上线」。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 「待处理」一直是空的 | 全埋点未开，或套餐不含收件箱 | 改去「事件定义」里登记已经上报的名字 |
| 接受后分析里仍没有 | 回溯还在跑，或事件名和代码不一致 | 等回溯完成，且不要改已经写入数据的名字 |
| 方案里是「开发中」 | 生成时该定义还不是「生效」 | 先登记，再在方案里把条目流转到「已上线」 |
网站、小程序、服务端合并成一个用户
三端各自上报时默认是三个人，用同一类型、同一串登录标识后才归到身份映射里的一个用户。匿名访客仍然只计数，不进用户列表。
前提
站点已是识别模式：打开 控制台全端分析用户身份映射，顶部不再提示匿名模式。识别模式需要 Pro 及以上套餐，它不是 控制台配置合规中心 里的档位开关；开启后默认档位固定为「3 · Cookie + 识别」。三端使用同一种标识类型，默认是登录标识，其他可选类型有邮箱、手机号、OpenID、UnionID 和自定义。
步骤
网站在登录成功后调用
识别模式打开后才会加载身份扩展。调用
webcount.login('u_123', { $name: 'Ada' })。站点未识别、该访客实际档位低于 3（地区规则降档、要求同意但未同意、DNT 或 GPC），或标识命中黑名单时，调用直接返回。扩展还没加载时，先放进window.__wcq。小程序或 App 用同一串标识
拿到你们自己的用户标识后调用
login('u_123', { $name: 'Ada' }, { type: 'login' })。类型必须和网站一致。用 OpenID 时，三端都写 OpenID，不要一边是登录标识、一边是 OpenID。服务端带上同一标识
向
POST /api/v1/track提交事件，正文里写login_id为u_123，login_id_type为login。密钥只需勾选「服务端 Track」，用Bearer wck_…，不要把完整密钥写进代码仓库。
验证
三端各发一条之后，在身份映射里按这个标识找到同一个人，用户详情里能看到不同端的事件。anonymous、guest、全零和 -1 这类标识会被拒绝，并出现在该页告警里。
常见失败
| 现象 | 原因 | 处理 |
|---|---|---|
| 用户列表仍是空的 | 身份映射仍提示匿名模式，或访客实际档位低于 3 | 先开启识别模式，再核对地区规则和同意设置 |
| 变成两个用户 | 标识字符串或类型不一致 | 三端使用同一串、同一类型 |
| 服务端事件是另一个人 | 没写 login_id，或类型不同 | 补上 login_id 与 login_id_type |