IMHO, 黑貘來說

在台灣 Netflix 有上的動畫 (防疫期間)

2021-06-21T14:11:00.005+08:00

依 IMDB 超過 1 萬人以上評分的順序

降世神通

1. 9.3 Avatar 降世神通
2. 9.2 Ricky and Moorty
3. 9.1 鋼之鍊金術師 Brotherhood
4. 9.0 進擊的巨人
5. 9.0 獵人
6. 9.0 死亡筆記本
11. 8.8 一拳超人
13. 8.8 咒術迴戰
16. 8.7 鬼滅之刃
18. 8.7 排球少年
19. 8.7 Bojack Horseman 馬男波傑克
20. 8.7 反叛的魯魯休
21. 8.7 烙印勇士
23. 8.7 南方公園
26. 8.6. 四月是你的謊言
27. 8.6 Young Justice 少年正義聯盟
29. 8.6 Advanture Time 探險活寶
30. 8.6 火影忍者疾風傳
32. 8.6 The Simpsons 辛普森家庭
34. 8.5 Love, Death and Robots 愛死機器人
35. 8.5 約定的夢幻島
37. 8.5 我的英雄學院
38. 8.5 Trollhunters 巨怪獵人
43. 8.5 攻殼機動隊 SAC
48. 8.5 新世季福音戰士
51. 8.4 The Dragon Prince 龍的王子
53. 8.4 Jojo 的奇幻冒險
55. 8.4 The Legend of Korra 科拉傳奇

科拉傳奇

原始來源：

資料科學的局限或是不同可能性？(來檢驗王定宇與黃偉哲民調的真實面)

2018-03-10T23:17:00.001+08:00

民進黨為了要決定提名，因此辦了民意調查，來決定候選人，而公布高雄市的民調時，嘗試跟 "專頁儀表板" 做了個比較，發現相關性達到 0.99 以上這個令人吃驚的事，但第二天台南的民調跟專頁儀表板的相關性只有 0.03，這數字可以說是完全無關，而 0.99 的相關性雖然是令人吃驚，但 0.03 這個無關結果更令人無法理解。（見粉絲團談論人數與民調的驚奇異同 )

會出現 0.9911 的相關性雖然驚訝，但還是在可接受範圍，但 0.03 這部份是完全出乎意料，而一直在想，到底是甚麼樣的情型造成這完全無關的結果呢？在想會不會是一個是正相關，而另一個是負相關所造成的結果。

因此檢驗這數字的時候，發現有兩組資料是相當有趣的差異，一組是陳亭妃，顏純左，李俊毅，這三個人的粉絲團談論數跟民調的相關性不只是達到 0.99，而是 0.9999，這數字更令人驚訝，但另三個人的數字只剩 -0.4178。

甚至在有人提醒，不是使用葉宜津因為注音事件造成這一兩個星期的大升，而是大家都用 "月中位數" 時，此時即使是扣掉王定宇與黃偉哲這兩個人，相關係數是 0.9782，但一起算的時候自然還是 0.0462 的無關，但在這邊做了個有趣的嘗試，就是把這兩個人的數字對調，又發現一個驚人的事實，這六個人的相關係數居然是 0.9748 的高相關。

會有這樣的結果，不得不讓人猜想，是不是有人把這兩個人數字弄錯，若真的是這樣，該出線的應該是王定宇而不是黃偉哲。此時就不得不想到很多 "陰謀論"，說不定是故意調包，或是早就談好的呢？

因為每一個候選人都很特別，最後的民調與談論數都是大家經營出來的結果，但事出必有因，會造成這樣的結果因子很多，像原本所說的：

1. 高雄慢慢變成一個商業都市，網路的普及率與接受度較高。

2. 台南有相當的人口還是在鄉村，使用網路接受訊息的狀況較低。

3. 王定宇是較為全國性的人物，不代表可以直接轉成台南市。

4. 黃偉哲的傳統插旗與廣告還是奏效？
5. 台南市的民調真的有所失真？

這些會造成影響，有些不是，甚至也發現花更多錢廣告的反倒黃偉哲不是最高的，那到底為甚麼會造成這樣的現像呢？

我相信數字會說話，除了王定宇與黃偉哲，高雄市與台南市的候選人的 "轉換率" 都很接近，有多少網路聲量就會有多少民調結果，這轉換率乖離度最大的是葉宜津，而這因子大家應該不意外。

但到底發生甚麼因子，造成王定宇與黃偉哲的 "轉換率" 完全超乎系統的預期？連我都相信 "事出必有因"，即使很難會發生，但最簡單的答案往往可能是最正確的答案，也就是真實民調是兩個人對調！

會有這樣的意外也是我預期不到的，因為以前除了用電話民調外，從來沒有其他系統可以輔助，因此大家只能相信民調，但專頁儀表板提供了一個可能性來檢驗，且在這次發現網路的真實與電話的真實若是沒有甚麼奇怪的 "因子" 大都是接近的，若有差距一定是發生甚麼事？

當然用這兩種不同方法論來互相驗証有很大的問題，一個是網路聲量越高，不代表的是正面的，也可能是負面的，且即使是正面，也不代表能轉換成 "支持度"，更不要說這選區的選民在這些支持者的比例多少，以及這選區的網路使用者是多少？

只是透過談論數是相信支持者與關心者多少跟選區相關，必竟要談論 (Making Story) 沒這麼簡單，所以會有如此高的正相關是不意外，這也是用這種方法論 "成功" 的地方？

但這不代表驗證電話民意有問題，因為網路的談論數即使可以轉換成支持度，但這樣直接說台灣的大市長直接給柯文哲做好了，因為他擁有目前透過網路所衡量出來的支持者，只是這系統為甚麼沒包含柯文哲呢？最簡單就是他並沒有參與高雄市或台南市的初選。

因此若不是系統失靈，更不是民意失真或做假，除非一個很大的因素是："台南市選民跟本認為王定宇不是出來選的"。此時唯一可解釋的就是 "棄保效應"，雖然王定宇是受到許多人支持，但當要選擇一個時，棄保效應就是原本支持王定宇的，知道他現在是第一屆的立法委員，還須要更多屆的歷鍊時，這些人的支持就會轉為支持第二個或是不同考量的結果。

畢竟資料科學利用社群數據，最有趣的地方是他是可以很準確的呈現事實的數字，但必須要有對此問題夠了解的人去組合才會有接近其他方法論的結果。所以若是棄保效應是最後操弄這次民調的最大因子，這兩個人的數字會失真也就不意外了。

所以在這次的研究可以發現幾件事：

1. 用社群聲量來轉換民意的機會很高，且幾乎都可以到 9 成以上的準確度。

2. 甚至可以用這個來做檢驗，像這次是不是真的王定宇與黃偉哲的數字弄錯或失真，也是一個有趣的檢定。

3. 但面臨到一些像 "棄保效應" 的因子時，系統就可能無法得知而造成很大的差距，因為表面的候選人民單跟真實的差很多。

4. 若真的是棄保效應，也大概可以知道像這次陳亭妃想要挖王定宇的支持者，不知為甚麼失敗，因為大部份的人都轉向黃偉哲。

有人說，棄保或配票等等說不定是傷害民主最大的事，當然若真的是這個民調是假的是更糟糕的事，雖然這都不是我們樂見的，但這次的電話民調與網路聲量讓我們看到一件有趣的事，就是在資料科學中，這兩個系統之間互相轉換面臨到的局限，或是可以挖掘到更深層的真實，而這個真實如何或是如何判斷，可能還要更多的事來驗證吧。

粉絲團談論人數與民調的驚奇異同

2018-03-09T00:13:00.001+08:00

這幾天，公布了台南與高雄這兩個地方的民進黨內部的電話民調，雖然這跟真的投票沒有絕對關係，但做民調是很花成本的，當然除非有內參保密民調與對外公開民調外，民調還是很有效的 "政治工具"。

談論人數一直是很好的指標，尤其是在選舉的時候，因為選舉最後決勝負是得票數，而選戰不可能就是等著最後結果，也必須努力的讓聲量與認同度提高，所以最常見的方式就是電話民調。

電話民調的問題很多，但網路民調問題也是很多，所以我認為這兩個方法論雖然一致，最後跟的票數有正相關是必然，只是最後這個相關的差距在於 "誤差" 與 "轉換率"，而在選舉這種分秒必爭的戰場，本來就不該輕忽任何資訊，想辦法在 "先驗" 的情型下知道戰況做判斷是必要的。

昨天在公布民進黨高雄市民調結果，恭喜陳其邁 Chen Chi-Mai 出線，當時我看這數字雖然並不意外，也沒想那麼多，而剛有朋友問我今天台南市的狀況，此時我就很想知道高雄市電話民調有沒有辦法透過誤差與轉換率來推估。

因此把民調與這週平均談論數輸入，來算 "線性迴歸" 的 "相關係數"，我預期應該是 0.7~0.8 之間，若低於這數字一定是有方法論的問題，但跑出來的結果立刻讓我嚇到吃手手，再三確認這數字沒問題，因為跑出來的結果是：

0.9911

通常相關係數大於 0.7 就可以推估有一定的相關，但 0.99 這數字已經說這兩個是一樣的結果，只有 1% 的誤差，當然這只有四筆資料，可信度表面是資料不足，但這個談論數是基於台灣平常有 1 千 5 百萬的使用者行為的結果，這個解空間不能說太小。

這數字一出來的確讓我嚇到，因為 0.9911 這數字真的是故意用 "做" 的也很難做成這樣，只是換來看台南市又是一個怎樣的狀況呢？結果更令人吃驚！

0.0310

這個數字代表的是不是正相關，也不是負相關，而是趨近於無關，這跟高雄的幾乎是 1 的正相關是天差地遠，為甚麼會有這現像呢？是真的頗令人玩味，但這邊提出幾點可能解釋。

1. 高雄慢慢變成一個商業都市，網路的普及率與接受度較高。

2. 台南有相當的人口還是在鄉村，使用網路接受訊息的狀況較低。

3. 王定宇是較為全國性的人物，不代表可以直接轉成台南市。

4. 黃偉哲的傳統插旗與廣告還是奏效？
5. 台南市的民調真的有所失真？

當然這數字有時背後意義很多，就像是在兩年前的立委選舉，雖然談論人數與票數的相關係數是 0.74 ，但每個政黨都不一樣：

畢竟這種結果常常決定於選民結構，雖然我認為這種計算方式雖然在全國性的選舉比較有意義，而六都市長通常具有相對的可信度，但其他縣市長與縣市議員的轉換度就應該很低，但沒想到一個台南市與高雄市就天差地遠。

接下來選舉越來越近，黨內初選的電話民調到底意義為何？或者是可以即時呈現的網路聲量該又如何看呢？雖然我們知道這些離選票不完全一致，但通常說，有聲量就代表有一定的支持度，除非打的是烏賊戰，此時即使高聲量也會變成負相關，或許這也是另一種警惕。

春節期間媒體粉絲團經營最不易，但政治人物與藝人是高峰

2018-02-17T19:41:00.000+08:00

專頁儀表板除了作為社群編輯的工具外，更想做的是想要成為 "透過社群來了解社會" 的儀表板，因此對於 "屬性" 上做了各個面相的定義，除了常見的分類外，更重要的是依立場，議題來去 "標籤"。

