Google Analytics（分析）入门：App + Web

谷歌最近在公众访问中发布了新版本的Google Analytics（分析），称为App + Web 。 Simo Ahab已经就如何开始使用该工具编写了出色的分步说明，因此我决定将其翻译成俄语。 我将自己补充说，该产品刚刚在Beta版中出现，而且显然仍将完成。 我们已经开始测试Google BigQuery中的新数据结构和内置数据导出功能的功能，并希望很快就更多地讨论其优缺点。 总体而言，今天的分析师对创新给予了积极的评价。 例如，OWOX BI的Vlad Flax认为，通过此更新，对于准备更改其数据结构的项目，Google简化了收集数据并将其从Google Analytics（分析）传送到BigQuery的过程。 此外，它还可以作为DWH（用于营销数据）为Google BigQuery增值。

以下是Simo文章的译文，包括其使用评级和使用印象。

尽管标题笨拙，但它确实是实现Google Analytics（分析）V2或Firebase Web的所有目标的绝佳工具。 在这里，我们不是在谈论在Firebase的Google Analytics（分析）和Universal Analytics之间创建摘要报告的迷人方法，也不是在改进Universal Analytics。

不，我们正在谈论一种新的网络流量测量模型，该模型可与Google Analytics for Firebase很好地配合使用。

这仍然是一个略微粗糙的产品，并且文档仍然缺少，所以我认为我将给您带来优势，并展示如何使用Google跟踪代码管理器来设置数据收集。 我打算在功能退出Beta测试后立即发布完整，适当，全面的指南。 但是，本文应该为那些已经渴望立即尝试其所有新功能和有趣功能的人们提供帮助。

Google Analytics（分析）：App + Web的名称有点尴尬。 在我看来，这只是时间问题，我们什么时候将其称为Web的Firebase或类似的东西，因为这本质上就是这样。 在本文中，我将在不愿意输入完整名称的地方将其称为GAv2（是的，我很懒。）



开始之前，请在新标签页中打开Krista Seyden的精彩博客 ，并特别注意她发表的有关Google Analytics（分析）报告功能的三篇文章：App + Web。

1. Google Analytics（分析）中的新应用+网络媒体资源
2. Google Analytics中的路径
3. Google Analytics（分析）中的Streamview 。

更新：在我发布本文后，Krista立刻发布了另一本出色的指南，而且很棒的是它对此进行了补充，因为它更详细地介绍了创建Firebase项目的步骤。 通常，请检查以下内容： App + Web的逐步设置 。

我将从几个开场白开始，因此，如果您愿意，只需跳过它们，直接进入实现步骤。

警告事项

首先，Google Analytics（分析）：App + Web处于beta测试中。 这意味着它尚未完全准备就绪。 严重的是，它还没有准备好。 毫无疑问，我现在正在脑海中思考的许多事情都会落到平台上，以及您将遇到的许多问题的答案，很可能会在将来的版本中给出。

以下是我在报告用户界面和Google跟踪代码管理器的设置中发现的几点：

• 没有专门的报告，例如“网站搜索报告”或“电子商务”
• 无法在用户报告用户界面中区分自动收集，推荐和自定义事件。
• 您可以配置用户资源，请参见下面的操作方法。
• 使用GTM时，无法在Google Analytics（分析）中将数组（或任何其他多维对象）作为事件参数发送给项目。
• 在GTM的配置标签中设置常量值似乎是不可能的。
• 您可以根据此支持文档升级现有的Firebase Analytics资源。 当您在Google Analytics（分析）中打开资源（前提是您已在Google Analytics（分析）中链接了该资源）时，您会在屏幕顶部看到一个蓝色横幅，提示您进行更新。

请确保关注官方博客以及Krista的博客 ，因为它们将成为您获取更多信息的魔杖，包括有关本章列出的问题的信息。



最后，显而易见的一点。 这不是Universal Analytics 。 您过去在Universal Analytics中经常看到的许多东西都不在Firebase中。 就我个人而言，我希望功能的同等化指日可待，因为现在Google有机会创建新的更好的东西。 但是，当然，我们所有人都希望该平台在某个时候替代Universal Analytics，因此，至少在相同的用例中，它应该很有用。

我认为，此处是Universal Analytics与新平台之间的主要区别。

通用分析：
一切都围绕会话的概念构建
针对点击，会话和用户范围的自定义定义。
实时地面报告。
段。
没有语义结构。
非常有利的配额和限制（样本除外）。

Google Analytics V2：
一切都围绕“用户”和“事件”的概念构建
自定义属性和自定义事件参数
StreamView和DebugView提供了更深入的细节。
听众
自动收集和推荐事件。
严格的配额和限制 （不抽样）。

