Nên chạy analytics self-hosted nào trên VPS?

Nên chạy công cụ phân tích web self-hosted nào trên VPS?

Phân tích web self-hosted có 2 nhóm. Chọn nhầm nhóm gây tốn kém hơn chọn nhầm sản phẩm. Một nhóm chạy một script nhỏ trong browser của khách truy cập và lưu dữ liệu mà script đó báo cáo. Nhóm còn lại đọc access log mà web server đã ghi sẵn. Sau lựa chọn này, mọi thứ khác, gồm database và lượng memory cần dùng, đều phụ thuộc vào đó.

Câu trả lời ngắn gọn cho một máy cấu hình nhỏ: GoatCounter và Medama chạy được trên 1 GB vì mỗi công cụ chỉ là một process dùng một file. Umami thêm một Postgres container và cung cấp dashboard mà người không chuyên kỹ thuật vẫn có thể đọc. Plausible Community Edition và Rybbit đều chạy ClickHouse, vì vậy nên chuẩn bị 2 GB RAM trở lên. Matomo là sản phẩm đầy đủ tính năng và cần server có cấu hình phù hợp với lưu lượng của bạn. GoAccess không thêm gì vào page vì nó đọc một log đã tồn tại.

Thẻ script hoặc server log: mỗi loại có thể thấy gì

Thẻ script đo lường trình duyệt. Trang được tải, script chạy, rồi gửi một request đến collector của bạn. Bất kỳ sự cố nào làm đứt chuỗi này đều không hiển thị với bạn: JavaScript bị tắt, filter list chặn request, request đến collector thất bại hoặc crawler không bao giờ chạy script.

Log parser đo lường request. Web server ghi một dòng cho mỗi request, dù bạn có cài thêm gì hay không, nên dữ liệu đã có sẵn trên disk. Nó thấy mọi crawler và mọi lượt truy cập vào file không chứa thẻ script. Nó không thấy những gì xảy ra bên trong trình duyệt. Nó cũng không thấy trang được trả về từ browser cache hoặc từ CDN (content delivery network) đặt phía trước server của bạn, vì request đó không bao giờ đến server.

Hai con số sẽ không khớp và không con số nào sai. Matomo hỗ trợ cả hai cách. Tài liệu của Matomo nêu rõ log import không có các dữ liệu mà JavaScript tracker cung cấp: độ phân giải màn hình và tiêu đề trang, event, content tracking, heatmap, session recording và form analytics. Đây là phần phải đánh đổi khi đếm request thay vì đếm trình duyệt.

Bot traffic là phần còn lại tạo ra chênh lệch. Số liệu dựa trên log bao gồm crawler nếu bạn không filter chúng. Với một site thông thường, tỷ lệ crawler đủ lớn để làm thay đổi kết luận của bạn. GoAccess và log import của Matomo đều filter các bot đã biết. Không công cụ nào filter được crawler khai báo sai user agent. Vì vậy, nên kết hợp mọi cách đếm dựa trên log với chặn AI crawler tại server và đọc log sau khi chặn, không phải trước khi chặn.

GoAccess: phân tích từ log bạn đã có

Cài GoAccess từ repository Debian và Ubuntu chính thức của dự án, vì các gói do distribution cung cấp thường chậm hơn các bản release.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

Sau đó trỏ GoAccess vào log và ghi báo cáo tĩnh.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

Lệnh đó thất bại với Permission denied khi chạy bằng user thông thường, vì trên Ubuntu, log của nginx thuộc sở hữu của root và có group adm. Thêm user của bạn vào group đó bằng sudo usermod -aG adm $USER, rồi đăng xuất và đăng nhập lại vì membership của group được đọc khi đăng nhập. Chạy id và kiểm tra xem adm đã xuất hiện trong danh sách chưa trước khi thử lại.

Báo cáo đọc log hiện tại chỉ bao phủ phần log mà logrotate chưa chuyển đi. Request của ngày hôm qua nằm trong access.log.1, còn các file cũ hơn đã được nén, nên báo cáo theo tuần cũng phải đọc các file đã rotate.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

GoAccess cũng có chế độ live, --real-time-html, cập nhật trang qua WebSocket. Chế độ này cần thêm một port và một proxy rule riêng. Với hầu hết website, báo cáo theo giờ được cron ghi ra là đủ và cần bảo mật ít hơn.

