CN104504084B - 确定用户留存率的方法及装置 - Google Patents

Abstract

本公开是关于一种确定用户留存率的方法及装置，用以在用户留存率计算过程中的计算效率。所述方法包括：确定首日与当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数；根据所述用户身份标识和所述相隔天数确定在所述首日的新增用户的数量以及所述新增用户在所述当日的留存数量；根据所述新增用户的数量与所述留存数量确定所述应用程序在所述当日的用户留存率。本公开技术方案可以避免较为耗时耗力的去重与求交集的计算过程，提高计算用户留存率的效率。

Description

确定用户留存率的方法及装置

技术领域

本公开涉及互联网技术领域，尤其涉及一种确定用户留存率的方法及装置。

背景技术

随着移动应用的飞速发展，移动应用的提供商通过计算用户留存率来确定移动应用如何迎合用户，通过对用户行为进行分析，定制产品方向，进而做最有价值的活动推广。

相关技术中有首日留存率(2天留存率)、3日留存率、7日留存率、15天留存率和月留存率等等，以3日留存率为例，第3天用户留存率指在今天的新增用户在3天后还在使用的用户/今天的新增用户数，3日内用户留存率指在今天的新增用户在未来的三天有使用的用户数/今天的新增用户数。

以音乐应用程序(app)为例说明相关技术中留存率的计算过程：例如，需要在9.23日计算9.21日的3日留存率，从9.21日的日志中分析出当天新增用户人数num1，并记录这些新增用户的idset1，计算9.23日使用该音乐app的用户，进而得到9月23日使用该音乐app的idset2，确定set1和set2的交集的个数num2，计算得到9.21日的3日留存率为num2/num1。在上述确定用户留存率的过程中，由于同一个用户在当日有可能多次登录该应用程序，因此为了避免重复统计同一个用户的多次登录行为，还需要对同一用户在同日内的多次登录行为进行去重处理，而“去重”与“两个集合求交集”均是比较耗时的操作；尤其是在3日内留存率时，还需要确定9.22和9.23两天用户的id集合，当用户量在千万级别时，将会导致服务器占用大量的计算时间对音乐应用的日志进行统计处理。

发明内容

为克服相关技术中存在的问题，本公开实施例提供一种确定用户留存率的方法及装置，用以提高在用户留存率计算过程中的计算效率。

根据本公开实施例的第一方面，提供一种确定用户留存率的方法，应用在服务器上，包括：

确定首日与当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数；

根据所述用户身份标识和所述相隔天数确定在所述首日的新增用户的数量以及所述新增用户在所述当日的留存数量；

根据所述新增用户的数量与所述留存数量确定所述应用程序在所述当日的用户留存率。

在一实施例中，所述根据所述用户身份标识和所述相隔天数确定在所述首日的新增用户的数量，可包括：

将所述相隔天数为0的用户身份标识确定为首日登录所述应用程序的新增用户；

统计所述多个日志消息中所述相隔天数为0的用户个数，得到登录所述应用程序的新增用户的数量。

在一实施例中，所述根据所述新增用户的数量与所述留存数量确定所述应用程序在所述当日的用户留存率，可包括：

确定所述留存数量与所述新增用户的数量的比值，将所述比值确定为所述应用程序在所述当日的用户留存率。

根据本公开实施例的第二方面，提供一种确定用户留存率的方法，应用在服务器上，包括：

确定首日至当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数、从所述首日截止到所述当日所述用户使用所述应用程序的使用天数；

根据所述用户身份标识、所述相隔天数确定在所述首日的新增用户的数量以及根据所述用户身份标识、所述使用天数确定所述新增用户从所述首日的次日至所述当日的留存总数量；

根据所述新增用户的数量与所述留存总数量确定所述应用程序在所述相隔天数内的用户留存率。

在一实施例中，所述根据所述用户身份标识、所述相隔天数确定在所述首日的新增用户的数量，可包括：

将所述相隔天数为0的用户身份标识确定为首日登录所述应用程序的新增用户；