因此會有 "藍綠" 或 "廢死/反廢死"，"支持/尊重同志"，"勞資/性別"，"台北/台南"，"親子/旅遊" 等等不同的 "屬性"，而這些 "標籤" 說是種 "聚焦" 的方法，也可以做為比較的基準，所以除了相同標籤的一起看文章或圖片來集合與交互參考，甚至有排行榜來做為 "儀表板" 的概覽。

所以在一開始就寫了依 "標籤" 來看粉絲團屬性的時間軸趨勢，而當時考量到粉絲團數量的變化，因此而不是用 "絕對值" 而是用 "相對變化" 來看，只是這些變化有時太過敏感，每天上上下下反而較難看到 "趨勢"，所以想說有機會改寫成總量的圖表來看。

而這幾天看到了有趣的現像，原本看起來意義不高的圖表找到一些端倪，也就是除了立場的相對性可以看到一消一長的結果，而這次春節這段時間，更發現有趣的現像：

1. 在春節這段時間，只要是媒體，都會慘跌，無論是大眾媒體，分眾媒體，甚至是 "內容農場" 或是 "純分享粉絲團" 都跌得很深。

2. 但相較 "內容農場"，新聞媒體或是分眾媒體在花蓮大地震都震出一個相當高的眼球，除了媒體外，政治人物或宗教信仰也在花蓮大地震都有上漲。

3. 花蓮大地震媒體賺到不少眼球，但 "內容農場" 等粉絲團則是沒有跟著上去，但地震完後春節的這段時間都是有回復一些，只是春節又跌下去。

4. 政治人物跟媒體不一樣，地震這種大事件抓到目光後，雖然之後有點小跌，而開始春節拜年時又上漲回去，可以說是一波很重要的成長。

5. 除了政治人物在春節有所成長外，拜年是少不了藝人，因此藝人類的粉絲團春節當天成長了 35% 是相當驚人，只是相較地震時政治人物有 42% 的成長與信仰有 32% 成長也不算甚麼了。

6. 會拜年的還有一些網紅等公眾人物，而網紅在過年期間的成長是春節還沒開始就上升，跟藝人必須等到初一才上升是不一樣的狀況。

這些現像說真的不意外，但從數字更能佐證這些事情，下面的圖表來看就知道：

大眾媒體與分眾媒體都是在地震時成長最多，在春節時就開始下跌，而大眾媒體在春節有止跌的現像，但小型媒體大概都還在放假。

而分享粉絲團與內容農場也是在春節下跌，但在地震時沒有獲得流量。

政治人物某方面跟宗教信仰很接近，有趣的是最高的成長差了一天，春節也有時間差，但幾乎是相同的曲線。

網紅跟藝人也很接近，跟上面的政治人物不一樣的是無法在大事件獲得關注，但還是有所成長，而在春節倒是成長最多的，而這兩組圖也有些許不一樣，一個是在地震成長較多，一個是春節成長較多，一個是較早過春節，一個是要等到大年初一。

但若是要讓大家猜，春節過年這段期間成長最多的是那個，結果旅遊食材類並沒有很明鮮的高峰，真正最高峰的是下面這個，有高達 54% 的成長：

是的，就是 "宮廟" 類，表示民間信仰在這種節慶的確是一年的最熱的一段時間，只是相對的大部份的網路圈，這段時間是最暗淡的幾天，嗚~~~

從一例一休來看社群變化

2017-12-04T17:28:00.005+08:00

有人問我這次一例一休本來一開始民進黨如此的強勢, 但為甚麼如此呢?

記者對一例一休的文章數, 可以看到在 10 月之前有還是有在露出, 但在 10 月底才開始加碼...

主要是社群一開始沒甚麼熱度, 一直到 10 月底才開始...

即使是評論也是跟著按讚的熱度走, 但看得出來前期比讚少, 但後期比讚更多..

但從這邊看, 在新聞的留言是在 10/29 帶動整個氣氛, 這點不排除是網軍, 且這也是改變整個趨勢的領先指標....

那 10/29 或是 10/28 到底發生甚麼事呢?

但事實上在 11/22 之前民進黨還是很堅持自己的立場, 但在 11/23 號之後, 整個民進黨開始軟化與白熱化? 當然不是民意的關係.... 而是他們發現這樣的監持不是民意反彈很大, 而是原本無法收割民意的國民黨突然有人站出來, 而現在變成是民進黨的眼中釘, 像今天連上台都上不了台....

當然在新聞媒體下面的留言能不能成為領先指標, 畢竟這本來就是人民, 社群與網軍競爭的地方...

在上面的圖可以看到在 10/30 那天有 2838 個留言跟一例一修有關, 且獲得 7772 個 "讚" 同, 這數字是相當驚人的...

所以來看, 有時真正的人氣不是新聞, 而是留言下的按讚, 而這部份又不計算原本新聞裏面的社群訊號, 這對於輿情分析者更困難, 因為不只要分析粉絲團, 真正要分析的是新聞網站下的留言, 甚至是裏面的按讚與回應, 因為會被大眾注意到的開始與結果都在這邊, 而不是只靠粉絲團的讚享評而已, 這也是相當有趣的現像....

SEO 顧問前半年所須要做的事 Roadmap

2017-10-05T00:25:00.001+08:00

六年前之前，我只擔任 SEO 公司的 SEO 顧問，因為知道自己不是那種願意花時間去教化別人傳教士的個性，更沒有好的講師有的深入淺出能力，所以對於那些想要一步升天的公司，是敬謝不敏。但因為朋友的關係，勉為其難的接下第一份純 SEO 顧問的工作，雖然之後還是有不少家公司陸續找我，而我是更確信 "SEO 不只是 SEO"，認為這是一個須要系統功能，內容編輯，前端介面等等合作才會有好的成效的工作，而這幾年的實務經驗讓我更堅定這件事。

而之後我雖然接了十家以上的顧問，其中都包含 SEO 這部份，但我不會把自己設定成 SEO 顧問，因為我知道這工作若是沒有下去參與的顧問，執行，觀察，開工作，成效都很有限，畢竟網路有趣的地方雖然跟行銷不一樣，有人說行銷有一半是浪費的，最麻煩是你不知道是那一半，而 SEO 最有趣的地方是相信每做一件事都是對的，但成效有高有低，有快有慢，甚至最麻煩的你知道網站一定有錯的地方，而這些有時要抽絲撥繭的找出答案是須要工具，時間，甚至往往會在意想不到的過程找到問題解決點。

這些經驗累積下來，我也慢慢的摸索出一條路，也就是一個 Roadmap，也就是先後次序的階段，因為每一個公司的資源都是有限的，但 SEO 要做的事是成百上千件累積出來的，而至少在 SEO 的前期，如何先做最有效果的事，變成一件很重要的事，雖然不是說這些做完就好，因為我不認為有公司有須要或能夠投入那麼多資源做這些事，而做事順序就像是 80/20 法則一樣，先把最重要好做的 20% 先解決，而那些說不定就有 80% 的成效，會讓之後的 SEO 做得更輕鬆。

我會把 SEO 過程分為幾個階段：

階段零: HTML 語法優化
事實上因為我不像很多 SEO 講師能夠巨細彌遺的改善 HTML 的語法，所以有時都會建議他們去上課，或是用 SEO 的 On-Page Analysis 的工具找到自己的問題，雖然這些都是很基本，但也看過太多自以為都做好的人事實上還有太多的基本工沒做好，雖然以現在的觀點，依循著 HTML 5 的格式就已經差不多，或是大部份的分析工具都能夠找到不少該做的事，這些的爭議並不大，只要隨著許多書，課程來走，就很足夠。

階段一: 改正錯誤

除了 HTML 的錯誤外，最重要的是利用像 Search Console (Webmaster Tools) 以 Crawler 的角度來看網站的錯誤，無論是 SC (Search Console) 的 Crawler Error，或是 HTML Improvement (改善 HTML)，還以許多像 sitemap ，robots.txt，網址參數，結構化資料錯誤等等許多問題，這個通常都可以透過 SC 來獲得線索。

只是這只是線索，有些可以透過像 Crawler Error 的 Linked From 找到答案，但也有不少是沒辦法的，甚至有些沒有時間資料時要透過第三方程式來比對知道改善的地方或發生新錯誤的地方，尤於有些事不是做了就有效，包含 SC 的資料是三天前這問題，有時這個比 Runtime Error 的 Debug 還要困難說。

階段二: 優化 Meta-Data

通常會牽涉到使用者介面是最麻煩的，因為這須要更多的美術與前端參與，所以第二個階段是處理不會被 "使用者" 看到的在 Head 的 meta-data，這邊要處理的東西相當多，從最重要的 Tite 與 Description，以及一堆 Social Tag 如 Open Graph，Twitter Card 等，除外更有各種 Schema.org 與 Microformat ，還有 Json-LD 等等的資訊，這些都對 SEO 有很大的幫助，若是做好會有很大的成長，只是這些須要的是更多與內容，系統的相互配合，這個跟除錯一樣，都是須要很大的創意與基本知識，經驗配合。

階段三: 優化 Tag 頁 (非內容性的增加頁數)

網頁分成兩大類，一個是物件內容頁，與中間頁，這中間頁包含分類，索引，搜尋，等等的頁面，如何讓這些物件內容頁之間的連結關係更強化，須要的就是中間頁的製作，這也包含標籤頁等等的方式。但標籤頁不只是頁面，而更是之後能夠強化內容，語意，情境等等的基本工。

語意一直是 SEO 很重要的一環，若能夠透過人事時地物因果的標籤把內容聚合，串連，將會是在因為語意的強化關聯很重要的因子，因為中文不像英文一樣很容易切字，有時須要人工智慧與工人智慧的結合才能夠加深內容的價值。

階段四: 內部連結建立 (推薦閱讀)

在上一個階段提到去建立標籤，是為了增加內容頁，但更重要的是增加連結，雖然除了語意外，可以透過編輯的智慧，使用者行為的關聯分析等等來串接資訊，不要忘了，SEO 的真義是 "用對的內容與連結讓使用者去閱讀，點擊" ，這個基礎工夫是 SEO 的排名因子再怎麼調整與改變中，還是有不會變的因子。

當然若是用 Javascript 等外掛的連結，語意不相通的內容連結，一直改變的連結與內容是相當吃虧的，但建立完善的網頁連結是相當重要的，甚至能夠做到網頁之間的六度分隔，也就是任意兩個網頁只靠連結就可以在六次點擊點到，那就很好了，甚至從概念與使用者行為的網頁內容，更應該在三個點擊就可以做到就更好了，這甚至須要更好的麵包屑與資料探勘來做連結與預測。

當然上面四個階段是個大綱，還有更多的細節去注意，更多的工具去協助，以及編輯內容的參與才能夠做得更好。

而下面第五階段與之後呢？事實上還有很多，而並不是我有所保留，因為目前的經驗每一個媒體，每一個網站的安排都不盡相同，所以很難統整成可以建議的下面階段，但我相信前面的四到五個階段就足以做半年到一年了，就我的經驗，此時的搜尋流量就應該是幾倍的成長，你這個 SEO 顧問就應該足以被公司所認同了。

很多人寫這樣的文章是為了尋找更多的顧問機會，而我剛好是相反，我已經不太想接任何以 SEO 為前提的顧問工作，而是想辦法在 awoo 那邊培養幾個能夠交接我這個棒子的人，所以這篇有點像是種 "告別" 的完結，我還是想要更專心的開發工具，開發系統，因為有太多內容與 SEO 的基本工更須要去完成，尤其是中文，尤其是面對那些 "黑帽 SEOer"。