与Universal Analytics所做的相比，限制尤其令人痛苦。

无论如何，我确信这些问题会在Google Analytics（分析）之前得到解决：App + Web经过Beta测试，但可以肯定的是： 这不是Universal Analytics 。 尝试将新的衡量模型视为超越通用Analytics（分析）所能提供的机会，而不仅仅是填充古老的GA数据模型的一种方法。

由于这些警告， 我强烈建议您停止在Universal Analytics中收集数据，而仅在Google Analytics（分析）App + Web中收集数据 。 无论如何，最好与站点上已有的任何设置并行运行此新的度量模型，以便您可以比较两个数据集之间的奇偶校验。

创建新的Analytics（分析）设置：App + Web

要创建新的Google Analytics（分析）媒体资源：App + Web，您需要执行以下操作：

注意！ 根据已发布的文档，将来可能会大大简化这些步骤。

步骤1：建立新的Firebase专案

转到Firebase控制台并创建一个新项目。 这将是您新设置的基础Firebase项目。



给项目起一个名称和ID（ID必须是唯一的，它将基于项目的名称生成）。

阅读并接受Firebase条款，然后单击“继续”。



在下一步中，确保选中“为我的项目设置Google Analytics（分析）”复选框，然后单击“继续”。



现在，根据您是否已经拥有Google帐户，您可以选择在哪个帐户中创建资源或整体上创建一个新帐户。 如果您没有与您的登录信息相关联的Google Analytics（分析）帐户，则需要接受GA服务条款，然后将为您创建一个新帐户和资源。



单击创建项目并完成处理后，可以转到Google Analytics（分析）并在所选帐户中找到新的App + Web资源。

步骤2.创建一个新的Web流

新的度量模型围绕着来自您的应用程序（iOS和Android）或Internet的流。 我希望将来我们会看到新的流，例如“测量协议”，它将接受来自连接到Internet的任何设备的HTTP请求。

无论哪种情况，请在资源列中选择“ 数据流”选项，然后选择“ Web” 。



要配置流，请输入站点的URL并为流指定一个描述性名称。 然后单击小齿轮以设置增强测量。



增强测量基本上向站点添加了一些自动跟踪功能，这些功能在创建基本配置标签后便会激活。



可以自动跟踪的事物列表非常清晰，并且在“增强测量”配置中得到了很好的解释（请参见上面的屏幕截图）。

准备就绪后，创建一个数据流，您将在屏幕上看到一堆标记说明和其他要点。 要注意的最重要的事情是度量ID。 保持此标签为打开状态，以便您可以在必要时将维度ID复制到Google跟踪代码管理器代码中。



完成了吗 好的，现在让我们进入Google跟踪代码管理器。

创建一个基本配置标签

在Google跟踪代码管理器中，当您创建新代码时，您会在选择器中看到两个新的代码模板。



Google Analytics（分析）：“应用程序+ Web配置”类似于gtag.js实施中使用的 config 命令 。 您可以使用它来配置跟踪器，发送初始网页浏览量以及为所有事件设置常量值。

当您打开模板时，您当然不会受到很多选择的欢迎。 实际上，您有一个用于确定测量ID的字段，一个用于选择是否发送初始综合浏览量的开关以及可以在标记中设置的配置字段 。



要配置基本标记，请在上一部分中创建的Web流的“测量ID”字段中指定它。 如果要为设备和应用程序之间的测量铺平道路，可以在与用户身份验证ID关联的user_id字段中设置一个值。

根据文档 ，如果希望在使用相同维度ID的每个后续调用中发送这些事件参数，则应该能够在要配置标记集的字段中定义任何事件参数。 不幸的是，在撰写本文时，这似乎不起作用。

设置自定义属性

要设置用户属性，您必须首先在报告用户界面中创建它们 。



接下来，转到配置中要设置的字段并添加一个新字段。 字段名称必须为user_properties 。



您必须使用自定义JavaScript变量（或自定义变量模板）作为字段值，该字段值将返回一个对象，该对象的每个键都对应于您在报告UI中创建的用户属性名称，并且该值与您要作为自定义属性发送的名称相同问题。

例如，要设置user_type属性（请参见上面的屏幕截图），我可以创建一个如下所示的Custom JavaScript变量：

 "function() { return { user_type: 'Premium user' }; }" 

然后，您需要将此变量添加为配置标记中user_properties字段的值。

另一种方法是使用自定义变量模板（如果您不记得什么用户模板，请参阅我的指南 ）。 这是我创建的用于返回用户属性对象的模板 。 您可以使用它来创建一个变量，在其中设置各个键和用户属性值，然后将此变量设置为配置标记中user_properties键的值。



