eMAG找新仓报价，仓商要整库买家明细：询价到底给到哪一步？

假设你刚给一家新仓商发完一句“想做eMAG订单履约，麻烦报价”，对方回得很快：可以，把最近几个月的订单明细发来，最好包含买家姓名、电话、完整收货地址、订单号，我先测配送区域和作业量。

eMAG新仓询价：匿名订单画像与仓配数据

先说明范围：这里说的“新仓”，是卖家拟合作的外部仓配服务商，不把eMAG自身的FBE与第三方仓询价混在一起。如果你讨论的是FBE，应该直接按对应官方方案和账号合同核实。

很多卖家卡住的地方就在这里。仓商要报价，当然需要数据；可“需要数据”不等于“需要整库买家”。

真正值得先做的，不是把姓名和电话删掉再发一遍，而是把询价阶段和正式履约阶段拆开。前者要回答的是“这批货有多大、送到哪里、峰值多高、退件有多少、有哪些异常作业”；后者才可能涉及某一笔订单到底送给谁、送到哪里、怎么联系。两个阶段用同一张订单明细表，既没有必要，也容易把数据边界一步跨过头。

先问清楚：仓商到底拿什么数据才能算出报价

一份合格的询价资料，应该像一张“业务体检表”，而不是买家通讯录。

先把服务范围写清楚。包括从哪里发货、准备覆盖哪些国家或地区、是家庭地址还是其他交付方式、退件回哪里、是否需要重新包装或质检。这里的“目的地”不需要先落到某一个人的门牌号，可以先按国家、州/省/大区，或者仓商自己的配送分区来统计。若仓商的报价体系必须按邮编分区，先让对方说明需要多细的邮编粒度，再决定是否需要进一步提供数据。

然后是订单量。至少给出一个明确的统计周期，例如最近90天，而不是一句“平均每月大概几千单”。周期内的订单总量、件数、每单件数或订单行数、月度变化，以及峰值日和峰值周，都应该能对上。

这里有个容易被忽略的细节：峰值要保留，不能只报日均。仓库真正需要安排人的时候，往往不是平均日，而是促销或某个异常高峰。如果过去90天有12,000个假设订单，平均每天约133单，但假设峰值日达到310单，那么仓商面对的是一个约2.3倍于日均的峰值，而不是“每天133单”的仓库。这个差异会直接影响拣货、打包、出库和交接班的能力配置。

商品也不要只给“平均重量”。报价通常至少会被包装后的长、宽、高、毛重和计费重影响，所以最好按区间给分布，同时保留尾部。比如，下面这个完全假设的90天样本里，70%的包裹不超过2kg，22.5%在2—5kg，7.5%超过5kg；再补一个P95包装尺寸和最大异常尺寸。这样仓商才能知道大部分订单长什么样，也知道那一小撮“大东西”是不是会把报价结构打穿。

为什么一定要留尾部？因为如果三档重量只用中点粗略估算，整体平均重量可能看起来只有约2kg，但那7.5%的重件仍然可能落入完全不同的处理和配送规则。大件、超长件、易碎件、含电池或需要特殊标签的商品，也可能不是按普通件处理。报价资料的价值就在于把这些“少数但贵”的订单单独拎出来。

目的地同样如此。假设12,000个订单中，70%来自A区、20%来自B区、10%来自C区，这种分布比一个“平均配送距离”有用得多。如果还有2%的订单属于偏远或额外配送区域，就单独报出来。仓商如果只看到平均距离，很容易把这2%藏进平均值；等真正出单后，偏远附加费才会从账单里冒出来。

退件不是一个百分比就结束了

仓商询价经常只问“退货率多少”。这个数字可以给，但必须先把分母说清楚。

例如，假设统计周期内有12,000个已发出订单，其中540个最终形成退回件，那么这里的退件率就是540÷12,000=4.5%。这是一个假设口径，实际业务中应以你和仓商约定的订单状态作为分母，不要把“申请退货”“已经寄回仓库”“退款完成”混在一起。

