بهترین ابزارهای تحلیل وب self-hosted برای VPS

کدام ابزار تحلیل وب self-hosted را باید روی یک VPS اجرا کنید؟

ابزارهای تحلیل وب self-hosted در دو دسته قرار می‌گیرند و انتخاب دسته اشتباه، هزینه‌ای به‌مراتب بیشتر از انتخاب محصول اشتباه برای شما خواهد داشت. دسته اول یک اسکریپت کوچک در مرورگر بازدیدکننده اجرا کرده و گزارش‌های ارسالی آن را ذخیره می‌کند. دسته دوم، لاگ دسترسی (access log) که وب‌سرور شما از قبل می‌نویسد را می‌خواند. تمام مراحل بعدی، از جمله پایگاه داده و حافظه مورد نیاز، مستقیماً از همین انتخاب اولیه ناشی می‌شود.

پاسخ کوتاه برای یک سرور کوچک: GoatCounter و Medama روی 1 GB رم اجرا می‌شوند، زیرا هر کدام تنها یک پردازش روی یک فایل هستند. Umami یک کانتینر Postgres اضافه می‌کند و داشبوردی در اختیار شما می‌گذارد که برای افراد غیرفنی نیز قابل خواندن است. Plausible Community Edition و Rybbit هر دو از ClickHouse استفاده می‌کنند، بنابراین برای 2 GB رم یا بیشتر برنامه‌ریزی کنید. Matomo یک محصول کامل است و به سروری متناسب با حجم ترافیک شما نیاز دارد. GoAccess هیچ چیزی به صفحه اضافه نمی‌کند، زیرا صرفاً لاگی را می‌خواند که از قبل وجود دارد.

تگ اسکریپت یا لاگ سرور: هر کدام چه چیزی را می‌بینند

تگ اسکریپت، مرورگرها را اندازه‌گیری می‌کند. صفحه بارگذاری می‌شود، اسکریپت اجرا می‌گردد و یک درخواست به جمع‌آوری‌کننده (collector) شما ارسال می‌کند. هر چیزی که این زنجیره را قطع کند، برای شما نامرئی است: غیرفعال بودن JavaScript، لیست فیلتری که درخواست را مسدود می‌کند، شکست در ارسال درخواست به جمع‌آوری‌کننده، یا خزنده (crawler) که هرگز اسکریپت‌ها را اجرا نمی‌کند.

تجزیه‌کننده لاگ (log parser)، درخواست‌ها را اندازه‌گیری می‌کند. وب‌سرور شما برای هر درخواست یک خط می‌نویسد، فارغ از اینکه چیزی نصب کرده باشید یا خیر؛ بنابراین داده‌ها از قبل روی دیسک موجود هستند. این روش هر خزنده و هر بازدید از فایلی که تگ اسکریپت ندارد را می‌بیند. اما نمی‌تواند ببیند درون مرورگر چه اتفاقی افتاده است و نمی‌تواند صفحه‌ای که از کش مرورگر یا از یک CDN (شبکه توزیع محتوا) در مقابل سرور شما ارائه شده را ببیند، زیرا آن درخواست هرگز به سرور شما نرسیده است.

این دو عدد با هم مطابقت نخواهند داشت و هیچ‌کدام هم اشتباه نیستند. Matomo می‌تواند هر دو کار را انجام دهد و در مستندات خود توضیح می‌دهد که وارد کردن لاگ (log import) در مقایسه با ردیاب JavaScript چه مواردی را از دست می‌دهد: وضوح تصویر صفحه (screen resolution)، عناوین صفحات، رویدادها، ردیابی محتوا، نقشه‌های حرارتی (heatmaps)، ضبط نشست‌ها (session recordings) و تحلیل فرم‌ها. این لیست، بهای شمارش درخواست‌ها به‌جای شمارش مرورگرهاست.

ترافیک ربات‌ها نیمه دیگر این شکاف است. شمارش‌های مبتنی بر لاگ، خزنده‌ها را نیز شامل می‌شوند مگر اینکه آن‌ها را فیلتر کنید؛ و در یک سایت معمولی، سهم خزنده‌ها آن‌قدر بزرگ است که می‌تواند نتایج شما را تغییر دهد. GoAccess و قابلیت وارد کردن لاگ در Matomo، هر دو ربات‌های شناخته‌شده را فیلتر می‌کنند. هیچ‌کدام نمی‌توانند خزنده‌ای را که در مورد user agent خود دروغ می‌گوید فیلتر کنند؛ این دلیل خوبی است که هر نوع شمارش مبتنی بر لاگ را با مسدود کردن خزنده‌های هوش مصنوعی در سطح سرور همراه کنید و لاگ را پس از اعمال مسدودسازی بخوانید، نه پیش از آن.

