2016年7月21日 星期四

給政府單位資訊局處想做 UX 調整的技術基本 GA 建議

(這篇文章說是寫給政府單位的資訊局處做參考, 但主要是考量到政府單位較難像一般民間機構有很快的轉變, 或有足夠的資源去改變, 但相對若對於一些資訊化還不夠, 或資訊單位較難被重視的大型企業或研究單位也適用)
0. 不能有共用帳號:

網路最重要的是 Trust but (can) Verified, 也就是說可以盡量授權讓人能夠更方便做事, 但前題是也要知道他做了那些事, 不須要刻意去建立一個假帳號, 而是每一個人可以用習慣的個人帳號來處理事情.

但我們可以記錄與追查所有事, 看是誰做的, 通常這事很少不是居於不相信, 而是基於相信, 但尤於常常因為了解不夠, 學習不夠, 或警覺不夠會發生錯誤, 而此時若知道他做過甚麼事的話就可以回溯 (Roll Back), 但若一組帳號登入的密碼被一個人以上知道, 我們就不知道誰做的, 或是有甚麼可以協助與防範的.

1. 讓所有單位的 Google Analytics 帳號可以有資訊單位一個以上的人來協助管理:

在還沒有能夠裝設同一個 GA Property 或透過 API 來整合所有的 GA 之前, 最簡單的就是有人可以看到所有的 GA, 事實上大部份的單位不只不是沒裝 GA, 不然就是仰賴場商協助分析 GA, 但事實上 SI 場商對於經營並不專長, 更不要說這個經營也是須要 Domain Know-How.

嘗試著有兩三位個可以協助各單位分析網站經營的狀況, 進一步提供意見的 Task Force (工作小組), 至少不要讓這種基本工都沒做好, 這就很糟糕了.

2. 所有單位網站至少要裝有一個共同的 GA Property

雖然 GA 從來不建議一個網站裝很多個 GA, 因為這不會讓管理更單純, 有時會讓 GA 的 Javascript 更容易有衝突, 但至少為了讓資訊部能夠好管理, 說要真的之後透過 API 來做整合之間, 共用一個 GA Property 是最簡單的方法, 雖然這對外包也是有點困難, 但透過上面第一點的方式還是可以彌補一些.

但記得 GA 很多項目都是不會看網域名或主機名, 因此不同的網域 (Hostname) 若是在同一個 GA Property 下要設 Filter (篩選器) 的 Rewrite, 把 Hostname 併入 URI (URL) 中, 不然會跑出所有網站的首頁是同一頁的現像.

3. 使用一個 Service Account 來做管理與透通

透過一個後台機制以及這個 Service Account 來授權, 可以更輕易的管理或檢視各個單位的 Google Analytics, 進一步的做分析與儀表版, 這樣才能真正發揮出網站分析工作小組的效用, 而這些都是須要資訊才能做判斷的.

這可以透過一個管理帳號來操作, 相對的也可以之後用這個方式去管帳號, 隨之的反倒是可以廢掉前面兩件事情的必要, 只是這部份須要較長時程的專案才能夠完成.

4. 建立事件 (Events)

做分析最重要的是聚合, 透過聚合後的使用者行為是最基礎的基本建設, 使用者的點擊都是有意義的, 但若這使用者訊號都是獨立事件是很難分析的, 所以我們要將之聚合, GA 的事件是最簡單的方式, 透過事件可以整合相同概念的行為, 將之分化與分類, 這是最必要的事.

依照版型去區分基本的 Head, Navigation, Breadcrumb Trail, Sidebar, Footer, Search, Tag, Extension, Basic Info 等等共用的事件, 更要以基本區塊做為 UI/UX 分析的下一環, 其中包含能夠去聚合相同的觀點, 例如 "使用者族群", "須求類型" 等等.

5. 標題, 描述, 與 Meta Data 都能夠提供有用的資訊

理論上有了事件就能夠解決大部份的使用者行為分析, 但真正要去了解使用者的須求之前更要知道這資訊的內容, 透過語意分析或事先下標籤 (Tag) 都可以知道這個資訊或這行為在做甚麼事, 只是這部份可能成本很高, 更須要有基本工, 就是建置對的標題或描述等 Meta Data 才行.

不只標題要符合現代的下標方式, Description (描述) 更是重要的是 "關鍵字" 的建立, 或是標籤的建立, 讓使用者行為與內容做結合, 前題也是這資訊內如本質已經聚焦才行, 要去用語意網路去判斷不是不行, 但不會像人一樣精確.

6. 每個網頁都要對內容, 情境, 使用者, 提供者等提供正確的標籤資訊