GoatCounter: một binary Go và một file SQLite

GoatCounter được phát hành dưới dạng binary biên dịch tĩnh, nên không cần cài runtime. Tải một bản build từ trang release rồi chạy, hoặc dùng image.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

Khi chạy dưới dạng binary, goatcounter serve lắng nghe trên cổng 8080 và tạo SQLite tại ./goatcounter-data/db.sqlite3. Tạo site đầu tiên từ command line thay vì web wizard nếu instance đã nằm sau proxy.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

GoatCounter có thể tự quản lý certificate bằng goatcounter serve -listen=:443 -tls=tls,rdr,acme, sử dụng ACME (automatic certificate management environment). Cách này phù hợp với máy chủ không chạy dịch vụ nào khác. Nếu nginx hoặc Caddy đã quản lý cổng 443, hãy để GoatCounter chạy trên cổng 8080 rồi proxy đến đó. Theo số liệu của dự án, tracking script có dung lượng khoảng 3.5K. GoatCounter cũng có tracking pixel cho các trang không chạy JavaScript. Nếu SQLite trở thành giới hạn trên site có lưu lượng cao, binary tương tự có thể dùng Postgres với goatcounter serve -db 'postgresql+dbname=goatcounter'. Backup chỉ là copy một file. Đây là ưu điểm thực tế của mô hình này.

Medama: một container duy nhất chỉ chiếm 256 MB

Medama là lựa chọn binary đơn mới nhất trong danh sách này. Theo thiết kế, nó không dùng cookie. Dự án công bố tracker dưới 1 KB và các site nhỏ có thể chạy trên máy ảo với 256 MB bộ nhớ. Đây là các tuyên bố do dự án công bố, không phải số liệu được đo cho hướng dẫn này.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

Lệnh chính thức publish port trên 8080:8080. Prefix loopback ở trên là có chủ đích; phần reverse proxy giải thích lý do. Lần đăng nhập đầu tiên dùng admin với password CHANGE_ME_ON_FIRST_LOGIN. Tên của password chính là instruction.

Có một lỗi đã được ghi nhận mà bạn dễ gặp phải. Đăng nhập chỉ hoạt động qua HTTPS hoặc trên localhost. Vì vậy, nếu bạn cấu hình proxy trước khi có certificate, form sẽ từ chối password đúng nhưng không in ra lý do. Hãy hoàn tất thiết lập TLS (transport layer security) trước, rồi đăng nhập.

Umami: PostgreSQL và dashboard quen thuộc

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

Lệnh này khởi động ứng dụng trên cổng 3000 cùng với một PostgreSQL container chạy bên cạnh. Tài liệu yêu cầu PostgreSQL v12.14 trở lên. Nếu build từ source, cần Node.js 18.18 trở lên. Umami có image dựng sẵn là docker.umami.is/umami-software/umami:postgresql-latest. Image này cần DATABASE_URL trỏ đến một database bạn đã chạy sẵn.

Thông tin đăng nhập lần đầu là admin với mật khẩu umami. Hãy đổi mật khẩu trước khi trỏ DNS đến máy chủ. Ngay khi DNS record phân giải và proxy phản hồi, instance có thể truy cập từ Internet. Về chi tiết Compose, file môi trường và restart policy, xem một Docker Compose stack trên VPS thay vì sao chép một stack mà bạn chưa đọc.

Mô hình này gồm một Node process và Postgres. Nó nặng hơn một binary đơn lẻ nhưng nhẹ hơn nhiều so với mọi hệ thống chạy ClickHouse.

Plausible Community Edition: ClickHouse đặt mức RAM tối thiểu

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

Tính đến August 2026, version v3.2.1 là bản hiện tại và lệnh clone cố định đúng version này theo chủ ý. Stack gồm ba phần: application, Postgres lưu account và setting, cùng ClickHouse lưu event data. SECRET_KEY_BASE phải là chuỗi dài ít nhất 64 byte. Lệnh gọi openssl tạo ra chuỗi đáp ứng yêu cầu đó.

