VPS پر self-hosted web analytics کے لیے بہترین tool

آپ کو VPS پر کون سا self-hosted web analytics tool چلانا چاہیے؟

Self-hosted web analytics دو خاندانوں میں تقسیم ہوتا ہے، اور غلط خاندان کا انتخاب غلط product کے انتخاب سے زیادہ مہنگا پڑتا ہے۔ ایک خاندان visitor کے browser میں ایک چھوٹی script چلاتا ہے اور وہ script جو معلومات بھیجتی ہے انہیں محفوظ کرتا ہے۔ دوسرا خاندان وہ access log پڑھتا ہے جو web server پہلے ہی لکھ رہا ہوتا ہے۔ اس کے بعد database اور مطلوبہ memory سمیت باقی تمام فیصلے اسی ایک انتخاب سے طے ہوتے ہیں۔

چھوٹے server کے لیے مختصر جواب یہ ہے: GoatCounter اور Medama، 1 GB میں چل جاتے ہیں، کیونکہ ہر ایک ایک file پر ایک process چلاتا ہے۔ Umami ایک Postgres container شامل کرتا ہے اور ایسا dashboard فراہم کرتا ہے جسے non-technical شخص بھی سمجھ سکتا ہے۔ Plausible Community Edition اور Rybbit دونوں ClickHouse چلاتے ہیں، اس لیے 2 GB RAM یا اس سے زیادہ کا منصوبہ بنائیں۔ Matomo مکمل product ہے اور آپ کے traffic کے مطابق server کا سائز درکار ہوتا ہے۔ GoAccess صفحے میں کچھ بھی شامل نہیں کرتا، کیونکہ یہ پہلے سے موجود log پڑھتا ہے۔

اسکرپٹ ٹیگ یا سرور لاگ: ہر ایک کیا دیکھ سکتا ہے

اسکرپٹ ٹیگ browsers کی پیمائش کرتا ہے۔ صفحہ load ہوتا ہے، اسکرپٹ چلتا ہے، اور یہ آپ کے collector کو ایک request بھیجتا ہے۔ اس سلسلے میں خلل ڈالنے والی ہر چیز آپ سے پوشیدہ رہتی ہے: JavaScript بند ہو، کوئی filter list request کو block کر دے، collector کو request ناکام ہو جائے، یا کوئی crawler اسکرپٹ چلائے ہی نہ۔

لاگ parser requests کی پیمائش کرتا ہے۔ آپ کا web server ہر request کے لیے ایک لائن لکھتا ہے، چاہے آپ کچھ install کریں یا نہ کریں، اس لیے data پہلے ہی disk پر موجود ہوتا ہے۔ یہ ہر crawler اور ایسی file پر آنے والی ہر hit دیکھتا ہے جس میں script tag موجود نہ ہو۔ یہ browser کے اندر ہونے والی کارروائی نہیں دیکھ سکتا۔ یہ browser cache یا آپ کے server کے سامنے موجود CDN (content delivery network) سے serve ہونے والا صفحہ بھی نہیں دیکھ سکتا، کیونکہ وہ request آپ کے server تک پہنچی ہی نہیں۔

دونوں numbers ایک جیسے نہیں ہوں گے، اور ان میں سے کوئی بھی غلط نہیں ہے۔ Matomo دونوں طریقے استعمال کر سکتا ہے۔ Matomo کی documentation میں بتایا گیا ہے کہ اس کا log import، JavaScript tracker کے مقابلے میں، کن معلومات کو چھوڑ دیتا ہے: screen resolution اور page titles، events، content tracking، heatmaps، session recordings اور form analytics۔ browsers کے بجائے requests گننے کی یہی قیمت ہے۔

