Tag: analytics

Cloudflare Zaraz 的新價錢

Cloudflare Zaraz 有點像是 GA4、Mixpanel 或是 Amplitude 這種產品：

Cloudflare Zaraz is a solution that developers and marketers use to load third-party tools like Google Analytics 4, Facebook CAPI, TikTok, and others.

剛剛看到 Cloudflare Zaraz 的宣佈的新價錢：「Zaraz launches new pricing」，翻資料的時候發現去年七月的時候也有宣佈過價錢，但當時看起來反彈頗大而暫緩：「Cloudflare Zaraz steps up: general availability and new pricing」。

先看一下去年七月當時宣佈的價錢，這邊用了 Zaraz Loads 這個特別的 term：

If you exceed the free Zaraz Loads allocations, you'll be charged $0.50 for every additional 1,000 Zaraz Loads, but the service will continue to function.

看起來 Zaraz Load 包括了 script loading 以及 pageview event 都各算一次：

A Zaraz Load is counted each time a web page loads the Zaraz script within it, and/or the Pageview trigger is being activated.

這樣的話 1M event 就要 US$500，隔壁棚 Mixpanel 可以在「Pricing - Mixpanel | Product Analytics」這邊試拉，同樣 1M event 只要 $140，難怪當時被幹剿到不行...

這次公佈的價錢則是又用了新的 term，叫做 Zaraz Events，這個看起來就是一般理解的 event：

One of the biggest changes we made was changing the metric we used for pricing Zaraz. One Zaraz Event is an event you’re sending to Zaraz, whether that’s a pageview, a zaraz.track event, or similar.

而價錢直接下殺到 1M event 收 US$5，跟之前的差異巨大：

With the new Zaraz pricing model, every Cloudflare account gets 1,000,000 Zaraz Events per month for free. If your account needs more than that, every additional 1,000,000 Zaraz Events are only $5 USD, with volume discounting available for Enterprise accounts.

只是不知道 Zaraz 可以做到什麼程度，「理論上」會比較陽春，但不知道夠不夠用？

Cloudflare 前幾天 API 與 Dashboard 出事的 Post Mortem 記錄

前幾天 Cloudflare 的 API 與 dashboard 掛了一天多，少見的讓 Matthew Prince (CEO) 自己出來發 post mortem 記錄了：「Post Mortem on Cloudflare Control Plane and Analytics Outage」，在 Hacker News 上面也有蠻多討論的：「Post Mortem on Cloudflare Control Plane and Analytics Outage (cloudflare.com)」，這邊是整理我自己讀完後的感想。

從「Matthew Prince - The Cloudflare Blog」這邊可以看出來 Matthew Prince 上次是 2023/09/27 的公關文「Cloudflare’s 2023 Annual Founders’ Letter」，還有對應的多國翻譯，像是繁體中文的「Cloudflare 2023 年度創始人來信」，再往前的 2022/12/11 也是公關文「Welcome to Cloudflare’s Impact Week」(以及對應的繁體中文版本：「歡迎來到 Cloudflare 的 Impact Week」)。

這次的事情算是 Cloudflare 在 post-IPO 後很少見的長時間出事，就難得看到 Matthew Prince 自己出來坦了。為了重新建立信任，加上因為層級的關係，可以看到透漏出很多架構細節，算是這次可以窺視 Cloudflare 架構的一些資訊。

先大概提一下官方文章的著墨點：他們花了非常多的篇幅在機房服務商 Flexential 在處理 PDX-04 (這是 Cloudflare 訂的名稱) 機房電力問題的失職 (要注意這邊是 Cloudflare 的觀點，認為 Flexential 的失職，目前沒有從 Flexential 這邊的消息出來解釋)，淡化掉了 Cloudflare 自己的設計問題，這邊在 Hacker News 上有蠻多人都有指出來的。

這次事件一切的起因是 Flexential 的 PDX-04 機房整個電力系統斷線 offline 導致的，屬於標準的 data center failure 的情況，像是 2013 年二月時是方機房的火災 (可以參考 iThome 的整理)，或是 2021 年 OVH 的機房火災 (「去年 OVH 機房大火的部份情形最近被揭露」)，是個在設計架構時一定會規劃進去的項目。

