關於 Google Analytics 「不得追蹤單一個體」的誤解？

昨天 Google Analytics 把 Universal Analytics 送進公測，我終於有機會到處看看。新的 Measurement Protocol 要求每個 Request 都要送個 Unique-id 給 GA，以便辨識是同一人（使用 Web 版或行動 SDK 的人，程式會自己幫你搞定這一點，一切都跟以前一樣），因此我覺得或許我以前誤解了 Google「不得識別單一個體」的條文。後來看 Universal Analytics 的資料找到這條：

You will not upload any data that allows Google to personally identify an individual (such as certain names, social security numbers, email addresses, or any similar data), or data that permanently identifies a particular device (such as a mobile phone’s unique device identifier if such an identifier cannot be reset), even in hashed form.

「您不可以上傳任何能讓 Google 識別特定個人（如姓名、身分證字號、電子郵件地址等）或特定設備（例如手機上無法更動的唯一設備號碼）的資料，即使雜湊過也不行。」

這好像跟我原本的認知就已經不同了，畢竟他很強調「不可讓 Google 識別」，而不是不可讓我識別。於是又回頭看服務條款：

You will not (and will not allow any third party to) use the Service to track, collect or upload any data that personally identifies an individual (such as a name, email address or billing information), or other data which can be reasonably linked to such information by Google.

「您不可（亦不能授意第三方）使用此服務追蹤、搜集、上傳任何可用以識別單一個人的資料（如姓名、電子郵件地址、賬單資訊等），或其他可由 Google 合理連結此等資訊的資料。」

好像仍然只是在強調不可以陷 Google 於不義。也就是說，依照此兩條解釋，其實如果我自己為使用者定一個 ID（例如 35009a79-1a05-49d7-b876-2b884d），然後設定 Custom Value 去追這個 ID，並不違反 Google 的條款。因為只有我自己才可能知道 35009a79-1a05-49d7-b876-2b884d0f825b 是誰，Google 無從得知，除非他駭進我後台系統，或者我笨笨的在前台就把這個 ID 跟前述使用者個人資料連在一起。

菁英政治

從 Open Source 界不願承認的九件事一文中，引一段有意思的：

More often, though, it is heavily qualified. In many projects, documentation writers or artists are less influential than programmers. Often, who you know can influence whether your contributions are accepted as much as the actually quality of your work.

Similarly, the famous are more likely to influence decision-making than the rank and file, regardless of what they have done recently. People like Mark Shuttleworth or corporations like Google can buy their way to influence. Community projects can find their governing bodies dominated by their corporate sponsors, as has usually been the case with Fedora. Although meritocracy is the ideal, it is almost never the sole practice.

不敢說自己看得很多，不過以上大部份都正確。很久以前，我記得聽人說過 Open Source 的環境是菁英政治而非純然民主；Mitchell Baker 也曾說過 Mozilla 的文化上應該是 Earned authority；或說我自己在關於社群式管理的心得隨筆也描述過在程式碼上貢獻與應允者間的關係往來。

「打馬碼的最大」是這類社群的常見現象，我們也經常低估文件、繪圖者的貢獻程度。這有點像一間公司獨尊業務的作法，只有有「營收產出」的能拿到最豐碩的果實，而忽略其他人在輔助支援上的努力。這點應該是我們致力改善的，如果都像 TonyQ 一樣把視覺設計視為心中的神或許不壞 :P

有名的人也確實比較有影響力，不過這沒什麼不好。以瞎透舞姿先生來說，他的「有名」其來有自，必然也經過了許多努力而生 -- 生下來就有名的人不多見，在這個社群內更不太發生，而無論他做了什麼、也都會對他後續的影響力產生影響。又，在每個環境裡的「有名」，也不見得會能夠被帶到另一個環境裡。如果在商普界知名的 Mr. xxxxx 們來談 Open Source，我們應該會請他講中文。因此這份「有名」事實上也是 earned authority 的代表，而我們也不愛單純由 given 而來的權力。

至於贊助商主宰，嗯，慣於用資源而非道理來控制人的群體充斥我們周圍，我自己仍然會記得即使是這些人也仍是「社群」的一份子，也代表著部份的聲音，應獲得一定尊重（說到底資源的贊助也屬於一種貢獻啊）；又，不喜歡原也不必勉強，你總可以選擇自己不被那些勢力左右，就開個分支或離開吧。