Bot traffic اس فرق کا دوسرا بڑا سبب ہے۔ Log-based counts میں crawlers شامل ہوتے ہیں، جب تک آپ انہیں filter نہ کریں۔ عام site پر crawlers کا حصہ اتنا زیادہ ہو سکتا ہے کہ آپ کے نتائج بدل جائیں۔ GoAccess اور Matomo's log import دونوں known bots کو filter کرتے ہیں۔ ان میں سے کوئی بھی ایسے crawler کو filter نہیں کر سکتا جو اپنے user agent کے بارے میں جھوٹ بولتا ہو۔ اسی لیے log-based counting کو server پر AI crawlers کو block کرنا کے ساتھ استعمال کرنا بہتر ہے، اور block سے پہلے کے بجائے block کے بعد لاگ پڑھنا چاہیے۔

GoAccess: آپ کے پاس پہلے سے موجود log سے analytics

اسے project کی اپنی Debian اور Ubuntu repository سے install کریں، کیونکہ distribution packages releases سے پیچھے رہتے ہیں۔

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

پھر اسے log فراہم کریں اور ایک static report لکھیں۔

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

عام user کے لیے یہ command Permission denied کے ساتھ fail ہوتی ہے، کیونکہ Ubuntu میں nginx log کی ownership root کے پاس ہوتی ہے اور اس کا group adm ہوتا ہے۔ sudo usermod -aG adm $USER کے ذریعے خود کو اس group میں شامل کریں، پھر log out کرکے دوبارہ log in کریں، کیونکہ group membership login کے وقت پڑھا جاتا ہے۔ id چلائیں اور دوبارہ کوشش کرنے سے پہلے تصدیق کریں کہ فہرست میں adm موجود ہے۔

live log پر بنائی گئی report صرف وہی data شامل کرتی ہے جسے logrotate نے ابھی منتقل نہیں کیا۔ کل کی requests access.log.1 میں موجود ہوتی ہیں، جبکہ اس سے پرانی files compressed ہوتی ہیں۔ اس لیے weekly view کے لیے rotated files بھی پڑھنا ضروری ہے۔

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

ایک live mode بھی موجود ہے، --real-time-html، جو WebSocket کے ذریعے page update کرتا ہے۔ اس کے لیے دوسرا port اور اپنی proxy rule درکار ہوتی ہے۔ زیادہ تر sites کے لیے cron کے ذریعے ہر گھنٹے لکھی جانے والی report کافی ہوتی ہے، اور اس میں secure کرنے کے لیے کم چیزیں ہوتی ہیں۔

GoatCounter: ایک Go binary اور ایک SQLite file

GoatCounter ایک statically compiled binary کے طور پر release ہوتا ہے، اس لیے کوئی runtime install کرنے کی ضرورت نہیں۔ release page سے build حاصل کرکے اسے چلائیں، یا image استعمال کریں۔

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

binary کے طور پر چلانے پر، goatcounter serve port 8080 پر listen کرتا ہے اور ./goatcounter-data/db.sqlite3 پر SQLite database بناتا ہے۔ جب instance پہلے ہی proxy کے پیچھے ہو تو پہلا site web wizard کے بجائے command line سے بنائیں۔

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

یہ goatcounter serve -listen=:443 -tls=tls,rdr,acme کے ذریعے اپنا certificate بھی manage کر سکتا ہے اور ACME (automatic certificate management environment) استعمال کرتا ہے۔ یہ ایسے server پر مفید ہے جہاں کوئی دوسری سروس نہ چل رہی ہو۔ اگر port 443 پہلے سے nginx یا Caddy کے زیرِ انتظام ہو تو GoatCounter کو port 8080 پر چلنے دیں اور اس کی طرف proxy کریں۔ project کے اپنے اندازے کے مطابق tracking script تقریباً 3.5K کا ہے، اور ان pages کے لیے tracking pixel بھی موجود ہے جن میں JavaScript شامل نہیں ہوتی۔ اگر مصروف site پر SQLite حد بن جائے تو یہی binary goatcounter serve -db 'postgresql+dbname=goatcounter' کے ذریعے Postgres استعمال کر سکتی ہے۔ Backups ایک file copy کی صورت میں ہوتے ہیں، اور یہی اس tool کے اس ڈیزائن کی بنیادی وجہ ہے۔

Medama: ایک single container جو 256 MB کا دعویٰ کرتا ہے

