用于办公平台的统一消息管理系统

技术领域

本发明涉及消息管理技术领域，具体涉及了一种用于办公平台的统一消息管理系统。

背景技术

如今是信息时代，不管是个人还是企业，每天都会发送和接收到形形色色的消息。比如通过邮箱获取，打开手机app的自动推送的消息，手机渠道接收到的渠道消息。

目前，对于消息发送方来说，向消息接收方进行消息推送，主要是通过接口的形式，消息发送发的信息推送系统通过向提供进行消息推送的推送渠道业务方提供数据对接的数据接口，将需要发送的业务消息，通过渠道推送给消息接收方。

而对于大型企业或是政务部门来说，自身的业务系统数量庞大。例如在有业务办理部门，需要向进行业务办理的客户通知业务办理的期限，在业务推销部门，需要向目标客户推送广告消息，在宣传部门，需要向广泛用户发送宣传信息等等。不同部门对于消息推送的方式不同，有的的短信推送，有的是APP推送，有的是公众号推送等，又由于每个业务部门的需要推送业务消息的内容以及时间不同，因此通常来说，每个业务部门都独立、独自地管理并掌握着自身的业务消息推送管理。因此，对具有业务消息推送具有需求的业务部门，都是以各自业务系统提供与推送渠道业务方的数据接口，容易造成与推送渠道业务方数据接口的冗余，同时各个业务系统均需要和推送渠道的接口进行对接，造成推送的业务消息分散，如果需要对已经发送的业务消息进行追溯，需要从发送消息的业务部门进行调取，无法对所有业务部门发送的业务消息统一进行查看和管理，并且内部业务系统提供的与外部推送渠道业务方的数据接口过多，对于政务部门来说，内部系统本身的安全性造成影响。

发明内容

本发明意在提供一种用于办公平台的统一消息管理系统，能够对业务系统的消息集中，通过不同的推送渠道，推送给消息接收方。

本发明提供的基础方案：一种用于办公平台的统一消息管理系统，包括服务器，所述服务器包括系统管理模块、消息接收模块、渠道选择模块、消息推送模块、推送判断模块；

系统管理模块，用于管理接入的业务系统，以及录入各个业务系统的消息接收方；

消息接收模块，用于接收业务系统发送的业务消息，以及业务系统所选择的消息接收方；

渠道选择模块，对接各类推送渠道，用于获取业务系统所选择的推送渠道，推送渠道可以为一种或多种；

消息推送模块，用于将业务消息通过业务系统所选择的推送渠道，推送给消息接收方；

推送判断模块，用于获取业务消息是否推送到消息接收方，若未推送到，则通过消息推送模块再次进行推送。

本发明的原理在于：系统管理模块对接入的业务系统进行管理，企业或政务部门中的各类业务系统直接与本方案中的统一消息管理系统对接，系统管理模块提供数据接口，与各业务系统进行数据对接，并在对接完成后负责业务系统的接入后的管理。业务系统接入之后，可以预先绑定进行业务消息推送的推送渠道。业务系统在接入过后，可以录入各自的消息接收方的接收路径。当业务系统需要向消息接收方推送业务消息时，使用者通过业务系统，将业务消息编辑好过后，向服务器发送业务消息，以及选择业务消息所要发送的消息接收方，服务器在接收到业务消息和消息接收方后，首先根据消息接收方查找接收路径，之后，根据业务系统所绑定的推送渠道中，选择一种或者多种推送渠道，将业务消息推送给消息接收方。之后获取业务消息是否成功的推送到消息接收方，若是未推送到，这再次进行推送，保证消息能够成功推送到消息接收方处。

相比于现有技术，具有以下优点：