所以有這類 SEO 顧問須求的人請找 awoo，而要上課的人更是可以找像連啟佑等人，就我聽過他們的課與演講，這部份比我強不知幾倍，所以我還是偷偷的縮回技術層面去解決無法克服的疑難雜症，這對我的成就感是較大的。

八招教你如何辨識臉書詐騙

2017-06-17T01:19:00.001+08:00

我們都知道網路詐騙是一個很嚴重的問題, 不下於假新聞, 雖然這些事都不是在網路上獨特的社會現像, 因為在現實社會這些欺騙的事層出不窮, 但透過網路的高效率散播, 有時比現實社會來得嚴重.

在臉書投廣告, 大部份都是須要透過粉絲團來操作, 若是我們能夠 "定位" 這些詐騙粉絲團, 就能很清楚的判斷那些在網路購物是屬於欺騙成份較高? 當然這邊欺騙不見得是指 "完全" 的騙錢, 就像是一些旅遊團的購物行程那樣, 通常是指這些商品品質與價錢與外在真實存在著落差, 而有人從中獲取高額利潤...

透過粉絲團的追蹤, 有時可以知道很多事情, 若是能夠抓到大多數的 "詐騙" 粉絲團, 此時就會從 "談論人數" 知道有多少人在七天內對這些粉絲團 "傳訊", "分享", "按讚", "下訂", "打卡".. 等等之類的行為, 而這些人大概就是正在 "受騙" 進行式的人數.

在 "專頁儀表版" 中, 不到一個月就已經標示了有 187 個 "詐騙" 粉絲團, 但也因為這些粉絲團往往被很多人檢舉或負評時就用完即丟, 目前還有談論數在進行的還是有 118 個, 總談論人數有 90841, 這代表有七天內有接近 10 萬人有接受到這些訊息且進行 "動作/Making Stories", 這數字不能說很少.

而在收錄這樣的粉絲團時, 也大致可歸納出下面八點, 大部份可以輕易做出判斷:

1. 沒有在經營, 粉絲數都很少, 但談論數因為廣告的關係偏高
2. 不會在粉絲團揭露商品資訊
3. 價格多在 699~1899 的區間
4. 商品跟粉絲團屬性常不一致
5. 版型就那幾種, 都是一頁式網站
6. Favicon 也不超過三種
7. 網址都很奇怪, 沒意義, 或是夾雜
8. 過於強調貨到付款, 安心退貨

右邊的表就是目前談論數超過 10, 收錄在 "專頁儀表版" 的詐騙粉絲團, 可以看到這些粉絲團粉絲數都很少, 但透過廣告獲得很高的談論人數, 這代表著廣告是很有用的, 事實上他們都知道不須要太經營, 因為若被檢舉過多就會被臉書停權, 只是這過程有時須要兩三個月, 而這段時間就已經賺夠了.

這份列表可以在 "詐騙" 的選項看到這份清單, 當然這是靠我跟幾個朋友搜集來的, 遺漏的還是很多, 若有看到可以在最下面留訊息給我.

當然在未來這列表可以跟 "假新聞" 等等反制系統結合, 多少會降低上當的人, 只是這還須要更多功夫來完成.

附註: 當然這些都是靠 "工人智慧" 判斷, 雖然有極高的自信是對的, 但若被誤判的請快跟我們說...

為甚麼臉書談論數對粉絲團經營是重要的？

2017-05-15T00:25:00.000+08:00

我是不做 "Me,too" 的, 但我知道粉絲團經營最重要的共同指標, 一個是觸及數, 另一個是互動數, 但這數字只有經營者知道, 即使從洞察報告可以看到你加觀察的幾個粉絲團, 最近文章的互動狀況, 但還是離真的狀況有點距離, 除外粉絲團可以比較的就是 "談論數".

當然每一個粉絲團都不一樣, 電子商務最終的 KPI 是訂單(金額)轉換率, 而網站就是點擊數(率) 了, 但要比較, 共同點不是 "粉絲數", 因為這跟觸及數與互動數太遠了, 因為臉書的演算法會被觸及到的不是只加粉絲就可以了, 而是真的透過互動產生的效果.

因此我在之前也一直在找是否能夠有直接比較 "談論數" 的系統, 能夠知道真實的經營狀況, 而做為經營的參考, 很不幸的國外的一兩個不是台灣收錄的太少, 就是很多人不太管這部份.

但會讓我想做的原因不是這個, 而是因為真的要做 "部落格觀察" 或 "粉絲團觀察", 我知道除了用 "談論數" 來看經營, 另一個問題就是 "分類與聚焦", 也就是說除了要有一個即時真實的談論數來做比較, 精確的分類才是重點.

後來最後因為一個計劃的前置作業關係, 真的須要一個 "能夠透過粉絲團來看真實民意" 的公開計劃, 只好真的做下去了, 雖然表面上這 "又是一個" 別人已經做過類似的事, 但又是完全不一樣的事.

在之前先讓大家知道甚麼是談論數 (People Talking About This/Count):

PTAT: The number of unique people that created a story about your page or on your page in seven-day period.

翻譯就是: 七天內, 對你的粉絲頁或在你的粉絲頁, 產生事情的不重覆使用者數.

這些事情包含下面幾種, 我就不翻譯了:

like a page
post on the page wall
like a post
comment on a post
share a post
answer a question
RSVP to a page’s event
mention the page in a post
tag the page in a photo
check in at a place
share a check-in deal
like a check-in deal
write a recommendation
claim an offer

當然這是 2012 年五年前的資料, 現在的 "Stories" 可是更多種了, 而這數字為甚麼重要呢?

1. 這是七天內也就是即時的狀況，因此最適合做粉絲團經營的 Dashboard (儀表版)。
2. 這是公開的，任何人都可以直接看到這粉絲頁的談論數，不須要有任何權限。
3. 因為是每一個行為 (事情) 都算，且又是不重覆使用者，更可以看到真實的覆蓋率。
4. 不像粉絲數是可以一直累積，甚至是作假，由於這數字因為夠即時到很容易驗證為甚麼會有這結果，較難作假。
5. 一個互動的人若在七天內沒產生行為/事情就不算了，這更可以看到使用者的黏著度與忠誠度。
6. 因為這資訊是公開的，若是可以比較參考，你更可以知道這粉絲頁為甚麼有這樣的成果，然後跟你自己經營的做對照學習。

因此在這邊我做了一個簡單的系統, 透過標籤聚合粉絲團的共同與不同屬性標籤, 來看一些這個台灣發生了甚麼事.

就像是最新的資料:
社論泛藍 : Total TAT: 322030, Week TAT: 336161, TAT Change: -4.20%
社論泛綠 : Total TAT: 343320, Week TAT: 330305, TAT Change: 3.94%

你從上面這個數字就可以看到, 上週之前整個泛藍 (社論粉絲團) 氣勢是很高的, 但因為眾多因素, 讓整個翻轉過來, 你知道了這個, 就不會瞎子摸象不知道這個社會的氛圍或發生了甚麼事, 只要去看這屬性前面幾名的談論數, 為甚麼提高, 就可以了解原因, 離你如何運籌帷幄, 參與這社會就不遠了.

徐重仁的全聯事件社群觀察

2017-04-14T00:48:00.000+08:00

這邊是要定義為 "失言" 事件，要看把失言定義為：

1. 講了不該講的話。

2. 講了跟自己想法不一樣的話。

這邊的失言應該是比較向前者，只是這邊不該講的話是真實的還是錯的，已經有太多的討論，在這邊就不討論了，要看的是這次 "雙聯公關災難"，可以說是在台灣網路圈投下一個震憾彈，只是一個發生在台灣，一個發生在國外，受觀注的程度還是不一樣。

而其中最強的留言大概就是 "徐重仁" 親上火線回應，在不到 15 分鐘就破 300 個分享，不到一小時就破千了，真希望知道那時的觸及數是如何，但在無法知道的情型下，就幾個取樣時間來看社群反應的變化。

因為我們知道社群的數字是以指數的時間軸改變，所以因此就以 15 分鐘，30分鐘，一小時，兩小時，四小時，八小時的取樣來看這數字變化，在這邊就做成下表：

在這個表中，我們可以看到當然是前一兩小時分享量是增加最多的時候，而後面增加越來越少，甚至在這個減少速度倒是很平穩的在 1/1.2 往下降。但若我們不用時間軸的指數來看，的確是前 1~2 小時量是最多的，雖然第三小時沒有取樣，甚至可以說在前三小時就大勢底定了。

但這種事件的狀況是比較極端的，畢竟全聯小編在台灣是很被重視的，甚至可以引 @暗月之鏡的一段話:

因此小編是一個很難當的工作，因為幾乎是須要許多合縱連橫，對事情的發生要足夠敏感兼政治正確，尤其是找到點去讓大家認同（或稱帶風向），因為現在的社群時代不一樣了，這個不是那種用官大學問大來決定事情要如何想的社會，要真的講出合理的前因後果才能夠說服別人。

相較新聞而言，須要四到六小時的散播時間才會到社群，而這種小編的小圈圈，甚至是網路社群，三小時沒注意到就已經腿了 (Lag) 了，甚至有人也整理了表來看，沒有搶前兩小時的卡位，就不用玩了。（下圖取自商週粉絲團)

而新聞所影響的社群，下圖是用全聯，聯航，及徐重仁三個做比較：

從這邊可以看得出來，新聞真的須要六小時到半天來發酵，有時往往到晚上 10:00 or 11:00 時才會到最高 (每小時按讚數)。

雖然單則動態與新聞是如此的散播，但代表事情有這麼簡單結束嗎？事實上不然，因為這只是個開始，因為社群的評論即使到了一階段，二次創作才開始。

就像是上圖就是社群有關 "徐重仁" 這次事件為主軸的各種創作，現在才開始。

但拉回來我想用老貓的想法做個結尾：

畢竟這次的事件是從徐重仁失言開始，但我們若沒有認真的去思考，為甚麼會有這樣的事，就像我回答的：

但最麻煩的事, M型社會這類的事情也沒因為他的失言爆發的事件而有任何稍微積極的建言與政策提出, 這的確是我們該努力的...

更希望從這事，我們可以從社群，從這些 "長輩" 來獲得教訓，畢竟這個社會是屬於我們的責任，不該是任何個人來承擔的。

利用 Search Console w/ API 打造 Dashboard 儀表板

2017-03-15T05:03:00.002+08:00

網站經營最主要的是要知道流量怎麼來，以及要怎麼去 (轉換率)，而網站只是個中間的介面，讓事情能夠發生，雖然這個 "中間" 事實上是相當複雜的。

在流量的來源的分析中，現在幾乎是靠社群，廣告，與搜尋這三個主要來源，雖然說推薦 (Referral) 與電子郵件 (email) 不能說沒有價值，但相較之下還不如討論即時通訊 (Direct Message) 等不同社群觀點所創造流量反具有更多的未來性。

我一直認為用搜尋來導流是好事，其中有兩個大的原因:

1. 這是從使用者須求做出發的，不像是廣告有時的利基是創造使用者錯誤須求。

2. 這是從內容做出發，任何搜尋進來都是因為內容，內容才是最好表現與傳遞概念的方法。

但這不是我不喜歡用社群與廣告來導流，只是有時透過搜尋行為人才能夠找到真正所要的資訊與東西，雖然搜尋引擎有沒有做好，這又是另一個問題了。