Medama اس فہرست میں جدید ترین single binary آپشن ہے۔ اسے ڈیزائن کے لحاظ سے cookies کی ضرورت نہیں، اور project کے مطابق tracker 1 KB سے کم ہے۔ project یہ بھی بتاتا ہے کہ چھوٹی sites 256 MB memory والی virtual machines پر چل سکتی ہیں۔ یہ project کے شائع کردہ دعوے ہیں، اس guide کے لیے ناپے گئے اعداد نہیں۔

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

official command port کو 8080:8080 کے طور پر publish کرتا ہے۔ اوپر دیا گیا loopback prefix دانستہ ہے، اور reverse proxy والا section اس کی وجہ بیان کرتا ہے۔ پہلی login admin سے ہوتی ہے، password CHANGE_ME_ON_FIRST_LOGIN ہے، اور اس password کا نام ہی instruction ہے۔

ایک documented failure mode آپ کو روک سکتا ہے۔ login صرف HTTPS یا localhost پر کام کرتی ہے۔ اس لیے اگر certificate سے پہلے proxy setup کریں تو form درست password بھی reject کر دیتا ہے، اور وجہ ظاہر نہیں ہوتی۔ پہلے TLS (transport layer security) setup مکمل کریں، پھر login کریں۔

Umami: Postgres، اور ایسا dashboard جسے لوگ پہچانتے ہیں

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

یہ application کو port 3000 پر شروع کرتا ہے اور اس کے ساتھ PostgreSQL container چلاتا ہے۔ دستاویزات کے مطابق کم از کم PostgreSQL v12.14 درکار ہے۔ اگر آپ source سے build کریں تو Node.js 18.18 یا اس کے بعد کا ورژن چاہیے۔ ایک prebuilt image بھی دستیاب ہے، docker.umami.is/umami-software/umami:postgresql-latest، جس کے لیے DATABASE_URL کو پہلے سے چل رہے database کی طرف point کرنا ضروری ہے۔

پہلا login admin ہے اور password umami ہے۔ DNS کو اس server کی طرف point کرنے سے پہلے اسے تبدیل کریں، کیونکہ record resolve ہوتے ہی اور proxy کے جواب دینے پر instance internet سے قابل رسائی ہو جاتا ہے۔ Compose کی تفصیلات، environment files اور restart policy کے لیے VPS پر Docker Compose stack دیکھیں۔ ایسی stack copy نہ کریں جسے آپ نے پڑھا نہ ہو۔

اس deployment میں ایک Node process اور Postgres شامل ہیں۔ یہ single binary سے زیادہ وسائل استعمال کرتا ہے، لیکن ClickHouse چلانے والی کسی بھی چیز سے بہت کم وسائل لیتا ہے۔

Plausible Community Edition: ClickHouse کم از کم RAM طے کرتا ہے

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

August 2026 تک Version v3.2.1 موجودہ version ہے، اور clone command جان بوجھ کر اسی version پر قائم کی گئی ہے۔ اس stack کے تین حصے ہیں: application، accounts اور settings کے لیے Postgres، اور event data کے لیے ClickHouse۔ SECRET_KEY_BASE کم از کم 64 byte کی string ہونی چاہیے، جو openssl call تیار کرتی ہے۔

Plausible کی اپنی requirements میں کم از کم 2 GB RAM شامل ہے، تاکہ ClickHouse اور application out of memory killer کا شکار نہ ہوں۔ اس کے لیے ایسا CPU بھی درکار ہے جو SSE 4.2 یا NEON کو support کرے، کیونکہ ClickHouse کو یہ درکار ہے۔ VPS خریدنے سے پہلے اس دوسری requirement کی جانچ کرنا مفید ہے۔ یہ ARM اور x86 VPS میں انتخاب کے عملی فرقوں میں سے ایک ہے۔ ClickHouse دستیاب سمجھتی ہوئی memory میں سے زیادہ سے زیادہ memory بھی استعمال کرے گا۔ اس لیے shared box پر Compose میں container memory کی حد مقرر کرنا میں بیان کردہ طریقے کے مطابق ceiling مقرر کریں۔

