转载

推倒网站跟踪的时代已经到来

　　英文原文：The Web-Tracking Tipping Point

　　编者按：贾斯汀·克劳斯（Justin Krause）是 Asana 的商业智能和网页开发团队的负责人。

　　我们正在见证互联网发展中的一个分水岭——在苹果推出内容拦截器后，我们看待和理解我们网上的用户的方式将发生深刻的改变。

　　这看上去并没有多么重要。虽然广告拦截器在桌面浏览器上存在了很多年，但类似谷歌分析的产品仍然成为了测量和监测网站的行业标准。但这些都即将改变——个人产品和分类将因为移动版 Safari 上的一个小小的技术转变而受到很大影响，有自己的网站的机构也将必须适应这一转变，否则就会在竞争中处于劣势。

　　为什么改变会在现在发生呢？简单地说，这是因为网站跟踪的遗留系统已经无法工作了。由于现有的广告拦截器，它已经不能准确地捕捉用户在网站上的活动了，移动端内容拦截器的加入会进一步影响它收集到的数据的准确性。它无法在单页面网站应用程序上工作，是因为它是基于页面加载而构建的。出于相同的原因，它更无法捕捉移动应用上的活动，因为移动应用中 90% 的动作都不是页面加载，而且移动应用的多堆栈数据通常集成化较低。不过，遗留系统最大的缺陷是把数据藏起来，即把关于你的客户的关键数据放在一个无法访问的地方，只有使用费用高昂且脆弱的 API 集成才能集成数据及进行自动操作。

　　移动内容拦截器是对遗留系统的致命一击。相比桌面广告拦截器，它对用户更有吸引力——节省网络带宽和更快的页面加载对移动端非常重要。防止收集隐私信息只不过是一个附带的功能。当用智能手机使用互联网的趋势已经无法阻挡时，如果很难收集 iOS 用户的信息——这些用户在网上花的钱和时间最多，将影响数据的准确性，让数据变得不可靠。

　　这些变化不是一蹴而就的。但是，安卓也会步 iOS 的后尘，采用类似的技术，而且，当用户熟悉这种技术后，他们将更有可能使用桌面拦截器。甚至连浏览器也有可能内置这种技术。

　　受影响的 不只是发布者

　　这种技术将深刻影响数字广告和归因，进而会影响发布者和其他依靠广告盈利的公司。但这仅仅是开始。

　　让我们检查一下任何电商或 B2B 网站，看看它们所有的 cookie 和请求（通常是通过谷歌跟踪代码管理器发出的）。这些网站（以及各种跟踪代码管理器），连同所有与它们合作的创意机构和市场营销人员，将受到巨大影响。而那些在这种平台上进行销售的公司将受到更大的影响——那么，电商公司将如何可靠地重新定位用户呢？

　　在移动端减少网络带宽占用以及清理大量繁琐的东西是值得追求的目标。

　　想触及那些最精通科技的用户将变得更加困难；对广告网络的逆向选择实际上会越来越频繁。衰落的归因模式将降低对投资回报率的信心，让广告项目——甚至是任何营销项目都更难有把握地进行量化，也更缺乏具体的合理性。

　　除数字广告和归因之外，Optimizely 之类的前端的网站测试框架也将受到影响，这是因为 Optimizely 是加载测试偏差和以异步方式发送数据的 JavaScript 片段。如果你的 A/B 测试只考虑了较少使用移动端、不那么精通科技的人群，结果会怎样？测试结果仍然有效、可操作吗？

　　从最基本的层面看，理解网上的用户行为将变得更加困难。试图将谷歌分析中的数据与内部系统中的数据相结合的分析人员已经知道两者间几乎总存在明显的分歧，而第三方系统扣留的数据越多，分歧就越严重。没有合适的数据对很多产品和营销团队来说就像双目失明一样——他们不知道在他们的用户那里究竟发生了什么，也无法对其采取明智的应对措施。

　　接下来该怎么做？负担将会转移

　　网站追踪的未来很好理解，但要承认它却很难；我们不能再依赖第三方 cookie 和 JavaScript 片段了。负担从用户的浏览器上转移回了我们自己的网站服务器上，而且这个转移会让网站的堆栈变得更复杂。但是，这个转移中却暗含着一个绝佳的机会，能让我们统一我们的数据，改进我们理解用户的方式；那些最有远见的团队将从转移的努力中收获成果。

　　新的内容拦截器将时常阻止用户的浏览器向谷歌或 Optimizely 发送请求，但不可能阻止发送给来源的请求（正如我们所知道的，如果阻止，则会破坏任何类似 AJAX 的东西，并会破坏网页）。因此，合理的解决方案是，依赖向第三方域名发送异步请求的解决方案应该发布服务端库。你将把 PHP 或 Ruby 库连同你的 JavaScript 片段一起粘贴到你的服务器上；JavaScript 会把请求发回你自己的服务器上，然后你的服务器会以 REST 形式与这些第三方服务进行通信。

　　就像移动应用的生态系统产生了更多工作量以及混乱和变化一样，网站分析上的转变不会那么容易。