统计所述多个日志消息中所述相隔天数为0的用户个数，得到登录所述应用程序的新增用户的数量。

在一实施例中，所述根据所述用户身份标识、所述使用天数确定从所述首日的次日至所述当日的留存总数量，可包括：

将所述使用天数为1的用户身份标识确定为从所述次日至所述当日在所述新增用户数量中使用所述应用程序的用户；

统计所述多个日志消息中所述使用天数为1的用户个数，得到从所述次日至所述当日所述新增用户登录所述应用程序的留存总数量。

在一实施例中，所述根据所述新增用户的数量与所述留存数量确定所述应用程序在所述相隔天数内的用户留存率，可包括：

确定所述留存总数量与所述新增用户的数量的比值，将所述比值确定所述应用程序在所述相隔天数内的用户留存率。

根据本公开实施例的第三方面，提供一种确定用户留存率的装置，应用在服务器上，包括：

第一确定模块，被配置为确定首日与当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数；

第二确定模块，被配置为根据所述第一确定模块确定的所述用户身份标识和所述相隔天数确定在所述首日的新增用户的数量以及所述新增用户在所述当日的留存数量；

第三确定模块，被配置为根据所述第二确定模块确定的所述新增用户的数量与所述留存数量确定所述应用程序在所述当日的用户留存率。

在一实施例中，所述第二确定模块可包括：

第一确定子模块，被配置为将所述第一确定模块确定的所述相隔天数为0的用户身份标识确定为首日登录所述应用程序的新增用户；

第一统计子模块，被配置为统计所述多个日志消息中所述第一确定子模块确定的所述相隔天数为0的用户个数，得到登录所述应用程序的新增用户的数量。

在一实施例中，所述第三确定模块可包括：

第二确定子模块，被配置为确定所述第二确定模块确定的所述留存数量与所述新增用户的数量的比值，将所述比值确定为所述应用程序在所述当日的用户留存率。

根据本公开实施例的第四方面，提供一种确定用户留存率的装置，应用在服务器上，包括：

第四确定模块，被配置为确定首日至当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数、从所述首日截止到所述当日所述用户使用所述应用程序的使用天数；

第五确定模块，被配置为根据所述用第四确定模块确定的所述户身份标识、所述相隔天数确定所述新增用户从所述首日的次日至所述当日的留存总数量；

第六确定模块，被配置为根据所述第五确定模块确定的所述新增用户的数量与所述留存总数量确定所述应用程序在所述相隔天数内的用户留存率。

在一实施例中，所述第五确定模块可包括：

第三确定子模块，被配置为将所述第四确定模块确定的所述相隔天数为0的用户身份标识确定为首日登录所述应用程序的新增用户；

第二统计子模块，被配置为统计所述多个日志消息中所述第三确定子模块确定的所述相隔天数为0的用户个数，得到登录所述应用程序的新增用户的数量。

在一实施例中，所述第五确定模块可包括：

第四确定子模块，被配置为将所述第四确定模块确定的所述使用天数为1的用户身份标识确定为从所述次日至所述当日在所述新增用户数量中使用所述应用程序的用户；

第三统计子模块，被配置为统计所述多个日志消息中所述第四确定子模块确定的所述使用天数为1的用户个数，得到从所述次日至所述当日所述新增用户登录所述应用程序的留存总数量。

在一实施例中，所述第六确定模块可包括：

第五确定子模块，被配置为确定所述第五确定模块确定的所述留存总数量与所述新增用户的数量的比值，将所述比值确定所述应用程序在所述相隔天数内的用户留存率。

根据本公开实施例的第五方面，提供一种确定用户留存率的装置，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

确定首日与当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数；

根据所述用户身份标识和所述相隔天数确定在所述首日的新增用户的数量以及所述新增用户在所述当日的留存数量；

根据所述新增用户的数量与所述留存数量确定所述应用程序在所述当日的用户留存率。

根据本公开实施例的第六方面，提供一种确定用户留存率的装置，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