1.通过对各业务系统的业务消息进行集中推送，业务系统的主体方只需要与服务器进行接口对接即可，无需再单独和其他外部渠道进行对接，由服务器与各个推送渠道进行统一接口对接。服务器接收到消息后，根据业务系统的选择将业务消息通过各种渠道推送给消息接收方。对外而言，减少内部业务系统与外部推送渠道进行数据对接的数据接口数量，并且不同外部推送渠道只需要提供一个数据接口，避免了对外提供数据接口的冗余，同时提高内部系统的安全性。对内而言，具有业务消息推送需求的业务部门，只需要与服务器进行数据对接即可，在内部规范好数据对接的标准，在日后新的具有消息推送的业务部门时，能够更加便捷地使用上业务消息推送的服务。

2.将各个业务系统的业务消息，通过统一消息管理系统集中后统一发布，各个业务系统发送的业务消息都会在服务器中被统一被记录存储，当在日后对业务消息进行查看或追溯时，直接从服务器中调取到历史发送的历史消息，各业务部门也无需再单独存储已经发送过的业务消息，从而便于对各个业务系统所发送的业务消息进行集中统一的管理。

进一步，所述服务器还包括敏感词模块，所述敏感词模块包括识别模块和优化模块；

识别模块，预设有敏感词词库，用于在接收到业务消息后，识别业务消息中是否包含有敏感词；

优化模块，用当业务消息中存在敏感词时，对敏感词进行替换或去除。

识别业务消息中是否包含有敏感词，通过预先设置敏感词库，识别业务消息中是否包含敏感词库中敏感词，当存在敏感词时对敏感词进行替换和去除，从而避免将含有敏感词的业务消息推送给消息接收方。

进一步，所述敏感词模块还包括优化分析模块，所述服务器还包括消息退回模块；

优化分析模块，用于判断对敏感词进行替换或去除后的业务消息，与原始业务消息是否具有歧义；

消息退回模块，用于当具有歧义时，将业务消息返回业务系统；

消息推送模块，还用于当不具有歧义时，才将业务消息推送给消息接收方。

若业务系统编辑的业务消息中存在敏感词，在对敏感词进行替换或者去除过后，判断经过替换或者去除敏感词后的业务消息，与原本的业务消息之间是否具有歧义，可通过现有的语义识别算法进行实现。若是具有歧义，则将业务消息退回给业务系统，使使用者对业务消息重新进行编辑后发送。

进一步，所述服务器还包括有等级获取模块，所述渠道选择模块包括提醒等级模块以及等级推送模块；

等级获取模块，用于获取业务消息的及时等级，所述业务消息包括及时等级依次降低的紧急业务消息、通知业务消息以及日常业务消息；

提醒等级模块，预设有各个推送渠道的提醒等级，推送包括提醒等级依次降低的短信推送、微信公众号推送、手机APP推送以及邮箱推送；

等级推送模块，用于根据业务消息的及时等级，选择不同提醒等级的推送渠道。

对业务消息进行及时等级划分，紧急业务消息为需要快速使消息接收方知晓的业务消息，例如极端天气预警、业务逾期告警，通知业务消息为通知消息接收方在某个时间节点前需要知晓的消息，例如考试通知、业务办理通知等。日常业务消息为日常普通消息，如天气预报、近期活动等。推送渠道也包括不同提醒等级的推送渠道，根据业务消息的及时等级，选择不同提醒等级的推送渠道进行推送。

进一步，所述服务器还包括已读判断模块；

已读判断模块，用于在将业务消息推送给消息接收方后，获取推送渠道反馈的已读反馈，将接收到已读反馈的消息标记为已读反馈给业务系统。

通过推送渠道反馈，推送的业务消息是否已读，并将已读的业务消息进行标记，反馈给业务系统，使业务系统能够对业务消息的推送情况进行了解。

进一步，所述服务器还包括时间获取模块、时段分析模块；

时间获取模块，用于获取业务系统向消息接收方推送业务消息的上传时间；

时段分析模块，用于获取消息接收方的个人数据，并根据个人数据分析消息接收方的时段数据，所述时段数据包括工作时段以及空闲时段；