BASE_URL بالکل public URL کے برابر ہونا چاہیے۔ اگر ایسا نہ ہو تو آپ login کرتے ہیں، application غلط host پر redirect ہو جاتی ہے، اور session cookie ایسے domain کے لیے لکھی جاتی ہے جس پر آپ کا browser موجود نہیں ہوتا۔ نتیجتاً آپ بغیر کسی error message کے دوبارہ login form پر پہنچ جاتے ہیں۔

فراہم کردہ compose file کوئی port publish نہیں کرتی، کیونکہ اس کے آگے proxy استعمال کرنے کی توقع ہے۔ ایک override شامل کریں جو default application port کو صرف loopback پر publish کرے۔

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

Matomo: مکمل پروڈکٹ اور اس کے مطلوبہ سرور

Matomo، MySQL یا MariaDB کے ساتھ PHP پر چلتا ہے۔ اس لیے یہ container stack کے بجائے روایتی web stack کے لیے موزوں ہے۔ یہ یہاں موجود واحد tool بھی ہے جو traffic volume کے مطابق hardware requirements شائع کرتا ہے۔

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

یہ August 2026 تک Matomo کی شائع کردہ کم از کم requirements ہیں، اس guide کے لیے کی گئی measurements نہیں۔ ماہانہ 100,000 pageviews تک کے لیے اسے 2 CPU cores، 2 GB RAM اور 50 GB SSD درکار ہے، اور ایک ہی server application اور database دونوں چلا سکتا ہے۔ 1M/month پر یہ requirement بڑھ کر 8 GB RAM اور 250 GB disk ہو جاتی ہے۔ 10M/month پر Matomo دو servers کی سفارش کرتا ہے، اور آخری row database server دکھاتی ہے: 16 GB RAM اور 400 GB disk۔ ان disk figures کو ان single-binary options کے ساتھ ملا کر دیکھیں جن میں پورا dataset ایک SQLite file ہوتی ہے۔

Archiving وہ حصہ ہے جو لوگوں کو حیران کرتا ہے۔ By default Matomo اس وقت reports بناتا ہے جب کوئی dashboard کھولتا ہے۔ اس لیے data بڑھنے کے ساتھ dashboard سست ہو جاتا ہے اور آخرکار timeout ہو جاتا ہے۔ دستاویزی حل یہ ہے کہ general settings میں browser-triggered archiving بند کریں اور اس کے بجائے archiver کو cron سے چلائیں۔ اسے اس user کے طور پر چلائیں جو Matomo files کا مالک ہے، اور Matomo directory سے command اجرا کریں۔

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

Matomo processed report tables کے ساتھ raw log tables بھی رکھتا ہے، اور schedule کے مطابق پرانا raw data اور پرانی reports حذف کر سکتا ہے۔ اسے installation کے وقت فعال کریں، disk full ہونے کے بعد نہیں۔ Matomo server access logs بھی import کر سکتا ہے۔ اس طرح یہ یہاں موجود واحد product ہے جو دونوں families کو بیک وقت cover کرتا ہے۔

Rybbit اور نئے stacks

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

Rybbit حال ہی میں متعارف ہوا ہے اور اس کا dashboard جدید ہے۔ setup script environment file لکھتی ہے اور Docker Compose کے ذریعے stack شروع کرتی ہے۔ یہ ClickHouse چلاتا ہے، اور Caddy کو اپنے web server کے طور پر شامل کرتا ہے۔ Caddy port 443 سنبھالتا ہے اور آپ کے فراہم کردہ domain کے لیے certificate کی درخواست کرتا ہے۔ جس machine پر nginx پہلے ہی port 443 سنبھال رہا ہو، وہاں script bind نہیں کر سکے گی۔ اس لیے project کا manual Compose طریقہ استعمال کریں اور اسے اپنے موجودہ proxy کے پیچھے رکھیں۔ دستاویزات میں کم از کم 2 GB RAM، Ubuntu 24 LTS پر testing، اور ARM کے لیے ARMv8.2-A یا اس کے بعد کا ورژن درکار بتایا گیا ہے، کیونکہ ClickHouse استعمال ہوتا ہے۔