GoAccess: تحلیل داده‌ها از لاگ‌های موجود

آن را از مخزن رسمی پروژه برای Debian و Ubuntu نصب کنید، زیرا بسته‌های موجود در مخازن توزیع‌ها معمولاً از نسخه‌های اصلی عقب‌تر هستند.

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

سپس آن را به سمت فایل لاگ هدایت کرده و یک گزارش ایستا (static) تهیه کنید.

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

این دستور برای یک کاربر عادی با خطای Permission denied مواجه می‌شود، زیرا در Ubuntu مالکیت لاگ‌های nginx در اختیار root و گروه adm است. با استفاده از sudo usermod -aG adm $USER خود را به این گروه اضافه کنید، سپس از سیستم خارج و دوباره وارد شوید، چرا که عضویت در گروه‌ها هنگام ورود به سیستم خوانده می‌شود. دستور id را اجرا کرده و پیش از تلاش مجدد، مطمئن شوید که adm در لیست ظاهر شده است.

گزارش روی لاگ زنده فقط شامل مواردی است که هنوز توسط logrotate جابه‌جا نشده‌اند. درخواست‌های دیروز در access.log.1 قرار دارند و فایل‌های قدیمی‌تر فشرده شده‌اند، بنابراین برای مشاهده گزارش هفتگی باید فایل‌های چرخش‌یافته (rotated) را نیز بخوانید.

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

یک حالت زنده به نام --real-time-html نیز وجود دارد که صفحه را از طریق WebSocket به‌روزرسانی می‌کند. این حالت به یک پورت دوم و قانون پروکسی اختصاصی نیاز دارد. برای اکثر سایت‌ها، یک گزارش ساعتی که توسط cron نوشته می‌شود کافی است و امنیت آن نیز ساده‌تر تأمین می‌شود.

GoatCounter: یک فایل اجرایی Go و یک فایل SQLite

نرم‌افزار GoatCounter به‌صورت یک فایل اجرایی کامپایل‌شده و ایستا (statically compiled) عرضه می‌شود، بنابراین نیازی به نصب هیچ محیط اجرایی (runtime) ندارد. می‌توانید نسخه build شده را از صفحه releases دریافت و اجرا کنید، یا از image آن استفاده نمایید.

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

هنگامی که به‌عنوان یک فایل اجرایی اجرا می‌شود، goatcounter serve روی پورت 8080 گوش می‌دهد و فایل SQLite را در مسیر ./goatcounter-data/db.sqlite3 ایجاد می‌کند. زمانی که نمونه (instance) برنامه پشت یک پروکسی قرار دارد، بهتر است اولین سایت را به‌جای استفاده از ویزارد وب، از طریق خط فرمان ایجاد کنید.

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

این برنامه می‌تواند با استفاده از goatcounter serve -listen=:443 -tls=tls,rdr,acme و پروتکل ACME (محیط مدیریت خودکار گواهی)، گواهی‌های TLS خود را مدیریت کند که برای سرورهایی که هیچ سرویس دیگری روی آن‌ها اجرا نمی‌شود، مفید است. در مواردی که Nginx یا Caddy پورت 443 را در اختیار دارند، GoatCounter را روی پورت 8080 باقی بگذارید و ترافیک را به آن پروکسی کنید. طبق اعلام پروژه، اسکریپت رهگیری (tracking script) حدود 3.5K حجم دارد و برای صفحاتی که از JavaScript استفاده نمی‌کنند، یک پیکسل رهگیری (tracking pixel) نیز در نظر گرفته شده است. اگر در سایت‌های پربازدید، SQLite به گلوگاه تبدیل شود، همین فایل اجرایی می‌تواند با استفاده از goatcounter serve -db 'postgresql+dbname=goatcounter' از Postgres پشتیبانی کند. پشتیبان‌گیری از این ابزار صرفاً با کپی کردن فایل انجام می‌شود که مهم‌ترین مزیت این ساختار نرم‌افزاری است.