等级推送模块，还用于当业务消息为紧急业务消息或通知业务消息，且在消息接收方工作时段时，采用提醒等级低的推送渠道向消息接收方推送业务消息，并根据预设的等待时长，在等待时长过后，获取业务消息是标记为已读，若未标记为已读，则采用提醒等级更高的推送渠道再次进行推送。

通过获取到消息接收方的个人信息，确定消息接收方的工作时段和空闲时段，在工作时段时，首先采用提醒等级较低的业务消息。例如对于紧急业务消息首先采用微信公众号进行推送，对于通知业务消息，首先采用手机APP的方式进行推送。在一段时间过后，获取业务消息是否已读，若是业务消息没有被标记为已读，则采用提醒等级更高一级的推送渠道进行推送。通过这种方式，在消息接收方的工作时段，首先采用提醒等级较低的推送方式，若是其当前工作不是特别繁忙，通过提醒等级较低的推送方式，便能够使其查看到已经推送的业务消息，后续也不再进行推送。若是在消息发送的时段，消息接收方当前工作较为繁忙，在第一次推送时，通过提醒等级较低的推送方式无法引起其注意，因此不会在消息接收方较为繁忙的时候打扰其工作。当过一段时间过后，若是推送的业务消息仍然没有被标记为已读，有可能是其仍然较为繁忙，也有可能是其忙过之后，没有注意到之前推送的业务消息。此时通过提醒等级更高一级的推送方式，由于紧急业务消息和通知业务消息都具有一定的时限性，在发出通知过后，若消息接收方仍然未读，此时便通过提醒等级较高的推送方式进行推送，保证消息接收方能够及时查看到业务消息。

通过本方案中的方式，对于紧急业务消息和通知业务消息，若是在消息接收方的工作时段进行推送，优先采取不会打扰其正常工作的推送方式进行推送，若消息接收方当前工作不繁忙，通过提醒等级较低的推送方式，便能够推送得到。从而提高用户体验度。

进一步，等级推送模块中，业务消息的及时等级越高，预设的等待时长越短。

及时等级越高，等待时长越短，若是消息接收者未读消息，以更快的速度通过更有效的同时方式将消息推送给消息接收者。

进一步，所述识别模块，还用于识别出业务消息中的截止期限；

所述等级推送模块，还用于根据上传时间和截止期限，调整等待时长，上传时间与截止期限之间的间隔时间越长，等待时长越长。

进一步，所述服务器还包括渠道统计模块，用于统计周期内各个业务系统使用推送渠道向消息接收方推送业务信息的使用情况，所述渠道统计模块包括使用统计模块、查收统计模块、统计反馈模块；

使用统计模块，用于统计各个推送渠道的使用次数；

查收统计模块，用于根据业务消息是否标记为已读，分别统计各个业务系统通过各个推送渠道推送给消息接收方的业务消息的已读率；

统计反馈模块，用于将周期内推送渠道的使用情况，反馈给所属的业务系统。

对业务系统的使用情况进行统计，在每个周期统计出各个业务系统进行消息推送所采用的推送渠道的使用情况。包括有周期内的推送渠道的使用次数，以及各个推送渠道推送给消息接收方的业务消息的已读率。将统计得到的推送渠道的使用情况反馈给业务系统。

进一步，所述服务器还包括渠道筛选模块；

渠道筛选模块，根据各个推送渠道的使用情况，筛选出非必要渠道；

渠道选择模块，还用于当业务系统向消息接收方推送业务消息的推送渠道有多个，且包含非必要渠道时，不选择非必要渠道。

根据推送渠道的使用情况，筛选出非必要渠道，当推送渠道的使用率较低或者时某个推送渠道推送的消息已读率较低时，停用推送渠道，降低资源占用率，节省成本。

附图说明

图1为本发明用于办公平台的统一消息管理系统实施例的逻辑框图。

具体实施方式

下面通过具体实施方式进一步详细说明：

实施例基本如附图1所示：

