概要
大多数电商分享都是针对实物电商，无法直接应用到虚拟商品交易。
本文是笔者在阿里、猿辅导建设电商中台时对于虚拟商品交易的经验总结，介绍了难点与解法。
经典电商
中台化的商品建设，不同于课程售卖等某一单一品类的售卖，突出的挑战是：不同商品所需要的数据模型不同。
经过多年的电商发展，业内普遍采用类目属性的方式进行KV化的管理。
类目一般分为前台类目和后台类目。
后台类目
后台类目又叫标准类目，通过关键属性、绑定属性、商品属性、销售属性，确定SPU、商品、SKU，公开资料相对较多，这里就不再赘述了。
后台类目是运营同学发布商品、管理商品、制定规则的依据，是标准化的信息。
前台类目
前台类目又叫导航类目，是前端导航与搜索的依据。
前后台类目的关系
商品本身的固有属性是稳定的，但是为了导购，运营同学会希望能够有不同的组合方式，为买家带来更好的体验。
对于类目系统而言，一套系统无法满足不同的两种场景。
这种情况下，通过调研传统商超发现同一个产品在货架和仓库的存储是不同的方式：
仓库相对固定，食品在食品区，洗护品在洗护品区；货架则会根据季节、销售情况、社会事件而随时调整；前台类目便是参考货架设计给成。
类目管理是一个相对复杂的事情，早期的前台类目一般是运营同学手动管理的，成体系的电商公司一般是自动化抽取，形成前后台类目一般是多对多的关系。
虚拟商品的三个难题
淘宝、天猫等实物电商与传统商超密切相关，设计过程中很多是参考传统商超而来。
但是做过虚拟商品交易的同学会发现，直接套用实物电商或者传统商超的思路、玩法，会发现很多地方玩不下去。
这其实反应了虚拟商品交易与实物商品交易的目的、场景、方式的不同，因此设计关注点、原则与实物电商也是有所差别的，具体的难题体现在三个方面：
管理难
实物电商，虽然有 B2B、B2C、C2C、B2B2C 等多种形式，然而实物本身固有属性是比较明确的。
但是对于虚拟商品，对于是否能够归为属性、是否需要归为属性，并没有很好的分类依据，标准化困难，进而导致定义、发布、维护困难。
导购难
通过属性与前台类目，实物电商可以轻松完成树状查找、搜索、个性化推荐等能力，十分适合商城的场景。
但是对于虚拟商品一般是针对多个业务线的商业化诉求的支撑，面临的场景没有典型性，如课程售卖可能会固定透出某些商品，付费会从各个内容进行商品透出。
传统的导购方式无法满足虚拟商品交易的复杂情况，是第二个难题。
交易难
实物售卖，更多的是对现有能力的扩充，如限购、发货等节点的实现相对统一。
但是对于虚拟商品，限购如同一个课程的不同期数不能重复购买、VIP时长上限，发货如发放课程资格、发放VIP时长，每个业务是完全不同的。
虚拟商品本身蕴含了比实物商品更多业务信息，如能否自动发货、是否VIP半价等业务信息，单纯依靠固有的物理属性是远远不足的。
如何抽象商品的业务信息，通过标准化的方式保证交易流程的高效有序进行，是第三个难题。
虚拟商品难题的解法
如何管理
功能组织隔离
功能上，虚拟商品的出发点是多业务的支持，虚拟商品多业务间，关联关系相对较弱，如搜题VIP和斑马体验课，商品的类目、属性没有直接关系。
组织上，不同虚拟商品的运营归属于不同部门，有隔离上的诉求，辅导的运营不能也不应该修改
虚拟商品管理的第一个方法是，根据业务线，将类目、属性彻底分离，符合功能和组织上的诉求，将前期不稳定因素，控制在一定范围之内。
自动化商品发布
对于中台角度，商品作为标准沉淀，而教研课程、媒体资讯等作为具体业务支撑不能作为中台的一部分。
对于运营同学，课程内存维护与售卖信息维护很有可能是同一个运营，要求运营在多个系统才能完成课程上架销售，并不是最优的选择。
因此商品发布通过 API 或 SDK，在售卖实体保存的同时，自动化根据模板创建、更新，是降低发布、管理复杂度的有效手段。
如何导购
前台类目
前台类目可以简单做，所需的场景也相对简单，如斑马课程完全不需要前台类目，小猿商城也仅仅为基本诉求，并非建设的重点。
配置化资源位
以南瓜课程、搜题 VIP 为例，固定位置推荐固定商品，适合由业务方自行维护。
内容付费
在视频、公众号等内容付费场景，内容会通过鉴权系统判断无权限时进行推荐，由具体业务方对接教研课程、媒体资讯，教研课程、媒体资讯提供商品信息。
智能推荐
传统零售的思路更多的是人找货，而新零售的出现更多的强调货找人，通过将用户标签化，导购系统主动将商品推荐给用户。
如何交易
扩展开发
标准、流程由被中台规定，业务方在具体扩展点完成个性化逻辑扩展，拥有约束下的较大自由度，边界收敛，变化可控。
对于实物商品，限购规则、发货规则以配置化为主；而对于虚拟商品，跟多的是扩展开发为主。
标签
交易个性化操作的对象很对情况下并非某一商品，而是某一类商品。
类目的粒度相对较粗，针对的跟多是物理层面的划分，无法满足丰富多样的划分需求。
对于临时或长期的商品划分诉求，通过商品打标的方式，可以快速、低成本的进行支持，虚拟商品活动较多，打标的诉求更多。
特征
属性描述了商品是什么，而业务信息则是描述商品怎样卖，两者虽然都是对商品的抽象，但是存在本质上的区别。
因此将商品的业务信息抽象为特征，是将业务信息标准化的重要手段。
特征的形式
特征相对于属性的是否必填、是否枚举、是否可输入、是否可多选，形式可能有文本框、多选框、时间选项、子选项等多种形式。
综合考虑易用性、可维护性，将每特征数据存储为JSON结构，特征的发布可以结合前端的可配置组件。
特征的使用
特征是业务信息的抽象，但是业务信息不仅商品存在，非叶子类目、叶子类目、SPU、SKU 都有抽象业务信息的可能，因此特征的存在维度相比属性是更为丰富的。
特征带来便捷性的同时一定程度上也增加了系统的复杂性，对于特征的使用需要遵守几个原则：
可以不用特征的，尽可能不用特征，如通过类目、标签可以完成判断的
只有一个业务方使用的，一定不是特征，因为特征解决的是中台层面的业务信息抽象，一定是可以复用的
虚拟商品功能建设
虚拟商品还权益管理、会员体系建设、自动续费等实物商品不具备的能力，这些不属于商品的范畴，在这里就不详细展开了。