事件的聚合是 GA 的基本, 但只透過 GA 有時是不夠的, 夠過更多的資訊, 才能做到 "Data-Driven UX Redesign", 沒有 Data 就不叫 Data-Driven (資料驅動) 了, 要有對的資料才能做出正確的資訊.

有了這樣的配對資料, 相信不只能夠更了解人民或使用者的須求, 透過更即時的儀表版可以知道民意的趨向, 說不定從這角度才是真正的以使用者為本的分析, 相對的若是能夠把這資訊更公開, 就更可以寫出 "使用者建議" 的個人化須求分析, 讓使用者去自我調整, 自我建議, 畢竟有時使用者才更了解使用須求不是嗎?

--------------------

後記:

忘了說, 做 1 與 2 是為了因為 3 比較難完成的過渡性運作, 若有能力的資訊單位可以直接跳到 3 來直接做一個更好整合控管的系統.

而目的都是為了 4 (事件), 這對大部份的公司都是可以跳過前三項直接做的, 且大部份的公司 5, 6 都已經做得不錯, 所以當做好 4 就可以直接跳到下一階段真的去做 Data-Driven UX Redesign 了...

2016年7月15日 星期五

大數據有時只要轉個彎就能夠很實用了

有人知道我一直在思考與發展 "新媒體" 的可能性, 雖然大家都已經知道不能用 "網路" 來去劃分甚麼是傳統媒體與新媒體, 而是要以 "是否應用網路多對多的技術實現社群互動來產生價值" 來做區分, 所以也提出了個計劃:

當然這計劃不會停下來也會持續進行, 雖然這會那時實現也不確定, 或許不見得是用甚麼形式實現, 更有可能也不須要我來實現是最好啦, 但記得在 4 個月前, 寫下一個豪語:


而做到現在, 的確已經有很多 "成果" 了, 但離真的具有 "效果" 卻又還很遠, 但其中有一點最有趣的就是 "個人化".

在做個人化大家都知道是很簡單的概念, 就是若是系統能夠從一個人的閱讀記錄, 一篇篇了解這篇文章的獨特屬性, 而不是單純的從個人檔案 (profile), 或是文章分類決定一個人偏好, 尤其是透過最近的閱讀, 最新的閱讀能夠更精確的推薦給那個使用者.

這以現在的技術角度通常不是問題了, 尤其是現在與時俱進的電腦計算能力與機器學習, 以前做不到的現在都越來越簡單, 只是接下來的問題是如何拿到使用者的閱讀記錄或是如何推薦給他?

當然閱讀記錄有時可以透過臉書的動態牆分享, 對於須要大量閱讀的 "傳教士" 而言, 其平常分享的內容就足夠聚焦到他的偏好, 但其他人真的不是靠有人寫出閱讀器, 不然就是要靠 Plug-In 來追蹤了.

前一陣子有人問我是否可以做文章分類, 而新文易數當時抓資料時是以標籤 (Tag) 為目標, 並不是以分類 (Catalogue) 為目標時, 在想說要重新抓這些媒體是相當困難的, 此時就想到一個很有趣的想法:
若是虛擬一個人格 (Agent), 若是只餵食(閱讀)體育新聞時, 此時推薦出來的清單都應該是以體育新聞或其相關為主.
當時就用這概念就做了幾個機器人 (Software Agent), 就可以很輕易的把文章做分類, 只要有針對這分類的 "種子", 即使這個分類只是次分類, 如棒球, 汽車, 教育, 長照, .... 因為不是針對這些類別去做定義, 而是持續的把這相關的文章丟進去這系統, 即使若是有算不到的情形, 再經過 "工人" 的再 "餵食 (輸入)", 此時配對出來的訊號 (Signal) 會越來越高, 也越來越準.


上面就是在新文易數尚未開放的新功能 (應該也不會開放, 因為會直接寫成 API), 這篇文章雖然是屬於社會類, 但因為是國際的社會類, 又跟產業金融相關, 所以這三個數字都偏高, 若是以演算法的角度, 應該是屬於社會類與國際類, 事實上很多文章的分類本來就是很模糊, 甚至應該是網狀 (Network) 的多屬性關係 (Relation), 而不是單一的階層關係, 在這種系統就更可以表現出其 "優秀" 的地方.

此時就想到幾個有趣的地方, 若不是持續輸入一種分類的文章, 而是持續輸入一個媒體的文章, 即使這個媒體是多種分類屬性, 所以理論上最後推薦出來的應該是:

1. 可以建議這個媒體的記者該追蹤的新聞或文章
2. 可以建議這個媒體的讀者, 他會有興趣閱讀的跨媒體內容