کسی بھی نئے project کے لیے اہم احتیاط یہ ہے کہ features تیزی سے شامل ہوتے ہیں اور breaking changes بھی جلد آ سکتی ہیں۔ کسی tag کو pin کریں، pull کرنے سے پہلے release notes پڑھیں، اور پہلے database backup لیں۔

Retention اور disk growth: اپنے box پر اس کی پیمائش کریں

Disk growth کا انحصار اس بات پر ہے کہ tool ہر event کے لیے کیا محفوظ کرتا ہے۔ GoatCounter hits کو counters میں aggregate کرتا ہے، اس لیے اس کی file کا حجم raw volume کے مقابلے میں distinct pages اور days کے ساتھ زیادہ بڑھتا ہے۔ Umami اور Matomo ہر event کے لیے rows محفوظ کرتے ہیں، جبکہ Matomo raw rows کے علاوہ processed report tables بھی محفوظ کرتا ہے۔ ClickHouse events کو columns میں محفوظ کرتا ہے اور انہیں بہت زیادہ compress کرتا ہے۔ اسی لیے Plausible اس volume کو بھی سنبھال لیتا ہے جو row store پر نمایاں بوجھ ڈالے۔

یہ guide فی million pageviews megabytes کی کوئی قدر شائع نہیں کرتی، کیونکہ اس نے آپ کے traffic پر اس کی پیمائش نہیں کی۔ یہ reading خود لیں۔ service اور user names کو اپنی Compose file کے مطابق تبدیل کریں۔

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"

یہ number درج کریں، ایک ہفتہ انتظار کریں، پھر اسے دوبارہ درج کریں، اور فرق کو اس ہفتے dashboard کی رپورٹ کردہ pageviews سے تقسیم کریں۔ یہ figure آپ کی site اور آپ کے bot filtering سے متعلق ہے، اس لیے کسی بھی شائع شدہ اوسط سے زیادہ مفید ہے۔ پھر اس وقت retention limit مقرر کریں جب number ابھی کم ہو۔ ایک full disk VPS پر ہر service کو بند کر دیتی ہے، صرف analytics کو نہیں۔ یہی اس بات کی سب سے مضبوط وجہ ہے کہ database volume کو ایسی جگہ رکھا جائے جس کے بارے میں df -h آپ کو warning دے گا۔ اس risk پر اس box میں مزید توجہ درکار ہے جس پر پہلے ہی کوئی bulky چیز موجود ہو، کیونکہ self-hosted photo server disk کو اس وقت بہت پہلے بھر دے گا جب کوئی analytics database اس کے قریب بھی نہ پہنچا ہو۔

ریورس پراکسی کے پیچھے subdomain پر اس کا رویہ

collector کو اس site کے subdomain پر رکھیں جس کی پیمائش وہ کرتا ہے، مثلاً stats.example.com۔ اس طرح collector کی request first-party بن جاتی ہے، لہٰذا browser کے وہ rules اس پر لاگو نہیں ہوتے جو third-party requests کو block کرتے ہیں۔

container port publish کرتے وقت application کو loopback پر bind کریں۔ Docker اپنے firewall rules، ufw سے پہلے لکھتا ہے۔ اس لیے -p 3000:3000 کے طور پر publish کیا گیا container internet سے قابل رسائی رہتا ہے، چاہے ufw status یہ بتا رہا ہو کہ port denied ہے۔ اسے کسی دوسری machine سے curl http://SERVER_IP:3000 کے ذریعے test کریں؛ dashboard دستیاب ہو جائے گا۔ اگر اسے -p 127.0.0.1:3000:3000 کے طور پر publish کیا جائے تو یہی test 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 headers اختیاری نہیں ہیں۔ X-Forwarded-For کے بغیر ہر visit 127.0.0.1 سے آتی ہوئی دکھائی دے گی۔ نتیجتاً country report خالی رہے گی اور unique visitors کی تعداد تقریباً ایک تک محدود ہو جائے گی۔ ہر project خود طے کرتا ہے کہ وہ کس header پر، اور کس setting کے تحت، اعتماد کرے گا۔ اس لیے اندازہ لگانے کے بجائے اس کی proxy documentation ایک بار دیکھیں۔ Caddy یہ headers خود set کرتا ہے، اور اسی کام کے لیے Caddyfile میں صرف دو lines درکار ہوتی ہیں۔

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