更重要的是，退件不是简单的540个包裹。仓商可能真正关心的是：其中多少只是原包装完整、扫码入库后重新上架；多少需要拆包检查；多少要重新包装、换标签；多少存在破损，需要拍照、隔离或等待卖家处理。若这几类作业差异明显，就按比例拆开。

同样的逻辑适用于异常订单。不要把“有特殊作业”写成一句话。把易碎、超大、需要组合装、换标、重新包装、质检、退件检测等项目分别给出占比或件数。仓商要的是作业类型，不是买家的身份。

一张最小询价画像，通常已经够用了

如果把前面的信息压缩成仓商真正用得上的最小集合，可以是这样一套：

第一组是范围。 发货地所在国家/区域、拟服务的目的地国家和大区、交付方式、退件回收地点、计划上线时间。

第二组是规模。 统计周期、订单数、商品件数、订单行数、平均订单件数、月度分布、峰值日、峰值周。若存在明显季节性，再标出旺季月份或活动周。

第三组是包裹。 包装后的重量分布、长宽高分布、P50/P95以及最大尺寸、计费重规则；如果商品在不同包装下差异很大，按包装类型拆开。

第四组是区域。 按国家、大区或仓商已有配送区间统计订单占比；偏远区、额外网络区、超出常规服务区的比例单独列，不要塞进平均数。

第五组是退件和特殊作业。 退件率及其分母、退件数量、需要检查/重新包装/换标的比例，以及大件、易碎、特殊标签等异常作业占比。

这套数据已经足够让仓商回答很多报价问题：需要多少仓内处理能力，普通件和异常件各占多少，尾程主要落在哪些区域，退件会产生多少额外作业。它回答的是“仓库要为你准备什么”，而不是“买家是谁”。

别把“去姓名”误当成“已经匿名”

这是这类询价里最容易掉进去的坑。

有些卖家会想：姓名、电话删掉就行，剩下订单号、完整邮编、下单时间、SKU、配送方式，总不能算买家资料吧？

不能这么简单理解。

数据是否还能识别一个人，不只看有没有姓名。一个很特殊的订单，加上非常精细的地址、时间、商品组合和其他字段，可能仍然可以把某个订单单独挑出来；如果仓商自己还有其他数据，原本看起来没有意义的字段组合也可能被重新关联。

所以，询价文件里最稳妥的做法不是“去掉姓名”，而是从源头上不生成买家级文件。让仓商拿到的是统计结果，而不是一行对应一个人、一行对应一笔订单的表。

例如，不要给“邮编1234的某人买了三件某SKU”，而是给“该配送区在统计周期内有1,860票，占总出库量15.5%”。不要给每个订单的精确下单时间，而是给每天或每周的订单量。不要给每个地址，而是给配送区域分布。不要给买家留言，而是统计“需要人工处理的特殊备注订单占比”。

这才是真正把询价问题变成了仓配问题。

如果仓商坚持要明细，先逐字段追问四件事

如果对方还是说“没有订单明细没法报价”，不必马上争论合不合规，也不必直接把文件发过去。把问题拆开，逐字段问。

第一问：这个字段具体拿来算什么？

如果对方说需要完整地址才能算偏远地区费用，可以继续问：是需要每一单完整地址，还是只需要邮编/配送区？如果只是为了分区报价，为什么不能先给各区间的订单数量？如果对方要手机号，是用于报价模型，还是因为已经进入实际派送阶段？这两个答案完全不同。

第二问：谁会收到？

不要只听“我们仓库”。确认实际接收的法律主体、负责报价的团队、后续是否进入仓储系统、运输系统、客服系统，是否还有外包商或分包处理方。仓商公司名、存储系统、实际访问角色，至少要能对应起来。

第三问：放在哪里、留多久？

