一种基于日活数据的运营消息推送方法及系统与流程

1.本技术实施例涉及信息处理技术领域，尤其涉及一种基于日活数据的运营消息推送方法及系统。


背景技术：

2.随着互联网行业高速发展，智能终端应用程序(app)的功能日益多样。为了提高用户粘度，增加应用曝光，实现应用消息及时传递，提高业务营收等目的，很多应用程序的运营平台会给用户推送相应的运营消息，如活动宣传，咨询推送，广告通知等。目前，在进行运营消息推送时，一般会采用全量推送或者1对1推送的方式，通过运营消息推送来主动与用户进行交互，以此可以减少用户需求信息的搜索时间，使消息推送成为用户获取信息的一个重要途径。
3.但是，采用现有消息推送方式进行运营消息推送，会出现触达用户不精准的情况，低精度的消息推送会给用户带来不必要的打扰，同时使运营平台推送大量无用数据，增加运营成本。


技术实现要素：

4.本技术实施例提供一种基于日活数据的运营消息推送方法及系统，能够实现运营消息的多维度、精准推送，提升运营消息推送的灵活性，解决现有运营消息推送精度偏低的技术问题。
5.在第一方面，本技术实施例提供了一种基于日活数据的运营消息推送方法，包括：
6.获取用户的日活数据，基于所述日活数据确定多个维度的用户群体数据源；
7.获取推送内容和目标用户选择信息，基于所述推送内容和所述目标用户选择信息配置运营消息推送服务，所述目标用户选择信息用于选择指定维度的所述用户群体数据源所属的用户作为目标用户；
8.根据所述目标用户选择信息所选择的所述目标用户执行所述运营消息推送服务。
9.在第二方面，本技术实施例提供了一种基于日活数据的运营消息推送系统，包括：
10.获取模块，用于获取用户的日活数据，基于所述日活数据确定多个维度的用户群体数据源；
11.配置模块，用于获取推送内容和目标用户选择信息，基于所述推送内容和所述目标用户选择信息配置运营消息推送服务，所述目标用户选择信息用于选择指定维度的所述用户群体数据源所属的用户作为目标用户；
12.推送模块，用于根据所述目标用户选择信息所选择的所述目标用户执行所述运营消息推送服务。
13.在第三方面，本技术实施例提供了一种电子设备，包括：
14.存储器以及一个或多个处理器；
15.所述存储器，用于存储一个或多个程序；
16.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的基于日活数据的运营消息推送方法。
17.在第四方面，本技术实施例提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面所述的基于日活数据的运营消息推送方法。
18.本技术实施例通过获取用户的日活数据，基于日活数据确定多个维度的用户群体数据源；获取推送内容和目标用户选择信息，基于推送内容和目标用户选择信息配置运营消息推送服务，目标用户选择信息用于选择指定维度的用户群体数据源所属的用户作为目标用户；根据目标用户选择信息所选择的目标用户执行运营消息推送服务。采用上述技术手段，通过用户日活数据确定出不同维度的用户群体数据源，选择不同用户群体数据源进行运营消息推送服务的配置，可以实现运营消息的多维度、精准推送，提升运营消息配置的灵活性，并减少应用运营平台的运营成本。
附图说明
19.图1是本技术实施例提供的一种基于日活数据的运营消息推送方法的流程图；
20.图2是本技术实施例中用户日活数据的处理流程图；
21.图3是本技术实施例用户群体数据源的生成示意图；
22.图4是本技术实施例推送流程的触发流程图；
23.图5是本技术实施例以运营消息推送服务的处理流程图；
24.图6是本技术实施例提供的一种基于日活数据的运营消息推送装置的结构示意图；
25.图7是本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
26.为了使本技术的目的、技术方案和优点更加清楚，下面结合附图对本技术具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
27.本技术提供的一种基于日活数据的运营消息推送方法，旨在通过处理用户日活数据确定用户不同位置的用户群体数据源，进而在进行运营消息编辑时，选择相应维度的用户群体数据源进行运营消息推送，以此来优化提升运营消息的推送精度，减少运营投入成本。对于传统的运营消息推送方式，其主要是采用1对1推送或者全量推送的方式，这种推送方式容易导致触达用户不精准，给用户带来不必要打扰的情况，同时使推送服务推送大量无用数据，增加服务成本。由于行业内对运营消息推送的目标用户群体划分维度不够明确，导致推送精准度相对较低。另一方面，现有的运营消息无法自主灵活配置，运营人员无法自
主配置消息推送规则，容易影响消息推送的易用性和实时性，增加运营工作成本，错失最佳推送时间。此外，现有运营消息推送方式也缺乏对全球大数据量用户的考虑，运营消息的推送主要是针对一门语言进行推送，当应用服务为全球服务时，缺乏对多种使用不同语言的用户进行实用性运营消息推送。基于此，提供本技术实施例的一种基于日活数据的运营消息推送方法，以解决现有运营消息推送精度偏低的技术问题，并提升运营消息配置的灵活性、易用性和实用性。
28.实施例：
29.图1给出了本技术实施例提供的一种基于日活数据的运营消息推送方法的流程图，本实施例中提供的基于日活数据的运营消息推送方法可以由基于日活数据的运营消息推送设备执行，该基于日活数据的运营消息推送设备可以通过软件和/或硬件的方式实现，该基于日活数据的运营消息推送设备可以是两个或多个物理实体构成，也可以是一个物理实体构成。一般而言，该基于日活数据的运营消息推送设备可以是应用运营平台服务器、电脑等计算设备。
30.下述以该基于日活数据的运营消息推送设备为执行基于日活数据的运营消息推送方法的主体为例，进行描述。参照图1，该基于日活数据的运营消息推送方法具体包括：
31.s110、获取用户的日活数据，基于日活数据确定多个维度的用户群体数据源。
32.本技术在进行运营消息推送时，基于预先确定的多个维度的用户群体数据源进行灵活选择，以精准确定运营消息的目标用户，进而进行目标用户的运营消息推送。在此之前，需要根据用户的日活数据确定各个维度的用户群体数据源，以便于在进行运营消息配置过程中，供运营人员选择指定的用户群体数据源，确定目标用户进行运营消息推送。
33.可以理解的是，用户日活数据中包含了用户id、操作平台(android/ios)、登录时间和设备id等信息，通过处理这些信息即可得到用于标识用户的多种维度的属性信息，定义这些属性信息为用户群体数据源。进而基于这些用户群体数据源，即可确定一个应用程序中分属于各个群体的用户。后续在进行运营信息推送时，根据实际需求推送的目标群体，即可实用性选择对应用户群体数据源进行运营消息推送服务的配置。
34.参照图2，用户日活数据的处理流程包括：
35.s1101、基于用户日活数据进行筛选处理得到一次处理数据；
36.s1102、根据一次处理数据搜索用户国家基础信息和用户应用端打点数据，筛选处理用户国家基础信息和用户应用端打点数据，得到二次处理数据；
37.s1103、对一次处理数据和二次处理数据进行聚合，得到多个维度的用户群体数据源。
38.具体地，应用程序在运营服务过程中，对用户每次登录应用程序的操作，客户端层面会将用户登录数据作为用户日活数据进行打点上报到数据仓库工具(hive)的大数据平台上。其中，用户日活数据的上报维度包含用户id、操作平台(android/ios)、登录时间和设备id及众多冗余数据列。
39.参照图3，由于上报的这部分初始数据源中，数据量和数据列项多且冗杂，因此需要对初始数据源进行二次清洗，如剔除其中包含的机器人用户及非法用户数据，选取指定时间范围内的数据等。进一步根据数据的登陆时间进行划分，且对用户id进行去重聚合得出一次处理数据。一次处理数据标识了用户当日活跃情况，其具体包括了设定周期内登录
过的用户id，用户操作平台(android/ios)等用户日活数据。
40.基于处理得到的一次处理数据，本技术实施例使用一次处理数据去搜索同样在数据仓库工具(hive)的大数据平台中预存储的用户国家基础信息数据表和用户应用端打点数据表，以获取相应的用户国家基础信息和用户应用端打点数据。进一步基于获取到的用户国家基础信息和用户应用端打点数据进行三次清洗，剔除表格查询不到的数据，剔除非法国家内的数据，以此获得二次处理数据。二次处理数据包括了用户实际国家码或者区域码(即用户区域信息)、用户应用端语言码及应用渠道等信息。可以理解的是，运营平台在用户注册及用户使用应用程序服务过程中，会对应构建这一用户国家基础信息数据表和用户应用端打点数据表，以便于后续进行相关用户属性信息的统计。
41.之后，将一次处理数据和二次处理数据进行聚合，并按照运营消息推送服务所规定好的格式构建json数据，对用户划分出多个维度的用户群体数据源。用户群体数据源的维度包括用户id、区域、操作平台、语言码和应用渠道中的一种或多种。每位用户生成一条json数据，在生成大量json列表并落盘后，完成目标用户群体数据源的聚合构建。
42.可选的，由于用户群体数据源直接存储在数据库或者系统缓存中，对于面向全球用户的应用程序运营平台而言，需要存储的用户数据量特别大，其对内存空间的占用相对较大。基于此，本技术实施例通过使用数据仓库工具(hive)redis数据库或者分布式文件系统(hdfs)进行用户群体数据源的分片存储。
43.其中，数据分片存储的流程包括：
44.s1104、每日定时基于各个用户的用户群体数据源生成当日文件目录，并以生成时间戳命名当日文件目录；
45.s1105、将所有用户的当日文件目录分片存储至数据仓库工具或者分布式文件系统中。
46.基于已完成统计的用户群体数据源，本技术实施例会每日定时获取上述目标用户群体数据源，并在数据仓库工具(hive)或者分布式文件系统(hdfs)中生成当日文件目录，以生成时间的时间戳命名该目录。然后根据用户群体数据源的数据量，将当日文件目录分成100个左右的分片，分别在对应目录中生成一个“.json”的文件，方便后续对所有分片同时进行扫描，提高推送速度。运营人员根据需要可以查看到对应的分片数据，每日的用户日活数据根据实际需要分片，如100个分片左右。每个分片存储着大量的用户数据，并且填充了对应的筛选数据，方便后期调用筛选。可以理解的是，由于用户群体数据源的数据量大，后续需要周期对当日文件目录进行扫描，通过将目标群体数据源存储至数据仓库工具(hive)或者分布式文件系统(hdfs)，会大幅度降低数据库的存储压力，优化系统的运行。
47.可选的，系统可以保留连续设定天数的用户群体数据源。如保留连续五天的用户群体数据源。数据中的每份副本都是当天的目标用户群体数据源，并按时间进行倒序排序目录。以此可以防止在系统异常的情况下，当日文件目录搜寻不到，系统仍可以通过倒推时间获取最近一天的用户群体数据源，保证系统正常运行。此外，还可以设置监控服务，监控用户群体数据源的存储情况。如某日用户群体数据源没有生成对应的文件目录，则输出提示信息给对应运维人员进行分析处理。以此可确保数据的稳定存储，优化用户群体数据源的管理。
48.s120、获取推送内容和目标用户选择信息，基于推送内容和目标用户选择信息配
置运营消息推送服务，目标用户选择信息用于选择指定维度的用户群体数据源所属的用户作为目标用户。
49.进一步地，基于预先构建的用户群体数据源，本技术实施例在进行运营消息推送服务构建时，即可结合多个维度的用户群体消息数据源进行运营消息推送服务的配置。通过在多个维度的用户群体消息数据源中选择指定的用户群体数据源，即可依此确定当前运营消息推送服务的目标用户。
50.在进行运营消息推送服务的编辑配置时，通过提供一个运营消息推送服务的编辑页供运营人员进行编辑。其中，编辑页提供的配置项目主要有用户群体数据源，推送内容(标题，链接，内容，图标)，推送原因，待推送的时间等。根据实际推送需求，运营人员在编辑页上加载需要推送的内容，设置推送原因、待推送的时间并选择对应的用户群体数据源，生成目标用户选择信息，以此即可完成一个运营消息推送服务的配置。
51.基于运营人员的配置结果，系统获取对应的推送内容和用户选择信息，基于推送内容和用户选择信息即可构建运营消息推送服务进行运营消息推送，将对应的推送内容推送至用户选择信息所选择的目标用户。可选的，由于编辑页还提供了推送原因和待推送时间项目的配置，则本技术实施例基于运营人员的配置结果，还获取推送内容的推送原因和待推送时间，结合推送原因和待推送时间配置运营消息推送服务。举例而言，在运营消息推送服务的编辑页面，运营人员通过各个配置项目的编辑，指定运营消息的推送平台(如全部，ios或者android)、投放渠道，国家，语言码，发送时间，点击跳转的深度连接链接(如主播推荐，主题房，转换链接，自定义链接等)，标题，推送内容，推送原因，图标等信息后，基于运营人员的配置结果，即可将各类配置数据进行拼凑处理成固定格式的json数据，即该运营消息推送服务，进而执行运营消息推送服务。
52.s130、根据目标用户选择信息所选择的目标用户执行运营消息推送服务。
53.进一步的，基于运营人员配置的运营消息推送服务，即可进行运营消息推送服务的执行。其中，系统通过设置常驻任务对运营消息推送服务进行预处理，定时扫描审核通过且到达待发送时间的运营消息推送服务，进入运营消息推送服务的发送流程。
54.具体的，参照图4，本技术运营消息推送服务推送的触发流程包括：
55.s1301、在确定运营消息推送服务审批通过之后，将运营消息推送服务放入待发送队列；
56.s1302、实时监听当前时间节点，在当前时间节点等于待推送时间时，触发运营消息推送服务的推送流程。
57.其中，参照图5，本技术构建运营消息推送服务，进行运营消息推送服务的推送流程之前，还进行运营消息推送服务的审批流程。通过提供一个可视化界面供审核人员进行运营消息推送服务的审批。当运营配置成功及审批工作人员审批通过后，将运营消息推送服务推送进入待发送队列，并实时监听运营消息推送服务的待发送时间，当前时间到达待发送时间后，开始运营消息推送服务的发送流程。反之，如若审核不通过，则会大会审核人员一端，进行运营消息推送服务的重新编辑。
58.进一步地，在推送运营消息推送服务时，还判断当前运营消息推送服务的推送类型是否满足推送条件，以确保用户可以正常使用推送服务。以直播平台的直播间推送服务为例，在进行推送运营消息推送服务时，首先判断运营消息推送服务是否为直播间推送。若
不是直播间推送，则直接进行运营消息推送服务的预处理，若是，则需要进一步判断直播间是否开播。其中，在确定运营消息推送服务为直播间推送时，检测对应的直播间是否开播；若是，开始推送运营消息推送服务，若否，循环检测对应的直播间是否开播设定时间段后，将运营消息推送服务丢弃出待发送队列。
59.本技术实施例通过判断当前运营消息推送服务的推送类型，如果推送类型是主播推荐或主题房等直播间推荐，则需检测直播间是否开播。以此可以确保推送效益最大化，使触及到的用户在点击跳转链接时能成功进入直播房间中，提升用户的体验。而当房间在开播状态时，就直接进入下一步推送流程。如果直播未开始，则推迟推送检测10s，并将推送状态置为“主播未开播”，如持续两个小时未开播，则将该运营消息推送服务丢弃出待发送队列，将推送状态置为“发送超时”，提示运营人员重新校验配置。通过运营后台配置的发送链接可判断推送类型是直播间推送类型，该类型需要判断房间是否开播，未开播则需要等待10s重新检测，直至两小时后将推送状态置为“发送超时”状态。非直播间推送类型或已在开播中的房间类型则直接进行推送数据预处理。由推送预处理服务将运营后台配置的数据进行拼凑处理，处理成json数据。
60.具体的，在进行推送服务预处理时，通过确定推送场景，并对推送服务进行去重，防止重复推送。然后判断当前推送服务的调度模式，如即时发送模式,指定时间戳发送或者定时发送操作。进而根据目标用户选择信息在预存储的用户群体数据源中筛选确定目标用户，以此完成推送服务预处理。
61.之后通过http请求运营消息推送服务接口，以运营消息推送服务json格式进行推送。并且，为了保证服务安全，各个服务节点仅支持内网访问。在推送服务发送成功后，则将推送状态置为“发送中”状态。
62.可选的，本技术还基于推送检测服务检测所有目标用户的推送结果，基于推送结果更新运营消息推送服务的推送状态和推送用户数量，并对应存储推送状态和推送用户数量，以用于运营平台查询。通过设置常驻任务对“发送中“状态的推送服务进行检测，以检测推送服务是否发送完成。其中，通过http请求查询推送状态链接，获取唯一的推送信息。运营平台的推送服务任务将会返回对应运营消息推送服务对所有用户扫描并发送的数据，当检测所有目标用户均推送成功时，更新推送状态为“推送成功“及对应的推送人数。在一个实施例中，还可以设置相应的推送服务告警任务，在检测到http请求失败时，推送服务告警任务返回推送失败的提示，以提示进行推送失败检测或者重新推送运行消息。可选的，推送检测服务任务还可以展示推送状态、推送用户数量以及对应的运营消息推送服务的历史配置信息，以用于运营查询。推送检测服务任务在不同的阶段都可以对检测到的推送状态进行更新，以便于运营、审核人员查询不同运营消息的推送状态。例如，审核人员通过查询筛选待审核状态的运营消息推送服务，以便于进行运营消息审核，提升审核效率。
63.最终，在运营消息推送成功后，用户终端(如手机)的通知窗口会弹出相应的运营消息，其显示的数据均与运营后台配置的一致，并且用户点击之后会根据后台配置的深度链接跳转至对应客户端页面，以此完成运营消息推送。
64.可选地，本技术在进行运营消息推送时，运营后台还提供一个可视化前端页面，以进行运营消息编辑配置、状态查询等操作。并且，可视化页面还提供搜索功能，运营人员可根据用户id，应用渠道，推送状态，国家，语言码，推送时间，提交人等多维度进行搜索，以查
询不同的运营消息推送服务。而对于审核人员，即可通过搜索处于对应状态的运营消息推送服务，进行审批(通过/不通过)，若通过则进入待发送队列，不通过则允许重新编辑。通过提供搜索功能，可以进一步提升运营消息推送服务的编辑推送效率，优化推送效果。
65.上述，通过获取用户的日活数据，基于日活数据确定多个维度的用户群体数据源；获取推送内容和目标用户选择信息，基于推送内容和目标用户选择信息配置运营消息推送服务，目标用户选择信息用于选择指定维度的用户群体数据源所属的用户作为目标用户；根据目标用户选择信息所选择的目标用户执行运营消息推送服务。采用上述技术手段，通过用户日活数据确定出不同维度的用户群体数据源，选择不同用户群体数据源进行运营消息推送服务的配置，可以实现运营消息的多维度、精准推送，提升运营消息配置的灵活性，并减少应用运营平台的运营成本。
66.在上述实施例的基础上，图6为本技术提供的一种基于日活数据的运营消息推送系统的结构示意图。参考图6，本实施例提供的基于日活数据的运营消息推送系统具体包括：获取模块21、配置模块22和推送模块23。
67.其中，获取模块21用于获取用户的日活数据，基于日活数据确定多个维度的用户群体数据源；
68.配置模块22用于获取推送内容和目标用户选择信息，基于推送内容和目标用户选择信息配置运营消息推送服务，目标用户选择信息用于选择指定维度的用户群体数据源所属的用户作为目标用户；
69.推送模块23用于根据目标用户选择信息所选择的目标用户执行运营消息推送服务。
70.获取模块21包括：
71.处理单元，用于基于用户日活数据进行筛选处理得到一次处理数据；根据一次处理数据搜索用户国家基础信息和用户应用端打点数据，筛选处理用户国家基础信息和用户应用端打点数据，得到二次处理数据；对一次处理数据和二次处理数据进行聚合，得到多个维度的用户群体数据源。用户群体数据源的维度包括用户id、区域、操作平台、语言码和应用渠道中的一种或多种。
72.存储单元，用于每日定时基于各个用户的用户群体数据源生成当日文件目录，并以生成时间戳命名当日文件目录；将所有用户的当日文件目录分片存储至数据仓库工具或者分布式文件系统中。
73.配置模块22还包括：
74.获取推送内容的推送原因和待推送时间，结合推送原因和待推送时间配置运营消息推送服务。
75.推送模块23还包括：
76.触发单元，用于在确定运营消息推送服务审批通过之后，将运营消息推送服务放入待发送队列；实时监听当前时间节点，在当前时间节点等于待推送时间时，触发运营消息推送服务的推送流程。
77.检测单元，用于在确定运营消息推送服务为直播间推送时，检测对应的直播间是否开播；若是，开始推送运营消息推送服务，若否，循环检测对应的直播间是否开播设定时间段后，将运营消息推送服务丢弃出待发送队列。
78.状态更新单元，用于基于推送检测服务检测所有目标用户的推送结果，基于推送结果更新运营消息推送服务的推送状态和推送用户数量，并对应存储推送状态和推送用户数量，以用于运营平台查询。
79.上述，通过获取用户的日活数据，基于日活数据确定多个维度的用户群体数据源；获取推送内容和目标用户选择信息，基于推送内容和目标用户选择信息配置运营消息推送服务，目标用户选择信息用于选择指定维度的用户群体数据源所属的用户作为目标用户；根据目标用户选择信息所选择的目标用户执行运营消息推送服务。采用上述技术手段，通过用户日活数据确定出不同维度的用户群体数据源，选择不同用户群体数据源进行运营消息推送服务的配置，可以实现运营消息的多维度、精准推送，提升运营消息配置的灵活性，并减少应用运营平台的运营成本。
80.本技术实施例提供的基于日活数据的运营消息推送系统可以用于执行上述实施例提供的基于日活数据的运营消息推送方法，具备相应的功能和有益效果。
81.在上述实际上例的基础上，本技术实施例还提供了一种电子设备，参照图7，该电子设备包括：处理器31、存储器32、通信模块33、输入装置34及输出装置35。存储器32作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本技术任意实施例所述的基于日活数据的运营消息推送方法对应的程序指令/模块(例如，基于日活数据的运营消息推送系统中的获取模块、配置模块和推送模块)。通信模块33用于进行数据传输。处理器31通过运行存储在存储器中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的基于日活数据的运营消息推送方法。输入装置34可用于接收输入的数字或字符信息，以及产生与设备的用户设置以及功能控制有关的键信号输入。输出装置35可包括显示屏等显示设备。上述提供的电子设备可用于执行上述实施例提供的基于日活数据的运营消息推送方法，具备相应的功能和有益效果。
82.在上述实施例的基础上，本技术实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种基于日活数据的运营消息推送方法，存储介质可以是任何的各种类型的存储器设备或存储设备。当然，本技术实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的基于日活数据的运营消息推送方法，还可以执行本技术任意实施例所提供的基于日活数据的运营消息推送方法中的相关操作。
83.上述仅为本技术的较佳实施例及所运用的技术原理。本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由权利要求的范围决定。