H5商城没有小程序后台里那套现成的「访问—转化」报表，流量又来自短信、广告、分享、门店码等多种链接。如果不在页面上把来源、设备和支付分支记清楚，运营只能对着一个混合后的访问量做判断。本文写的是怎么采、怎么拆、怎么验证改版，渠道怎么投、活动怎么设计请看H5商城营销推广全攻略，两边不再互相抄同一套指标说明。
H5的数据环境和小程序不一样
- 会话发生在浏览器：微信内置浏览器、Safari、各家Android WebView 的限制不同。微信里 referrer 经常是空的，不能指望「上一跳页面」自动说明来源，必须自己在链接上带渠道参数。
- 没有提审，发版很快，更需要版本标记：活动页今天改、明天再改很常见。分析时要能区分是哪一版页面，否则优化前后的对比会混在一起。
- 没有2MB分包，但有性能预算：体积没有平台硬顶，并不代表可以无限堆脚本。首屏时间、JS错误、接口超时要和转化放在同一张看板上，否则会把「买来的点击」误判成「货不行」。
- 支付不是一条漏斗：微信内是JSAPI，微信外是微信H5支付加支付宝手机网站支付。合并成一个「支付率」会掩盖某一条通道故障。
- 召回也要记结果：模板消息、企业微信添加、短信送达、Web Push 授权都是可记录事件。只看商城内点击，会低估「人已经离开页面」之后的运营。
采集边界
埋点只要能回答运营问题即可，不要把每一次滚动、每一次鼠标移动都打到服务端。页面上多一段同步脚本就会拖慢首屏。手机号、身份证、详细收货地址等敏感字段不要写入分析事件；需要用户画像时用匿名ID关联业务库，并遵守隐私政策和最小必要原则。
埋点：先能对上账，再谈模型
看店通在H5项目里通常把采集分成四层，上线前后都要做一次对账，而不是埋完就交给报表。
1. 计划写在事件表里
- 页面浏览：首页、类目、商品、活动、购物车、结算、支付结果、自定义活动页。每条带页面类型、页面ID、渠道参数、浏览器环境（是否微信内）。
- 经营事件：搜索、筛选、加购、提交订单、发起支付、支付成功、支付失败、领券、参与抽奖或拼团。支付失败要有原因码，便于区分用户取消、通道拒付还是超时。
- 触达事件：短信发送与回执、公众号模板消息发送结果、企业微信好友添加、Web Push 授权与点击。这类事件发生在商城页面之外，却决定复购能不能做起来。
- 技术健康：首屏或最大内容绘制、接口失败、JS异常、白屏。按机型和浏览器分组，问题往往集中在一两款 WebView，而不是「全站都慢」。
代码埋点适合下单、支付这种必须准的事件；可视化或全量采集适合探索点击热区，但要过滤后再入库。百度统计、Google Analytics 可以作流量补充，订单金额仍以自家业务库为准，两边对不上时以支付回调为准。埋点与第三方工具的接入说明见H5数据追踪。
2. 传输与校验
- 事件体用JSON，字段固定：事件名、时间、匿名用户ID、会话ID、页面、渠道、设备。能在服务端补的（如订单金额）不要信前端传来的可篡改字段。
-
上报用HTTPS POST，失败重试要有上限，避免弱网下把队列打爆。页面关闭时可用
navigator.sendBeacon补最后一条。 - 上线当天用自己的测试链路走一遍：带参数的广告链接 → 加购 → 微信内支付 → 微信外H5支付 → 支付宝手机网站支付，核对本库订单号和分析事件能否对上。
- 之后按日看：有没有整页漏报、支付成功数是否小于等于订单库、渠道参数为空的比例是否突然升高（常见于分享时把参数截断）。
看板按问题拆，不按教科书堆指标
指标很多，日常只需要能回答下面四类问题。所谓「行业平均转化区间」缺少可核对的来源，本文不罗列，也不拿它们当考核线。自己的基线来自近几周的同渠道数据，以及改版前后的对照。
1. 人从哪来，质量如何
独立访客、浏览次数、停留、跳出，要连同渠道一起看。H5的渠道至少拆到：短信、信息流、搜索广告、公众号、社群分享、门店码、自然搜索。同一活动不同物料用不同参数。若某渠道访问很多、加购很少，先查落地页是否和素材一致、首屏是否过慢，再去改货盘。
浏览深度浅，不一定是内容失败：广告落地页本来就短，用户看完主图和价格就走，属于预期形态。把它和内容页、商品详情用同一套「停留要长」的标准去比，会得出错误结论。
2. 为什么访问没有变成钱
把路径拆开，而不是只看一个总转化率：
- 商品曝光 → 进入详情 → 加购：看主图、价格、规格是否让人看懂。
- 加购 → 提交订单：看地址表单、运费说明、登录或验证码是否把人拦住。
- 提交订单 → 发起支付 → 支付成功：必须按JSAPI、微信H5支付、支付宝手机网站支付三条线分开。某一条骤降，优先查商户号、授权目录、referrer 限制和证书，而不是改商品标题。
加购高、下单低，多半是流程问题；下单高、支付低，多半是通道或信任问题。客服工单按「支付失败 / 打不开 / 发货」分桶，往往比漏斗图更快指向原因。
3. 货和客单价在不在健康范围
点击、收藏、成交要落到SKU。H5列表页的主图和标题几乎决定点击，详情页的规格选择决定加购。滞销款不要只靠砍价去推，先看是曝光不足还是看了也不买。客单价用满额赠、搭配建议来抬，但要观察退款——硬凑单会把售后做高。
4. 人会不会回来
新访、回访、复购，对H5要和触达事件一起读。回访低，先看支付成功页有没有把手机号、公众号、企业微信留下；再看短信和模板消息有没有实际发出。Web Push 只统计已授权的浏览器用户，不要拿它和全站回访比，否则会低估微信内用户（那边本来就没有Web Push）。
上线初期看这五组就够
按渠道的访问与支付成功、三条支付通道各自的成功率、首屏与JS错误、短信或模板消息的发送回执、30天内是否有第二单。看板做得很宽却没人打开，不如每天固定看这五组。投放与玩法如何配合这些数字，见营销推广全攻略。
四种常用分析方法（按H5场景来用）
1. 漏斗：找出真正断掉的那一截
标准路径可以定为：带参进入 → 浏览商品或活动 → 加购 → 提交订单 → 发起支付 → 支付成功。关键不是漏斗有多漂亮，而是同一路径按渠道、按浏览器、按支付方式再切一刀。短信进来的人可能跳过首页直达商品；广告进来的人可能在首屏就走。混在一个漏斗里，优化动作会对不准人。
改完一版之后，用同一渠道、同一时段长度对比，不要用大促去对比平日。若只有支付成功变少、访问没变，先看通道；若访问和加购一起掉，才去看素材和落地页。
2. 路径：看用户是不是被导航带偏
H5常见的别扭路径包括：活动页找不到规格、详情与购物车来回跳、支付失败后回到首页而不是订单页。把高频路径画出来，能发现导航或按钮文案问题。反复返回上一页，多半是信息没说清（运费、发货时效、是否包邮）。异常路径要抽几条会话看录屏或客服记录，不要只看聚合图。
3. 热力：把按钮放到手会点的地方
点击热力看哪些模块被点、哪些装饰图被误点；滚动热力看活动长页有多少人根本没滑到规则和购买按钮。H5长页活动特别容易把下单按钮放在屏幕外。结论要落到改布局：主按钮提前、规则折叠、避免把可点区域做成纯展示图。热力工具会加重页面，仅在改版期对关键页开启即可。
4. 对照实验：一次只动一个变量
适合测首屏主图、价格呈现、按钮文案、是否默认勾选优惠券。用户随机进A/B，核心指标用支付成功，而不是点击。周期覆盖工作日和周末，样本太少不要下结论。统计上可用常用的差异检验，但不把「显著性」当成唯一门槛——还要看客服负反馈和退款。确认有效后先小流量再全量，H5虽然发版快，全量回滚也要有开关。
一种常见且可复核的改法
详情页跳出偏高时，先用热力看用户是否把时间花在图和价格上、规格区是否被忽略。把主图轮播可点区域加大、价格与库存靠近加购按钮、规格默认选中有货项，再对比同一渠道的加购和支付。这类改动不依赖「行业平均跳出率」，只依赖你自己改版前后的对照。
从数字回到动作
发现问题和改页面之间，要有优先级，否则技术排期会被「都重要」填满。
- 先修影响成交的：某条支付通道失败、某款浏览器白屏、证书或域名异常。这类问题按故障处理，不走「下周迭代」。
- 再修浪费预算的：某条广告素材点击贵且不加购、落地页和素材不一致、渠道参数丢失导致无法关停劣质渠道。
- 然后才是体验打磨：文案、排序、推荐、会员分层。没有前两层，优化首页皮肤意义有限。
改动要写预期指标和观察窗口，上线后对照，无效就回滚。用户访谈和问卷用来解释「为什么掉」，不能代替支付成功数。触达侧也一样：短信开了但退订升高，要减频或改文案，而不是继续加量。
看店通在数据侧提供什么
看店通可在H5商城接入页面与交易埋点、渠道参数规范、按浏览器和支付分支拆开的漏斗、以及与短信、公众号模板消息、企业微信、Web Push 发送结果的对照。需要事件表模板或看板字段清单，可通过页面右下角客服微信索取。具体投放与活动怎么用这些字段，仍以营销推广页为准，以免两篇文章写同一段「指标定义」。
小结
H5的数据分析要回答的是链接场景里的问题：人从哪条链接来、在哪一种浏览器里逛、走的是哪条支付、离开后有没有被再次触达。采集准确、拆分合理、改版可对照，比堆一套无法核对来源的「行业转化率」有用。性能和支付配置的技术背景见支付接入指南，立项阶段的指标取舍也可参考开发常见问题中关于上线初期盯数的问答。
