电商经营
这块看板有 10 张卡片
4 × KPI1 × 漏斗1 × 趋势1 × 留存1 × 分布2 × 分组表
这块看板上的指标
GMV · 订单数 · 客单价 · 下单转化率 · 看商品用户数 · 下单用户数
问题在哪
每家店周一都会问的三个问题
数据通常都在，只是分散在店铺后台、支付渠道和广告账户里。
购物车被放弃，不知道在哪一步
加购看着挺健康，订单却不行。没有 begin_checkout 这一步，分不清是地址表单还是支付页的问题。
盯这个数： 结账完成率
渠道按点击评价，不按利润
广告平台各报各的转化。花费没导入、没对上实付订单之前，每个渠道看起来都是赢家。
盯这个数： 渠道 GMV 表
退款在另一个系统里
不扣退款金额的 GMV 会高估当月。包里把 refund 当成一等事件，带退款原因。
盯这个数： 退款率
模板指标
14 个指标，每个只有一个定义
下面每个指标都由下一节的事件算出来。名称就是装完之后你在控制台里看到的那个。
| 指标 | 定义 | 格式 | 所在看板 |
|---|---|---|---|
| GMV | PROPSUM(purchase.revenue) | 金额 | 电商经营 商品与转化 |
| 订单数 | TOTALS(purchase) | 数值 | 电商经营 商品与转化 |
| 下单用户数 | UNIQUES(purchase) | 数值 | 电商经营 |
| 客单价 | PROPSUM(purchase.revenue) / TOTALS(purchase) | 金额 | 电商经营 |
| 看商品用户数 | UNIQUES(view_item) | 数值 | 电商经营 商品与转化 |
| 加购数 | TOTALS(add_to_cart) | 数值 | — |
| 加购用户数 | UNIQUES(add_to_cart) | 数值 | 商品与转化 |
| 加购率 | UNIQUES(add_to_cart) / UNIQUES(view_item) * 100 | 百分比 | 商品与转化 |
| 下单转化率 | UNIQUES(purchase) / UNIQUES(view_item) * 100 | 百分比 | 电商经营 |
| 结账完成率 | TOTALS(purchase) / TOTALS(begin_checkout) * 100 | 百分比 | 商品与转化 |
| 搜索数 | TOTALS(search) | 数值 | — |
| 退款金额 | PROPSUM(refund.revenue) | 金额 | 商品与转化 |
| 退款单数 | TOTALS(refund) | 数值 | 商品与转化 |
| 退款率 | TOTALS(refund) / TOTALS(purchase) * 100 | 百分比 | 商品与转化 |
指标名称和公式来自行业包。TOTALS 数事件次数，UNIQUES 数人数，PROPSUM 对某个属性求和。本页所有数字都是示例数据。
模板装上的看板
每块看板由一组卡片组成：KPI、漏斗、趋势、留存、分布和分组表。装上以后可以改、复制、分享。
商品与转化
这块看板有 8 张卡片
4 × KPI1 × 漏斗2 × 趋势1 × 分组表
这块看板上的指标
看商品用户数 · 加购率 · 结账完成率 · 退款率 · 加购用户数 · 退款金额
漏斗
看商品、加购、结账、支付
购买漏斗用 7 天窗口，周五回来付款的买家也算数。−46% 的角标标出流失最多的那一步。
购买漏斗
7 天窗口看商品
2,400
加购
1,248
开始结账
674
支付成功
508
按属性拆开
同一条漏斗按商品类目、优惠券或 payment_method 拆，看哪部分商品转化得动。
按渠道比较
每个渠道各跑一条漏斗。点击便宜、结账一步却弱的渠道，比它看上去贵。
锁定同一件商品
搜索购买漏斗锁定 item_id，你看到的是人们有没有买下他们搜的那件。
包里的其他漏斗
- 搜索购买漏斗站内搜索 → 看商品 → 支付成功 · 7 天窗口
团队怎么用
模板第一天就能干的四件事
每一块都把一个能力和它要解决的店铺问题配在一起。
用法 1
修好漏水的那一步结账
begin_checkout 和 purchase 把整个支付流程框起来。中间自己加步骤事件，或者让全埋点把字段点击捡起来，漏斗就能精确显示买家停在哪。
- 结账完成率作为 KPI 卡片
- 按设备拆漏斗，只在手机上出现的 bug 会浮出来
- 从结账页到离开者转去页面的路径分析
示例场景： 手机端结账完成率 31%，桌面端 58%。地址自动补全在 iOS 上失效。改一处，回来 9 个点。
购买漏斗 · 手机端
7 天窗口看商品
2,400
加购
1,248
结账
674
支付
508
用法 2
按扣除花费后的 GMV 给渠道排序
点击 ID 留在买家身上，purchase 带着收入，导入花费之后渠道表就变成回报表。邮件订阅也是一个渠道，和付费渠道用同一个订单定义。
- 14 个广告平台按点击 ID 识别
- 渠道 GMV 表就在经营看板上
- CSV 或集成导入花费
渠道 GMV
最近 30 天| 渠道 | 看商品 | 下单 | GMV | 回报 |
|---|---|---|---|---|
| 邮件订阅 | 4,120 | 312 | $13,100 | 6.2× |
| Google Ads | 12,480 | 486 | $20,400 | 3.4× |
| Meta | 9,870 | 264 | $11,090 | 2.1× |
| Microsoft Ads | 3,210 | 98 | $4,120 | 1.8× |
| TikTok | 7,640 | 71 | $2,980 | 0.8× |
用法 3
盯复购，不只盯首单
经营看板里有按周的首购到复购留存。第二周回来的买家才是利润；优惠券和生命周期邮件就在这里被评价。
- 复购留存卡片，8 周
- 分群：买过两次、无退款
- 同一档案上的 RFM，用于生命周期活动
首单后复购（周）
| 首单 | 买家 | 第1周 | 第2周 | 第3周 | 第4周 | |
|---|---|---|---|---|---|---|
| 9月1日当周 | 612 | 100% | 18% | 14% | 12% | 11% |
| 9月8日当周 | 640 | 100% | 21% | 15% | 13% | |
| 9月15日当周 | 598 | 100% | 19% | 16% | ||
| 9月22日当周 | 655 | 100% | 24% |
用法 4
退款带原因，按门店看
refund 带 order_id、金额和原因码。退款率在商品看板上；门店排行表显示哪家店退得最多。
- 退款金额趋势挨着 GMV
- 原因：质量、尺码、改主意、延误
- group=store 做门店 GMV 排行
退款原因 · 占退款单比例
尺码质量改主意延误其他
统计 × 客服
访客停在结账页时打个招呼，购物车还在眼前
实时列表里有位访客在结账页待了三分钟，购物车 $184，来自 Google Ads。客服看到购物车、浏览过的页面和她试过的优惠码。邀请在她关掉标签页之前发出去。
- 按 /checkout 停留时长和购物车金额触发主动邀请
- 上下文卡片：购物车、来源、最近五页、优惠码尝试
- AI 先从你的物流和退换政策页回答问题
示例场景： 一个月里结账页发出 1,284 次主动邀请，318 次得到回复，172 次在当次会话内付了款。
访客上下文
- 页面
- /checkout · 3 分 12 秒
- 购物车
- $184 · 3 件
- 来源
- Google Ads · spring_sale
- 优惠码
- 试了两次，无效
- 访问
- 第 2 次 · 4 天前来过
- /collections/outerwear
- /products/parka-01
- /cart
- /checkout
yourstore.com/checkout
TC
Mia · 店铺客服
你好！那个码昨天过期了，换 SPRING10 就行，对你的购物车有效。还需要别的帮助吗？
事件
9 个事件，5 个必需
浏览器事件来自代码片段或全埋点。purchase 和 refund 从服务端上报，order_id 作为 insert_id，重试的 webhook 不会重复计数。
| 事件 | 显示名 | 触发时机 | 必填属性 | 来源 |
|---|---|---|---|---|
search | 站内搜索 | 提交站内搜索时。results = 0 表示无结果搜索。 | query | 网页 小程序 App |
view_item必需 | 看商品 | 商品详情页，每次看商品一条。 | item_id | 网页 小程序 App |
add_to_wishlist | 收藏 | 商品被收藏时。 | item_id | 网页 小程序 App |
add_to_cart必需 | 加购 | 商品加入购物车时，能带数量和金额就带上。 | item_id | 网页 小程序 App |
remove_from_cart | 移出购物车 | 商品被移出购物车时。 | item_id | 网页 小程序 App |
view_cart | 看购物车 | 打开购物车页或购物车抽屉时。 | — | 网页 小程序 App |
begin_checkout必需 | 开始结账 | 进入结账流程时；有 items_count 和 coupon 就带上。 | — | 网页 小程序 App |
purchase必需 | 支付成功 | 支付成功后由服务端上报；insert_id = order_id，revenue 为实付金额，group = 门店。 | order_idrevenuecurrency | 服务端 |
refund | 退款 | 发生退款时由服务端上报，带 order_id、金额和原因。 | order_idrevenue | 服务端 |
事件名、必填属性和来源来自行业包。标为「服务端」的事件必须由你的后端上报；订单号、发票号作为 insert_id 去重。
场景
两家店，两个第一周
场景示例，非真实评价。
结账完成率是我们以前从没见过的一个数。第一天 54%。两周之后、去掉一个字段，63%。流量没变。
RK
R. K.
店主 · DTC 外套品牌
TikTok 带来最多看商品的人，买的人最少。渠道 GMV 表在一次会上结束了争论，预算挪到了邮件订阅和搜索。
DN
D. N.
增长 · 家居用品店
以使用者视角撰写的场景示例，非真实评价。
电商模板会装上什么？
9 个事件；14 个指标，含 GMV、客单价、下单转化率、结账完成率和退款率；2 条漏斗；2 块看板：电商经营、商品与转化。
要改店铺代码吗？
浏览器事件可以来自代码片段、全埋点或 Shopify、WooCommerce、Webflow 插件。purchase 和 refund 建议从服务端或支付回调上报，不会因为标签页关掉而少掉收入。
多门店品牌怎么处理？
事件上带 group=store:
商品级报表从哪来？
purchase 可以带 items 数组：item_id、category、price、quantity。带了，促销和商品报表按明细算；不带，优惠券报表只能到订单级。
能看到复购率吗？
经营看板里有首购到复购的周留存。建一个「购买 ≥2 次」的分群，就能把它当成一个实时人群来跟。
跨境是单独的包吗？
不是。跨境外贸方案装的就是这个电商包，再加上翻译客服和海外广告归因。