询价文件是否会进入报价系统、邮件附件、共享网盘、CRM或测试环境？报价结束后是否删除？如果以后不合作，文件是不是还会保留？如果对方说“我们都这么存”，这不是答案；你要的是这批数据具体怎么存、谁能访问、何时删除。

第四问：正式履约的合同和数据路径在哪里？

如果已经进入实际履约，仓商可能确实需要收件人姓名、地址、电话等字段。但这时讨论的是正式业务的数据处理安排，不再是询价。要看双方合同、数据处理附件或其他适用文件如何规定处理目的、角色、权限、分包和跨境传输。不能因为“以后肯定要发货”就倒推“现在可以先拿到完整买家表”。

特别注意：询价和正式履约，往往不是同一条数据流

假设你最终选中仓商。仓库需要通过系统拿到某一笔订单的收件信息，这可能是实际履约不可缺少的数据流。

但询价阶段只是回答“这家仓库能不能按我的业务量和区域报价”。如果这个问题用匿名汇总数据已经能回答，就没有理由提前把买家级数据送进去。

更现实一点说，卖家应该把整个数据流画成两条线。

第一条是报价线：卖家 → 汇总数据 → 仓商报价人员 → 报价系统。这里尽量只放订单量、目的地区间、尺寸重量、峰值、退件和特殊作业。

第二条是履约线：平台/卖家系统 → 实际履约系统 → 仓库/承运商 → 买家。这里才讨论具体订单需要哪些字段，以及这些字段依据什么合同和授权被处理。

两条线越早分开，后面越容易管理。最怕的是为了让报价快一点，直接把履约线上的整张订单表扔给报价人员，然后再想办法解释“这些数据只是临时报价”。

别拿平台页面替代这次数据流的核实

就这次eMAG仓商询价，最容易出现的误区是：平台后台能看到某个字段，于是默认这个字段也可以直接导出给第三方。

这两件事没有必然关系。

平台订单处理、物流、退件本来就可能涉及不同角色和不同系统。仓商报价时要知道的是你的业务规模和作业特征；真正进入履约后，某些订单字段才可能成为发货所必需的数据。不要用“以后肯定要发货”给“现在先把整库给出去”找理由。

同样，也不要拿一份平台隐私政策就替代你和仓商之间的数据处理安排。真正影响这次数据流的，是当前账号适用的合同、数据条款、履约方案、接口和实际接收主体。如果这些文件或条件当前没有拿到，就明确标成“待核”，不要靠公开网页猜。

仓商说自己做过很多eMAG订单，可以说明他熟悉业务；它不能自动证明对你这批具体数据的接收、存储、分包和跨境路径都已经得到适用的合同安排。

如果涉及跨境，更不能把“仓库在海外”当成自动合规

对于中国卖家，这一步尤其容易被忽略。

假设卖家在中国，买家在欧盟，仓商却把数据存到另一个国家的云服务里，或者报价文件又被同步到境外团队。此时就不能只问“仓商是不是欧洲公司”，而要把数据从哪里来、到哪里去、谁在处理、谁能访问、有没有再传输一路问清楚。

欧盟GDPR的基本原则包括数据最小化和存储期限限制；如果由处理者代表控制者处理个人数据，通常需要相应的合同或法律安排来规定处理的对象、期限、性质、目的、数据类型、数据主体类别以及双方权利义务；如果发生向第三国的个人数据传输，还要进一步核对适用的跨境传输机制和保障条件。

这里最关键的一点不是背条款编号，而是别把几个完全不同的概念混在一起：

“仓商是第三方”不等于“仓商一定不能处理数据”；

“对方签了保密协议”也不等于“所有个人数据处理安排都已经完成”；

“把姓名换成客户001”不等于“数据已经匿名”；

“数据最终要用于发货”也不等于“询价阶段就可以先拿到完整买家表”。

真正需要核实的是具体数据流和具体角色。

给仓商的第一版询价回复，可以很简单

