作者：刘志远
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
电商产品经理宝典：电商后台系统产品逻辑全解析试读：
前言
随着智能手机的普及，互联网以汹涌之势融入我们的生活，上到花甲古稀的老人，下到总角之年的小朋友，都或多或少用过一些应用，对一些产品有各种见解，越来越多人开始讨论产品。对产品经理来说这是最好的时代。
但是产品同质化越来越严重，用户体验却难以量化，马太效应在互联网行业如同魔咒，流量被巨头掌握，中小企业难以突破流量黑洞。对产品经理来说这同时也是最坏的时代。
大部分用户根本感知不到后台产品的存在，会觉得后台产品颇为神秘。业内人一般认为做后台产品很难，因为产品的逻辑复杂。在大家天马行空的畅想之后，后台产品经理会想着怎么落地，后台系统能不能支撑？什么样的产品方案可以满足需求？
时至今日，对于产品经理的要求趋向业务型、平台型，甚至产生了细分领域专家。纯粹的前端产品经理（页面、交互）逐渐失去竞争力。而当后台产品经理的视野开始从功能延伸到模块，再延伸到子系统，最后关注整体系统时，就有了把控平台型产品的能力。
任何一个小功能在深入思考之后就是无底洞，需要对其取舍和衡量。可能因为我是一个工科生，喜欢做后台产品，喜欢沉浸于逻辑自洽的乐趣中。我遇到生活中的许多场景都会不自主地去想优化方案。
当我开始做电商后台产品时，想找些资料来系统化学习，却发现市场上关于产品的书籍，要么是产品方法论，要么是电商运营，基本没有产品后台相关的系统化书籍。电商行业发展这么多年，相关ERP软件也很成熟，很纳闷为什么没有后台产品的系统化资料？当时就想着自己以后要总结一些经验。
按照我的计划，以《电商后台是怎么回事儿》开头，逐步将商品、订单、促销等十几个子系统逐个一点点剖析，写出一个系列。后来，我开始在公众号“碎碎恋产品”上发表一些关于电商后台产品的文章，结识了一些同行业的产品朋友，他们认同我所写的产品内容，觉得是“干货”，鼓励我继续分享。后来出版社的编辑老师联系到我，第一次意识到分享这件事可以这么酷，遂决定做出这本书。
本书的核心在于“电商后台产品”。
第1章简要地介绍了产品经理的工作职责、常见的电商模式，第2章介绍后台产品的作用、架构以及做后台产品的注意点。
第3章到第10章，将电商后台产品的子系统进行细分讲解，主要包括商品中心、促销系统、内容管理（CMS系统）、库存管理、物流管理、采购管理、仓库管理系统、订单管理等主要系统。
第11章总结了电商后台产品的其他子系统，重点讲解了会员系统、调度中心、支付系统、权限系统。
第12章重点叙述了跨境电商产品的不同点，包括跨境电商的几种模式、订单流程及清关备案流程。
本书以电商后台产品为例，介绍了在后台产品设计时的体系化思维。虽然无法面面俱到，但从庞大的后台产品体系中，我们可以慢慢学会从整体去思考系统定位，判断功能的优先级，或者从系统层面去思考功能的价值。
建议各行业的产品经理们，以及电商行业的程序员、运营人员，都应该了解研究电商后台。电商后台的体系成熟、完整、庞大，有很强的借鉴意义，并且大部分产品都逃脱不了商业化，也就会和电商后台系统或多或少有些重叠。
希望本书能够带给大家些许帮助。
感谢公众号“碎碎恋产品”的粉丝们，是你们给了我写作的原始动力。感谢电子工业出版社的林瑞和老师在写作上给予的帮助。
最后将我最喜欢的一句话送给在产品经理成长路上前行的读者们：
为者常成，行者常至。
售后服务
轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。
·提交勘误：您对书中内容的修改意见可在提交勘误处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。
·交流互动：在页面下方读者评论处留下您的疑问或观点，与我们和其他读者一同学习交流。
页面入口：http：//www.broadview.com.cn/32579
伟大的事物不是一时冲动做起来的，而是由一系列小事共同造就的。
——梵高第1章产品经理概述
在不同管理架构的公司、不同类型的团队中，或者开发不同类型的产品，产品经理角色的差异是非常明显的。例如：有些产品经理负责与用户沟通、进行需求调研，有些负责交互设计和产品原型设计，有些产品经理从数据中挖掘需求，有些产品经理参与从需求调研、开发、上线推广到迭代的全过程。
产品经理是对产品负根本责任的管理者，负责协调、整合和管理各种人力、物力等资源，将产品方案转化成实际产品上线。优秀的产品经理应该是心理学家和管理者的综合体，具有“同理心”，理解用户、开发、运营等产品相关人员，帮助团队明白正在开发的内容，理解用户的需求；让团队明白他们的目标客户，想通过产品解决用户的哪些痛点；善于管理团队，确保团队能够高效完成项目。
产品经理的成长就如同游戏通关升级的过程，初期负责写需求文档，做一个模块功能；逐步开始负责一个产品，比如一个APP或一个系统，涉及产品的所有需求都需要关注，还要协调相关的产品配合；等到成为产品线负责人，就需要关心整个产品线，从公司业务的角度思考产品战略、管理产品团队、协调各部门资源来配合产品战略。1.1产品经理的工作职责【产品经理的日常工作】
日常工作中，产品经理的事情多而杂，但总结起来，工作主要分为以下几个方面。（1）了解产品的用户和市场。
产品经理的立足点是产品，而产品的来源又是需求。产品经理需要通过市场调研、与目标用户沟通、竞品分析等多种方式来深入了解用户需求。需求有多种来源：比如用户的“吐槽”，运营部门、业务部门或者公司领导的产品目标。
作为产品经理，要在理解业务的基础上，按照产品战略规划来筛选、挖掘需求。世上没有无来由的爱，也没有无来由的恨。产品经理要分析需求背后的深层原因及用户心理，在符合产品定位和战略的情况下，过滤掉不符合产品定位以及性价比较低的需求。
用户提出来的需求只能称作用户需求，还不能算产品需求。例如，用户向你描述的是“需要一匹更快的马”，实际他真实的想法是“需要一辆汽车”。产品经理要学会转化“用户需求”为“产品需求”。
除非是公益性产品，否则产品需求一定要符合业务驱动因素。产品经理要了解产品的用户和市场，解决用户的核心需求，推动业务的发展。（2）设计产品方案，在公司内部讨论、评审，确认需求优先级，确定产品方案以解决用户需求。
设计产品方案（PRD文档）是产品经理的基本工作。在进行产品规划和设计时，应考虑业务驱动、需求重要性和开发资源等因素以确定需求的优先级。产品经理要协调可用的资源进行产品评审，敲定可用的产品方案。这个过程对于产品经理最具挑战性，要阐述清楚自己的方案，讲解用户的需求，需要在坚持与妥协中前进。
产品经理应该是个理想的现实主义者，要用有限资源去完成最大价值的需求，最终目标是推动产品需求的落地。基于对开发成本的把握，对于每个阶段每个版本能完成哪些需求都要了然于胸。（3）跟进项目开发进度，确保按时上线。
在产品评审通过之后，产品经理应确保开发进度。除了争取相应的开发资源之外，还有一件事情对于产品经理的职业要求最高，就是“需求变更”。这也是开发过程中最应慎重、最易被坑的地方。一旦需求评审通过就不要轻易变更。产品经理应尽量提供精简而有效的文档，对于某些关键点，则需要私下给对应的开发细化讲解。
万不得已发生了需求变更，产品经理要及时给相应人员同步变化，避免信息不同步带来的多余工作。在项目开发的过程中，产品经理要同步跟进，用心测试，发现问题要及时沟通，确保项目按时上线。（4）上线后跟进用户反馈，优化迭代。
产品应建立一套发现问题、解决问题的用户反馈机制。尽管我们会尽量确保产品需求和用户需求一致，但是总会出现一定偏差。产品上线之后，我们需要收集用户反馈，来源包括各大应用商店的评论、贴吧“吐槽”、与深度用户的直接交流、产品端的反馈等，确保能够及时解决问题和修改错误。
在收集用户反馈的过程中，我们也能发现一些新的用户需求，再加上市场反馈来确定产品的迭代目标，快速反应，优化迭代。【产品经理的必要品质】
作为产品经理，应该将自己看作产品的负责人，对自己所属的产品模块、产品甚至产品线负责任。
想成为优秀的产品经理，应当有一些必要的能力。
1.了解不同人的想法
产品经理必须深入到各种人群中，包括用户、市场人员、工程师、设计师等。和不同职业、不同性格的人打交道，了解他们对产品的看法，深入挖掘需求，为不同的角色来构建产品，以找到最核心的需求；同时也能够更好地合作，推进大家完成项目目标。
2.信息传达能力
产品经理必须有能力通过产品界面、图表、交互界面向用户清晰地传达关键信息。产品经理向团队讲解产品方案，向运营讲解业务市场，向用户传达产品功能，这些都需要产品经理善于表达。
用户如果在使用某种产品时，学习成本过高，没法快速找到关键信息，会使用户困惑，从而选择其他产品。
此外，国内的互联网公司开发产品时，经常追求大而全，不断地累加功能，这就对产品经理的信息传达能力提出了更高的挑战。
3.洞察力
互联网行业变化太快，可能短短一两年，市场就会发生翻天覆地的变化。产品经理应了解行业动态，发现新环境下的新兴趋势。虽然不一定要创新来颠覆行业，但是要跟上主流趋势，甚至用新的方式来连接现有的想法。
4.逻辑思维能力
优秀的产品经理必须具有较强的逻辑思维能力，严格地思考系统的设计、执行策略。逻辑对于产品设计尤为重要，我们要考虑主流程及子流程的畅通。特别是后台产品经理，内部模块之间甚至许多系统之间会发生频繁的信息交互，完整的产品逻辑避免出现错误的尴尬。如果用户发现产品逻辑上的错误，这会比交互体验差更严重，转而弃用产品。
5.权衡能力
开发产品的任何一个功能都会产生成本，产品经理需要根据项目最重要的维度（例如美观性、进度要求、功能性、使用场景），经过权衡，来确定最合适的产品方案和优先级。产品经理在很多时候都面临现实与理想之间的权衡，比如新增功能、修改Bug、系统升级等。
6.推动力
提出产品计划之后，产品经理应与执行团队（开发团队、各部门相关人员）沟通，推动产品向前推进，确保功能开发、发布上线都是成功和良好的。
作为产品经理，应该是一名现实的理想主义者，对产品有着无比认真的态度，同时能够适当妥协，利用有限的资源来推动产品目标的达成。1.2相关工具、网站介绍
市面上有许多关于方法论的书籍和文章，笔者就不对流程方法做过多赘述。主要说说产品经理平常工作中使用最频繁的一些工具和网站。
首先是原型工具。产品经理使用原型来表达产品想法，不拘泥于形式，有时手绘就可以做一些原型图，最常见的是用Axure画线框图。笔者一开始也喜欢尝试使用各种原型工具，后来使用Axure习惯了，就不再需要其他工具。原型、流程图甚至PRD文档都开始使用Axure写。
思维导图在整理思路时非常有效，能够帮助我们建立系统性的结构思维，有助于对所研究的问题进行深刻地和富有创造性地思考，在具化的过程中找到解决问题的关键因素或关键环节。特别是当我们的想法只是一个点子时，利用思维导图能够迅速拓展成形。常用的思维导图软件有Mindmanager、Xmind，还有轻便式的百度脑图。这些都是非常优秀的思维导图工具。
PRD（Product Requirement Document）是产品经理将产品需求落地实施最重要的文档，没有标准的规范，也没有统一模板。PRD的表达方式和产品经理的个人风格有很大关系。建议产品经理们还是尽量详细写PRD，有需求变更时，尽量在PRD中更新。PRD文档不仅是开发和测试人员进行工作的依据，也能够清晰记录产品迭代的过程，还能在长时间后找回“初心”，追溯当时的产品规划和功能的出发点。
另外产品经理还需要进行需求管理的表格，对需要做的、已经做的、做完的需求进行整理跟踪，对需求来源、Deadline、进度进行追踪，这个表格就相当于产品经理的工作清单，可以跟踪工作完成度。需求管理表格可以直接使用Excel来完成。
印象笔记也是款不错的软件，可以随时随地进行记录，帮我们构建结构化的知识体系，特别是标签功能，可以轻松对笔记进行分类。工作日志、生活感悟、学习心得等都可以放在印象笔记上。作为产品从业者，知识积累和复盘是相当重要的。当然通过其他的笔记工具也是可以的。
有些产品经理常用的网站，例如PMCAFF、人人都是产品经理网站、知乎等，都有同行聚集的社群。通过交流，产品经理可以从大家的思考中汲取营养；产品经理也要学会分享，发出自己产品声音，只有在输入输出的循环过程中，才能获得真正的成长；通过线上，产品经理还有机会结识不同领域的同行，倾听不同的看法，了解下大家都在做什么，避免思维陷入局限。总之，产品经理要善于利用互联网获取有效信息。
许多电商后台的产品经理抱怨平常接触的后台产品太少，很多时候都在空想。实际上有许多成熟可学习的资源。例如大家可以在淘宝上开个淘宝店，将里面的店铺管理、订单管理、物流、商品、售后、促销、装修等流程都走一遍，还能体会作为系统使用者的一些操作和功能痛点；还有可以多看看京东的商家后台，把能接触到的功能都用一遍，思考其背后的产品逻辑和可优化点；有赞的产品交互做得很不错，开店门槛也不高，电商后台产品经理都可以尝试用一下。除了从产品的角度去思考信息流、产品逻辑，还要从使用者的角度出发，思考怎样交互更加便捷。
优秀的产品经理都具有“场景思考力”，那什么是“场景思考力”呢？就是在具体场景内联想思考的能力，而不是一味空想。
例如，我们在骑共享单车时，可以思考下共享单车这个产品，其除了每次扫码用车时收费，是不是也可以出类似公交车的月票，或者VIP包月服务，比如每月20元不限次数骑车？作为产品经理，在浏览同类产品时，要有从业务思考的主动性。如图1-1所示，这是大家经常逛的京东商城的一个商品详情图，这张图包含许多信息，你先思考几分钟，然后说说从这张图看到了什么？
经过对图1-1的深入思考和分析后，我们可以发现的产品点如下。（1）商品主图、商品名称、价格、商品详情图等信息都是直接取的商品相关信息，从商品模块获取。标题前的“自营”是后台判断商品为自营商品后加的标记。图1-1 京东详情图截图（2）“降价通知”说明后台提供价格监控功能，可以在降价时通知用户。大家可进一步思考价格监控系统的产品设计逻辑。（3）促销栏中的“多买优惠”是一种促销方式，满2件8折、满3件7折，可以推测出其优惠规则。联想下，如果在设置优惠满2件7折时，选择商品列表，在加载商品详情页时，去查询该商品参与的促销活动。甚至还可以联想生活中遇到的一些促销活动是不是可以在这里用。（4）“已选”中的内容指的是规格、数量，我们发现切换一个规格，商品名称和价格会发生变化，这个商品详情是以SKU为维度来展示的。（5）“送至”这一栏中包含的信息较多，首先地址是从收货默认地址中提取的。当我们改变地址时，现货可能变成缺货，说明不同地址的发货仓库是不同的。另外地址选择偏僻些，预计到货时间会发生变化，从次日达变成三日达，这说明背后有个从发货仓库到收货地址的物流时长预估系统支撑。（6）礼品购是平台提供的附加服务功能。（7）评价中有评价数量、好评度等指标，另外评论不是按评价时间直接显示的，说明对评论有筛选机制。评论上面还有关键词显示，可按照关键词筛选，说明对评论还有关键词提取规则。还可以从评论中看出一系列内容。（8）“购物车”提供了直达购物车的快捷路径，算是驱动用户购买的一种设计。购物车右上角的“72”代表购物车中商品的数量。
以上列举了对于商品详情页的部分思考，可以看出“场景思考力”能带给产品人许多启发和拓展性。实际上，不论在使用APP，还是与快递人员接触，甚至在超市购物等各种场景中，只要我们多结合场景思考，就会有许多不错的点子，完整整理出来就可能是可用的产品逻辑。
电商产品是最成熟、最典型的系统化产品，从电商产品入门，再去探索其他的产品，就会发现理解起来很容易。除了系统的逻辑有相通之处，还因为电商行业会带给产品人成熟的体系化思维。大部分行业的产品相对电商产品，复杂度相对较低。学习、理解学习电商后台产品，相信对每个电商从业者都很重要，特别是产品经理，能够在成熟的框架下快速建立系统化的产品理念。1.3电商模式
随着互联网产业的蓬勃发展，依托于互联网的电子商务，突破了传统行业经验模式的束缚，将宣传、销售、生产、交易、物流等合为一体，突破了时空的限制，为买家和卖家提供了交易平台。特别是移动互联网的普及，从根本上改变了人们的消费理念和生活方式，同时也引起了很多行业的变革——最明显的就是物流行业——在十年前，当日达或次日达根本无法想象。
电商行业发展到现在，也遇到了瓶颈。如今流量成本高昂，客户忠诚度低。对很多小平台电商来讲，几乎无复购率，只要停止砸钱做活动、铺广告，订单量就会直线下降。电商在疯狂增长之后遇到了天花板，传统零售在电商的冲击下也开始了关店潮。线下实体转线上发展，线上网店转线下寻求突破，都在寻找新的商业模式。
电子商务随着信息服务方式的创新及应用领域的不断扩大，电子商务的模式也层出不穷，每个电商平台在发展的过程中可能会兼顾多种模式，总结下来主要有5种类型：B2C、B2B、C2C、C2M、O2O。
B2C（Business to Consumer）：企业与消费者之间的电子商务。B2C是电子商务最普遍的模式，就是通常说的商业零售，借助互联网进行在线销售，直接面向消费者销售产品和服务，消费者线上支付，网上购物。B2C模式的电商是日常生活中最常见的模式，类似京东、天猫等都是典型的B2C商城。
B2B（Business to Business）：企业与企业之间的电子商务。供应方（Business）与采购方（Business）之间通过运营者（Operator）达成产品或服务交易的一种电子商务模式。B2B解决的是供应商的上游到中游的问题，B2B模式的优势在于可降低采购成本，节省周转时间，但是企业采购一般要求较高（资质、流程、库存、货款等），需要许多线下沟通，目前B2B电商大部分是促成中小企业的线上交易。如今B2B平台更多是提供企业之间的信息匹配，要将B2B电商发展成类似B2C一样繁荣，需要在细分行业深度挖掘需求。类似阿里巴巴（1688）是典型的B2B商城。
C2C（Consumer to Consumer）：消费者与消费者之间的电子商务。C2C模式相对B2C来说更加灵活，对于海量商品和类目进行补充，可以针对用户做个性化定制。市场的主流趋势仍是B2C，更能保证商品质量和服务。移动社交的兴起给C2C电商带来了一定机会，给了C端做分销或个性化商品的环境。淘宝网、微店等都是典型的C2C商城。
C2M（Customer to Manufactory）：客户与工厂直接对接，即定制化生产消费。C2M砍掉了架在消费者和制造商之间的品牌商、零售商。对于消费者而言，这将是重磅福利，因为这样省去了渠道成本和库存成本，消费者将能用非常低的价格买到品质上乘的商品，而且还能定制；对于制造商来说，由于价格低质量好，吸引更多顾客，这也能给他们带去巨大的收益；这种模式还解决了库存顽疾这一大问题，将传统的刚性生产模式变成了柔性生产线。未来C2M的利润空间更多的将是定制服务和增值服务。
O2O（Online to Offline）：一般是指线上到线下，通过互联网连接本地生活服务，解决日常生活中的衣食住行等需求。O2O平台在线上提供生活服务信息，从线上获取信息、购买，到线下享受服务，再到线上评价完成消费的闭环。
以上说的这些模式在日常生活中都能接触到，甚至有的平台是多元化的商业模式，兼具多种模式。经过多年的发展历程，不论自营式电商，还是平台式电商，或是细分领域的电商，各类电商企业层出不穷。毫不过分地说，许多需求都被挖掘到过剩。马太效应也在电商行业得到了充分的体现，先行者或巨头们过得越来越好，一些追风者企业则消亡了一批又一批。失败点或在供应链的管控上，或在用户流量上，或在资金链断裂上等。
目前中国已经成为网络零售平台最先进、电商环境最好的国家。从2016年开始，电商巨头如阿里巴巴、京东逐渐开始大规模涉足线下实体商业，新零售概念开始兴起。可以预知的是，未来商业将向自动化和智能化的方向发展。和过去十几年一样，未来的商业模式也会改变消费者对商业的认知，传统的线下卖场、商业综合体将迎来一场变革，新技术如VR（虚拟现实）、AI（人工智能）、大数据分析等将广泛应用于日常生活中来满足用户需求，线上线下的深度结合将更好地服务消费者。
对于电商产品经理来说，这是最好的时代，将有机会参与到改善新零售服务的浪潮中，思考各种新技术与商业结合的可能性，与各行各业的专家、工程师一起协同工作，用产品优化服务。第2章支撑线后台概述很多人接触电商都是从淘宝（天猫）、京东开始，也仅限于前端商城，很少有机会了解后台。如同骨骼之于人体，后台对于电商业务的支撑起着至关重要的作用。一开始接触后台产品，会觉得异常困难，因为后台不是某个独立系统，而是多个模块组合，并且之间还有信息交互。后台重逻辑、重业务，对产品经理的要求很高，令许多人望而却步。不过当我们慢慢梳理清楚业务，弄清楚系统之间的信息流转，就能逐渐成长，甚至在逻辑自洽中找到做后台产品的乐趣。2.1什么是电商后台“前端用户的一小步，后台系统的一大步。”相信接触过后台一段时间的产品经理都会发出这样的感慨。
平常我们用的最常见的功能，比如购物车、优惠券等，看似很简单，用户在使用时也就是点一下，实际上在后台要经过很多条件的校验、多系统间的信息流转。
电商后台对大部分用户来说很陌生，平常几乎接触不到。后台与前端是相对的，对普通消费者来说，商家系统和平台管理系统都属于后台；对平台上的商家而言，商家系统就是后台系统；对平台来说，平台的管理系统属于后台，针对C端的APP、H5商城和针对B端的商家管理系统都属于用户端。
电商后台系统，其实也不能叫做一个系统，可以称为后端支撑产品线，一些公司将其拆分为很多子系统，阿里更将其发展成了中台事业群（商品中心、搜索事业部、共享业务平台等）。后端一系列系统支撑着公司各种业务的进行和发展，当前端展示、业务处理（订单、售后）、库存变动等业务正在进行时，后端各系统间则互相调用接口进行数据更新。
电商行业的许多业务与传统零售业类似，构建后台系统的过程实际在做信息化供应链。做电商产品经理，一定要读供应链管理的相关书籍，用专业化的理论来理解业务。
在漫漫人类历史中，商业以各种形态已存在千百年，现代供应链管理理论发展已近百年，供应链的信息化自计算机诞生后就不断在推进。电商行业不同于其他互联网领域，已经有许多成熟的商业理论可以应用。电商后台产品线的大多数工作是将线下的供应链体系搬到线上，比如采购、仓储、供应商管理、库存管理、商品、售价管理等，这些领域在传统制造业、零售业已有一套成熟的理论和应用。
现在很多电商企业会选择自主开发电商整套系统，系统却很“土”，只在意从0到1，却忽略从1到100的优化。以库存管理为例，商品库存仍是囤货策略，没有从科学的角度去考虑库存周转期、安全库存、补货策略等已经很成熟的东西。图2-1所示的是马士华老师在《供应链管理》中的供应链管理体系构建总体模型。可以发现，电商后台产品的许多业务都在这张图中有所体现。电商公司的采购、仓储、服务、物流、订单等工作都在供应链管理中有所涉及。比如Push/Pull方式就经常用在电商的库存管理中，双11的促销就是Push的方式，先备货，然后通过促销来增加需求。电商后台的许多工作是将供应链流程信息化，以系统的方式来控制业务。当然电商产品中也有许多独有的内容，如在线商城、内容管理（CMS）等。图2-1 供应链管理体系构建总体模型
以客户下订单为例来介绍业务信息在各系统之间的流转，涉及主要的信息交互如图2-2所示。从用户选择商品、生成订单到订单出库、物流配送、用户签收、退货退款，信息在多系统中流转更新数据。
从图2-2中可以看出，前端用户简单的下单动作，需要后台系统多系统模块之间的配合。对于产品经理来讲，理清各系统之间的业务逻辑，特别是当商品类型多样（包括服务商品、实物商品、服务加实物商品等），业务复杂（包括预售、代销、代发等）时，各系统模块的隔离、设计时考虑扩展性非常必要。图2-2 订单业务流程
在电商企业中，后台系统主要的作用是业务支撑、优化服务流程、提高服务效率，还可以提供数据分析参考，进而为业务调整提供参考。2.2电商后台产品架构
电商后台是业务要求较高的产品，当前台产品或业务人员提出需求时，有经验的后台产品经理第一时间想到的不是画原型、设计功能，而是分析要实现需求涉及哪些模块，需要协调哪些子系统对接。所以优秀的产品经理一定是对产品整体架构比较清楚，能从系统整体角度考虑功能的合理性，在平台层面为未来可能的业务发展进行规划和设计。
好的产品架构对于一个企业来讲是非常重要的一件事情，决定了是否能够承载业务的发展，就如同地基之于高层建筑。由于商业性质决定了电商业务支撑系统必须具备稳定性、可扩展、操作便捷、安全性强等特点，产品经理在设计产品架构时，应充分考虑到业务发展需要，尽量将各模块隔离，比如以商品模块建商品中心，以订单模块建订单中心等。只有在产品设计上有模块化思想，具有前瞻性，技术在开发时才会考虑业务隔离，当业务调整、功能新增时，开发可迅速进行，避免牵一发而动全身的事情反复发生。
产品架构的可扩展性非常重要。很多时候会听到开发讲“不要写死”——写代码讲究“可复用、可扩展”。对于产品架构来说同样如此。产品经理在设计产品架构时，要思考未来产品迭代的方向，可能会增加哪些模块，从一开始就给以后的发展留下可能性。如果新产品还没迭代几个小版本，增加一些功能就需要整个页面层级或技术架构推倒重做，那肯定是产品经理的问题。以网易云音乐为例，从2013年云音乐的1.0版本开始，一直更新到现在，APP的信息架构和页面层级基本没发生太大变化。好的产品架构能够支撑业务拓展，降低维护成本。
电商后台产品架构设计要求产品经理非常懂业务。对于系统逻辑思维、整体业务认知以及发展的前瞻性，不同行业、不同用户群的产品经理在做产品整体架构时思路也会不一样。
针对一般电商业务，笔者简单画了一张产品模块示意图（如图2-3所示），基本一些中小型电商公司的产品架构大致如此。除了图中所示，现在很多电商公司开始转型社交电商，采用UGC模式或直播电商，在产品架构上会新增资讯系统，实现资讯与商品的高度融合。图2-3 电商后台产品架构（简化版）（1）商品中心：主要管理SKU（最小库存单位）、SPU（标准化产品单元）、属性（关键属性、非关键属性、销售属性）、类目品牌、价格等有关商品的数据。（2）订单中心：管理订单类型、订单状态，收集关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据，进行库存更新、订单下发等一系列动作。（3）支付中心：管理支付数据，调用第三方支付平台接口，记录支付信息（对应订单号、支付金额等），支付对账。（4）会员中心：主要管理用户等级、用户权益、积分、卡券等会员相关信息，通过一系列满足用户心理、提高黏性的方法来实现开发新用户、增加用户活跃度的目的。（5）调度中心：将订单信息转化为发货通知单，以及其他出入库单，调度仓库和物流进行发货。（6）促销中心：主要管理活动相关，优惠券、满减、专场活动、促销专区等。促销工具的开发对电商尤其重要。促销活动的滥用易造成的用户疲劳，怎样推陈出新，给产品经理造成了很大挑战。（7）内容管理系统：主要是对用户端进行页面配置（Banner、ICON、Tab），配置首页，自定义活动页面，设置生效时效。（8）评价中心：管理商品评价和用户反馈。这并没有想象的那么简单，涉及一些敏感词和敏感图片的筛选，以及回复内容管理。（9）采购中心：管理SKU，当库存预警时，及时生成采购单进行入库。有供应商管理模块，主要进行供应商管理评级，发展新供应商等功能。（10）财务管理：主要管理订单、采购系统相关的财务数据，数据准确性要求较高。还需要负责对账、清账、统计等业务。（11）WMS系统（仓库管理系统）：主要包括入库、出库、盘点等模块。WMS主要和调度中心进行数据交互，反馈出入库状态和库存变动。（12）物流中心：主要包括运费模板，负责运费管理（前端订单、真实物流成本）、物流状态保存查询（包括快递100、菜鸟等关联业务）。如果是跨境电商，还涉及和海关总署的对接，进行报关操作。（13）风控中心：主要利用大数据进行用户信用建设、反欺诈，避免恶意评价、刷单退款等操作，构建安全的电商购物环境。（14）客服中心：主要管理退货退款、售后服务等操作，包括呼叫中心、在线客服等，与之对应的是工单系统，将客服任务进行队列管理，分配给相应的客服。（15）店铺管理：功能庞杂，相当于提供给B端用户一个Saas管理后台，提供管理商品、营销、订单一系列功能，主要针对一些有对B端业务的电商开放平台。
对电商公司来讲，最核心最难做的有三部分：商品、订单、库存。商品与店铺、营销、评价等相关；订单与会员、营销、支付、库存、物流等相关；库存与订单、采购、WMS、营销等相关。系统之间业务逻辑和交互异常复杂，规则多样。
对电商后端支撑线各模块的业务功能有初步认知之后，可以看到的是，平常手机中的一个电商APP，背后是若干子系统在支撑着，亦是许多技术和产品人员在辛苦付出。
每个子系统不是孤立的，通过产品架构相互关联，定义其功能范围。产品架构与技术架构相辅相成，产品架构决定需求和设计，技术架构决定技术框架与性能。
产品架构将这些不同用途的功能进行聚类整合，将电商后台拆分成多个子系统，明确业务边界，尽量减少系统之间的耦合，高效支撑前端业务。2.3后台丰富度的权衡
对于电商后台，初创小公司用几十个开发人员就能满足需求开发，维持业务流转，大公司则需要几百甚至上千个开发人员来进行开发维护。这就涉及后台系统复杂度的问题，除了业务范围的区别，还有业务量的因素。
如图2-4所示，以商品模块为例，在业务量逐步增长时，为了高效便捷地服务用户，会慢慢拆分多个模块。如图上所示，在系统上线初期，整个后台系统融合在一起，商品部分只是后台系统的一个模块。随着业务量的增长，将商品中心独立为子系统；接着随着业务继续增长，库存模块从商品中心中独立出来，单独成为库存中心；再接着发展下来，价格模块从商品中心独立成价格系统；再后来，价格系统根据需要拆分为价格管理系统与价格监控系统。从这个例子中我们可以看到，系统都是从简单到复杂，随着业务慢慢迭代。图2-4 商品模块系统进化过程
对产品经理来说，并不是要把系统做得大而全，也不是小而精。前面提到过，产品经理要做现实的理想主义者，根据实际情况来制定产品迭代计划，不求一步到位。
在产品开发初期，为了尽快上线、降低开发成本，会优先开发主需求，后期随着业务发展慢慢迭代。很多后台产品在上线一段时间后，随着业务增长处理起来会变得越来越吃力。各系统模块杂糅在一起，耦合度高，还有可能出现牵一发而动全身的情况。后台产品经理的能力很大一部分在于对业务的梳理能力，越到后台发展中后期，业务逻辑会越复杂。对业务进行拆分，定义产品架构，支撑中长期的业务发展，极其考验产品经理的能力。
从下章开始详细介绍电商后台产品线中的各系统模块，主要包括业务处理逻辑、与其他系统之间的信息交互等。第3章商品中心
每次在网上购物，逛淘宝、天猫、京东的时候，映入眼帘的都是品类繁多的商品，浏览选择商品比实体店都要方便。当我们选择分类或者直接搜索的时候，可以按条件筛选，快速从千万商品中找到心中想要的商品；甚至不用查找，系统就推荐出了想要的商品。在浏览商品时，商品主图、详情图、规格属性等信息应有尽有，让我们感觉比在超市拿着实物获得的信息还要多，感觉一切都很神奇，那么电商系统到底是怎么实现商品的精细化管理呢？
对于产品经理来说，商品中心的合理设计不仅能够满足前端商品的多样化展示，还能支撑复杂场景下，商品信息在订单中的系统流转。
商品是电商产品体系的核心之一，我们将统一管理商品的地方定义为“商品中心”。商品中心的数据应用场景很多，在使用的维度上分为前端和后端。从前端来讲，是给商品展示、订单、营销活动提供商品数据支撑；从后端来讲，商品中心给订单发货、仓库管理、供应商管理、采购提供基础数据支撑。
为了更清晰地描述商品中心这项重量级工程，也是为了能够让后台各系统模块理解起来更加轻松，笔者主要从9个方面来阐述商品中心：商品的基本概念、类目和品牌管理、属性管理、SKU编辑、商品编辑、商品管理、商品搜索及筛选、商品推荐、商品评论等。
随着商业模式的变化，商品中心的架构亦会随之变动，例如商品分为实物商品或虚拟商品，商品归属分自营或平台商家，售卖分为正常售卖和预售。不同业务场景下商品中心的设计会有些不同。虽然本文讲的主要是类似B2C模式的商品中心的设计，但是万变不离其宗，只要善于思考，结合业务场景，举一反三，都能够找到最合适的解决方案。3.1商品的基本概述
接触过电商的朋友都或多或少地接触一些术语，类似SKU、SPU、属性、类目等，如果你在做运营或者做开发，或者做产品，在实际工作中就会频繁被这些名词所包围。下面具体介绍一下电商的一些基本术语。
SKU：（Stock Keeping Uint，即库存量单位），库存控制的最小可用单位。例如“iPhone 7 Plus 128G银色”就是一个SKU，仓库管理、采购进货、库存管理都是以SKU为记录单元。
SPU：（Standard Product Unit，即标准化产品单元），是一组标准化信息的集合，例如“iPhone 7 Plus”就是一个SPU。
类目：即分类树。电商常用的有两层类目：前台展示类目和后端商品类目。前台类目指的是展示给消费者看的类目，会根据季节、销售策略、活动进行变动；后台类目属于基础数据，不可随意变动，添加SKU时都需要选择后台类目，进行绑定。
属性：分为关键属性、销售属性、非关键属性。关键属性是指能够唯一确定产品的属性，是必填项，例如手机的屏幕尺寸、型号属于关键属性。销售属性是组成SKU的特殊属性，或称为“规格属性”，例如手机的“颜色”、“内存”。非关键属性指的是除关键属性、销售属性外的其他属性，如手机的手机接口类型。非关键属性不一定是非必填项，不过有时为了商品信息完整，也会设为必填项。
商品模块的组成较为复杂，特别是在定义SKU与SPU时，涉及类目、属性等信息。笔者画了一下商品的架构图，如图3-1所示，根据商品的公共数据库，主要包含品牌库、属性库、通用规格库、税率库、生产信息库（产地）等信息，先定义出SKU，然后加上商品描述和规格，就成了商品。对于商品库，衍生出了价格管理、评论管理、搜索筛选、商品推荐等模块。当然还会有库存管理，本章不做讨论，后面会有章节专门聊库存管理。图3-1 商品模块组成3.2类目管理和品牌管理【类目管理】
如前文所说，商品类目分为两层：基础数据类目层（后台类目）、前台展示类目层（前台类目）。
现在前、后台类目分离的理念已深入人心，那为什么要将前、后台类目分开管理，而不是前、后台共用一套类目呢？
这就是业务驱动产品的一个实例。随着商品量的增多（京东的SKU达到数百万级，淘宝、天猫的SKU达到数亿级）、类目树的层级越来越深，一方面，如果买家直接使用后台类目，那么查找商品时将越来越难，另一方面，出于日常运营需要，运营人员在调整类目时，都需要去变更商品的类目，工作量巨大，而且随着节日、时令季节变化，运营会经常变更类目。
在这样的情况下，将前、后台类目分离。后台类目面向商家或供应链人员，商品属性、销售属性及品牌等很多数据都是在基础类目上进行管理；前台类目面向用户，方便用户查找商品，还可以随着运营需要去调整。前、后台类目通过映射关联。
类目管理对商品模块有非常重要的意义，有着明显的平台定位印记，每个行业的类目都会有其特色。类目管理的作用在于以下几点。（1）方便快速发布及管理商品，供应链人员或平台商家更好进行商品管理。（2）标准化商品服务，对于电商平台，品类定义基本确定平台的商品服务范围。（3）有利于仓库管理，合理的商品类目管理还能方便仓库中库位分区管理商品。（4）日常运营需要，在电商运营中，需要进行商品聚类，科学的类目管理可以减少运营的管理工作。
1.后台类目
后台类目主要面向平台商家，用于管理商品和属性。在添加和管理商品时，都是在基础数据类目层对商品进行管理，如图3-2所示，是京东后台的基础类目。
后台类目相对固定，确定了之后不会轻易变更或删除，如果类目下挂载有商品，就不能删除或作废。
类目树的层次不能太深，一般三层或四层。如果太深，不论对于管理还是技术性能来说，都是不利的。类目树中最后一层类目称为叶子类目，商品必须挂载于叶子类目下。图3-2 京东后台类目
商品属性、销售属性及品牌等很多数据都是在基础类目上进行管理。发布商品时，在选择好叶子类目之后，会被要求选择品牌、填写相应的属性，所以类目管理属于较为核心的工作，一定要从长远角度考虑。
赠品作为促销（低价）商品，应该专门设置类目，通常放置到商品发布类目“其他—赠品”类目下，以避免引起买家对该商品的误解，进而避免产生不必要的纠纷。
2.前台类目
前台类目主要面向用户，方便用户筛选查找商品，如图3-3所示，是京东的前台类目。前台类目可以根据运营需要，灵活多变。所以处理产品的前端类目时，就应该提供多样化的前端类目支持。
从用户渠道的纬度上讲：（1）前台类目可支持不同客户端的设置。PC端、H5端、APP端等渠道由于用户群体有所差异，可分别设置前台类目，独立运营。例如京东的PC商城、APP、微信商城的分类就有所差异。（2）支持平台商家自定义店铺前台类目。每个商家的产品和定位不同，有不同的类目运营需求。例如淘宝的每个店铺都可以自定义自己的前端类目。图3-3 京东前台类目
从前台类目定义的维度上讲：（1）前台类目对应后台类目，可一对一、一对多、多对多，自由组合，动态调整。现在大部分自营电商都是用的这种类型。（2）前台类目直接对应品牌、商品，适合商品较少的小商家。这种情况主要是因为一些电商平台提供给平台上商家的类目服务，在添加商品时可以直接选择前台展示的类目。（3）前台类目对应后台的叶子类目和某项属性的组合。例如分类时选择奶粉中的1段、2段、3段等属性组成类目。
前台类目不同于固定的后台类目，编辑很灵活、可重叠、可删除、可随时变动，定时生效。【品牌管理】
品牌是商品的必备属性之一，在用户做购买决策时亦是关键因素。品牌管理的流程相对于类目管理来说更简单，如图3-4所示。图3-4 品牌组成
需要注意的是以下两点。（1）新建品牌，其相关字段一般有：Logo、中文名、英文名、产地、备注、状态（可用、不可用）。（2）将品牌关联到类目上，关系也是一对一、一对多、多对一。例如雀巢的产品有咖啡、奶粉、饮料等不同种类，这三类产品属于不同的叶子类目。
品牌关联类目的好处在于：提升发布商品的便捷性，避免出错；品牌管理标准化；在搜索筛选商品时更加快捷。
当然品牌关联类目也会带来一定的管理难度。对于中小电商来说，当品牌数量并不是太多的时候，可以不做关联。3.3属性管理
属性是对产品性质的描述，是区分产品差异性的集合。在电商中，属性通常分为关键属性、销售属性、非关键属性、商品属性。（1）关键属性：能够确认唯一“产品″的属性。关键属性可以是一个属性，也可以是多个属性的组合。例如：通过手机的“品牌”、“型号”两个属性组合就能确定唯一的产品，这两个就是关键属性；通过服装的“品牌”、“货号”两个属性组合能确定唯一的产品，所以这两个也是关键属性。（2）销售属性：也称为规格属性。其是组成SKU的特殊属性，它会影响买家的购买和卖家的库存管理。例如服装的“颜色”、“套餐”和“尺码”，都是销售属性。（3）非关键属性：除关键属性、销售属性外的其他属性。非关键属性不一定是非必填项，有时为了商品信息完整，也会被设为必填项。注意，产品的非关键属性并不包括商品属性。（4）商品属性：表示商品的特有特征，比如新旧程度、保修方式等，不能作为产品的属性。
属性的定义对于良好的消费体验有着至关重要的意义，对搜索、索引、筛选都能起到至关重要的作用。商品搜索能力，除了标题、类目，很大程度依赖于商品属性，条件筛选的基础数据也是商品属性和规格属性。完善商品属性对于实现良好用户体验至关重要。
属性包括属性名、属性值，一般都是挂在具体类目下，设置为必填或非必填。在设置属性值时，须保留一定的扩展性，部分允许自定义属性。商品属性管理要求强大的类目运营能力，在中小型电商平台一般会提供基础属性值，再开放自定义属性编辑，让用户来完善属性库数据。【商品属性系统的设计】
为了方便商品管理，我们需要在系统中建立一套属性库，类目属性都是调取的属性库里的数据，而属性搭建的原则通常是从属性分类的纬度来搭建的，分别是关键属性、销售属性、非关键属性、商品属性。
如图3-5所示，在定义一个属性时，需要挂载在类目下，区分属性分类（关键属性、销售属性、非关键属性、商品属性），并确定属性值、显示类型（单选、多选、可自定义）、是否必填以及属性分组。对属性的定义是为了在添加商品时，属性列有判断条件。在搜索筛选时，确定各属性字段的意义和权重。图3-5 属性编辑
属性编辑主要是定义当前分类的商品具有哪些属性。在属性管理上，有两个产品方法可以使用，属性分组和属性继承。
1.属性分组
由于一个类目的属性有时会很多，可能几十个，甚至上百个，所以引入了属性分组的概念，把形容某一类特征的几个属性归属于一个组，这样在前端的规格参数里可以按后台设置的属性分组按序展示，也方便对属性进行管理。如图3-6所示，屏幕参数、镜头参数、曝光控制、闪光灯参数等都属于属性分组。
2.属性继承
如果网站的商品分类为三个层级，每个商品由很多的商品属性构成，其中同一层级的商品属性可能有很多都是相同的属性，为了减少属性添加时的工作量，我们将这部分共用的属性归类后赋值在上一层级的分类中，依次操作，将归类后的属性分别赋值给上级的分类中。图3-6 属性分组
每一个层级的商品属性继承上一层级的商品属性，将每个层级的属性提取出来，便组成了一个商品的完整的属性表达。
如图3-7所示，1级类目有属性A，2级类目有属性B，3级类目有属性C，那3级类目下的商品SKU1就具有属性A、B、C。比如实物商品佳能EOS 800D（在类目“数码”→“摄影摄像”→“单反相机”中）就有商品毛重、像素、套头三个属性需要填写。（举例只取了部分属性。）图3-7 属性继承
当属性库搭建完成后，就会被各个叶子类目调用，添加商品时就需要填写这些属性，商品就有了载体，例如图3-8所示。属性库在前台便充当起了导购、描述、筛选的作用。对于仓库管理有较大作用（易碎、防潮等），根据这些属性便能确定商品的唯一性（SKU）。图3-8 淘宝的商品属性（类目“男装”→“风衣”）
特别需要注意的是一些规格属性（如颜色、尺码等）。很多产品有多规格，例如衣服、鞋子等。以一双男鞋为例，有颜色（假设白、红、黑3种颜色），有尺码（从39～44共6种尺码），那么这个SPU（男鞋）下面就有18个SKU。这些SKU的属性除了规格属性外，其他属性都是一致的，所以在新建商品时，可聚合到一起，共用其他属性。3.4SKU与SPU
SKU和SPU算是电商中最基础的概念，SKU是最小库存单元，SPU是标准化产品单元。很多电商从业者在入门的时候都会被这两个概念围绕。
SPU与SKU的关系有许多种，可以一对多、一对一，如图3-9所示。绝大部分SPU与SKU都是一对一，多规格的SPU和SKU之间是通过规格属性来连接的。SPU的库存是由其对应的SKU库存共同决定的。
以iPhone 7 Plus（SPU）为例，这个SPU的规格有多种（颜色包含金色、白色、黑色、玫瑰金、银色、亮黑、红色等6种；内存包含32G、128G、256G等3种），对应18（即3×6）种SKU。比如“iPhone 7 Plus白色32G”、“iPhone 7 Plus黑色32G”这两个SKU都能具化到实物。仓库系统、采购系统、库存系统、订单中心等系统都是主要管理SKU。图3-9 SPU与SKU关系示例
在日常运营中也很常见一个SKU对应多个SPU，比如图3-9中SKU2就对应SPU1和SPU2。例如在一家淘宝店中，同样的一件男裤，店家可以起两个不同的商品名称（“七分裤男夏季薄款纯棉运动休闲”、“7分男士短裤男夏天宽松大码小脚潮”），这时候在前台展示的是不同商品，系统中这两件商品编码（SPU编码）也不同，但是发货对应的是同一个SKU，库存也是共用。
还有一个比较特殊的概念：组合SKU，主要是解决出售组合商品的问题。组合SKU的属性都继承主SKU。组合SKU不同于套装促销。套装促销在订单中会展示多个商品，而组合SKU在前台是一个商品。组合SKU的应用场景主要是添加赠品、组合售卖，与前台的商品套餐有所区别。在订单解析成发货单时，组合SKU需解析成单一SKU，方便仓库发货，更新库存。
如表3-1所示，SKU3是一个组合商品，在前台售卖时是单个商品，下单之后流出仓库就解析成SKU1和SKU2。还有一个业务场景，这种组合套装有特殊的包装，而仓库不会去包装的情况下，套装进仓的时候就以独立的SKU入库，不需要做拆分处理。表3-1 商品与SKU的对应关系举例【编码问题】
在电商系统中流转的是系统生成的SPU编码和SKU编码。这里要介绍一下69码，我国官方的商品编码是69开头，俗称69码，例如食品包装上的条码。在编辑商品的时候，一般会有个条形码字段需要填写，就是系统中的SKU对应69码。这个条形码主要在采购、出入库时使用。
在仓库的条码方案以下有两种。（1）全部自建条码。采用自己的SKU编码管理商品，需要入库前重新贴标，成本较高。（2）有69码的商品沿用69码，无69码的商品（比如蔬菜、生鲜等）以及无法指定到单一的有码商品重新贴SKU编码。在仓库管理时做相应的条码映射。3.5商品编辑
SKU组成如图3-10所示。在添加商品时，通过销售属性去关联SPU与SKU，同一SPU在前台显示时可以共用同一商品详情，只是通过规格属性映射到具体的SKU上。通过供应商去关联采购，进而影响仓库中SKU的库存。供应商在添加SKU时亦可不选择，可以在采购系统中添加关联。针对商品的关键属性和属性值，可以在商品搜索和筛选时用上，良好的属性定义对于顾客决策树的缩短有着至关重要的作用。图3-10 SKU组成
很多电商公司业务定位都是B2B2C，为了扩充SKU，增加用户量，或者构建平台体系，都会允许第三方来平台管理商品，类似京东、淘宝。这类平台的商品结构更加复杂，SKU需要增加所属商家，商品详情、属性值、库存都需要相互独立，在SKU、SPU纬度上增加一个商家纬度。这里不做过多扩展，感兴趣的朋友可以深入思考。
笔者再从商品前端显示来说说后台设计的那些事儿。
用户平常购物接触到最多的就是商品显示页，商品列表、商品详情页的基础信息都是从商品中心获取。目前对于商品设计有着成熟的产品方案。电商网站的商品产品结构大同小异，淘宝、天猫上的商品以SPU形态显示，京东上以SKU形态显示，两种处理方式各有优劣势（淘宝切换规格时商品详情不变，京东切换规格时标题及详情会改变）。其实笔者更倾向于淘宝、天猫的商品结构，能够支持更加灵活的商品方案。
如图3-11所示，商品信息主要由类目、标题、品牌、商品属性、规格（销售属性）、价格、库存、SKU信息（属性、毛重、长宽高等）、商品图、商品详情描述、物流信息等组成。至于经常看到的服务标签（分期、极速退款）、商品标签（热销）、活动标签（满减、优惠券）、价格标签（拼团价、活动价）、同类商品等都是商品信息的标签，需要另外定义，后面的章节会提到。图3-11 京东（左）与天猫（右）的商品详情页
后台在编辑商品信息时，设置存储的也是这些内容：类目、标题、品牌、商品属性、规格（京东定义为销售属性）、价格、库存、SKU信息（毛重、长宽高等）、商品图、商品详情描述、物流信息等。【规格、价格信息】
需要注意的是，在设置规格时（例如设置如图3-12所示京东的商品规格时），主要包括颜色、尺寸，为了支持多样化的用户需求，选择之后可以编辑规格。规格一对一确定之后，可单独设置价格、库存、商家SKU，淘宝或天猫上亦可添加条形码（69码），也可以设置统一价、统一库存。填写商家SKU主要是为了方便对应到具体的SKU。对于自营电商，这里填写的就是SKU编码，库存无法设置，直接同步仓库中的SKU库存。系统中的SKU名称和商品名称是有区别的，SKU名称是方便在系统中进行管理流转，而商品名称有一定的营销性质。图3-12 京东商品规格
平台上会针对商品设置平台价和市场价，如图3-13所示。平台价（即图中的京东价）主要是当商品具有不同规格、价格时，出现在搜索、筛选列表中只显示一个价格，相当于商品的均价。毛重、长宽高等数据主要是为了物流而设置的，自建仓库的自营电商一般在SKU数据层就会录入这些数据，直接调用。货号即商品编码，在商城购物时会扫描的条形码就是货号。货号不等同于SKU编码，同一商品编码的商品可能是不同SKU，有着不同的规格，所以不能直接拿货号来管理SKU。图3-13 京东平台上的商品信息【商品图、商品详情描述、物流信息】
除了不同规格对应的商品缩略图，商品图还包括商品主图，一般要求图片质量较高，包括整体图和细节图。商品主图是吸引顾客眼球的必要利器，不论是列表页，还是活动页，顾客除了关注价格，主要就是商品主图，运营上架时需慎重选择商品主图。
商品详情页现在一般会区分电脑版和手机版，由于两者的使用场
试读结束[说明：试读内容隐藏了图片]