用于办公平台的统一消息管理系统，包括服务器，服务器包括系统管理模块、消息接收模块、渠道选择模块、消息推送模块、推送判断模块、敏感词模块、等级获取模块、已读判断模块、时间获取模块、时段分析模块，

系统管理模块，用于管理接入的业务系统，以及各个业务系统的消息接收方。具体的，本方案中的统一消息管理系统，对内提供统一的借口，与各个业务系统进行数据对接。业务系统接入过后，可以进行推送渠道的管理，以及录入自身业务接收方的信息以及推送路径。

消息接收模块，用于接收业务系统发送的业务消息，以及业务系统所选择的消息接收方。当业务系统要向消息接收方发送业务消息时，在自身系统上编辑好业务消息的内容，上传到服务器，并选择出该条业务消息的消息接收方。本实施例中支撑批量选择以及搜索选择。通过向业务协同展示其关联的消息接收方列表，通过勾选的方式选择出本次业务消息发送的消息接收方。

敏感词模块，包括识别模块、优化模块和优化分析模块。

识别模块，预设有敏感词库，用于在接收到业务消息后，识别业务消息中是否包含有敏感词。本实施例中，使用现有的整理好的敏感词库。通过识别业务消息中是否包含有敏感词库中的敏感词。

优化模块，当业务消息中有敏感词时，对敏感词进行替换或去除。当识别得出业务消息中包含敏感词库中的敏感词时，查找敏感词的近义词进行替换，若是不存在近义词，则对敏感词进行去除。

优化分析模块，用于判断对敏感词进行替换或去除后的业务消息，与原始业务消息是否具有歧义。在对敏感词进行去除或替换过后，通过现有的语义识别算法，对优化后的业务消息以及优化前的业务消息进行语义识别，比对是否具有歧义。若是没有歧义便可直接发送，若是具有歧义，则将业务消息返回给业务系统，并标注出敏感词。

渠道选择模块，对接有各类推送渠道，用于获取业务系统所选择的推送渠道，推送渠道可以为一种或多种。消息推送模块，用于将业务消息通过业务系统所选择的推送渠道，推送给消息接收方。具体的，对外通过渠道选择模块与各类推送渠道进行对接，本实施例中，推送渠道包括有短信推送、微信公众号推送、手机APP推送以及邮箱推送。短信推送为对接三大运营商平台，通过三大运营商平台以短信的方式发送业务消息。微信公众号为对接微信平台，以公众号通知的方式发送业务消息。手机APP为采用定制APP的方式向安装有手机APP的消息接收方用户发送业务消息。邮箱推送为对接各大电子邮箱平台，以电子邮件的方式推送业务消息，本实施例中采用腾讯企业邮箱。

等级获取模块，用于获取业务消息的及时等级，业务消息包括及时等级依次降低的紧急业务消息、通知业务消息以及日常业务消息。具体的，业务系统在编辑好业务消息后，可以选择业务消息的及时等级，及时等级包括有紧急业务消息、通知业务消息以及日常业务消息。具体的，紧急业务消息为需要快速使消息接收方知晓的业务消息，例如极端天气预警、业务逾期告警，通知业务消息为通知消息接收方在某个时间节点前需要知晓的消息，例如考试通知、业务办理通知等。日常业务消息为日常普通消息，如天气预报，近期活动等。

渠道选择模块包括有提醒等级模块和等级推送模块。

提醒等级模块，预设有各个推送渠道的提醒等级。本实施例中，推送等级由高到低依次为短信推送、微信公众号推送、手机APP推送以及邮箱推送。

等级推送模块，用于根据业务消息的及时等级，选择不同提醒等级的推送渠道。例如对于日常业务消息，采用手机APP推送和邮箱推送。对于通知业务消息，采用手机APP推送和微信公众号推送，紧急业务消息采用微信公众号推送和短信推送。

