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 的廣告了 (業配那種不算),基本上用過就回不去了...

南韓對 Apple 與 Google 的 In-App 付款機制的提案

WSJ 上看到南韓對 AppleGoogle 的 in-app 付款機制提案,強制 Apple 與 Google 讓 app 的開發者 (或是開發商) 使用第三方支付平台:「Google, Apple Hit by First Law Threatening Dominance Over App-Store Payments」。

看不到 WSJ 內文的可以看「Apple and Google must allow developers to use other payment systems, new Korean law declares」這篇,裡面有引用韓國的媒體報導 (英文版):「S. Korea looks set for legislation to curb Google, Apple's in-app billing system」。

要注意這還沒有通過,目前過委員會而已 (parliamentary committee),接下來要表決才會成為正式法律。

先前美國亞利桑那州的法案被擋下來,然後參議院提的法案也還在進行中,看起來還有很硬的仗要打:「由美國參議院提出的 Open App Markets Act」。

先繼續等後續發展,可以想見 Apple 與 Google 一定會想辦法抵制...

Ansible 的爭論

前幾天在 Hacker News Daily 上看到「Five Ansible Techniques I Wish I’d Known Earlier」這篇,裡面提到了一些 Ansible 的用法還蠻有用的,算是開始用 Ansible 後應該都會有幫助的用法... 不過 Hacker News 上的討論「Ansible Techniques I Wish I’d Known Earlier (zwischenzugs.com)」比較精彩...

目前在頂端的留言對 Ansible 幹到不行,尤其是那個 YAML 格式:

Ansible is abysmal. I don't know why anyone still chooses it. It's a mess of yaml and what feels like a million yaml files that is always extremely hard to follow. Honestly writing some python, or bash is a lot easier to follow, read, and understand. The only thing it has going for it is the inventory system. I wish ansible would die already.

然後講到 bash 與 python 之類的工具時有人提到 idempotent:

>bash and python
Neither of those of idempotent.

馬上就有人幹勦,大多數人在寫 Ansible playbook 時根本沒人在注意 idempotent,而且一堆 shell script 的東西被塞進 YAML 只能說痛苦 XDDD

Most of the ansible roles I come across written by my team are not idempotent either, its a huge lie that Ansible is idempotent. Its idempotent if you put the effort into make it be but if I see tons of shell or command module invocations without prerequisite checks to see if the work should be done. Most devs I see using Ansible treat it like a shell script written in YAML and to that purpose it sucks.

我自己目前會挑 Ansible 主要還是因為 server 不需要另外裝軟體,是個 production 為導向的設計,再更大的時候就要想一下要怎麼繼續搞下去了...

OpenRsync 專案

看到「(open)rsync gains include/exclude support」這篇才注意到有 OpenRsync 專案...

在 OpenRsync 的網站上是指到 OpenBSD 的 cvsweb 上:「src/usr.bin/rsync/」,不過在 GitHub 上也有一個 repository:「kristapsdz/openrsync」,裡面有提到目前應該是以 OpenBSD 內的 source code 為主:

This system has been merged into OpenBSD base. If you'd like to contribute to openrsync, please mail your patches to tech@openbsd.org. This repository is simply the OpenBSD version plus some glue for portability.

然後有也提到 OpenRsync 主要就是 license 的關係 (rsync 目前是 GPLv3):

This is an implementation of rsync with a BSD (ISC) license. It's compatible with a modern rsync (3.1.3 is used for testing, but any supporting protocol 27 will do), but accepts only a subset of rsync's command-line arguments.

不過在一開始的報導裡面,有人反應軟體與 rsync 的相容性不太好,會搞爆 rsync:

By grey (grey) on 2021-08-31 05:17

Nice!

Albeit, the last time I was testing openrsync, I discovered I could use openrsync to reproducibly crash rsync on FreeBSD13-CURRENT on a Raspberry Pi 3 and decided rather than try to debug rsync, I would wait for openrsync to mature a bit, I'm grateful to see that it continues to progress!

就當作個記錄...