留存率以及相关误区

Paul H. Müller

2019年9月24日

对于 Adjust 的很多客户而言,留存率—特别是“ Day 1(次留)”的留存率—是评估推广活动表现的重要指标。然而,这个被广泛采用的指标是如何定义与计算的,行业间相关的讨论却很少。

虽然这种 KPI 乍看之下似乎简明易懂,但实际上它牵涉到相当复杂的考虑。并且随着定义方式的不同,所产生的数据结果也会大相径庭。

例如,最近从其他归因供应商转换过来的一位 Adjust 客户发现,他们 Day 1 的平均留存率大幅下跌。就此,该客户会认为,Adjust 计算留存率的方法显然有问题。

但事实上,这两种方法都“正确”,不同的只是对“天(Day)”的定义。

这到底有多难?

当在评估用户安装后的“留存”时,我们的想象情境可能是:该用户在下班返家途中安装我们的应用,并且在第二天早上再次打开该应用。该用户可能在去上班的途中,玩了两轮同一款游戏或连续两晚使用了同一个外卖应用。我们会直觉上认为用户连续两“天”打开了应用;其中,“天”是指特定于该用户的位置与时区的自然日。

那么这时问题出现了。

如果您的所有用户是在单个时区内生活、工作和活动,上述定义实现起来就简单。然而现实世界并非如此。用户遍布全球各地,时区成了程序员不得不面对的棘手问题。面对这个难题,开发者也只能接受用户会在不同时区穿梭的事实。

这也意味着,要想确定您各个用户的自然日是否已变为第二天,是否能视为“Day 1”留存,在实际操作上是件非常困难的事。

这也是目前没有 MMP (Mobile Measurement Partner, 中译:移动监测伙伴)或移动数据分析供应商使用此定义的原因所在。它操作起来实在是太复杂了。

但是,如果“天”的含义并非您认为的那样,那么,您的归因供应商又是如何定义它呢?

“天”的不同定义

要解决这个问题,最简单的方法是使用集中式时钟,创建通用的“标准日”。

此方法是数据分析供应商最常用的方法,也就是使用协调时间时 (UTC) 作为时区,他们将该时区用作“天”的全局定义。此方法很容易实现,仅需让服务器知道用户打开应用时处于 UTC 时区的哪一天。

那么,此定义和我们之前探讨的直觉假设有何不同呢?

如果是欧洲用户,UTC 日和实际自然日之间的时差就只有几个小时。根据夏令时和国家/地区的不同,我们与他们的时差很少超过 ±2 小时。

但是世界其他国家/地区又如何呢?

在纽约,实际的一天比全局 UTC 日晚 4 到 5 个小时,这种情况不算太好,也不算太糟。幸运的是,在这个时间段,人们通常都处于睡眠之中。

然而,旧金山比我们的 UTC 日晚了 7 或 8 个小时。这意味着,如果用户在当地时间下午 5 点之前打开一个应用,随后再次打开(即使是在同一小时内),他们也将被视为在 Day 1 留存。显然,这与我们所认为的留存不同。

另一方面,中国比 UTC 日早 8 个小时,我们的“午夜”是中国当地的上午 8 点。如果用户在当地时间上午打开应用,随后在午餐时再次开启,则将被视为留存。

显而易见地,这个定义存在严重的问题。在此示例中并没有如实反映“Day 1 的留存率”。尽管我们仍然可以根据同一时区内的留存率来比较推广活动的表现,但使用此定义进行全球对比恐怕会造成许多错误。

但是,问题还不止如此。

为了提供定制化服务,许多监测公司允许客户选择不同于 UTC 的时区来定义其同期群“全局日 (global day)”。

其想法是,客户可以选定一天,以尽可能贴近真实情况的方式对用户群的“实际天数”做划分。

但是,在转变为 Adjust 的客户的示例中,这样做会导致 KPI 严重失真。

设想一家总部位于中国的公司,其大部分用户都在北美。他们的全局日为北京时间。在这个情况下,“午夜”被很突兀地定义为纽约的中午 12 点和旧金山的上午 9 点。

通过这样人为的手段将应用最活跃的使用时间划分为不同的两天,我们从而获得了极高的留存率。在午餐休息时间玩两轮游戏(间隔几分钟)的用户将被视为“留存”。

我们要很明确地表示,这种计算留存率的方法不仅是错误的,而且很危险。提供这种方法的 MMP,如果没有向客户妥当地解释其缺点和潜在的数据问题,就可能误导广告主为实际上价值不高的用户投注过多预算资金。

应运而生

在过去的几年里,我们一直在研究解决这个问题的方法。

我们没有采取通过更改日历上的日期来定义“天”,而是将“天”定义为“24小时”。

通过这种方式,我们可以比较用户打开应用的两个时间戳,并确定它们之间是否已超过 24 小时。

因此,无论用户位于哪个时区或者处于什么样的当地时间,只有该用户 24 小时后再次打开应用才能被视为“Day 1 留存”。

所有用户都遵循相同的定义,避免极端情况出现,从而产生具有评估价值及意义的 KPI。

这很简单,对吧?

不得不面对的问题

对于从其他 MMP 转换过来的客户,要适应这种方法,一开始可能比较棘手。上述客户可能会发现,他们 Day 1 的留存率从 50% 下跌为约 25%。

这个道理说得通。因为按照日历逻辑,大约有一半在 Day 1 留存的用户,在安装应用 24 小时后其实没有返回该应用。尽管如此,没有人愿意看到数据下跌。客户这样的担忧情有可原。

尽管如此,我们的当务之急并非ㄧ味追求数据上的美观,而是结合分析和营销,从而实现整体应用生态系统成功和健康的共同目标。这种原理和我们的防作弊套件非常相似,在使用防作弊套件检测出虚假安装后,您的安装量会下降。同样,采用我们的同期群方法可能会导致 Day 1 的留存率下降。但这并非是一件坏事,它其实提供了更客观、更可操作的统计数据。只是如果 UA 经理的奖金取决于人为夸大的留存率,那么接下来的情况可能会有点小尴尬了。

总而言之,明智的广告主需要作出最好的决策。理解每个 KPI 背后的逻辑(例如,时区和地理因素等因素)能帮助您做出更有价值的决定。

数据好看固然不错,但数据准确性更为重要,这也是我们采用这个留存率计算方法的原因所在。

Want to get the latest from Adjust?