CDON 中文知识库（超详细手册版）

搜索范围为本页详细正文内容。

这一章专门解决你刚才最不满意的点：如果一个模块覆盖了 25 篇文章，那就不能只给 4 张卡片，而应该把“怎么上架、有哪些字段、怎么填、有哪些限制”完整讲明白。

1.1 先理解 CDON 现在的商品结构

CDON 新的平台思路里，商品不是传统意义上“一个 product 包含很多零散字段”那么简单。官方已经明确转向 Product-Article Model。更直白地说：

• Article 是真正对外卖的销售单元，它自己有标题、描述、图片、价格、库存等信息。
• Product 更多是一个“把多个 article 关联起来”的壳，用来做变体聚合。

所以你不能再用老思维理解成“我建一个商品，再附几个 SKU 完事”。CDON 的新逻辑更强调 article 自身的完整性。

1.2 CDON 支持哪些上架方式

根据官方资料，CDON 至少支持以下几种方式：

1. Merchant Center 手工创建：适合 SKU 少、想先看清前后台逻辑的新手。
2. CSV 导入：适合简单商品批量导入，但有明显限制。
3. XML 文件导入：适合老的接口式批量处理，更结构化。
4. API / 自研集成 / 集成伙伴：适合 SKU 多、长期规模化经营。

如果你是完全新手，最合理的顺序通常是：先手工建少量商品 → 看懂字段和展示 → 再决定 CSV / XML / API。

1.3 Merchant Center 手工创建商品时，字段到底要填什么

官方文章《Using CDON Merchant Center to manually create articles》已经明确列出了一批核心字段。我这里直接翻译成中文好理解的版本。

1.4 类目不是随便选的

官方《Categorizing Products》明确说过：类目错，不只是影响曝光，还会影响税务信息、过滤展示和用户查找结果。也就是说，类目错不仅卖不动，还可能造成更严重的后果。

手工建商品时，虽然可以勾选 1–5 个类目，但并不代表你可以乱堆。官方说明里甚至强调：如果你已经选了下层类目，就没必要再重复选上层类目，因为层级关系会自动继承。

1.5 标题、详情页和图片为什么不能糊弄

官方《Product Detail Page Guidelines》讲得很直白：详情页如果信息不完整或不清晰，会导致以下后果：

• 客户买错
• 退货增加
• 客户跑去别处找信息，导致加购流失
• 搜索可见性变差

官方点名的常见问题包括：

• 缺规格参数
• 图片少或者图片差
• 描述重复、敷衍、像垃圾文案
• 缺品牌或 GTIN
• 缺兼容性说明
• 缺保修或退货信息

换成中国卖家更容易懂的话：你别把详情页当成“传个名字和一张图就能开卖”的地方。CDON 和 Google 这种平台会把这些信息质量直接转化成可见性、信任感和售后风险。

1.6 图片要求比很多人以为的更具体

官方《Product Image Guidelines》已经给出了非常明确的规则：

• 最低分辨率：600 × 600，低于这个会被自动拒绝。
• 背景必须是白底或透明底。
• 不能带水印、logo、网址、边框、文案文字。
• 只能用 PNG / JPEG。
• 图片必须真实反映你卖的商品，不能颜色、材质、图案不一致。
• 商品要尽量占画面的 75%–90%。
• 如果是组合装，图里要把所有商品展示出来。
• 如果卖的是同款多件装，可以展示单件，但不能误导。

还有一条很容易出事：版权责任在你自己。官方明确要求你必须拥有图片版权，或者至少有明确商业使用授权。

1.7 CSV 导入的限制，新手非常容易踩坑

这部分是你刚才点得最对的地方之一。官方《Upload Products (CSV Import)》不是只说“可以用 CSV”，而是有很关键的限制：

• CSV 不支持变体商品。
• 如果强行用 CSV 导变体，官方直接警告可能造成严重错误。
• 多市场商品数据必须放在同一个 CSV 文件里，不能每个市场分一个文件。
• 如果你用 Excel，建议导出成 UTF-8 编码。

这意味着什么？意味着 CSV 更适合简单、非变体、规则比较统一的商品。SKU 多、结构复杂、变体多的卖家，不要把 CSV 当成长期方案。

1.8 XML 导入为什么更结构化，但也更严

官方《Create/Update Products (XML Files)》已经说得非常直接：要创建一个完整商品，你需要 4 类 XML 文件：

1. Product
2. Price
3. Availability
4. Media

而且每个文件都不能超过 28.6 MB。这说明 XML 方式不是“随便拼个字段”就行，而是标准化、分块明确的结构化导入。

1.9 Product data type：为什么说这不是“改单字段”的接口

官方对 Product data type 的解释非常重要：Product 是完整定义。意思是，你每次送进去的 product 数据，必须足够完整地重新描述这个商品。你不能只改单个标题，然后别的东西都不带。

官方甚至直接举了类似意思的例子：如果你只更新 title，而没有带类目和变体相关数据，商品会被重新定义成一个信息更少的残缺版本。

