明天的數字營銷分析工具（下）

轉載贊3 收藏3 評論

舉報 2014-07-24

掃描,分享朋友圈

來源：CWA

上回提到了兩個“明天”的工具：Miapex和Ghostery，在新的一集里，我們繼續看其他的有趣的解決方案。

工具三：HeapAnalytics

HeapAnalytics是另外一個很具有前瞻性的解決方案。這個工具非常符合我在上集中說的“去技術化”特征。

我們都知道，做網站分析，有兩個大部分的事情要做，一個是做Tracking（監測），另外一個是做（Analysis）分析。Tracking這塊，如果只是把一個工具提供的基本代碼原封不動的丟到</body>或者</head>前面還好點，但如果我們要實現哪怕一點點高級的功能，基本都需要對代碼動或大或小的“手術”。對于Google Analytics而言，做event tracking（事件追蹤）或者是自定義變量（custom viarables）對于不懂前端技術的朋友來說，就不怎么簡單了。而更復雜的監測則更望塵莫及。

HeapAnalytics的一大特異之處是，讓我們任何完全不懂技術的“普通人”，也能夠輕而易舉的監測到任何我們想監測的東西。

HeapAnalytics的方法是，它提供了一個所見即所得的追蹤方式——HeapAnalytics在它的監測配置頁面中，直接引用了你的頁面，然后，你的鼠標移動到頁面的任何可交互位置，都會有一個紅框把該交互元素框取下來。這時，如果你點擊，就等于告訴了HeapAnalytics說，“我想監測這里”，于是HeapAnalytics讓你把這個想監測的地方起一個名字，然后它就會開始幫你監測這個地方。是不是追蹤設置非常簡單？下圖中所示的，就是當我把鼠標停留在搜索框的位置時，HeapAnalytics的監測確認紅框也框下了這個互動元素。一旦我確定這個地方需要監測，并且提交給HeapAnalytics，它就會忠實記錄這個搜索框被激活的次數加上搜索發生的次數。如果你想單獨記錄搜索框被激活的次數，或者點擊放大鏡圖標的次數，只需要把鼠標移動到相應位置即可。

不過，不僅如此。這個工具另一個讓人印象深刻的地方是，即使你自己沒有定義頁面上的任何元素，當你鼠標在它的監測設置頁面上點擊下去的時候，它會立即告訴你這個地方曾經被點擊的次數。如下圖所示：

既然抓圖抓到了這個網站的頁面，我就順便做一下介紹。這個網站是我和好多個對大數據有特別愛好的朋友一起做的，我們的宗旨是翻譯一些覺得有趣的海外的關于大數據的信息，然后完全完整原汁原味的呈現給大家。其中有很多不錯的內容，所以，如果大家對大數據感興趣，又想知道國外的counterparts是怎么看待大數據的，不妨支持這個網站，謝謝！鏈接是：世界大數據觀察。如果有興趣加入我們的，也請跟我聯系。

關于HeapAnalytics我就說到這里，因為是完全免費的，大家自己去嘗試就好了。它并不是一個全面的工具，但它確實是一個很好的event tracking的解決方案。

工具四：Ensighten

這些工具統一屬于一個大的范疇，即tag manager工具。這一類工具要解決的問題很明確，即降低各種加之在頁面上的追蹤代碼和互聯網營銷工具代碼的管理復雜度。一個簡單的場景可以讓大家理解它們的用途。如果我們的一個網站上，放置了Google Analytics（GA）的代碼，大家都知道它的代碼是可以根據需要進行定制的，如果某一天，你覺得必須要對頁面上GA的代碼進行修改了，你會怎么做？通常的流程是，你需要拿著新的代碼，告訴你的前端工程師，請他們幫忙放上代碼，并且測試代碼的可靠性，然后才能正式上線啟用。這個流程對于一個稍微復雜一點的企業，就不是那么簡單了，至少分析師需要向前端工程師求情，然后再等待執行排期。或許，等你剛剛改好了這個代碼，新的代碼修改需要又出現了，你不得不又找工程師幫忙——我相信你已經不得不請他吃飯以確保他能心平氣和的幫你的忙了。

問題是，我們要應付的還不只是一個GA的代碼，還有很多其他監測的代碼，比如我們在第一集提到的那些工具，比如Miapex的代碼，或者流行的Adobe Analytics工具神馬的。而且，我們還不只是會在頁面上放置監測代碼，我們還會放上很多營銷工具的代碼，例如做targeting，retarting，還有RTB的代碼——頁面上塞滿了各種代碼，我們每次要做修改，都要讓技術同事忙活一番，而且還存在著各種可能沒能事先預知的危險。所以，這絕對不是可以輕視的事情。