是以，我還是抱持樂觀的態度看這些缺失。會向著更好的地方去，中途的曲折只是必然要來的墊背。

[免費課程] 網站分析入門 - 給 FLOSS 志工社群網站管理員的網站分析

tl;dr: 2013/2/16 一整天，有免費的網站分析課程，歡迎報名。（請先參考本文最後面的報名資格）

---

我一直覺得網站分析很重要，但直到進入網路行銷公司之前，倒沒有很認真去看待這門學問。MozTW 早早就裝了 Google Analytics，也設定了追蹤下載量的程式，然後呢？我們知道每個月都有很多人上 moztw.org 下載  Firefox，所以呢？

「網站分析」在從前對我們而言，似乎就是網站的心電圖 － 放上去、會動，那我的網站沒問題，完工！

不過代誌不是我想的那麼簡單，深入探究才發現，網站分析其實可以提供一些問題的答案或線索，作為輔助調整網站的利器：

• 幫助你精確思考網站的目的，以及「勝利條件」
• 訪客進入你的網站，到底想做什麼？
• 網站中的哪一頁，對於達成目標最有價值？
• 又，哪些頁面可能有問題，需要調整？
• 你的網站該前進 mobile 了嗎？
• 放在別人網站的連結，到底有沒有用？

FLOSS 的志工夥伴平常看很多技術性文件、上開發軟體的課程，不過「網站分析」甚少落入我們的眼簾。趁著與公司 GG 閒在家的機會，這次我與 OSSF 合作，開設「給 FLOSS 志工社群網站管理員的網站分析」入門課程，希望在提升社群網站品質部份有點小小貢獻。

• 時間：2013.02.16  09:00-17:00
• 地點：Changee Coke

我們將以 Google Analytics 為工具，課程內容預定包括：

• 設定 Google Analytics、埋設基本追蹤碼
• 重新思考網站目標，定義網站目標
• 重要數據與報表說明，如 Visits vs. Pageview、Bounce、Conversion、Traffic source 等等
• 區隔，與進階區隔
• 自訂報表、Dashboard
• 自動信件通知設定
• 設計多網站分析結構
• 權限設定
• 其他我突然覺得很重要的東西（炸）

小弟在 FLOSS 社群裡從來不（也無法）以技術能力走天下，因此可以想見這門課程不需要太深的技術能力，適合推薦你社群中熱心幫忙、但非技術人的夥伴參加。所有需要的科技知識（Cookies、Referral、Domain & Sub-domain、基礎 RegExp...），我都會試圖在課程裡解釋。

感謝 OSSF 鼎力支援，這樣的課程將完全免費 -- 當然，市場上也有其他網站分析的課程，而為了讓該給 FLOSS 社群的資源能妥善利用，我針對報名者資格做了點限制：

Update: 我們應該還有名額讓不符下列條件的朋友報名，所以無論如何還是歡迎填個資料。

1. 參與者應該擁有任一 FLOSS 志工社群網站的管理權限
• 網站需與 FLOSS 志工社群相關，開放規格的語言（Python、JavaScript）亦可、研討會 ok
• 如果您是拿薪水來協助管理 FLOSS 志工社群網站，那請找坊間的課程來上。我個人推薦喬后的課，作為我在知世的好同事，她在網站分析這門學問上也更專業。
2. 或者，任何擁有條件 1 資格的人，願意幫你背書、按你的要求調整網站
3. 又或者，你已經擁有任一 FLOSS 志工社群網站的 Google Analytics（或其他分析工具）的管理權限
4. 場地沒有電腦，歡迎自備上網設備
• 非 100% 必要，但有實際看會比較好
• 又，用手機會看得爆炸辛苦，建議至少是平板，筆電還是最好的

如果你符合這樣的條件，歡迎填寫這份表單，我們在確定後會發給你 OSSF 報名 VIP 碼協助你報名。

填寫報名申請表

願力無邊但名額有限，所以有興趣的夥伴馬上報名吧 :D 隨附我在 WebConf 2013 講的「網站分析？我小時候以為自己會」簡報，供參考。