Medama: یک کانتینر واحد با ادعای مصرف 256 مگابایت حافظه

Medama جدیدترین گزینه در این فهرست است که به صورت یک فایل باینری واحد ارائه می‌شود. این ابزار طبق طراحی، بدون کوکی کار می‌کند و پروژه ادعا می‌کند که حجم اسکریپت ردیاب آن کمتر از 1 کیلوبایت است. همچنین، این پروژه ادعا می‌کند که سایت‌های کوچک می‌توانند آن را روی ماشین‌های مجازی با 256 مگابایت حافظه اجرا کنند. این موارد ادعاهای منتشرشده توسط خود پروژه هستند و اعدادی نیستند که برای این راهنما اندازه‌گیری شده باشند.

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

دستور رسمی، پورت را به صورت 8080:8080 منتشر می‌کند. استفاده از پیشوند loopback در بالا عمدی است و بخش reverse proxy دلیل آن را توضیح می‌دهد. اولین ورود با نام کاربری admin و رمز عبور CHANGE_ME_ON_FIRST_LOGIN انجام می‌شود؛ نام آن رمز عبور، در واقع همان دستورالعمل ورود است.

یک حالت شکست مستند وجود دارد که ممکن است با آن مواجه شوید. ورود به سیستم فقط از طریق HTTPS یا روی localhost کار می‌کند؛ بنابراین اگر پیش از تنظیم گواهی، proxy را راه‌اندازی کنید، فرم ورود رمز عبور صحیح را رد می‌کند و دلیل آن نیز نمایش داده نمی‌شود. ابتدا تنظیمات TLS (امنیت لایه انتقال) را تکمیل کنید و سپس وارد شوید.

Umami: Postgres و داشبوردی که کاربران با آن آشنا هستند

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

این دستور برنامه را روی پورت 3000 به همراه یک کانتینر PostgreSQL در کنار آن اجرا می‌کند. مستندات، نسخه 12.14 از PostgreSQL را به عنوان حداقل نیاز و Node.js نسخه 18.18 یا جدیدتر را برای حالتی که قصد دارید از سورس کامپایل کنید، پیشنهاد می‌دهند. یک ایمیج از پیش ساخته شده به نام docker.umami.is/umami-software/umami:postgresql-latest وجود دارد که به متغیر DATABASE_URL نیاز دارد تا به دیتابیسی که از قبل اجرا کرده‌اید، اشاره کند.

نام کاربری برای اولین ورود admin و رمز عبور آن umami است. پیش از آنکه DNS را به سمت سرور تنظیم کنید، رمز عبور را تغییر دهید؛ زیرا به محض اینکه رکورد DNS حل شود و پروکسی پاسخ دهد، این نمونه از طریق اینترنت در دسترس خواهد بود. برای جزئیات مربوط به Compose، فایل‌های environment و سیاست restart، به جای کپی کردن یک stack که آن را مطالعه نکرده‌اید، به یک Docker Compose stack روی VPS مراجعه کنید.

میزان مصرف منابع این سرویس شامل یک پردازش Node و دیتابیس Postgres است. این ترکیب از یک فایل اجرایی تکی سنگین‌تر و از هر سیستمی که ClickHouse اجرا می‌کند، بسیار سبک‌تر است.

نسخه Plausible Community Edition: ClickHouse و حداقل حافظه رم

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

نسخه v3.2.1 تا اوت 2026 نسخه جاری است و دستور clone آن را به همین نسخه محدود می‌کند. این پشته از سه بخش تشکیل شده است: برنامه، Postgres برای حساب‌ها و تنظیمات، و ClickHouse برای داده‌های رویداد. مقدار SECRET_KEY_BASE باید حداقل یک رشته 64 بایتی باشد که خروجی فراخوانی openssl است.

نیازمندی‌های خود Plausible حداقل 2 گیگابایت رم را الزامی می‌داند تا ClickHouse و برنامه با مشکل out of memory killer مواجه نشوند؛ همچنین پردازنده باید از SSE 4.2 یا NEON پشتیبانی کند که برای ClickHouse ضروری است. این مورد دوم پیش از خرید ارزش بررسی دارد و یکی از تفاوت‌های عملی در انتخاب بین VPS با معماری ARM یا x86 است. ClickHouse تا جایی که تصور کند حافظه در دسترس است از آن استفاده می‌کند، بنابراین در یک سرور اشتراکی، طبق توضیحات محدود کردن حافظه کانتینر در Compose، یک سقف برای آن تعیین کنید.