由於這種方法可以有足夠量的樣本來輸入偏好, 所以通常會有很好的效果, 此時也利用癮科技來做實驗, 大家可以去看看效果如何, 但此時並沒有去過濾排除這個媒體, 所以出現這癮科技的文章也沒甚麼意外.

但很多網站沒有文章怎麼辦呢? 大家可以參考 "透過 Search Console API 來做關鍵字建議工具的改良" 這篇文章, 或許就直接匯入這些關鍵字, 把關鍵字當成文章, 此時就可以持續與大量的輸入, 且可以跟上時事, 準確度就很高, 這系統就變成可以推薦這網站值得發展的方向.

除了個人化, 分類, 媒體編輯, 網站經營外, 甚至可以輸入某立委 (政治人物) 的相關新聞, 以及這政治人物在粉絲團發表的文章, 就會跑出 "那些新聞值得這立法委員值得深入追蹤的建議清單", 畢竟身為立委助理 (或政治人物) 每天要去看新聞來培養自己風向球的敏感度是很辛苦的, 若能夠把較具影響力或社群有較多回應的去做篩選, 再找到是這個政治人物的守備範圍或有關系的訊息, 這樣是很有幫助的.

以現在大數據的分析中, 大部份的困難不是沒有資料, 而是有龐大的次級資料 (不是直接對應問題答案的資料), 若是大家已經有做出個人化的推薦, 可以嘗試看看轉個彎, 透過資料的整合就可以產出很有趣的應用.

而很多有關媒體, 立委之類的資訊, 這邊已經整理出不錯的資訊, 可以直接透過 API 匯入大家的編輯後台或 Dashboard (儀表版), 有興趣的可以找我介接, 希望對大家的工作有幫助.

2016年7月10日 星期日

很少人注意到的十件最重要標題製作要點 (不是殺人那種, 但不知道可是會死人?)

以 SEO 的角度, 若是以網站內容與結構的角度來看, 第一重要的網域, 其次是接下來的網址, 而排第三的就是標題了.

但標題這東西大家都只聚焦到如何寫出一個標題殺人法吸引讀者的騙術(?), 事實上除了那些騙點擊的招式之外, 還有更多基本功要做的, 尤其是技術部份, 或者是 SEO 部份, 甚至是網站經營部份都須要知道的 Know-How, 畢竟這才是讓網站可長可久的事情.

就我的經驗來看, 打開 Search Console (以前叫 Webmaster Tools) 能夠沒有 "錯誤" 的是少之又少, 大部份的人看到才發現該做的事情有那麼多, 但實際上因為太多事情沒做, 到最後只能掌握 "未來避免錯誤", 把錯誤數控制在一定的數字範圍, 過去的就讓他過去, 畢竟有太多事情處理不完.

其中最常犯的錯誤就是標題, 尤其是不同的網頁 (網址) 擁有相同的標題, 畢竟在 "制式" (Canonical) 網址在被廣為所知之前, 一個網頁因為不會改變內容的參數太多, 不太可能用網址來決定網頁的 Uniq (獨特性), 用標題的不同反倒是對於有認真經營的人是較好的線索, 但實際面有太多只是做表面功夫的系統整合商不會去管這種事, 而業主更沒有這種知識, 所以到最後網站經營變得相當困難.

既然標題是如此的重要, 所以我們在 "製作標題" 時, 須要注意到甚麼事情呢?

1. 次序 (階層):

標題有時比較像是英文地址, 從小到大, 不像中文地址是從大行政區寫到小巷弄, 而是從細節開始寫起, 但實際上也不完全如此解適, 應該是以越接近這網頁 (HTML) 完整語意的標題要放越前面, 越後面放的可較廣的層面, 例如分類等等, 最後才是網站名稱.

2. 序號 (索引鍵): 

在 HTML 改善中有一個很重要的項目要重複的標題, 這以 SEO 來說可以是致命性的錯誤, 但在於有時候網站內容不完全是由編輯所撰寫時, 遇到相同的命名是很常見的事, 為了避免這事情發生, 通常會在標題加入序號, 也就是在資料庫使用的索引鍵, 因為這是唯一 (Uniq) 的, 所以重覆的機會就不太會發生了.

3. 分隔與符號:

標題是如此重要所以也要盡量避免讓搜尋引擎判斷錯誤, 所以有時須要做一些處理讓搜尋引擎更好去辨識, 畢竟中文的斷字沒有那麼簡單, 因此利用一些標點符號, 或是空白等分隔, 不只讓使用者更好去閱讀區別, 更重要的是能夠精確的定位關鍵字.