因此網站經營很重要的一點，就是你要知道你網站有甚麼樣的內容，以及使用者是因為甚麼問題與情境進來，接下來就是網站是否有好的介面與導引，讓使用者找到對她有最好體驗的過程。

所以打造一個輕易有效了解網站內容，包含使用者體驗與流程，跟使用者是因為甚麼樣的原因進來的工具是很重要的，這也是 Dashboard 儀表版最重要的功能。

雖然 Google Analytics 一直是個很好的工具，但尤於 Real Time API 還是在 Beta 測試的階段，反而 Search Console API 變成最有效了解使用者為甚麼進來，甚至是更前面的知道有多少使用者在透過搜尋引擎嘗試著在搜尋找答案，以及使用者是怎進到網站與進到那一個頁面的工具。

而 Search Console 最大的唯一問題是時間性，也就是說資料都是三天前的，這在儀表版的角度是很糟糕的，因為儀表版有時最重要的功能就是能夠看到即時的資訊，做為讓我們判斷下一步該怎麼做的依據，而沒有即時性的 Real Time Data，是相當麻煩的。

但不否認的就很多網站經營者而言，也沒有那麼多時間去了解以及對使用者與網站狀況去做回應與回饋，有時這個週期是在一個星期到一個月就很了不起了，更不要說絕大多數的網站經營者都是蝦子摸象，甚至連 Search Console 的 Webmaster Tools 都沒認領過，使用過，知道這些資訊做判斷，大部份都是相信自己的直覺，這才是最糟糕的。

而有那些值得做為重要元素，是做為我們打造 Search Console 為基礎的 Dashboard 呢？

1. 搜尋流量：使用者透過搜尋點擊進來的流量，無論是一定時間內的數字（如 7 天或 28 天），以及這段時間的成長變化，這的確是最重要的 KPI。

2. 曝光數：隨著網站內容越來越多，搜尋引擎一定認為這網站越來越有價值，但是否真的有寫出使用者會搜尋的情境與關鍵字，也就是符合使用這的須求，來看曝光數以及變化，並搭配搜尋點擊數看其相關性，也就是點擊率，更可以知道是否打中須求。

3. 搜尋關鍵字的變化：通常品牌字往往是流量最多，但最不須要經營的，相較之下應該聚焦在那些字在成長，無論是曝光或點擊，甚至那些字雖然沒有點擊，而更是網站該經營的，雖然這資料是三天前，大部份都是已知，但也可以透過這檢核是否有遺漏或做為發想的基礎。

4. 標籤建議：透過 Search Console 最能夠化為實際行動的是在是否能夠做為方向，但寫新文章與開發新商品也並不簡單，若能透過新的字詞與文章產生的新關聯，適當的對舊內容下新的標籤而進一步給予新的生命，這是最直接的行動建議。

雖然這樣說很簡單，但有些資料源是須要開發，甚至儀表版本身就是一個很繁複可難可簡單的系統，即使說真的要非常合乎企業智慧 (Business Intelligence) 的使用還是要客製化的開發，但大部份的功能都是已經有相當成熟的須求與產品，這邊介紹兩套不錯的儀表版平台 (Platform) 給大家參考：

一個是 Google 自己出的 Data Studio，這套最大的好處就是已內建與 Google Search Console API 介接的功能，也就是拉一拉就可以了，而前兩項就可以輕易的拉出來相當合用的介面，甚至透過分享的功能可以當作公司內部給大家用的即時動態文件，下面就是一個我給 Spotlights 聚光平台用的儀表版：

雖然 Data Studio 是對的，但相對的沒辦法直接輕易的客製化，也就是資訊都要透過 Google Big Query， Google Doc，Google Storage，或是資料庫的串接才行，似乎沒辦法直接抓外部網頁的 JSON 或 CSV 來產生報表與圖，所以下面是一個叫 theDash 的範例，他可以直接套用我已經寫好的工具與 API，輕易的做出搜尋關鍵字變化的儀表版。

儀表版最重要的價值是盡量讓使用者不須要操作的情型下被動的看到，畢竟太多事情已經把工作時間壓得滿滿的，還要定期去看儀表板是很不切實際的，所以應該是在公司常經過的地方裝電視牆，讓所有人去檢核看到，畢竟一個人的時間與能力有限，大家一起注意不是更好嗎 ?

更重要的是，透過這樣的系統讓網站經營者更了解使用者的須求，有對的資訊才能夠做對的決策，對的行為，然後再用省下來的時間去發揮人真正的價值，創造新的文明，再把時間浪費在更美好的事物與創作上，這才是生命的價值。

評析行政院性平觀測系統

2017-03-10T16:57:00.002+08:00

又一個是乍看很漂亮, 功能很多, 資料也不少, 但完全沒有經營概念與基礎的網站, 為甚麼政府單位的網站都是這樣阿....

基本上要討論裏面內容的問題可能討論不完, 我先說以內容與經營相關 SEO 的角度來看這網站的問題:

[主要問題]

description: 無
canonical: 無
title 隨內容改變: 無
microdata: 無
sitemap: 無
tag/keyword: 無
html5 tag: 無
麵包屑 or Navigation: 無
Open Graph: 無

[次要問題]

ga 等 UX tracking: 無
API or Lined Data: !? (匯出圖表是 png 圖檔?)
AMP: 無
RWD: 無
mobile viewpoint: 無
WAI-ARIA: 無

[但至少有的]

shortcut (favicon): 有
h1 隨內容改變: 有 (部份)

幸好不是我顧問公司的作品, 不然就會被我退回重做, 這個幾乎是開不完的票等級了, 有時還真的覺得某一群人指導下做的網站雖然比起原本沒內容的政府網站已經好很多了, 但拿到以 "職業水準" 來看還是有一大段距離..

但上面的幾點, 我想很多政府網站會好一些, 只是這個網站內容不錯, 結構很糟, 相對的很多外包案都會有 "政府網站版型與內容管理規範" 所以會好一些, 倒是這個網站似乎走常規以外的開發路線, 所以內容不錯, 相對的該犯的錯都犯了....

當然, 會隨手拿來分析, 也是因為對這網站有所期許, 畢竟我不希望這些努力因為一些網站經營基本知識不夠而無法發揮原本推動者想要的目標與意義...

[編按] 圖都是取自於原網站: http://geo.ey.gov.tw/

從搜尋關鍵字來看使用者資料驅動介面設計 (User Data Driven UI Design)

2017-02-22T15:31:00.002+08:00

"SEO 的精髓是用對的文字內容連到對的網頁連結, 給對的使用者來去點擊而得到有用的答案"

通常會很習慣的把網站經營分成三個部份:

1. 內容: 包含新聞報導, 商品介紹, 討論等等內容媒質
2. 介面: 包含分類, 網站結構, 索引, 功能, 搜尋, 呈現, 等等, 讓內容給讀者看得到
3. 行為: 除了閱讀外, 包含行銷, 廣告宣傳, 互動, 等等, 促成使用者有動機去使用內容

而 SEO 雖然某方面只是屬於中間的介面, 但還是須要內容與外部的行為做導引, 也就是說, 在 SEO 的精髓, 媒合對的內容給對的使用者, 其中不只是內容驅動的導引, 更有使用者行為驅動的方法, 也就是 User-Data Drivent UI Redesign.

也就是了解使用者行為, 尤其是導流進來媒介與網站, 或者是之後透過對使用者的了解去做分析, 然後給與最好的導引, 無論有沒有影響所謂的 "Crawler/爬蟲", 但從使用者尋求資訊得到滿足方向去導引反倒是 SEO 現在最重視的事.

只是事情有那麼簡單嗎?

在 2011 年, Google 基於 "隱私權" 的理由, 把從搜尋結果頁的 HTTP 通訊協定的 Refer 經過一次的跳轉加密, 導致網站系統無法得知使用者是透過搜尋引擎是基於甚麼原因(搜尋關鍵字)而造訪這個網站/網頁, 這似乎看起來沒甚麼, 但這代表著經營者無從得知使用者為甚麼來這網站的動機, 更不用說能夠因使用者來這網站的 "情境" 給予不同的介面來最適使用者的須求.

即使扣掉這問題, 事實上問題還更多:

1. 並不是所有的網站有 Sitemap 或一個統整的資料庫可以找到所有的內容
2. 並不是所有的內容都有標籤或關鍵字, 能夠分析其重點
3. 並不是所有的網頁都有確實的裝上 Google Analytics, 或是很難統整

路是人走出來的, 問題不是拿來討論的, 而是要解決的, 而在 Data Mining 的部份, 我嘗試各種方式去建立關係:

1. 消費模式
2. 閱讀經歷
3. 標籤關係
4. 搜尋結果 (SERP)
5. 搜尋歷史
6. ....

等等方式, 只是這些都會面臨到一個問題: "須要建立資料庫與搜集資料", 這個或許對有實力的大家而言不是問題, 但對於小公司, 或者是大政府, 這困難度是相當高的, 所以我一直在想有甚麼可以取代這方法的....

而在去年時, Google Search Console API 終於釋出時, 我發現這是很不錯的出口, 因為:

1. 設定 (認領) Search Console 不須要埋碼, 可以用 GA, 檔案, Meta 以及 Domain Name 來授權, 其中網域對於政府機關相當有用.
2. 很多網站沒有好的 Sitemap, 而 GSC 做了最基本的 Index (索引), 甚至是肯定有效有意義可以導流的網頁.
3. 對於網站沒有編輯去定義標籤, 所以利用使用者的關鍵字幫忙做標籤定義, 尤其是可以是多種情境下的聯集.
4. 這資料雖然是有限, 但還是可以回溯 90 天, 所以更新週期可以降低, 且本來就不太須要耗資源去存與抓.
5. 這個關鍵字往往包含情境, 也就是若是用網頁與關鍵字的關係來建立距離(關係), 是一個很好的 Relation Analysis (關聯分析).

所以在過年期間利用時間實作出來, 然後經過幾次的演算法調整, 終於調到滿意的結果, 甚至有新的發現:

1. 因為這不是單從內容去做分析, 而是使用者搜尋點擊去分析, 所以更像是情境分析.
2. 因為這是搜尋曝光的聯結, 有時網頁會被移除會失效, 當使用者到了不存在的網頁時, 透過搜尋的歷史資料, 可以導到最有可能尋找的內容, 不再只是 404 回首頁.
3. 因為這是在 Google 的搜尋行為記錄的, 所以不須要額外搜集資料, 即使是新的網站, 認領授權後三天後也可以開始.
4. 因為是行為的關係, 這種標籤不再只是從作者與編輯觀點做出發, 更是由使用者出發, 所以更像是 User Data Driven 的 UI 設計.
5. 因為有了這樣的關鍵字資料庫, 可以進一步的做麵包屑, 甚至做自動產生的標籤系統.

像下面就是透過某 3C 網站跑出來的結果.

從這邊不只可以做內容推薦, 商品推薦.

誰說 Search Console 只是用來看 SEO 的, 事實上真正要做的是透過使用者行為來檢視文章的內容, 甚至是透過這樣的使用者資料, 做為進一步的 User Data Driven UI Design, 進一步的 "用對的文字內容連到對的網頁連結, 給對的使用者來去點擊而得到有用的答案", 這樣就可以提升 CTR, 透過內容與使用者的媒合讓網站更有價值.