假设现在还处于纯询价阶段，可以先给对方这样一份匿名业务画像：

> 本次为报价阶段，暂不提供买家姓名、电话、邮箱、完整收货地址、订单号及订单备注等买家级信息。 > > 统计周期为最近90天。假设订单量12,000票，日均约133票，峰值日310票；目的地按国家/大区汇总，分别给出订单量及占比；包裹按包装后重量和尺寸区间统计，并提供P95及最大异常尺寸；退件率按已发出订单为分母计算，并拆分需要检查、重新包装或换标的比例；另行列出大件、易碎及其他特殊作业占比。 > > 请据此先提供仓储、拣配、出库、尾程和退件处理的报价口径。若其中某一项报价必须使用订单级字段，请逐项说明字段、用途、所需粒度、接收主体、存储位置/期限、是否涉及分包及跨境传输，以及正式履约所依据的数据处理文件或合同安排。

这段话的作用不是把仓商挡在门外，而是逼着报价需求变得具体。

如果对方回复“只需要邮编”，事情就简单了；如果他说“必须完整地址”，那就继续追问为什么。很多所谓“报价必须要明细”，拆开之后其实只是一个区域计价问题，完全可以先用分区统计解决。

什么时候才值得进入订单级数据

等到报价已经足够明确，双方准备进入正式履约，再把问题重新问一遍。

这时候需要确认的不是“仓商愿不愿意保密”，而是：具体哪一类订单数据必须进入仓库系统；哪些字段由谁提供；仓库是以什么角色处理；是否允许使用分包商；分包商是谁；数据保存多久；如何删除或返还；系统放在哪里；谁有访问权限；如果团队在不同国家访问，跨境传输怎么处理。

如果实际派送只需要收件人姓名、地址和电话，就不要顺手把买家历史购买记录、营销标签、支付信息、客服聊天记录等一并交出去。能用一笔订单完成履约，就没必要把一个买家的完整画像带进仓库系统。

反过来，如果仓商为了处理偏远地区报价，确实需要某种更细的地址粒度，也可以让对方先说明其计价规则，再由卖家在自己的环境里把原始数据转换成区域统计结果。这样做的核心不是“永远不提供邮编”，而是让原始买家数据尽可能少离开原来的控制范围。

卖家真正应该准备的，不是一张“买家明细表”

如果今天就要给eMAG新仓询价，最实用的动作不是打开订单导出按钮，而是先建一张只服务于报价的匿名数据表。

里面有：统计周期、订单量、件数、订单行数、峰值日/周、目的地区间及占比、包装后重量尺寸分布、P95和最大值、偏远区占比、退件率及分母、退件处理类型、特殊作业占比，以及拟采用的交付和退件范围。

里面没有：姓名、手机号、邮箱、完整地址、订单号、支付信息、客户账号、客服原话和任何不影响报价的买家属性。

如果这张表已经足够让仓商报价，那就停在这里。

如果还不够，就不要用“仓商要求”四个字结束讨论，而是继续追问：缺的是哪个字段，它到底解决哪个报价问题？

这个问题问清楚以后，eMAG仓配询价就从“要不要把整库买家资料发出去”，变成了一个更容易管理的业务动作：先用最少的数据把价格算出来，等真正需要履约时，再按实际合同和数据流开放真正需要的字段。

如果卖家同时在准备其他欧洲本土平台的开店，ESG跨境已有的官方合作平台入驻支持、前置资料预审和专席对接，可以把平台准入资料与仓配询价分开处理；而eMAG这次的仓商询价，最值得先做的，仍然是把一张买家明细表改造成一张匿名的仓配业务画像。

仓商真正需要知道的是你的订单长什么样，不是你的买家是谁。

声明：本文系作者独立观点，不代表ESG跨境立场。文中涉及的平台规则、费率及出海政策具有时效性，实际运营请以平台官方最新公布为准。如有版权争议、内容勘误或业务交流，欢迎随时与我们联系。