20260916 数据分析方向　要不要做（分公司填写）

状态列读法：

• 可做 —— 数据源已核对，现在就能跑
• 需修正 —— 分析意图成立，但原来写的字段或口径被字段表推翻，按备注改
• 待打通 —— 依赖 O2 商品映射或 O11 单号映射，映射命中率验证前结论视为待确认
• 数据不足 —— 表存在、结构对，但行数太少（个位数到几十行），只能定性不能定量
• 不可做 —— 空表或字段已证伪，别立项

合计 25 组 188 条：可做 142 + 可做（样本口径）3 / 需修正 14 / 待打通 15 / 数据不足 8 / 不可做 6。

换句话说，真正能今天就开跑的是 145 条，另外 43 条要么先补数据、要么先打通映射、要么直接划掉。

按"先抢数据、再止血、后补账、最后建机制"排。同一批内可以并行，跨批不要跳。

一、阈值不写死。

所有"高/低/异常"的线，用本店自己的 P25 / P50 / P75 初始化，跑三个月再调。

Gemini 那两个外部阈值（0.5 元/包裹、0.35 元/单）本份不采用——不同件单价、不同包装方式的店，这两个数完全不可比。

二、归因不能加减。

推广报表口径、生意参谋口径、ERP 结算口径三套互斥。

同一笔成交在三套里都会出现，加起来就是重复计算。O5 的差额表是用来解释差异的，不是用来求和的。

三、ERP 是第三套口径，不是"正确答案"。

ERP 记的是实际发货结算，它和平台口径对不上是正常的（时间差、退款、未发货）。

不要用 ERP 去"纠正"生意参谋，只做差额说明。

四、空表和微表要显式标注，不能默认可用。

本份用五级状态列解决这件事。看到"数据不足"和"不可做"就别排期，先决定补不补数据。

五、样本不等于全局。

Claude 版把清捷单店 3 天 2,968 单的样本写成了全局前提（件单价 3.94 元、运费占比约一半）。

本份保留这些数字但标明出处。在全量重算之前，它们只是假设。

六、先算命中率再下结论。

O1 / O2 的映射没验证之前，所有跨系统的数字都带一个未知折扣。命中率本身就是第一个结论。

一、不做的分析方向

1. 定制与跨境相关——业务上不做，数据也没有
2. 行业大盘预测——手上只有本店数据，预测不了大盘
3. 用户画像标签体系——代发买家是商家不是消费者，人口属性标签没意义
4. 复杂的归因模型（如 Shapley）——三套口径都对不齐，谈不上多触点归因
5. 实时看板——采集是按日的，实时没有数据基础

二、六条【查库】证伪的边界（来自 DeepSeek 版，已实测）

三、三个被用错的字段

• orders.express_discount_amount 是净额法，已经从 order_amount 里扣掉了，再减一次就是重复扣
• order_items.cost_price 为 NULL 不等于 0，NULL 表示走出库移动加权成本
• skus.box_quantity 为空视为 1，不是"没有装箱概念"

1688 侧（SQLite data/datacenter.db）——业务数据全在 sycm_records 宽表，靠 data_type 区分、字段在 payload JSON 里：

-- 商品池三个数（必须限定终端，否则会把三个终端的行加在一起）
select json_extract(payload,'$.在线商品数'), json_extract(payload,'$.有访问商品数')
from sycm_records
where data_type='sycm_item_core_trend' and shop_code='qingjie'
  and stat_date='2026-09-14' and json_extract(payload,'$.终端')='全终端';

-- 本境在售商品数（302 行但只有 151 个 distinct）
select count(distinct json_extract(payload,'$.offer_id'))
from sycm_records
where data_type='work_goods_onsale_all' and shop_code='benjing';

-- 各数据源新鲜度（O12）
select data_type, shop_code, max(stat_date) from sycm_records group by 1,2;

ERP 侧（PostgreSQL，123.207.20.88 容器 erp-postgres，五个独立租户库 erp / erp_001 / erp_002 / erp_003 / erp_004，不能跨库 join）：

