2017年3月15日 星期三

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

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

在流量的來源的分析中,現在幾乎是靠社群,廣告,與搜尋這三個主要來源,雖然說推薦 (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年3月10日 星期五

評析行政院性平觀測系統

又一個是乍看很漂亮, 功能很多, 資料也不少, 但完全沒有經營概念與基礎的網站, 為甚麼政府單位的網站都是這樣阿....
基本上要討論裏面內容的問題可能討論不完, 我先說以內容與經營相關 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/

2017年2月22日 星期三

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

"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 來做關鍵字建議工具的改良

2017年2月21日 星期二

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

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


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

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

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

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

2017年1月8日 星期日

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

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

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 年記....

若我們的見面是以年為單位的話, 下次你見到我時問 "你最近過得如何?", 或許用這篇可以跟你講我 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 相較前幾年次數較少, 本來還有個 "實況" 的一年, 就是投入實況投票與實況監看的開發, 只是相較前面無論就影響或時間都是較少.

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

2016年12月30日 星期五

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

在 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

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

2016年12月29日 星期四

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

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), 這件事永遠跑不掉.

LinkWithin

Related Posts Plugin for WordPress, Blogger...

熱門文章