網站分析 我小的時候以為自己會 from Bob Chao

關於 COSCUP 參與人員的雜記

前幾天聽說，有人覺得我在 COSCUP 就是不斷把 MozTW 的人帶進去。

這確實是我 2010 以前在做的事情，畢竟 MozTW 很多（絕大部分吧，哈）核心成員都不是技術人員，他們能對 Open Source 世界最好的貢獻，其中一項就是在這些不需要技術底的領域服務。不過至少我突然很好奇：那麼幾年以來，掛上 MozTW 名稱的決策參與者有多少，有怎樣的變化？最重要是，我有沒有偏袒什麼？

先定義「決策參與者」，雖然 COSCUP 一直都把絕大部分的決策攤給全體工作人員出意見，但我會傾向覺得所有「組長」職、場務組的「小組長」職，以及議程委員會的成員屬於研討會裡比較該先計算的決策參與者。做事的人最大，而組長一般也是最勞心的；議程委員會會決定整體議程的走向，不可說不重要。雖然一定漏了很多因素，但這樣的想法應該還算可以接受。

由於手上沒有組員資料，先算組長吧；網站上只有 2011、2012 的組長資料，我連同今年的一起計算後，比例大概是 30.7%、20% 及今年的 33%，我每年都減少 1~2 個組的決定讓比例比較高一點，不過去年倒是只有 20%（意外地少，我自己是沒注意）。

好像不算太偏袒，但倒是意外發現一個問題：「名字後面不掛社群品牌」的組長比例，前年是 30.77%、去年是 60%、今年估計應該是 40%（我也不會掛），這樣的比例似乎有點讓人擔心。我的疑惑是，這些不掛社群品牌的人，是因為認同 Open Source 所以來辦活動，還是單純因為喜歡辦活動的氛圍所以參加？

希望是因為認同，不然 COSCUP 的演變就是專業研討會活動公司了，這樣不好。

看可以來做點什麼。

結果就到了 2013

2011 年沒寫回顧，但現在倒是有很多時間可以寫 2012 的。作為一個自稱「活在網路上」的人，要寫回顧這種東西總不缺素材，就挑幾件事情，也當作整理一下自己。

婚

2012 年有很多同學結婚了，從新年第一天的史丹利到年尾的阿之；這其實可以預期，畢竟我們都不小了。「柏強，我們已經不年輕了」我總是會想起昱維的話，雖然死命地賴在 20 幾歲的圈子裡沒有離開。

有合的，也有分的，無論如何希望都過得安好。

跟同學好像總是不太「親密」，不敢拿什麼君子之交淡如水來當藉口，我似乎必然是這樣疏離 -- 不過心裡大大小小總是有留你們一個位子，所以會希望儘量參與你們的婚宴。儘量啦。

旅行

如果要把去中華人民共和國管轄區域也當作出國的話，2012 年居然出訪了五次。公司的事情居多，去了深圳、香港、上海、新加坡，年中也跟女友去了京阪神。

雖然除了香港之外都是沒去過的地方，不過要說最有記憶，果然還是單純去玩的日本行最豐富，也繼荷蘭村之行後又走訪了真正稱得上「主題樂園」的環球影城。

今年大概不會這麼常離開臺灣了，但仍希望排趟迪士尼體驗一下。本島旅行的部分居然只有最後的跨年花蓮遊啊... 是我的錯。

學習

我一直知道自己該好好學統計，因為個性上必然會往以數據支援決策的方向去，卻總沒有實行。在知世的時光，阿亮把喬后排在我隔壁，應該是一個改變想法的關鍵。我終於開始好好面對數據、趨勢以及各種似是而非的論點。

考完了 Google 分析的認證，順利過關，終於開始也只是個開始。我小時候以為自己會網站分析，現在不敢說會了 -- 稍稍懂一點。這部份希望今年可以再繼續加強。

下半年開始接觸免費的線上課程 Coursera，紮紮實實上了一堂 Gamification 的課程，也難得地每段影片、每次報告從不缺席。對於這個字詞，總算是有比較系統化的了解。