推送判断模块，用于获取业务消息是否推送到消息接收方，若未推送到，则通过消息推送模块再次进行推送。通过获取到各个推送渠道的推送回执，判断是否成功推送到消息接收方，若未成功推送到消息接收方，则再次进行推送。

已读判断模块，用于在将业务消息推送给消息接收方后，获取推送渠道反馈的已读反馈，将接收到已读反馈的消息标记为已读反馈给业务系统。具体的，对于邮箱推送，通过电子邮件平台可以监控邮件是否已读。手机APP推送，通过APP管理平台可以监控APP消息是否已读。对于微信公众号推送，可以通过监控公众号的访问情况判断消息是否已读。

时间获取模块，用于获取业务系统向消息接收方推送业务消息的上传时间。时段分析模块，用于获取消息接收方的个人数据，并根据个人数据分析消息接收方的时段数据，时段数据包括工作时段以及空闲时段。具体的，本方案中的消息接收方都为个人，通过获取到消息接收方的个人数据，分析消息接收方的工作时段以及空闲时段。本实施例中，通过获取到消息接收方的工作单位信息以及岗位信息，根据工作单位和岗位信息确定出消息接收方的上班时间以及下班时间，从而确定出消息接收方的工作时段以及空闲时段。

等级推送模块，还用于当业务消息为紧急业务消息或通知业务消息，且在消息接收方工作时段时，采用提醒等级低的推送渠道向消息接收方推送业务消息，并根据预设的等待时长，在等待时长过后，获取业务消息是标记为已读，若未标记为已读，则采用提醒等级更高的推送渠道再次进行推送。等级推送模块中，业务消息的及时等级越高，预设的等待时长越短。具体的，本实施例中，对于紧急业务消息和通知业务消息，若是上传业务消息的时间在消息接收方的工作时段，首先采用提醒等级较低的推送方式。例如，对于通知业务消息，首先采用手机APP推送方式，将业务消息推送给消息接收方。之后，已读判断模块获取推送渠道反馈的已读反馈。在经过等待时长过后，等级推送模块识别之前推送的业务消息，是否已经被标记为已读，若是已经标记为已读，则不再进行推送，若是没有被标记为已读，则通过更高一级的推送渠道进行推送，在经过等待时长过后，若是没有被标记为已读，则采用微信公众号推送的方式进行推送。本实施例中，根据业务消息的及时等级，设定等待时长，业务消息的及时等级越高，等待时长越短。在本申请的其他实施例中，识别模块还用于识别业务消息中的截止期限。例如对于通知消息、业务逾期消息，通常在业务消息中会标注出截止日期，通过识别模块对业务消息语义进行识别，得到业务消息中的截止日期。得到截止日期过后，等级推送模型，根据业务消息的上传时间以及截止时间，计算时间差得到间隔时间，间隔时间越长，等待时长越长。

实施例二

本实施例和实施例一的区别在于，本实施例中，还包括有渠道统计模块，渠道统计模块用于统计周期内各个业务系统使用推送渠道向消息接收方推送业务消息的使用情况。渠道统计模块具体包括有使用统计模块、查收统计模块、统计反馈模块。

使用反馈模块，用于统计各个渠道的使用次数。具体的，在业务系统通过各个推送渠道进行业务消息的推送时，没推送成功一条业务消息，便记录下某个业务系统使用某个推送渠道的次数加一。在周期结束时，统计出本周期内，各个业务系统使用各个推送渠道的总次数。本实施例中，以一个月为一个周期。

查收统计模块，用于根据业务消息是否标记为已读，分别统计各个业务系统通过各个推送渠道推送给消息接收方的业务消息的已读率。具体的，本实施例中，需要业务消息在规定时间内已读，在统计时才会统计为是已读消息，若是业务消息发出后，消息接收方未在规定时间内已读的话，在统计时也会被标记为未读消息。通过查收统计模块，统计出周期内，业务系统使用各个推送渠道推送给消息接收方的业务消息的已读率。

