数据在哪 · 指标说明书
这份说明书回答一个问题：你想看的那个指标，在站内哪个页面、哪个区块，背后是哪张表的哪个字段。
有的，写清位置；没有的，明确写「没有」，并说明要做什么统计/采集才能有。
版本 v1.0 ｜ 更新 2026-10-22 ｜ 覆盖平台：美团 · 淘宝闪购 · 京东到家 ｜ 站内报表 64 个入口
0一分钟看懂
站内和「商品/订单维度」相关的分析页一共 6 个，都在侧边栏 BI看板 组里：
| 页面 | 侧边栏位置 | 一句话说清它管什么 | 接口 |
|---|
| 订单·商品分析 | BI看板 › 第2项 | 订单级 + SKU 级明细：单量 / 金额构成 / 客单价 / 价格带 / 时段 / 逐单逐品 | /api/order-analysis |
| 销售与流量转化 | BI看板 › 第1项 | 分平台看曝光→进店→下单→成交的漏斗与转化率 | /api/sales-conversion |
| 投放与归因 | BI看板 › 第3项 | 投放计划-日：花费 / 曝光进店增量 / ROI / 归因窗口 | /api/ad-attribution |
| 履约分析 | BI看板 › 第4项 | 接单/配送时长、超时、履约成本拆解、门店对比 | /api/fulfillment-analysis |
| 活动与券分析 | BI看板 › 第5项 | 活动类型 / 平台商家承担 / 支出率 / 券 / 活动 SKU / 回落 | /api/promo-analysis |
| 数据粒度总览 | BI看板 › 第6项 | 5 种粒度 × 29 种用途的「有没有 / 在哪」总表 | 前端内置 |
有 站内直接能看，点开就有
部分 能用近似口径算，但不是平台原值，看数时要知道它在近似什么
没有 数据源里根本没有这个字段，必须先补采集或建模
1订单级
主看板：BI看板 › 订单·商品分析（页面 id order-analysis）。顶部可切平台（美团/京东到家/淘宝闪购）、选日期区间、按门店名过滤。
1.1 KPI 卡片区（页面上方一排灰底卡片）
| 指标 | 站内位置 | 数据来源（表.字段） | 状态 |
|---|
| 订单数（成交单量） | 订单·商品分析 › 卡片「订单数」 | mt_orders.order_sn（按单号去重，剔除 order_status LIKE '%取消%'）
京东 jd_orders.order_sn；闪购 tb_flash_orders.order_sn | 有 |
| 含取消的总单量 | 订单·商品分析 › 「订单数」卡片右侧灰字「含取消 N 单｜总 N 单」 | 同上，不剔除取消（total_count / cancel_count）。与美团后台「下单量」比对应看这个数 | 有 |
| 成交金额（订单总额） | 卡片「成交金额」 | 美团 mt_orders.goods_total_price；京东 jd_orders.total_amount；闪购 tb_flash_orders.total_amount | 有 |
| 配送费 | 卡片「配送费」 | 美团 mt_orders.delivery_fee_total；闪购 tb_flash_orders.delivery_fee；京东该字段平台不提供 | 有 / 京东 没有 |
| 包装费 | 卡片「包装费」 | 美团 mt_orders.package_fee；闪购 tb_flash_orders.package_fee；京东无 | 有 / 京东 没有 |
| 优惠合计 | 卡片「优惠合计」 | 美团 merchant_activity_pay + platform_activity_pay；京东 discount_amount；闪购 merchant_*_pay + non_merchant_*_pay 合计 | 有 |
| 优惠后实付 | 卡片「优惠后实付」 | 美团 user_pay（商品实付，不含配送费）；京东 user_payable；闪购 user_pay | 有 |
| 客单价 | 卡片「客单价」 | 实付 ÷ 订单数（页面现算） | 有 |
| 件单价 | 卡片「件单价」 | 实付 ÷ 件数（件数来自明细表 SUM(product_qty)） | 有 |
| 每单件数 | 卡片「每单件数」 | 件数 ÷ 订单数 | 有 |
| 促销订单占比 | 卡片「促销订单占比」 | mt_order_product_detail.is_promo_order='是' 的单号去重占比 | 有 |
| 免配送费订单占比 | 卡片「免配送费订单占比」 | 闪购 tb_flash_orders.free_delivery；美团按 delivery_fee_discount 推断 | 部分 |
1.2 区间缺日提示（红色提示条）
页面顶部口径说明下方，会按所选区间自动比对「应有天数 vs 实际有单天数」，缺哪天就红字列出（例：缺 2026-10-21、2026-10-22，最近可用业务日 10-20）。看到这条先补数据，别当经营下滑。
1.3 下方 4 个分布表 + 2 张明细表
| 区块 | 站内位置 | 口径与字段 | 状态 |
|---|
| 时段分布（7 段） | 📊 订单时段分布 | 按 HOUR(order_time) 分 7 段：00-06 / 06-09 / 09-12 / 12-15 / 15-18 / 18-21 / 21-24。不是营业时长口径，是下单时刻分布 | 有 |
| 价格带（6 档） | 💰 各价格带订单占比 | 按 user_pay 分 0-10 / 10-20 / 20-30 / 30-50 / 50-100 / 100+ 元 | 有 |
| 高客单品类 TOP15 | 🏷️ 高客单品类 | mt_order_product_detail.product_category，筛选实付 ≥ 平台客单价 ×1.5 的订单 | 有 |
| 高/低客单标识 | 同上（阈值） | 高客单 = 实付 ≥ 客单价×1.5；低客单 = 实付 ≤ 客单价×0.5（站内自定义规则，不是平台标签） | 部分 |
| 订单明细（逐单） | 🧾 订单明细（订单级） | 单号 / 下单时间 / 门店 / 商品金额 / 配送费 / 包装费 / 优惠 / 实付 / 件数。支持「📤 导出订单CSV」 | 有 |
| SKU 明细 | 📦 SKU 明细（SKU级） | 见第 2 章。支持「📤 导出SKU CSV」 | 有 |
| 城市 | 导出 CSV 内 | 美团 mt_orders.city_name / mt_order_product_detail.city_name；闪购 tb_flash_orders.city；京东订单无城市字段（只有流量表 jd_traffic_overview.city） | 有 / 京东 没有 |
| 支付方式 | 明细内 | 美团 mt_orders.pay_method、明细 pay_type；京东 pay_method / pay_channel | 有 |
| 取消原因 | 明细内 / 美团订单页 | 美团 mt_orders.cancel_reason、闪购 invalid_reason、京东 cancel_reason | 有 |
| 接单时长 / 配送时长 | 美团订单页 / 履约分析 | 美团 accept_seconds（秒）、delivery_time_min（分钟）；闪购是文本时间需自行相减 | 有 |
1.4 订单级里「没有的」
| 想要的东西 | 状态 | 现在能到什么程度 / 要怎么做才有 |
|---|
| 起送价 | 没有 | 平台导出的订单表不含门店配置。要有：从美团/闪购「门店设置」导出起送价，或对接开放平台门店配置接口，建 store_config(shop_id, 起送价, 免配门槛) 表 |
| 满减/满赠门槛（结构化） | 部分 | 只能在 promo_name 文本里用正则提「满X元减Y」这类命中的活动（覆盖率不全）。要有：活动后台的活动配置导出（含门槛值） |
| 商品历史调价记录 | 没有 | 没有任何价格流水表。现在只有当日快照（tb_flash_orders.origin_price/sale_price）。要有：每天抓商品列表价格入库，才能做价格变动时间线 |
| 利润品标识 | 没有 | 缺成本覆盖 + 费用分摊，无法判定。见第 2 章「SKU 毛利」 |
2SKU 级
主位置：订单·商品分析 › 底部的「SKU 明细」表；也散落在 商品信息 › 商品销售（product-sales）、库存管理 › 库存查询（inv-stock）。
| 指标 | 站内位置 | 数据来源（表.字段） | 状态 |
|---|
| SKU 编码 | SKU 明细表第 1 列 | 美团 mt_order_product_detail.product_sku（另有 product_upc、item_code）；京东 jd_sku + merchant_sku + upc；闪购 product_sku / product_barcode | 有 |
| 商品名称 | SKU 明细表第 2 列 | product_name（三平台都有） | 有 |
| 品类 | SKU 明细表第 3 列 | 美团 product_category（平台二级分类）；京东 category_l1/l2/l3；闪购 product_category；自有分类在 products.category | 有 |
| 销量（件） | SKU 明细「销量」 | 美团 SUM(product_qty)；京东 product_qty；闪购 buy_qty（促销件数另有 promo_buy_qty） | 有 |
| SKU 行金额 | SKU 明细「金额」 | 美团 product_real_amount（行级实付）；京东 product_price × product_qty；闪购 sale_price × buy_qty | 有 |
| 原价 / 售价 / 促销价 | SKU 明细 | 美团 product_original_price；闪购 origin_price / sale_price（可算出「是否在促销」）；京东 product_price | 有 |
| 促销标记 / 参与的活动名 | SKU 明细 | 美团 is_promo_order、promo_name、promo_activity；闪购 is_full_gift、promo_buy_qty | 有 |
| SKU 成本 | 商品信息 › 商品档案 | products.cost_price / products.cost；库存表 inventory.cost_price（更全） | 部分 |
| SKU 级毛利 | 无 | 需 行实付 − 成本×件数 − 分摊的佣金/活动/配送，成本覆盖率不足时只能对部分 SKU 算。要补：SKU 成本维护 + 费用分摊规则表 | 部分 |
| 引流品 / 利润品标识 | SKU 明细（近似） | 引流品现用「件单价 ≤ 10 元」近似；利润品没有（依赖毛利） | 部分 / 利润品 没有 |
| 高低客单标签 / 价格带 | 见 1.3 | 按订单实付或件单价分档（站内规则） | 部分 |
| 商品规格 / 条码 / 供应商 | 商品信息 › 商品档案 | products(spec, color, supplier_id, sku) | 有 |
| SKU 库存 / 可售天数 | 库存管理 › 库存查询 | inventory：qty_available / qty_actual / qty_locked / sales_7d / sales_30d / available_days / suggest_purchase | 有 |
⚠ 一个必须知道的坑：美团明细表里 platform_activity_pay / shop_activity_pay 是订单级的值，在同一订单的每一行 SKU 上重复出现，绝对不能直接 SUM（会翻好几倍）。订单级金额要 GROUP BY order_no 取 MAX()；行级拆分只有 product_subsidy_total。
3投放计划-日 + 归因
主看板：BI看板 › 投放与归因（ad-attribution，接口 /api/ad-attribution，视图 summary / plans / daily / rows / baseline）。
先说结论：三个平台里只有淘宝闪购有投放数据。美团、京东到家在站内完全没有投放花费/曝光数据——这两块的投放要在各自后台看，或补导出。
3.1 淘宝闪购（唯一有数据的平台）
| 指标 | 站内位置 | 数据来源 | 状态 |
|---|
| 投放日期 | 投放与归因 › 按日表 | tb_flash_promotion.date（3,237 行，2026-06-14 起） | 有 |
| 投放对象 / 计划归属 / 出资方 | 计划明细 | promotion_product（投的商品）/ plan_ownership（计划归属）/ funding_source（出资来源） | 有 |
| 投放花费 | KPI「投放金额」 | promotion_cost（推广花费）、cash_cost（现金花费） | 有 |
| 曝光增量 / 进店增量 | 漏斗区 | exposure_increase / store_visit_increase（增量口径，平台算法） | 有 |
| 全店成交 / 订单 / 访客 | 计划明细 | total_transaction / total_orders / total_store_visits / total_exposure | 部分 |
| ROI（投产比）/ 费用率 / 单均获客成本 | KPI 区 | 页面现算：GMV ÷ 花费、花费 ÷ GMV、花费 ÷ 订单数 | 有 |
| 投流漏斗（曝光→进店→下单→成交） | 漏斗区 | tb_flash_traffic：total_exposure / total_store_visits / total_orders / store_conversion_rate / order_conversion_rate | 有 |
| 归因窗口 / 基线对比 | 「基线」视图 | 用投放前 7 天做基线对比（时间前后对照，不是真对照组） | 部分 |
⚠ 重复登记陷阱：tb_flash_promotion 的 total_*（全店曝光/访客/订单/成交）在多个计划行里重复登记——30 天直接 SUM 曝光 1,209 万，而流量表实际只有 48 万（25 倍）。算总量时只能加总计划独占项（花费、增量），全店值必须去重或改用 tb_flash_traffic。
3.2 投放 / 归因里「没有的」
| 想要的东西 | 状态 | 现在能到什么程度 / 要怎么做才有 |
|---|
| 美团投放（推广通）花费与效果 | 没有 | 站内零数据。要有：美团商家后台「推广通」按日导出 → 建 mt_ad_plan(date, plan_id, cost, exposure, clicks, orders, gmv) 表并接导入脚本 |
| 京东投放（京准通）花费与效果 | 没有 | 同上，从京准通后台导出 |
| 投放时段分布 | 没有 | 平台只给日粒度。要有：后台按小时报表导出 |
| 归因订单 ID（哪一单是投流带来的） | 没有 | 三个平台导出里都没有「投放-订单」关联字段。要有：平台侧开通归因报表，或做站内实验（分人群/分时段开关投放）才能归因 |
| 对照组基线 / 增量因果 | 部分 | 现在只有「投放前后对比」，会被季节/大促干扰。要真增量：设计 A/B（同期同城不同店开关投放），否则只能叫相关不叫因果 |
| 投放计划 ID | 部分 | 闪购表里有投放对象和计划归属，但没有平台计划编号；美团/京东完全没有 |
4履约（订单级 + 门店-日）
主看板：BI看板 › 履约分析（fulfillment-analysis，视图 summary / stores / durations / hours / costs / orders）。
| 指标 | 站内位置 | 数据来源 | 状态 |
|---|
| 接单时长 | 履约分析 › 时长分布 | mt_orders.accept_seconds（秒）；闪购 merchant_accept_time − order_time | 有 |
| 配送时长 | 履约分析 › 时长分布 | mt_orders.delivery_time_min；京东 jd_orders.delivery_time + jd_aftersale.avg_delivery_time；闪购 tb_flash_service | 有 |
| 超时单量 / 超时率 | 履约分析 / 京东售后 | 京东最全：jd_aftersale.timeout_order_count + 分档 timeout_0_1/1_5/5_10/10_20/20_30/30_plus_count、on_time_rate；闪购 tb_flash_service.on_time_rate；美团靠 mt_orders.delivery_status | 部分 |
| 超时罚款 | 美团订单 › 明细列 | mt_orders.fine_type / fine_reason / fine_amount（来自平台佣金明细） | 有 |
| 履约成本拆解 | 履约分析 › 成本拆解 | 美团 delivery_fee_total + service_fee + commission + commission2 + package_fee；闪购 platform_commission、merchant_delivery_pay、package_fee | 有 |
| 单均履约成本 / 成本率 | 履约分析 KPI | 成本合计 ÷ 订单数；成本合计 ÷ GMV（页面现算） | 有 |
| 配送补贴（商家/平台） | 成本拆解内 | 美团 delivery_fee_discount；闪购 merchant_delivery_pay 与 non_merchant_delivery_pay 分列 | 有 |
| 高峰 / 低谷 | 履约分析 › 时段 | 按下单时刻聚合（同 1.3 时段口径） | 有 |
| 门店履约历史水平 | 履约分析 › 门店对比 | 按 shop_name / store_name 聚合时长、超时、成本 | 有 |
| 小单标识 | 订单明细（规则） | 用实付低于阈值判定（站内规则，非平台标签），阈值可在页面看到 | 部分 |
4.1 履约里「没有的」
| 想要的东西 | 状态 | 现在能到什么程度 / 要怎么做才有 |
|---|
| 配送距离 | 没有 | 三个平台的订单导出都没有距离字段。可行路径：用 orders.receiver_address（聚水潭有收货地址）或平台地址做地理编码，算门店→收货点直线/骑行距离 → 需要一次地址→坐标转换（高德/腾讯地图 API）+ 每日增量计算 |
| 远单标识 | 没有 | 依赖距离，同上。有距离后按「距离 > 门店中位数×1.5」定义即可 |
| 运力缺口（骑手在线/缺口） | 没有 | 站内没有骑手侧数据（只有 orders.rider_name/rider_phone 的姓名电话）。要有：平台「运力」报表导出，或接入配送侧系统 |
| 考核规则 / 罚则文本 | 没有 | 平台规则不在数据里（只落了罚了什么钱）。要有：把各平台考核规则人工维护成配置表，才能算「达标率/预警」 |
| 超时率（美团全量） | 部分 | 美团商责报表的超时字段全期为 0（源报表未填充），只能用 delivery_status 近似 |
5活动与券
主看板：BI看板 › 活动与券分析（promo-analysis，视图 summary / types / coupons / skus / daily / baseline / lapses）。
| 指标 | 站内位置 | 数据来源 | 状态 |
|---|
| 活动名称 / 类型 | 活动与券 › 类型分布 | 美团 mt_order_product_detail.promo_name（形如 活动名X元[美团承担:a,商家承担:b]，解析成类型+金额）；闪购 is_full_gift、promo_buy_qty | 有 |
| 承担方与各自金额（平台/商家/品牌） | 类型分布 + KPI | 同上解析出的「美团承担 / 商家承担」；闪购 merchant_*_pay（商家承担）与 non_merchant_*_pay（平台承担）分列；京东只有 discount_amount 一个总数 | 有 / 京东 没有 |
| 优惠力度（减多少元） | 类型分布 | 从 promo_name 提取「X元」 | 有 |
| 支出总额 / 支出率 | KPI 区 | 活动承担合计；支出率 = 支出 ÷ GMV | 有 |
| 活动 SKU 销量 / GMV | 活动 SKU 表 | mt_order_product_detail 按 is_promo_order='是' 的 SKU 聚合 | 有 |
| 活动后回落 | 回落视图 | 活动后 N 天 vs 活动期日均对比 | 部分 |
| 增量 GMV / ROI | 基线视图 | 活动前窗口做基线的前后对比（非因果） | 部分 |
| 券支出（仅金额） | 券视图 | 闪购 merchant_coupon_pay / non_merchant_coupon_pay / customer_buy_coupon_pay；美团券混在 promo_name 里按名称识别 | 部分 |
5.1 活动券里「没有的」
| 想要的东西 | 状态 | 现在能到什么程度 / 要怎么做才有 |
|---|
| 活动 ID | 没有 | 三个平台的订单/明细导出里都没有活动编号，只有活动名称。要补：活动后台「活动列表」导出（含活动ID）→ 建 promo_master 主表，再按名称回挂 |
| 活动起止时间 | 没有 | 同上，一次导出活动主表即可解决（现在只能靠单量突变倒推活动期） |
| 活动门槛（满X元可用/满X件） | 没有 | 只有零散文本。要补：活动配置导出（见上） |
| 券发放量 / 领取量 / 核销率 | 没有 | 导出里只有「券花了多少钱」，没有发了多少张、领了多少张、核销多少张。要补：各平台「优惠券」报表导出（发放/领取/核销三列） |
| 券客单价 / 券对应 SKU | 没有 | 缺券维度明细。补了发放核销报表 + 券ID 后可算 |
| 活动毛利 | 没有 | 需要 SKU 成本（见第 2 章），成本覆盖率不足 |
| 力度实验（A/B、满减梯度对比） | 没有 | 需要主动做实验（同城分组设不同力度），站内只能做事后对比 |
| 起送价 / 免配门槛 | 没有 | 同 1.4：需门店配置表 |
6粒度 × 用途
完整的 5 粒度 × 29 用途对照矩阵在站内 BI看板 › 数据粒度总览（granularity-map），那里是可勾选的交互表。这里只给结论口径：
| 粒度 | 主要用途（能支撑的） | 看数去哪 | 覆盖度 |
|---|
| 门店-日 / 门店-时段 | 门店经营日报、时段排班、门店对比排名 | 仪表盘 · 三平台BI看板 · 各平台日报页 | 较完整 |
| 订单级 | 单量/金额/客单价/价格带/时段/明细导出 | 订单·商品分析 | 较完整 |
| SKU 级 | 商品销量榜、品类结构、促销品分析 | 订单·商品分析 › SKU 明细 / 商品销售 | 部分（缺成本/毛利） |
| 活动 / 券级 | 活动支出与承担、活动 SKU、回落 | 活动与券分析 | 部分（缺活动ID/门槛/券发放） |
| 投放计划级 | 投放花费、ROI、漏斗、基线 | 投放与归因 | 仅闪购（美团/京东缺） |
7「没有的」汇总 —— 要补哪些统计
按「补的成本从低到高」排序。前三项属于导一份表就能解决，后面几项需要建模或接系统。
| # | 缺什么 | 影响哪些指标 | 补的方式 | 具体动作 |
|---|
| 1 | 活动主表（活动ID / 起止时间 / 门槛 / 力度） | 活动分析全部维度 | 导表即可 | 美团「营销活动」、闪购「营销中心」导出活动列表 → 建 promo_master → 按 promo_name 回挂订单明细 |
| 2 | 优惠券发放 / 领取 / 核销 | 券渗透率、核销率、券客单价 | 导表即可 | 各平台「优惠券」报表导出 → coupon_stat(date, coupon_id, shop, issued, received, used, amount) |
| 3 | 门店配置（起送价 / 免配门槛 / 满减档位） | 起送价、免配率、门槛分析 | 导表即可 | 门店设置导出 → store_config(shop_id, min_order, free_delivery_threshold, ...) |
| 4 | 美团 / 京东 投放数据 | 投放 ROI、费用率、增量 | 导表 + 建表 | 推广通 / 京准通按日导出 → mt_ad_plan / jd_ad_plan，复用闪购投放页的报表逻辑 |
| 5 | SKU 成本覆盖率 + 费用分摊规则 | SKU 毛利、利润品、活动毛利 | 需建模 | ① 补齐 products.cost_price；② 定分摊规则（佣金按金额、活动按行、配送按单）；③ 建 sku_margin 视图 |
| 6 | 配送距离 | 远单占比、单均里程、距离-时效 | 需建模 | 收货地址 → 经纬度（高德/腾讯 API，注意合规）→ 门店坐标 → 算距离存 order_distance |
| 7 | 骑手 / 运力在线数 | 运力缺口、高峰人力 | 需接系统 | 平台「运力监控」报表或配送侧系统导出 |
| 8 | 投放归因订单 ID / 对照组实验 | 真增量、因果 ROI | 需实验设计 | 平台归因报表（若有）+ 站内做同期同城开关投放的分组实验 |
| 9 | 商品价格变更流水 | 调价影响、价格弹性 | 需每日抓取 | 每日抓商品列表价格快照 → product_price_history(sku, date, price)，才能做调价记录 |
| 10 | 平台考核规则文本 | 达标率、罚款预警 | 需人工维护 | 人工整理成规则配置表（超时阈值、罚金标准），配罚金实发数据算达标率 |
8数据从哪来 & 什么时候更新
8.1 主要源表（数据落在这 6 张表里，其余报表都是它们的二次加工）
| 表 | 行数 | 装什么 | 谁写进来的 |
|---|
mt_orders | 15.7 万 | 美团订单主表（59 列：金额、活动、结算、提现、罚款、时长） | 官方「商品维度」CSV 导入 |
mt_order_product_detail | 26.9 万 | 美团订单 × SKU 明细（49 列：行金额、促销、品类、时长） | 同上（同一次导入） |
tb_flash_orders | 8.6 万 | 淘宝闪购订单 + SKU 明细（一行一 SKU，含平台/商家各项承担） | RPA 导出 CSV |
tb_flash_promotion | 3,237 | 闪购投放计划-日（唯一的投放数据源） | RPA 导出 |
jd_orders | 2.2 万 | 京东到家订单 + SKU（含处方/医保字段） | RPA 导出 zip |
orders / inventory / products | 87.5 万 / 9.5 万 / 2,648 | 聚水潭全平台订单、库存、商品档案（成本在这里） | 聚水潭 API（每 10 分钟） |
8.2 更新节奏
- 聚水潭（订单/库存/商品）：API 每 10 分钟同步；夜间 03:00 / 03:30 跑汇总。
- 美团订单：靠商家后台导出「商品维度」CSV 放进
D:\rpa_transer\美团\美团订单\，每天 15:45 自动入库（无新文件则跳过）。
- 美团其他（客服/评价/履约/门店评分）：RPA 每天 08:00 跑
rpa_sync_scheduled.bat。
- 淘宝闪购 / 京东：RPA 每天导出后在 15:35 补推进服务器。
- 数据体检：每天 16:30 跑 33 项检查 → 站内 报表 › 🩺 数据体检（
data-health）看红黄绿。
⚠ 当前已知缺口（2026-10-22 巡查）：
- 美团订单 2026-10-21、10-22 未入库——因为这两天的「商品维度」CSV 还没从美团后台导出（目录里最新只到 10-20）。订单·商品分析页会红字提示缺日。
- 闪购订单缺 2026-09-25、10-07 ~ 10-09。
- 电话转写源 2026-07-30 起断供（客服相关指标不可用）。
- 美团
mt_fulfillment 是脏表（101 万行列错位），履约分析已改用 mt_orders 的时长字段，不要再用那张表。
9自己动手查
9.1 常用接口（都需要登录态，浏览器里直接访问即可）
| 接口 | 用途 |
|---|
/api/order-analysis?platform=mt&view=summary | 订单级 KPI（含 cancel_count / total_count / coverage） |
…&view=orders&page=1&size=50 | 逐单明细（size 最大 200） |
…&view=skus / hours / bands / cats | SKU 明细 / 时段 / 价格带 / 高客单品类 |
/api/ad-attribution?view=plans|daily|summary|rows|baseline | 投放计划-日与归因 |
/api/fulfillment-analysis?platform=mt&view=costs | 履约成本拆解（view 还有 summary/stores/durations/hours/orders） |
/api/promo-analysis?platform=mt&view=types | 活动类型与承担方（还有 coupons/skus/daily/baseline/lapses） |
9.2 直连数据库查（只读账号）
host 118.31.4.76:3306 ／ user remote_user ／ db mystore。
写 SQL 前必看的两个坑：① 京东表没有 import_date（用 deal_time / stat_date / stat_period）；② 闪购 tb_flash_traffic / tb_flash_service 的 date_str 是 '20261012' 无连字符，用 '%Y%m%d' 解析。
对账口径（和聚水潭比单量时）：聚水潭 orders 里 platform='美团' 混有手工单，只取 CHAR_LENGTH(order_no) IN (18,19)；并剔除 0 元行（祝福语/赠品）。实测 10-01~10-20 官方 18,252 单 vs 聚水潭 18,297 单，差 0.25%。