مقدار BASE_URL باید دقیقاً با URL عمومی مطابقت داشته باشد. در غیر این صورت، پس از ورود، برنامه شما را به میزبان اشتباه هدایت می‌کند و کوکی نشست برای دامنه‌ای نوشته می‌شود که مرورگر شما در آن نیست؛ در نتیجه بدون دریافت هیچ پیام خطایی، دوباره به فرم ورود بازگردانده می‌شوید.

فایل compose ارائه‌شده پورتی را منتشر نمی‌کند، زیرا انتظار می‌رود یک پروکسی در مقابل آن قرار گیرد. یک override اضافه کنید که پورت پیش‌فرض برنامه را فقط روی loopback منتشر کند.

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

Matomo: محصول کامل و سروری که به آن نیاز دارد

Matomo روی PHP با MySQL یا MariaDB اجرا می‌شود، به این معنی که به‌جای پشته‌های کانتینری، با پشته‌های کلاسیک وب سازگار است. این ابزار همچنین تنها موردی در این لیست است که راهنمای سخت‌افزاری بر اساس حجم ترافیک منتشر می‌کند.

[
  {
    "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
  }
]

این‌ها حداقل‌های منتشرشده توسط Matomo تا اوت 2026 هستند و اندازه‌گیری‌های انجام‌شده برای این راهنما نیستند. تا 100,000 بازدید صفحه در ماه، این ابزار به 2 هسته CPU، 2 گیگابایت رم و 50 گیگابایت حافظه SSD نیاز دارد و یک سرور هم برنامه و هم پایگاه داده را میزبانی می‌کند. در 1M/month این مقدار به 8 گیگابایت رم و 250 گیگابایت دیسک می‌رسد. در 10M/month، Matomo دو سرور را پیشنهاد می‌دهد و ردیف آخر سرور پایگاه داده را نشان می‌دهد: 16 گیگابایت رم و 400 گیگابایت دیسک. این ارقام دیسک را در کنار گزینه‌های تک‌فایلی (binary) بخوانید، جایی که کل مجموعه داده یک فایل SQLite است.

بایگانی (Archiving) چیزی است که کاربران را غافلگیر می‌کند. به‌طور پیش‌فرض، Matomo گزارش‌های خود را زمانی که شخصی داشبورد را باز می‌کند می‌سازد؛ بنابراین با رشد داده‌ها، داشبورد کندتر شده و در نهایت با خطای timeout مواجه می‌شود. راه‌حل مستند این است که بایگانیِ مبتنی بر مرورگر را در تنظیمات عمومی غیرفعال کنید و archiver را از طریق cron، با کاربری که مالک فایل‌های Matomo است و از داخل دایرکتوری Matomo اجرا کنید.

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

Matomo همچنین جداول لاگ خام را در کنار جداول گزارش‌های پردازش‌شده نگه می‌دارد و می‌تواند داده‌های خام قدیمی و گزارش‌های قدیمی را طبق زمان‌بندی حذف کند. این قابلیت را هنگام نصب فعال کنید، نه زمانی که دیسک پر شده است. Matomo همچنین می‌تواند لاگ‌های دسترسی سرور را وارد (import) کند، که آن را به تنها محصول در این لیست تبدیل می‌کند که هر دو خانواده را همزمان پوشش می‌دهد.

Rybbit و پشته‌های جدیدتر

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

Rybbit یک ابزار تازه وارد با داشبوردی مدرن است. اسکریپت راه‌اندازی آن، فایل environment را می‌نویسد و پشته را با استفاده از Docker Compose بالا می‌آورد. این ابزار از ClickHouse استفاده می‌کند و به همراه Caddy به عنوان وب‌سرور اختصاصی عرضه می‌شود که پورت 443 را اشغال کرده و برای دامنه‌ای که وارد کرده‌اید، گواهی درخواست می‌کند. در سروری که nginx از قبل پورت 443 را در اختیار دارد، اسکریپت قادر به bind کردن نخواهد بود؛ بنابراین از روش دستی Compose پروژه استفاده کنید و آن را پشت پروکسی فعلی خود قرار دهید. مستندات حداقل 2 GB رم را توصیه می‌کنند و تست‌ها روی Ubuntu 24 LTS و معماری ARMv8.2-A یا جدیدتر (به دلیل نیازهای ClickHouse) انجام شده است.