统计反馈模块，用于将周期内推送渠道的使用情况，反馈给所属的业务系统。通过统计反馈模块，将业务系统关于各个推送渠道的使用次数，消息已读率反馈给业务系统。

渠道筛选模块，根据各个推送渠道的使用情况，筛选出非必要渠道。

渠道选择模块，还用于当业务系统向消息接收方推送业务消息的推送渠道有多个，且包含非必要渠道时，不选择非必要渠道。

实施例三

本实施例和实施例一的区别在于，本实施例中，服务器还包括已读率获取模块、渠道排序模块、调整标记模块以及渠道调整模块；

已读率获取模块，用于分别获取预设周期内各个业务系统通过各个推送渠道向消息接方推送业务消息的消息已读率；

渠道排序模块，用于分别对各个业务系统所使用的推送渠道，发送业务消息的消息已读率进行排序；

调整标记模块，用于识别是否有业务系统所使用的推送渠道发送业务消息的消息已读率排序，与预设的推送渠道的提醒等级不同，若是则对对应的业务系统添加渠道待调整标记；

渠道调整模块，用于识别具有渠道待调整标记的业务系统的消息已读率中，相邻排序之间的推送渠道的消息已读率差值是否大于预设限值，若是，则根据消息已读率排序，对该具有渠道待调整标记的业务系统的推送渠道的提醒等级进行调整。

具体的，服务器对内对接各多个业务系统，对外对接有各种推送渠道。已读率获取模块，分别获取到各个业务系统，所使用的推送渠道的业务消息的消息已读率。例如业务系统A所使用的有短信推送、微信公众号推送、手机APP推送，则获取业务系统A，使用短信推送的业务消息的已读率，微信公众号推送的业务消息的已读率，以及手机APP推送的业务消息的已读率。业务系统B使用的推送渠道有手机APP推送和邮箱推送，则获取业务系统B使用手机APP推送业务消息的已读率和邮箱推送业务消息的已读率。

渠道排序模块，对各个业务系统使用的推送渠道，发送业务消息的消息已读率进行排序。将各个业务系统所使用的推送渠道，按照已读率由高至低进行排序，如业务系统A，使用短信推送的消息已读率为40%，使用手机APP推送的消息已读率为20%，使用邮箱推送的消息已读率为80%。则已读率排序为：1.邮箱推送。2.短信推送。3.手机App推送。

调整标记模块对已读率排序进行识别，判断是否与预设的提醒等级具有区别。预设的提醒等级为由高到低依次为短信推送、微信公众号推送、手机APP推送以及邮箱推送。按照上述示例中，第一为邮箱推送，第二为短信推送，则邮箱推送、短信推送的排序与预设的提醒等级发生了变化。

渠道调整模块，识别具有渠道待调整标记的业务系统的消息已读率中，相邻排序之间的推送渠道的消息已读率是否大于预设限值。当发生变化后，识别相邻排序是否大于预设限值，例如识别邮箱推送和短信推送的已读率差值是否大于预设的限值，本实施例中，预设限值为20%。若已读率差值大于预设限值，则根据已读率排序对提醒等级进行调整，即对于该业务系统，调整后的推送渠道的提醒等级从高到低依次为邮箱推送、短信推送、手机APP推送。

由于不同的业务系统，所发送的业务消息类型不同，所面向的用户群体不同。不同用户群体可能存在常用的消息接收方式不同。因此根据不同渠道的消息已读率进行排序，识别得到各个推送渠道的消息已读率，对不同业务系统的推送渠道的提醒等级进行调整。

实施例四

本实施例和实施例一的区别在于，本实施例中，还包括周期统计模块、系统标记模块、

周期统计模块，用于根据各个业务系统历史统计周期中推送渠道的使用情况，得到各个业务系统的标准参考数据，所述标准参考数据包括总消息条数、总已读率、各渠道消息条数、各渠道已读率；