Yêu cầu chính thức của Plausible cần ít nhất 2 GB RAM để ClickHouse và application không bị out of memory killer dừng, cùng CPU hỗ trợ SSE 4.2 hoặc NEON vì ClickHouse cần các tập lệnh này. Nên kiểm tra yêu cầu CPU trước khi mua VPS. Đây cũng là một khác biệt thực tế khi chọn giữa VPS ARM và x86. ClickHouse cũng sẽ dùng lượng memory mà nó cho là đang khả dụng. Vì vậy, trên máy dùng chung, hãy đặt giới hạn như mô tả trong giới hạn memory của container trong Compose.

BASE_URL phải khớp chính xác với public URL. Nếu không, bạn vẫn đăng nhập được nhưng application chuyển hướng sang host sai. Session cookie được ghi cho domain mà browser không truy cập, nên bạn quay lại form đăng nhập mà không có thông báo lỗi.

File compose đi kèm không publish port vì thiết kế giả định có proxy đứng phía trước. Hãy thêm file override để chỉ publish port mặc định của application trên loopback.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo: sản phẩm đầy đủ và máy chủ mà nó yêu cầu

Matomo chạy trên PHP với MySQL hoặc MariaDB, nên phù hợp với web stack truyền thống thay vì container stack. Đây cũng là công cụ duy nhất trong danh sách này công bố yêu cầu phần cứng theo lưu lượng truy cập.

