基本上當時的立論是: 像 Big Data 這種專案執行最大的問題是資料取得的不確定性太多, 無法由上到下的系統分析, 但像資策會這麼階層性如此複雜的組織, 要能夠很快的把這環節串起來就是靠 Hackathon.
國外的確有很多這樣的案例, 而在講完之後, 也在想, 自己也找幾個朋友來實驗與實作看看, 但因為既然只是朋友之間的活動, 不太可能是那種長時間聚在一起的實作, 所以只能說是 Hackahop, 無法是馬拉松, 所以談不上是用跑的, 那就用跳的吧...
想說選一個很快就可以結案的計劃, 也就是說沒在很快的時間做完, 之後就不會有人想用想看的東西, 就是: 分析去年(2013)網站的報告產生器.
本來是說要去 "派樂地" 去 co-work 的, 但最後就到了紅色死神的實驗室, 雖然當晚最後反倒是花較多的時間討論, 但也確定了幾個功能與方向, 以及決定英文名, 而回家後的當晚, 一些 Prototype 雛型就出來了, 所以這兩天才會跑出幾篇奇怪的文章.
而在昨天, 也確定網址與中文名後, 就有整合介面出來了....
這個系統是架構在 Google Analytics 的進一步分析, 把這幾年的資料列出來後, 交叉比對出新資料, 然後再去跟 Facebook API (graph) 做整合, 也就是說, 這個是幫你看出你用肉眼無法直接看到的, 不然說列出一整年的 10 大文章只要拉拉 Google Analytics 出來就太簡單了, 一個經營者應該不至於不會認不出來那些網頁/文章是去年還是前年的吧?
當然用程式來做還是會有問題, 理論上識別網站不是用網址來分就是標題來分, 但這個部落格剛好是在前年改名字, 去年還改網址, 因此就會出現一些不見得算出來的事, 幸好這些還是可以透過演算法或熱門去 "消除掉"...
有人應該會好奇 "最有價值文章" 是怎來? 為甚麼不是點閱數最高的文章? 這個就很複雜了, 這是參考: 點閱數, BounceRate, ExitRate, 分享數, 平均閱讀時間等等的綜合指標, 點閱數有算在內, 但不是絕對, 而像最後出來的是 "一個表格" 這篇文章, 我就覺得相當合理..
你想知道你部落格/網站的結果嗎? 現在封測, 有須要的可以找我算, 因為權限控管還沒完全弄好, 等到整個安全與流程沒問題就會開放測試了...
(以下就是這部落格的結果)
---------------------------------------------------------
沒有留言:
張貼留言