确定首日至当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数、从所述首日截止到所述当日所述用户使用所述应用程序的使用天数；

根据所述用户身份标识、所述相隔天数确定在所述首日的新增用户的数量以及根据所述用户身份标识、所述使用天数确定所述新增用户从所述首日的次日至所述当日的留存总数量；

根据所述新增用户的数量与所述留存总数量确定所述应用程序在所述相隔天数内的用户留存率。

本公开的实施例提供的技术方案可以包括以下有益效果：通过日志消息的方式来记录用户登录应用程序的次数与天数，由于通过一个日志消息的方式可以统计用户在每一日登录应用程序的行为，当用户存在在一日之内多次登录应用程序的情形下，避免了相关技术中需要对同一用户在同日内的多次登录行为进行去重处理；通过新增用户的数量与留存数量或者留存总数量确定用户留存率，避免了对首日的新增用户与当日内登录应用程序的用户之间的求交集操作，由此可知，本公开实施例避免了较为耗时耗力的去重与求交集的计算过程，提高了计算用户留存率的效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据一示例性实施例示出的确定用户留存率的方法的流程图。

图2是根据一示例性实施例一示出的确定用户留存率的方法的流程图。

图3是根据又一示例性实施例示出的确定用户留存率的方法的流程图。

图4是根据又一示例性实施例一示出的确定用户留存率的方法的流程图。

图5是根据一示例性实施例示出的一种确定用户留存率的装置的框图。

图6是根据一示例性实施例示出的另一种确定用户留存率的装置的框图。

图7是根据又一示例性实施例示出的一种确定用户留存率的装置的框图。

图8是根据又一示例性实施例示出的另一种确定用户留存率的装置的框图。

图9是根据一示例性实施例示出的一种适用于确定用户留存率的装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的确定用户留存率的方法的流程图，该确定用户留存率的方法可以应用在服务器，如图1所示，该确定用户留存率的方法包括以下步骤S101-S103：

在步骤S101中，确定首日与当日用户登录应用程序时的日志消息，其中，日志消息包括用户身份标识、从当日截止到首日的相隔天数。

在一实施例中，当日为2014.12.19日，如果用户在2014.12.16日(本公开实施例中的首日)通过客户端首次登录了应用程序，服务器可以接收到来自客户端的日志消息，该日志消息可以包含两个字段(uid，day)，其中，uid表示用户身份标识，day表示客户端从当日截止到首日的相隔天数，例如，新增用户从2014.12.16日至2014.12.19使用应用程序的相隔天数为18-16＝3天。

在步骤S102中，根据用户身份标识和相隔天数确定在首日的新增用户的数量以及根据相隔天数统计新增用户在当日的留存数量。

在一实施例中，服务器可以根据日志消息(uid＝XXX，day＝0)的uid来确定首日登录应用程序的新增用户，即如果识别到该uid为新的用户身份标识即可识别是否为新增用户，通过统计新的uid的个数来确定当日新增用户的数量Sum_(M)(day＝0)，其中，M表示具体的首日日期，例如，2014.12.16；在另一实施例中，可以直接通过日志消息中的day是否为0来确定是否为新增用户，并统计日志消息中day为0的数量，即可得到首日的新增用户的数量Sum_(M)(day＝0)。

在一实施例中，例如，2014.12.16日为首日的新增用户有100个，其中有50个新增用户在2014.12.19登录使用了该应用程序，则该50个新增用户在2014.12.19通过客户端向服务器发送的日志消息中，day参数所记录的相隔天数为19-16＝3天，由此，通过统计该100个新增用户在当日(2014.12.19)的day参数，即可确定该100个新增用户在当日登录使用该应用程序的留存数量。

在步骤S103中，根据新增用户的数量与留存数量确定应用程序在当日的用户留存率。