创建配置标签后，请使用“所有页面”开关启用它，然后进入预览模式。 让我们看看这个新的测量模型如何在网站上工作！

测试！

当您访问该网站并下载预览容器时，请打开浏览器的开发人员工具，并查看GAv2使用的Cookie。



cookie _ga与Universal Analytics几乎相同，只有一点点差异。 _ga cookie将cookie值中域的部分编码为GA1之后的数字。 例如，如果将cookie写入simoahava.com，则该域由两部分组成，并且cookie前缀为GA1.2。

但是，对于GAv2，这与使用默认cookie_domain值（自动配置）不同。
我认为这可能是一个遗漏，就像您手动设置域一样，例如www.simoahava.com ，该cookie具有通常的GA1.3。 前缀。

另一个cookie, _ga_MEASUREMENT-ID **似乎支持会话状态。 第一个长数字是创建Cookie时的时间戳（以秒为单位），第二个长数字是最后一次匹配发送至GA时的时间戳。

换句话说，似乎GAv2至少跟踪会话当前是否处于活动状态。 是否会在更大程度上使用客户端持久性作为会话信息，以及该cookie是否可用于确定Web浏览器中的会话状态，还有待观察。

JavaScript用于cookie，因此会受到诸如Safari的Intelligent Tracking Prevention等降低客户端cookie性能的措施的影响。

然后，按照浏览器发送的Web请求进行操作，或使用Google Analytics（分析）调试器扩展程序查看该库如何将匹配发送到Google Analytics（分析）。



首先，您可以看到请求已发送到熟悉的端点/collect ，只是请求位于/ g /路径上。

请求类型为POST，端点仍为图像像素。 换句话说，该点击似乎默认情况下使用Beacon API，这对于Universal Analytics（对于您必须手动启用此功能）来说是一个很大的改进。

Beacon API保护在页面卸载时发送的异步请求，即使关闭浏览器也可以执行这些请求。 这避免了跳过呼叫的麻烦（例如，与单击链接相关的事件），因为用户在请求完成之前就离开了页面。



如果您查看发送给GA的实际参数，如果您记得如何构建测量协议请求，这里有很多熟悉的内容。
参数v的值为2，而在Universal Analytics中的值为1。这是协议版本。
tid参数设置为您的尺寸ID。
gtm参数gtm从GTM容器的ID中散列的。
cid参数是存储在cookie _ga的客户端标识符。

其他选项实际上保持不变，包括uid （用户ID），dl / dr / dt（文档元数据）和sr （屏幕分辨率）。

不再有“匹配类型”维度，而是使用en（事件名称）参数来区分不同类型的匹配。 这是与Universal Analytics的主要区别，因为在GAv2中，您只有一个事件流，由您发送的事件参数以及事件名称决定了数据在报告中的显示方式。

事件参数以ep为前缀。 或epn。 分别用于文本参数和数字参数。 在屏幕截图中，我创建了一个名为country的事件参数并将其设置为US。

用户属性以up为前缀。 或upn。 用于文本或数字格式的自定义属性。 屏幕快照显示了名为user_type的用户的一个文本属性，该属性设置为Premium user。
最后，sid参数似乎包含当前会话开始时的时间戳（取自cookie _ga_MEASUREMENT-ID ）。

尚不清楚其他选择在做什么。

您可能会注意到的一件事是发送匹配数据的延迟。 加载页面后，您可以看到浏览器如何等待几秒钟，然后才能将匹配结果发送到GA。 这是因为GAv2自动对请求进行了分组，这又是一项很棒的功能更新。

通过将多个匹配项捆绑到一个请求中，可以将浏览器资源用于其他目的。 延迟的原因是浏览器正在等待其他匹配与网页浏览一起发送。

在创建第一个事件标签之前，请查看增强测量的工作方式。 首先，向下滚动到当前页面的末尾，然后查看发送到Google Analytics（分析）的事件。



然后单击从您的站点引出的链接（使用CTRL / CMD +单击以在新选项卡中将其打开）。 看一下选项。



最后，如果YouTube以enablejsapi = 1嵌入到您的网站中，请检查自动视频跟踪！



一切都非常酷，但是我希望我们能有更多控件来调整增强测量。

现在，让我们创建我们自己的事件代码！

创建一个事件标签

功能类似于使用gtag.js和Firebase事件。

换句话说，是自动收集的事件，推荐的事件和用户事件的组合。

创建新事件时，首先请确保该事件尚未自动收集。

然后检查是否存在可用于代替自定义事件的建议事件结构。 如果找到适当的建议事件，请在设置事件标签时确保使用建议的事件名称和参数。

