給政府單位資訊局處想做 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 了...

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

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

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

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

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

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

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

前一陣子有人問我是否可以做文章分類, 而新文易數當時抓資料時是以標籤 (Tag) 為目標, 並不是以分類 (Catalogue) 為目標時, 在想說要重新抓這些媒體是相當困難的, 此時就想到一個很有趣的想法:

若是虛擬一個人格 (Agent), 若是只餵食(閱讀)體育新聞時, 此時推薦出來的清單都應該是以體育新聞或其相關為主.

當時就用這概念就做了幾個機器人 (Software Agent), 就可以很輕易的把文章做分類, 只要有針對這分類的 "種子", 即使這個分類只是次分類, 如棒球, 汽車, 教育, 長照, .... 因為不是針對這些類別去做定義, 而是持續的把這相關的文章丟進去這系統, 即使若是有算不到的情形, 再經過 "工人" 的再 "餵食 (輸入)", 此時配對出來的訊號 (Signal) 會越來越高, 也越來越準.

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

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

1. 可以建議這個媒體的記者該追蹤的新聞或文章

2. 可以建議這個媒體的讀者, 他會有興趣閱讀的跨媒體內容

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

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

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

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

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

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

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