所以 Matthew Prince 先是解釋 Cloudflare 的 HA 作法，是直接在 Hillsboro, Oregon 租三個機房建立起 low-latency network：

Cloudflare's control plane and analytics systems run primarily on servers in three data centers around Hillsboro, Oregon. The three data centers are independent of one another, each have multiple utility power feeds, and each have multiple redundant and independent network connections.

但大家看到這計馬上就會去查，這個城市也才 66.9km2 的土地，大約是 1/4 個台北市 (約 291.8km2) 再小一些，拉了一下城市內的直線最遠距離，大約是 12km？

呃，這不是一個地震 (就在聖安地列斯斷層區域？) 或是一個核攻擊就把 Cloudflare 最核心的部分給擺平了嗎？

其中 analytics systems 就算了：整個 Hillsboro 掛了進入 gracefully degrading，我可以理解這個設計的考量，但 control plane 看起來不太妙？

雞蛋放在同一個籃子的問題裡先放著，雖然這個問題真的很...。

後續提到了有些重要的產品對沒有 HA 能力的服務上有相依性：

Unfortunately, we discovered that a subset of services that were supposed to be on the high availability cluster had dependencies on services exclusively running in PDX-04.

這邊沒有講是哪些服務的相依性，但文章其他地方有提到有些基礎服務是沒有跨機房 HA 架構的，只有在 PDX-04 有跑，包括了 Kafka 與 ClickHouse：

In particular, two critical services that process logs and power our analytics — Kafka and ClickHouse — were only available in PDX-04 but had services that depended on them that were running in the high availability cluster.

這點讓人頗意外的，Kafka 因為自己架設 & 維護過，知道他的架構本身就很容易設計到跨機房的 case，而且這算是很基礎建設的東西，居然沒有跨機房 HA？

而 ClickHouse 只有研究過，沒有實際把 production 量丟上去跑，但從文件看到的東西，應該至少能做到 shared-everything 的架構，也居然沒有跨機房 HA？

這接基礎建設的問題，導致了雖然只是單一機房 PDX-04 掛掉，但在有重要基礎建設消失的情況下 (應該就是上面提到的 Kafka 與 ClickHouse)，加上 Flexential 沒有給出恢復的時間，決定直接跑災難重建的 SOP (也就是 Hillsboro 的三個機房都回不來的情境)。

而這也可以看到恢復時間比較久，從決定切到歐洲的 DR site 到整個切過去花了四個多小時：

Because more services were offline than we expected, and because Flexential could not give us a time for restoration of our services, we made the call at 13:40 UTC to fail over to Cloudflare's disaster recovery sites located in Europe.

By 17:57 UTC, the services that had been successfully moved to the disaster recovery site were stable and most customers were no longer directly impacted.

因為 Kafka 與 ClickHouse 在 Hillsboro 只有單一機房有服務，那就不確定歐洲 DR site 平常有沒有建起來，也許這邊的四個多小時有不少是在歐洲 DR site 把 Kafka 與 ClickHouse 建起來？(這個就只能猜測了)

回到 Flexential 這邊，在恢復供電的過程發現 Cloudflare 這邊迴路用的 breaker 掛了，直到十個小時後才供電，但也因為大家都忙了一整天，Matthew Prince 決定讓大家先回去休息，隔天早上再從歐洲的 DR site 切回 Hillsboro，也因此拉長了恢復的時間：

At 12:48 UTC, Flexential was able to get the generators restarted. [...] When Flexential attempted to power back up Cloudflare's circuits, the circuit breakers were discovered to be faulty.

Flexential replaced our failed circuit breakers, restored both utility feeds, and confirmed clean power at 22:48 UTC. Our team was all-hands-on-deck and had worked all day on the emergency, so I made the call that most of us should get some rest and start the move back to PDX-04 in the morning. That decision delayed our full recovery, but I believe made it less likely that we’d compound this situation with additional mistakes.

要注意報告慣例是用 UTC 時間 (這又是另外一個主題了，先前 HN 上也有其他文章討論過...)，而 Hillsboro 在美西，要減八個小時，所以 22:48 UTC 是下午兩點多左右，美東與歐洲的團隊時間則會更晚。