在一实施例中，可以通过上述步骤S102得到的新增用户在当日的留存数量与新增用户在首日的数量的比值：来确定应用程序在当日的用户留存率，其中，Sum_(M)(day＝0)表示首日新增用户的数量，Sum_(M+N)(day＝N)表示首日新增用户在当日仍旧登录使用该应用程序的数量。

在本实施例中，通过日志消息的方式来记录用户登录应用程序的次数与天数，由于通过一个日志消息的方式统计用户在每一日登录应用程序的行为，当用户存在在一日之内多次登录应用程序的情形下，可以避免相关技术中需要对同一用户在同日内的多次登录行为进行去重处理；通过新增用户的数量与留存数量确定用户在当日的留存数量，避免了对首日的新增用户与当日内登录应用程序的用户之间的求交集的操作，由此可知，本公开实施例避免了较为耗时耗力的去重与求交集的计算过程，因此提高了计算用户留存率的效率。

在一实施例中，步骤S102可以包括：

将相隔天数为0的用户身份标识确定为首日登录应用程序的新增用户；

统计多个日志消息中相隔天数为0的用户个数，得到登录应用程序的新增用户的数量。

在一实施例中，步骤S103还可以包括：

确定留存数量与新增用户的数量的比值，将比值确定为应用程序在当日的用户留存率。

具体如何确定用户留存率的，请参考后续实施例。

至此，本公开实施例提供的上述方法，可以避免较为耗时耗力的去重与求交集的计算过程，提高了计算用户留存率的效率。

下面以具体实施例来说明本公开实施例提供的技术方案。

图2是根据一示例性实施例一示出的确定用户留存率的方法的流程图；本实施例利用本公开实施例提供的上述方法，以如何统计首日新增用户与根据相隔天数来确定用户留存率为例进行示例性说明，如图2所示，包括如下步骤：

在步骤S201中，确定首日与当日用户登录应用程序时的日志消息，其中，日志消息包括用户身份标识、从当日截止到首日的相隔天数。

步骤S201的描述可以参考上述步骤S101的描述，在此不再详述。

在步骤S202中，将相隔天数为0的用户身份标识确定为首日登录应用程序的新增用户。

在步骤S203中，统计多个日志消息中相隔天数为0的用户个数，得到登录应用程序的新增用户的数量。

在一个实施例中，当用户通过客户端登录使用该应用程序时，会向服务器发送日志消息(uid＝XXX，day＝0)，因此通过统计参数day的值，即可统计出该用户身份标识的用户为首日登录的新增用户。

在步骤S204中，根据相隔天数统计新增用户在当日的留存数量。

步骤S202的描述可以参考上述步骤S102的描述，在此不再详述。

在步骤S205中，确定留存数量与新增用户的数量的比值，将比值确定为应用程序在当日的用户留存率。

步骤S205的描述可以参考上述步骤S103的描述，在此不再详述。

为了更清楚的理解本公开实施例的技术方案，下面以用户A₁、A₂、…A₁₅₀、A₁₅₁共151位用户在2014.12.16日登录了音乐应用程序，则该151位用户对应的客户端在该日均向服务器发送了日志消息，其中，通过服务器的统计，确定A₁、A₂、…A₁₀₀共100位用户的日志消息中的day参数为0，则确定A₁、A₂、…A₁₀₀共100位用户为2014.12.16日的首日新增用户，如果需要确定该应用程序第3日(即2014.12.18日)的用户留存率，则还需要统计A₁、A₂、…A₁₀₀这100位新增用户在2014.12.18日有多少用户登录使用该应用程序，本公开实施例中，可以通过在2014.12.18日的日志消息中，这100位用户中有多少用户发送了日志消息，即可得到该100位用户在2014.12.18日登录使用的留存数量，此外，还可以通过统计在2014.12.18日服务器接收到的日志消息，从日志消息中的day参数来确定该100位用户在2014.12.18日登录使用的留存数量，例如，服务器通过统计该100位用户在2014.12.18的登录行为，确定A₁、A₂、…A₅₀50位用户在2014.12.18日登录了该应用程序，也即留存数量为50，由此可以计算得到该应用程序第3日的用户留存率为50/151＝0.331。