Ensighten、TrackingFirst以及Google Tag Manager是解決這類問題的工具。原理很簡單，把所有的代碼都不要再直接放到頁面上了，而是統一集中到第三方的服務器上的一個.js文件中，頁面上只放一段代碼，用于調用這個外部的.js文件。一旦調用發生，這個文件中的所有的代碼就能在頁面中發揮功能，就如同這些代碼直接被寫在了頁面中一樣。關于調用外部.js文件，對于前端技術同事來說就跟1+1=2一樣直白。如果你對此不是很了解，直接問問技術同事即可。利用這個方式，當你需要對任何第三方代碼進行修改時，就完全不必要再麻煩技術同事折騰頁面了，你只需要修改這個外部的.js文件即可，而且修改之后，立即生效。

我特別提及了Ensighten的原因是，它確實是我認為的目前業界最好的tag manager，而且風頭正勁。收購了它的競爭對手TagMan之后，它在這個領域的市場占有率可能也是最大的。這個公司不僅僅提供面向web的代碼管理方案，它也做event tagging的管理（對用于做事件追蹤的代碼進行管理），以及對mobile app tracking的代碼（相當程度上我認為是sdk的library）進行管理等。完整的解決方案讓這個供應商顯得更有競爭力。

Google的Tag Manager怎么樣呢？沒問題，免費而且穩定。它與Ensighten的競爭關系類似于Google Analytics和Omniture的競爭關系，各有各的市場吧。

圖：沒有Tag Management的情況下管理頁面的各種監測代碼真是非常麻煩的事情（圖片來自于工具：TraceAd）

圖：有了Tag Management，代碼管理簡簡單單！（圖片來自于工具：TraceAd）

另一個值得關注的地方是tag manager向app監測領域的延伸，即監測sdk管理工具。原理與上面一樣，各種sdk不再直接添加到app中，而是統一放到一個云端，這個云端生成一個“總的”sdk包，包含各種供應商的sdk，然后把這個總的sdk發給各個app。這樣app中的sdk需要做修改或升級，同樣不需要再對app本身進行迭代。這個領域同樣具有很大的前景。

Ensighten這一類工具的生意機會在哪里？我覺得太大了。它們真的很聰明，自己并不需要做一個特別的分析工具，或者不需要做一個營銷工具什么的，就能通過其他的分析工具或營銷工具服務商，迅速鋪滿各種終端。如果它們在自己的.js文件或者sdk中加上一點點實現自己功能的東西——比如監測點什么——理論上會比任何一家營銷工具能夠覆蓋的終端都要多。所以，他們實際上可以控制最多的數據源。當然，數據源就是錢，你懂的。

當然，我會說，幫助人們減少tagging的難度和成本，也是一種典型的去技術化。我期待在不遠的未來，所有的tracking和tagging都能不依賴于網站的前后端技術人員，這一定是遲早的事情。

工具五：Dundas和Sweetspot Intelligence

我一直在強調去技術化。數據不能被好好利用的原因，是人人都知道它是一個極為深奧且需要累積大量知識和技術才能被利用的東西。如同一個堅果，我們需要打碎它外部堅硬的果殼才能品嘗到鮮美的果實，但單這果殼就讓人望而卻步。所以數據的未來一定在去技術化，要讓普通人像瀏覽網頁一樣輕松地瀏覽數據，像操作手機一樣便利地操作數據。

數據如何才能更簡單的被人們瀏覽和操作？業界一般有兩種方法，這些方法都在數據的呈現層，也就是人機界面這個層次來體現。一種方法，是通過infographics的方式（就是我們看到的那些圖配數的狂拽炫酷屌炸天的數據圖），另一種方法，則是通過dashboard（關于dashboard報告，這里有幾篇文章都有詳細介紹，感興趣的同學不妨點擊：“可執行的網站分析報告精要”——跟糟糕的簡要報告說再見吧！；網站分析報告101：計劃、實施策略和Dashboard）。兩種方法當然都是當今最熱門的領域之一——數據可視化（Data Visualization）的最重要組成部分。而數據可視化的目的和價值，當然就是去技術化。在日常工作中，在對商業活動的指導頻率和強度上，dashboard都要比infographics重要的多。所以，在這個部分工具五中，我提到的兩個工具：Dundas和Sweetspot都是在dashboard領域有專門作為的。

在e-Summit的這次會議中，有好幾場專門關于dashboard的演講，其中一場甚至是key note speech，說明美國人對這個領域的重視。這不奇怪，因為幾乎所有利用數據的企業和部門，大家都更樂意于瀏覽更加友好的dashboard，而不是直接跳到細節報告本身。所以用戶友好是dashboard的第一個重要的特征。Dashboard的第二個特征，則是它必須能夠被定制化，畢竟不同企業和部分的業務不同，關心的事情肯定不一樣。Dashboard的最后一個特征，是絕對盡量簡明扼要的展現關鍵信息和細節。展現關鍵信息好辦，展現細節就不容易了，因為一旦有了細節，就會跟簡明扼要這個宗旨相矛盾。因此如何把握二者的平衡，是做dashboard中非常藝術的領域。