目前看起來 Cloudflare 的設計與流程有很大的改善空間？之後看看有沒有其他的八卦消息出來？

在 PostgreSQL 上直接掛 ML extension

Hacker News 首頁上看到「Show HN: PostgresML, now with analytics and project management (postgresml.org)」這個專案，可以在 PostgreSQL 上面直接掛 extension 跑 ML algorithm：「PostgresML - an end-to-end machine learning solution」，從 GitHub 上可以看到大多數是 Python 的程式碼。

從 GitHub 頁面上面可以看到這個專案還在比較早期的階段：

This project is currently a proof of concept. Some important features, which we are currently thinking about or working on, are listed below.

如果是目前要用的話，主要是方便看一些東西吧？可以想到的是掛個 replication 出來跑一些 query，這樣不會影響到 production database 的效能，應該還行...

另外看了一下支援的演算法，主要是以經典的 ML 演算法為主，而且就是套用 Python 上面的套件：XGBoost 與 scikit-learn。

這些演算法算是很好用了，而且掛到 PostgreSQL 裡面會讓使用上方便很多 (少了倒資料的動作，不過就得小心處理 dirty data 了)，然後專案也附上一個 UI 界面可以看一些資料，不過我猜還是用其他生 visualization 的工具會比較豐富一點：

另外一個想法是拿來學習還不錯？老師在上課的時候拿來示範一些演算法，就不用自己再刻很多程式碼...

從 Mozilla 官網下載的 Firefox 帶有追蹤用的標籤

前天看到「Each Firefox download has a unique identifier」這篇報導，就順手貼到 Hacker News 上面了：「Each Firefox download has a unique identifier (ghacks.net)」。

簡單的說就是 Mozilla 在 Firefox 的 binary 裡面加上 download token，後續就可以追蹤使用者：「[meta] Support download token」。

依照報導所提到的，每次下載 binary 都會有不同的 token：

在「Attached file dltoken_data_review.md — Details」裡面有回答更多細節，像是跟 Google Analytics 綁定：

