从单一问题到通用平台
OneCatalog 起源于一家数字代理公司,我们曾为不同行业的厂商和经销商搭建网店。每个新项目——无论商品类别——都面临同样的难题:数据散落在 PDF 目录、XLS 表格和封闭的 B2B 门户中。
内容运营手工填写商品卡片。供应商每次改版,爬虫都会失效。同一品牌在不同店铺中的规格描述不一致。一份目录上线需要 3–6 个月,后续维护还得再花半年。
我们意识到一件简单的事:商品数据唯一可靠的来源就是厂商本身。于是我们打造了一个平台,让厂商自己录入和维护商品,经销商和零售商通过一个 API 获取这些数据。
今天的 OneCatalog 是一个公开的 Wiki-API 平台:厂商掌握数据,经销商和零售商在 API 之上搭建自己的目录。
厂商 → 店铺 之间的痛点
数据散落在 PDF 中
厂商以 PDF 和 XLS 形式发布目录。要按参数或货号筛选,先得全部解析,然后持续追踪更新。
每家店铺规格各不相同
同一件商品在不同卖家那里描述都不一样:单位、格式、货号——各有各的写法。无法对比,更无法筛选。
照片质量低
卖家手里只有仓库里的手机照片。厂商有专业棚拍,但不谈判就拿不到。结果整个目录看起来很廉价。
内容团队成本高
一位运营每天处理 200 个 SKU 已是常态。1 万条目录需要 5 人忙半年,还要加上校对和摄影师。
爬虫是一条死胡同
爬取供应商网站等于同时跟基础设施、反爬系统和法律部门较劲。每一次改版,前面的工作就清零。
B2B 门户 = 没完没了的会议
部分品牌有封闭的 B2B 门户;开通需要走客户经理、签 NDA、签合同。一个品牌一个月起。
一个 API,厂商自己上架商品
厂商获得后台账号,自行添加商品——包括所有参数、照片和更新。经销商和零售商接入公开 API,自动获得始终最新的目录,无需自己维护。
结构化数据
品牌、系列、商品类型、参数——关系模型,不是 JSON 大杂烩。
统一规格
度量单位、ISO 国家代码、货号格式——所有商品类别遵循同一套规则。
三种图片尺寸
min / middle / max——按场景选择合适的尺寸,避免传输多余字节。
厂商后台
厂商自行录入商品、更新参数、上传照片。数据立即通过 API 提供。
REST + OpenAPI
标准规范,API 密钥鉴权,简单筛选。无 GraphQL,无 SOAP。
目录即示例
本站本身就是基于 API 可构建内容的范例。可作为参考。
OneCatalog 当前
我们的客户
厂商
一次性建好目录——随后随新系列上市持续更新。数据即刻送达所有合作店铺。
经销商
通过单一 API 直接获得厂商最新数据。无需电话沟通、NDA、过期的 XLS 文件。
零售商与网店
用 API 替代内容团队。一次集成接入所有需要的品牌,自动获取更新。
我们的工作方式
不糊弄用户
没有「五万家客户信赖」之类的虚假数字。价格页没有用编造 Logo 堆出来的「信任墙」。
不堆依赖
没有 UI 框架,没有图标库,没有状态管理器。只用真正必要的东西。
首日即上量
通过 query-param 调用 API 可绕过 CORS 预检。图片提供三种尺寸。响应解析采用防御式写法。
UX 优先于功能
一个真正好用的筛选弹窗,胜过三个半成品模式。