现在，如果您愿意，仍可以发送带有完全任意事件参数的完全配置的事件名称。 只需记住，您将在报告用户界面中失去一些灵活性，因为您可以在用户界面中为报告定义的自定义属性的数量受到严格限制。

让我们从一个简单的自定义事件开始 。

创建一个新的Google Analytics（分析）：应用程序+网络事件提示，并按如下所示进行填充：



将配置标签设置为上一部分中创建的值。 这与Google Analytics（分析）设置变量的工作方式类似，因为您只需配置一次跟踪器设置，然后便会将其应用于所有使用配置标签的标签。

给事件指定一个任意名称（即不是自动收集或推荐的事件之一）。 在这种情况下，我们使用data_loaded作为事件的名称。

然后添加一些参数：

• all_data是设置为true的自定义文本参数。
• debug_mode是一个参数，当安装在标记中时，该参数会在DebugView UI报告流中显示匹配项（有关此内容，请参见下文）。

选中该框以启动“加载窗口”单选按钮，刷新预览模式并将容器上载到网站。 查看网络请求/collect 。

加载页面后，您应该看到一个将两个匹配组合为一个的请求（批处理模式）。



如您所见，在第一行中有一个hit page_view ，在第二行中是用户事件data_loaded 。

现在转到Google Analytics（分析）报告用户界面，然后在报告导航器中选择DebugView。

请务必阅读Krista出色的流媒体报告文章，以了解如何解释以下数据。 您也可以阅读Firebase DebugView自己的文档以了解更多信息。

在屏幕顶部的“调试设备”选择器中，您可以查看当前有多少设备（例如浏览器实例）正在向GA发送调试匹配。 使用选择器滚动列出的设备，直到找到最近发送了data_loaded事件的设备。

该调试设备选择器当前不可用。 希望在不久的将来，将更容易找到调试设备。

找到data_loaded事件后，您可以看到DebugView中包含的其他匹配项。 这是因为，如果包中包含除data_loaded命中以外的data_loaded命中，它们还将自动在DebugView中列出。



您可以单击data_loaded事件中的参数，以查看通过点击发送到Google Analytics（分析）的信息类型。

在完成之前，我们也尝试发送推荐事件 。 我们将发送搜索事件以模拟站点搜索。

如果阅读推荐事件列表中的指示信息，您将看到搜索事件的名称为search，它search_term一个参数： search_term 。 因此，让我们创建一个新的事件标签并填写这些值！ 标签的外观如下：



如您所见，我只是在事件参数中对搜索词进行了硬编码。 我正在运行一个标签，该标签的“ 自定义事件触发器”设置为一个名为search的事件。

更新预览模式并重新加载网站后，我可以使用在页面的JavaScript控制台中运行的简单window.dataLayer.push ({event: 'search'})触发事件。

在DebugView中，我看到事件已记录：



而且...仅此而已。 没有什么可以区分此事件与用户事件。 没有与Universal Analytics类似的与网站搜索数据匹配的报告。 在某些时候，我确定某些搜索事件将记录在自己的报告中，在该报告中，搜索数据将与自动收集的事件view_search_results （记录有与该站点上的搜索相对应的查询参数的页面视图）结合在一起。

总结

在本文中，我想向您展示如何设置新的Google Analytics（分析）资源：使用Google跟踪代码管理器作为选定的实施工具时，App + Web。

希望我已明确表示该功能仍处于beta测试中，因此有意未完成。 随着时间的推移，将引入新功能，直到将来我们以功能齐全的平台退出beta版。

该平台是否打算取代Universal Analytics？ 仍然未知。 但是，当您不得不忍受新的出色的度量模型时，从概念上讲很难证明Universal Analytics服务或功能的未来版本是合理的。

我很高兴在Internet上谨慎介绍 Firebase。 自从很久以前开始使用Firebase（和Firebase Analytics）以来，这就是我一直期待的。 我认为用户和事件衡量模型优于Google Analytics（分析）使用的高度聚合和会话模型。

但是，为了理解Google Analytics（分析）：App + Web所考虑的用例与Universal Analytics的用例之间的可比性，我们需要在精神上进行多少上下文切换还有待观察。

我肯定会分配更多的资源来为Firebase编写内容，因为这种在应用程序和网站之间结合分析的新方法太有趣了，不能忽略。

让我们在评论中讨论Google Analytics（分析）：App + Web，但请记住，我们所谈论的是beta产品。 您可以随意表达对开发决策和缺少功能的失望，但是请记住，以建设性的方式提出批评可能会导致旨在消除最终产品中这些批评的变化，因为Beta版本的目的是来自社区的反馈。