今年讀的書大致上都偏向上述兩個方面，到 Anobii 上查了一下發現數目上是過去數年來的最少。「這就怪了，我記得我常常在看書啊？」後來發現最後兩個月狂看的九把刀書籍都沒登記上去，一記上去就變成 2x 本了。

接下來我想念點關鍵字廣告的書（為什麼這麼看來好像又要回網路廣告業的樣子 XD），以及終於應該再撿起來的，統計學。

工作與社群

目前是出社會後第一段待業中的時間，休息一陣。（有興趣的朋友，我的履歷請見邊欄。）

雖然離開知世進 Mozilla 後還是做了一大堆網站企劃、SEO、網站分析的事情（那個，我真的是掛社群經理），不過因為大大小小的原因，倒是少去 HPX 跟 UIGathering 了。我的興趣還在、書也還看，倒是不怕斷了聯繫。（瞧我非常快的又連了起來。）

一整年最大條的事情，大概就是成為 COSCUP 這個千人大拜拜的總招，有些想法累積到現在也終於看得更清楚、想得更完整了一些。志工社群有其驚人的魅力與「有機發展」的活力，單純拿錢做事的人要看見這些，或許還是難，而聖杯看來也還遠著。

今年的 COSCUP 又是絕無僅有的挑戰，如在 Facebook 上所說，「我頭洗下去了，能不能全身而退就看各位了。」大部份的情況下，我喜歡這種把自己交給大家的感覺，用這樣的風險要換那樣的成果，應該值得吧？

另外

嗯，結果還是走到這裡，我覺得我不對的成份居多，謝謝。去年初的「什麼都新」或許就是為了現在的「什麼都無」鋪路。或許這樣就是最好的結果，也希望（借用我的離職信）我們都向著更好的地方去。

---

或許終於也接近欲說還休的年紀？乘興而來，興盡而歸，於是就此停筆。

HTTPS 的 referrer 狀況筆記

很快筆記一下，周三去聽喬后演講時，她講了個我從前不知道的事：HTTPS 的網站連向 HTTP 網站時，瀏覽器不會送 referrer。以目前大部份網站都沒用 SSL 的情況來說，這會讓分析時高估直接流量（自以為有很多人加入書籤？XD）、且可能低估某些來源的威力。剛巧又有人貼了 Search Engine Land 的文章，說 iOS 6 因為預設搜尋引擎與 Firefox 相同，都轉往 SSL Search，所以就不送 referrer 了。如此推算，被低估的部份就變成自然搜尋，但這是網站健康程度的指標之一，雖然重要性就看個人，但若有需求該怎麼解決？

那就測試一下吧！Dropbox 的空間可以用 SSL 存取，所以我做了個簡單的網頁來顯示 referrer，想等 Google 去索引此網頁後再來測試搜尋。但，後來想到更快的方法：Facebook 也是 HTTPS 吧？那就從 Facebook 去連這個檔案就好。

• 原始網址 https://dl.dropbox.com/u/3280872/referrer.htm
• Facebook proxy link (from HTTPS) https://www.facebook.com/l.php?u=https%3A%2F%2Fdl.dropbox.com%2Fu%2F3280872%2Freferrer.htm&h=YAQH98kqz

好，所以事實證明，若 HTTPS 網站轉進另一個 HTTPS 網站時，還是會送 referrer。所以，如果想避開這種狀況帶來的影響，讓自己的網站也採用 HTTPS 就好了。花錢能解決的事情都是簡單，接下來的問題只在值不值得花。

不過現在大部份網站並不採用 HTTPS，那按理說會造成一部份的自然搜尋來源蒸發現象。但以我可以看到分析資料的網站而言，在 Firefox 預設改用 SSL Search 後，這種事情卻沒有發生，難道這代表 Firefox 的使用量已經低到無法撼動任何東西了嗎？ XD

這倒也不是。其實 Facebook 等網站或許因為廣告等需求，就算你用 HTTPS 連，他的 proxy link 仍採用 HTTP 未加密連線。也就是說

