简介这份《运营商家庭标准化产品库方案》PPT梳理了运营商家庭业务从产品现状、分场景解决方案到融合营销套餐的完整规划逻辑适合通信行业产品经理、渠道运营人员以及从事家庭宽带、智能家居、智慧社区相关业务的一线人员参考。内容覆盖家庭宽带、互联网电视、IMS固话、智能硬件及咪咕增值服务等自有产品并分欢乐的家、安全的家、舒适的家、健康的家、智慧的家等场景给出标准化产品组合思路还结合户型与家庭人群特点提出推荐方案能帮助读者快速建立面向家庭客户的产品体系框架与精准营销思路。资源包共1个文件文件类型为PPTX整体大小约341KB。当前已有179人学习下载适合需要理解家庭产品库两级管理机制、学习分场景方案设计与融合套餐打包方法的从业者作为汇报或培训参考素材。1. 家庭产品口径混乱标准库比新系统更迫切运营商做家庭市场多年宽带、IPTV、融合套餐、智慧组网、看家安防一堆产品散落在各省系统里。同一个“千兆宽带”在A省叫“十全十美千兆版”在B省叫“畅享千兆”在C省干脆挂在“智慧家庭礼包”里当附加项。渠道问起来口径不一客服查不到准确定义后端计费配置靠人工比对出账差错又多又难定位。多数人以为换一套CRM就能解决实际上缺的不是系统是一份能约束所有下游系统的“标准答案”。“运营商家庭标准化产品库方案”要做的事就是把散落在合同、价表、BOSS、电子渠道里的产品定义收拢成一份统一模型产品编什么码、挂在哪个目录、规格属性有哪些、状态怎么流转、可以和哪些产品组合下单。它不是PPT里的概念图是一套能落库、能校验、能对接受理开通的数据资产。这篇文章按我自己做运营商数据治理时惯用的打法来讲先立模型再建表再讲生命周期和规则编排最后给一组验证指标。适合正在做家庭产品梳理、BOSS域改造或者数据中台建设的同学参考。2. 标准化产品库的三层模型目录、规格、实例分离2.1 为什么家庭产品必须区分目录、规格和实例家庭业务的典型特点是组合多、个体差异大。用户办理“融合宽带 500M IPTV 看家”在受理界面是一张订单在计费侧拆成三条产品实例在渠道侧展示为“全家享套餐”。统一编码的前提是先拆层否则一物一号根本做不到。我一般把产品定义拆成三层产品目录Product Catalog、产品规格Product Spec、产品实例Product Instance)。目录管“怎么找”规格管“是什么”实例管“给谁用”。产品目录服务的是检索和货架管理类似电商的分类树。家庭业务下通常挂两条子目录销售目录和技术目录。销售目录给营业厅和线上渠道看叫“融合套餐”“单产品”“增值业务”技术目录给开通和计费系统用叫“宽带接入”“IPTV承载”“终端租用”。两边通过规格编码做映射而不是各建一套产品名。产品规格是所有下游共用的标准模板。编码唯一属性收敛状态受控。它不绑定某个用户只描述这个产品“可售卖、可开通、可计费”的特征。拿“千兆宽带”举例规格层面要定义带宽值、接入方式、资费模式、是否含终端、是否可单独退订。这些属性字段的取值不是自由文本必须来自数据字典。产品实例是用户侧的真实订购记录。一条实例必然引用一个规格编码带上服务地址、生效时间、订购渠道、开通工单号。层与层之间通过规格编码串联任何时候都能从实例反查到“用户买的是哪个目录下哪个规格”。2.2 属性收敛规格字段越少越容易标准化拆完层之后最容易翻车的是属性膨胀。业务方今天加一个“光猫版本”明天加一个“安装费减免标志”后天再来一个“营销活动来源”。字段越加越多最后规格表退化成一张Excel登记表标准库的“标准”二字就名存实亡。属性收敛我通常按四个口径来卡计费口径、开通口径、服务口径、稽核口径。计费口径管“怎么收钱”比如月费、一次性费用、减免规则开通口径管“怎么交付”比如接入技术、终端型号、施工时限服务口径管“坏了怎么修”比如是否含上门、是否支持移机稽核口径管“怎么验证”比如是否参与净推荐值统计、是否计入融合率。拿一个“智慧看家基础版”规格举例计费口径是月功能费10元开通口径是摄像头型号“看家mini 2”服务口径是远程调阅保留7天稽核口径是纳入智家业务渗透率分母。四个口径合起来十几个字段足够支撑一个产品从上架到结算跑通。凡是这四个口径之外的需求一律作为扩展属性放到附加表里改扩展属性不触发规格表结构变更。2.3 用“产品编码”把规格钉死在命名规则上模型分层之后还要在编码上做约束。不然规格表建好了编码还是会乱。家庭产品编码我建议用段式结构不要用流水号。段式编码的常见形式是“业务域-产品大类-产品子类-序列号-版本号”业务域固定两位家庭业务统一取“HJ”产品大类两位宽带为KD电视为DS组网为ZW看家为KJ产品子类两位代表该大类下的细分形态序列号四位由产品库统一分配版本号两位每次规格变更加一。比如“HJ-KD-GQ-0001-V01”是千兆宽带基础款“HJ-KJ-KJ-0003-V01”是看家基础版。编码规则一定要写进产品库系统的校验逻辑里而不是写在制度文件里。提交新规格时程序自动检查前缀组合是否合法、序列号是否重复、版本号是否已存在。这样从源头拦住手工乱造编码比事后查重可靠得多。3. 把产品库落地成表和接口一个可直接抄的小型实现3.1 核心表结构设计规格主表、属性表、关联规则表模型讲清楚了落地先建库。下面是按“规格主表 属性扩展表 关联约束表”的思路给出的建表SQL。这套结构删减过不是生产级别完整版但骨架足够个人项目或小团队验证使用。-- 产品规格主表 CREATE TABLE product_spec ( id BIGSERIAL PRIMARY KEY, spec_code VARCHAR(32) NOT NULL UNIQUE, -- 段式产品编码 spec_name VARCHAR(128) NOT NULL, catalog_id INT NOT NULL, -- 目录ID关联产品目录表 category VARCHAR(16) NOT NULL, -- 宽带/IPTV/看家等大类枚举约束 status VARCHAR(16) NOT NULL DEFAULT DRAFT, -- DRAFT/ACTIVE/SUSPENDED/RETIRED owner_domain VARCHAR(64) NOT NULL, -- 责任部门或系统域 version INT NOT NULL DEFAULT 1, effective_date DATE NOT NULL, expire_date DATE, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() ); -- 规格属性扩展表 CREATE TABLE product_spec_attr ( id BIGSERIAL PRIMARY KEY, spec_id BIGINT NOT NULL REFERENCES product_spec(id), attr_code VARCHAR(32) NOT NULL, -- 属性编码如 RATE_MODE attr_value VARCHAR(256) NOT NULL, -- 属性值 UNIQUE(spec_id, attr_code) ); -- 产品关联规则表 CREATE TABLE product_relation_rule ( id BIGSERIAL PRIMARY KEY, from_spec_code VARCHAR(32) NOT NULL, to_spec_code VARCHAR(32) NOT NULL, relation_type VARCHAR(16) NOT NULL, -- DEPEND/EXCLUDE/UPSELL effective_date DATE NOT NULL, expire_date DATE );逻辑说明规格主表只放稳定字段可变属性全部推进属性扩展表。spec_code承担全局唯一约束几个关键字段用状态和日期来做版本生效控制。属性扩展表用UNIQUE(spec_id, attr_code)约束同一规格下属性不重复这样新增属性不需要改表结构。关联规则表用来描述产品间的依赖和互斥后面第4章会展开。参数说明status字段四个取值对应规格生命周期的四个状态代码里必须用约束或检查约束保证取值合法effective_date和expire_date是软启停开关查询时要用“当前日期落在有效区间内”作为过滤条件不要只依赖状态位。3.2 写一个批量导入器Excel拆解成规格落库产品梳理阶段业务侧给到的大多是Excel。能不能把Excel干净地导入库里决定了标准和实际之间的距离。导入工具的核心不在读取在校验。import pandas as pd import psycopg2 from datetime import date xls pd.ExcelFile(家庭产品梳理_v3.xlsx) df xls.parse(规格清单, dtypestr).fillna() conn psycopg2.connect(host127.0.0.1 dbnameproduct_catalog userops password***) cur conn.cursor() errors [] inserted 0 expected_head [spec_code, spec_name, catalog_id, category, status, effective_date, expire_date] for idx, row in df.iterrows(): if not row.get(spec_code) or not str(row[spec_code]).startswith(HJ-): errors.append(f行{idx 2}: spec_code缺失或非HJ前缀) continue if len(str(row[spec_code]).split(-)) ! 5: errors.append(f行{idx 2}: 编码段数不正确: {row[spec_code]}) continue if row[status] not in (DRAFT, ACTIVE, SUSPENDED, RETIRED): errors.append(f行{idx 2}: 非法状态值: {row[status]}) continue if row[effective_date] row[expire_date]: errors.append(f行{idx 2}: 生效晚于失效: {row[spec_code]}) continue if row[category] not in (BROADBAND, IPTV, MESH, CAMERA): errors.append(f行{idx 2}: 非法业务分类: {row[category]}) continue cur.execute( INSERT INTO product_spec (spec_code, spec_name, catalog_id, category, status, effective_date, expire_date, version) VALUES (%s, %s, %s, %s, %s, %s, %s, 1) ON CONFLICT (spec_code) DO UPDATE SET spec_name EXCLUDED.spec_name , (row[spec_code], row[spec_name], int(row[catalog_id]), row[category], row[status], row[effective_date], row[expire_date])) inserted 1 if errors: print(校验失败导入中止共, len(errors), 条错误) for e in errors[:20]: print(e) conn.rollback() else: conn.commit() print(f成功导入 {inserted} 条规格)逻辑说明整个导入流程先做数据质量拦截再落库拦截项包括编码前缀、编码段数、状态合法性、日期区间合法性、业务分类合法性。一旦出现任何一条错误整体回滚避免半截导入导致库内标准不一致。参数说明业务分类枚举按家庭产品形态预先固定下来Excel里的写法是中文名还是英文编码都可以建议直接用英文编码减少一层映射ON CONFLICT处理重复规格码的情况这里图示为更新名称实际生产中建议换成版本号加一保留历史版本轨迹。3.3 对外查询接口按规格编码还是按目录树下钻产品库最终要被CRM、渠道、计费系统调用接口设计需要同时支持两种查询模式精确查规格和目录树下钻。# 精确查询规格详情 curl -X GET http://catalog-api.example.com/api/v1/specs/HJ-KD-GQ-0001-V01 \ -H token: 内部调用token # 按销售目录下钻取某目录下所有有效规格 curl -X GET http://catalog-api.example.com/api/v1/catalog/1003/specs?active_onlytruepage1size50 \ -H token: 内部调用tokenGET 响应中规格详情必须把主表字段和属性扩展表字段合并返回前端和调用方不需要关心属性到底存哪张表。按目录下钻时接口要自动过滤掉status ! ACTIVE或expire_date 当前日期的数据这是最容易漏掉的地方。很多调用方拿到的规格列表里一堆已停售产品就是因为查询接口没做有效期过滤。需要把“可用规格”与“全量规格”做成两个独立接口防止下游误用。4. 产品生命周期和组合规则售前售中售后都围着一份状态机走4.1 家庭规格的四个状态草稿、生效、停售、退市产品库的生命周期是“谁在什么时间能做什么”的单一事实来源。家庭产品规格的状态我从简设计为四个草稿、生效、停售、退市这是电信行业比较常见的归属生命周期定义。草稿状态表示规格已录入但未审核通过。库内数据可以增删改但对外接口查不到渠道和计费系统都不可见。家庭产品里经常有“新套餐试运行”在试运行期间就应该挂在草稿状态。生效状态表示规格可以面向用户销售所有下游系统以此状态为唯一可售标志。停售状态表示不对新用户销售但老用户续约、变更时仍然可用。退市状态表示规格彻底退出后台系统和接口都不再返回该数据。退市不是删除出现历史账单要查的时候还得能溯源。状态机里的关键点是流转条件。草稿到生效需要完成属性完整性校验生效到停售需要确认无新单流入停售到退市需要满足“无在用实例”。家庭业务的常见坑是宽带类产品在合约期内的用户不会被立刻清退停售到退市的间隔至少保持一个完整合约周期否则会造成在网用户游街。如果开发资源足够加一张规格操作审计表记录每一次状态变更的执行人、时间、原因、原状态、目标状态。出了账务问题这张表是定位责任人的第一现场。4.2 规则表加规则引擎依赖、互斥、升级用配置不要改代码产品库最容易积累技术债的地方是“组合规则”被埋进业务流程代码里。比如“千兆宽带可以单独办理”“500M融合套餐与IPTV增值包互斥”“看家摄像头依赖家庭宽带”。这些规则散落在前后端判断逻辑里业务方改一次开发改一次测试回归一次运维再发一次版一个礼拜过去了。标准做法是把组合规则也收进产品库做成“规则配置 通用校验引擎”。第3章里的product_relation_rule就是干这个用的。三种关系类型建议尽早固定依赖A产品必须有B产品才能办理互斥同一个账务下A和B不能并存升级关联办A时推荐同时办理B。还可以加一个“需审批”类型用于白名单产品。执行校验收口到一个方法改变规则不用动代码public class ProductRelationValidator { private static final String DEPEND DEPEND; private static final String EXCLUDE EXCLUDE; public void validate(String specCode, ListString existingCodes, ListProductRelationRule rules) { ListString errors new ArrayList(); for (ProductRelationRule rule : rules) { if (!specCode.equals(rule.getFromSpecCode())) { continue; } if (DEPEND.equals(rule.getRelationType())) { if (existingCodes null || !existingCodes.contains(rule.getToSpecCode())) { errors.add(缺少依赖产品: rule.getToSpecCode()); } } if (EXCLUDE.equals(rule.getRelationType())) { if (existingCodes ! null existingCodes.contains(rule.getToSpecCode())) { errors.add(与已有产品互斥: rule.getToSpecCode()); } } } if (!errors.isEmpty()) { throw new IllegalArgumentException(String.join(; , errors)); } } }逻辑说明fromSpecCode是本次要办理的产品existingCodes是用户账务下已有的产品列表。规则引擎只做两件事依赖检查时判断已有产品列表里是否包含目标编码互斥检查时判断是否包含即报错。规则数据来自配置表加一条规则就是往表里插一行数据。参数说明rules参数通常一次查全量或按fromSpecCode过滤量小直接全量加载到内存缓存existingCodes必须包含用户账单级和产品实例级两类产品编码否则容易漏判。家里挂着宽带和IPTV用户新办融合套餐的场景既要把单产品编码放进去也要把融合产品的累计列表放进去互斥判断才能覆盖完整。4.3 生命周期稽核在读报表和写接口两层都要卡状态配置好状态和规则只是第一步真正防呆的是把生命周期约束落到数据读写两层。读接口只返还有效规格写接口只接收有效规格编码。产品库对外开放的写操作通常只有两条新增实例和变更实例。新增实例时产品库必须拦截“停售”“退市”状态的规格编码变更实例时则要检查老规格和新规格的状态是否都允许挂在这个账务下面。在实操中还需要注意一个边界产品库的“生效状态”与CRM的“可售状态”可以不同步。CRM侧会有自己的促销活动比如“皎月专属千兆宽带”挂在系统里是独立SKU但产品库里不必为每一个促销SKU建规格。产品库收的是“产品”不是“价格策略”促销活动指向哪个规格、以什么折扣售卖这些属于营销域配置。两者的边界用一句话划清产品库回答“能不能办”营销域回答“以什么价格办”。5. 用数据质量指标验收产品库库存准确、源头唯一、配置完整产品库建成后怎样验证建得好不好复盘时主要看三个指标。第一类是产品条目去重率和同质异构收敛度。家庭宽带、IPTV、看家业务全集团条目数量的合理区间在1000到2000条之间。如果某省梳理完还有8000多条一定存在重复造规格的情况。建议跑一段查重SQL作为基线资产按“业务域产品大类计费属性”分组同组内出现多条规格就要被判定疑似重复。高频处理完以后重复率应该降到5%以下。第二类是配置完整率与引用一致性。这个指标用来判断规范化配置的依赖规则是否被业务侧持续遵守。建议做两条巡检一是统计属性扩展表里的字段覆盖情况比如“是否含上行带宽”这个字段是否在所有宽带规格里都有取值二是统计有状态的规则表里的规则是否被业务受理日志实际触发过。规则没有命中未必是无效线索在于“完全没命中”的大概率是配置错了方向。第三类是模拟受理通过率每条在新目录下的销售规格都需要用一套真实的受理报文做一次“冒烟”测试确认可以顺利走完订单、计费、开通、竣工全流程。冒烟通过率达不到100%是对接链路还没走通。我的做法是每周跑一次自动化模拟受理覆盖每个“生效”状态的规格把失败规格和失败原因自动推送工单给负责人。跑一段时间后历史存量“能卖不能装”的问题会集中暴露出来这正是产品库建设的前期攻坚重点。产品库上线之后运营维护会变成高频日常。建议你在此基础上做一套规则表的变更审计把每个规则的增改时间、操作人、审批单关联起来。后续如果要嵌入订单中心做实时校验这套审计数据可以直接复用。产品库的建设核心不在技术选型或工程框架而在能不能把业务未来的每一次产品变化都纳入一份统一口径的受控体系。归档到一步合格就能省下以后无数个“对不齐”的晚上。本文还有配套的精品资源点击获取