本实施例中，通过日志消息中的day参数来确定新增用户使用应用程序的相隔天数，避免了相关技术中需要对同一用户在同日内的多次登录行为进行去重处理；通过新增用户的数量与留存数量确定用户在当日的留存数量，避免了对首日的新增用户与当日内登录应用程序的用户之间的求交集的操作，由此可知，本公开实施例避免了较为耗时耗力的去重与求交集的计算过程，因此提高了计算用户留存率的效率。

图3是根据又一示例性实施例示出的确定用户留存率的方法的流程图，该确定用户留存率的方法可以应用在服务器，如图3所示，该确定用户留存率的方法包括以下步骤S301-S303：

在步骤S301中，确定首日至当日用户登录应用程序时的日志消息，日志消息包括用户身份标识、从当日截止到首日的相隔天数、从首日截止到当日用户使用应用程序的使用天数。

在一实施例中，当日为2014.12.19日，如果用户在2014.12.16日(本公开实施例中的首日)通过客户端首次登录了应用程序，服务器可以接收到来自客户端的日志消息，该日志消息可以包含三个字段(uid，day，times)，其中，uid表示用户身份标识，day表示客户端从当日截止到首日的相隔天数，times表示从首日截止到当日用户使用应用程序的使用天数，例如，用户从2014.12.16日至2014.12.19使用应用程序的相隔天数为19-16＝3天，times表示从首日截止到当日用户使用应用程序的使用天数，例如，从2014.12.16日至2014.12.19日，用户在2014.12.16首日登录使用了该应用程序，其中，17、19日登陆了应用程序，2014.12.18日并未登陆应用程序，则除了首日之外使用应用程序的使用天数为2天。

在一个实施例中，可以通过客户端在安装使用应用程序的首日向服务器发送日志消息(uid＝XXX，day＝0，tiems＝0)，用户如果在次日没有登陆应用程序则不会向服务器发送日志消息，用户如果在第三日登陆应用程序则发送日志消息(uid＝XXX，day＝2，times＝1)。

在步骤S302中，根据用户身份标识、相隔天数确定在首日的新增用户的数量以及根据用户身份标识、使用天数确定新增用户从首日的次日至当日的留存总数量。

在一实施例中，服务器可以根据日志消息(uid＝XXX，day＝0，tiems＝0)的uid来确定首日登录应用程序的新增用户数量，即如果识别到该uid为新的用户身份标识即可识别是否为新增用户，通过统计新的uid的个数来确定当日新增用户的数量Sum_(M)(day＝0)，其中，M表示具体的首日日期，例如，2014.12.16；在另一实施例中，可以直接通过日志消息中的day是否为0来确定是否为新增用户，并统计日志消息中day为0的数量，即可得到首日的新增用户的数量Sum_(M)(day＝0)。

在一实施例中，例如，2014.12.16日为首日的新增用户有100个，其中有90个新增用户在2014.12.17日登录使用了该应用程序，有80个新增用户在2014.12.18日登录使用了该应用程序，50个新增用户在2014.12.19日登录使用了该应用程序，由于每个用户的登录习惯不同，在2014.12.17日登录的90个新增用户、2014.12.17日登录的80个新增用户、2014.12.17日登录的50个新增用户中，有可能存在同一个用户在上述三日内重复登录的行为，本公开实施例可以通过得到三日内的留存总数量，即，对times为1的新增用户进行统计即可，避免了对三日内重复登录应用程序的用户的重复统计，进而可以提高计算用户留存率的准确度。

在步骤S303中，根据新增用户的数量与留存总数量确定应用程序在相隔天数内的用户留存率。

在一实施例中，可以通过上述步骤S302得到的新增用户在次日至当日的留存总数量与新增用户在首日的数量的比值：来确定应用程序从次日至当日内的用户留存率，其中，Sum_(M)(day＝0)表示首日新增用户的数量，表示从次日至当日内新增用户仍旧登录使用该应用程序的数量。

