一种内容推荐方法、装置及终端设备与流程

1.本技术属于电子商务技术领域，尤其涉及内容推荐方法、装置及终端设备。


背景技术：

2.随着互联网技术的发展，o2o(online to offline)电商平台的功能愈发强大，已经从一个单一的网上购物平台演化为了具有购物、娱乐、出行等功能的多功能网络平台。o2o电商平台(以下简称平台)功能的丰富旨在为用户生活提供便利。但实际应用中发现，很多用户并不会主动去探索尝试自己不熟悉的功能。导致平台很多功能的用户使用率并不高。
3.为了提供平台功能的用户使用率。一种做法是在用户使用平台的过程中，平台主动为用户推送新功能的介绍，或者提示用户平台中存在的一些新功能并提供功能开启的快捷操作，以吸引用户去尝试这些新功能。这种做法虽然一定程度上可以吸引用户尝试平台新功能，但对用户的针对性不强，导致实际效果不佳。同时也会影响用户对平台的体验感，不利于平台的发展。因此需要一种可以向用户个性化推荐平台功能的方法，以提高用户对平台功能的使用率。


技术实现要素：

4.有鉴于此，本技术实施例提供了一种内容推荐方法、装置及终端设备，可以解决现有技术无法向用户个性化推荐平台功能的问题。
5.本技术实施例的第一方面提供了一种内容推荐方法，包括：
6.获取第一用户在平台内的操作数据。
7.基于操作数据对第一用户进行行为分析，预测第一用户的用户行为，并根据用户行为从第一用户的用户画像中选取出至少一个用户标签。
8.获取选取出的所有用户标签对应的使用样本数据，并基于用户行为和使用样本数据，预测第一用户的用户需求。使用样本数据中记录有第一用户对平台内功能的历史使用数据。
9.从使用样本数据中筛选出用户需求关联的待分析数据。
10.对待分析数据进行分析，确定出第一用户对应的待推荐内容。待推荐内容为功能，或者功能内容。
11.在第一方面的一种可能的实现方式中，对待分析数据进行分析，确定出第一用户对应的待推荐内容，包括：
12.对待分析数据进行解析，确定出待分析数据所属的功能，以及这些功能下第一用户使用过的功能内容。
13.从待分析数据中解析出确定出的各个功能以及功能内容的属性数据，属性数据包括：
14.功能的月均使用时长t11、功能的月均使用次数n11、最近一个月内功能使用的总
时长 t12和总次数n12，功能内容的月均使用时长t21、功能内容的月均使用次数n21、以及最近一个月内功能内容的总时长t22和总次数n22。
15.计算确定出的所有功能的月均使用时长平均值t01、月均使用次数平均值n01、最近一个月内确定出的所有功能使用的平均时长t02和平均次数n02。所有功能内容的月均使用时长平均值t03、月均使用次数平均值n03、最近一个月内所有功能内容使用的平均时长t04 和平均次数n04。
16.根据以下公式计算各个功能的需求分数。
[0017][0018]
根据以下公式计算各个功能内容的需求分数。
[0019][0020]
其中，f1为功能的需求分数，f2为功能内容的需求分数，a、b、c、d均为权重系数，用于调节使用时长与使用次数的分数比重，e为调节系数，用于调节功能内容的需求分数， c》a、d》b且e》1。
[0021]
将需求分数最高的功能或功能内容作为第一用户对应的待推荐内容。
[0022]
在第一方面的第二种可能的实现方式中，在根据用户行为从第一用户的用户画像中选取出至少一个用户标签之前，还包括：
[0023]
获取第一用户的用户信息，以及第一用户对平台内各个功能的历史使用数据。
[0024]
对各个功能的历史使用数据进行采样，得到使用样本数据。
[0025]
基于使用样本数据确定用户标签，得到第一用户对应的多个用户标签，完成对第一用户的用户画像构建。其中每个用户标签，关联有一种或多种功能。
[0026]
在第一方面的第三种可能的实现方式中，在获取第一用户的用户信息，以及第一用户对平台内各个功能的历史使用数据之后，对各个功能的历史使用数据进行采样，得到使用样本数据之前，还包括：
[0027]
若第一用户存在没有历史使用数据的待处理功能，则查找出对待处理功能具有历史使用数据的至少一个第二用户。
[0028]
获取各个第二用户的用户信息，以及对平台内各个功能的历史使用数据。
[0029]
从第二用户的历史使用数据中，剔除各个第二用户对待处理功能的历史使用数据。
[0030]
根据第一用户的用户信息、第一用户对平台各个功能的历史使用数据、各个第二用户的用户信息，以及剔除操作后各个第二用户对平台内功能的历史使用数据，计算第一用户与每个第二用户的相似度。
[0031]
筛选出相似度最高的第二用户，并将筛选出的第二用户对待处理功能的历史使用数据，作为第一用户对待处理功能的历史使用数据。
[0032]
在第一方面的第四种可能的实现方式中，根据第一用户的用户信息、第一用户对平台各个功能的历史使用数据、各个第二用户的用户信息，以及剔除操作后各个第二用户对平台内功能的历史使用数据，计算第一用户与每个第二用户的相似度，包括：
[0033]
计算第一用户的用户信息和第二用户的用户信息相似度。
[0034]
分别统计第一用户对各个功能的使用总时长和使用总次数，分别统计除待处理功
能以外，第二用户对各个功能的使用总时长和使用总次数。
[0035]
利用以下公式计算第一用户与第二用户的相似度：
[0036][0037]
其中，设第一用户称为用户b，第二用户称为用户c。s
bc1
表示用户b和用户c的相似度， n
(b)
表示用户b使用过的功能集合，n
(c)
表示用户c使用过除待处理功能以外的功能集合，t
bi
表示用户b对第i个功能的使用总时长，t
ci
表示用户c对第i个功能的使用总时长，n
bi
表示用户b对第i个功能的使用总次数，n
ci
表示用户c对第i个功能的使用总次数，s
bc2
表示用户b的和用户c的用户信息相似度，|n
(b)
|和|n
(c)
|分别表示n
(b)
和n
(c)
包含的功能数量， |n
(b)
|∪|n
(c)
|表示n
(b)
和n
(c)
包含的功能数量之和。
[0038]
α为权重因子，用于调节用户b和用户c在功能使用上的相似度和在用户信息上的相似度权重，β为时间因子，δ为数量因子。
[0039]
在第一方面的第五种可能的实现方式中，对各个功能的历史使用数据进行采样，得到使用样本数据，包括：
[0040]
将平台内的功能分为食物维度、娱乐维度、出行维度和健康维度，共四种功能类型。其中，食物维度包含与饮食相关的功能、娱乐维度包含与休闲娱乐相关的功能、出行维度包含与出行和住宿相关的功能，而健康维度包含与饮食相关的功能以及与用户看病和用药相关的功能。
[0041]
获取每种功能类型分别对应的不同的采样策略。
[0042]
按照每种功能类型分别对应的采样策略，分别对各个功能类型内功能的历史使用数据进行采样，得到使用样本数据。
[0043]
本技术实施例的第二方面提供了一种内容推荐装置，包括：
[0044]
数据获取模块，用于获取第一用户在平台内的操作数据。
[0045]
标签选取模块，用于基于操作数据对第一用户进行行为分析，预测第一用户的用户行为，并根据用户行为从第一用户的用户画像中选取出至少一个用户标签。
[0046]
需求预测模块，用于获取选取出的所有用户标签对应的使用样本数据，并基于用户行为和使用样本数据，预测第一用户的用户需求。使用样本数据中记录有第一用户对平台内功能的历史使用数据。
[0047]
数据筛选模块，用于从使用样本数据中筛选出用户需求关联的待分析数据。
[0048]
内容确定模块，用于对待分析数据进行分析，确定出第一用户对应的待推荐内容。待推荐内容为功能，或者功能内容。
[0049]
本技术实施例的第三方面提供了一种终端设备，终端设备包括存储器、处理器，存储器上存储有可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述第一方面中任一项内容推荐方法的步骤。
[0050]
本技术实施例的第四方面提供了一种计算机可读存储介质，包括：存储有计算机程序，其特征在于，计算机程序被处理器执行时实现如上述第一方面中任一项内容推荐方法的步骤。
[0051]
本技术实施例的第五方面提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项内容推荐方法。
[0052]
本技术实施例与现有技术相比存在的有益效果是：本技术实施例中通过预测用户行为来定位用户标签及标签下的使用样本数据，并通过使用样本数据确定出用户需求，再通过用户需求来二次筛选使用数据。此时筛选出的待分析数据是经由用户行为和需求双重筛选出的样本数据，其与用户实际需求的相关度极高。且使用样本数据的选取和二次筛选过程都是根据用户实际情况来自适应实现的可以减少大量弱相关的使用数据，同时可以避免人为主观因素的影响。使得选取的使用样本数据更加贴合用户的个性化需求。再基于待分析数据来筛选适宜用户的待推荐内容。因此本技术实施例最终的推荐内容更加准确。
附图说明
[0053]
为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0054]
图1是本技术实施例提供的内容推荐方法中用户画像阶段的实现流程示意图；
[0055]
图2是本技术实施例提供的内容推荐方法中用户画像阶段的实现流程示意图；
[0056]
图3是本技术实施例提供的内容推荐方法中计算用户相似度的实现流程示意图；
[0057]
图4是本技术实施例提供的内容推荐方法中内容推荐的实现流程示意图；
[0058]
图5是本技术实施例提供的内容推荐装置的结构示意图；
[0059]
图6是本技术实施例提供的终端设备的示意图。
具体实施方式
[0060]
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
[0061]
为了说明本技术所述的技术方案，下面通过具体实施例来进行说明。
[0062]
随着用户实际需求的不断增加，用户逐渐希望可以在线上找到更多的生活服务，因此平台原本的网上购物功能已无法满足用户实际需求。与此同时，伴随着互联网技术的不断发展，也给平台功能丰富化提供了技术基础。在此基础上，平台从一个单一的网上购物平台逐步演化为了多功能网络平台。其常见的功能有：外卖、团购美食、团购买菜、网上菜市场、网上超市、住宿、休闲娱乐、打车出行、火车票或机票、买药以及网上医院等。
[0063]
平台功能的日益丰富给用户带来更多的生活便利。但实际生活中很多用户没有尝试探索平台功能的习惯，导致平台很多功能的实际用户使用频率并不高。此时丰富的功能不仅没有给用户带来便利，反而可能会导致用户觉得平台臃肿，从而导致用户体验下降。
[0064]
为了引导用户使用平台功能，一种可选的方式是一种做法是在用户使用平台的过程中，平台主动为用户推送新功能的介绍，或者提示用户平台中存在的一些新功能并提供功能开启的快捷操作，以吸引用户去尝试这些新功能。但实际情况是每个用户的实际情况都不一样，对于单个用户而言，并不是所有的功能都有使用的需求。通用式的推荐新功能，对用户的针对性较差，从而导致最终的实际效果并不好。因此如何为用户推荐一些真正感
兴趣或者有需求的内容，使得用户可以在自己实际需求的基础上开始逐步适应平台功能，并使用平台功能，是一个具有亟待解决且较大实际意义的问题。
[0065]
为了挖掘用户实际的需求，本技术实施例首先会对用户在平台内历史的使用数据进行分析，确定出用户实际具有的多个标签，以及每个标签对应相关的使用数据，从而实现对用户画像的建立。这些标签反映着用户不同维度的特性。在此基础上，本技术实施例会记录用户在平台内的操作数据，并基于这些操作数据对用户进行行为分析，确定出用户实际可能的一些行为。再基于这个可能的行为来匹配用户画像内的标签，确定出与行为相关的标签以及标签下对应的使用数据。此时可以得到用户实际状态下相关的一些使用样本数据，实现对样本数据的初步筛选。
[0066]
在确定出用户实际状态下相关的使用样本数据之后，本技术实施例会基于这些使用样本数据进行分析，来预测用户实际可能的需求，确定出用户实际到底需要什么。再基于预测出的实际需求来对使用样本数据进行二次筛选，挑选出与用户需求强相关的使用数据(即待分析数据)。最后本技术实施例会基于待分析数据来进行分析，确定出适宜用户的功能或功能内的具体内容作为待推荐内容，再将待推荐内容推荐至用户。
[0067]
本技术实施例具有以下有益效果：
[0068]
1、由于用户的使用数据可能会涉及到很多用户行为，这些行为之间相关性具有较大差异。因此若将所有使用数据均作为样本数据来预测用户需求以及分析推荐的内容，这样会导致一些几乎不相关的行为对应的使用数据也会被一起使用，这样会导致样本数据的有效性较差。而若人为预先对用户的使用数据进行分类，并将不同类型的使用数据与用户行为关联起来，再根据关联的情况来选取用户行为对应的使用数据作为样本数据，以预测用户需求以及分析推荐的内容。这种则会受到人为主观性的影响。每个人的划分标准都可能会有差异，即划分的准确性无法保障，从而使得样本数据的有效性仍较差。
[0069]
本技术实施例中通过预测用户行为来定位用户标签及标签下的使用样本数据，并通过使用样本数据确定出用户需求，再通过用户需求来二次筛选使用数据。此时筛选出的待分析数据是经由用户行为和需求双重筛选出的样本数据，其与用户实际需求的相关度极高。且使用数据的选取和二次筛选过程都是根据用户实际情况来自适应实现的，相对使用数据全选时而言，可以减少大量弱相关的使用数据，从而可以提高最终推荐的准确。而相对人为划分一些使用数据类型并关联行为来选取使用数据而言，本技术实施例可以避免人为主观因素的影响，使得选取的使用数据更加贴合用户的个性化需求。因此使得本技术实施例最终的推荐内容更加准确。
[0070]
2、本技术实施例的用户画像是基于用户实际使用情况建立的多维度标签画像，同时在用户画像使用上也更加灵活。不是单维度的推荐，也不是固定维度的组合。而是根据实际用户情况来灵活选取用户画像中的标签，不同用户甚至同一用户不同操作，本方案选取的用户标签都可能会有差异。这样可以摒弃一些无用因素的干扰，提高准确性。同时用户不是单薄仅有某一类特征的用户。这样更能得到真实的用户，使得对行为的分析，需求的预测，以及内容的推荐都更加准确可靠。
[0071]
3、我们不是简单的功能推荐。我们的待推荐内容既可以是功能本身，也可以是功能下的具体内容。即我们推荐内容的颗粒度大小可以更为精细，对用户更加友好，因此使得推荐的效果更佳。
[0072]
本技术实施例根据实际的技术方案实施情况，可以分为用户画像和内容推荐两个阶段，以下分别进行说明。
[0073]
阶段一：用户画像。
[0074]
图1示出了本技术实施例一提供的内容推荐方法中用户画像阶段的实现流程图，详述如下：
[0075]
s101，获取第一用户的用户信息，以及第一用户对平台各个功能的历史使用数据。
[0076]
在本技术实施例中，第一用户是指需要进行内容推荐的用户。用户信息是指用户的一些属性信息。根据平台情况的不同，用户信息包含的具体信息内容可以有所差异。例如，在一些可选实施例中，用户信息可以包括用户的性别和年龄。而在另一些可选实施例中，用户信息亦可以包括用户的性别、年龄和收货地址。
[0077]
本技术实施例不对平台具有的功能进行过多限定，具体可根据实际应用情况确定。例如在一些可选实施例中，平台的功能可以包含以下功能中的任意一种或多种：外卖、团购美食、团购买菜、网上菜市场、网上超市、住宿、休闲娱乐、打车出行、火车票或机票、买药以及网上医院。
[0078]
历史使用数据，是指用户在平台内历史使用各个功能的数据。如点击了功能内的哪些内容，以及具体的点击时间等。考虑到一些平台同时具有网站和终端应用两种访问方式，因此一些可选实施例中，历史使用数据内还可以包括用户历史使用功能时对应的门户类型。例如是通过网站的方式操作的还是通过终端应用(如手机内安装的应用程序)操作的。
[0079]
s102，对功能的历史使用数据进行采样，得到使用样本数据。
[0080]
由于历史使用数据的时间跨度和数据量可能会比较大。例如若用户是平台的多年用户，那理论上历史使用数据可能会有几年的时间跨度，此时对应的数据量会比较大。但实际应用中发现，用户的行为是具有一定周期性和规律性。且不同需求下产生的行为，其周期性和规律性还会存在一定的差异。因此对于发生时间较远的历史使用数据，其数据有效性较差。若直接作为后续用户需求分析的样本数据，一方面会导致数据处理量较大，另一方面也会降低分析的准确性。
[0081]
因此在s101中获取到历史使用数据之后，本技术实施例会对历史使用数据进行数据采样，挑选出其中有效性较高的数据作为使用样本数据。本技术实施例不对具体的采样方法做过多限定，具体可由本领域技术人员根据实际需求确定。例如在一些可选实施例中，可以设置一个固定的采样窗口长度对所有历史使用数据进行采样。如采样窗口长度均设置为一个月，此时均截取最近一个月内的历史使用数据作为使用样本数据。亦可以根据每种历史使用数据的特性，设置不同的采样窗口长度进行采样。
[0082]
为了可以更加精确的分析平台功能，以便提高后续对用户需求的分析预测准确性。在本技术的一个可选实施例中，根据功能的特性将功能分为食物维度、娱乐维度、出行维度和健康维度，共四种功能类型。其中，食物维度包含所有与饮食相关的功能、娱乐维度包含与休闲娱乐相关的功能、出行维度包含与出行和住宿相关的功能，而健康维度包含与饮食相关的功能以及与用户看病和用药相关的功能。以下是四种功能类型分别可以包含的功能的举例：
[0083]
食物维度可以包含：外卖、团购美食、团购买菜、网上菜市场、网上超市。
[0084]
娱乐维度可以包含：休闲娱乐。
[0085]
出行维度可以包含：打车出行、火车票或机票、住宿、休闲娱乐。
[0086]
健康维度可以包含：网上医院、买药、外卖、团购美食、网上超市、网上菜市场、团购买菜。
[0087]
在此基础上，平台实际包含的功能类型，均可按照四种功能类型包含功能情况进行确定。例如假设一可选实施例中平台内包含：外卖、团购美食、休闲娱乐、火车票或机票，由于外卖同时属于食物维度和健康维度、休闲娱乐属于娱乐维度、火车票或机票属于出行维度，因此此时平台同时包含食物维度、娱乐维度、出行维度和健康维度四种功能类型。
[0088]
对于四种功能类型下包含的历史使用数据，均利用采样窗口的方式进行采样。但由于每种功能类型的特性存在一定差异，因此在进行采样时，采样窗口长度会根据人类自然活动规律设定。从而使得四种功能类型对应的采样窗口长度不会完全一样。具体采样方法或策略如下：
[0089]
1、针对食物维度的历史使用数据。首先会设置一个采样窗口长度的默认值。该默认值可以设置为一周或一个月。考虑到实际生活中，用户可能会存在口味的变化，且不同用户口味变化的周期可能会有差异。因此一个固定的采样窗口长度难以满足不同用户的实际需求。基于此，本技术实施例会每月对用户过去半年食物维度的历史使用数据进行规律分析，确定出用户的饮食周期。再将该饮食周期更新为针对食物维度的历史使用数据的采样窗口长度。
[0090]
以一实例进行举例说明，可以在每个月第一天，对用户过去半年食物维度的历史使用数据进行规律分析。确定出用户一般多久口味会产生变化，即用户口味的饮食周期。再将该饮食周期设置为针对食物维度的历史使用数据的采样窗口长度。如假设分析结果为，用户两个月口味会有一次明显的变化，即饮食周期为两个月。此时，本技术实施例会将食物维度对应的采样窗口长度设置为两个月。即在s102中针对食物维度下的功能，会截取近两个月的历史使用数据来作为对应的使用样本数据。
[0091]
作为本技术的有一个可选实施例。考虑到实际生活中，除了用户自身因素导致的口味变化。一些外部的因素也可能会对用户的口味产生一定的影响，从而导致用户口味变化。例如季节的变化、天气的突变以及用户地理位置发送较大的变化。为了应对这种情况，除了上述每个月定期对用户过去半年食物维度的历史使用数据进行规律分析确定出用户的饮食周期以外。本技术实施例还会设定一些触发条件。当检测到这些触发条件时，本技术实施例也会对用户过去半年食物维度的历史使用数据进行规律分析确定出用户的饮食周期，并将该饮食周期更新为针对食物维度的历史使用数据的采样窗口长度。其中，具体的触发条件内容本技术实施例不做过多限定，可由技术人员根据实际需求选取或设定。例如可以包括但不限于：检测到季节切换(即每个季节的最后一天)、检测到当天的天气发生变化以及用户的定位与前一次的定位的空间距离大于距离阈值。距离阈值的实际值可由技术人员根据实际需求设置，此处不做限定。如可以设置为1000千米。
[0092]
其中，本技术实施例不对食物维度的历史使用数据规律分析方法做过多限定，具体可由技术人员根据实际需求选取或设定。例如在一些可选实施例中，可以采用一些数据规律分析算法，如smca算法和聚类分析法等。而在另一些可选实施例中，亦可以预先对食物进行分类。对半年内的历史使用数据中用户操作包含的食物类型，按照历史使用数据的发
生时间进行聚类，确定出用户一般多久会有一次明显的对食物类型喜好的变化。即确定出食物类型发生变化的周期值。
[0093]
2、针对娱乐维度的历史使用数据。首先会设置采样窗口长度的默认值为一个月。此时均截取最近一个月内的历史使用数据作为使用样本数据。同时考虑到用户兴趣爱好的长期规律性。即人在一段时间内可能会有不同的兴趣爱好，但长久的生活/工作习惯，会使得部分兴趣爱好是具有持久性的。因此本技术实施例还会对过去半年娱乐维度的历史使用数据进行分析，筛选出其中存在的一些长久爱好。并将这些爱好对应的历史使用数据加入至使用样本数据中。其中，本技术实施例不对长久爱好的分析方法做过多限定，可由技术人员根据实际需求选取或设定。例如，作为一种可选的分析方式，可以对娱乐维度的历史使用数据内涉及的娱乐项目次数进行统计，并将其中次数大于次数阈值，或者次数最大的前n个娱乐项目作为用户的长久爱好。其中次数阈值和n可由技术人员自行设置。如次数阈值可以设置为6-10 中的任意一值。n可以取1至3中任意一值。
[0094]
同时，本技术实施例会对娱乐维度的历史使用数据进行去重，以保证长久爱好对应加入的数据不会重复计算。如喜欢唱歌因此经常去ktv，此时会将去ktv加入至使用样本数据。但要是使用样本数据里面已经有了去ktv这个数据，则把插入的去ktv数据删除掉。
[0095]
3、针对出行维度的历史使用数据。本技术实施例首先会识别用户的出行情况，判断用户是否经常性的离开常驻城市。具体的判断方法可以是根据用户的设置或者定位数据，判断出用户的常驻城市。再根据用户的定位数据确定出用户离开常驻城市的次数。若该次数大于出行次数阈值，则判定为用户经常性的离开常驻城市，即用户为活动性用户。反之若该次数小等于出行次数阈值，则判定为用户不经常离开常驻城市，即用户为非活动性用户。其中，定位数据的有效时间范围，以及次数阈值具体大小此处不做过多限定，可由技术人员根据实际需求设置。例如在一些实施例中，定位数据有效时间范围为2年。即此时会根据用户2年内的定位数据，来判断用户是否经常性的离开常驻城市，是否为活动性用户。而次数阈值则可以设置为7至10中任一值。
[0096]
针对活动性用户，由于其经常性的需要出行。因此在对其进行出行维度的历史使用数据采样时，采样窗口长度需要较长，以保障得到的使用样本数据的有效性。反之对于非活动性用户，其出行的频率很小，无需很长的采样窗口长度也可以得到较为有效的使用样本数据。且不会带来过多的冗余数据，节约计算量。因此在本技术实施例中，会设置两个不同的采样窗口长度，且活动性用户的采样窗口长度长于非活动性用户的采样窗口长度。以实现对用户实际出行情况的自适应处理。在识别出用户是否为活动性用户之后，再选取出对应的采样窗口长度，并对出行维度的历史使用数据进行采样，得到相应的使用样本数据。其中，活动性用户和非活动性用户对应的采样窗口长度实际值此处不做过多限定，可由技术人员根据实际需求设定。例如在一些可选实施例中，可以设置活动性用户的采样窗口长度可以为6个月至 12个月中的任一值，而非活动性用户的采样窗口长度则可以设置为1个月至3个月中的任一值。
[0097]
以一实例进行举例说明，假设定位数据有效时间范围为2年、次数阈值为7、活动性用户的采样窗口长度为6个月、非活动性用户的采样窗口长度为1个月。此时本技术实施例首先可以根据用户两年内的定位数据确定出用户定位次数最多的城市a为常驻城市。同时统计两年内定位数据不为城市a的次数。若该次数大于7，则判定用户为活动性用户，此时会
截取用户在过去6个月内出行维度的历史使用数据，作为出行维度的使用样本数据。而若该次数小等于7，则判定用户为非活动性用户，此时会截取用户在过去1个月内出行维度的历史使用数据，作为出行维度的使用样本数据。这样既能保障使用样本数据的有效性，又能避免引入较多的冗余数据，增加计算量。
[0098]
4、针对健康维度的历史使用数据。由上述对功能的分类可知，健康维度包含食物维度内的所有功能。但与食物维度不同之处在于，食物维度更关注的是用户的饮食偏好。而对于饮食相关的功能，健康维度关注的则是用户饮食健康。同时健康维度还关注则用户身体的健康状况，因此还包含着用户看病用药方面的功能。即健康维度与食物维度关注的侧重点不同。其中，健康维度中饮食相关功能的历史使用数据采样方法，可以参考对食物维度的历史使用数据采样方法，此处不予赘述。而用户看病用药与用户的审通健康情况相关度极高，因此这方面功能的历史使用数据采样则是保留所有的历史使用数据。此时无需设置采用窗口。
[0099]
另外，作为本技术的一个可选实施例。考虑到历史使用数据内包含的数据较多。如饮食相关功能的历史使用数据会包含用户购买的具体食物、购买时间、价格、销售商家和购买次数等。看病用药相关功能的历史使用数据会包含用户具体药物、购买时间、价格、销售药店或医院以及购买次数等。这些数据与用户身体健康的相关性差异较大且离散性高。因此若保留所有的数据并进行后续的用户需求分析，一方面会导致数据量较大计算量大，另一方面相关度各异的离散数据也会导致用户需求分析难度增大。因此在本技术实施例中，在采样时会对历史使用数据进行数据提炼，具体如下：
[0100]
考虑到饮食健康与用户吃的食物种类、次数、食物来源很重要。因此本技术实施例会对将食物分为健康食物和垃圾食物，并会对截取出饮食相关功能的历史使用数据进行食物分类和统计，确定出食物的类型(即健康食物还是垃圾食物)、每种食物类型的次数以及食物的来源。其中来源分为外卖熟食和自购食材。所有通过平台购买的熟食均为外卖熟食来源，所有提高平台购买的非熟食食材，均为自购食材。外卖熟食说明用户以外卖为主，对用户健康程度较低。而自购食材，说明用户会自行烹饪，相对健康程度较高。
[0101]
对于看病用药情况，用药类型、次数以及近期使用用户看病和用药相关功能的使用次数很重要。因此本技术实施例会对看病买药相关功能的历史使用数据进行分析，确定出其中药物的类型、每种药物类型的次数以及预设时间段内使用用户看病和用药相关功能的使用次数。其中预设时间段的具体时段，可由技术人员自行设定，此处不做过多限定。例如可以设置为以当前时间为终止时间的半年内。
[0102]
至此，本技术实施例完成了对四种功能类型下所有功能历史使用数据的采样，这些功能下采样得到的所有使用样本数据，即为s102中所需的使用样本数据。
[0103]
作为本技术的一个可选实施例。实际应用中，对于单个用户而言平台虽然功能丰富，但不一定所有的功能都会使用过。因此在进行历史使用数据采样时，可能会遇到部分功能历史使用数据缺失，无法进行正常的采样的情况。从而导致使用样本数据缺失。若以存在缺失的使用样本数据进行后续的数据处理，以及用户需求的分析预测，会使得需求分析预测的可靠性降低。基于此，本技术实施例提供了一种填补用户历史使用数据的方法，详述如下：
[0104]
参考图2，在s101之后，s102之前，还包括：
[0105]
s201，若第一用户存在没有历史使用数据的待处理功能，则查找出对待处理功能具有历史使用数据的至少一个第二用户。
[0106]
在s101获取到第一用户的历史使用数据，会查找平台功能中是否存在第一用户没有对应的历史使用数据的功能(以下称为待处理功能)。如果有，说明第一用户没有使用过待处理功能。此时本技术实施例会从平台已有的用户中找出用过待处理功能的用户(即第二用户)。具体而言，只需找出对待处理功能有历史使用数据的用户即可。
[0107]
应当理解的，单个用户可能有一个或多个功能一直都没有使用过，因此本技术实施例中的待处理功能，可以是一个或多个功能。同时，每个功能都可能被一个或多个用户使用。因此在本技术实施例中，查找出的第二用户数量不确定，可能是一个或多个。具体需根据实际情况确定。
[0108]
s202，获取各个第二用户的用户信息，以及各个第二用户对平台各个功能的历史使用数据。
[0109]
在确定出第二用户之后，本技术实施例会获取这些这些第二用户的用户信息，以及对平台各个功能的历史使用数据。具体的操作细节和原理等，与s101获取第一用户的用户信息和历史使用数据相同，因此此处不予赘述，具体可参考s101的说明。
[0110]
s203，从获取到的历史使用数据中，剔除各个第二用户对待处理功能的历史使用数据。根据第一用户的用户信息、第一用户对平台各个功能的历史使用数据、各个第二用户的用户信息，以及剔除操作后各个第二用户对平台各个功能的历史使用数据，计算第一用户与每个第二用户的相似度。
[0111]
在本技术实施例中，考虑到第一用户不具有待处理功能的历史使用数据。在进行用户相似度计算时，待处理功能的历史使用数据不具有太大的参考意义。因此在计算第一用户和第二用户的相似度之前，会先剔除第二用户对待处理功能历史使用数据。以减少不必要的计算工作。应当理解的，此处的剔除不代表删除第二用户对待处理功能历史使用数据，仅仅是为了说明不使用这些数据来进行用户相似度的计算。
[0112]
本技术实施例不对第一用户和第二用户的相似度计算方法做过多限定，具体可由技术人员根据实际需求选取或设定。参考图3，作为本技术的一个可选实施例，提供了一种第一用户和单个第二用户的相似度计算方法，详述如下：
[0113]
s2031，计算第一用户的用户信息和第二用户的用户信息相似度。
[0114]
本技术实施例不对用户信息相似度的计算方法做过多限定，可由技术人员根据实际需求选取或设定。例如可以采用余弦相似性、皮尔森系数或者调整余弦相似性等算法来实现，此处不做过多限定。
[0115]
s2032，分别统计第一用户对各个功能的使用总时长和使用总次数，分别统计除待处理功能以外，第二用户对各个功能的使用总时长和使用总次数。
[0116]
s2033，利用公式(1)对用户信息相似度、第一用户对各个功能的使用总时长和使用总次数以及第二用户对各个功能的使用总时长和使用总次数进行处理，得到第一用户与第二用户的相似度：
[0117][0118]
在本技术实施例中，将第一用户称为用户b，第二用户称为用户c。公式(1)中，s
bc1
表示用户b和用户c的相似度。n
(b)
表示用户b使用过的功能集合，n
(c)
表示用户c使用过的功能集合(不包括待处理功能)。t
bi
表示用户b对第i个功能的使用总时长，t
ci
表示用户c 对第i个功能的使用总时长。n
bi
表示用户b对第i个功能的使用总次数，n
ci
表示用户c对第 i个功能的使用总次数。s
bc2
表示用户b的和用户c的用户信息相似度。|n
(b)
|和|n
(c)
|分别表示n
(b)
和n
(c)
包含的功能数量。|n
(b)
|∪|n
(c)
|表示n
(b)
和n
(c)
包含的功能数量之和。
[0119]
其中，α为权重因子，用于调节用户b和用户c在功能使用上的相似度和在用户信息上的相似度权重。β为时间因子，其值越大，则两个用户使用功能的时长差异度对相似度的影响越大。δ数量因子，其值越大则两个用户使用功能的次数差异度对相似度的影响越大。α、β和δ值可由技术人员根据实际情况设置，此处不做过多限定。
[0120]
作为本技术的一个可选实施例，考虑到本技术实施例中对相似用户的寻找，更多的是为了可以填补第一用户缺失的历史使用数据。因此对于功能的使用相似度情况重要性，高于用户基础情况的相似度情况。基于此，在本技术实施例中，可以设定α》0.5。另外，作为本技术的另一个实施例，考虑到用户对功能的使用时长与用户对功能偏好的关联度，弱于用户对功能的使用次数与用户对功能偏好的关联度。因此在本技术实施例，可以设定δ》β，以提高功能的使用总次数对用相似度的影响度。
[0121]
在本技术实施例中，通过功能的使用总时长和功能的使用总次数两个维度来量化用户对功能的使用情况。从而使得即使是用户没有使用过的功能，其也可以有两个维度的初始值，即功能的使用总时长和使用总次数均为0。因此可以将第一用户所有使用过的功能，以及第二用户所有使用过的功能，有效的进行量化比较。使得对功能使用情况比较的更加全面可靠。进而使得对用户相似度的计算更为精准可靠。
[0122]
s204，筛选出其中相似度最高的第二用户。将筛选出的第二用户对待处理功能的历史使用数据，作为第一用户对待处理功能的历史使用数据。
[0123]
在确定出各个第二用户与第一用户的相似度之后，本技术实施例会选出其中相似度最高的一个第二用户。并将该第二用户对待处理功能的历史使用数据，作为第一用户对待处理功能的历史使用数据。此时即可填补第一用户对待处理功能历史使用数据的缺失。同时又确保了填补来的历史使用数据的可靠性，进而为后续用户需求分析预测的准确性提供样本数据基础。
[0124]
s103，基于使用样本数据确定用户标签，得到第一用户对应的多个用户标签，完成用户画像构建。其中每个用户标签关联有一种或多种功能。
[0125]
本技术实施例中不对用户标签的确定方法做过多限定，可由技术人员根据实际需求选取或设定。例如，在一些可选实施例中，可以由技术人员预先设置好一些用户标签，以及用户标签与功能之间的关联关系。此时只需要将功能对应的使用样本数据与用户标签关联起来即可。而在另一些可选实施例中，亦可以对使用样本数据进行聚类，并基于聚类结果来标记用户标签(此时的用户标签属于抽象的用户标签，其表征的是用户的某一类抽象特性)。再根据使用样本数据对应的用户标签，即可确定出使用样本数据所归属的功能，与用户标签的关联关系。
[0126]
作为本技术的一个可选实施例，在上述将食物维度、娱乐维度、出行维度和健康维度，共四种功能类型的实施例基础上。本技术实施例在进行用户画像时，操作如下：
[0127]
对每种功能类型下的使用样本数据分别进行聚类，并对聚类结果进行标记，得到
每种功能类型分别对应的一个或多个用户标签。
[0128]
在本技术实施例中，考虑到功能类型本身就是功能的特性做的功能分类。因此其对应的使用样本数据本身就具有较强的关联性。再以功能类型为单位，对单个功能类型下的所有使用样本数据进行聚类，可以避免不同功能类型下使用样本数据聚类时的相互干扰。从而可以极大地提升聚类的准确性，使得用户标签更加贴合用户的个人情况，用户画像更加精准可靠。其中，本技术实施例不对具体使用的聚类方法做过多限定，可由技术人员根据实际选取或设定。例如，可以使用两步聚类、kmeans聚类或者系统聚类等算法。
[0129]
在完成s101至s103的操作后，即完成了阶段一用户画像的构建。
[0130]
本技术实施例的用户画像是基于用户实际使用情况建立的多维度标签画像，这样更能得到真实的用户。为后续对用户行为的分析，需求的预测，以及内容的推荐提供了更加可靠有效的基础数据。
[0131]
阶段二：内容推荐：
[0132]
在完成用户画像构建的基础上，本技术实施例可以进行第二个阶段：内容推荐。参考图4，示出了本技术实施例一提供的内容推荐方法中内容推荐阶段的实现流程图，详述如下：
[0133]
s401，获取第一用户在平台内的操作数据。
[0134]
在本技术实施例中，操作数据可以包含两种情况：
[0135]
情况1、操作数据是第一用户单次在平台内，对所有功能的使用数据。
[0136]
情况2、操作数据是第一用户最近多次使用平台过程中，在平台内对所有功能的使用数据。其中具体的次数可由技术人员设定，如可以设置为2至5中任一值。
[0137]
对于情况1，可以实现对用户单次使用平台的数据分析，适合一些有实时分析需求的场景。如需要在用户使用平台的过程中，一边响应的用户的操作，一边对用户操作进行实时分析，确定出对应适宜的待推荐内容。
[0138]
对于情况2，可以实现对用户一段时间内使用平台的数据分析，可以更加深入的挖掘用户实际行为倾向。如根据一段时间内用户在平台的操作数据，分析用户这段时间的潜在行为倾向，并确定出对应适宜的待推荐内容。
[0139]
本技术实施例不对操作数据实际的情况做过多限定，可根据实际应用场景确定。
[0140]
s402，基于操作数据对第一用户进行行为分析，预测第一用户的用户行为，并根据用户行为选取出第一用户对应的至少一个用户标签。
[0141]
在获取到操作数据之后，本技术实施例会进一步地对操作数据进行分析，预测用户接下来可能的行为，即接下来用户会使用哪个或哪些功能。其中，本技术实施例不对具体使用的用户行为预测方法做过多限定，可由技术人员根据实际需求选取或设定。例如，作为一种可选的实施方式，可以预先训练一个用户行为预测模型。即利用大量用户的实际行为路径作为训练样本数据，利用神经网络模型进行深度学习训练，得到一个可以基于已有的用户行为路径，预测用户后续行为的用户行为预测模型。再基于该模型来对操作数据中第一用户的功能使用行为进行处理，预测第一用户接下来可能的行为。而在另一种可选实施方式中，亦可以预先训练一个用于用户行为预测的gnn模型。再使用训练好的gnn模型来实现第一用户接下来可能行为的预测。
[0142]
在确定出用户接下来可能的用户行为之后，本技术实施例会将行为相关的所有用
户标签均选取出来。作为用户标签选取的一种可选实施方式，可以查找出与用户行为相关的所有功能，并将这些功能关联的所有用户标签都提取出来。
[0143]
作为用户标签选取的另一种可选实施方式，在上述将食物维度、娱乐维度、出行维度和健康维度，并对每种功能类型分别进行用户标签提取的实施例基础上。本技术实施例首先会确定用户行为中的功能所属的功能类型。再将这些功能类型内包含的所有功能筛选出来，并将筛选出的功能关联的所有用户标签全提取出来。例如，假设用户行为是使用外卖功能。由于外卖功能属于食物维度和健康维度，因此此时本技术实施例会将食物维度和健康维度内包含的所有功能确定出来，再将这些功能关联的用户标签全部提取出来。
[0144]
应当理解地，本技术实施例并未对预测的用户行为数量进行过多限定。即在s402中预测出的用户行为，既可以是单个行为，也可以是多个行为。例如，可以仅是使用外卖功能，也可以是使用外卖功能和使用团购买菜功能。
[0145]
s403，获取选取出的所有用户标签对应的使用样本数据，并基于用户行为和筛选出的使用样本数据预测第一用户的用户需求。
[0146]
用户行为是用户需求表象化的体现，其内在隐藏着用户内在的真实需求。例如用户虽然在使用外卖功能和团购买菜功能，但其实际可能只是不知道吃什么好，隐藏在内的实际需求是寻找适合用户口味的美食。因此在确定出用户行为对应的所有用户标签之后，本技术实施例会将这些用户标签下所有功能的使用样本数据都筛选出来，并进行用户需求分析。确定出用户的实际需求。其中，本技术实施例不对用户需求的划分规则做过多限定，可根据实际应用情况确定。例如，在一些可选实施例中，用户需求可以是技术人员预先手动设置多种需求标签，此时的用户需求具有较为明确日常生活实际含义。如寻找美食、做饭、购物、放松身体、旅游、出差和看病等。而在另一些可选实施例中亦可以采用一些聚类来对用户需求进行聚类，此时聚类得到的每种用户需求，是具有一定共性特征数据集标签。其不一定能与人类日常生活需求严格对应起来。
[0147]
本技术实施例不对用户需求具体的分析预测方法做过多限定，可由技术人员根据实际需求选取或设定。
[0148]
作为本技术的一个可选实施例，为了实现对用户需求的预测，会预先训练好一个可以进行用户需求预测的需求预测模型。相应的s403中，操作如下：
[0149]
基于筛选出的使用样本数据，生成这些使用样本数据所属功能的特征向量。
[0150]
生成用户行为对应功能的特征向量。
[0151]
将得到的所有特征向量输入至需求预测模型，得到第一用户的用户需求。
[0152]
其中，对需求预测模型的训练操作如下：
[0153]
预设一个初始的需求预测模型，该需求预测模型为神经网络模型，采用机器学习方法。可选用的机器学习方法包括但不限于如：逻辑回归、自适应增强、支持向量机、随机森林和长短期记忆网络的学习方法。
[0154]
针对多个样本用户收集多组训练数据，其中每组训练数据包括两部分：
[0155]
a部分：样本用户对一个或多个平台功能的使用数据，以及样本用户最近一次使用平台功能时对应的使用数据。
[0156]
b部分：样本用户在最近一次使用平台功能后，对应的用户需求。其中，由技术人员预先设置好多种用户需求，如寻找美食、做饭、购物、放松身体、旅游、出差和看病等。样本用
户只需在最近一次使用平台功能后，按照自己实际情况选取其中一个或多个用户需求即可。
[0157]
对训练数据的a部分进行向量化处理，得到训练数据中每个功能对应的特征向量。对于训练数据而言，将a部分对应的特征向量作为输入，对应b部分的用户需求作为对应的标签，对初始的需求预测模型进行训练。直至需求预测模型满足预设的收敛条件，得到可用于用户需求预测的需求预测模型，完成模型预训练。
[0158]
由于单个用户可能并没有使用过平台的所有功能。因此若仅根据用户实际使用功能的情况来进行行为预测，大概率预测出的行为，也是对用户已使用过的功能再次操作。仅行为预测本身难以跳出“用户已使用过的功能”这一范围。针对用户未使用过的功能仍无法涉及。为了解决这一问题，本技术实施例针对每个用户行为，都会选取出其对应的所有用户标签。并会将选取出的所有用户标签的使用样本数据筛选出来。从而使得即使用户只是希望进行某个行为，本技术实施例也可以查找出与该行为所有相关的功能并进行处理。从而使得用户不熟悉甚至完全没有使用过的功能，也可以被纳入可能推荐的范畴。进而使得推荐待推荐内容，能真正达到提高用户对平台功能的使用率的效果。
[0159]
s404，从使用样本数据中筛选出用户需求关联的待分析数据。
[0160]
由于s403中获取的是用户行为所有相关的使用样本数据，其数据内容较多，且并非其中所有的数据都与用户需求有较强相关性。
[0161]
例如假设在一些可选实施例中，用户行为是使用外卖功能。同时假设用户需求是做饭。外卖功能归属于食物维度和健康维度。此时本技术实施例将食物维度和健康维度内包含的所有功能的使用样本数据都提取出来，用于分析用户需求。但实际情况中网上医院、买药、外卖和团购美食这些功能，与做饭的相关性较差。而网上超市、网上菜市场和团购买菜这些功能，会涉及到做饭所需的食材、调味品和厨具等，因此与做饭的相关性较高。
[0162]
由此可知，若直接使用s403中获取到的使用样本数据来分析用户适宜的推荐内容，会有大量与用户需求弱相关的使用样本数据参与进来。这会降低最终推荐内容的准确性。因此本技术实施例在确定出用户需求之后，会对使用样本数据进行二次筛选，仅挑选出其中与用户需求强相关的使用样本数据(即待分析数据)。
[0163]
其中，本技术实施例不对待分析数据的筛选方法做过多限定。可由技术人员根据实际需求选取或设置。例如在一些可选实施例中，可由技术人员预先设置好用户需求与功能的关联关系。在s404中，先确定出与用户需求相关联的所有功能，再从使用样本数据中筛选出这些相关联功能的使用样本数据，并作为待分析数据。
[0164]
s405，对待分析数据进行分析，确定出第一用户对应的待推荐内容。待推荐内容为功能，或者功能内容。
[0165]
在本技术实施例中，将所需推荐给用户的内容称为待推荐内容。其中，待推荐内容既可以是功能，也可以是功能内的具体内容(即功能内容)。因此本技术实施例首先会对待分析数据进行解析，确定出待分析数据所属的功能，以及这些功能下第一用户使用过的功能内容。并且会将这些功能和功能内容作为对象再进行分析，确定出其中的待推荐内容。
[0166]
例如，假设在一实施例中，待分析数据是网上超市、网上菜市场和团购买菜这些功能的使用样本数据。此时本技术实施例会将网上超市、网上菜市场和团购买菜这些功能确定出来。同时根据待分析数据内用户对网上超市、网上菜市场和团购买菜这些功能实际的
使用情况，确定出那些功能内容被用户使用过。如假设待分析数据中记录有网上超市内的“超市卖场”、网上菜市场内的“海鲜水产”以及团购买菜内的“火锅食材”，这些功能内容被用户使用过。则此时也会把超市卖场、海鲜水产和火锅食材也选取出来。因此，此时本实施例会将网上超市、网上菜市场、团购买菜、超市卖场、海鲜水产和火锅食材，这3个功能和3个功能内容作为对象，得到共计6个分析的对象。
[0167]
在确定出功能及功能内容后，本技术实施例会从待分析数据中解析出各个功能和功能内容的属性数据。其中属性数据包括：
[0168]
功能的月均使用时长t11、功能的月均使用次数n11、最近一个月内功能使用的总时长 t12和总次数n12，功能内容的月均使用时长t21、功能内容的月均使用次数n21、以及最近一个月内功能内容的总时长t22和总次数n22。
[0169]
同时计算确定出的所有功能的月均使用时长平均值t01、月均使用次数平均值n01、最近一个月内所有功能使用的平均时长t02和平均次数n02。所有功能内容的月均使用时长平均值t03、月均使用次数平均值n03、最近一个月内所有功能内容使用的平均时长t04和平均次数n04。
[0170]
最后，根据各个功能和功能内容的属性数据，计算第一用户对每个功能和功能内容的需求分数。其中，功能的需求分数f1计算公式(2)如下：
[0171][0172]
功能内容的需求分数f2计算公式(3)如下：
[0173][0174]
其中，a、b、c、d均为权重系数，用于调节使用时长与使用次数的分数比重。e为调节系数，用于调节功能内容的需求分数，以使得功能内容的需求分数与功能的需求分数具有可比性。考虑到用户需求具有一定的时效性。因此实际应用中会设置c》a且d》b，在此基础上， a、b、c、d的具体值大小可由技术人员根据自行设置。同时，考虑到功能内容的使用时长和使用次数，一定小于其所属的功能。但从推荐效果上来看，推荐功能内容后若用户使用功能内容，那么一定需要先进入功能内容所属的功能。因此是有利于用户习惯使用该功能的。基于此，在本技术实施例中，设置e》1。在此基础上的e具体值大小可由技术人员根据自行设置。
[0175]
最后，将功能和功能内容中，需求分数最高的功能或功能内容作为待推荐内容，即可得到最适合第一用户实际需求的待推荐内容。
[0176]
s406，将待推荐内容推送至第一用户。
[0177]
本技术实施例不对待推荐内容的推送方法和时机做过多限定。可由技术人员根据实际需求自由设定。例如推送的方式可以是用户在使用平台的时候，对待推荐内容进行优先展示。如优先显示在平台首页醒目区域、显示在平台内的搜索界面、或者将待推荐内容在平台内的显示顺序提高，如从原本的第二页提前到第一页。亦可以是用户在使用平台的过程中，以弹窗等形式向用户推送待推荐内容，以吸引用户使用待推荐内容。而推送的时机，可以是在用户使用平台的过程中实时推送，亦可以是用户在下一次进入平台是进行推送。
[0178]
本技术实施例中通过预测用户行为来定位用户标签及标签下的使用样本数据，并通过使用样本数据确定出用户需求。再通过用户需求来二次筛选使用数据。此时筛选出的
待分析数据是经由用户行为和需求双重筛选出的样本数据，其与用户实际需求的相关度极高。且使用样本数据的选取和二次筛选过程都是根据用户实际情况来自适应实现的，相对使用样本数据全选时而言，可以减少大量弱相关的使用样本数据，从而可以提高最终推荐的准确。而相对人为划分一些使用数据类型并关联行为来选取使用数据而言，本技术实施例可以避免人为主观因素的影响，使得选取的使用数据更加贴合用户的个性化需求。因此使得本技术实施例最终的推荐内容更加准确。
[0179]
本技术实施例可以向推荐用户可能需要的功能或功能内容。这个可以使用户使用过的功能，也可以是用户没有使用过但可能需要的功能或功能内容。这样的推荐更加适合用户的实际情况，不会为了吸引用户使用新功能而强行推荐用户无用的功能，因此可以实现对用户实际情况的个性化推荐。当待推荐内容是用户从而尝试过的功能或功能内容时，由于这些推荐内容是用户所需的内容。因此不会引起用户的反感，反而会为用户提供便利。用户在尝试使用这些功能或功能内容后，会逐步熟悉这些功能。进而提升用户对平台功能的使用率，提高平台的用户体验。
[0180]
另外，我们不是简单的功能推荐。我们的待推荐内容既可以是功能本身，也可以是功能下的具体功能内容(用户在操作功能内容时，也同时在使用功能本身)。即我们推荐内容的颗粒度大小可以更为精细，对用户更加友好，因此使得推荐的效果更佳。
[0181]
对应于上文实施例的方法，图6示出了本技术实施例提供的内容推荐装置的结构框图，为了便于说明，仅示出了与本技术实施例相关的部分。图6示例的内容推荐装置可以是前述实施例一提供的内容推荐方法的执行主体。
[0182]
参照图5，该内容推荐装置包括：
[0183]
数据获取模块51，用于获取第一用户在平台内的操作数据。
[0184]
标签选取模块52，用于基于操作数据对第一用户进行行为分析，预测第一用户的用户行为，并根据用户行为从第一用户的用户画像中选取出至少一个用户标签。
[0185]
需求预测模块53，用于获取选取出的所有用户标签对应的使用样本数据，并基于用户行为和使用样本数据，预测第一用户的用户需求。使用样本数据中记录有第一用户对平台内功能的历史使用数据。
[0186]
数据筛选模块54，用于从使用样本数据中筛选出用户需求关联的待分析数据。
[0187]
内容确定模块55，用于对待分析数据进行分析，确定出第一用户对应的待推荐内容。待推荐内容为功能，或者功能内容。
[0188]
进一步地，内容确定模块，包括：
[0189]
对象确定模块，用于对待分析数据进行解析，确定出待分析数据所属的功能，以及这些功能下第一用户使用过的功能内容。
[0190]
数据解析模块，用于从待分析数据中解析出确定出的各个功能以及功能内容的属性数据，属性数据包括：
[0191]
功能的月均使用时长t11、功能的月均使用次数n11、最近一个月内功能使用的总时长 t12和总次数n12，功能内容的月均使用时长t21、功能内容的月均使用次数n21、以及最近一个月内功能内容的总时长t22和总次数n22。
[0192]
计算确定出的所有功能的月均使用时长平均值t01、月均使用次数平均值n01、最近一个月内确定出的所有功能使用的平均时长t02和平均次数n02。所有功能内容的月均使
用时长平均值t03、月均使用次数平均值n03、最近一个月内所有功能内容使用的平均时长t04 和平均次数n04。
[0193]
需求计算模块，用于根据以下公式计算各个功能的需求分数。
[0194][0195]
根据以下公式计算各个功能内容的需求分数。
[0196][0197]
其中，f1为功能的需求分数，f2为功能内容的需求分数，a、b、c、d均为权重系数，用于调节使用时长与使用次数的分数比重，e为调节系数，用于调节功能内容的需求分数， c》a、d》b且e》1。
[0198]
内容选取模块，用于将需求分数最高的功能或功能内容作为第一用户对应的待推荐内容。
[0199]
进一步地，内容推荐装置，还包括：
[0200]
第一信息获取模块，用于获取第一用户的用户信息，以及第一用户对平台内各个功能的历史使用数据。
[0201]
采样模块，用于对各个功能的历史使用数据进行采样，得到使用样本数据。
[0202]
用户画像模块，用于基于使用样本数据确定用户标签，得到第一用户对应的多个用户标签，完成对第一用户的用户画像构建。其中每个用户标签，关联有一种或多种功能。
[0203]
进一步地，内容推荐装置，还包括：
[0204]
用户查找模块，用于当第一用户存在没有历史使用数据的待处理功能时，查找出对待处理功能具有历史使用数据的至少一个第二用户。
[0205]
第二信息获取模块，用于获取各个第二用户的用户信息，以及对平台内各个功能的历史使用数据。
[0206]
数据剔除模块，用于从第二用户的历史使用数据中，剔除各个第二用户对待处理功能的历史使用数据。
[0207]
相似度计算模块，用于根据第一用户的用户信息、第一用户对平台各个功能的历史使用数据、各个第二用户的用户信息，以及剔除操作后各个第二用户对平台内功能的历史使用数据，计算第一用户与每个第二用户的相似度。
[0208]
数据填充模块，用于筛选出相似度最高的第二用户，并将筛选出的第二用户对待处理功能的历史使用数据，作为第一用户对待处理功能的历史使用数据。
[0209]
进一步地，相似度计算模块，包括：
[0210]
第一相似度模块，用于计算第一用户的用户信息和第二用户的用户信息相似度。
[0211]
统计模块，用于分别统计第一用户对各个功能的使用总时长和使用总次数，分别统计除待处理功能以外，第二用户对各个功能的使用总时长和使用总次数。
[0212]
第二相似度模块，用于利用以下公式计算第一用户与第二用户的相似度：
[0213][0214]
其中，设第一用户称为用户b，第二用户称为用户c。s
bc1
表示用户b和用户c的相似
度， n
(b)
表示用户b使用过的功能集合，n
(c)
表示用户c使用过除待处理功能以外的功能集合，t
bi
表示用户b对第i个功能的使用总时长，t
ci
表示用户c对第i个功能的使用总时长，n
bi
表示用户b对第i个功能的使用总次数，n
ci
表示用户c对第i个功能的使用总次数，s
bc2
表示用户b的和用户c的用户信息相似度，|n
(b)
|和|n
(c)
|分别表示n
(b)
和n
(c)
包含的功能数量， |n
(b)
|∪|n
(c)
|表示n
(b)
和n
(c)
包含的功能数量之和。
[0215]
α为权重因子，用于调节用户b和用户c在功能使用上的相似度和在用户信息上的相似度权重，β为时间因子，δ为数量因子。
[0216]
进一步地，采用模块，包括：
[0217]
功能分类模块，用于将平台内的功能分为食物维度、娱乐维度、出行维度和健康维度，共四种功能类型。其中，食物维度包含与饮食相关的功能、娱乐维度包含与休闲娱乐相关的功能、出行维度包含与出行和住宿相关的功能，而健康维度包含与饮食相关的功能以及与用户看病和用药相关的功能。
[0218]
策略获取模块，用于获取每种功能类型分别对应的不同的采样策略。
[0219]
采样子模块，用于按照每种功能类型分别对应的采样策略，分别对各个功能类型内功能的历史使用数据进行采样，得到使用样本数据。
[0220]
本技术实施例提供的内容推荐装置中各模块实现各自功能的过程，具体可参考前述图1 至图4实施例以及其他方法实施例的描述，此处不再赘述。
[0221]
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0222]
应当理解，当在本技术说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
[0223]
还应当理解，在本技术说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
[0224]
如在本技术说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
[0225]
另外，在本技术说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本技术实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。
[0226]
在本技术说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本技术的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是
所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
[0227]
本技术实施例提供的内容推荐方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，ar)/虚拟现实(virtual reality，vr)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，umpc)、上网本、个人数字助理(personal digitalassistant，pda)等终端设备上，本技术实施例对终端设备的具体类型不作任何限制。
[0228]
例如，所述终端设备可以是wlan中的站点(staion，st)，可以是蜂窝电话、无绳电话、会话启动协议(session initiationprotocol，sip)电话、无线本地环路(wireless local loop， wll)站、个人数字处理(personal digital assistant，pda)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、车联网终端、电脑、膝上型计算机、手持式通信设备、手持式计算设备、卫星无线设备、无线调制解调器卡、电视机顶盒(set top box，stb)、用户驻地设备(customer premise equipment，cpe)和/或用于在无线系统上进行通信的其它设备以及下一代通信系统，例如，5g网络中的移动终端或者未来演进的公共陆地移动网络(public land mobile network，plmn)网络中的移动终端等。
[0229]
作为示例而非限定，当所述终端设备为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。
[0230]
图6是本技术一实施例提供的终端设备的结构示意图。如图6所示，该实施例的终端设备6包括：至少一个处理器60(图6中仅示出一个)、存储器61，所述存储器61中存储有可在所述处理器60上运行的计算机程序62。所述处理器60执行所述计算机程序62时实现上述各个内容推荐方法实施例中的步骤，例如图1所示的步骤101至103。或者，所述处理器60执行所述计算机程序62时实现上述各装置实施例中各模块/单元的功能，例如图5 所示模块51至55的功能。
[0231]
所述终端设备6可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器60、存储器61。本领域技术人员可以理解，图6 仅仅是终端设备6的示例，并不构成对终端设备6的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入发送设备、网络接入设备、总线等。
[0232]
所称处理器60可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(applicationspecific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理
器等。
[0233]
所述存储器61在一些实施例中可以是所述终端设备6的内部存储单元，例如终端设备 6的硬盘或内存。所述存储器61也可以是所述终端设备6的外部存储设备，例如所述终端设备6上配备的插接式硬盘，智能存储卡(smart media card，smc)，安全数字(secure digital， sd)卡，闪存卡(flash card)等。进一步地，所述存储器61还可以既包括所述终端设备6 的内部存储单元也包括外部存储设备。所述存储器61用于存储操作系统、应用程序、引导装载程序(bootloader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器61还可以用于暂时地存储已经发送或者将要发送的数据。
[0234]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0235]
本技术实施例还提供了一种终端设备，所述终端设备包括至少一个存储器、至少一个处理器以及存储在所述至少一个存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使所述终端设备实现上述任意各个方法实施例中的步骤。
[0236]
本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。
[0237]
本技术实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时实现可实现上述各个方法实施例中的步骤。
[0238]
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(read-only memory，rom)、随机存取存储器(random accessmemory，ram)、电载波信号、电信信号以及软件分发介质等。
[0239]
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
[0240]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0241]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目
的。
[0242]
以上所述实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使对应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。