　　但这么做有一些根本性的问题。第一，只有精通技术的开发者能有把握地调整服务器端代码。对大多数网站管理者而言，他们会依赖他们的主机或 WordPress 插件来替他们完成这项工作。最终，在部署这些解决方案时，这将产生更多的冲突和延迟，降低它们的吸引力。精通技术的开发者会产生这样的疑问：“如果我已经在部署客户端和服务端的代码，为什么还要使用第三方系统？”开源的分析解决方案将得到推动，而且更多机构将选择把更多分析和信息工作交给其内部完成。

　　另一个问题是可扩展性。现在大部分的网页属性都被优化为提供页面，而不是处理分析数据流。新的服务端解决方案必须简单、可靠、有内聚力。如果我们不考虑性能就增加大量请求和像素，就像现在的情况一样，那么我们最终将冲垮我们自己的服务器，增加成本和潜在的延迟。成功的解决方案会把前端数据与服务端处理器在一个单一、精心设计的管道上结合起来，然后把数据从服务器导出到数据仓库（和第三方服务）中，可以是批量导出。

　　在这种转变中，很多机构将不会采取行动，并将依靠越来越糟糕的有缺陷的数据。数据是无济于事的，而偏见会导致糟糕的信息和决策。对开发人员、分析人员和营销人员来说，这将是一段混乱的时期，而复杂的团队中则可能产生分歧，出现一部分人采用新工具、另一部分人依然固守旧工具的情况。

　　是时候进行革新了

　　虽然混乱，但如果能超越内容拦截的问题，解决与网站追踪有关的更深层次的问题——把前端数据与多堆栈内部数据相结合，不以页面加载为中心、而是以网页和应用上的事件和会话衡量网站使用体验，并为更多机构实现第一方、特有的数据，那么这一转变将开启重要的市场机遇，将现有的参与者重新洗牌。

　　公司在营销和产品上的投资需要行之有效的解决方案，新工具将演化以填补这一空白——而且，由于新工具越来越复杂，具有深层次测量的专业技能的新开发人员和分析人员将涌现出来，并会非常吃香。

　　理想的解决方案是什么样的？鉴于前端和和后端的堆栈都多种多样，系统需要变得非常灵活。对于情况如何发展，第三方错误追踪指出了一个令人兴奋的方向。Bugsnag 之类的服务几乎每种语言都有库，这些库能在服务器层运行，并能以 REST 方式与流数据就错误和异常进行交互。分析也可以以同样的方式进行。

　　不过，希望机构能利用这一机遇收回他们对其数据的所有权，并且开源工具能得到推动，帮助流数据进入像 Redshift 这样的第一方数据仓库，与内部数据结合，被更灵活地使用。整个社区应该联合起来，为 Web 2.0 应用程序规定一种合理的通用模式。Looker 之类的第三方 BI 服务应该建立在这种专有数据之上，而不是像谷歌分析现在所做的那样把这些数据藏在无法访问的地方。

　　如果这些都能实现，我们就是用一个简单但残缺的网站分析系统换来了一个能够带来更深刻的洞见的更加丰富、更加复杂的系统。这需要大量的投资和更多的专业技能，但回报将是更好的信息，以及最终更好的产品、更好的用户体验和更出色的商业成果。

　　最终， 这将对用户 非常有益

　　与某些人声称的内容拦截器是苹果促使更多人使用本地新闻阅读器的秘密诡计正相反，这一改变至少是对用户非常有益的。在移动端减少网络带宽占用以及清理大量繁琐的东西是值得追求的目标。如上所述，这些带宽中的一部分无疑将被转移到来源上，但总体而言，Safari 移动用户的体验应该会更好（而且最终当我们把整个互联网都清理干净后，其他所有用户的体验都会更好）。

　　有自己的网站的机构将必须适应这一转变，否则就会在竞争中处于劣势。

　　这一改变还有隐私上的考虑——移除第三方 cookie 将能减少那些与我们已经从购物车里删除的商品有关、在网上到哪都能见到的令人尴尬的广告。但总体而言，对网上隐私的影响可能有限，因为这些公司有别的方法分享数据——其中最重要的就是仅通过分享邮件列表分享数据。通过定制受众定位，Facebook 已经使这一方法成了主流。通用 ID 和 IP 和解将被更广泛地使用，对营销人员和内容平台将变得更为重要。

　　这对互联网也非常有益

　　通过使我们转换为使用移动端、移动应用，以及从 Safari 开始对我们如何测量、跟踪、定位的现状发起挑战，苹果迫使我们对互联网进行反思。就像移动应用的生态系统产生了更多工作量以及混乱和变化一样，网站分析上的转变不会那么容易。但它也会产生大量的机会和新的赢家。它会为在这个生态系统中更好、更灵活地分析和理解用户和产品的机制敞开大门。它将促使我们变得更好——更集成、意图更清晰、更睿智。

　　是时候了。

　　题图来自：JAMBRO/SHUTTERSTOCK

正文到此结束