بهترین ابزارهای تحلیل وب 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 خود دروغ می‌گوید فیلتر کنند؛ که این خود دلیلی موجه برای ترکیب هر نوع شمارش مبتنی بر لاگ با مسدود کردن خزنده‌های AI در سطح سرور و خواندن لاگ پس از اعمال مسدودسازی، به‌جای پیش از آن است.

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 به صورت یک باینری کامپایل‌شدهٔ ایستا عرضه می‌شود، بنابراین هیچ runtime خاصی برای نصب نیاز ندارد. یک نسخه build را از صفحه release دریافت کرده و اجرا کنید، یا از image آن استفاده نمایید.

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

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

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

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

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

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

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 کار می‌کند؛ بنابراین اگر پیش از تنظیم گواهی، پروکسی را راه‌اندازی کنید، فرم ورود رمز عبور صحیح را رد می‌کند و دلیل آن نیز نمایش داده نمی‌شود. ابتدا تنظیمات 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، به یک Docker Compose stack روی VPS مراجعه کنید و از کپی کردن stackهایی که مطالعه نکرده‌اید، خودداری کنید.

ردپای منابع این سرویس شامل یک پردازش 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 file) را می‌نویسد و پشته را با استفاده از Docker Compose بالا می‌آورد. این ابزار از ClickHouse استفاده می‌کند و Caddy را به عنوان وب‌سرور داخلی خود ارائه می‌دهد که پورت 443 را اشغال کرده و برای دامنه‌ای که وارد کرده‌اید، گواهی TLS درخواست می‌کند. در سروری که nginx از قبل پورت 443 را در اختیار دارد، اسکریپت قادر به bind کردن نخواهد بود؛ بنابراین از روش دستی Compose در پروژه استفاده کنید و آن را پشت پروکسی فعلی خود قرار دهید. مستندات حداقل 2 GB رم، تست روی Ubuntu 24 LTS و معماری ARMv8.2-A یا جدیدتر برای ARM (به دلیل نیازهای ClickHouse) را توصیه می‌کنند.

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

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

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

این راهنما عدد مشخصی برای مگابایت به ازای هر میلیون بازدید ارائه نمی‌دهد، زیرا این مقدار را روی ترافیک شما اندازه‌گیری نکرده است. خودتان این اندازه‌گیری را انجام دهید. نام سرویس و کاربر را مطابق با فایل 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) تعیین کنید. پر شدن کامل دیسک باعث از کار افتادن تمام سرویس‌های روی VPS می‌شود، نه فقط سرویس تحلیل؛ این قوی‌ترین دلیل برای نگهداری volume پایگاه‌داده در جایی است که df -h درباره آن هشدار می‌دهد. این ریسک در سروری که از قبل میزبان داده‌های حجیم است، توجه بیشتری می‌طلبد، زیرا یک سرور عکس self-hosted بسیار زودتر از هر پایگاه‌داده تحلیلی، فضای دیسک را تمام خواهد کرد.

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

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

هنگام انتشار پورت container، برنامه را به loopback bind کنید. Docker قوانین firewall خود را پیش از ufw اعمال می‌کند؛ بنابراین containerی که به‌صورت -p 3000:3000 منتشر شده است، حتی زمانی که ufw status اعلام می‌کند پورت مسدود است، از اینترنت قابل دسترسی خواهد بود. آن را از یک ماشین دیگر با curl http://SERVER_IP:3000 آزمایش کنید تا dashboard را دریافت کنید. اگر به‌صورت -p 127.0.0.1:3000:3000 منتشر شود، همین آزمایش Connection refused را برمی‌گرداند و فقط proxy می‌تواند به آن دسترسی داشته باشد. این رویه فقط برای پنهان‌کردن dashboard نیست؛ هستهٔ اجرای یک onion service روی همان سرور نیز محسوب می‌شود، زیرا هر سرویسی که همچنان در public interface پاسخ دهد، آدرس پنهان را به IP شما مرتبط می‌کند. endpoint مربوط به collector باید از اینترنت عمومی قابل دسترسی بماند، اما dashboard چنین الزامی ندارد. اگر ترجیح می‌دهید آن را از طریق یک شبکهٔ خصوصی بخوانید و subdomain دومی منتشر نکنید، اعلام شبکهٔ VPS به tailnet با subnet router این امکان را بدون بازکردن پورت فراهم می‌کند.

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) همچنان به بنر کوکی نیاز دارید؟

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

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

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

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

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

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

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

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

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

• یک سایت شخصی یا وبلاگ با بازدید کمتر از حدود 50,000 صفحه در ماه: GoatCounter یا Medama، روی یک VPS با 1 GB رم، به همراه پشتیبان‌گیری از طریق کپی فایل.
• سایتی که امکان افزودن اسکریپت در آن وجود ندارد، یا مخاطبانی که به‌شدت اسکریپت‌ها را مسدود می‌کنند: GoAccess روی لاگ‌های موجود، به‌صورت زمان‌بندی‌شده.
• سایت یک کسب‌وکار کوچک که فرد دیگری داشبورد را بررسی می‌کند: Umami، به همراه کانتینر Postgres آن.
• سایتی که در آن به دنبال تعریف هدف (Goal) و قیف فروش (Funnel) هستید، روی سروری با 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 یا کش مرورگر بارگذاری می‌شوند نیز محاسبه نمی‌شوند، زیرا آن درخواست‌ها هرگز به سرور شما نرسیده‌اند. بسیاری از سایت‌ها از هر دو روش استفاده می‌کنند و آن‌ها را به عنوان دو اندازه‌گیری متفاوت در نظر می‌گیرند.