在本实施例中，通过日志消息中的day参数和times参数来确定新增用户使用应用程序的相隔天数和使用天数，避免了相关技术中需要对同一用户在从次日至当日之间多次重复登录行为的去重处理；通过新增用户的数量与留存总数量确定用户从首日至当日的留存总数量，避免了对首日的新增用户从次日至当日之间重复多次登录应用程序的求交集的操作，由此可知，本公开实施例避免了较为耗时耗力的去重与求交集的计算过程，因此提高了计算用户留存率的效率。

在一实施例中，步骤S302可以包括：

将相隔天数为0的用户身份标识确定为首日登录应用程序的新增用户；

统计多个日志消息中相隔天数为0的用户个数，得到登录应用程序的新增用户的数量。

在一实施例中，步骤S302可以包括：

将使用天数为1的用户身份标识确定为从次日至当日在新增用户数量中使用应用程序的用户；

统计多个日志消息中使用天数为1的用户个数，得到从次日至当日新增用户登录应用程序的留存数量。

在一实施例中，步骤S303还可以包括：

确定留存数量与新增用户的数量的比值，将比值确定为应用程序在当日的用户留存率。

具体如何确定用户留存率的，请参考后续实施例。

至此，本公开实施例提供的上述方法，避免了较为耗时耗力的去重与求交集的计算过程，因此提高了计算用户留存率的效率。

下面以具体实施例来说明本公开实施例提供的技术方案。

图4是根据又一示例性实施例一示出的确定用户留存率的方法的流程图；本实施例利用本公开实施例提供的上述方法，以如何根据相隔天数和使用天数来确定用户留存率为例进行示例性说明，如图4所示，包括如下步骤：

在步骤S401中，统计首日至当日用户登录应用程序时的日志消息，日志消息包括用户身份标识、从当日截止到首日的相隔天数、从首日截止到当日用户使用应用程序的使用天数。

步骤S401的描述可以参考上述步骤S301的描述，在此不再详述。

在步骤S402中，将相隔天数为0的用户身份标识确定为首日登录应用程序的新增用户。

在步骤S403中，将相隔天数为0的用户身份标识确定为首日登录应用程序的新增用户。

步骤S402和步骤S403的描述可以参考上述步骤S202和步骤203的描述，在此不再详述。

在步骤S404中，将使用天数为1的用户身份标识确定为从次日至当日在新增用户数量中使用应用程序的用户。

在步骤S405中，统计多个日志消息中使用天数为1的用户个数，得到从次日至当日新增用户登录应用程序的留存总数量。

步骤S404和步骤S405的描述可以参考上述步骤S302的描述，在此不再详述。

在步骤S406中，确定留存总数量与新增用户的数量的比值，将比值确定应用程序在相隔天数内的用户留存率。

步骤S406的描述可以参考上述步骤S303的描述，在此不再详述。

为了更清楚的理解本公开实施例的技术方案，下面以用户A₁、A₂、…A₁₅₀、A₁₅₁共151位用户在2014.12.16日登录了音乐应用程序，则该151位用户对应的客户端在该日均向服务器发送了日志消息，其中，通过服务器的统计，确定A₁、A₂、…A₁₀₀共100位用户的日志消息中的day参数为0，则确定A₁、A₂、…A₁₀₀共100位用户为2014.12.16日的首日的新增用户，如果需要确定该应用程序的3日内(即2014.12.16至2014.12.18日)的用户留存率，则还需要统计A₁、A₂、…A₁₀₀这100位新增用户在2014.12.16至2014.12.18日有多少用户登录使用该应用程序，本公开实施例中，可以通过在2014.12.17日的日志消息中的times参数是否为1，来统计这100位用户中有多少用户在17日登陆使用了该应用程序，即可得到该100位用户在2014.12.17日登录使用该应用程序的留存数量，可以通过统计在2014.12.18日的日志消息中的times参数是否为1，来统计这100位用户中有多少用户在18日登陆使用了该应用程序，即可得到该100位用户中有多少用户在18日登陆使用该应用程序的留存数量，通过将上述两日内的留存数量相加，得到3日内的留存总数量，例如，服务器通过统计该100位用户在2014.12.17日的登录行为，确定A₁、A₂、…A₅₀50位新增用户在2014.12.17日登录了该应用程序，也即17日的留存数量为50，服务器通过统计该100位用户在2014.12.18日的登录行为，确定A₃₁、A₃₂、…A₉₀60位新增用户在2014.12.18日登录了该应用程序，也即18日的留存数量为60，由于A₃₁、A₃₂、…A₅₀30位新增用户在17日的日志消息中的times为1，而18日的日志消息中的times为2，因此，该30位A₃₁、A₃₂、…A₅₀用户不计入18日的留存数量中，因此本公开实施例通过times参数即可避免了去重的操作，由此可以计算得到该应用程序3日内的用户留存率为(50+60)/151＝0.801。