因此, 在接下來 2017 年 SEO 的第 10 項重點, 就是透過 API 取得資料, 做為 User Data Driven 的 Redesign, 誰說 SEO 已死, 是那些人跟本沒抓到重點, 所以下一篇就是 "誰說 SEO 已死, 那些該死的黑帽手法本來就不應存在"......

延伸閱讀: 透過 Search Console API 來做關鍵字建議工具的改良

SEO 在 2017 的十項新趨勢與重點整理

2017-02-21T00:18:00.001+08:00

SEO 是一個很可怕的產業, 因為他的變化也太快了, MOZ 整理了一份表, 是在講 2016 SEO 的事件與變化, 單單列出來公開的事件就超過 30 個, 更不用說是沒公布的, 其中包括官方修改 (藍色), 併購的公司 (紅色), 官方文章宣布 (綠色), 專利權發布 (紫色) 與產品上市 (棕色).

去年寫了一篇 2016 的 29 項 SEO 重點, 而今年也順勢讀了幾十篇討論 2017 SEO 趨勢報告, 也順手整理一下, 而這次刻意把 2016 出現過的項目濾掉, 不然就會超過 40 項以上, 跟本不算是 "新趨勢" 的 "重點".

但有一家 AIM 請了 39 個從業人員投票出他們認為 2017 年後最重要的三個趨勢, 整理了一份排行榜, 我覺得很有趣, 大家可以看看大家的共同想法是甚麼:

這順序跟我想的相當接近, 雖然整理的方向有出入, 大家可以做為參考, 下面就是我去蕪存菁的整理:

1. AMP:
雖然說 AMP 在去年 (甚至前年) 就是一個很重要的項目, 但從 Search Console 特地把 AMP 的檢核錯誤拉出一大類, 到 SERP (搜尋結果頁) 也用 icon (標示) AMP 的項目, AMP 包含的內容不只是在手機, 也包含速度, 而慢慢確立這個項目應該不會曇花一現 (大概吧?).

2. SO.LO.MO
有人把 SO.LO.MO. 改成 SE.LO.MO, 但在我眼中, Search 與 Social, Local, Mobile 的結合是很難拿掉任和一項, 但也有人認為 Local (Googl My Business/GMB) 的問題蠻多的, 只是為了更多的流量, 也不能不去適應.

3. Redirect
現在已經有越來越多的 Redirect 去做轉址, 廣告等等, 只是這種 Redirect 3XX 有各自的意義與用途, 之前有人說盡量用 Permanent 而不要用 Temporary Redirect, 現在似乎價值已經不會差很多, 所以應該還是以自己的情境為主才是真確的.

4. Voice Search
語音搜尋已經越來越多這不用說了, 但真的認真的去對應語音輸入使用的語助詞, 用語, 甚至長尾關鍵字真的有在對應嗎? 這包含這問題的答案去打造網頁, 應該只要少數重視 SEO 的公司有工作小組或專案去討論與解決這事吧?

5. MicroFormat
從 Schema, 到 Rich-card 到 JSON-LD (Linked Data), 以及 Google 的 Instant Answer, 機讀的應用層面越來越廣, 已經不是之前用 RSS 去做 Sitemap 就夠了, 而是要用更多的 Meta-Data 去描述資料的使用, 也包含給搜尋引擎的爬蟲了解, 才能給 Google Brain 去計算阿, 以現在的觀點要真的去確認中文的自然語言語意還是有不夠完善的地方.

6. Search Experience
雖然說在 SERP 後的 After Search 說是不存在的, 但搜尋經驗的提升也包含這一塊, 計算使用者是否透過 SERP 找到答案, 做為提供最佳解的線索, 這種天經地義可以用的資料不用真的太對不起使用者了, 已經越來越多資料證明 Google 在做這事時, 系統即使不知道是甚麼原因進來, 至少知道是搜尋進來時, 不給予好的使用者經驗與線索提升 CTR, 不要跟我說你在做 SEO.

7. Related Keyword
雖然已經不用再說 Semantic Web (語意網路), 但關連的關鍵字從提供分類, 麵包屑, 文章推薦等等的指引已經是不可或缺, 在做內容時沒有想過這篇內容的 "語意", "情境", "對像", 以及後面的相關關鍵字, 說你能夠因此聚焦做使用者資料分析的再優化, 沒有這種基礎功打底我才不相信有做好.

8. Link Quality
連結相對還是很重要的, 此時配合著前一點, 就是說 "SEO 的精髓是用對的文字內容連到對的網頁連結, 給對的使用者來去點擊而得到有用的答案", 這代表的是 Link Quality 連結品質, 而能做出這樣有品質的連結, 有些是靠編輯的苦工, 有時靠的是 SEO 系統的成果才行.

9. Epic Content
永遠的內容為王, 做出值得傳頌的內容, 永遠是最好的行銷, 只是這個是可遇不可求, 唯一的做法就是真正了解問題所在, 對其解答持續不停的產生內容, 不知道內容如何賺寫或沒有經驗, 不知道其社群散播的路徑或知道其價值與衡量方法, 然後相互回饋寫出更好的內容, 這才是最重點阿....

10. 這邊就先保密, 因為寫這 9 點已經很累了, 就待下回分解吧.....

這篇文章主要的內容是取自於下面 G+ 書籤的這些文章心得, 有空的也可以去讀看看, 只是你會發現不重覆的點真的超過 40 點, 事實上真的想不開就來看 2016 的 29 項 SEO 重點, 因為這大部份的問題與該做的事都還是存在的, 只是更多與更重要, 誰說 SEO 已死了阿?

https://plus.google.com/u/0/+GeneHong/posts/3xVUQKqoeob

年營收 35 億美金的 Steam 如何再一次優化網站?

2017-01-08T20:09:00.004+08:00

在網站製作中, 我最推崇幾個網站:

1. IMDB: 在 Web 1.5 中, 實現使用者導向與內容技術最好的典範, 尤其是對 Keyword 在搜尋的應用, 更是早期的投入者.

2. Steam: 利用資料與功能來強化使用者體驗, 並真的以社群為導向的 "電子商務網站", 且真的是站在消費者這邊.

3. Milanoo: 對於產品分類與選項, 有其獨道之處, 尤其是 "聚焦" 在特殊產品是相當便利的使用者介面.

前一陣子看到 Steam 的改版, 雖然他們一直在改版, 但這次的改版更令我驚豔, 雖然我知道大家提到 Steam 都是聚焦在他們是個很獨特的 "數位內容" 消費網站, 但也因為這些是數位內容, 使用者經驗更是重要.

雖然我知道有不少人不知道甚麼是 Steam, 要介紹也介紹不完, 但大家只要知道, 即使是 Amazon 執電子商務牛耳, 但遇到遊戲產業的數位內容消費, 還是落後 Steam 一大截, 更不要說 Sony 的 PS Store 與 Microsoft 的 Xbox 商店, 當然硬是要說比 Steam 大的就是 Apple 的 Appstore 與 Google Play 有關遊戲部份, 雖然商品方向也不太一樣.

而 Steam 的網站設計有一個跟大部份網站不一樣的地方, 就是絕大多數的網站在努力簡化網站的流程與功能, 而 Steam Store 是反其道而行, 把網站的功能強大化, 來迎合玩家對尋找, 判斷, 購買遊戲的須求.

太多的電子商務網站, 想要做的就是一直推銷商品, 不太介意商品是不是真的消費者所要的, 只要賺到錢, 剩下的問題就是場商與產品的問題, 但 Steam 一直是想辦法讓玩家找到自己想要的遊戲, 所以大部份的電子商務網站 "個人化", "資料探勘(Data Mining)" 都是做假的, 通常只是聊備一格的裝飾品, 而 Steam 這部份倒是以這為重心.

所以這次 Steam 的改版, 更增強了一些功能:

1. 個人化介面: 選單可以自訂, 甚至廣告的內容可以自訂, 推薦的方式可以自訂, 幾乎可以打造屬於自己的 Steam 首頁了.

2. 個人行為輔助: 不只是前面提資料探勘結果的 "探索佇列", Steam 把買過的, 最近更新的, 沒興趣的, 不是 Highlight 提示或是過濾引藏, 讓 Wishlist 或相反的 No Interest 當作介面的強化, 不再只是種清單而已, 而那些最近瀏灠, 推薦早就是標準配備了.

3. 好友是最好的推銷員: 現在在首頁就可以看到好友在玩甚麼, 想買甚麼, 當然每一個商店頁本來就可以看到那些朋友想買或已經在玩, 這些都可以強化消費動機, 畢竟遊戲是一起玩是最好玩的.

4. 鑑賞家的強化: 以社群為中心的行銷, 當然不是用甚麼廣告代言人, 而是找出社群的意見領秀做領頭羊, 無論是推薦或是吐嘲, 一點也不避誨.

5. 即時的資訊: 有時會讓使用者更有意願留下來, 是提供無窮無盡有意義的資訊, 而 Infinite Scrooll (無限捲軸) 是一個最簡單的出發, 但更多的即時資訊的聚合有時才會讓使用者一直看, 一直看, 怎樣找出有意義的即時資訊給使用者, 無論是好友或是個人等等所觸發, 都須要規劃者認真去思索.

當然做這麼多, 最困難的不只是把這些功能做出來, 而是在完全不攜牲速度的前提下, 這不只是對技術須求有很高的挑戰, 而是真的認真思考 "可行性" 分析這件事, 尤其是大部份網站的功能須求, 都是由行銷所提出, 而技術端無法找到一個方法去達到 "使用者體驗" 優化的標準, 而 Steam 有很多小細節對技術人員都是很好的參考, 每一項設計都是相當有趣的.

雖然 Steam 的網站開發也曾發生過災難, 例如曾經開放使用者下標籤, 但沒有去聚焦而過於發散後失去意義, 但或許 Steam 是個社群網站, 很快的就調整腳步去改善, 因此可以證明 Steam 並沒有失去創新的精神, 只是這過程能夠更好, 幾乎是每一個網站經營管理開發者須要一起學習的.

只是台灣應該沒有一個電子商務網站有做到 35 億美金, 但透過 Steam 的經驗, 或許能夠讓我們學習, 即使有些是很難複製的, 但我相信透過使用者導向, 資料導向的優化與設計, 先行者給我的啟發就很有意義了.

網址: http://store.steampowered.com/about/newstore2016/

我的 2016 年記....

2017-01-08T17:54:00.002+08:00

若我們的見面是以年為單位的話, 下次你見到我時問 "你最近過得如何?", 或許用這篇可以跟你講我 2016 年整體而言過得如何? 也就是我在 2016 年最值得題的 10 件事:

1. 新文易數

從 2014 年末寫到現在, 新文易數一直在改版, 2016 年嚴格說是改版較少的一年, 但遇到 Facebook API 一直 "改變", 很多 API 不能用得情形也得一直修改, 由其是針對 "正負向" 的計算, 到依人物, 議題一起比較的排行榜, 甚至比較媒體在社群的表現, 多少還是有點進展, 只是經營過網站的人就知道一件事: "維護一個系統是相當不容易的".

2. 未來國會, 未來新聞, 未來政論

而在 2015 年底時打造了一個 "未來國會" 這樣的平台, 覺得相當有價值, 因此很想繼續做類似的事情, 因此嘗試用相同的模式再次創造 "未來新聞" 這平台, 雖然已經做出成果, 但最後還是被腰斬沒有公開 (果然辦公室政治很複雜), 雖然因此情續低潮了好幾個月, 而再打起精神做 "未來政論" 這計劃, 而這計劃還在執行中, 希望能夠做出對社會有意義的東西.. (事實上也是自己想用啦~~)

