工具二：Ghostery
Ghostery跟我上面讲的Miapex并不是一类工具，它的商业模式和功能不是分析工具，而是服务于监测实施。它属于我前面说的去技术化的工具。
Ghostery的功能很简单，他们自己是这样介绍的：
“当今的网站，没有几家不放几个第三方监测代码在其上做各种事情的。这些代码有的做监测，有的帮助做广告，有的做营销（例如实现retargetting），有的做widgets……，有些网站有放了超过十种甚至几十种别人的监测代码，这些代码偷偷记录我们的行为数据，而普通网站访问者根本无从得知。”
看看下面的梅西百货的网站，就用了十多种各种第三方监测。
“我们要改变这个状况，让你自己拥有决定哪些第三方监测可以‘监视’你，哪些不能‘监视’你的权力。”
“Ghostery”实际上是一个插件，用了它之后，你可以自己决定让网站中的哪些第三方监测生效，哪些失效。方法很简单，在Ghostery帮你列出来的所有第三方监测中，关闭你不喜欢的即可。他声称帮助用户管理和控制自己的隐私。这个提法深受欢迎。
Ghostery的另外一个作用，是帮网站主了解自己的网站到底被多少监测软件占领了，并且可以迅速排查哪些有用，哪些早已不应该存在在页面上。
不过，Ghostery并不仅仅只是这点功能，它实际上想要做的商业模式是2B的。由于超过数十万用户使用这个工具，他们成功的让自己成为了一个安装广泛的toolbar。现在，浏览器上有了它的toolbar，于是这个公司开始为企业提供这些公司网站在客户端的表现情况，而且还能够捕捉到很多的用户的数据。这个想法真是有够绝的。看起来跟我们国家的360杀毒一脉相承，杀毒不是目的，搞到数据和流量才是目的。
记住这家企业：Ghostery，国内完全可以快速翻版。
最后，放一张在旧金山清晨拍的照片，正好就是梅西百货的倩影。
工具三：HeapAnalytics
HeapAnalytics是另外一个很具有前瞻性的解决方案。这个工具非常符合我在上集中说的“去技术化”特征。
我们都知道，做网站分析，有两个大部分的事情要做，一个是做Tracking（监测），另外一个是做（Analysis）分析。Tracking这块，如果只是把一个工具提供的基本代码原封不动的丢到</body>或者</head>前面还好点，但如果我们要实现哪怕一点点高级的功能，基本都需要对代码动或大或小的“手术”。对于GoogleAnalytics而言，做eventtracking（事件追踪）或者是自定义变量（customviarables）对于不懂前端技术的朋友来说，就不怎么简单了。而更复杂的监测则更望尘莫及。
HeapAnalytics的一大特异之处是，让我们任何完全不懂技术的“普通人”，也能够轻而易举的监测到任何我们想监测的东西。
HeapAnalytics的方法是，它提供了一个所见即所得的追踪方式——HeapAnalytics在它的监测配置页面中，直接引用了你的页面，然后，你的鼠标移动到页面的任何可交互位置，都会有一个红框把该交互元素框取下来。这时，如果你点击，就等于告诉了HeapAnalytics说，“我想监测这里”，于是HeapAnalytics让你把这个想监测的地方起一个名字，然后它就会开始帮你监测这个地方。是不是追踪设置非常简单？下图中所示的，就是当我把鼠标停留在搜索框的位置时，HeapAnalytics的监测确认红框也框下了这个互动元素。一旦我确定这个地方需要监测，并且提交给HeapAnalytics，它就会忠实记录这个搜索框被激活的次数加上搜索发生的次数。如果你想单独记录搜索框被激活的次数，或者点击放大镜图标的次数，只需要把鼠标移动到相应位置即可。
不过，不仅如此。这个工具另一个让人印象深刻的地方是，即使你自己没有定义页面上的任何元素，当你鼠标在它的监测设置页面上点击下去的时候，它会立即告诉你这个地方曾经被点击的次数。如下图所示：
既然抓图抓到了这个网站的页面，我就顺便做一下介绍。这个网站是我和好多个对大数据有特别爱好的朋友一起做的，我们的宗旨是翻译一些觉得有趣的海外的关于大数据的信息，然后完全完整原汁原味的呈现给大家。其中有很多不错的内容，所以，如果大家对大数据感兴趣，又想知道国外的counterparts是怎么看待大数据的，不妨支持这个网站，谢谢！链接是：世界大数据观察。如果有兴趣加入我们的，也请跟我联系。
关于HeapAnalytics我就说到这里，因为是完全免费的，大家自己去尝试就好了。它并不是一个全面的工具，但它确实是一个很好的eventtracking的解决方案。
工具四：Ensighten
这些工具统一属于一个大的范畴，即tagmanager工具。这一类工具要解决的问题很明确，即降低各种加之在页面上的追踪代码和互联网营销工具代码的管理复杂度。一个简单的场景可以让大家理解它们的用途。如果我们的一个网站上，放置了GoogleAnalytics（GA）的代码，大家都知道它的代码是可以根据需要进行定制的，如果某一天，你觉得必须要对页面上GA的代码进行修改了，你会怎么做？通常的流程是，你需要拿着新的代码，告诉你的前端工程师，请他们帮忙放上代码，并且测试代码的可靠性，然后才能正式上线启用。这个流程对于一个稍微复杂一点的企业，就不是那么简单了，至少分析师需要向前端工程师求情，然后再等待执行排期。或许，等你刚刚改好了这个代码，新的代码修改需要又出现了，你不得不又找工程师帮忙——我相信你已经不得不请他吃饭以确保他能心平气和的帮你的忙了。
问题是，我们要应付的还不只是一个GA的代码，还有很多其他监测的代码，比如我们在第一集提到的那些工具，比如Miapex的代码，或者流行的AdobeAnalytics工具神马的。而且，我们还不只是会在页面上放置监测代码，我们还会放上很多营销工具的代码，例如做targeting，retarting，还有RTB的代码——页面上塞满了各种代码，我们每次要做修改，都要让技术同事忙活一番，而且还存在着各种可能没能事先预知的危险。所以，这绝对不是可以轻视的事情。
Ensighten、TrackingFirst以及GoogleTagManager是解决这类问题的工具。原理很简单，把所有的代码都不要再直接放到页面上了，而是统一集中到第三方的服务器上的一个.js文件中，页面上只放一段代码，用于调用这个外部的.js文件。一旦调用发生，这个文件中的所有的代码就能在页面中发挥功能，就如同这些代码直接被写在了页面中一样。关于调用外部.js文件，对于前端技术同事来说就跟1+1=2一样直白。如果你对此不是很了解，直接问问技术同事即可。利用这个方式，当你需要对任何第三方代码进行修改时，就完全不必要再麻烦技术同事折腾页面了，你只需要修改这个外部的.js文件即可，而且修改之后，立即生效。
我特别提及了Ensighten的原因是，它确实是我认为的目前业界最好的tagmanager，而且风头正劲。收购了它的竞争对手TagMan之后，它在这个领域的市场占有率可能也是最大的。这个公司不仅仅提供面向web的代码管理方案，它也做eventtagging的管理（对用于做事件追踪的代码进行管理），以及对mobileapptracking的代码（相当程度上我认为是sdk的library）进行管理等。完整的解决方案让这个供应商显得更有竞争力。
Google的TagManager怎么样呢？没问题，免费而且稳定。它与Ensighten的竞争关系类似于GoogleAnalytics和Omniture的竞争关系，各有各的市场吧。
图：没有TagManagement的情况下管理页面的各种监测代码真是非常麻烦的事情（图片来自于工具：TraceAd）
图：有了TagManagement，代码管理简简单单！（图片来自于工具：TraceAd）
另一个值得关注的地方是tagmanager向app监测领域的延伸，即监测sdk管理工具。原理与上面一样，各种sdk不再直接添加到app中，而是统一放到一个云端，这个云端生成一个“总的”sdk包，包含各种供应商的sdk，然后把这个总的sdk发给各个app。这样app中的sdk需要做修改或升级，同样不需要再对app本身进行迭代。这个领域同样具有很大的前景。
Ensighten这一类工具的生意机会在哪里？我觉得太大了。它们真的很聪明，自己并不需要做一个特别的分析工具，或者不需要做一个营销工具什么的，就能通过其他的分析工具或营销工具服务商，迅速铺满各种终端。如果它们在自己的.js文件或者sdk中加上一点点实现自己功能的东西——比如监测点什么——理论上会比任何一家营销工具能够覆盖的终端都要多。所以，他们实际上可以控制最多的数据源。当然，数据源就是钱，你懂的。
当然，我会说，帮助人们减少tagging的难度和成本，也是一种典型的去技术化。我期待在不远的未来，所有的tracking和tagging都能不依赖于网站的前后端技术人员，这一定是迟早的事情。