本实施例的有益技术效果可以参见上述实施例的有益技术效果，在此不再详述。

图5是根据一示例性实施例示出的一种确定用户留存率的装置的框图，应用在服务器上，如图5所示，确定用户留存率的装置包括：

第一确定模块51，被配置为确定首日与当日用户登录应用程序时的日志消息，日志消息包括用户身份标识、从当日截止到首日的相隔天数；

第二确定模块52，被配置为根据第一确定模块51确定的用户身份标识和相隔天数确定在首日的新增用户的数量以及新增用户在当日的留存数量；

第三确定模块53，被配置为根据第二确定模块52确定的新增用户的数量与留存数量确定应用程序在当日的用户留存率。

如图6所示，第二确定模块52可包括：

第一确定子模块521，被配置为将第一确定模块51确定的相隔天数为0的用户身份标识确定为首日登录应用程序的新增用户；

第一统计子模块522，被配置为统计多个日志消息中第一确定子模块521确定的相隔天数为0的用户个数，得到登录应用程序的新增用户的数量。

在一实施例中，第三确定模块53可包括：

第二确定子模块531，被配置为确定第二确定模块52确定的留存数量与新增用户的数量的比值，将比值确定为应用程序在当日的用户留存率。

图7是根据又一示例性实施例示出的一种确定用户留存率的装置的框图，应用在服务器上，如图7所示，确定用户留存率的装置包括：

第四确定模块71，被配置为确定首日至当日用户登录应用程序时的日志消息，日志消息包括用户身份标识、从当日截止到首日的相隔天数、从首日截止到当日用户使用应用程序的使用天数；

第五确定模块72，被配置为根据用第四确定模块71确定的户身份标识、相隔天数确定新增用户从首日的次日至当日的留存总数量；

第六确定模块73，被配置为根据第五确定模块72确定的新增用户的数量与留存总数量确定应用程序在相隔天数内的用户留存率。

如图8所示，第五确定模块72可包括：

第三确定子模块721，被配置为将第四确定模块71确定的相隔天数为0的用户身份标识确定为首日登录应用程序的新增用户；

第二统计子模块722，被配置为统计多个日志消息中第三确定子模块721确定的相隔天数为0的用户个数，得到登录应用程序的新增用户的数量。

在一实施例中，第五确定模块72可包括：

第四确定子模块721，被配置为将第四确定模块71确定的使用天数为1的用户身份标识确定为从次日至当日在新增用户数量中使用应用程序的用户；

第三统计子模块722，被配置为统计多个日志消息中第四确定子模块721确定的使用天数为1的用户个数，得到从次日至当日新增用户登录应用程序的留存总数量。

在一实施例中，第六确定模块73可包括：

第五确定子模块731，被配置为确定第五确定模块72确定的留存总数量与新增用户的数量的比值，将比值确定应用程序在相隔天数内的用户留存率。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图9是根据一示例性实施例示出的一种适用于确定用户留存率的装置的框图。例如，装置900可以被提供为一服务器。参照图9，装置900包括处理组件922，其进一步包括一个或多个处理器，以及由存储器932所代表的存储器资源，用于存储可由处理部件922的执行的指令，例如应用程序。存储器932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件922被配置为执行指令，以执行上述确定用户留存率的方法。