یک هشدار صادقانه برای هر پروژه نوپا: قابلیت‌ها به سرعت اضافه می‌شوند و تغییرات ساختارشکن (breaking changes) نیز به همین ترتیب رخ می‌دهند. همیشه یک تگ خاص را pin کنید، پیش از pull کردن یادداشت‌های انتشار (release notes) را بخوانید و ابتدا از دیتابیس نسخه پشتیبان تهیه کنید.

نگهداری داده‌ها و رشد دیسک: اندازه‌گیری روی سرور شخصی

رشد دیسک به نوع داده‌هایی بستگی دارد که ابزار برای هر رویداد ذخیره می‌کند. GoatCounter بازدیدها را در شمارنده‌ها تجمیع می‌کند، بنابراین حجم فایل آن بیشتر از آنکه به حجم خام ترافیک وابسته باشد، به تعداد صفحات و روزهای منحصربه‌فرد بستگی دارد. Umami و Matomo برای هر رویداد یک ردیف ذخیره می‌کنند و Matomo علاوه بر داده‌های خام، جداول گزارش‌های پردازش‌شده را نیز نگه می‌دارد. ClickHouse رویدادها را به‌صورت ستونی ذخیره کرده و به‌شدت فشرده‌سازی می‌کند؛ به همین دلیل Plausible می‌تواند ترافیکی را مدیریت کند که برای یک پایگاه‌داده ردیفی (row store) سنگین است.

این راهنما عدد مشخصی برای مگابایت به ازای هر میلیون بازدید ارائه نمی‌دهد، زیرا این مقدار را روی ترافیک شما اندازه‌گیری نکرده است. خودتان این اندازه‌گیری را انجام دهید. نام سرویس و کاربر را مطابق با فایل Compose خود تنظیم کنید.

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"

عدد را یادداشت کنید، یک هفته صبر کنید، دوباره آن را ثبت کنید و اختلاف را بر تعداد بازدیدهای گزارش‌شده در داشبورد برای آن هفته تقسیم کنید. آن عدد مختص سایت شما و فیلترینگ ربات‌های شماست، بنابراین از هر میانگین منتشرشده‌ای ارزشمندتر است. سپس در حالی که حجم داده هنوز کم است، یک محدودیت برای نگهداری (retention limit) تعیین کنید. پر شدن کامل دیسک باعث از کار افتادن تمام سرویس‌های روی VPS می‌شود، نه فقط سرویس تحلیل؛ این قوی‌ترین دلیل برای نگهداری volume پایگاه‌داده در جایی است که df -h در مورد آن هشدار خواهد داد. این ریسک در سروری که از قبل میزبان داده‌های حجیم است، نیاز به توجه بیشتری دارد، زیرا یک سرور عکس self-hosted بسیار زودتر از هر پایگاه‌داده تحلیلی، فضای دیسک را تمام خواهد کرد.

نحوه عملکرد پشت یک reverse proxy روی زیردامنه

collector را روی یک زیردامنه از سایتی که اندازه‌گیری می‌کند قرار دهید، مانند stats.example.com. این کار باعث می‌شود درخواست‌های collector به عنوان first-party شناخته شوند، بنابراین تحت تأثیر قوانین مرورگر که درخواست‌های third-party را مسدود می‌کنند، قرار نمی‌گیرند.

هنگام انتشار پورت container، برنامه را به loopback متصل کنید. Docker قوانین فایروال خود را پیش از ufw اعمال می‌کند، بنابراین container منتشرشده به صورت -p 3000:3000 از اینترنت قابل دسترسی است، حتی اگر ufw status بگوید که پورت مسدود شده است. آن را از یک ماشین دیگر با curl http://SERVER_IP:3000 تست کنید؛ داشبورد را دریافت خواهید کرد. اگر به صورت -p 127.0.0.1:3000:3000 منتشر شود، همان تست نتیجه Connection refused را می‌دهد و فقط proxy می‌تواند به آن دسترسی داشته باشد.

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;
    }
}