اگر آپ نے ابھی تک proxy منتخب نہیں کی تو nginx، Caddy اور Traefik کا تقابلی جائزہ میں بتایا گیا ہے کہ چند subdomains والے single box کے لیے کون سا proxy موزوں ہے۔

کیا آپ self-hosting کی صورت میں بھی cookie banner استعمال کریں؟

Self-hosting سے یہ بدلتا ہے کہ data کس کے پاس رہتا ہے۔ اس سے data کے بارے میں قانون کی شرائط نہیں بدلیں۔ دو قواعد کو الگ رکھیں۔ ePrivacy consent rule visitor کے device پر کسی بھی چیز کو store یا read کرنے سے متعلق ہے، اس لیے ایسا tool جو کوئی cookie set نہ کرے اور local storage میں کچھ نہ لکھے، اس مخصوص requirement کے دائرے سے باہر رہتا ہے۔ GDPR personal data کی processing سے متعلق ہے، اور IP address کو personal data شمار کیا جاتا ہے۔ اس لیے آپ کو اب بھی ایک lawful basis، data retention کی حد، اور اس سوال کا جواب درکار ہے کہ آپ نے متعلقہ شخص کے بارے میں کیا data محفوظ کر رکھا ہے۔

Plausible، Umami، GoatCounter اور Medama default طور پر کوئی cookie set نہیں کرتے۔ اس کے بجائے ہر project کون سا data derive کرتا ہے، یہ مختلف ہوتا ہے اور versions کے درمیان بدل سکتا ہے۔ اس لیے summary کے بجائے project کی اپنی privacy documentation پڑھیں۔ Matomo میں IP anonymisation اور opt out endpoint شامل ہوتے ہیں، جنہیں آپ admin interface میں enable کرتے ہیں۔

مختلف ممالک میں regulators مختلف نتائج تک پہنچتے ہیں۔ مثال کے طور پر France کی CNIL ایسی شرائط شائع کرتی ہے جن کے تحت audience measurement کو consent سے مستثنیٰ قرار دیا جا سکتا ہے۔ یہ section factual summary ہے، legal advice نہیں۔ حقیقی users والی حقیقی site کے لیے اپنے jurisdiction میں کسی lawyer سے مشورہ کریں۔

ایک اہم بات جسے لوگ نظرانداز کرتے ہیں: access log بھی personal data ہوتا ہے۔ GoAccess page میں کوئی script شامل نہیں کرتا، لیکن پھر بھی IP addresses process کرتا ہے۔ اس لیے log-based analytics خودبخود ان قواعد کے دائرے سے باہر نہیں ہو جاتی۔

ایڈ بلاکرز، اور آپ کے اعداد و شمار کیوں کم ہوں گے

فلٹر فہرستیں hostname اور URL pattern کی بنیاد پر مطابقت تلاش کرتی ہیں۔ Hosted analytics product کو شناخت کرنا آسان ہوتا ہے، کیونکہ ہر صارف اسے اسی معروف hostname سے load کرتا ہے۔ Collector کو اپنی subdomain پر منتقل کرنے سے request میں سے وہ hostname ختم ہو جاتا ہے، اور script کو اپنے منتخب کردہ path سے serve کرنے پر معروف filename بھی ختم ہو جاتا ہے۔ اس طرح فہرست کو مطابقت تلاش کرنے کے لیے دونوں سابقہ identifiers دستیاب نہیں رہتے۔

