同时做 Shopee 和 Lazada 的卖家,资料管理翻车通常不是因为资料太多,而是因为两个平台的字段名、图片规格、类目结构长得太像。像到你以为可以直接复制,但每次复制都会踩到一两个不一样的地方:Shopee 的主图要求 1:1 比例且部分类目要求白底,Lazada 的主图尺寸要求和信息图规则又是另一套;同一个产品在两个平台的类目路径可能完全不同;SKU 编码你在 Shopee 用了一套,到 Lazada 又随手编了一套,一个月后自己都对不上。
一个运营团队同时管 3 个 Shopee 站点(马来/泰国/菲律宾)和 2 个 Lazada 站点(马来/泰国),上架初期图省事把 Shopee 的 listing 直接搬到 Lazada,结果第一周就有 4 个 SKU 的图片被 Lazada 审核打回,2 个产品因为类目选错导致搜索排名归零。后来他们花了三天时间重新整理资料体系,之后再也没出过类似问题。这套方法以下完整拆解。

Shopee 和 Lazada 后台资料到底差在哪
两个平台 80% 的字段看起来一样,但剩下 20% 的差异足以让你每次上架都踩坑。 先把关键差异摸清楚,再动手整理。
| 维度 | Shopee | Lazada |
|---|---|---|
| 主图尺寸 | 最低 500×500px,推荐 1000×1000px,1:1 比例 | 最低 330×330px,推荐 800×800px,部分类目允许非正方形 |
| 主图规格 | 部分类目要求纯白底,不允许拼图 | 允许信息图(标注卖点),但有文字占比限制 |
| 产品标题字符数 | 马来/泰国/菲律宾上限不同,通常 100-120 字符 | 通常上限约 255 字符,但建议控制在 80 字符以内 |
| SKU 编码 | 平台自动生成 + 卖家可自定义,无强制格式 | 卖家自定义,同一店铺内不可重复 |
| 类目结构 | 三级或四级类目,各站点类目树差异较大 | 统一类目树,各站点差异较小 |
| 变体设置 | 最多 2 层变体(如颜色+尺寸) | 最多 2 层变体,但变体命名规范更严格 |
| 物流模板 | 按站点配置,需逐站设置 | 统一物流合作伙伴体系,配置相对集中 |
| 促销工具 | 闪购、关注礼、优惠券等,各站点入口不同 | 促销活动集中在卖家中心,入口统一 |
这张表的实际用法:每次上新品时,先核对这 8 个维度有没有按平台分别处理,而不是默认”和上次一样”。
先搭框架:按用途把资料分成四类再动手
整理资料不是把文件堆进文件夹,而是先确定分类逻辑,再往里放东西。 不管你有 3 个店还是 30 个店,后台资料按用途只分四类:
| 类别 | 包含什么 | 更新频率 |
|---|---|---|
| 产品资料 | SKU 底表、标题、描述、属性参数、价格 | 每次上新/改价时 |
| 视觉素材 | 主图、详情图、视频、A+ 页面素材 | 每次上新/换季/活动时 |
| 店铺配置 | 物流模板、退货政策、自动回复话术、店铺装修 | 每月或每季度 |
| 账号凭证 | 登录账号密码、支付账号、API 密钥、2FA 信息 | 低频但极重要 |
四类资料的管理原则不同:产品资料追求的是跨平台统一底表、按平台分发;视觉素材追求的是命名规范、按平台按规格存储;店铺配置追求的是模板化和版本记录;账号凭证追求的是安全隔离、权限可控。搞混管理原则比搞混文件本身更危险。
产品资料的统一底表怎么建
一份底表管所有平台,按平台分列差异字段,不要为每个平台单独维护一份表格。 单独维护的结果是改了一个地方忘了改另一个,三个月后五份表格五个版本,没人知道哪个是最新的。
统一底表的核心字段结构:
| 字段 | 说明 | 是否跨平台通用 |
|---|---|---|
| 内部 SKU 编码 | 你自己的编码体系,全平台统一 | ✅ 通用 |
| 产品名称(中文) | 内部管理用 | ✅ 通用 |
| Shopee 标题 | 按 Shopee 标题规范填写 | ❌ 平台专属 |
| Lazada 标题 | 按 Lazada 标题规范填写 | ❌ 平台专属 |
| 核心属性 | 材质/重量/尺寸等 | ✅ 通用 |
| Shopee 类目路径 | 该产品在 Shopee 的类目 | ❌ 平台专属 |
| Lazada 类目路径 | 该产品在 Lazada 的类目 | ❌ 平台专属 |
| 采购价 | 成本 | ✅ 通用 |
| Shopee 售价 | 各站点可能不同 | ❌ 平台+站点专属 |
| Lazada 售价 | 各站点可能不同 | ❌ 平台+站点专属 |
| 主图文件名 | 指向素材库的文件名 | ❌ 按平台规格分 |
| 上架状态 | 各平台各站点的上架状态 | ❌ 平台+站点专属 |
内部 SKU 编码是整张底表的锚点。 建议用”品类缩写-序号-变体代码”的格式,例如 PH-0023-BK-M(手机壳第 23 款黑色 M 号)。这个编码在所有平台、所有站点保持一致,是你和供应商、仓库、财务对账的唯一标识。Shopee 和 Lazada 各自平台内的 SKU 编码可以不同,但都必须能映射回这个内部编码。
回到那个五店团队的案例:他们最开始没有统一底表,每个站点的运营各维护一份 Excel,三个月后同一款产品在 Shopee 马来站叫 SKU-A01,在 Lazada 泰国站叫 TH-001,仓库发货时根本对不上。后来统一用一份 Google Sheet 底表,所有人在同一份表上操作,按平台分列填写差异字段,对账时间从每周 3 小时降到 40 分钟。
图片素材的命名和存储规则
图片管理的核心问题不是找不到图,而是找到了但不确定这张图是给哪个平台哪个站点用的。 一张图改了尺寸、加了文字、换了背景之后存了五个版本,文件名全叫 product_01_final_v2_new.jpg,谁都分不清。
命名规则建议(固定格式,全团队统一):
{内部SKU}_{平台}_{站点}_{图片类型}_{序号}.{格式}
示例:
PH-0023-BK_shopee_my_main_01.jpg(手机壳黑色款 Shopee 马来站主图第 1 张)PH-0023-BK_lazada_th_detail_03.jpg(同款 Lazada 泰国站详情图第 3 张)PH-0023-BK_base_photo_01.png(原始产品照片,未裁剪未加工)
文件夹结构建议按”产品 → 平台 → 站点”三层:
/产品素材库/PH-0023-BK/base(原始素材)/shopee/my(马来)/th(泰国)/ph(菲律宾)/lazada/my/th/PH-0024-WH/...
这套结构的好处是,当你需要批量替换某个平台某个站点的主图时,直接进到对应文件夹,不用在几百张图片里肉眼筛选。
有一种反对意见是:搞这么多文件夹太麻烦了,产品少的时候没必要。确实,如果你只有 5 个 SKU、2 个站点,一个文件夹平铺也能找到。但产品超过 20 个、站点超过 3 个的时候,没有命名规则的素材库会变成灾难。这个临界点来得比多数人预想的快。
账号密码和店铺配置的管理方法
账号凭证是四类资料中数量最少但风险最高的一类。 一个密码泄露可能导致店铺被盗,一个 API 密钥暴露可能导致数据被抓取。管理原则只有一条:操作者能用,但不需要看到明文。
按优先级处理:
| 凭证类型 | 管理方式 | 禁止做法 |
|---|---|---|
| 店铺登录密码 | 密码管理工具或浏览器自动填入,操作者无需知道明文 | 在微信群/文档里明文共享 |
| 支付账号 | 仅财务角色可见,其他角色通过授权使用 | 运营人员直接持有支付密码 |
| API 密钥 | 存储在安全位置,按项目授权调用 | 硬编码在公开代码或共享文档里 |
| 2FA 验证信息 | 绑定到工具自动填入,不在人之间传递 | 验证码截图发群里 |
店铺配置(物流模板、退货政策、自动回复等)建议每个站点维护一份配置文档,记录当前生效的设置和上次修改时间。不需要多复杂,一个表格就够:
| 配置项 | Shopee 马来 | Shopee 泰国 | Lazada 马来 | 最后更新 |
|---|---|---|---|---|
| 物流模板 | J&T / Shopee Express | Flash / Kerry | LEX / J&T | 2026-06 |
| 退货政策 | 7 天无理由 | 7 天(需未拆封) | 14 天 | 2026-05 |
| 自动回复话术 | 版本 v3 | 版本 v2 | 版本 v3 | 2026-07 |
这份表的作用是:当某个站点的退货率突然上升时,你能立刻查到这个站点现在用的是什么退货政策、什么时候改过、和其他站点有什么不同。
整理过程中最容易出错的四件事
第一,把 Shopee 的图直接传到 Lazada。 Shopee 部分类目要求白底主图,而 Lazada 允许甚至鼓励信息图(标注卖点文字)。如果你在 Shopee 费力做了白底图,直接搬到 Lazada 就浪费了 Lazada 允许信息图的优势;反过来,把 Lazada 的信息图传到 Shopee 可能直接被审核打回。
第二,SKU 编码跨平台不统一。 上文已经强调过:如果 Shopee 用一套编码、Lazada 用另一套,仓库发货和财务对账就会出问题。统一内部 SKU 编码是底线。
第三,改了一个平台的价格忘了改另一个。 尤其是参加平台促销活动时,Shopee 降了价,Lazada 忘了同步,买家跨平台比价后投诉。解决方法是:任何价格变动必须回到统一底表操作,底表上改完后按平台分发。
第四,多人操作时不知道谁改了什么。 一个人在 Shopee 后台改了产品描述,另一个人不知道,在 Lazada 上还在用旧版描述。这个问题靠沟通纪律能缓解,但根治需要有操作记录可追溯。
多平台多店铺的账号环境怎么配
Shopee 和 Lazada 同时运营,最容易忽略的问题不是资料混乱,而是登录环境混乱。 5 个店铺用同一台电脑同一个浏览器轮流登录,平台看到的是同一个设备指纹和 IP 在多个卖家账号之间切换。Shopee 和 Lazada 都有多店关联检测机制,这种登录模式本身就是风险信号。
环境隔离的标准做法是:每个店铺在独立的浏览器容器里运行,绑定独立的 IP 出口,店铺之间的 Cookie 和指纹参数互不共享。飞跨浏览器的做法是把每个店铺作为一个独立工作单元,容器内运行时平台看到的始终是同一台独立设备在固定位置访问,而不是一台共享电脑在多个店铺之间跳转。飞跨内置 Shopee、Lazada 等 20+ 跨境平台的卖家后台直达入口,每个平台下含 20+ 站点直链,不需要先打开首页再手动切换站点。
环境隔离配好之后,资料管理的安全底座才算搭完:产品资料靠统一底表管、视觉素材靠命名规则管、店铺配置靠版本记录管、账号凭证和登录环境靠工具管。四类资料四种管理方式,各归各位。
从零开始整理的执行顺序
不需要一次做完,按这个顺序分三步走:
当天就做:建一份统一底表(Google Sheet 或飞书多维表格),把现有所有 SKU 填进去,分平台列出标题、类目、售价。这一步解决的是”全局视图”问题。
一周内做完:按命名规则重新整理图片素材库,把现有图片归到”产品→平台→站点”的文件夹结构里。这一步花时间但只做一次。
持续维护:每次上新品时按底表格式填写、按命名规则存图、按配置表记录变更。新品纳入体系的时间成本大约 15-20 分钟/SKU,比事后补整理快得多。
FAQ
Shopee 和 Lazada 同时做后台资料怎么整理才不搞混?
核心是建一份跨平台统一底表,用内部 SKU 编码作为锚点,通用字段只维护一份,差异字段按平台分列。图片按”产品→平台→站点”三层文件夹存储,文件名包含 SKU、平台、站点、图片类型四个要素。飞跨浏览器内置 Shopee 和 Lazada 共 40+ 站点的后台直达入口,配合每店独立容器,从登录环境层面避免多店资料和操作互相干扰。
Shopee 的 listing 可以直接复制到 Lazada 吗?
产品核心信息(属性、参数、描述框架)可以复用,但标题格式、主图规格、类目路径通常不能直接搬。建议从统一底表出发,按各平台的字段规范分别导出,而不是从一个平台的后台直接复制到另一个。
SKU 编码应该用平台自动生成的还是自己定义的?
自己定义,并且全平台统一。平台自动生成的编码只在该平台内有效,跨平台对账和仓库发货时无法识别。自定义编码建议用”品类缩写-序号-变体代码”格式,简短且可读。
图片素材需要按平台分开存储吗?
需要。Shopee 和 Lazada 的主图规格、信息图规则不同,同一张图通常不能直接跨平台使用。原始产品照片统一存一份,按平台规格裁剪加工后分别存到对应文件夹。
多人操作时怎么保证底表不被改乱?
用在线协作表格(Google Sheet / 飞书),开启操作历史记录,每次修改自动留痕。关键字段(SKU 编码、采购价)设置编辑权限,只有指定角色能改。
两个平台的促销活动价格怎么同步?
任何价格变动都先回到统一底表更新,再按平台分别设置。不要在平台后台直接改价后忘记同步底表。活动期间建议在底表增加”活动价”列,标注活动平台、时间段和折后价。
店铺数量少的时候有必要搞这么复杂的体系吗?
2 个店以内,一份 Excel 平铺管理确实够用。但如果计划半年内扩到 5 个店以上,建议从第 3 个店开始就用分类框架和命名规则。体系搭建的成本是固定的,越早搭、后面省的时间越多。
Shopee 和 Lazada 各站点的类目结构差异大吗?
Lazada 各站点的类目树相对统一,差异较小。Shopee 各站点的类目结构差异明显,同一个产品在马来站和菲律宾站可能归属完全不同的类目路径。上新时务必按站点逐个确认类目,不要默认所有站点一致。