← 返回 Skill 列表
extension
分类: 数据与分析需要 API Key

海关提单买家情报提取(免费版)

零成本从海关提单里提取买家进口行为情报。用 ImportYeti 免费网页 + Crawlora 免费额度两条 ¥0 通道,完成实体消歧与同名异企闸门、跨通道交叉定级、FMC 持牌 OTI 名录判货代、8 角色分级、HS+品名双条件品类判定、时效衰减、按地区票数的来源国分析、个人进口商清洗,并对一份现成的公司名单批量补提单证据。当买不起或不愿买商业海关 API(ImportYeti 官方/腾道/Panjiva)时使用,也用于回答「这家公司到底有没有在进口、进口什么、跟谁进口、多近」。关键词:提单、BOL、海关数据、买家核实、进口证据、名单背书、外贸获客、lead verification、NVOCC、FMC OTI、货代识别、品类判定、CCPA。

person作者: user_6729c630hubcommunity

提单买方情报提取(Import-Bill Buyer Intel)

一句话:用 ¥0 的两条通道,把「这家公司是不是买家」变成「这家公司在什么时候、从谁那儿、买了什么、多少票」的可复核证据。 方法来自真实项目实测,包含数百次假阴性 / 假阳性的修正记录。

这是什么 / 不是什么(先对齐预期)

  • 是什么:一套买手洞察引擎与判据脚本 —— 方法、判据、管线架构, 以及证明这些判据没有失效的自检与负例测试。
  • 不是:不是全自动代运营成品。Bring Your Own Data & Keys —— 不含 API Key、代理池或预先抓好的行业数据;产出的是带 unknown 栏位的证据表, 不是替你跑完的业务。能对你的数据、按你的行业改判据,才是这套东西值钱的地方。

何时用

  • 要证明「这家公司真的在进口」,而不是「看起来像买家」
  • 不想付费买商业海关 API(腾道 3 万元起;ImportYeti 官方付费且无试用)
  • 手上有一份公司名单,要给它批量补一层提单证据(票数 / 来源国 / 品类命中 / 时效 / 供应商)
  • 需要能截图给客户或老板看的提单号级证据

不要拿来做什么

  • ❌ 判趋势(「这家正在把订单移出中国」)—— 那是配套技能 buyer-persona-outreach 的活。 本技能只产出事实切片;把两个时期的切片直接相减当结论,是这套方法踩过的最贵的一跤。
  • ❌ 判「哪家还有空位」 —— 「某国 0 票」不等于有空位,见 references/pitfalls.md 坑 P14。

三条不可协商的纪律

违反其一,产出物就该作废重写。它们不是风格建议。

  1. 缺字段 ≠ 取值为假。 拿不到就写 unknown,永不用默认值顶替。 「不在 FMC 名录」≠「不是货代」;「可见供应商里没有中国厂」≠「没有中国供应链」。
  2. 极端结果先怀疑判据,再怀疑世界。 跑出「0 家」「100% 命中」这类数字时, 第一个动作是拿 3 条已知答案的样本喂给分类器,而不是写结论。 一个把 11 家判成 0 家的分类器,比没有分类器更危险 —— 它会产出一条方向性的错误结论。
  3. 同一量有两条可得口径时,必须并列声明用了哪个,并加「一致或显式告警」的断言。 两个口径打架时,代码会静默挑错那个,而且不报错。

这套判据踩过的坑(节选 7 条)

下面每条都是实测撞出来的,不是推演的。 完整 27 条见 references/pitfalls.md(带 ⚡ 的会造成方向性错误结论,不是小瑕疵)。 之所以挑这 7 条摆在这里:它们最能说明这套判据的钱是花在哪儿的。

| # | 撞到什么 | 代价 | |---|---|---| | ⚡ P6 | 用 house 提单占比判货代:真实 DTC 品牌 95.83%,另一真实品牌 0.00% | 该指标根本不度量主体性质 ⇒ 已整体下架,改走 FMC 持牌 OTI 名录 | | ⚡ P9 | 泛化名(Moss / RES / Wesco)模糊匹配落到同名异企 | 返回的票数看着完全正常,静默污染整份结论 | | ⚡ P11 | 读 sup["name"],但调用点传的键是 supplier | 58 家全落同一分支,无告警、数字看着合理 | | ⚡ P13 | 单点 last_shipment_date 是 2026-03,看着很新 | 年分布 {2018:27, 2019:20, 2020:1, 2026:2} ⇒ 早已停业 | | ⚡ P14 | 某公司近期窗口该国 0 票,看着是空位 | 窗口里坐着他国 33 / 6 / 2 票 ⇒ 那是被占满 | | ⚡ P16 | suppliers[] 被上游硬截断在 7 条 | 53 家样本的最大值恒为 7,无一例外,且响应里没有任何截断标志 | | P4 | $15.4M 被纯数字正则解析成 15.4 | 差一百万倍,而且不报错 |

元教训:两个错误会互相掩盖。 词表漏判把数字变成 0,闸门错筛让 0 看起来「合理」—— 修一个查不出来,两个都得查。

标准流程

两条主线,先选对方向:

  • A. 核实单家 —— 已知一个公司名,验证它是否真在进口。
  • B. 名单批量背书(最常用)—— 已有一份名单,要给整体补证据层。

步骤 1|通道与凭据

先把 User-Agent、日期制式、错误映射按 references/channels.md 配好,再跑任何查询。 这一步配错会让后面所有数据静默失真。