1. 你使用 HTTPS 來連 Facebook，並點擊一個看到的對外連結
2. 這個對外連結會先跳到 HTTP 連線的 proxy link：以我的測試網站來說，就是 http://www.facebook.com/l.php?u=https%3A%2F%2Fdl.dropbox.com%2Fu%2F3280872%2Freferrer.htm&h=YAQH98kqz
3. 這樣正式連過去另一個站的時候，對方無論是否採 HTTPS 連線，仍可收到來自 facebook.com 的 referrer

實際上 Google 也是如此，即使你採用 SSL Search，按照 Search Engine Land 的方法到 whatismyreferer 測試，對方也能正確顯示你從 Google 來。因為 Google 也用 proxy link 當跳板，然後這張跳板也刻意僅用 HTTP 連線。這是 Firefox 採用 SSL Search後，在數據上沒有造成任何影響的原因。

最後一個問題 - 那為什麼 iOS6 採用 SSL Search 後，搜尋上會造成這種影響？從剛剛的各種線索推算，答案就簡單了：因為 Google 行動版的行為不同。Google 行動版雖然也用 proxy link 來計算點擊數，但這個 proxy link 卻採用 HTTPS 連線，所以瀏覽器發現連線對象是 HTTP 網站時，也就很快樂地把  referrer 擋下來了。你可以用 Firefox for Android 搜尋 whatismyreferer 後，長按搜尋結果連結來證實此點。

喔，這樣才是置入性行銷啊 :)

COSCUP 2012 - 改變與檢討 (1) 交誼廳、Workshop、接駁車

檢討的部份或許檢討會上可以再補充，先列一些我們嘗試的改變，並提一些個人的看法 -- 如同沒有人能夠代表社群一般，即使作為 COSCUP 2012 的總召，我仍沒有意思在這裡代表整個籌辦團隊發言。以下的紀錄，或可說是分享，但更多其實是為以後的自己記錄。為免富奸上身，寫幾點我就貼一篇，就算真的上身了至少還有產出...

取消交誼廳議程

除了行政部份「一切從簡、降低負擔」這種與會者看不見的變化之外（之後會討論，不富奸的話），取消交誼廳議程或許是最早決定的改變，源自於 COSCUP 裡有幾年的「交誼廳其實不適合放議程」爭議。去年已經稍有改變，在第二天改以 Unconference 的方式進行而只預排了一天議程，今年我跟議程組長打開始就希望讓交誼廳回到「交誼」性質，讓想休息的人有個地方可以去。

實際狀況裡，或許因為宣傳不力、或者在中研院的場地裡空一間出來隨便大家搞仍是新機制，總之「交誼」的效果似乎不佳。又，今年 COSCUP 很幸運的逃過颱風，而且居然一滴雨也沒下，於是交誼廳當然也不會有以前發生過的積水問題。這倒無損我認為應該尋求別的方式來消化場地總人數的想法。

說「場地總人數」，因為中研院人文館單論座位，其實無論如何是無法容納上千人的會議。取消交誼廳會讓這個問題更嚴重，所以一方面第二天仍有 Unconference，二方面我們需要多一些東西來幫忙消化人，這就是下一項「Workshop」。總地來說，取消交誼廳議程其實並不那麼不可行，以中研院的場地對照單日會眾人數近千人但有兩百左右在會議室外（工作人員、攤位人員)來說，塞一下還是進得去的。

增加 Workshop

因應取消交誼廳，我們搬出了另一個很久以前也討論過的東西：Workshop。在以前的討論裡，是希望舉辦 Workshop 將 COSCUP 變成一個三天的研討會：第一天是 Workshop，接著兩天是原本 COSCUP 研討會型式的會議，今年既然是要處理人數問題，那自然就是一起辦。

在原來的規劃上，COSCUP 主辦團隊只負責場地，與最基本的電力與網路協助，其他在這三小時裡要搞什麼，就全部交給審核通過的社群搞。某種程度上，你或許也可以把它視為外包給某個社群的議程區段 -- 事實上 JuluOSDev 的方式，就很像理想中的狀況，也確實吸引很多聽眾。不過由於第一次辦，分工上沒討論清楚讓大家忙得團團轉，有了這次的經驗，下次再明白定一下分工（大聲地說出「COSCUP 只負責場地，報到及現場其他工作人員等請自行處理或另外提出需求）應該可以跑得很順。