1.10 Identity：哪些标识必须满足

官方《Product Identities》里，对 identity 的要求很具体：

• id 必填
• GTIN 或 MPN 至少要有一个
• model product 和每个 variation 都必须有各自唯一 id
• product id 不区分大小写
• id 长度限制为 1–40 个字符
• 允许字符有限，不是任意符号都能用
• 如果填 GTIN，长度必须是 8 / 12 / 13 / 14 位数字

这部分如果一开始没建对，后面不仅导入麻烦，变体、图片、价格、库存的关联也会全乱。

1.11 Price：价格不是只填一个数字

官方《Price data type》明确说明：

• 每个销售市场都要有价格
• 价格必须含 VAT
• sale price 不能高于 original price
• 还要符合平台允许的运费档位

这意味着如果你卖多个市场，不是简单“统一一个价格”就结束，而是要按市场和税务逻辑来处理。

1.12 Availability：库存、状态、交期怎么影响能不能卖

官方《Availability data type》里，讲得很细：

• 要设置库存、状态、交期区间
• min 不能大于 max
• 状态如果是 offline，商品就不能买
• 如果库存大于 0 且发售日期已到，商品可买
• 如果库存为 0 且发售日期已到，商品不可买，但可能允许订阅到货提醒
• 如果发售日期在未来，商品属于预约 / 未来可售逻辑

简单说，商品能不能卖，不只是“有库存”这一件事决定，而是至少看：Status + Stock + Release Date 这三个组合。

1.13 Media：图片要求不仅是“有主图就行”

官方《Media data type》对图片结构要求也很明确：

• 每个商品必须恰好 1 张主图
• 附图可选
• 最多 10 张图
• 变体商品可以给主商品和变体分别配图
• 如果是双维变体，图片展示还有“主导属性”的逻辑，不是随便切换

1.14 给中文新手的上架建议顺序

1. 先确认商品可卖、合规
2. 再确认类目
3. 再确定 identity（SKU / id / GTIN / MPN）
4. 再补标题、描述、属性、品牌
5. 再配价格与 VAT
6. 再配库存、状态、交期
7. 最后补图和变体逻辑
8. 先拿少量 SKU 验证，再批量导入

这一章解决另一个你明确指出的硬缺口：回款周期不是“每月两次”一句话就结束，而是要讲清楚什么时候打、为什么没打、哪张表看什么、为什么销售额和到账金额对不上。

2.1 CDON 标准回款频率

官方《Payment Frequency》和《Receiving Your Payment》都说明：CDON 通常是每月两次付款。这点是基础规则。

而《Payment Report》进一步补充了更具体的时间点：通常会有两次 payment files，常见是每月 14 日和 28 日。

2.2 第一笔付款不是无条件打

这里很多新手会误会。官方明确说：第一笔付款只有当你自上次付款后的销售额达到以下门槛时才会发生：

• 3000 SEK
• 3000 NOK
• 3000 DKK
• 或者 300 EUR

如果没达到门槛，不代表钱没了，而是这部分销售额通常会并入第二笔付款。

2.3 第二笔付款为什么更稳定

官方写得很清楚：第二笔付款不受最低销售额门槛限制。也就是说，就算你这一段销售额不大，第二次付款仍会走流程。

2.4 为什么有时候回款会被延后

官方几篇文章对这个问题给了不同口径，但核心意思一致：交期过长、履约表现差、违反 SLA 或条款，都可能导致回款顺延或暂缓。

• 有的文章写：如果 delivery time 是 14 天或以上，平台可能延后一个付款周期。
• 另一些文章写：如果 delivery time 是 11 天或以上，也可能顺延。

你不需要纠结 11 还是 14 这个文本差异，实操上你只要记住：交期设得长、履约做得差，会增加延后付款风险。

2.5 Overview Of The Payment：适合看整体，不适合查细节

官方说得很明白：这个视角适合看总体的 payment overview。你能看到：

• 总销售额
• 总费用
• 整体结算情况

它适合做“大盘判断”，但不适合你去追某个订单为什么多 10 块、少 20 块。

2.6 Settlement Report：看这一期平台扣了什么

官方《Settlement Report》说得比较直：这张表让你看这个付款周期里：

• 你卖了多少
• 平台收了多少佣金
• 平台收了多少服务费

所以它更像财务总览，不是逐订单细账。

2.7 Payment Report：真正查订单级明细要看它

如果你想知道“为什么这笔订单到账是这个数”，官方建议看 Payment Report。因为它是订单级别的明细。

官方还补充了一个很重要的付款结构：

• 第一份 payment file：通常覆盖上次付款后到上个月末的交易
• 低于 3000 SEK 门槛的金额，会并到第二次付款
• 第二份 payment file：处理到第二次付款节点时的销售额，不受金额门槛限制

2.8 The Payment File：哪些字段最重要

官方《The Payment File》对字段解释非常实用，这部分是很多中文卖家最缺的内容。

