为优化用户在手机中的推送消息体验，解决 “用户无法分辨并自主控制真正想要收到的消息”这类问题，我们将消息分为：系统消息、运营消息两个类别进行管理。开发者需根据自身应用的通知场景，将消息内容按照对应消息类别发送。
一、分类说明
根据用户对推送内容的关注程度，划分为“系统消息”、“运营消息”两个消息类别，不同类别对应不同的权限，消息类别及对应权限的映射关系如下：
| 消息类别 | 划分原则 | 允许发送的内容 | 增量申请方式 | 管控规则（总量管控+频控管控） | 接入方式 |
| 系统消息 | 用户对收到此类消息有预期，并需要及时知道的消息，如果错过可能会导致不良影响。 | • 即时消息• 邮件• 用户设置的提醒• 物流• 订单• 待办待阅读• 财务• 功能提醒详细内容参考文中消息分类场景说明 | 邮件申请，申请模板及要求见下文 | 此接口已对外公开总量管控：默认等于3倍的用户订阅数，免费申请增量频控管控：单用户单应用每天收到的消息条数无上限 | 开发者接口设置参数（classification=1），开发文档详见《服务端API接口文档》 |
| 运营消息 | 用户对收到此类消息无预期，关注程度较低。 | 除“系统消息”允许发送内容以外的内容推荐、活动推荐、社交动态等通知。详细内容参考文中消息分类场景说明 | 商务申请 | 此接口已对外公开总量管控：默认等于1倍的用户订阅数，商务申请增量频控管控：单用户单应用每天收到的消息条数上限5条 | 开发者接口设置参数（classification=0），开发文档详见《服务端API接口文档》 |
注意： Funtouch OS_10及以上版本已取消消息盒子，取消盒子正在向OS10之前版本覆盖。
二、消息分类场景说明
1.【系统消息】场景概述
系统消息接口仅允许即时消息、邮件、用户设置的提醒、物流、订单、待办待阅读、财务、功能提醒8类消息推送：
| 序号 | 系统消息类型 | 场景概述 | 具体场景 |
| 1 | 即时消息 | 聊天消息（私信、私聊、群聊） | 包括聊天消息中的图片、文件传输、语音/视频通话，不包括官方号或者商家批量推送给用户的私信、广告 |
| 2 | 邮件 | 邮件的发送、接收状态信息 | 如：邮件发送成功提醒、收到新邮件通知等 |
| 3 | 用户设置的提醒 | 用户在APP内主动设置的提醒信息或弹窗确认会收到推送的提醒信息 | 如：设置的签到打卡提醒；主动设置的开播提醒、书籍更新、付费的订阅内容更新等；设置的商品或机票降价、商品开团提醒等 |
| 4 | 物流 | 物流节点信息 | 包括收发货，派送，签收，取件通知等 |
| 5 | 订单 | 订单生成信息及订单状态变化 | 如：下单成功、卖家收到新订单、订单详情、订单状态、物流状态、订单售后、订单投诉处理进度、开票信息等 |
| 6 | 待办待阅读 | 个人事项提醒（用户待处理业务流程或者待阅读的通知） | 如：审核进度提醒、认证状态等网址转app流程提醒；商品库存不足、商品售罄、商品下架等通知；工单处理、限制提现、客诉警告、店铺限制、商品黑名单、交易违规、涉假/涉欺诈发货等通知；常旅信息到期、证件过期等提醒；路况提醒、行程通知、出行服务生成的检票、到达、延误、晚点等行程通知等 |
| 个人状态变化 | 包括账号上下线、账号信息认证、等级权限变更等 | ||
| 个人设备提醒 | 包括智能设备、监控设备的系统提醒、设备报警等 | ||
| 7 | 财务 | 个人交易提醒 | 包括收付款、银行到账&扣款、催缴&退款信息、充值，涉及金额、账单、交易提醒、贷款受理进度、还款/逾期提醒、资金冻结提醒、资金限制提醒、缴纳保证金提醒、红包到账（非促销类红包）等 |
| 个人资源变化（用户有偿的虚拟资源及非促销类增值服务变化提醒） | 包括用户个人的虚拟财产如积分/余额等变更提醒，以及增值服务的充值/到期/续费/到账提醒等（虚拟财产必须是非促销类的, 促进用户增长的领金币或促销类红包/优惠券不属于“系统消息”） | ||
| 8 | 功能提醒 | 用户操作了系统功能后的结果通知 | 如：“共享单车已关锁还车，点击查看详情” |
2.【运营消息】场景描述
不允许通过系统消息接口发送运营消息，包括但不限于广告、推广、活动等对用户有主动运营作用的推送，或者其他非用户主动触发的信息；未订阅的影音视听内容、商品推广、宣传，或者折扣、红包、领劵优惠信息等。
| 序号 | 运营消息类型 | 场景描述 |
| 1 | 内容推荐 | 非用户主动订阅，APP向用户推送的资讯、内容。如：微博、资讯、新闻、点评、小说、广告、视频、音频、直播等等 |
| 2 | 陌生人推荐 | 大V、主播、异性、可能认识的人等 |
| 3 | 金融理财 | 金融理财产品推荐。 如：投资、贷款、股票、基金、贵金属等 |
| 4 | 促销活动及推荐 | 商品推广、宣传、折扣、红包、领劵、返现等优惠信息；推荐产品功能、服务更新，商品、商家、店铺推荐的内容，例如“您的授信额度增加” |
| 5 | 业务到期提醒 | 提醒用户保险、医疗、水电到期续保续费，或者话费、会员等月结日充值提醒等服务续期类推送 |
| 6 | 运营活动 | 各类APP内非用户主动设置的需用户参与的活动提醒消息、小游戏提醒、服务或商品评价提醒等。 如：抽奖、积分、签到、任务、分享、偷菜、领金币等 |
| 7 | 天气 | 天气预警提醒 |
| 8 | 社交动态 | 用户之间的社交互动提醒，如：添加好友、被赞、被@、评论、留言、关注、转发、回复 |
| 9 | 订阅信息 | 关注的人发布作品，如：关注的人直播提醒、动态更新 |
3.特殊场景消息归档
以下特殊场景可按消息归档模板提供相应材料发至邮箱push@vivo.com申请归为系统消息中的“用户设置的提醒”：
①【社交动态】满足以下交互要求可申请归为系统消息：弹窗和用户确认将收到该类别的PUSH通知，用户可选择“接收”或“取消”，选择接收后可加入“系统消息”分类。如顾客对门店的点评提醒、老师对作业的点评提醒可申请归为系统消息。
②【订阅信息】满足以下交互要求可申请归为系统消息： 用户点击订阅后，弹窗和用户确认将收到该类别的PUSH通知，用户可选择“接收”或“取消”，选择接收后可加入“系统消息”分类。如关注的主播开播提醒、特别关注的账号/作者发布动态属于【用户设置的提醒】类“系统消息”，而普通关注了账号/作者且未确认动态更新会推送的动态更新属于【订阅信息】，只能从运营消息接口发送。
特殊场景消息归档模板（仅限运营消息中社交动态、订阅信息）
| 邮件标题： Vpush系统消息归档申请 – 应用名称 | ||
| 邮件正文：您好，因我司应用XX（应用名称）部分消息属于用户主动订阅，参考《推送消息分类说明》，判断以下场景符合“用户设置的提醒”，申请归档为系统消息，请vivo推送团队核实。应用名称：XXAppId：XXXX应用包名：XXXX | ||
| 消息模板说明 | 消息模板/样例（标题+内容） | 证明材料（弹窗截图/录屏） |
| 例：房源动态变更通知 | 标题：你关注的【****】，有新上房源内容：点击查看 | |
| 注意：消息模板说明是指消息的内容类别，如：设置的签到打卡、开播提醒、书籍更新、付费订阅内容更新、商品或机票降价、商品开团提醒等。需要列举所有希望归档为系统消息发送的消息模板。 |
三、开发者接入流程
1．通过API传入相应参数
①系统消息只能通过API接口创建，web端运营平台暂不支持此功能。API接口新增请求字段classification，“0”代表运营消息，“1”代表系统消息，不填默认为0。
②相关错误码（开发文档详见《服务端API接口文档》）
10073：系统消息发送量总量超出限制
10082：系统消息开关未打开
2．智能分类二次修正
①参数传“0”代表运营消息，不经过智能分类二次修正，直接从运营消息总量扣除额度，并受用户接收条数限制的频控；
②参数传“1”代表系统消息，经过智能分类二次修正，若智能分类识别出不是系统消息，会自动修正为运营消息，并扣除运营消息额度；若识别为系统消息，则从系统消息总量扣除额度。
③部分特殊情况下，会出现误判，智能分类可能会将系统消息判定为运营消息。发生此情况时，请按下面误判反馈邮件模板填写发送至：push@vivo.com
| 主题：XX应用消息分类误判反馈内容：……应用名称（含包名）：……误判类型：系统消息误判为运营消息误判消息：逐条展示（超过5条必须附上表格明细）附件：误判消息明细 |
④开发者通过邮件反馈智能分类误判情况，平台再通过线上纠错，减少反馈的消息类型误判情况。
四、消息分类接入规范
1．严格限制系统消息发送量级和发送消息类型
①限制发送量级：默认3倍SDK订阅数的系统消息量级。
②若无法满足系统消息的实际需求量级，可以单独额外申请。需要保证申请量级完全符合实际推送量级，禁止申请后又不使用的情况发生，平台会根据实际情况下调系统消息量级。（系统消息量级申请请使用下方邮件模板）
③限制发送的系统消息类型：目前仅限于前文中即时消息、邮件、用户设置的提醒、物流、订单、待办待阅读、财务、功能提醒8类消息允许推送。
2．不允许通过系统消息接口发送运营消息
包括但不限于广告，推荐，推广，活动等对用户有主动运营作用的推送，或者其他非用户主动触发的信息；未订阅的影音视听内容、商品推广、宣传，或者折扣、红包、领劵优惠信息等。
五、运营监管及处罚
vivo推送平台日常巡查消息分类的接入情况，如发现推送内容不符合要求的，将进行违规处罚，特别是将运营消息通过系统消息渠道滥发的将会严格处罚。
1．违规界定
对于开发者违规滥用系统类消息，包括：使用系统消息通道发送运营消息、用户投诉消息产生打扰。
常见运营消息类型如：
①消费优惠类通知、商品降价类通知、商品更新提醒类通知等一些涉及消费的营销类通知。
②涉及红包、卡券、优惠券、积分类消息偏社交属性的推送
③关注的主播发表作品、评论、点赞、回复等消息
2．运营监管
平台将按消息分类标准，对API接口字段classification为“1”的消息（即系统消息）进行每日巡检，巡查开发者以系统消息渠道发送运营消息的情况，并按违规程度及频次进行相应处罚，最高将关闭消息推送功能。
3．处罚标准
根据违规程度，执行以下处罚标准：
处罚与整改同步进行，违规处罚应用需按要求限期整改，接受处罚并提供整改排期，整改完成后邮件通知vivo推送平台并全量发布。
逾期未整改完成需提前邮件申请延长整改时间并说明缘由，逾期无故未整改，视为再次违规，进入下一档处罚。
违规整改期结束后，后续点检如再次出现违规行为，将视为新一轮违规并执行相应处罚。
| Vpush通知系统消息渠道滥用处罚规则 | ||
| 若违规量级过大，vivo推送平台将视影响范围/严重程度/违规频次，酌情加重处罚措施 | ||
| 违规频次 | 处罚内容 | 整改期限 |
| 首次 | 邮件警告 | 30个自然日 |
| 第二次 | 降低系统消息日推送量级20% | 14个自然日 |
| 第三次 | 降低系统消息日推送量级50% | 7个自然日 |
| 第四次 | 暂时关闭系统消息推送功能，直至整改完成 | — |
| 开通系统消息1倍SDK订阅量 | 观测14个自然日 | |
| 开通系统消息2倍SDK订阅量 | 观测14个自然日 | |
| 恢复至默认配置（即3倍SDK订阅量） | — |
① 降低系统消息日推送量级在应用现有量级上计算；开通系统消息量级在3倍SDK订阅量级上计算。
② 第四次违规整改完成后，开发者需提交恢复申请，平台将梯度开通系统消息日推送量级，梯度时间结束后开发者需再次发送恢复申请，进入下一个梯度观测。
③ 若梯度观测时违规，将再次暂时关闭系统消息推送功能。若梯度观测无违规，将在30个自然日后恢复系统消息量级，此后再次违规将重新计次。
注意：处罚期间，开发者不得以系统消息量级不足申请额外增量
4、整改排期
如应用因违规而被限制系统消息推送权限，接收处罚通知后需向push@vivo.com发送“系统消息渠道违规整改排期”，并附上整改内容。
整改排期模板
| 邮件标题：Vpush系统消息渠道违规整改排期 – 应用名称 | |
| 邮件正文：您好，我司应用XX（应用名称）于XXXX年XX月XX日，被vivo推送团队告知由于XX触发系统消息渠道滥用违规。当前，我司根据相关规范进行整改，整改完成后将邮件同步整改结果。同时，我司承诺：不再出现利用系统消息渠道发送运营消息的行为。应用名称：XXAppId：XXXX应用包名：XXXX整改排期：XXX整改完成时间：XXX （须在对应整改期限内） | |
| 整改内容：经排查，以下消息不符合系统消息分类规则，现改为通过运营消息渠道发送。 | |
| 消息类别 | 消息模板/样例（标题+描述） |
| 注意：消息类别是指消息的内容类别，如：新闻资讯、营销活动、社交动态提醒等。需要列举所有整改的消息类别，每一种类别至少列举一种消息模板或样例（包括消息标题和描述）。 |
5、误判申诉申请
如应用因误判违规而被限制系统消息推送权限，可向push@vivo.com发送“系统消息误判申诉”，并附上误判类型及示例。
消息误判申诉模板：
| 邮件标题： Vpush系统消息误判申诉 – 应用名称 | |
| 邮件正文：您好，我司应用XX（应用名称）于XXXX年XX月XX日，被vivo推送团队告知由于XX而被降低/关停系统消息推送能力。参考《推送消息分类说明》，认为以下消息为系统消息误判为运营消息，请vivo推送团队核实。应用名称：XXAppId：XXXX应用包名：XXXX | |
| 申请内容：以下消息我司认为符合系统消息分类规则，申请继续使用系统消息渠道发送。 | |
| 消息类别 | 消息模板/样例（标题+描述） |
| 注意：消息类别是指消息的内容类别，如：新闻资讯、营销活动、社交动态提醒等。需要列举所有希望继续使用系统消息渠道发送的消息类别，每一种类别至少列举一种消息模板或样例（包括消息标题和描述）。 |
6、恢复权益申请
如应用因违规而被限制系统消息推送权限，可在整改完成后向push@vivo.com发送“系统消息推送权益恢复申请”，并附上整改报告。
整改完成恢复权益模板：
| 邮件标题： Vpush系统消息推送权益恢复申请 – 应用名称 | |
| 邮件正文：您好，我司应用XX（应用名称）于XXXX年XX月XX日，被vivo推送团队告知由于XX而被降低/关停系统消息推送能力。当前，我司已根据相关规范对违规消息进行整改，整改报告见附件。同时，我司承诺：不再出现使用系统消息渠道发送运营消息的行为。请vivo推送团队：恢复XX（应用名称）的系统消息推送权益。应用名称：XXAppId：XXXX应用包名：XXXX | |
| 申请内容：经排查，以下消息不符合系统消息分类规则，现已改为通过运营消息渠道发送。 | |
| 消息类别 | 消息模板/样例（标题+描述） |
| 注意：消息类别是指消息的内容类别，如：新闻资讯、营销活动、社交动态提醒等。需要列举所有整改的消息类别，每一种类别至少列举一种消息模板或样例（包括消息标题和描述）。 |
vivo推送团队收到申请后，将对应用提交的整改报告进行审核巡检，如审核通过将恢复该应用的系统消息推送权限。
申请通过恢复权限后，平台再次监控到违规消息，将视为新的违规。
六、常见问题
Q1：什么时候开始进行运营消息频控？
为保证用户不被过多的运营消息打扰，平台将从2020年6月1日起，对运营消息进行每日频控限制，即单用户接收单个应用每天推送的运营消息条数上限为5条；
Q2：一直不接入消息分类会有什么负面影响？
若未接入消息分类，将导致所有消息默认按照运营消息类别下发，受到用户接收条数频控限制；
Q3:如果将社交动态、订阅信息等运营消息误传为系统消息怎么办？
线上智能分类会进行2次修正，线下将会按照处罚标准进行处罚；
Q4:系统消息量级不够用怎么办？
若系统消息量级不够用，可以邮件特殊申请实际需求的系统消息量级，按照下面的邮件模板填写信息后发送至邮箱：push@vivo.com
| 主题：xxx应用申请增加im消息/系统消息发送量级正文：……应用名称：……应用ID：……包名：……应用简介：……系统消息需求量级：……（申请后总量）数据佐证：……具体推送场景说明：如即时消息（应用内用户聊天消息）、订单（订单状态变化消息） |
编辑：yimen，如若转载，请注明出处：https://www.yimenapp.com/kb-yimen/12121/
部分内容来自网络投稿，如有侵权联系立删
