如何解决Google Fit 估计某些用户通过 REST API 的步骤会减少
我们在拥有数千名用户的过程中使用 Googlefit REST API 来获取每日步数。对于大多数用户来说,流程是可以的,尽管我们发现一些用户具有这种特定行为:用户在白天步数增加,但在某些时候,他们会显着减少。
我们主要在华为健康应用(以及一些小米健康应用)上发现了一些与此相关的问题。
我们使用这个 dataSourceId 来获取每日步数:derived:com.google.step_count.delta:com.google.android.gms:estimated_steps
我们请求获取 3 月 15 日(西班牙时报)数据的示例之一:
POST https://www.googleapis.com/fitness/v1/users/me/dataSources
Accept: application/json
Content-Type: application/json;encoding=utf-8
Authorization: Bearer XXXXXXX
{
"aggregateBy": [{
"dataTypeName": "com.google.step_count.delta","dataSourceId": "derived:com.google.step_count.delta:com.google.android.gms:estimated_steps"
}],"bucketByTime": { "durationMillis": 86400000 },"startTimeMillis": 1615244400000,"endTimeMillis": 1615330800000
}
对于大多数用户来说,这很顺利(它获取与 googlefit 应用程序中显示给用户的数据相同的数据),但对于某些用户,如所述,白天的数字首先会增加,然后会减少。一些用户在 googlefit 应用中的数据比通过 REST API 找到的数据多得多(或显着多)。
我们甚至在白天与特定用户进行了跟踪。使用 'durationMillis': 3600000 的桶,我们绘制了一天中每小时步数的直方图(使用定制流程)。
对于同一天,在不同的时间点(在这种情况下有几个小时的差异),我们为完全相同的用户获取此信息:
20210315-07 | ########################################################## | 1568
20210315-08 | ############################################################ | 1628
20210315-09 | ########################################################## | 1574
20210315-10 | ####################### | 636
20210315-11 | ################################################### | 1383
20210315-12 | ###################################################### | 1477
20210315-13 | ############################################### | 1284
20210315-14 | #################### | 552
对比这个,在几个小时后被检索到:
20210315-08 | ################# | 430
20210315-09 | ######### | 229
20210315-10 | ################# | 410
20210315-11 | ###################################################### | 1337
20210315-12 | ############################################################ | 1477
20210315-13 | #################################################### | 1284
20210315-14 | ###################### | 552
(“20210315-14”表示 2021 年 3 月 15 日的 14 点)
这是第一种情况下返回的 JSON:
[{"startTimeNanos":"1615763400000000000","endTimeNanos":"1615763460000000000","dataTypeName":"com.google.step_count.delta","originDataSourceId":"raw:com.google.step_count.delta:com.huawei.health:","value":[{"intVal":6,"mapVal":[]}]},{"startTimeNanos":"1615788060000000000","endTimeNanos":"1615791600000000000","value":[{"intVal":1568,{"startTimeNanos":"1615791600000000000","endTimeNanos":"1615795080000000000","value":[{"intVal":1628,{"startTimeNanos":"1615795200000000000","endTimeNanos":"1615798500000000000","value":[{"intVal":1574,{"startTimeNanos":"1615798860000000000","endTimeNanos":"1615802400000000000","value":[{"intVal":636,{"startTimeNanos":"1615802400000000000","endTimeNanos":"1615806000000000000","value":[{"intVal":1383,{"startTimeNanos":"1615806000000000000","endTimeNanos":"1615809480000000000","value":[{"intVal":1477,{"startTimeNanos":"1615809660000000000","endTimeNanos":"1615813200000000000","value":[{"intVal":1284,{"startTimeNanos":"1615813380000000000","endTimeNanos":"1615815420000000000","value":[{"intVal":552,"mapVal":[]}]}]
这是后一种情况下返回的 JSON:
[{"startTimeNanos":"1615788300000000000","value":[{"intVal":517,"endTimeNanos":"1615794540000000000","value":[{"intVal":430,{"startTimeNanos":"1615796400000000000","endTimeNanos":"1615798200000000000","value":[{"intVal":229,{"startTimeNanos":"1615798980000000000","value":[{"intVal":410,"value":[{"intVal":1337,"mapVal":[]}]}]
如您所见,所有点始终来自 originDataSourceId:"raw:com.google.step_count.delta:com.huawei.health"
看起来 Googlefit 的一个过程正在做某种调整,删除一些步骤或数据点,尽管我们无法找到检测什么和为什么的方法,也无法向用户解释正在发生的事情或他或我们可以让他的应用程序数据与我们的完全一样(或相反)。他的 googlefit 应用程序显示的数字与 REST API 显示的数字不同。
用户已禁用“googlefit 应用跟踪活动”选项。
我很想知道,或者尝试获得一些提示:
谢谢和问候。
在 Andy Turner 提出问题后更新(感谢您的评论!)。
我们能够在几个小时内“抓住”这个:18.58(大约 6K 步)、21.58(大约 25K 步)、22.58(大约 17K 步)、23.58(大约 26K 步)。我们导出了这些数据集,这是结果。
另一个重要信息:数据仅来自“raw:com.google.step_count.delta:com.huawei.health”。我们查看了其他可能看起来可疑的数据集,所有数据集都是空的(除了派生数据等等)。
如果我们正确地理解这一点,可能是华为有时发送一个值,而下一次发送另一件事;所以可能是华为部分配置错误。
以下是导出的数据集: https://gist.github.com/jmarti-theinit/8d98996873a9c499a14899a9b62162f3
GIST 的结果是:
Length of 18.58 points 165
Length of 21.58 points 503
Length of 22.58 points 294
Length of 23.58 points 537
How many points in 21.58 that exist in 18.58 => 165
How many points in 22.58 that exist in 18.58 => 57
How many points in 22.58 that exist in 21.58 => 294
How many points in 23.58 that exist in 18.58 => 165
How many points in 23.58 that exist in 21.58 => 503
How many points in 23.58 that exist in 22.58 => 294
所以我们的赌注是由华为背后的设备删除和添加点(例如,18.58 - 22.58 中只有 57 是常见的),我们无法从 googlefit 方面控制更多。那是对的吗?我们还能看到什么?
解决方法
我们在使用 REST API 时遇到了类似的问题。
这与 Jordi 的情况相吻合:
- 我们也来自西班牙(还有我们的用户),尽管我们在西班牙和美国使用服务器
- 对于某些用户,我们获得与 google fit 应用相同的每日步数值,但对于其他用户则不然
- 当天每天的步数增加,但我们每隔一天发出请求,每天的步数有时会减少
- 我们从一天的开始到一天的结束发出相同的请求,使用 86400000 作为存储桶时间和相同的数据类型和数据源 id
我们正处于最后的开发阶段,所以我们只对少数用户进行测试。我们的用户有小米手环设备。
我们认为问题可能是我们正在访问的服务器不同步,因为如果我们使用 other apps like this one 进行测试,它们会显示正确的值。我们创建了另一个 google 云控制台 oauth 客户端凭据和新电子邮件帐户,以使用全新的用户和 oauth 客户端进行测试,但结果相同。
这是获取每日步数的推荐方式,我们使用的是完全相同的请求 https://developers.google.com/fit/scenarios/read-daily-step-total 即使使用文档中的“尝试”选项,结果也是错误的。
我们还能做些什么来帮助您解决问题? 非常感谢!
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。