هدرهای forwarding در اینجا اختیاری نیستند. بدون X-Forwarded-For، هر بازدید از سمت 127.0.0.1 می‌آید، بنابراین گزارش کشور خالی می‌ماند و بازدیدکنندگان یکتا همگی در یک دسته قرار می‌گیرند. هر پروژه تعیین می‌کند که به کدام هدر و تحت چه تنظیمی اعتماد دارد، بنابراین به جای فرض کردن، یک بار مستندات proxy آن را بررسی کنید. Caddy این هدرها را به‌طور خودکار تنظیم می‌کند و یک Caddyfile برای همین کار تنها دو خط است.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

اگر هنوز proxy انتخاب نکرده‌اید، مقایسه nginx، Caddy و Traefik بررسی می‌کند که کدام‌یک برای یک سرور واحد با چند زیردامنه مناسب‌تر است.

آیا در صورت self-hosting همچنان به بنر کوکی نیاز دارید؟

میزبانی شخصی (self-hosting) تغییر می‌دهد که چه کسی داده‌ها را در اختیار دارد، اما قوانین مربوط به آن داده‌ها را تغییر نمی‌دهد. دو قاعده را از هم تفکیک کنید. قانون رضایت ePrivacy مربوط به ذخیره یا خواندن هرگونه اطلاعات روی دستگاه بازدیدکننده است؛ بنابراین ابزاری که هیچ کوکی تنظیم نمی‌کند و چیزی در local storage نمی‌نویسد، خارج از این الزام خاص قرار می‌گیرد. GDPR مربوط به پردازش داده‌های شخصی است و از آنجا که آدرس IP جزو داده‌های شخصی محسوب می‌شود، شما همچنان به یک مبنای قانونی، محدودیت در نگهداری داده‌ها و پاسخی برای زمانی که فردی درباره داده‌های ذخیره‌شده‌اش از شما سوال می‌پرسد، نیاز دارید.

ابزارهای Plausible، Umami، GoatCounter و Medama به‌صورت پیش‌فرض هیچ کوکی تنظیم نمی‌کنند. آنچه هر کدام به جای آن استخراج می‌کنند، در هر پروژه متفاوت است و بین نسخه‌ها تغییر می‌کند؛ بنابراین به‌جای تکیه بر خلاصه‌ها، مستندات حریم خصوصی خودِ پروژه را مطالعه کنید. Matomo قابلیت ناشناس‌سازی IP و یک endpoint برای انصراف (opt out) ارائه می‌دهد که می‌توانید آن را در رابط کاربری مدیریت فعال کنید.

نهادهای نظارتی در کشورهای مختلف به نتایج متفاوتی می‌رسند. برای مثال، سازمان CNIL در فرانسه شرایطی را منتشر کرده است که تحت آن، سنجش مخاطبان می‌تواند از دریافت رضایت معاف باشد. این بخش یک خلاصه واقعی است و مشاوره حقوقی محسوب نمی‌شود. برای یک وب‌سایت واقعی با کاربران واقعی، با یک وکیل در حوزه قضایی خود مشورت کنید.

نکته‌ای که افراد از آن غافل می‌شوند این است که لاگ دسترسی (access log) نیز داده شخصی محسوب می‌شود. ابزار GoAccess هیچ اسکریپتی به صفحه اضافه نمی‌کند، اما همچنان آدرس‌های IP را پردازش می‌کند؛ بنابراین تحلیل‌های مبتنی بر لاگ به‌طور خودکار خارج از قوانین نیستند.

مسدودکننده‌های تبلیغات و دلیل کاهش آمار شما

لیست‌های فیلتر بر اساس نام دامنه (hostname) و الگوی URL عمل می‌کنند. شناسایی یک محصول تحلیلگر میزبانی‌شده (hosted) آسان است، زیرا همه آن را از یک نام دامنهٔ شناخته‌شده بارگذاری می‌کنند. انتقال جمع‌آوری‌کننده (collector) به زیردامنهٔ اختصاصی خودتان، آن نام دامنه را از درخواست حذف می‌کند و ارائهٔ اسکریپت از مسیری که خودتان انتخاب کرده‌اید، نام فایل شناخته‌شده را از بین می‌برد. هر دو مورد، معیارهای تطبیق لیست‌های فیلتر را تغییر می‌دهند.