یہ post کسی hit rate کا دعویٰ نہیں کرتی، کیونکہ اس میں اسے measure نہیں کیا گیا۔ کسی بھی setup کو block کرنے والے visitors کا تناسب آپ کی audience پر منحصر ہوتا ہے، اور developer audience عام audience کے مقابلے میں کہیں زیادہ blocking کرتی ہے۔ اس کے بجائے اپنے gap کو measure کریں۔ اسی ہفتے کے دوران access log میں GoAccess کے ذریعے HTML pages کی requests شمار کریں، پھر اس کا موازنہ اپنے script-based tool کی رپورٹ کردہ pageviews سے کریں۔ آپ کی site پر یہ فرق blocked visits اور cache سے serve ہونے والے pages کا مجموعہ ہے۔

Hosted product سے منتقل ہونے والے دن totals میں تبدیلی کی توقع رکھیں، اور یہ بھی ذہن میں رکھیں کہ اس تبدیلی کا کچھ حصہ blocking سے متعلق نہیں ہوگا۔ Products اس بارے میں مختلف ہوتے ہیں کہ pageview کیا ہے، single-page application کے اندر route change کو ایک pageview شمار کرنا ہے یا نہیں، اور session کب ختم ہوتا ہے۔ یہ نتیجہ اخذ کرنے سے پہلے کہ traffic کم ہو گیا ہے، کئی ہفتوں کے trends کا موازنہ کریں۔

کس سائٹ کے لیے کون سا ٹول

• ذاتی سائٹ یا ایسا blog جس پر ماہانہ تقریباً 50,000 pageviews ہوں: 1 GB VPS پر GoatCounter یا Medama، اور backups کے لیے file copy کافی ہے۔
• ایسی سائٹ جہاں script شامل نہ کر سکیں، یا ایسی audience جو scripts کو بڑے پیمانے پر block کرتی ہو: موجودہ log پر GoAccess، مقررہ schedule کے مطابق۔
• چھوٹی business site جہاں dashboard کوئی دوسرا شخص دیکھتا ہو: Umami، اس کے Postgres container کے ساتھ۔
• ایسی سائٹ جہاں goals اور funnels درکار ہوں، اور server میں 2 GB RAM یا اس سے زیادہ ہو: Plausible Community Edition، یا نیا dashboard چاہیے اور نسبتاً کم پختہ project قابل قبول ہو تو Rybbit۔
• متعدد سائٹس، متعدد user accounts، یا raw data کو اپنی retention policy کے تحت رکھنے کی ضرورت ہو: Matomo، جس کے لیے اوپر دی گئی published guidance کے مطابق resources مقرر کریں۔

سب سے چھوٹے ایسے tool سے شروع کریں جو آپ کے حقیقی سوال کا جواب دے سکے۔ بعد میں GoatCounter سے Plausible پر منتقل ہونے کے لیے ایک subdomain اور کچھ history درکار ہوگی۔ Matomo سے کسی دوسرے tool پر منتقل ہونا ایسی migration کا باعث بنے گا جس سے آپ بچنا چاہیں گے۔ اگر آپ اب بھی یہ طے کر رہے ہیں کہ اسی server پر اور کیا چلایا جا سکتا ہے تو وسیع self-hosting جائزہ میں بتایا گیا ہے کہ اس کے ساتھ کیا موزوں ہے۔ اور اگر آپ کی اصل ضرورت visitor counts کے بجائے کسی application کی request level tracing ہے تو self-hosted observability service اس کام کے لیے موزوں tool ہے۔

FAQ

کیا self-hosting analytics سے cookie banner کی ضرورت ختم ہو جاتی ہے؟

نہیں، اور یہ دونوں سوالات الگ ہیں۔ ePrivacy کے تحت consent rule visitor کے device پر کسی چیز کو store یا read کرنے کا احاطہ کرتا ہے، اس لیے ایسا tool جو کوئی cookie set نہیں کرتا اور local storage میں کچھ نہیں لکھتا، اس مخصوص requirement کے دائرے سے باہر رہتا ہے۔ GDPR ایک مختلف rule ہے اور personal data کی processing کا احاطہ کرتا ہے۔ IP address personal data ہے، اس لیے cookie نہ ہونے کے باوجود آپ کو lawful basis اور retention limit درکار رہتی ہے۔ Self-hosting سے data آپ کے server پر منتقل ہو جاتا ہے اور اس کے لیے ذمہ دار فریق آپ بن جاتے ہیں۔ اپنے regulator کی guidance دیکھیں اور اپنے معاملے کے لیے lawyer سے مشورہ کریں۔