3. 工作的開始與結束

因為同時在很多公司上班 (累~~), 雖然有一半都很穩定, 但相對的有一半是不穩定的, 有幾個是做三年五年以上, 甚至是快 10 年 (9年) 的, 但也有一個是不到一年就被腰斬的 (這很少見), 最後是有兩到三個工作在 2016 年結束, 一個是從 2014 年的姊妹淘, 一個是做不到一年的風傳媒, 但也因此開始了關鍵評論網的旅程, 也獲得了很大的成果.

4. 遊戲: Pokemon Go, Civ6, Clickers Hero, Royal Clash

遊戲一直是很好浪費時間的美好事情之一, 2016 的年度大作 "文明帝國六" 是不可能漏掉的精神時光之屋, 而 Pokemon Go 能說是讓 "走路" 增加情趣的遊戲, Clickers Hero 是填空無聊時間的最佳遊戲, Royal Clash 是能夠在 3~5 分鐘決定有好心情好轉或持續低落的真槍實彈, 雖然很想否認, 但這部份花掉的時間是有一定的比例.

6. Netflix

另一個 "浪費時間與生命的美好事物" 比例的就是電影與音樂, 2016 最大的改變就是 Netflix 終於到台灣了, 也因此多看了一堆美劇與少量的電影, 當然雖然有 Hinet-MOD 與 Spotify, 但相對的豐富度還是有段距離, 在此推薦朋友 Netflix, 把第四台剪掉吧.....

7. 台灣輕旅行

旅行的時間總是可遇不可求, 大概是在連續假期時才比較有機會吧, 2016 年出遊了三次, 去了關西 (小叮噹), 花蓮, 及滿洲跟埔里, 而本來有一次想再去花蓮, 想要騎機車在山間的感覺, 但後來颱風來攪局只好放棄了.

8. 騎腳踏車

若是說今年有甚麼不一樣的, 大概就是騎腳踏車吧, 因為沒機會方便的打桌球之後, 就只好換個項目運動, 幸好有 Ubike, 河濱公園的夜騎一直是很愜意的, 雖然沒有真的建立成為好習慣, 但也騎到淡水過一次, 感覺相當不錯, 希望 2017 能夠增加頻率阿....

9. Hackathons, Workshops, Speech, Lessons

除了工作外, 去參加黑客松或 Workshop, 偶而客串當評審或講者, 一直是讓常常會有低潮的我有點翻轉的機會, 但還是一如往常的, 不會得獎是一定的, 雖然這不會是我的重點, 重點是 "吃喝玩樂" 吧.....

10. 科展, 電腦

在之前曾經想要帶著小孩來趟 "圖書館之旅", 來到各個圖書館走走, 但畢竟小孩比我還忙, 偶而抽空帶他去咖啡店走走說不定機會較高, 最後是因為科展的關係, 就用 "Live Demo" 的方式導引大兒子寫程式, 居然最後有不錯的成績, 也確定的確電腦是不用教的, 是用 "做" 的.

除了上面 10 點外, 的確有遺珠之憾, 例如今年是換手機的一年 (因為上隻手機也用三年多), 但先換到 Samsung Tab S 受不了還是換回 Sony Z3 Tablet, 陪小孩聽演奏會或聽他的演奏會, 只是 2016 相較前幾年次數較少, 本來還有個 "實況" 的一年, 就是投入實況投票與實況監看的開發, 只是相較前面無論就影響或時間都是較少.

我相信這些項目這幾年下來, 有其變, 也有其不變, 這也是人生阿....

meta tag, 決定 SEO 的 25 項標準與通訊協定系列 XV

2016-12-30T23:20:00.002+08:00

在 Head 中, 理論上只有幾個 tag:

1. titlte

2. style

3. base

4. link

5. meta

6. script

7. noscript

這 7 個 tag 要去描述接下來真正被讀者看到, 除外都是被瀏灠器呈現 (Render) 的本體 (Body), 而 Body 有超過一百個 tag 來去 Markup 出內容, 但這幾個 head 的 tag, 說不重要是因為讀者看不到, 沒寫也沒關係, 但事實上當你考慮到 SEO 時, 又完全不是這麼一回事了.

我都說以 SEO 結構的觀點, 最重要的項目是:

1. Domain Name 網域

2. Directory 目錄

3. URL 網址

4. Title 標題

5. Description 描述

6. H1 Head1

7. 其他

當然通常第 1 項網域的改變與新增是大事, 通常網頁在討論與考慮的, 在網址之外就是標題與描述了, 而標題在 HTML Tag 中就是 head 的 title, 那緊次於這些的 "描述" 呢? 這描述就躲在 meta 裏面.

所以這個 meta 到底重不重要呢? 基本上有在用 Search Console (原本叫 Webmaster Tools) 的人知道, 都會有一個 HTML 錯誤與改善, 其中有一個就是針對描述, 也就是 meta 這個 description 的 property 的使用, 若是沒有或是太短, 就是 SEO 很糟糕的事.

事實上不只 SERP (Search Engine Result Page) 有時也會使用 Description 做為網址標題後的描述, 這往往是決定讀者會不會點進的關鍵, 而後面更不用說更不用說了, 其他的 JSON-LD (ld+json) 等等的事都是排在後面附加想要加分的項目, 有時再怎樣也不會比 title 與 description 重要.

在前面幾個也提到, 在 head 裏面可以做許多事:

1. 宣告 robots 如何讀取, 也是 meta 的一種

2. Open Graph 都是用 meta

3. RSS 也是種 link alternative

4. AMP 也是靠 head 來去宣告

5. Sitemap 也是個 link

6. JSON-LD 是種 script

7. Google News Crawler 也有自己的 meta, 如 news-keywords

8. Breadcrumb 也是可以定義在 JSON-LD 中

當然雖然不完全都是靠 meta 來做定義, 但這邊就可以看到 head 的重要性與 meta 這個 tag 的重要性, 但也如同我上一篇說的, 這些標準與協定, 幾乎是沒有獨立存在的, 幾乎是共同架構出這個網頁, 網站, 知識庫的.

我是很想排出重要的 meta element 的....

1. description

2. robots 相關

3. charset 與

4. content 與 http-equiv

5. viewport (RWD 後)

6. Social Card/Graph (twiiter, facebook 之後)

7. 新聞使用

8. 作者與時間

9. 其他 schema

上面有那些是你還沒加到呢?

Breadcrumb, 決定 SEO 的 25 項標準與通訊協定系列 XIV

2016-12-29T23:14:00.002+08:00

Breadcrumb in schema: https://schema.org/breadcrumb
Breadcrumb in WebSchema: https://www.w3.org/wiki/WebSchemas/Breadcrumbs
Breadcrumb in WAI: https://www.w3.org/WAI/tutorials/menus/multiple-ways/
Breadcrumb in WHATWG: https://html.spec.whatwg.org/multipage/scripting.html#rel-up
Breadcrumb in HTML5: https://developer.mozilla.org/en/docs/Web/HTML/Element/nav

事實上這一系列講到這邊已經錯縱複雜了, 就像是 JSON-LD 是架構在 Linked Data 上, Linked Data 上是須要在 Microdata (Schema) 定義, WAI 也是用這些去建立起來, 而這些都是基於在 HTML (HTML5) 上, 而這些又須要 HTTP 的通訊協定才能運作, 說是已經寫成白紙黑字的標準, 有時能夠運作也是架構在許多的可能性與乎略很多複雜度才能實作的.

前一篇談到 Linked Data, 也講到 JSON-LD 是種實作, 而上面又有 LDP (Linked Data Platform) 與 JSON-LD API 的發展, 這些完全是必要知道的, 但說說跟 SEO 有很大的相關, 多少也是強說愁, 因為有那些內容與型式, 甚至是經營跟 SEO 是無關的呢?

但這邊想從 Schema, W3C, WAI, WHATWG 等等的實作中, 拉出一個很重要的概念, 就是 Breadcrumb (麵包屑), 以及所屬的 Navigation / Menu 等等的概念.

在現在的 SEO 角度來看, 能夠讓使用者繼續看下去的網站就是好的網站, 因為太多的網站都是看一頁就離開, 不是因為已經獲得解答, 而是無法獲得資訊的網站, 能夠讓使用者更進一步的得到他想要的資訊, 也就是一個網頁若能夠有好的 CTR (Click through Rate), 往往代表這個網站的價值較高, 因此對 SEO 是很好的訊號 (Signal) 或因素 (Metics).

而一個網站可以分成主要兩種頁面, 一個是內容頁, 一個是中間頁, 而中間頁包含:

1. 首頁
2. 分類頁
3. 搜尋頁
4. 標籤頁
5. 功能頁

而這些頁面的交互關係, 靠得就是連結, 而這個產生連結的方式有很多種, 就 HTML5 的角度定義了幾種:

1. Header
2. Navigation (nav)
3. Sidebar (aside)
4. foooter
5. section

以及真正的 article, 而其中的 Navigation 就是包含 menu, catalogue, breadcrumb 等等的方式, 而較具有跟這頁有直接關係可以看得出來的就是麵包屑, 麵包屑是可以清楚讓使用者知道這網頁所在的位置, 與上下層關係, 甚至是路逕.

當時的 Practice 是建議用這三種方式去實作:

而在 HTML5 之後, 麵包屑無論是用甚麼方式呈現, 都要用 <nav> 將之包起來, 像下面那樣..

在 WAI 中, 更希望加入 role, class 與 aria-label, 如下:

事實上在 Schema 與 JSON-LD 的實作下, 也該是如此:

看到這邊, 大家會不會覺得一個簡單的麵包屑, 居然如此的博大精深, 真的到處都存在, 因為事實上在 SERP 中, 已經早就導入這概念, 包含前面說的 News 的 Section.

這系列講的是 SEO 與標準的關係, 就講到這邊, 但事實上麵包屑是相當重要的事, 無論就 Semantic Web, 就 Data Mining, 就 Tag (標籤), 分類的角度, 都有不同的思維, 但說穿了這些都是為了建立知識, 讓資訊串起來, 只要是人在做資訊獲取 (Information Retrievaling), 這件事永遠跑不掉.

Linked (Open) Data, 決定 SEO 的 25 項標準與通訊協定系列 IIVX

2016-12-28T23:56:00.000+08:00

Linked Data: http://linkeddata.org/

我們常常把資料給複製&貼上, 只是也在想, 若這些複製貼上不是只有內容, 而是導引成一個可以串接起來的資料時, 當源頭修改時, 後面的資料也是否可以同步修正呢?

Linked Data 的概念就是就透過 URIs (Uniform Resource Identifier) 與 RDF (Resource Description Framework) 的實作, 把資料給 "Linked (串接)" 起來, 讓資料變成資訊, 讓資訊變成知識的可能性, 也就是之前提到 Google 一直在推的, Knowledge Graph.

在 JSON-LD 中, 只是說把 Linked Data 用 JSON 包起來, 而後讓搜尋引擎的 Crawler 更容易知道這是甚麼樣的結構化資料 (Structured Data), 這資料透過 Schema.org (Microdata) 包含描述與使用, 也是因為透過這樣的共通定義, 讓資料再利用得以實現, 進一步的建立知識.