4. 輔助關鍵字與分類:

說到關鍵字的確是 SEO 的重點, 因此通常除了給人看的 H1, H2 的標題外, 給機器看 head 的 title, 有時可以加入一些原本不存在真正標題的關鍵字, 或者是加入情境的分類, 這樣可以更延伸語意, 畢竟下標不是那麼簡單, 尤其是現在越來越多人習慣用問句做標題 (?), 或者是用匿稱去稱乎別人, 此時真正的關鍵字就不見了? 不放在 H1 或 og:title, 放在 head 的 title 倒也是另一種方式.

5. 字數長度:

標題的字數雖然有限制, 但從精確的語意標題開始擴大成大綱或情境, 最後用相同的站名或用來區分的序號, 雖然可能或超過 20 字, 但問題並不大, 因為最前幾個字足以讓人與機器辨視就可以了, 但還是要控制在一定數字之內, 以中文字的角度最好是低於 40~50 字, 甚至應該說屬於這單頁的語意的確還是要在 20 字內.

6. Sitemap 的一致性:

會出現標題的地方很多, 除了剛說的 H1, og:title 或 head.title, 在 sitemap (機器讀取用的) 或 RSS 也會有出現標題的地方, 有時搜尋引擎會抓 head.title 做為標題, 有時也會跑去抓 sitemap 的 title, 若不想要出錯, 就要保持一致性, 雖然有時刻意不一致也是有其運用的情境.

7. 變動性 (訊息, Javascript):

在有了瀑布流或訊息的機制, 利用 Javascript 去修改標題的場合越來越多了,  雖然這個對搜尋引擎不會有作用, 但對於臉書在分享時是可以指到對的網址是有幫助的, 也包含能夠提示使用者有沒有新的訊息進來, 也在於利用 Javascript 在做導引時有效, 是很好利用的方式.

8. Schema:

除了上面說的四種 Title 外, 還有第五種, 就是在 Schema.org 定義下的 Title, 尤其是現在由於利用 JSON-LD 的實作也越來越多, 以及 Google 的使用廣泛, 這部份也相對重要, 當然這也是跟內容屬性的相關性很強, 不同的內容有不同的使用情境與設計, 無論是保持一致性或是針對不同情境下標, 都是可以的.

9. 其他 Meta-Data:

當然除了前面幾種 Title 外, 一個好的網站還是要完整的滿足較多的社群有較多的 Title, 甚至若是被收錄成新聞網站後, 新聞網站更有其 sitemap 與 meta data 來去協助不同的使用情境有不同的用處, 此時考慮的地方要更多了.

10. 連結網址的標題:

除了網頁自身的標題, 出現標題更多的場合是在連結的時候, 雖然透過 Open Graph 等 meta data 可以定義社群使用狀況或是搜尋引擎使用, 但更多無法操控的是外部連結的標題, 尤其這在很多情型是 Anchor Text (錨點文字), 在意義上是更高的, 而至少網站可以利用內部連結及其相關的錨點文字定義標題, 讓使用者更願意去點擊, 這在使用者情境是相當重要的.

11. 目標對像的語氣與情境:

前面說了那麼多種類的標題 (Title), 應該就會知道不同的標題有不同的使用範籌, 而下標題不只是那種騙點擊的那種標題殺人法的一種, 而應該是一種連續性的情境, 讓讀者能夠深入內容, 深入答案, 從而能夠更進一步的深層閱讀, 透過這種資訊的串連能夠讓讀者獲得要的資訊, 這才是一個好的資訊的價值所在.

當然上面的 10 點 (及多塞的一點結論) 標題製作要點, 要讓大家知道的只是大綱, 事實上裏面有太多的細節, 這個就要透過長期的內容寫作, 社群經營, 技術實作一點點的補足, 雖然那種標題殺人法的確是短時間內有效, 但最後還是很可能是效用越來越低, 較為實際的是與時俱進的基本功, 這才是網站製作經營的本質.

2016年6月15日 星期三

透過 Search Console API 來做關鍵字建議工具的改良

在三四年前 (2012 年底) 時, 總覺得 Google Analytics 不是那麼好用, 畢竟有很多東西不是靠設區間, 設目標, 設事件, 設轉換就可以做到, 事實上那時這些功能不是沒有或者沒那麼完善, 但那時至少就 SEO 的角度來看有個很大的功能: 知道使用者是用那個關鍵字進來....

