透過 Google Analytics - Measurement Protocol 追蹤 IOT、Email 開信率等

雖然很多東西都建立在 Android 上，但總是有純 Unix 的環境，這時就用用 Google analytics (GA) 的 REST API 了 XD 這東西用途很廣，因為它可以偽裝成 image ，例如 <img src="//www.google-analytics.com/collect?...">，甚至可以用在 EDM 等等的（雖然 Email 常常預設把遠端資源關閉） ，此例，我們專注在 IOT 上，而測試方式只要用用 cURL 即可，十分便利。

由於是 IOT 角色，須留意 GA 的資源限制：https://developers.google.com/analytics/devguides/collection/protocol/v1/limits-quotas

• 10 million hits per month per tracking ID
• 200,000 hits per user per day
• 500 hits per session not including ecommerce (item and transaction hit types).

總之，用法都很簡單，叫 IOT 定期打卡即可，最重要的工作項目反而是定義產品的使用情境，把那些狀態定義好後，當作 web page 來呼叫 Google Analytics API 吧！

簡易範例：

$ curl 'https://www.google-analytics.com/collect?v=1&t=screenview&tid=TRACKING_ID&an=YOUR_APP_NAME&cid=CLIENT_ID&cd=YOUR_PRODUCT_STATE'
GIF89a?????

其中範例回應的就是一張 GIF 圖檔，而更多應用請參考 https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters ，若一直試不出來，可以用 https://ga-dev-tools.appspot.com/hit-builder/ 偵錯看看。

[NodeJS] 透過 Wget + HTTP Proxy Server 架構進行 Content 分析

前陣子研究抓取資料時，發現 web crawler 搭配 proxy 時，可以在 proxy 這層進行資料的處理、分析，就一直思考到底要用 python 還是 node.js 測試，最後，實在是 node.js 方便許多，就...衝啦。

在進行之前，小提一下 Proxy Server 本身就有 Internet Content Adaptation Protocol (ICAP) 機制，其實只需要架一個 Squid 在寫一些 ICAP 即可達到類似的效果，有興趣可參考：[Python] 使用 PyICAP 淺玩 ICAP 與 Squid (以 Response Modification / RESPMOD 為例) @ Ubuntu 12.04。

對於沒開發過 node.js 的我，就先參考 node-http-proxy 的目錄結構建立起來一個 open source：node-content-filter-proxy。

這兩天抽空把玩的心得：

• 支援 HTTP Requests
• 尚未處理 HTTPS Requests

抽取 <a href="...">...</a> 用法：


$ cd node-content-filter-proxy/examples && npm install
$ clear;node extract-hmtl-a-href.js
1 Jun 10:20:22 - Service Running at 3128 Port

透過 wget proxy usage：

$ http_proxy="http://localhost:3128" https_proxy="http://localhost:3128" wget -qO -  http://www.google.com/
<a href="http://www.google.com.sg/imghp?hl=en&tab=wi">Images<a/>
<a href="http://maps.google.com.sg/maps?hl=en&tab=wl">Maps<a/>
<a href="https://play.google.com/?hl=en&tab=w8">Play<a/>
...

簡單的說，想要透過既有的 crawler (wget) 去下載資料，但是，資料中我只對 hyperlink 感到興趣，所以透過 proxy server 更新成只回傳 hyperlink 就好，維持 hyperlink 結構可以讓 wget --recursive 抓資料。

如此一來，原先 crawer = wget 架構，轉形成 crawler = wget + proxy server + content analysis 模式，可以專心擺重在內容分析，不必從頭刻一隻類似 wget 的程式。

最後一提，在 extract-hmtl-a-href.js 範例中，採用的不是透過 regular expression 去分析 link ，而是接近一隻 Javascript Rendering Engine (cheerio) ，所以未來可以做的事更多了 :) 至於效率部分倒還好，畢竟 crawler 抓太快會被 ban 掉，此外，分析 content 時，也能設計複雜更高的 seed list (回吐  hyperlink 時)，能避開 DOS 現象（例如限定某個 domain 、網站一天只抓2000筆等）。