的確透過這樣的方式, 我們可以追溯知識的起源與結果, 但在還沒有實現 "Knowledge is the One" 時, Linked Data 是用各式各樣的 Datasets 去描述, 在上面的圖都有看到,其中也包含較知名的:

1. DBpedia: 將 Wikipedia 的資料 Linked Data 化
2. FOAF: 描述人語人之間的關係
3. GeoNames: 地理名稱
4. UMBEL: 透過 Web Ontology Language 建立最基本人工智慧須要的 Semantic Web.

只是大家看到這邊, 的確 Linked Data 很偉大, 但跟 SEO 的關係為何呢? 誠實說, 我也只是猜測, 尤其是 Knowledge Graph 這塊.

雖然不否認的 Knowledge Graph 現在是一個呈現在 SERP (搜尋引擎結果頁) 的欄位, 但由於有其連結, 一定會帶入流量, 雖然這些 Knowledge Graph 幾乎是被知名的網站所占據位子, 不是因為那些網站真的導入 Linked Data, 而是蠻多是 Google 刻意打造出來的, 但若網站本身就提供 Linked Data 時, 不否認的 Google 未來會引用的機會蠻高.

只是拉回來, 這個所謂的 Linked Data 跟之前的 Trackback 多少也是有關係的, 甚至這個還導出 seealso 及 breadcrumb 種種的 Protocol, 而能夠把資訊串連, 而這個 "連結" 也是 SEO 一個很重要的基礎不是嗎?

所以在之前, 還是先把 JSON-LD 做好, 甚至的嘗試著做 Linked Data Platform, 或許對網站的架構會更完善, 這就明天再說了...

AMP, 決定 SEO 的 25 項標準與通訊協定系列 XII

2016-12-27T23:51:00.002+08:00

AMP Project: https://www.ampproject.org/

這在某種角度又是一個很 Hacking 的通訊協定, 甚至有時連 "標準" 都談不上, 就像是 Facebook 的 Instant Article 一樣, 雖然說是種大家一起遵守的東西, 甚至是有實用性, 但在某方面又是種為了保持優勢的大公司企圖.

雖然從很早開始, "Speed" 網站速度就是決定網站 "價值" 的一件事, 因為速度夠快, 才能夠被搜尋引擎 Crawler 抓取的夠快, 索引 Index 的夠多, 當然對 SEO 的幫助是正面的, 因此網站讀取速度一直是被做為很大的因子 Metics.

而 AMP (Accelerated Mobile Pages) 雖然是為了手機加速的通訊協定, 但現在已經有足夠多的使用者要去更嚴肅的面對, 尤其是手機的讀取往往代表的就是通訊速度不夠快, 下載時間較久, CPU 也不夠好, 執行時間也被拉長, 因此的確須要有一個能夠讓手機加速讀取的方式, 這就是 AMP.

也因為這是 Google 主導的, 因此在 Search Console (原 Webmaster) 中, AMP 是很重要的一環, 有了 AMP 頁, 一定在行動裝置的搜尋占有優勢, 但予其這樣說, 加快網頁速度的確不完全只是為了 "SEO", 這是一個內容為王, 使用者體驗為后的狀況, 沒有好的使用者體驗, 王就會失去價值.

在 Search Console 已經有足夠完善的文件與 Validation 驗證的工具與錯誤檢核的機制, 這邊不太須要說, 但該討論的是, 在 AMP 做的時候, 我們還能夠思考甚麼?

的確在前端這概念雖然推出沒多久, 但這困難度與重要度就足以把這工作項目區分出來, 就是前端(工程師), AMP 雖然也是個前端, 但思考的方式跟很多前端不一樣, 即使也是有很多是一樣的, 尤其是一個最麻煩的衝突點:

使用者體驗 > 開發者體驗 > 易於開發

現在的前端有太多的 Framework, 這些架構都是為了加速開發, 且有更不錯的體驗, 只是這個體驗有時會使用太多的記憶體與 CPU 的資源, 雖然這些也都會降低使用者體驗, 但大部份的開發者與讀者有時會太著重炫麗的表現, 而沒有注意到是否有太多讀者並沒有真的提高使用者體驗.

但不得不否認的, AMP 到底是個過渡性的協定與標準, 還是以後會持續下去, 我個人是不看好, 但有些概念的確是好的, 可以做為參考, 但有些是的確會被淘汰的, 就像是上面那個衝突點, 這是沒有絕對的對錯, 但你要知道你自己在甚麼樣的角度去做這事情.

只是現在, 為了使用者, 真的要去考慮到速度, 所以用這個角度來看, AMP 是相當重要, 真的要去認真面對的事, 甚至手機版就是要用這角度去開發, 即使只有這三年, 但, 你的網站難道在三年後還會繼續使用原本的版型嗎? 所以這一點也不算是做白工.

前九個協定/標準統整介紹, 決定 SEO 的 25 項標準與通訊協定系列 XI

2016-12-26T23:26:00.000+08:00

在開始寫時, 就在想一個有趣的問題:

我還有時間寫嗎?

現在我手上有 N 個工作, 重點是有一個大計劃, 除外還有很多小計劃把我的時間瓜分掉, 所以答案應該是 "沒有時間寫", 但此時要換一個問題:

我還須要成長與反思嗎?

這答案是肯定的, 因為這樣重新壓擠自己的時間去延伸閱讀, 思考到反芻, 就前幾次的經驗證明我每寫一次就在這議題有更進一步的感受.

而我一直覺得台灣缺少的就是這類的 Open Document, Open Practice 的 Working Group 去認真的討論, 實踐, 每次都是個案, 每次都是見招拆招, 每次都是很片斷的淺短評論, 有多少人真的去踏實的去實作, 去系統化的解決問題?

回頭來看我須要學習的東西太多了, 無論是 Search Engine Optimization, Open Data, Data Mining, ... 雖然說穿了都是 Data, 但我知道我的基礎工還是不夠, 須要一直不斷的學習, 但在於時間不夠的情況下, 或許把整個 Data Science 的 Scope 縮到最小, 就是 SEO, 因此, "決定未來 SEO 的 25 項標準與通訊協定系列" 就這樣子出來了.

在想即使寫得不夠好, 但至少當成是自己的 Roadmap, 也給初學者一個 Roadmap 或許或多或少對自己, 對大家有點幫助.

目前已經寫的是下面九篇文章:

JSON-LD: 更輕易的描寫網頁的 Schema

WAI-ARIA: 定義出對行動障礙者的網頁互動

Open Graph: 讓網頁被社群網站所使用

Site Maps: 讓搜尋引擎更好知道如何索引網站

RSS: 讓網站被其他機器讀取時間, 標題與大綱

Robots.txt: 避免搜尋引擎索引到不該讀取的網頁

Author: 讓網頁有作者宣告, 而建立作者的威信

Trackback: 讓網頁知道被其他的網頁所使用, 提及

Google News Sitemap: 讓 Google 的新聞爬蟲更精確抓取

這些協定與標準, 是透過許多 Working Group 所製定出來的, 包含 W3C, Google, Facebook 或其他單一組織, 從這些標準制定的過程與背後, 可以看到許多的思維, 即使有些是很商業的導向, 但也是架構在 "須求" 的角度去出發, 才能獲得共鳴, 協定與標準才能產生意義, 就像是我多的, IC 能夠再利用不是封裝的概念 (Encapsultion) 而已, 而是必須大家共同使用一本 IC Book 才行, 知道 7400 的 Nand 腳位是如何安排, 才能組合這些資訊的運作, 發揮效用.

SEO 多少也是須要這樣, 管理一個網站也是須要這樣, 經營一間公司更不用說, 治理一個國家更也須要這樣的概念, 建立系統, 建立制度, 建立標準, 建立溝通管道, 建立工作模式, 建立連接格式, ... 有這樣的 Standard 與 protocol, 才可能會有 Open Goverment, Open Social, Open Business, .....

不知道這九篇對大家有沒有幫助, 聽說很多人覺得看了之後還是更看不懂, 這可以肯定不是大家的問題, 而是我的問題, 畢竟我的文筆很糟也不是一天兩天了, 即使有人覺得我一篇這樣跟本寫不到一千字, 跟我平常就寫出兩三千字差很多, 雖然我不否認有可能是江郎才盡, 但主要也是要趕在 12 :00 前寫完真的是有點辛苦.

只是現在面臨一個問題就是接下來與 SEO 相關的協定與標準, 不是過大不然就是關聯度不高, 不然就是很難寫, 來試試看想接下來還能寫的有那些題目:

1. HTML Logical Tags
2. HTML5 New Tags
3. HTTP Error Code
4. AMP
5. Instant Article (Social Signal)
6. Link Data (Knowledge Graph)
7. Twitter Card and Other Social Signal
8. JSLD-API
9. Schema.org
10. .........

現在已經不像以前可以找資料一面唸個兩三小時, 再來花一個小時去寫了, 從找資料到寫出來可能要在半個小時到一個小時之內, 這些題目的挑戰已經過於巨大, 畢竟我不是為了寫而寫, 而是為了自我學習而寫, 雖然知道無法跟前幾屆那樣寫得精彩已成事實, 而明天大家能不能看到我的文章, 我現在也沒有把握, 只能說, Have Fun~~~~

Google News Sitemap, 決定 SEO 的 25 項標準與通訊協定系列 X

2016-12-25T23:00:00.003+08:00

Sitemap News: http://www.google.com/schemas/sitemap-news/0.9/sitemap-news.xsd

這個 XML 的 Namespace 可能對大部份的人都不重要, 除非是對新聞網站, 因為這個 Sitemap 出現的結果不是在一般搜尋, 而是新聞搜尋....

為甚麼對大多數人都不重要呢? 因為要被 Google 認定是新聞網站是要經過申請的, 而這申請相當不容易, 台灣也只有幾十個網站被認為是新聞網站 (事實上也是這麼多而已), 所以也只有這些網站做得到.

若申請成功的話, 的確有很多事情要做:

1. Google News Crawler 有專屬的 sitemap

2. metadata 也有專屬的 name, 其中包含 news-keywords

3. 在 Publisher Center 設定分類

4. 在 Publisher Center 設定編輯嚴選之類的, 包含 App

5. 之後在 Search Console 可以看到 News Crawler 的錯誤

而這個 News Sitemap 的專屬 Tag 也沒有多少個:

1. publication: (name, language)

2. access

3. genres

4. publication_date

5. title

6. keyword

7. stock_tickers

這些都是寫在 sitemap 的, 也是去 search console 去 submit, 然後 crawler 就會自動抓了, 但這都不是問題, 問題是出的問題 (繞口令?), 也就是 Crawler Error 的如何解決, 常用的問題有這三種:

1. Article too long

2. Article too short

3. Fragmented Article

但這邊就不詳細解釋要如何解決問題了, 雖然大部份就可以去查 Google 那些有說跟沒有說一樣的官方說法.

只是拉回來要問的是, 真的有人在用 Google News Search 嗎? 當然這邊指的 News Crawler 會出現在 Google News 上面, 甚至在一般的 SERP 因為偶而會有一個欄位是給新聞使用, 而這個是保證在第一頁的, 說不重要還是很重要, 因此還是要想辦法解決 Sitemap News 的 Error 與 News Crawler 的 Error, ...

畢竟沒有人嫌流量太多的, 不是嗎?

TrackBack, 決定 SEO 的 25 項標準與通訊協定系列 IX

2016-12-24T20:55:00.000+08:00

MovableType: https://movabletype.org/documentation/trackback/specification.html