این مطلب ادعایی دربارهٔ نرخ موفقیت (hit rate) ندارد، زیرا چنین موردی اندازه‌گیری نشده است. سهم بازدیدکنندگانی که یک تنظیمات خاص را مسدود می‌کنند به مخاطبان شما بستگی دارد؛ مخاطبان توسعه‌دهنده بسیار بیشتر از مخاطبان عمومی، محتوا را مسدود می‌کنند. شکاف آماری خود را اندازه‌گیری کنید. در طول یک هفته، درخواست‌های صفحات HTML را در لاگ دسترسی با استفاده از GoAccess بشمارید و آن را با تعداد بازدیدهای گزارش‌شده توسط ابزار مبتنی بر اسکریپت خود مقایسه کنید. تفاوت این دو، مجموع بازدیدهای مسدودشده و صفحاتی است که از حافظهٔ پنهان (cache) در سایت شما بارگذاری شده‌اند.

انتظار داشته باشید که آمار کلی در روزی که از یک محصول میزبانی‌شده به سیستم خود مهاجرت می‌کنید تغییر کند، و بدانید که بخشی از این تغییر هیچ ارتباطی به مسدودسازی ندارد. محصولات مختلف در تعریف «بازدید صفحه» (pageview)، اینکه آیا تغییر مسیر در یک برنامهٔ تک‌صفحه‌ای (SPA) یک بازدید محسوب می‌شود یا خیر، و زمان پایان یک نشست (session) با هم اختلاف نظر دارند. پیش از آنکه نتیجه بگیرید ترافیک کاهش یافته است، روندها را در طول چند هفته با هم مقایسه کنید.

کدام ابزار برای کدام سایت

• یک سایت شخصی یا وبلاگ با بازدید کمتر از 50,000 صفحه در ماه: GoatCounter یا Medama، روی یک VPS با 1 GB رم، به همراه پشتیبان‌گیری از طریق کپی فایل.
• سایتی که امکان افزودن اسکریپت در آن وجود ندارد، یا مخاطبانی که به شدت اسکریپت‌ها را مسدود می‌کنند: GoAccess روی لاگ‌های موجود، به صورت زمان‌بندی شده.
• سایت یک کسب‌وکار کوچک که فرد دیگری داشبورد را بررسی می‌کند: Umami، به همراه کانتینر Postgres آن.
• سایتی که در آن به دنبال تعریف اهداف (goals) و قیف‌های تبدیل (funnels) هستید، روی سروری با 2 GB رم یا بیشتر: Plausible Community Edition، یا اگر داشبورد جدیدتر می‌خواهید و یک پروژه نوپا را می‌پذیرید، Rybbit.
• سایت‌های متعدد، حساب‌های کاربری زیاد، یا نیاز به نگهداری داده‌های خام طبق سیاست‌های حفظ دادهٔ خودتان: Matomo، با ابعاد پیشنهادی طبق راهنمای رسمی آن که در بالا ذکر شد.

با کوچک‌ترین ابزاری که به نیاز واقعی شما پاسخ می‌دهد شروع کنید. مهاجرت از GoatCounter به Plausible در آینده، تنها هزینهٔ یک زیردامنه و مقداری از تاریخچهٔ داده‌ها را برای شما خواهد داشت. اما مهاجرت از Matomo به هر ابزار دیگری، مستلزم یک فرآیند انتقال دشوار است که از آن لذت نخواهید برد. اگر هنوز در حال تصمیم‌گیری برای سایر سرویس‌های قابل میزبانی روی همان سرور هستید، بررسی جامع خودمیزبانی (self-hosting) مواردی که در کنار این ابزارها جای می‌گیرند را پوشش می‌دهد، و اگر آنچه واقعاً نیاز دارید ردیابی درخواست‌ها در سطح اپلیکیشن است و نه شمارش بازدیدکنندگان، یک سرویس مشاهده‌پذیری (observability) خودمیزبان ابزار مناسب برای آن کار است.

FAQ

آیا میزبانی شخصی (self-hosting) ابزارهای تحلیل، نیاز به بنر کوکی را از بین می‌برد؟

خیر، این دو موضوع از هم جدا هستند. قانون رضایت در ePrivacy، ذخیره یا خواندن هرگونه داده روی دستگاه بازدیدکننده را پوشش می‌دهد؛ بنابراین ابزاری که هیچ کوکی تنظیم نمی‌کند و چیزی در local storage نمی‌نویسد، از این الزام خاص معاف است. اما GDPR قانون متفاوتی است و پردازش داده‌های شخصی را پوشش می‌دهد؛ از آنجا که آدرس IP دادهٔ شخصی محسوب می‌شود، حتی بدون کوکی نیز به مبنای قانونی و محدودیت نگهداری داده نیاز دارید. میزبانی شخصی، داده‌ها را به سرور شما منتقل می‌کند و شما را به عنوان مسئول آن داده‌ها تعیین می‌کند. دستورالعمل‌های نهاد نظارتی خود را بررسی کنید و برای مورد خاص خود با یک وکیل مشورت کنید.