到 2016 的現在, 這個功能已經像廢物一樣, 因為 Google "基於隱私" 的關係, 不讓經營者看到搜尋關鍵字, 也就是在登入狀態, 雖來 Log 可以知道使用者的來源是 Google, 但是用那個關鍵字是無法得知的, 在 2013 年之前, 還是有六七成的關鍵字是可以看得到, 但到現在, 連 6~7% 都沒有了, 我曾做過一張表, 就是算這幾年無關鍵字 (No Provided) 的變化, 從下面就看得出來, 在 2011 年 10 月開始執行這政策, 現在可能只剩 2.5% 可以看得到了.



因此在當時做的網事 ( http://web.mas.ter.tw/ ), 透過關鍵字的變化來做到 "關鍵字建議工具" 是非常好用的, 但隨著 No Provided 的增加, 曾改成為透過落點頁 (Landing Page) 來去推測, 雖然沒有那麼直接, 還是有相當的實用價值, 只是在某方面感覺無論就準確度或者是直覺度還是差了一點.

雖然說很早 Google Analytics 就把 Search Engine Optimization (SEO, Webmaster Tools) 的報表整進去, 所以這幾年我隔一段時間都會去看看 GA 有沒有把 SEO 這部份開放 API, 若是有的話就太好了....

而等了很久還是等不到, 反倒是 Google 這段時間突然重視起這個 Webmaster Tools, 不只改名成 Search Console, 且原本很少更新功能變成幾乎一段時間就有新東西, 就像這個月就加了 json-ld (ld+json) 的工具 (Structured Data Testing Tool), 也定名為 Rich Card, 但除外, 在年初就有聽過 API 也隨之改善, 不只是只有做些 "管理" 的新增刪除, 重點是能夠把最重要的搜尋結果透過 API 可以取得.

雖然有在用 Search Console 的人都知道, 他們的資料都會晚個三四天, 但某方面已經是夠用了, 所以把當時網事寫出來的 "關鍵字建議工具" 做個改版, 但與其說是改版還不如說是完全不一樣, 因為 GA 是以埋的碼 (javascript GA code) 為單位, 但 Search Console 是以網站為單位, 甚至 http 與 https 就是不一樣, 且更重要的是, 在 Search Analytics 中有 GA 沒有的曝光量 (Impressions) 與排名, 及就可以算出 Click Through Rate (CTR) 了.

但先不管排名與 Impression, CTR, 單單就點擊這點就很夠了, 雖然這個數量只有 Google, 不包含 Yahoo/Bing, 只是基本上我們的確可以慢慢忽略 Yahoo 了.

下面兩張表上面是原本透過 GA 抓到, 下面是透過 SC (Search Console) 的 API 抓的, 從這邊就可以看到其變化, 這資料是用 "新文易數" 來做舉例:
從這邊就可以看出來在不到 10% 的資料, 要算出個有意義的資料真的太困難了, 除非偶而會有爆量的關鍵字, 在被稀釋之後的資料跑出來, 不然就是沉在看不到的地方, 相對透過 SC 的資料, 唯一的問題是只能抓到三天前的資料外, 完整度都相當足夠, 原本看不到的都看到了.

當然除了可以從 Clicks 來看, 還可以從 Impressions 的角度來看, 且在這邊應該要分開兩種 Impressions, 一種是使用者會點擊而爭取到流量的關鍵字, 另一種是跟網站屬性差很多的關鍵字, 即使曝光再高, 但點擊通常是 0 這種關鍵字是沒有意義的, 所以本來就應該從這三種角度來看, 自然我也寫出了三種不同的報表來實驗.

基本上在 SC 的觀點, 這些查詢都是總量, 的確是不會影響到 "隱私權" 的問題, 這時候至少 Google 已經不會被罵說想把這種資料拿來自己賺錢用了, 對網站經營者倒是個很大的福音, 有興趣嗎? 就招喚你們的工程師吧 (別忘了幫他們加薪) ....

2016年5月18日 星期三

從社群的各個角度來看媒體

最近很喜歡在相關的課程說一個很重要的觀點:

"大數據是一種最準確但也是偏差最大的一種觀察研究方法, 準確是因為資料的取得可以很客觀且巨量, 這樣的資料才能做到誤差最小, 但若是只用一種角度去看或是一種方法去搜集, 這種巨量的資料反倒是造成巨量的偏見"

不要說是社群只是眾多經營媒體的觀點與數字的一種, 單單從臉書社群來看媒體, 也是有各式各樣的觀點與數字, 更不要說我們只用粉絲團來看媒體的經營, 即使是臉書使用者的資料都能搜集到, 若沒有去了解各個面向, 誤會說不定會比正確理解來得機會高, 但若不用這些資料來去觀察, 那又可能是種刻版印像的放大, 只會讓你又犯了一次次的決策錯誤.

在兩年前嘗試著用林克傳說做了一個社群排行榜, 那個系統跟這次用新文易數做基礎的社群排行榜最大的差別是:

林克傳說能夠取樣各種媒體, 但就單一媒體的資料不夠完整, 而新文易數是能夠算到單一媒體的所有資訊, 但不在列表的就無法反應出來.

現在新文易數的確已經收錄超過 70 個媒體的資料, 尤其是前 30 大原創性高的新聞網站都收錄其中, 雖然說 30 名以後的媒體一定有問題, 但相對的前 10 名應該不會在名單之外, 我們來看這樣的社群排行榜會是怎樣的結果:


若是以總數來看, 第一名是東森新聞雲, 幾乎第二名蘋果的兩倍, 而第三名到第五名是自由時報, 壹週刊與雅虎不相上下, 但跟第二名也是差兩倍, 第六七名則是三立新聞網與中時電子報, 而除外在前十名的是東森新聞, 動網與聯合新聞網.

這是以總數來看, 這個總數是這媒體在七天內刊出的新聞, 每則新聞有其按讚, 分享與評論, 將之加總起來, 雖然在取樣與區間或多或少有時間差, 但理論上大家的條件與範圍都是一致不會差太多.

而從讚享評總數來看會讓一些新聞數沒有那麼多的小媒體吃虧, 若是用單一則最高的觀點來看, 擠進前 10 名的媒體是風傳媒 (事實上總量原本是第 11 名), 被擠下去的是動網, 且是跌到第 24 名, 如此可知道動網的社群很強, 但因為是專業媒體, 族群被限制住, 所以最大的數量就沒辦法很高.

雖然綜合新聞媒體總量與最高值是占便宜的, 但在平均就很吃虧, 所以若是以前 10 名的角度, 前面 11 個媒體還能擠進去的只剩東森新聞雲, 壹週刊跟東森新聞, 這三個媒體有甚麼共同點呢? 等一下再說...

中位數指的是所有新聞排序後, 讚享評排中間的那則新聞數字, 此時不只只剩動網與東森新聞雲在前 10 名, 甚至前 30 名也只有這兩個媒體加上風傳媒與三立新聞網, 畢竟要能夠讓有一半的新聞都能動, 不只是靠內容, 記者與編輯自己也要能夠參與社群才能做得到.

眼尖的讀者有看到系統有一個 "嗨文率", 這數字是相當有趣, 計算方式很簡單, 就是 "按讚/(分享+評論)", 這個數字越高代表的是讀者看完之後很喜歡按讚, 但不會想要分享與評論, 這代表的是甚麼呢? 通常代表的是這些文章即使是有趣, 好玩, 新鮮, 但很難對社會, 對生活有所影響, 甚至不會去討論與推薦, 會造成嗨文率高有兩種可能性:

1. 農場文太多
2. 社群帶動強

而剛剛說到同時總數高, 且平均值也高的三個媒體就是東森新聞雲, 壹週刊跟東森新聞, 這三個媒體正巧是總數高且嗨文率也高的三個媒體, 雖然在嗨文率上, 動網是比這三個媒體足足多出一倍, 我們知道動網是個內部社群凝聚力相當夠的專業媒體, 而這三個媒體不完全是這因素, 代表的是另一個因素機會較高了.

若是這嗨文率高是這因素, 那若嗨文率很低的原因又是甚麼, 同時也是有兩種很大的因素:

1. 文章多是乾貨, 很硬
2. 此媒體完全無法帶動社群

所以若是把嗨文率從小排到大的話, 我們很清楚的是立報, 端新聞, 風傳媒等媒體不是很專業, 就是新聞多有份量, 造成大家的分享與討論機會很高, 不然就是像台視或中央社那樣, 社群跟本嗨不起來, 就不用想會有人按讚了.

應該有人有看到表格中有個 "長尾指數", 這代表著這媒體是否有網路媒體可帶動的長尾效應, 還是極度利用炒作議題所造成的結果, 數字越高代表越長尾, 而這部份的計算與意義, 倒是等到畫出一張圖後再來解釋比較方變, 敬待下回分解.......

最後, 媒體的社群表現, 尤其是只看讚享評的數字, 說穿了用再多種的數字來看也只是眾多面相的一種, 跟真正的導流, 或者是所有流量, 甚至是媒體的收益, 往往每一個環結每一個媒體都是u有不一樣的轉換率, 雖然這資料的準確度再高, 也是種有偏差的觀察, 只是對於要去參與社群經營的媒體工作人員, 卻是相當有用的, Have Fun~~~~

連結: http://tag.analysis.tw/media_social.php

2016年4月12日 星期二

New SEO KPI 的規劃

很多人一直問我, SEO 這工作最主要的 KPI 是甚麼? 我通常會說有兩大表相:

1. 搜尋引擎帶進來的流量數
2. 搜尋引擎帶進來的流量占比

這兩個主要 KPI 的成長量 (月成長與年成長) 就可以決定 SEO 的效果, 但這個做為檢核的機制是不錯, 但要做為做事的導引卻是相當困難, 所以我再補充了幾個可以量化的點:

1. 搜尋引擎的索引總數
2. 外部連結的數量與連結頁數
3. 內部連結的數量與分布
(4). HTML 的錯誤數
(5). 搜尋引擎的錯誤數

只是無奈這部份 Google 都沒提供較好的 API, 某方面只能用 csv 匯入資料來作業...

在一年半前 (2014 年 1 月), 想出了一個有趣的方法來檢核 SEO KPI, 也就是:

"搜尋引擎進來的關鍵字與落點頁, 是否具有長尾效應?"

雖然這個用人工去算是相當困難的, 但相對的若是用 Google Analytics API 來做並不困難, 因此後來做了 seokpi.analysis.tw 這系統, 就可以從分布圖定義出簡單的 "Index (指數)" 來去比較這個網站是否從一般行銷方式的 80/20 慢慢的進步到長尾, 然後配合最前面的兩個搜尋流量與占比, 這四個數字定義出一個最終 KPI.

但一年半過了, SEO 的改變也相當多, 面向與思維也越來越廣泛與複雜, 用這四個數字來做最終 KPI 的基礎已經不夠了, 因此也在想說如何進一步的改良這個 SEO KPI, 來去協助大家的進步.

而一年多來最大的概念改變在於:

1. 使用者在網站的訊號變得是一個重要的因子
2. 網站內容會依網站結構有不同的使用者訊號比較
3. 搜尋引擎帶進來流量是否有真正的價值
4. 搜尋引擎行為對網站的影響 

要去計算到上面幾件新思維改變, 就代表網站分析前題是要做到下面三件事:

1. 要去區分內容頁與中介頁, 與內部搜尋結果頁對搜尋引擎的差異
2. 不同來源與搜尋引擎來源對使用者行為的差異來證明
3. 如何區分 Short Click, Long Click, Pogosticking, Next Click 與 Next Search 的來源

雖然最後的指標, 也終也是使用 Click Through Rate, Time On Site/Page per Session, Bounce Rate/Exit Rate 這三種類型的指標來去計算其效益, 只是對於 SEO 操作的人, 真的要去區分上面與計算出這幾種來源與類型, 來去比較這之間的差異, 有些不是可以靠苦工做得到的, 甚至有時不是靠單純的 GA 操作就可以得到的.

當然在某方面甚至不是只靠 Google Analytics, 或是只是用檢視的區分與比較, 說不定是只靠 GA 是做不到的, 但相對的, 但畢竟是否能夠用幾個基本的 Customized 的方式就可以做到基本的計算, 畢竟真的要不只用 GA 的普遍性是更困難的.

但話說, GA 雖然是一個很重要的角度, 但除此之外還有一個更重要的是 On-Page Analysis, 而這部份大家真的可以去使用 Awoo 的 SEO Tools, 如 天下無狗 與 球來就打, 這也是一個很基礎的項目, 也不要忘記了...

而這次的 New SEO KPI, 整體的演算法雖然都已經想好 (聽說是在去年就想好了), 但那時會實作出來大家可以給個建議, 畢竟這次的複雜度不輸給一年半前的挑戰阿...

2016年4月7日 星期四

未來電視

電視, 或者說是螢幕, 甚至是網頁 (Web), 是一種讓人看到資訊的介面, 但與其說是傳遞影音的內容, 更具概念性的意涵是: 人的眼界可以透過這個 "Windows/視窗" 來去穿越, 穿越時間, 穿越空間, 穿越思考, 甚至可以穿越人性的一個 "設備".

這樣說也有點太過於抽象或流於概念化, 但事實上從電視的發展到現在, 也沒多久, 只是未來的可能性越來越高, 只是這個絕對不是把定義放在 "影音", 甚至是靠 "規格" 來去思索, 就像是下面我在 2006 年寫的 Web 8.0 Road-map 一樣, 這是一種文明演化的可能性:

Web 1.0 網站與網頁的開始:  [名言] 給我 Web (1.0), 我給你全世界.
Web 2.0 非同步顯示與使用者互動: [名言] 沒有 2.0 就不叫 Web.
Web 3.0 語意網路與自動化/自主化: [名言] 還要去想今天做甚麼? 這問 Web 3.0 就好.
Web 4.0 全影顯示與腦波輸入的開始: [名言] 連紅綠燈都變 Web 了, 那有甚麼不是 4.0?
Web 5.0 身體內嵌 Agent: [名言] Web 5.0 是天生的, 不是後來創造的.
Web 6.0 網路 Cyborg 的串聯: [名言] 抵抗是無意義的, 所有都會被 Web 6.0 整合.
Web 7.0 Deep Thought: [名言] 宇宙是由 Web 7.0 創造的, 是一個終極實驗.
Web 8.0 此時還有人嗎? [名言] GUT 可能要 11 維時, Web 8.0 就終結一切.

雖然說這些都是靠技術去實現, 就像是現在的電視從 SD 到 FHD, 到 UHD, 從 4K, 8K 到 16K, 在某些方面是種數量的變化, 是種規格的改變, 但真正的代表是種可能性擴展, 也就是說讓內容創作者可以從體驗, 到感知, 到應用所有元素去實現所有的想像.

只是這樣的想像須要一步步去完成, 不可能一促而及, 就像是 Internet 的發展即使再快, 但有很多過程與中間技術, 無論是有繼續使用或沒有人在用的技術, 但要去實現過程都是很辛苦的路, 或許我們來嘗試著列舉幾個未來須要突破的事:

1. 螢幕之間的溝通: 每次看到一些未來展望的影片, 都有跨螢幕的觀看的體驗, 所以大家都覺得這應該很簡單, 但事實上現在還沒有較好的協定與方式去讓兩個螢幕去做溝通, 那就更不用說是協同了.

2. 人身份的辨識: 雖然這理論上是最簡單的, 但目前大部份都是要靠搖控器來操作選項輸入, 雖然說靠 Camera 可以做, 而離實務上還很遠, 但現在有 iBeacon 等等都是候選.

3. 3D: 無論是 VR 或是 3D, 離真正的裸視還有段距離, 雖然有些已經有高單價特定環境的解決方案, 但要能夠普及或較寬鬆的環境設備可能還須要一些開發技術.

4. 內容的選擇: 無論是用甚麼方式來看, 重點還是在內容, 只是這內容是如何去選擇, 是永遠的單線執行, 還是依人的想法回饋改變, 這背後的演算法會是甚麼, 會讓人的視野更廣更深, 還是讓人更淺薄更好操控?

5. 與社會的互動: 雖然電視是個看穿出去 "窗戶", 但能不能演化成為一個可以互動的 "門", 可以透過電視去參與社會, 甚至讓人與人之間能夠有更多樣性的互動, 都是 "未來電視" 的可能性.

6. 資訊呈現的架構與連結: 常常看到很多看起來像 "Prototype" 的 Demo, 資訊的整合與呈現似乎是相當吻合場景與須求, 但這才是最困難的, 要去跟那些既有資訊連結, 無論是內部與外部, 透過辨識情境, 都沒這麼簡單.

7. 內容的產出: 在非線性與非單一視野的觀影經驗慢慢成型, 但挑戰的是內容要如何製作, 如何產出, 從腳本的製作, 影像的拍攝, 甚至剪接的方式也會變得不一樣, 內容製作者要如何面對這挑戰, 做出經典範本讓大家學習, 這才是更須要時間.

8. 社群的連結: 除了內容, 除了社會, 人最多的訊息是來自於社群, 也就是朋友, 在未來, 類社群, 類影像的訊息溝通會扮演很重要的角色, 畢竟真正讓人悸動的還是人, 不是內容.

而上面幾個要克服的事, 都可以從很多角度或面向來看, 主要是以人, 內容, 機器, 架構與系統商這幾個層面, 而這些層面要考量的是下面幾點:

A. 人的角度: 2, 4, 5, 8
B. 內容的角度: 3, 4, 5, 7, 8
C. 機器的角度: 1, 2, 3, 8
D. 架構的角度: 1, 2, 4, 5, 8
E. 系統商的角度: 4, 6

當然這只是主要的, 事實上未來電視要發展, 本來就是種多面向的事情, 要把這些整合實作出來, 沒這麼簡單, 甚至可能要像 IP 一樣, 走到現在已經到 IPv6 了, 而未來電視要走到第幾版才會真正合乎人性呢? 這就要看大家的投入與參與, 或者只是個使用者都會影響到未來....

LinkWithin

Related Posts Plugin for WordPress, Blogger...

熱門文章