5) List all proposed measurements and indicate the category of data collection for each measurement, using the [Firefox data collection categories](https://wiki.mozilla.org/Firefox/Data_Collection) found on the Mozilla wiki.   

<table>
  <tr>
    <td>Measurement Description</td>
    <td>Data Collection Category</td>
    <td>Tracking Bug #</td>
  </tr>
  <tr>
    <td>A download token that uniquely corresponds to a Google Analytics ID</td>
    <td>Category 4 "Highly sensitive or clearly identifiable personal data"</td>
    <td>Bug 1677497</td>
  </tr>
</table>

我自己重製不出來 (都是被導去 CloudFront)，但留言區裡面的 Yuliya 透過 Tor 有重製出來：

I have tried some TOR exit nodes:

Name: Firefox Setup 98.0.1_germany.exe
Size: 55528896 bytes (52 MiB)
SHA256: 2d8164d547d8a0b02f2677c05e21a027dc625c0c1375fd34667b7d039746d400
SHA1: 71302acbee6895b84cf0dfae99050926f2db59ef

Name: Firefox Setup 98.0.1_austria.exe
Size: 55528896 bytes (52 MiB)
SHA256: a139a45dd5737ab981068ca2596b7fdfde15e5d4bc8541e0a2f07a65defd3e4e
SHA1: 28630a0aababa162ca9e7cbca51e50b76b9c3cff

I have labeled the file for the corresponding country of the exit node.

如果不願意換到 Chromium-based 的方案，目前在討論裡看到的替代方案是 LibreWolf，昨天裝起來後發現還行，應該也可以測試看看...

法國 CNIL 認為 Google Analytics 傳輸資料回美國違反 GDPR

先前提過德國認為沒有告知使用者網站使用 Google Fonts 違反 GDPR (可以參考先前寫的「德國的地方法院說使用 Google Fonts 服務沒有告知使用者違反 GDPR」這篇)，這次法國的 CNIL (英文維基百科的介紹：「Commission nationale de l'informatique et des libertés」，是法國政府的一個獨立單位) 認定 Google Analytics 將資料傳回美國違反 GDPR：「Use of Google Analytics and data transfers to the United States: the CNIL orders a website manager/operator to comply」。

文章的 summary 講的差不多：

Google Analytics provides statistics on website traffic. After receiving complaints from the NOYB association, the CNIL, in cooperation with its European counterparts, analysed the conditions under which the data collected through this service is transferred to the United States. The CNIL considers that these transfers are illegal and orders a French website manager to comply with the GDPR and, if necessary, to stop using this service under the current conditions.

這件事情在 Hacker News 上的討論很熱烈，這邊就不爆雷了：「Use of Google Analytics declared illegal by French data protection authority (cnil.fr)」，在看的時候要知道 Hacker News 是非常美國觀點的站台 (偏 Y Combinator 或是 VC 圈子觀點)。

Google Analytics 會愈來愈不準的問題

在 Hacker News Daily 上看到在討論 Google Analytics 會愈來愈不準的問題：「58% of Hacker News, Reddit and tech-savvy audiences block Google Analytics」，先大概知道 Plausible 也是一個分析工具，宣稱重視隱私以及相關法規 (...)，所以網站裡面提到的推論可以看看就好，這次我主要是看數字而已。另外當然，Hacker News 上對這篇文章的討論「Tech-savvy audiences block Google Analytics (plausible.io)」也可以翻翻。

作者先前注意到愈一般性的網站，阻擋率就愈低，但科技相關的網站就會高到失真：

In a previous study, I’ve found that less than 10% of visitors block Google Analytics on foodie and lifestyle sites but more than 25% block it on tech-focused sites.

其實不算太意外，除了 Google 自家的瀏覽器，其他的瀏覽器愈來愈多預設就會擋掉各種 tracker，而科技相關網站的受眾常常會「保護自己」。

首先的段落提到的全站的比率，有大量的使用者會擋掉 Google Analytics (要注意這邊是拿科技類網站的數字，不是一般性的網站)，：

58% of visitors block Google Analytics

然後是桌機與筆電的使用者阻擋率比較高 (還是科技類網站的數字)：

68% of laptop and desktop users block Google Analytics

另外提到 Firefox 使用者的阻擋率超高，應該是幾乎都會裝套件擋，另外記得新版的 Firefox 預設會擋，可能也有關係 (再提醒一下，這是科技類網站)：

88% of Firefox users block Google Analytics

另外一個不算意外的是 Linux 使用者也是擋的很兇 (科技類網站)：

82% of Linux users block Google Analytics

這有兩個重點蠻重要的，第一個是，就算你不是科技類網站，你也應該試著用其他工具「校正」Google Analytics 的數字，你要知道 Google Analytics 偏差了多少。

第二個是 Firefox 使用者的數量可能都被低估了，以 Firefox 阻擋率這麼高的情況下，有可能 Firefox 使用者會裝各種阻擋工具，把各種分析平台都擋一輪。不要直接用這些工具的數字決定忽略掉 Firefox 的使用者，最好要多方面驗證：

I expected these numbers to be higher. However, an even more interesting metric is the 88% block in Firefox.

Firefox may not have a great market share, but based on these numbers it's market share may very well be eight times higher than your analytics report. This can change the argument of "it's only 3% of our users so we don't need to test on FF" to "it's a quarter of our user base, we should at least test it", depending on your target audience. I've seen tons of people claim general Firefox usage is negligible based on public data from websites such as statcounter, but these metrics prove that those statistics are unreliable and should not be used.

The best you can do is use server side UA inspection, though you can't really distinguish bots from real users that way.

另外順便提，我在辦公室裡面推銷 uBlock Origin 的方式是跟他們說 YouTube 影片就沒有 Google 的廣告了 (業配那種不算)，基本上用過就回不去了...

Firefox 在 Strict Tracking Protection 模式下閹割 Google Analytics

在 Twitter 上看到 Firefox 在 Strict Tracking Protection 模式下會閹割掉 Google Analytics：

剛好可以跟另外一篇「Google Analytics: Stop feeding the beast」一起看，這篇主要是對網站管理端的說明，你可以使用其他對隱私保護比較好的服務，或是考慮自己架設。

回到使用者端的部份，在 Firefox 裡面 Browser Privacy 預設是 Standard，換成 Strict 後就會觸發這個行為：

不是直接擋掉到 google-analytics.com 與 googletagmanager.com 的連線，而是把 javascript 抽換掉，讓呼叫的程式碼完全不會做事。

在 Strict 模式下，除了會閹割 Google Analytics 外，也有其他的 js 會被閹割 (像是 Facebook 的)，可以在 GitHub 上的「gecko-dev/browser/extensions/webcompat/shims/」這邊翻到。

這個功能很明顯在 Google Chrome 上不會內建，但很久前就有套件可以用了。目前比較常見的作法是透過 uBlock Origin 做，而且是在內建的「uBlock filters – Privacy」這組定義裡面就有實做，對應到 GitHub 上的 privacy.txt 這邊可以看到：

! Redirect to neutered Google Analytics 
||google-analytics.com/analytics.js$script,redirect=google-analytics.com/analytics.js

! Redirect to neutered Google Analytics Experiments
||google-analytics.com/cx/api.js$script,redirect=google-analytics.com/cx/api.js

不過 Firefox 上的 uBlock Origin 與其他套件也有類似的功能，真的在意的人應該早就使用了...

AWS 推出了 Amazon S3 Storage Lens 可以看 S3 使用的概況

AWS 推出了 Amazon S3 Storage Lens，可以看 S3 使用的概況：「Introducing Amazon S3 Storage Lens – Organization-wide Visibility Into Object Storage」。

要使用者個功能需要授權 Amazon S3 Storage Lens 一些權限，照著說明去 IAM 開就可以了，開好後要等他一陣子，他需要去分析記錄才能產出 dashboard。

有免費版與付費版可以用，付費版的部份目前看到都是「$0.20 per million objects monitored per month」，但沒把所有的區域都翻完，所以不確定。

我自己看了一下免費版提供的預設 dashboard，就已經給出不少好用的資訊了，像是 30 天內的物件數與空間使用率變化，可以抓到一些成長數量的感覺。

可以建議至少免費版的部份就先開起來丟著...

移除 Blog 上的 Google Analytics，改用 Matomo

跑了快一個月了，大概整理一下...

一直都有在規劃降低對 Google 服務的依賴性，最主要的是使用 DuckDuckGo 替代 Google Search (但搜尋的品質還是差一截，所以寫了一些工具幫助我在不滿意的時候可以快速切到 Google 搜尋：「在 DuckDuckGo 搜尋頁快速切換到 Google 的套件」)。

而最近在研究的另外一個服務是 Google Analytics，我只用很基本的功能 (像是熱門文章，作業系統與瀏覽器的比率這些很基本的資料)，不需要對於觀看客群有了解 (這個需要像 Google Analytics 跨站蒐集資料)，所以替代方案應該不難找...

憑著印象與一些關鍵字，找到了 Matomo，這是一套 open source 的 web analytics 服務，以前叫做 Piwik (參考「Piwik is now Matomo - Announcement」)，整個系統用 PHP + MySQL 就可以打發 (反正量不大的東西不需要拿什麼神兵利器出來，MySQL 硬塞硬算就可以了)，接著把本來 Google Analytics 的 js 換掉就行了...

跑了快一個月後感覺還 ok，基本的資訊都有...

Amazon Elasticsearch 支援 I3 instance (i.e. 1.5 PB Disk) 了

Amazon Elasticsearch 支援 I3 instance 了：「Run Petabyte-Scale Clusters on Amazon Elasticsearch Service Using I3 instances」。

Amazon Elasticsearch Service now supports I3 instances, allowing you to store up to 1.5 petabytes of data in a single Elasticsearch cluster for large log analytics workloads.

i3.16xlarge 單台是 15.2 TB 的硬碟空間，100 台就會是 1.5 PB，不知道跑起來會多慢 XDDD

Amazon Elasticsearch Service – Amazon Web Services (AWS) | FAQs 這邊還沒修正 XD：

You can request a service limit increase up to 100 instances per domain by creating a case with the AWS Support Center. With 100 instances, you can allocate about 150 TB of EBS storage to a single domain.