self-hosted analytics کو VPS پر کتنی RAM درکار ہوتی ہے؟

اس کا فیصلہ dashboard نہیں بلکہ datastore کرتا ہے۔ GoatCounter اور Medama ایک file پر ایک process کے طور پر چلتے ہیں، اور Medama کی documentation کے مطابق چھوٹی sites 256 MB والی machines پر چل سکتی ہیں۔ Umami، Node application کے ساتھ ایک Postgres container بھی چلاتا ہے۔ Plausible Community Edition اور Rybbit دونوں ClickHouse چلاتے ہیں، اور دونوں projects کم از کم 2 GB کی شرط بیان کرتے ہیں۔ Matomo کی اپنی guidance کے مطابق ماہانہ 100,000 pageviews تک کے لیے آغاز 2 CPU cores اور 2 GB RAM سے ہوتا ہے۔

میرے self-hosted اعداد و شمار اس analytics tool سے کم کیوں ہیں جسے میں نے تبدیل کیا؟

اس کی دو وجوہات ہیں، اور دونوں حقیقی ہیں۔ Filter lists بعض collector requests کو block کر دیتی ہیں، اس لیے script based ہر tool ان visits میں سے کچھ کھو دیتا ہے۔ Products counting بھی مختلف انداز میں کرتے ہیں، کیونکہ pageview کی تعریف اور session ختم ہونے کا وقت ان کے درمیان مختلف ہوتا ہے۔ اپنے access log سے HTML page requests کا ایک ہفتہ لیں اور اسے اسی ہفتے کے script based pageviews کے ساتھ compare کریں۔ یہ فرق blocked visits اور cached pages کا مجموعہ ہے، جسے اپنی site پر measure کیا گیا ہے، نہ کہ کسی دوسرے کے شائع کردہ rate سے لیا گیا ہے۔

کیا میں Plausible یا Rybbit کو ARM VPS پر چلا سکتا ہوں؟

دونوں ClickHouse چلاتے ہیں، اور ClickHouse کو x86 پر SSE 4.2 یا ARM پر NEON درکار ہوتا ہے۔ Plausible کی requirements میں یہی بات درج ہے، جبکہ Rybbit کی docs کے مطابق ARM systems کو ARMv8.2-A یا اس سے جدید version درکار ہے۔ موجودہ ARM server cores اس شرط پر پورے اترتے ہیں، لیکن پرانے cores نہیں اترتے۔ خرابی application log میں ظاہر ہونے کے بجائے ClickHouse کے start ہونے سے انکار اور instruction set error کی صورت میں سامنے آتی ہے۔ چھوٹے ARM box پر single file tools اس مسئلے سے بچا لیتے ہیں، کیونکہ ان میں سے کوئی بھی ClickHouse نہیں چلاتا۔

کیا tracking script استعمال کرنے کے بجائے server logs parse کرنے چاہییں؟

جب آپ script شامل نہیں کر سکتے، آپ کی audience بڑے پیمانے پر scripts block کرتی ہے، یا آپ ایسا count چاہتے ہیں جس میں crawlers بھی شامل ہوں، تو log parsing استعمال کریں۔ GoAccess ایسا log پڑھتا ہے جو آپ کا server پہلے ہی لکھ رہا ہوتا ہے، اس لیے اس سے page weight یا database میں کوئی اضافہ نہیں ہوتا۔ اس طریقے میں browser کے اندر ہونے والی تمام سرگرمیاں نظر نہیں آتیں۔ CDN یا browser cache سے serve ہونے والا page بھی miss ہو جاتا ہے، کیونکہ اس کی request آپ کے server تک نہیں پہنچی۔ بہت سی sites دونوں طریقے استعمال کرتی ہیں اور انہیں دو مختلف measurements سمجھتی ہیں۔