步骤 2|实体消歧(最容易出错的一步,不要瞎取 companies[0])

查询阶梯三级递进(单一查询必然误判 not_found):显示名 → 法定名 → 品牌核心词 + Inc/LLC。

候选打分见 references/entity-and-tier.md:分数 < 0.55 ⇒ 判 ambiguous_needs_review,不要硬猜。

⚠️ 实体同一性是所有跨记录聚合的前置闸门。 名单里的泛化名(Moss / RES / Wesco) 会撞上同名异企,返回的票数看起来完全正常,却会静默污染整份结论。

步骤 3|跨通道交叉定级

≥2 个独立通道返回同一提单号 ⇒ 升 confirmed;单通道有明细 = probable(封顶); 无明细 = not_found(如实留痕,严禁臆造)。

自证一致性检查(极强):总票数 / 最近提单日 / 别名数量 / 首条提单号 应在 A、B 两通道逐项吻合。

步骤 4|角色判定:8 角色分级,不要按 kind 硬过滤

kind=supplier 里混着品牌境外分支、真第三方供应商、代收壳、自然人 ⇒ 见 references/entity-and-tier.md。

货代判定走 FMC 持牌 OTI 名录(https://www2.fmc.gov/oti/NVOCC.aspx), 绝不用 house 提单占比(该判据已实证证伪并整体下架,references/pitfalls.md 坑 P6 有完整差分证据)。 返回必须三态:在名录=True / 不在名录=None(unknown)/ 查询失败=unknown。

步骤 5|品类判定:HS + 品名双条件

这是整套方法里最贵的一节。只有 HS 码没有品名 ⇒ 不得计入本品证据,降为「结构件·待确认」。

词表分三档分开记账:特指短语 / 专用件双词 / 实测产品线词。 单字通用词(clamp / rail / hook / bracket / mount)永远只算「候选」, 必须凑成双词才有指向性,否则水管卡箍、窗帘轨都会被算成目标品。

细节见 references/product-gate.md。

步骤 6|来源国:用 region_breakdown 的票数,不要用可见供应商家数

suppliers[] 被上游硬截断在 7 条(降序),且响应里没有任何截断标志。 ⇒ 任何由它反推的供给侧结论,默认口径必须写成下界,且该声明无条件输出(不得挂在条件分支上)。

判「有没有某国供应链」用 region_breakdown 的该国票数(国家级聚合,不受 7 条上限影响)。 若出现「地区有该国票、可见名单无该国厂」⇒ 单列「票在、供应商未见」档 —— 这不是空位,而是截断的现场样本。

步骤 7|时效标注

每家公司必算时效:>24 个月 标 stale,结论措辞降为「曾进口」,不得表述为「正在进口」。

⚠️ 活跃度必须用分布判,不能用单点 last_shipment_date:取 recent_shipments 的年分布算近 24 个月票占比, 且锚点必须是今天,不能锚切片自己的最大日期(后者会让早已停业的公司算出「近 24 月占比 100%」)。

步骤 8|输出

每行一条记录,至少含:实体 / 匹配分 / 定级 / 总票数 / 最近票日 / 时效档 / 本品证据条数 / 该国票数 / 可见供应商 / 角色 / unknown 清单。

必须有一栏 unknown,把「本该有但没拿到的字段」列出来 —— 交付物里的沉默比错误更会误导读者。

合规(不可选项)

  • 地区字段经 JURISDICTION_LABEL 归一化为中国台湾 / 中国香港 / 中国澳门。 上游原始串可出现在匹配表的 key 里(必须匹配得上),但交付物与文档中不得复现错误表述。 统计上三者单列,不并入中国大陆份额。
  • 来源国三个口径必须并列:① 历史累计(不带日期 ⇒ 高估当前)② 近期·注册地 ③ 近期·实体关联。
  • 涉自然人一律做 PII 处理,见 references/discipline.md 的「B2B 实体 vs 自然人」原则。
  • API key 只从本地配置文件读取,不得硬编码进脚本,更不得随技能或交付物一起分发。 交付前跑一次密钥泄漏扫描。

参考资料(按需加载)

| 文件 | 什么时候读 | |---|---| | references/channels.md | 动手前必读:两条通道的入口、计费、User-Agent、日期制式、错误映射 | | references/entity-and-tier.md | 做实体消歧 / 同名闸门 / 角色分级 / 货代判定前 | | references/product-gate.md | 建品类词表、判本品证据前(后果最严重的一次误判在这里) | | references/pitfalls.md | 出结论前过一遍;也可按症状关键词 grep 定位 | | references/discipline.md | 写脚本 / 断言 / 交付物前的通用工程纪律 | | assets/seeds.example.yaml | 批量模式的买方种子配置模板 | | assets/evidence-row.schema.md | 单条证据的标准字段与取值口径 |

一条方法论(比任何具体判据都值钱)

先证据,后名单。 拿着一份「看起来像买家」的名单去补证据,会一路向名单的先验低头: 名单里一个真买家都没有时,十条证据路径每一条都会很尽职地报回「没有」, 而这份「判据缺陷」会被读成「市场事实」。反过来才对 —— 先让提单说话, 用「实际进口了本品的那批公司」反向定义名单,再用别的维度去解释它们。

那次的代价:先名单后证据 ⇒ 全批报出「本品证据 0 家」⇒ 据此推出「ICP 选错了」这条方向性结论。 修好词表后,同一批数据出 11 家。同一个世界,两个相反的结论。