装置900还可以包括一个电源组件926被配置为执行装置900的电源管理，一个有线或无线网络接口950被配置为将装置900连接到网络，和一个输入输出(I/O)接口958。装置900可以操作基于存储在存储器932的操作***，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM或类似。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (8)

1.一种确定用户留存率的方法，应用在服务器上，其特征在于，所述方法包括：

确定首日至当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数、从所述首日截止到所述当日所述用户使用所述应用程序的使用天数；

根据所述用户身份标识、所述相隔天数确定在所述首日的新增用户的数量以及根据所述用户身份标识、所述使用天数确定所述新增用户从所述首日的次日至所述当日的留存总数量；

根据所述新增用户的数量与所述留存总数量确定所述应用程序在所述相隔天数内的用户留存率。

2.如权利要求1所述的方法，其特征在于，所述根据所述用户身份标识、所述相隔天数确定在所述首日的新增用户的数量，包括：

将所述相隔天数为0的用户身份标识确定为首日登录所述应用程序的新增用户；

统计多个所述日志消息中所述相隔天数为0的用户个数，得到登录所述应用程序的新增用户的数量。

3.如权利要求1所述的方法，其特征在于，所述根据所述用户身份标识、所述使用天数确定从所述首日的次日至所述当日的留存总数量，包括：

将所述使用天数为1的用户身份标识确定为从所述次日至所述当日在所述新增用户数量中使用所述应用程序的用户；

统计多个所述日志消息中所述使用天数为1的用户个数，得到从所述次日至所述当日所述新增用户登录所述应用程序的留存总数量。

4.如权利要求1所述的方法，其特征在于，所述根据所述新增用户的数量与所述留存总数量确定所述应用程序在所述相隔天数内的用户留存率，包括：

确定所述留存总数量与所述新增用户的数量的比值，将所述比值确定为所述应用程序在所述相隔天数内的用户留存率。

5.一种确定用户留存率的装置，应用在服务器上，其特征在于，所述装置包括：

第四确定模块，被配置为确定首日至当日用户登录应用程序时的日志消息，所述日志消息包括用户身份标识、从所述当日截止到所述首日的相隔天数、从所述首日截止到所述当日所述用户使用所述应用程序的使用天数；

第五确定模块，被配置为根据用所述第四确定模块确定的所述户身份标识、所述相隔天数确定新增用户从所述首日的次日至所述当日的留存总数量；

第六确定模块，被配置为根据所述第五确定模块确定的所述新增用户的数量与所述留存总数量确定所述应用程序在所述相隔天数内的用户留存率。

6.如权利要求5所述的装置，其特征在于，所述第五确定模块包括：

第三确定子模块，被配置为将所述第四确定模块确定的所述相隔天数为0的用户身份标识确定为首日登录所述应用程序的新增用户；

第二统计子模块，被配置为统计多个所述日志消息中所述第三确定子模块确定的所述相隔天数为0的用户个数，得到登录所述应用程序的新增用户的数量。

7.如权利要求5所述的装置，其特征在于，所述第五确定模块包括：

第四确定子模块，被配置为将所述第四确定模块确定的所述使用天数为1的用户身份标识确定为从所述次日至所述当日在所述新增用户数量中使用所述应用程序的用户；

第三统计子模块，被配置为统计多个所述日志消息中所述第四确定子模块确定的所述使用天数为1的用户个数，得到从所述次日至所述当日所述新增用户登录所述应用程序的留存总数量。

8.如权利要求5所述的装置，其特征在于，所述第六确定模块包括：

第五确定子模块，被配置为确定所述第五确定模块确定的所述留存总数量与所述新增用户的数量的比值，将所述比值确定所述应用程序在所述相隔天数内的用户留存率。