• Column K – Invoiced amount：客户应付金额
• Column L – Marketplace discount：如果客户用了平台优惠券，差额会显示在这
• Column M – Sales amount：平台应付给商家的商品销售金额基础值
• Column N – Commission：平台佣金
• Column O – VAT percentage：税率
• Column P：对应税额相关金额
• Column Q：多币种筛选时有帮助
• 第三个 sheet：能看服务费细项，以及这些费用挂在哪些订单上

官方还特别提醒：有些行会是负数，通常和退货、退款有关。

2.9 为什么销售额和到账金额经常对不上

这是很多人最困惑的点。官方已经在多篇文章里给出了答案，常见原因有：

• 客户用了平台折扣码
• 你参与了 campaign discount
• 平台扣了 commission 和 service fee
• 订单发生了退款或退货
• 结算统计周期不同

所以“订单显示卖了 100”不等于“银行一定到账 100”。

2.10 新手对账时最合理的顺序

1. 先看本期 Settlement Report，确认总体销售、佣金、服务费
2. 再看 Payment Report，拆到订单级别
3. 再查 Payment File 字段，把 discount、commission、VAT、退款拆开
4. 最后再核对银行到账

这一章把订单从进来到发货完成的关键规则讲清楚，避免你在履约上踩坑。CDON 对这部分非常敏感，因为这直接影响客户体验和平台绩效。

3.1 订单不是“有空再处理”

官方《Fulfillment Timeframes & Order Handling》明确写到：每个订单都必须在 SLA 下被处理。这里最关键的一条是：

• 订单应在 72 个工作小时内处理

如果你没有在承诺时间内发货，客户可以发起 missing 问题，这会直接影响你的绩效。

3.2 最长交付时间还有上限

官方在该文里还提到，从 2024-10-21 开始，普通商品的最大 delivery time 最高为 10 个工作日，预售商品除外。

这意味着你不能无限拉长交期来给自己留余地。

3.3 订单状态要看懂

老平台资料里常见状态包括：

• Pending：未处理订单
• Awaiting payment：已发货但平台尚未收妥客户付款
• Cancelled：已取消，不应发货
• Invoiced：客户已收货，将进入付款给商家的阶段

新平台《Order Handling & Fulfillment》则给出另一套更流程化的状态：

• CREATED：新订单，等待你处理
• ACCEPTED：已接受订单（仅部分商家可用此状态）
• FULFILLED：已发货
• NOT_FULFILLED：已取消 / 未履约

3.4 手工履约时实际怎么做

如果你是手工商家，Merchant Center 里基本流程是：

1. 进入 Orders
2. 查看订单商品、数量、价格、收货地址
3. 注意 Fulfillment Deadline
4. 确认发货后点击 FULFILL
5. 选择承运商，填写追踪号
6. 客户会收到发货 / 追踪通知

如果需要，你还可以先生成 delivery note。

3.5 API 履约和手工履约，本质规则一样

官方强调：无论你是 Merchant Center 手工处理，还是通过 API 集成处理，规则和截止时间是一样的。区别只是操作方式不同。

3.6 Carrier 和 Tracking ID 现在已经不是“可填可不填”

官方《Delivery Policy - Carrier and Tracking ID》讲得很明确：从 2025-10-01 起，除特定例外情况外，履约时必须填写承运商名称和追踪号。

唯一例外是：

• 北欧本地配送
• 订单金额低于 300 SEK / NOK / DKK 或 30 EUR

除此之外，carrier 和 tracking 基本都要有。

3.7 承运商不是你想填谁就填谁

CDON 采用白名单承运商体系。也就是说，平台只认可它白名单里的承运商。如果你用不在名单里的 carrier，未来可能直接履约失败。

官方列出的白名单里包括 PostNord、DHL、DB Schenker、Budbee、Instabox、GLS、DPD、Posti、Posten Bring 等。

3.8 追踪体验为什么影响绩效

官方《Tracking & Delivery Communication》强调得很清楚：客户不仅要“包裹在路上”，还要“知道包裹在路上”。

• 追踪号要在商品离开仓库时就能用
• 承运商最好能给客户发短信通知
• CDON 不会把客户邮箱给你，所以很多通知依赖手机号
• 手机号要带国家代码，比如 +46 这种格式

如果这些链路没做好，客户就容易发起“包裹去哪了”的问题，即使实际上货已经发出。

3.9 交期设置不能乱写

官方《Tracking & Delivery Communication》还说了一条很重要的经验规则：

• 交期应按国家分别设置
• min 和 max 的差值不要超过 3 天

这其实就是在防止卖家给一个过于模糊的交付承诺，导致客户心理预期混乱。

3.10 退货逻辑的最基础流程

官方《Returns》里给了几个基本场景：

• 如果订单还没发：可以取消对应行
• 如果订单已经发：可以建议客户拒收，让包裹自动退回
• 如果客户已收货：客户可按规则退回，你收到后再做退款 / 标记 returned
• 如果你提供付费预付回邮标签，必须事先告知客户费用

这说明退货不是一句“客户自己寄回来”就结束，后台处理动作和费用告知都要匹配。