ابزارهای تحلیل با میزبانی شخصی به چه مقدار RAM روی یک VPS نیاز دارند؟

این موضوع به datastore بستگی دارد، نه به داشبورد. GoatCounter و Medama به صورت یک پردازش واحد روی یک فایل اجرا می‌شوند و مستندات Medama بیان می‌کند که سایت‌های کوچک روی ماشین‌هایی با 256 MB RAM اجرا می‌شوند. Umami یک container دیتابیس Postgres در کنار یک برنامه Node اضافه می‌کند. Plausible Community Edition و Rybbit هر دو از ClickHouse استفاده می‌کنند و هر دو پروژه حداقل 2 GB RAM را توصیه کرده‌اند. دستورالعمل رسمی Matomo برای حداکثر 100,000 بازدید صفحه در ماه، با 2 هسته CPU و 2 GB رم شروع می‌شود.

چرا آمار ابزار میزبانی شخصی من کمتر از ابزار تحلیلی است که جایگزین کردم؟

دو دلیل وجود دارد که هر دو واقعی هستند. لیست‌های فیلتر، برخی از درخواست‌های جمع‌آوری داده را مسدود می‌کنند، بنابراین تمام ابزارهای مبتنی بر اسکریپت این بازدیدها را از دست می‌دهند. همچنین محصولات مختلف، آمار را به شکل متفاوتی محاسبه می‌کنند؛ چرا که تعریف «بازدید صفحه» (pageview) و زمان پایان یک نشست (session) بین آن‌ها متفاوت است. یک هفته درخواست‌های صفحه HTML از لاگ دسترسی (access log) خود را با همان هفته از بازدیدهای مبتنی بر اسکریپت مقایسه کنید. این اختلاف، مجموع بازدیدهای مسدودشده و صفحات کش‌شده است که به جای تکیه بر نرخ‌های اعلامی دیگران، مستقیماً روی سایت خودتان اندازه‌گیری شده است.

آیا می‌توانم Plausible یا Rybbit را روی یک VPS با معماری ARM اجرا کنم؟

هر دو از ClickHouse استفاده می‌کنند و ClickHouse روی معماری x86 به SSE 4.2 و روی ARM به NEON نیاز دارد. الزامات Plausible دقیقاً به همین موضوع اشاره دارد و مستندات Rybbit بیان می‌کند که سیستم‌های ARM به ARMv8.2-A یا جدیدتر نیاز دارند. هسته‌های سرور ARM امروزی این استاندارد را دارند، اما مدل‌های قدیمی‌تر خیر. در صورت عدم پشتیبانی، ClickHouse به دلیل خطای مجموعه دستورالعمل (instruction set error) اجرا نمی‌شود و این خطا در لاگ برنامه دیده نمی‌شود. در یک سیستم ARM کوچک، ابزارهای تک‌فایلی این مشکل را ندارند، زیرا هیچ‌کدام از آن‌ها از ClickHouse استفاده نمی‌کنند.

آیا باید به جای استفاده از اسکریپت ردیابی، لاگ‌های سرور را تحلیل کنم؟

زمانی از تحلیل لاگ استفاده کنید که امکان افزودن اسکریپت ندارید، مخاطبان شما به شدت اسکریپت‌ها را مسدود می‌کنند، یا می‌خواهید آماری داشته باشید که شامل خزنده‌ها (crawlers) نیز باشد. GoAccess لاگ‌هایی را که سرور شما از قبل می‌نویسد می‌خواند، بنابراین هیچ بار اضافی به صفحه تحمیل نمی‌کند و نیازی به دیتابیس ندارد. در این روش، تمام رویدادهای داخل مرورگر را از دست می‌دهید و صفحاتی که از طریق CDN یا کش مرورگر سرو می‌شوند نیز محاسبه نمی‌شوند، زیرا آن درخواست‌ها هرگز به سرور شما نرسیده‌اند. بسیاری از سایت‌ها از هر دو روش استفاده می‌کنند و آن‌ها را به عنوان دو معیار متفاوت در نظر می‌گیرند.