今晚是聖誕夜, 雖然想要早點寫完來看 Netflix 在 Sense8 拍的聖誕夜特輯, 但也要先寫完才放心, 但既然今晚是聖誕夜, 就來寫三個聖誕夜鬼魂的故事, LinkBack...

看過 "Christmas Carol/小氣財神" 的人應該都知道這故事, 雖然你不見得是看狄更森 (Dickens) 的原著, 但經過無數多次的改編, 很多人都知道這三個陰魂不散的鬼魂一直敲著我們, 一直連在我們背後 (Link Back).

這個 Linkback 有三個標準 (或加一):

1. Tackback (Ping), 由 Six Apart 所提出, 透過 HTTP Post 直接發出.
2. Pingback, 透過 XML-RPC 的格式發出 Back Link Ping.
3. Webmention, 由 W3C 所提出, 透過 HTTP POST 再加上認證的機制

這個 LinkBack 是個很好的東西, 是將資料的源頭串接起來, 在論文的觀點就是 "Reference/參考", 當然有時只是種延伸, 當有人寫出一篇不錯的文章, 就會有人想要回應, 而當然後面寫的人可以加註來源或網址, 就可以往前回去看, 但有了 TrackBack 這種機制, 就可以知道後面或前面的人是怎麼提及, 怎麼寫的, 此時就可以加上來源, 讓資訊能夠更流通, 讀者可以更了解全貌, 事實得已檢驗.

但為甚麼後來就沒人用呢? 當然就是那群萬惡的黑帽 SEOer.....

Google 計算網站價值, 最初用的就是 PageRank (PR) 這概念, 也就是 Reference 的觀點, 一個網站被提及或連結越多次, 這網站就越有價值, 而 Trackback 在 Blogging 時的效果就是你在你的文章提到一個網頁時, 系統就會自動或半自動發出 Trackback 的訊息給原網站知道, 原網站就可以建立一個連結連到後來寫的網站.

這種 Link Building 連結建立很快的就立刻被黑帽所使用, 發出大量不是真的 "引用" 來建立大量的外連, 最後大部份的系統在不受其擾的情形下關掉 Trackback, 而這協定也因為沒人再用就這樣死亡了.

雖然有人提出加入一些更嚴謹的回頭檢驗的機制, Pingback 相較之下比 Trackback 更不容易被 Spam, 但這種 LinkBack 機制已經被很多人恐懼較少使用, 最後實務上還是用得人不多.

此時 W3C 就接手了, 在 Social Web Working Group 的運作下, 在今年一月 12 日提出一個草案, 透過能夠 Verification (確認) 的機制來證明, 再加上 Vouch 做為 anti-spam 的機制, 應該就會好很多了, 但因為目前還是太新, 真的開發出來用得還是不多, 這能不能夠有效就看未來了.

那還有一個加一的 LinkBack 呢? 這個是透過瀏灠者的瀏灠器, 將上一頁閱讀的網頁回傳回去, 雖然這個幾乎是沒有人不實作, 但現在因為 Google 把 Search 的 Referral 全部跳轉後, 已經無法知道讀者是因為搜尋甚麼進來, 因此這個 Linkback 雖然沒有死, 但也是半殘了....

嗯, 今晚的耶誕夜不知道大家過得如何呢? 希望 SEOer 能夠更多愛一點讀者, 多愛一點網站, 不要再做虛假的事, 讓這個社會能夠更有意義的運作, 然後, Merry Xmas....... 希望接下來的耶誕節 "未來" 鬼魂是我們期望看到的...., 不要跟我一樣把 "未來" 拿掉了.

PingBack: http://www.hixie.ch/specs/pingback/pingback
Wemention: https://www.w3.org/TR/2016/WD-webmention-20160112/

Author, 決定 SEO 的 25 項標準與通訊協定系列 IIX

2016-12-23T23:43:00.000+08:00

Rel-Author in MicroFormats: http://microformats.org/wiki/rel-author

應該有人發現本來這個系列是叫 "決定未來 SEO 的 25 項標準與通訊協定系列", 但 "未來" 這兩個字被偷偷拿掉了, 因為若是真的要全部寫正在進行的未來, 可能就我的能力還是不夠, 且我發現還是不少人對 "基礎" 不夠, 因此就改了題目.

原本除了這個題目之外, 本來是想寫有關 Web 的 Authorship 的問題, 尤其現在這網路, 最大的問題之一是假新聞充斥的狀況, 因此也是考慮寫一系列的文章, 但這題目也是太難, 或者是跟技術關聯不大, 因此也就放棄.

但話說我還是想把有關 Author, News 等等的真實性機制做點強調, 因此就來討論有關 "Author" 的這個概念.

在目前現行運作的格式中, 有兩個有關 Author 的用法:

<meta name="author" content="Hege Refsnes">
<a href="http://erin.example.com/" rel="author">Erin Smith</a>

一個是放在 Head, 一個是放在 Body, 一個是講現在的網頁, 一個是講連過去的網頁, 放在 Head 自然不會有任何作用, 但放在 Link 就不一樣, 只是事實上瀏灠器也沒有針對這部份做特別的呈現 (Render).

既然不會被看到, 就不會有人刻意會去用, 但 Google 在 2011~2014 年曾經為了推 Google+ 做為 Profile 時, 有推過 Rel-Author 出現在 SERP (Search Engine Result Page) 中, 如下圖:

但後來就沒有努力推了, 這或許是最大的問題, 但為了打擊假新聞, 這個 Authorship 的概念會不會被再提及, 應該機會很高..

雖然這個 Author 因為 Knowledge Graph 的關係有出現在 SERP 上, 但這個對大部份的 SEO 是一個相當困難的挑戰, 而幾乎是 "個人品牌" 的經營了.

只是未來這個 Author 會在 SEO 會扮演甚麼樣的角色, 讓我們拭目以待.

圖源: https://moz.com/blog/will-google-bring-back-google-authorship
圖源: https://contentequalsmoney.com/rel-author-and-publisher/

Robots.txt, 決定 SEO 的 25 項標準與通訊協定系列 VII

2016-12-22T22:39:00.000+08:00

網站: http://www.robotstxt.org/

Robots.txt 或許是最早製定給搜尋引擎用的 Protocol, 若不算 ODP (Open Directory Project) 這個不算協定的東西, 這從 1994 年就開始, 也就是肯定跟 Google 無關的東西 (終於~~)

Robots Exclusion Standard 主要是為了排除機器人的爬蟲爬到不該爬的資料所設計, 所以是以 "排除" 做設計, 但裏面只有兩個主要的 item:

1. User-Agent: 刻意指那個搜尋引擎
2. Disallow: 排除那些目錄與網址

除外還有些沒有成為標準的項目:

3. Craw-Delay: 希望幾秒再來抓下一個網頁
4. Allow: 予許那些目錄與檔案, 在某些觀點很像 sitemap
5. Sitemap: 說明 sitemap 放在那, 這之前說過
6. Host: 建議使用那個網域

但這些都是為了搜尋引擎設記的, 對於會遵循的搜尋引擎自然不是問題, 但有些中國的搜尋引擎是不太管這些標準的.

在網站而言, robots.txt 是基本的, 至少對 Google 是有效的, 但這有時很難精確到每一個網頁對搜尋引擎以不同的控制, 因此就有了 name 為 robots 的 metadata, 像 Google 甚至有更多控制的選項, 以及對不同 Crawler 的方式, 如:

<meta name="googlebot" content="noindex">
<meta name="googlebot-news" content="nosnippet">

除了 robots.txt 以及 meta data 外, 事實上也可以透過 HTTP 的 Header 來傳遞資訊, 例如:

X-Robots-Tag: noindex

這部份的選項更多了, 如下圖:

不得否認的 Robots.txt 雖然是基本, 但也是可有可無, 因為這算是進階的控制, 而對於沒有注意到的人, 影響不大, 但對於想要進一步排除與控制搜尋引擎的人這是相當重要的, 但這要小心, 因為我曾看過有人不小心把 meta data 就設成 robots noindex, 然後就發生整個網站不被搜錄的慘劇 (不要笑, 我知道是你).

RSS, 決定 SEO 的 25 項標準與通訊協定系列 VI

2016-12-21T23:43:00.000+08:00

最新 RSS (?) : http://www.rssboard.org/rss-2-0-1

上一篇講到 Sitemap 現在觀點已經不是一個好的 Protocol/Format, 因為現在網站已經太大, 或者是搜尋引擎已經夠好了, 所以須要的是補足搜尋引擎的不足, 也就是 "提示/Notification" 搜尋引擎新的內容就可以.

而的確 sitemap 的四種方式其中一項也是透過類似 ping/submit 的方式去告訴搜尋引擎有那些內容是新的, 或是修改過的, 但這項功能已經被黑帽 SEOer 玩壞了, 現在搜尋引擎不只限制數量, 甚至有時也沒用了, 這也是 SEO 的悲哀之一.

因此 sitemap 沒有時間戳記, 而在 1999 到 2001 年的時候, 有一個標準被制定, 就是 RSS, 從 RSS 0.9X, RSS 1.X, RSS2.X 等等, 這個跟很多協定不一樣, RSS 的版本有時是獨立的東西, 甚至不完全向下相容, 所以到最後都獨立存在, 而 RSS 有一個最大的用途, 就是 Notification.

RSS 可以是 Rich Site Summary, 也可以是 RDF Site Summary, 更可以是 Really Simple Sydication, 就可以知道這是一個以實用為主的實作, 來去定義 "Feed" 這個格式, 最主要的是為了當時的 Blog (部落格) 開發出來的, 但現在已經包含新聞, 頭條, 影片, 語音等等的內容.

因為這個 "Feed" 的概念, 很合適做為搜尋引擎或相關 Crawler (爬蟲) 做為索引的依據, 所以很快的變成 Sitemap 可以用的格式之一, 且經過幾年的發展, 也有一支獨立成 ATOM, 雖然 RSS 也 Extened (延伸) 了不少內容.

下表就是 RSS 與 ATOM 主要的差異, 也多少看到包含的內容.

其中 RSS 原本只是必要 title, link, description, 之後延伸出 language, copyright, managingEditor, webMaster, pubDate, lastBuildDate, category, generator, docs, cloud, ttl, image, rating, textInput, skipHours, skipDays 等等的 Element.

且 RSS 是架構在 XML 上面的, 因此除了最常 "Enhance" 上去的 dc (Dublin Core), 要加甚麼 NameSpace 都不是問題, 所以後來最有名的 FeedBurner, 也有了自己的格式, 而 FB (FeedBurner) 被買走之後, Google 也在上面加了給廣告, 新聞等等的元素.

因為 RSS 有時間戳記, 就真的可以給搜尋引擎很大的線索去 Indexing 索引網站, 所以有時我都建議使用 RSS 做 Sitemap 比用 sitemaps 這格式更有效率與意義.

只是在台灣, 真的認真用 RSS 的人真的不多, 尤其是在利用其他元素來做資訊, 例如縮圖, 分類, 都很少人實作, 然後最有趣的我還看過某家媒體還很認真的把 pubDate 用中文表示

難道他們不知道 RSS 的目的是用來 Machine Readable, 因此要遵循 RFC 822 嗎?

或許部落格 (Blog) 已不再是未來發展的重點, RSS 也隨著使用人越來越少淡出舞台, 但或許 SEO 的存在, 讓 RSS 還是有延續的空間因素之一.