-- 空表与微表核查（做任何分析前先跑一遍）
select relname, n_live_tup from pg_stat_user_tables order by n_live_tup;

-- 所有经营口径的固定前缀
where is_padding_order = false

本份的核对方式：四份汇总里出现的每一个表名、行数、字段名、取值，都拿 1688_字段_完整.md（608 行）和 ERP_字段_完整.md（2,888 行）逐条比对。

对不上的降级为「需修正 / 数据不足 / 不可做」并写明原因，对得上的保留原描述。

没有一条是凭印象保留的。

DeepSeek汇总数据分析方向.md 与 GPT汇总数据分析方向.md 逐字相同，551 行里只差 8 行：

正文、条目编号、实测数字、SQL 示例全部一致。所以实际只有三份独立内容，

不要把它当成"两方独立验证过" —— 它们的错误也是同一份错误，不构成交叉印证。

下面这些表四份汇总都当成了可用事实源，实际不是。

这 6 条 Claude 版完全没有，但它们直接推翻了 Claude 版三个标为可做的条目：

上一版第一章「生意形态前提」列的这组数字：

订单中位金额 4.2 元、中位件数 1 件、件单价 3.94 元、询盘/成交 = 0.070、
405 个买家贡献 2968 单、前 20% 占 85.8%、最大单一买家占 14.6%、
订单来源淘宝 1162 / 小红书 577 / 抖音 472 / 京东 107

全部来自 trade_order，而 trade_order 只有清捷一家店、只有 2026-09-13 ~ 09-15 三天。

字段表原文标注：2,968 行 / 15 字段 / 仅清捷 / 三天 / 全库唯一带买家身份的表。

ERP 侧同期是 orders 787,164 行全历史、777 家店、12 个渠道。

所以这组数字的正确说法是：清捷店三天的样本特征，不是公司的经营形态。

对应修正：

• D1 的「前 20% 占 85.8%」保留，但标注为清捷 3 天口径，真集中度要用 ERP orders 按 customer_id 重算
• F3 的订单来源分布同上，全盘看 P6 / K1
• 「毛利率必须高于 54% 才不亏」是从 ROI 1.84 反推的，J1 做完当天作废
• 生意形态的定性结论（一件代发、不是批发、抬门槛等于赶客）仍然成立，不受样本量影响——它有业务侧独立佐证

物理上只有 6 张表，业务数据全压在 sycm_records 宽表，用 data_type 区分，字段在 payload JSON 里。

• 51 个数据集 / 1010 个字段 / 119,285 行，覆盖 清捷 / 花汇 / 华玲 / 本境
• 最大的几张：refund_list 35,009、sycm_flow_keyword 30,608、sycm_item_detail 25,076、

p4p_report_solution_item 4,247、trade_order 2,968

select json_extract(payload,'$.商品ID'), json_extract(payload,'$.消耗')
from sycm_records
where data_type='p4p_report_solution_item' and shop_code='qingjie'
  and stat_date between '2026-08-17' and '2026-09-15';

各表的时间窗差异极大，做日报前必须逐表确认：

同一套 ERP 的多租户部署，5 个库结构一致、数据独立，不能跨库 join。

143 张表 1917 字段，96 张有数据，47 张空表。

核心表：orders 787,164（九项成本 + 毛利）、inventory_ledger 917,569、

order_actual_costs 721,762、order_estimated_costs 787,129、alipay_bills 571,290、

finance_receivables 282,619、verification_pending_list 103,752、

after_sales_orders 6,925、combo_packs 7,109、customers 492、shops 777。

相减会算出负数，相加会把推广费算成两倍（这个坑实际踩过：把 p4p_report_daily_by_product

汇总表和三张商品级明细表加在了一起）。判断投放效果只走 A5 费用率 和 A6 基线对照 两条路。

跨库联查时先算三方匹配率，匹配率本身就是一个要盯的指标。

1688 侧同理：sycm_dom_site_factory（5 行，只有统计周期文字）、

sycm_dom_content_summary（7 行）、sycm_dom_flow_visitor（三维度不同行）需先补采集。