[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

Đây là mức tối thiểu do Matomo công bố tính đến tháng 8 năm 2026, không phải số đo được thực hiện cho hướng dẫn này. Với tối đa 100,000 pageview mỗi tháng, Matomo yêu cầu 2 core CPU, 2 GB RAM và 50 GB SSD; một máy chủ sẽ chạy cả ứng dụng và database. Ở mức 1M/month, yêu cầu tăng lên 8 GB RAM và 250 GB disk. Ở mức 10M/month, Matomo khuyến nghị dùng hai máy chủ; hàng cuối hiển thị máy chủ database với 16 GB RAM và 400 GB disk. Hãy so sánh các mức disk này với các lựa chọn dùng binary đơn, trong đó toàn bộ dataset nằm trong một file SQLite.

Việc archive là điểm khiến nhiều người bất ngờ. Theo mặc định, Matomo tạo report khi có người mở dashboard. Khi dữ liệu tăng, dashboard sẽ chậm hơn và cuối cùng bị timeout. Cách khắc phục được ghi trong tài liệu là tắt việc archive do browser kích hoạt trong phần cài đặt chung, rồi chạy archiver từ cron thay cho việc đó. Hãy chạy bằng user sở hữu các file Matomo và thực hiện từ thư mục Matomo.

php console core:archive --url=https://analytics.example.com

Matomo cũng lưu các raw log table cùng với các processed report table và có thể xóa raw data cũ cũng như report cũ theo lịch. Hãy bật tính năng này ngay khi cài đặt, không chờ đến khi disk đầy. Matomo cũng có thể import server access log, nên đây là sản phẩm duy nhất trong danh sách này hỗ trợ đồng thời cả hai nhóm.

Rybbit và các stack mới hơn

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit là một lựa chọn mới với dashboard hiện đại. Script cài đặt ghi file environment rồi khởi động stack bằng Docker Compose. Rybbit chạy ClickHouse và tích hợp Caddy làm web server riêng. Caddy chiếm cổng 443 và yêu cầu chứng chỉ cho domain bạn đã truyền vào. Nếu nginx đã chiếm cổng 443 trên máy chủ, script sẽ không thể bind vào cổng này. Khi đó, hãy dùng quy trình Compose thủ công của dự án và đặt Rybbit phía sau proxy hiện có. Tài liệu yêu cầu ít nhất 2 GB RAM, được kiểm thử trên Ubuntu 24 LTS và yêu cầu ARMv8.2-A hoặc mới hơn trên ARM vì ClickHouse.

Điểm cần lưu ý khi dùng một dự án còn mới: tính năng được bổ sung nhanh và breaking change cũng xuất hiện nhanh. Hãy pin một tag, đọc release notes trước khi pull và sao lưu database trước.

Đo retention và mức tăng dung lượng đĩa trên chính máy chủ của bạn

Mức tăng dung lượng đĩa phụ thuộc vào dữ liệu tool lưu cho mỗi event. GoatCounter tổng hợp các hit thành counter, nên file tăng theo số page distinct và số ngày nhiều hơn theo volume thô. Umami và Matomo lưu row cho từng event. Matomo còn lưu thêm các bảng report đã xử lý bên cạnh các bảng raw. ClickHouse lưu event theo column và nén rất mạnh. Vì vậy Plausible có thể xử lý volume khiến row store gặp quá tải.

Guide này không đưa ra con số megabyte trên mỗi triệu pageview, vì chưa đo con số đó trên traffic của bạn. Hãy tự đo trên hệ thống của mình. Điều chỉnh tên service và user cho khớp với file Compose của bạn.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

Ghi lại con số này, chờ một tuần, rồi ghi lại lần nữa. Lấy phần chênh lệch chia cho số pageview dashboard báo cáo trong tuần đó. Con số này phản ánh site và cơ chế lọc bot của bạn, nên có giá trị hơn mọi mức trung bình được công bố. Sau đó đặt giới hạn retention khi dung lượng vẫn còn nhỏ. Khi đĩa đầy, mọi service trên VPS đều ngừng hoạt động, không chỉ analytics. Đây là lý do quan trọng nhất để đặt database volume ở nơi mà df -h sẽ cảnh báo cho bạn. Rủi ro này cần được chú ý hơn trên máy chủ đã chứa dữ liệu cồng kềnh, vì photo server tự host sẽ làm đầy đĩa từ lâu trước khi bất kỳ analytics database nào tiến gần đến giới hạn.

Cách hoạt động phía sau reverse proxy trên một subdomain

Đặt collector trên một subdomain của website mà nó đo lường, chẳng hạn như stats.example.com. Khi đó, request đến collector được xem là first-party, nên không bị các quy tắc của trình duyệt dùng để chặn request third-party tác động.

Bind ứng dụng vào loopback khi publish cổng của container. Docker ghi các firewall rule riêng trước ufw, vì vậy container được publish dưới dạng -p 3000:3000 vẫn có thể truy cập từ Internet ngay cả khi ufw status báo cổng bị từ chối. Kiểm tra từ một máy khác bằng curl http://SERVER_IP:3000 và bạn sẽ truy cập được dashboard. Khi được publish dưới dạng -p 127.0.0.1:3000:3000, cùng phép kiểm tra sẽ trả về Connection refused và chỉ proxy mới truy cập được. Thói quen này không chỉ giúp ẩn dashboard: đây là nguyên tắc cốt lõi khi chạy onion service trên cùng máy, vì bất kỳ service nào vẫn phản hồi trên public interface đều có thể liên kết địa chỉ ẩn với IP của bạn. Collector endpoint phải tiếp tục có thể truy cập từ Internet công khai, nhưng dashboard thì không cần. Nếu muốn đọc dashboard qua private network thay vì publish thêm một subdomain, quảng bá network của VPS vào tailnet bằng subnet router sẽ giúp bạn thực hiện việc đó mà không cần mở thêm cổng.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Các header chuyển tiếp là bắt buộc trong trường hợp này. Nếu thiếu X-Forwarded-For, mọi lượt truy cập đều xuất phát từ 127.0.0.1, khiến báo cáo theo quốc gia trống và số visitor duy nhất bị dồn về gần một. Mỗi project quyết định sẽ tin cậy header nào và dùng setting nào, vì vậy hãy xem tài liệu proxy của project một lần thay vì tự giả định. Caddy tự đặt các header đó, và Caddyfile cho cùng tác vụ chỉ cần hai dòng.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

Nếu bạn chưa chọn proxy, bài so sánh nginx, Caddy và Traefik sẽ trình bày proxy nào phù hợp với một máy chủ có vài subdomain.

Bạn có còn cần cookie banner nếu tự host không?

Tự host thay đổi bên nào nắm giữ dữ liệu. Việc này không thay đổi quy định pháp luật áp dụng cho dữ liệu đó. Hãy tách riêng 2 quy tắc. Quy định về consent trong ePrivacy áp dụng cho việc lưu hoặc đọc bất kỳ dữ liệu nào trên thiết bị của khách truy cập. Vì vậy, một tool không đặt cookie và không ghi dữ liệu vào local storage không thuộc phạm vi của yêu cầu cụ thể đó. GDPR áp dụng cho việc xử lý dữ liệu cá nhân. Địa chỉ IP được xem là dữ liệu cá nhân, nên bạn vẫn cần lawful basis, thời hạn lưu trữ và phương án trả lời khi có người hỏi bạn đang lưu giữ dữ liệu gì về họ.

Plausible, Umami, GoatCounter và Medama không đặt cookie theo mặc định. Cách mỗi tool suy ra dữ liệu thay thế khác nhau tùy dự án và có thể thay đổi giữa các version, nên hãy đọc tài liệu privacy của chính dự án thay vì dựa vào bản tóm tắt. Matomo tích hợp sẵn tính năng ẩn danh IP và một endpoint opt out mà bạn bật trong admin interface.

Cơ quan quản lý ở mỗi quốc gia có thể đưa ra kết luận khác nhau. Ví dụ, CNIL của Pháp công bố các điều kiện để hoạt động đo lường audience được miễn consent. Phần này chỉ là tóm tắt thông tin thực tế, không phải tư vấn pháp lý. Với một site thực tế có người dùng thực tế, hãy hỏi luật sư tại khu vực pháp lý của bạn.

Một điểm thường bị bỏ qua: access log cũng là dữ liệu cá nhân. GoAccess không thêm script vào trang nhưng vẫn xử lý địa chỉ IP, nên analytics dựa trên log không tự động nằm ngoài các quy định này. Chuyển một service sang máy của bạn chỉ chuyển vị trí của rủi ro, không loại bỏ rủi ro. Đây cũng là lý do một instance SearXNG tự host thực sự che giấu điều gì chỉ che giấu thông tin với các search engine, trong khi bản thân các truy vấn vẫn được ghi vào log của bạn.

Trình chặn quảng cáo và lý do số liệu của bạn sẽ giảm

Các filter list đối chiếu hostname và pattern trong URL. Một sản phẩm analytics được host sẵn dễ bị khớp vì mọi người đều tải nó từ cùng một hostname phổ biến. Chuyển collector sang subdomain của bạn sẽ loại hostname đó khỏi request. Phục vụ script từ một path do bạn chọn sẽ loại filename phổ biến. Cả hai thay đổi này đều thay đổi thông tin mà filter list cần đối chiếu.

Bài viết này không khẳng định tỷ lệ bị chặn vì không đo tỷ lệ đó. Tỷ lệ visitor chặn một cấu hình cụ thể phụ thuộc vào audience của bạn. Audience là developer thường chặn nhiều hơn audience phổ thông. Thay vào đó, hãy tự đo khoảng chênh lệch của bạn. Trong cùng một tuần, dùng GoAccess đếm các request đến trang HTML trong access log. Sau đó so sánh với số pageview mà công cụ dựa trên script của bạn báo cáo. Trên site của bạn, phần chênh lệch là số lượt truy cập bị chặn cộng với các trang được phục vụ từ cache.

Hãy dự kiến tổng số liệu sẽ thay đổi vào ngày bạn chuyển khỏi sản phẩm được host sẵn. Một phần thay đổi đó có thể không liên quan đến việc bị chặn. Các sản phẩm không thống nhất về định nghĩa pageview, về việc một lần đổi route bên trong single-page application có được tính là một pageview hay không, và về thời điểm một session kết thúc. Hãy so sánh xu hướng qua nhiều tuần trước khi kết luận rằng traffic đã giảm.

Chọn công cụ nào cho từng loại site

• Site cá nhân hoặc blog có khoảng dưới 50,000 lượt xem trang mỗi tháng: GoatCounter hoặc Medama trên VPS 1 GB, với backup chỉ cần sao chép file.
• Site không thể thêm script, hoặc có lượng lớn người dùng chặn script: dùng GoAccess trên log hiện có và chạy theo lịch.
• Site doanh nghiệp nhỏ có người khác đọc dashboard: dùng Umami cùng container Postgres.
• Site cần theo dõi goal và funnel, chạy trên máy có từ 2 GB RAM trở lên: dùng Plausible Community Edition, hoặc Rybbit nếu muốn dashboard mới hơn và chấp nhận một project còn non trẻ.
• Nhiều site, nhiều tài khoản người dùng, hoặc cần giữ raw data theo retention policy của riêng bạn: dùng Matomo, cấp tài nguyên theo hướng dẫn được công bố ở trên.

Hãy bắt đầu bằng tool nhỏ nhất có thể trả lời đúng câu hỏi thực tế của bạn. Sau này chuyển từ GoatCounter sang Plausible chỉ tốn một subdomain và một phần lịch sử dữ liệu. Chuyển từ Matomo sang tool khác sẽ cần migration mà bạn sẽ không muốn thực hiện. Nếu bạn vẫn đang quyết định nên đặt thêm gì trên cùng máy đó, bài tổng hợp rộng hơn về self-hosting trình bày những gì có thể chạy cùng nó; còn nếu điều bạn thực sự cần là tracing ở cấp request của một ứng dụng thay vì đếm visitor, dịch vụ observability tự host mới là tool phù hợp.

FAQ

Self-hosting analytics có loại bỏ nhu cầu hiển thị cookie banner không?

Không, và đây là hai vấn đề riêng. Quy định về consent trong ePrivacy áp dụng cho việc lưu hoặc đọc dữ liệu trên thiết bị của khách truy cập. Vì vậy, công cụ không đặt cookie và không ghi dữ liệu vào local storage sẽ không thuộc phạm vi của yêu cầu cụ thể đó. GDPR là quy định khác và áp dụng cho việc xử lý dữ liệu cá nhân. Địa chỉ IP là dữ liệu cá nhân, nên ngay cả khi không dùng cookie, bạn vẫn cần cơ sở pháp lý và thời hạn lưu trữ. Self-hosting đưa dữ liệu lên server của bạn và khiến bạn trở thành bên chịu trách nhiệm về dữ liệu đó. Hãy kiểm tra hướng dẫn của cơ quan quản lý tại nơi bạn hoạt động và hỏi luật sư về trường hợp cụ thể.

Analytics self-hosted cần bao nhiêu RAM trên VPS?

Datastore quyết định mức tài nguyên, không phải dashboard. GoatCounter và Medama chạy dưới dạng một process trên một file, và tài liệu của Medama cho biết các site nhỏ có thể chạy trên máy chỉ có 256 MB. Umami thêm một Postgres container bên cạnh một ứng dụng Node. Plausible Community Edition và Rybbit đều chạy ClickHouse, và cả hai dự án đều yêu cầu ít nhất 2 GB. Hướng dẫn của Matomo bắt đầu từ 2 CPU cores và 2 GB RAM cho tối đa 100,000 pageview mỗi tháng.

Vì sao số liệu self-hosted thấp hơn analytics mà tôi đã thay thế?

Có hai nguyên nhân, và cả hai đều thường gặp. Filter list chặn một số request đến collector, nên mọi công cụ dựa trên script đều mất các lượt truy cập đó. Các sản phẩm cũng đếm khác nhau, vì định nghĩa pageview và thời điểm kết thúc session không giống nhau. Hãy so sánh số request đến các trang HTML trong access log của một tuần với số pageview dựa trên script trong cùng tuần đó. Chênh lệch là tổng của các lượt truy cập bị chặn và các trang được phục vụ từ cache, được đo trên chính site của bạn thay vì lấy theo tỷ lệ do bên khác công bố.

Tôi có thể chạy Plausible hoặc Rybbit trên ARM VPS không?

Cả hai đều chạy ClickHouse, và ClickHouse cần SSE 4.2 trên x86 hoặc NEON trên ARM. Yêu cầu của Plausible nêu chính xác điều này, còn tài liệu của Rybbit cho biết hệ thống ARM cần ARMv8.2-A hoặc mới hơn. Các ARM server core hiện nay đáp ứng yêu cầu đó, nhưng các core cũ thì không. Lỗi xuất hiện dưới dạng ClickHouse từ chối khởi động với thông báo lỗi instruction set, chứ không phải dưới dạng lỗi trong application log. Trên một máy ARM nhỏ, các công cụ dùng một file sẽ tránh được vấn đề này vì không công cụ nào trong số đó chạy ClickHouse.

Tôi có nên parse server log thay vì dùng tracking script không?

Hãy dùng log parsing khi bạn không thể thêm script, khi nhiều người dùng trong nhóm độc giả chặn script, hoặc khi bạn muốn số liệu bao gồm cả crawler. GoAccess đọc log mà server đã ghi, nên không làm tăng page weight và không cần database. Đổi lại, bạn không đo được những gì xảy ra bên trong browser. Bạn cũng bỏ sót các trang được phục vụ từ CDN hoặc browser cache, vì request đó không bao giờ đến server của bạn. Nhiều site chạy cả hai và coi chúng là hai phép đo khác nhau.