本发明涉及消息推送领域，特别涉及一种基于场景与用户行为的消息推送方法。
背景技术：
目前，移动互联网技术迅猛发展，智能手机功能不断创新，手机已经完全融入人们的生活。手机媒体已经成为继报纸、广播、电视、互联网之后的第五大媒体。基于移动互联网的电子商务和旅游业同样在迅速发展当中，人们的网购和生活方式也在悄然的改变。然而，服务质量不高、信息不全、个性化服务不到位等问题成为影响这些产业发展的重要问题。因此需要一种高效的推荐方法解决上述问题。
定位服务又叫做移动位置服务.它是通过电信移动运营商的网络(如GSM网、CDMA网)获取移动终端用户的位置信息。位置服务是融合了移动通信技术、空间定位技术、地理信息系统技术(GIS，Geographic Information System)、分布式计算技术、嵌入式数据库技术和互联网技术的高科技产业。而今位置服务业务范围已经涉及个人位置信息服务、相关信息查询、POI查询、路径规划、实时导航、物流管理、紧急救援、天气状况查询、路况信息查询等各种行业的不同服务。基于位置的服务能够利用电信运营商的软件硬件资源获得移动终端用户的地理位置信息例如地理位置坐标等。在GIS(Geographic Information System，地理信息系统)系统平台的支撑下，能够带来相应服务的经济增长。
传统的基于内容和基于位置的消息推荐技术存在诸多缺陷，比如信息负载过大、有用信息过少、消息推送正确率低等，导致推荐结果并不理想。用户主要还是凭借“签到”和查询方式获取信息。
技术实现要素：
本发明的主要目的在于克服现有技术的缺点与不足，提供一种基于场景与用户行为的消息推送方法，不仅仅局限于基于内容的消息推荐方式，而是结合场景和用户行为信息进行消息推送。
本发明的目的通过以下的技术方案实现：
一种基于场景与用户行为的消息推送方法，包括以下步骤：
S1、在终端设备的App中嵌入SDK，初始化设置并运行；
S2、利用终端设备的定位功能获取位置信息，判断触发地理围栏并是否进入特定区域；
S3、如果触发并进入特定区域，则通过SDK采集特定的场景信息与用户行为信息，并发送到服务端处理；
S4、服务端根据当前场景信息与用户行为信息，筛选出多条与之相关的消息，构成待推送消息集合；
S5、选取评分最高的一条消息推送给App，通过SDK做可视化处理；
S6、采集用户对所推送的用户行为信息，反映此条消息对用户价值，用于反馈和评价该推荐方式。
所述SDK，其能够生成标识该终端设备的唯一标识符CID，然后与服务端建立一个双向通道，用于发送采集的用户数据和接收推送的个性化消息。
所述终端设备包括智能手机、平板电脑。
所述特定区域包括商圈、景点。
所述场景信息、用户行为信息包括位置信息、时间天气信息、网络信息、用户设备信息、用户最近使用的应用信息、消息的浏览时间。
所述步骤S4，具体为：，服务端结合用户画像，融合场景数据和用户行为数据，计算出该用户最可能感兴趣的消息集合，选取相似度最高的一个，实现应景推送；通知可以结合用户近期一些具有时效性的数据，提供基于历史场景的消息推送。
所述评分最高的一条消息的推送方式包括以下方式：纯文本、通知栏提示、应用内弹窗。提醒用户接收到服务端的新消息。
本发明与现有技术相比，具有如下优点和有益效果：
本发明可以弥补传统推荐系统的不足，同时也更好的减小了用户面临的信息超量负载问题。结合用户的当前场景和行为的应景推送，可以向用户推荐更加符合当前场景的信息；结合协同过滤算法与用户画像，进一步提高了该推送服务的目标性和针对性，满足了用户对个性化消息的需求，避免了“大海捞针”式和“狂轰滥炸”式的消息推送方式。
消息推送也是“双刃剑”。精准及个性化的消息推送可以提升信息和客户端的品牌价值，增强用户的好感度。但无效信息往往会引起用户强烈的反感。因此，除了信息发布速度、信息内容质量、应用程序用户体验之外，消息推送同样需要掌握好方法和技巧。拥有一套支持第三方安全接入的、具有良好性能和高可靠性的云推送平台，是实现消息推送的基础。为了保证推送服务的质量，需要考虑该云平台的性能问题、可靠性问题以及安全问题。Reactor模式就是服务器设计过程中的一种重要思想。Reactor模式首先是事件驱动的，即将一个或多个客户的服务请求分离(demultiplex)和调度(dispatch)给应用程序。在事件驱动的应用中，同步地、有序地处理同时接收的多个服务请求。
附图说明
图1是本发明所述一种基于场景与用户行为的消息推送系统的结构示意图。
图2是本发明所述一种基于场景与用户行为的消息推送方法的流程图。
图3是推送服务的示意图。
图4是地理围栏管理的流程图。
具体实施方式
下面结合实施例及附图对本发明作进一步详细的描述，但本发明的实施方式不限于此。
实施例1
如图1、2、3、4，一种基于场景与用户行为的消息推送方法，包括以下步骤：
1、Android App嵌入SDK，初始化并运行。该SDK会生成一个用于标识该设备的唯一标识符CID，然后与服务端建立一个双向通道用于发送采集的用户数据和接收推送的个性化消息。
2、首先动态申请Android系统的相关权限，然后利用Android设备的定位功能，获取位置信息。最后与预设的地理围栏作对比，判断是进入、处于还是离开特定区域，比如商圈、景点等等。如图四所示。
3、SDK初始化完毕后，负责采集场景信息和用户行为信息，这些信息包括位置信息、时间天气信息、网络信息、用户设备信息、用户最近使用的应用信息等。
4、通过移动网络，SDK会将采集的实时数据上报到服务端，由服务端进行处理和分析，最后筛选出多条符合用户当前场景的消息，实现应景推送；结合用户近期一些具有时效性的数据，提供一种基于历史场景的消息推送方法。
5、集成该SDK的Android App具有将收到的消息可视化的功能，即在Android端以“纯文本”、“通知栏提示”和“应用内弹窗”三种方式，提醒用户接收到服务端的新消息。
6、采集用户对新消息的行为数据，比如记录用户是否打开该消息，浏览该消息的时长以及用户对此消息的评分等数据，反应用户是否对该条消息感兴趣，以此判断评价该推荐方法的优劣。
如图3，该消息推送云平台提供多种接入方式，包括：
Android SDK接入、Web端直接控制方式和Server SDK接入。
1、Android SDK接入。Android App在开发过程中集成该SDK。在初始化并运行后，Android App可以和消息推送云平台建立一个双向链接，一方面用于将采集的场景数据和用户行为数据上报到云平台，另一方面用于接收云平台推送的个性化消息，并通过“通知栏提示”、“应用内弹窗”和“纯文本”三种方式做新消息提醒。
2、Web端直接控制方式。第三方企业用户通过Web端直接登录管理台页面，配置相关参数，添加或删除待推送消息，查看消息推送相关数据，比如成功率和准确率等。Web端为用户提供友好的图形界面，操作简单直接。
3、Server SDK接入。面对数据量大且频繁的消息推送管理设置，第三方企业用户可以通过Server SDK接入方式，操作灵活。Server SDK初始化并运行后，会创建一个服务端的代理对象，第三方企业用户通过与该代理对象交互，可以管理云平台的相关数据。除此之外，第三方企业用户可以跳过Server SDK，直接调用REST API接口进行访问。
实施例2
一种基于场景与用户行为的消息推送方法，包括以下步骤：
1、Android App嵌入SDK，初始化并运行。该SDK会生成一个用于标识该设备的唯一标识符CID，然后与服务端建立一个双向通道用于发送采集的用户数据和接收推送的个性化消息。该CID用ANDROID_ID表示。ANDROID_ID是Android系统第一次启动时产生的一个64bit(16BYTES)数，可以通过Settings.Secure.getString()方法获得。如果设备被wipe还原后，该ID将被重置(变化)，否则将永远不会改变。因为ANDROID_ID的唯一性和不易改变的特性，所以比较适合用于唯一标识用户信息。
2、首先动态申请Android系统的相关权限。由于Android系统的安全性不断增强，使用部分功能时需要提示用户，并在得到允许后方可操作。因此需要通过ContextCompat.checkSelfPermission()方法检查用户是否允许获取位置权限。如果没有授权，将通过调用ActivityCompat.requestPermissions()方法去动态的申请相关权限。如果用户点击同意，则可以成功获取定位权限，进行下一步动作。当用户禁止授权后，还可以通过弹窗，再次提醒用户并对相关权限的使用原因做出解释。通过这样一系列的操作，保证能够顺利Android设备的相关权限。这些权限主要包括：
<uses-permission
android:name＝"android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission
android:name＝"android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission
android:name＝"android.permission.INTERNET"/>
然后利用Android设备的定位功能，获取位置信息。
在Android系统中，通过调用
getSystemService(getApplicationContext().LOCATION_SERVICE)
方法获取LocationManager。LocationManager可以用来获取当前的位置，追踪设备的移动路线，或设定敏感区域，在进入或离开敏感区域时设备会发出特定警报。在获取LocationManager之后，还需要指定LocationManager的定位方法。LocationManager的Location Provider有多种，包括NETWORK_PROVIDER、GPS_PROVIDER、PASSIVE_PROVIDER和FUSED_PROVIDER等。但是其中LocationManager主要有两种定位方式，分别为网络定位和GPS定位。在选定合适的定位方式后，通过locationManager.getLastKnowLocation()方法获取当前位置信息，如经度、维度和速度等。
最后与预设的地理围栏作对比。主要通过预设的地理围栏的中心点，计算当前位置与中心点的距离。再和地理围栏的半径作对比，判断是进入、处于还是离开特定区域，比如商圈、景点等等。
3、SDK初始化完毕后，负责采集场景信息和用户行为信息，这些信息包括位置信息、时间天气信息、网络信息、用户设备信息、用户最近使用的应用信息等。其中，用户设备信息包括用户手机品牌和型号、Android系统版本、当前设备电量以及在最近一定时间内的唤醒次数等等。
统计系统中其它App的使用信息，需要权限
<uses-permission
android:name＝"
android.permission.PACKAGE_USAGE_STATS"/>
与获取位置权限不同，申请该权限首先需要通过
getSystemService(Context.APP_OPS_SERVICE)
方法获得AppOpsManager对象，然后通过checkOpNoThrow()方法检查是否具有相关权限。如果没有，会弹出设置页面，由用户手动授予。最后成功获得相关权限。UsageStatsManager是Android系统5.0版本之后提供的一个统计App使用信息的类，通过
context.getSystemService(Context.USAGE_STATS_SERVICE)
方法可以获取该UsageStatsManager类的一个实例usm。通过
usm.queryUsageStat()和usm.queryEvents()
方法，可以获取所有App的近一天、一周、一个月和一年的使用情况。
4、SDK会将采集的数据封装到UBCDataInfo类中。然后通过移动网络，将采集的数据按照Json格式上报到服务端，由服务端进行处理和分析。服务端结合用户画像，通过对传统的系统过滤算法的改进，融合场景数据和用户行为数据，计算出该用户最可能感兴趣的消息集合，实现应景推送；通知可以结合用户近期一些具有时效性的数据，提供基于历史场景的消息推送。
5、在收到云推送平台的个性化消息后，该SDK会以“纯文本”的方式通知Android App。除此之外，集成该SDK的Android App具有可视化的功能：在Android系统中，调用SDK可以定制Notification和Dialog，实现“通知栏提示”或者“应用内弹窗”功能，提醒用户接收到服务端的新消息。
6、集成的Android SDK会监听所定制Notification和Dialog控件的行为，主要采集用户对新消息的行为数据，比如记录用户是否打开该消息，浏览该消息的时长以及用户对此消息的评分等数据。这些数据会封装到UBCMsgInfo类中，然后按照Json格式上报到服务端。服务端会根据这些反馈数据判断用户是否对该条消息感兴趣，以此评价这次推荐的优劣。
该云平台支持多种接入方式，具体实施步骤包括：
1、Android SDK接入。Android App在开发过程中集成该SDK。调用UBCAppSDK.init()方法进行初始化并运行。之后，Android App可以和消息推送云平台的MQTT服务器建立双向链接，一方面用于将采集的场景数据和用户行为数据上报到云平台，另一方面用于接收云平台推送的个性化消息，并通过“通知栏提示”、“应用内弹窗”和“纯文本”三种方式做新消息提醒。
2、Web端直接控制方式。云推送平台提供Web端管理接口，向第三方企业用户提供配置相关参数，添加或删除待推送消息，查看消息推送相关数据，比如成功率和准确率等服务。Web端为用户提供友好的图形界面，操作简单直接。
3、Server SDK接入。面对数据量大且频繁的消息推送管理设置，第三方企业用户可以通过Server SDK接入方式，操作灵活。调用UBCServerSDK.init()方法，Server SDK进行初始化并运行。之后会创建一个服务端的代理对象。该代理对象通过向云推送平台发送HTTP请求的方式进行数据传递。平台第三方企业用户通过与该代理对象交互，可以管理云平台的相关数据。对于非JAVA平台，可以直接调用该服务端的REST API，进行消息推送的设置和管理。
多种接入方式为用户提供的不同选择，大大增加了该系统的灵活性。Android SDK和Server SDK对系统接口做了良好的封装，方便调用，减少了开发人员的工作量；对于非JAVA平台，也可以调用REST API进行访问。
上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。