系统标记模块，用于将最新的统计周期内的使用情况，与各个业务系统的标准参考数据进行比对判断，若总消息条数和总已读率在预设的变化阈值内，则标记为第一业务系统，否则标记为第二业务系统；

将第二业务系统在最新的统计周期内推送渠道的使用情况与上一统计周期内推送渠道的使用情况进行比较，分别判断总消息条数和总已读率的变化趋势，所述变化趋势包括上升趋势和下降趋势，若总消息条数和总已读率的变化趋势相同，或总已读率不变，则判断为正常变化，若总消息条数和总已读率变化趋势不同，则判断为非正常变化；

若非正常变化的第二业务系统中，总消息条数呈上升趋势或在变化阈值内，而总已读率呈下降趋势，则识别该第二业务系统已读率呈下降趋势的推送渠道，并计算已读率呈下降趋势的推送渠道推送的消息条数，若呈下降趋势的推送渠道推送的消息条数在总消息条数中的数量占比高于预设的第一占比阈值，则在下一统计周期降低该推送渠道推送的业务消息数量并根据已读率选择推送的消息接收方，若低于预设的第二占比阈值，则在下一统计周期取消该推送渠道；

若非正常变化的第二业务系统中，总消息条数呈下降趋势或在变化阈值内，而已读率呈上升趋势，则将该该第二业务系统中已读率呈上升趋势的推送渠道的消息接收方的用户画像，将该推送渠道与所识别的用户画像绑定；

消息推送模块还用于根据用户画像绑定推送渠道进行业务消息推送。

具体的，对统计周期内各个业务系统的使用情况进行统计，并根据各个统计周期的使用情况得到标准参考数据，标准参考数据包括有总消息条数、总已读率、各渠道消息条数以及各渠道的已读率。本实施例中，标准参考数据为取近半年内各个统计周期的平均值。

之后将最新的统计周期内的业务系统关于推送渠道的使用情况与标准参考数据进行比对，如将最新的统计周期内的中消息条数与标准参考数据中的总消息条数进行比对，将最新的统计周期内的总已读率与标准参考数据中的总已读率进行比对等。若是总消息条数和总已读率在预设变化阈值内，即最新周期内的推送渠道的使用情况与标准参考数据相比变化较小，则标记为第一业务系统，否则标记为第二业务系统。

对于第二业务系统，根据其总消息条数和总已读率的变化趋势，判断是否为正常变化，当总消息条数和总已读率变化趋势相同，或者是总已读率不变，则认为是正常变化，若是总消息条数与总已读率变化趋势不同，即总消息条数提升，而总已读率下降，或者是总消息条数下降，而总已读率提升，则认为是非正常变化。

对于总消息条数呈上升趋势，而总已读率呈下降趋势的第二业务系统，识别出其已读率呈下降趋势的推送渠道，并计算出通过该推送渠道发送的业务消息，占总消息条数的数量，若是占比较高，则在下一统计周期降低该推送渠道推送的业务消息数量并根据已读率选择推送的消息接收方，若是占比较低，则在下一统计周期取消该推送渠道。以此对不重要的推送渠道进行筛除。

以上的仅是本发明的实施例，方案中公知的具体结构及特性等常识在此未作过多描述，所属领域普通技术人员知晓申请日或者优先权日之前发明所属技术领域所有的普通技术知识，能够获知该领域中所有的现有技术，并且具有应用该日期之前常规实验手段的能力，所属领域普通技术人员可以在本申请给出的启示下，结合自身能力完善并实施本方案，一些典型的公知结构或者公知方法不应当成为所属领域普通技术人员实施本申请的障碍。应当指出，对于本领域的技术人员来说，在不脱离本发明结构的前提下，还可以作出若干变形和改进，这些也应该视为本发明的保护范围，这些都不会影响本发明实施的效果和专利的实用性。本申请要求的保护范围应当以其权利要求的内容为准，说明书中的具体实施方式等记载可以用于解释权利要求的内容。