Google Analytics iOS SDK“1 秒会话”（可能是后台会话？）
Google Analytics iOS SDK "1 second sessions" (possibly background sessions?)
Google Analytics（使用 iOS SDK 版本 3.14 并内置会话跟踪）报告很大一部分应用会话为 1 秒。
也许用户正在启动一个应用程序来查看页面，然后（有效地）立即 离开该应用程序，但这似乎不太可能（它应该继续作为最重要的用例。你认为这样的用户会停止使用或卸载。）
最初我怀疑这与 "background fetch" 有关，但当我查看应用程序的先前版本（没有启用或使用后台提取）时，我仍然看到这些（看似）虚假会话。该应用程序（iOS9 之前）没有通用链接。
我不想看到这些会话的（明显的）原因（特别是如果来自自动操作而不是用户操作）是它删除了 "user behavior" 的所有值；即忠诚度、新近度和偏差 "average session length"。这些是我想使用 GA 的主要原因，即看看人们是否更多地使用它 more/valuing。
我的问题：
- 这些会话可能是由什么引起的？他们是假的吗？
- 如果是假的，我该如何阻止他们？
- 我能否确保新的 "background fetch" 代码不会以某种方式触发它们？
我考虑过/调查过的一些事情：
- 我在 Android 应用程序（此应用程序的对等应用程序）上看到了类似的大量 "short sessions"，而且数量非常多。我一直想知道这是否是网络搜索和网站链接的结果，这些网站链接会自动加载应用程序，并且是一个（非常）快速的用户 "move on"。 （通用链接是新的 iOS 应用程序正在努力的方向，但还没有看到太多。）鉴于它不是 iOS 我开始怀疑它是 Android.
- GA 上有一个 "optOut" 选项。这感觉就像是解决这个核桃问题的大锤。这也是一个持久性设置，感觉在瞬态情况下使用是有风险的。我可以尝试在 applicationDidEnterBackground / applicationDidBecomeActive 切换它（如果它被认为是解决方案，我会这样做）但担心它可能会产生负面影响。
- 一个跟踪器可以有多个。我计划尝试一种用于人类前台 activity 和一种用于后台操作（这可能允许在后台进行时间/事件跟踪，w/o 影响人类用户跟踪数量。也就是说，我不知道/ 相信这是虚假会话的原因。)
- 可以手动管理会话并自定义会话间隔超时，但我不明白为什么此应用程序需要任何自定义行为。这是一个正常的应用程序。
- 应用程序报告的崩溃总数与这些数字不符；这是一个普遍受欢迎的 4/5 星应用程序，很少崩溃。
Google Analytics 将持续时间衡量为交互之间的时间。
这意味着为了能够衡量持续时间，GoogleAnalytics 至少需要衡量两个交互。但是他们仍然需要收集有关单次交互会话的数据，并且从报告的角度来看，每个会话都以相同的方式开始 - 进行一次交互。只是有些人没有更进一步。考虑到这一点，Google Analytics 保留 运行 总会话持续时间。
- 当用户第一次互动时，总数设置为 0。
- 31秒后，他们再次互动。该总数更新为 31 秒。
- 10秒后，他们第三次互动。总计现在是 41 秒。
- 35 秒后，他们退出了。这是不可测量的，因此不是交互作用。 Google Analytics 忠实地等待了 30 分钟，然后才决定他们不会回来。
您的总会话持续时间记录为 41 秒，因为那是您签到的最后时间点。无法知道您多停留了 35 秒。
如果您查看了 4 或 5 页，这不是问题，但如果您只查看了 1 页，我们将留下 0 的会话持续时间。这就是每个 'Bounce'；每个只有一次交互的会话的测量长度为“0”秒。
将 8 或 9 秒后互动的少数人加入其中，“0 - 10”类别的平均时间为 1 秒。
原来问题出在 Google Analytics SDK 中。已发布新版本：
[Google Analytics SDK issue with short sessions][1]
Google Analytics（使用 iOS SDK 版本 3.14 并内置会话跟踪）报告很大一部分应用会话为 1 秒。
也许用户正在启动一个应用程序来查看页面，然后（有效地）立即 离开该应用程序，但这似乎不太可能（它应该继续作为最重要的用例。你认为这样的用户会停止使用或卸载。）
最初我怀疑这与 "background fetch" 有关，但当我查看应用程序的先前版本（没有启用或使用后台提取）时，我仍然看到这些（看似）虚假会话。该应用程序（iOS9 之前）没有通用链接。
我不想看到这些会话的（明显的）原因（特别是如果来自自动操作而不是用户操作）是它删除了 "user behavior" 的所有值；即忠诚度、新近度和偏差 "average session length"。这些是我想使用 GA 的主要原因，即看看人们是否更多地使用它 more/valuing。
我的问题：
- 这些会话可能是由什么引起的？他们是假的吗？
- 如果是假的，我该如何阻止他们？
- 我能否确保新的 "background fetch" 代码不会以某种方式触发它们？
我考虑过/调查过的一些事情：
- 我在 Android 应用程序（此应用程序的对等应用程序）上看到了类似的大量 "short sessions"，而且数量非常多。我一直想知道这是否是网络搜索和网站链接的结果，这些网站链接会自动加载应用程序，并且是一个（非常）快速的用户 "move on"。 （通用链接是新的 iOS 应用程序正在努力的方向，但还没有看到太多。）鉴于它不是 iOS 我开始怀疑它是 Android.
- GA 上有一个 "optOut" 选项。这感觉就像是解决这个核桃问题的大锤。这也是一个持久性设置，感觉在瞬态情况下使用是有风险的。我可以尝试在 applicationDidEnterBackground / applicationDidBecomeActive 切换它（如果它被认为是解决方案，我会这样做）但担心它可能会产生负面影响。
- 一个跟踪器可以有多个。我计划尝试一种用于人类前台 activity 和一种用于后台操作（这可能允许在后台进行时间/事件跟踪，w/o 影响人类用户跟踪数量。也就是说，我不知道/ 相信这是虚假会话的原因。)
- 可以手动管理会话并自定义会话间隔超时，但我不明白为什么此应用程序需要任何自定义行为。这是一个正常的应用程序。
- 应用程序报告的崩溃总数与这些数字不符；这是一个普遍受欢迎的 4/5 星应用程序，很少崩溃。
Google Analytics 将持续时间衡量为交互之间的时间。
这意味着为了能够衡量持续时间，GoogleAnalytics 至少需要衡量两个交互。但是他们仍然需要收集有关单次交互会话的数据，并且从报告的角度来看，每个会话都以相同的方式开始 - 进行一次交互。只是有些人没有更进一步。考虑到这一点，Google Analytics 保留 运行 总会话持续时间。
- 当用户第一次互动时，总数设置为 0。
- 31秒后，他们再次互动。该总数更新为 31 秒。
- 10秒后，他们第三次互动。总计现在是 41 秒。
- 35 秒后，他们退出了。这是不可测量的，因此不是交互作用。 Google Analytics 忠实地等待了 30 分钟，然后才决定他们不会回来。
您的总会话持续时间记录为 41 秒，因为那是您签到的最后时间点。无法知道您多停留了 35 秒。
如果您查看了 4 或 5 页，这不是问题，但如果您只查看了 1 页，我们将留下 0 的会话持续时间。这就是每个 'Bounce'；每个只有一次交互的会话的测量长度为“0”秒。
将 8 或 9 秒后互动的少数人加入其中，“0 - 10”类别的平均时间为 1 秒。
原来问题出在 Google Analytics SDK 中。已发布新版本：
[Google Analytics SDK issue with short sessions][1]