「Workshop 主辦人是否具備講師資格」也是一項爭議，我的定義裡是不算：這三小時基本上就是讓接手的社群自己決定要怎麼搞，你可以像 Fire.app 一樣就是一個講師從頭到尾，也可以像 Julu OS 一樣一堆人輪番上陣；或者可以是一個人主講、另一堆人協助與會者動手做，也當然可以就直接作為相互討論特定主題的園地、只有協助秩序的「主持」而沒有講師。由於型式太多樣，我們也不願多做限制，那相對來講就不將「COSCUP 講師」資格賦予講者。我們看到 Julu OS 自己額外做了 T-shirt 鼓勵分享者，是很好的範例。或許下次雖然 Workshop 講者仍不直接賦與 COSCUP 講師相關回饋，但可提供主辦社群定額 VIP 及兩個講者晚宴出席名額，可以平衡一下，也避免「Workshop 講師比較不重要」的誤會 -- 單純是因為定義不同而已。

不過為了確保 Workshop 人數，先前採獨立招生的方式讓我們吃了點苦頭，最後的決定「讓 Workshop 參與者同時擁有 COSCUP 入場資格」也有不少意見。如果再來一次，我想我會選擇回到「讓 Workshop 跟 COSCUP 報名完全脫勾」的想法，並且在市區另開戰場、於周五舉辦。這個想法優劣並存，讓下一屆的人去評估得失吧。以前的 Workshop 討論裡，其實還有「Workshop 就獨立收費」的想法存在過，不過不在這次的考量中，就不多談。

這是我們第一次辦 Workshop，招待不週請多包涵，也歡迎留下你的想法、甚至搶先表達明年當工作人員的意願 :P

取消去程接駁車

很多人以為這次 COSCUP 取消一大堆東西是因為經費不足，其實反而是先為了要節省資源降低負擔，才決定多所限制。這包括設立工作人員員額制度（很神奇吧，想當 COSCUP 志工也會有名額有限的一天...）、取消二籌見面會議改以兩次線上討論取代、降低會前會與檢討會人員餐費等行政項目，也包括取消上午點心、減少便當數（這兩個加起來有不良影響，容後討論），以及這一段要討論的「取消去程接駁車」等影響會眾的事情。

COSCUP 從在中研院辦的 2010 年起，首開先例設置了「接駁車」，方便當時只能從捷運南港站來的會眾前往中研院，到後來其他研討會也多有跟進。過去成效不算差，那這次為什麼要取消？原先是我在 PyCon Taiwan 時跟一群在辦研討會的人提到，從南港展覽館到中研院的車超多，似乎沒那麼必要提供接駁車，且我也希望由會眾自己負擔一些費用。小朱提出一個看法：早上真的有點懶得走中研院門口到人文館的那段路，沒來過的人面對這段路也怕迷失。於是大家討論出計程車共乘是個好方法：每個人分 25 塊並不是多大的負擔，不用等太久、滿四人就走的方式也比接駁車好一點，另外我個人也奢望能造成一點額外的作用 - 本來開源人們就是要拿出家裡的青菜煮石頭湯，鼓勵共乘讓大家一起坐小黃也增加認識同好的機會。於是，在公開討論區發表取得共識後，決定取消早上到會場的接駁車、改以配套機制鼓勵計程車共乘。

這個作法似乎招來了一些抱怨，不過大致上來說接受度也還不錯。兩天的駐點時間（上午八點起的一個小時）都有約 30 班次小黃前往中研院，保守推估兩天各有 90 人以上搭乘計程車前往會場，我個人覺得下次還可以比照辦理。

那麼晚上的接駁車何以不一併取消？一方面要叫計程車進來人文館並不方便，二方面在夜裡讓不熟悉場地的會眾從人文館走到中研院門口好像也不太保險，有鑑於安全與方便，仍然提供晚間接駁車。是說，大家在第二天結束的時候不太捧場，據說坐不滿一班？或許第二天晚間的接駁車還可以再減少班次避免浪費。

---

這三項基本上結果都還算可接受，或甚至可以說是好的。下一篇再來談有不良影響的「點心減量」 + 「便當限量」... 不富奸的話。