Dundas和Sweetspot這兩個工具都是dashboard的專業供應商。他們的商業模式都很明確：你給我原材料，我幫你來料加工，然后出了成品你付給我錢。原材料包括兩個：企業的業務目標和關鍵環節，以及與這些目標和環節相關的全部數據。這兩家公司，包括其他的RJMetrics等公司，并沒有特別大的不同。他們提供的服務包括：給你dashboard的生成工具（云端的或者local host的）你自己利用自己的數據制作dashboard，或是由這些服務商提供更為傻瓜的“去技術化”的服務直接利用客戶的數據，按照客戶的業務需求，把dashboards做出來，給客戶使用。有一些，例如Sweetspot，還可以做一些數據的挖掘，將挖掘的結果也呈現在dashbaords中。而Dundas則有較好的dashboard的互動能力，例如，在dashboard的某一個reportlet（子報告）中點擊一個柱狀圖中的柱子或是趨勢圖中的一根線，就會展現出這根柱子或者這根線的更細節的數據圖表。另外，大家也都提供針對不同行業的標準dashboard解決方案。

有朋友會問，Dashboards和網站分析工具中一個一個具體的報告誰更有價值？我認為它們都極為重要，體現了不同價值。Dashboards的核心在于以最“美妙”的方式展示所有的關鍵指標（KPI），而具體的reports則給你所有的過程和細節。你在dashboards上能夠快速發現讓你快樂的和讓你擔心的，但如果需要刨根問底，則需要具體的看reports。

不過，我也相信，隨著我們去技術化的深入，我們如何展示數據，一定會發生革命性的變化，dashboards最終能夠取代所有的reports，或者用更符合真實的說法，是reports本身，也會dashboard化。Dashboards不再僅僅只是展示KPI，在它的主界面上一定可以通過快速交互的方式，讓你直接在dashboards展示報告的細節，如同Dundas的網站視頻中給我們演示的那樣。更酷的工具才有未來。

工具六：Lytics

這個系列的最后一個工具，是Lytics。他們所做的是我在這個文章的第一篇中所講的“以用戶（客戶）為中心的監測和分析”，我另外一篇文章“2014年值得關注的數字分析新趨勢”也提到了同樣的觀點，這是明天的必然，或者說，明天其實已經到來了，已經是今天了。

Lytics這個工具做什么，用他們自己的話說，是“a customer data platform for customer-centric digital marketing”，就是幫助廣告主（用戶）實現以顧客為中心的數字化營銷的顧客數據平臺。理論上，這個工具幫助用戶解決幾個方面的問題：

1. 收集理論上與每個顧客相關的數據：Mobile上的用戶行為數據、互聯網上的瀏覽數據、在線購物數據、客服支持或CRM數據、社交媒體上的數據等等等等。

2. 把這些數據附著在具體的一個一個的顧客身上。當然，前提是能夠識別唯一顧客。

3. 整合這些數據，然后形成每一個顧客的畫像（profile），然后讓營銷部門和顧客關系部門利用顧客的畫像信息進行有針對性的營銷或服務。

這個工具目前仍然在內測和小圈子beta階段，這一解決方案的背后，順應了廣告主對于管理自己顧客（customer）和潛在顧客（target audience）的強烈需求。的確，我們一方面希望能夠迅速了解他們的方方面面，另一方面則希望在了解他們的基礎上分析他們的需求，并立即著手與他們發生互動。這意味著我們不再盲目、被動，而是瞅準機會為合適的對象傳達合意的消息。

與傳統的CRM工具的差異在哪里？我認為是能夠獲取和整合的用戶數據大大擴展了。傳統的CRM只能記錄已經成為自己客戶的有限的數據（購物和與你直接發生互動的那些數據），但Lytics之類的方案，則不僅僅只是盯著已經成為你的客戶的那些，還有你希望通過各種營銷手段“打擊”到的目標受眾（潛在顧客），并且，數據的內容拓展到了整個互聯網中他們的行為和靜態信息（如社會屬性），而不要求一定與你發生直接的交互。

Lytics做的如何？我尚未試用。不過這類工具其實已經不鮮見，DMP（Data Management Platform）要做的事情是完全類似的，只不過它們更偏向外部營銷，以及輸出給DSP或者Ad Exchange，而較少人為進行分析和挖掘。Lytics則提供reporting，分析以及人工的數據挖掘和數據可視化（利用Tableau之類的工具）。

這些工具，其實已經不是明天的工具了，它們已經在支配今天。

介紹到這個工具，關于明天的數字營銷分析工具也就差不多寫完了。可能還有很多我沒有寫到的。比如，NetConcepts的胡力同學邀請我寫一些ClickTale的，但是因為其實跟Miapex的解決方案比較類似，我就不重復寫了。感興趣的同學可以看胡力同學親自搭建的介紹Clicktale的網站。最后，如果大家有覺得很棒很酷的工具，也可以告訴我，我也很樂意學習之后，跟大家做介紹。

最后，老規矩，請同學們留（duo）言（duo）評（pai）論（zhuan）。

本文系作者授權數英發表，內容為作者獨立觀點，不代表數英立場。
未經授權嚴禁轉載，授權事宜請聯系作者本人，侵權必究。