VPS वर कोणते self-hosted वेब ॲनालिटिक्स टूल वापरावे?

VPS वर कोणते self-hosted वेब ॲनालिटिक्स टूल वापरावे?

Self-hosted वेब ॲनालिटिक्सचे दोन प्रकार आहेत. चुकीचा प्रकार निवडणे हे चुकीचे उत्पादन निवडण्यापेक्षा जास्त महाग पडू शकते. पहिल्या प्रकारात अभ्यागताच्या ब्राउझरमध्ये एक छोटी स्क्रिप्ट चालते आणि ती स्क्रिप्ट जो डेटा रिपोर्ट करते, तो साठवला जातो. दुसरा प्रकार तुमच्या वेब सर्व्हरने आधीच लिहिलेल्या access log वाचतो. त्यानंतरची सर्व प्रक्रिया, ज्यामध्ये डेटाबेस आणि लागणारी मेमरी समाविष्ट आहे, ती या एका निवडीवर अवलंबून असते.

लहान सर्व्हरसाठी थोडक्यात उत्तर खालीलप्रमाणे आहे. GoatCounter आणि Medama हे 1 GB रॅमवर चालू शकतात, कारण प्रत्येक टूल एका फाईलवर आधारित एकच प्रोसेस चालवते. Umami मध्ये एक Postgres कंटेनर जोडला जातो आणि ते एक असे डॅशबोर्ड देते जे तांत्रिक ज्ञान नसलेली व्यक्तीही वाचू शकते. Plausible Community Edition आणि Rybbit हे दोन्ही ClickHouse वापरतात, त्यामुळे किमान 2 GB किंवा त्यापेक्षा जास्त रॅमची तरतूद ठेवा. Matomo हे एक पूर्ण क्षमतेचे उत्पादन आहे आणि त्यासाठी तुमच्या ट्रॅफिकनुसार सर्व्हरची क्षमता असणे आवश्यक आहे. GoAccess मुळे पेजवर कोणताही अतिरिक्त भार पडत नाही, कारण ते आधीच अस्तित्वात असलेला log वाचते.

स्क्रिप्ट टॅग किंवा सर्व्हर लॉग: प्रत्येकाला काय दिसते

स्क्रिप्ट टॅग ब्राउझरचे मोजमाप करतो. पेज लोड होते, स्क्रिप्ट रन होते आणि ती तुमच्या कलेक्टरकडे एक विनंती पाठवते. या साखळीत अडथळा आणणारी कोणतीही गोष्ट तुम्हाला दिसत नाही: JavaScript बंद असणे, विनंती ब्लॉक करणारी फिल्टर लिस्ट, कलेक्टरकडे गेलेली अयशस्वी विनंती किंवा स्क्रिप्ट रन न करणारा क्रॉलर.

लॉग पार्सर विनंत्यांचे मोजमाप करतो. तुम्ही काहीही इन्स्टॉल केले तरीही तुमचा वेब सर्व्हर प्रत्येक विनंतीसाठी एक ओळ लिहितो, त्यामुळे डेटा आधीच डिस्कवर असतो. तो प्रत्येक क्रॉलर आणि स्क्रिप्ट टॅग नसलेल्या फाईलवर झालेली प्रत्येक हिट पाहू शकतो. ब्राउझरच्या आत काय घडले हे तो पाहू शकत नाही आणि ब्राउझर कॅशेमधून किंवा तुमच्या सर्व्हरच्या समोर असलेल्या CDN (content delivery network) कडून सर्व्ह केलेले पेज तो पाहू शकत नाही, कारण ती विनंती तुमच्या सर्व्हरपर्यंत पोहोचलेलीच नसते.

हे दोन आकडे जुळणार नाहीत आणि त्यापैकी कोणीही चुकीचे नाही. Matomo दोन्ही करू शकते आणि ते लॉग इम्पोर्टमध्ये काय गहाळ आहे याची माहिती त्याच्या JavaScript ट्रॅकरच्या संदर्भात देते: स्क्रीन रिझोल्यूशन आणि पेज टायटल्स, इव्हेंट्स, कंटेंट ट्रॅकिंग, हीटमॅप्स, सेशन रेकॉर्डिंग्ज आणि फॉर्म ॲनालिटिक्स. ब्राउझरऐवजी विनंत्या मोजण्याची ही किंमत आहे.

बॉट ट्रॅफिक हे या फरकाचे दुसरे कारण आहे. लॉग-आधारित मोजमापांमध्ये क्रॉलर्सचा समावेश असतो, जोपर्यंत तुम्ही त्यांना फिल्टर करत नाही, आणि सामान्य साईटवर क्रॉलरचा वाटा तुमचे निष्कर्ष बदलण्याइतपत मोठा असतो. 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

त्यानंतर लॉग फाईल निवडा आणि एक स्टॅटिक रिपोर्ट तयार करा.

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 मध्ये असतात आणि जुन्या विनंत्या कॉम्प्रेस केलेल्या असतात, त्यामुळे साप्ताहिक रिपोर्ट पाहण्यासाठी रोटेट केलेल्या फाईल्स देखील वाचाव्या लागतात.

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

यात --real-time-html नावाचा एक लाईव्ह मोड देखील आहे, जो WebSocket द्वारे पेज अपडेट करतो. त्यासाठी दुसऱ्या पोर्टची आणि स्वतंत्र प्रॉक्सी नियमाची आवश्यकता असते. बहुतेक साईट्ससाठी cron द्वारे तयार केलेला तासाभराचा रिपोर्ट पुरेसा असतो आणि त्यात सुरक्षिततेची जोखीम कमी असते.

GoatCounter: एक Go बायनरी आणि एक SQLite फाईल

GoatCounter हे स्टॅटिकली कंपाईल केलेली बायनरी म्हणून उपलब्ध आहे, त्यामुळे यासाठी कोणत्याही रनटाइमची स्थापना करण्याची गरज नाही. रिलीज पेजवरून बिल्ड घ्या आणि तो चालवा, किंवा इमेज वापरा.

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

बायनरी म्हणून चालवताना, goatcounter serve हे 8080 पोर्टवर लिसन करते आणि ./goatcounter-data/db.sqlite3 वर SQLite फाईल तयार करते. जेव्हा इन्स्टन्स आधीच एखाद्या प्रॉक्सीच्या मागे असेल, तेव्हा वेब विझार्डऐवजी कमांड लाईनवरून पहिली साईट तयार करा.

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 वर राहू द्या आणि त्याकडे प्रॉक्सी करा. प्रोजेक्टच्या आकडेवारीनुसार ट्रॅकिंग स्क्रिप्ट सुमारे 3.5K आकाराची आहे आणि ज्या पेजेसवर JavaScript नाही, त्यांच्यासाठी ट्रॅकिंग पिक्सेल उपलब्ध आहे. जर व्यस्त साईटवर SQLite ची मर्यादा गाठली गेली, तर तीच बायनरी goatcounter serve -db 'postgresql+dbname=goatcounter' वापरून Postgres ला सपोर्ट करू शकते. बॅकअप म्हणजे केवळ फाईलची प्रत तयार करणे होय, आणि या प्रकारच्या टूलसाठी हाच सर्वात मोठा फायदा आहे.

Medama: 256 MB ची मागणी करणारा एक सिंगल कंटेनर

Medama हा या यादीतील सर्वात नवीन सिंगल बायनरी पर्याय आहे. हे डिझाइननुसारच कुकी-मुक्त आहे आणि प्रकल्पाच्या दाव्यानुसार ट्रॅकर 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 वर पब्लिश करते. वरील लूपबॅक प्रीफिक्स मुद्दाम वापरला आहे आणि रिव्हर्स प्रॉक्सी विभागात याचे कारण स्पष्ट केले आहे. पहिली लॉगिन प्रक्रिया admin अशी आहे आणि पासवर्ड CHANGE_ME_ON_FIRST_LOGIN आहे, आणि त्या पासवर्डचे नाव हीच एक सूचना आहे.

दस्तऐवजीकरण केलेली एक त्रुटी तुम्हाला अडथळ्यात टाकू शकते. लॉगिन फक्त HTTPS वर किंवा localhost वरच काम करते. त्यामुळे, जर तुम्ही प्रमाणपत्रापूर्वी (certificate) प्रॉक्सी सेट केली, तर फॉर्म योग्य पासवर्ड नाकारेल आणि त्याचे कारण स्क्रीनवर दिसणार नाही. आधी TLS (transport layer security) सेटअप पूर्ण करा आणि त्यानंतरच लॉगिन करा.

Umami: Postgres आणि सर्वांना परिचित असलेले डॅशबोर्ड

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

हे कमांड PostgreSQL कंटेनरसह ॲप्लिकेशन पोर्ट 3000 वर सुरू करते. दस्तऐवजानुसार किमान PostgreSQL v12.14 आवश्यक आहे, किंवा जर तुम्ही सोर्स कोडवरून बिल्ड करत असाल तर Node.js 18.18 किंवा त्यापुढील आवृत्ती आवश्यक आहे. यासाठी एक प्री-बिल्ट इमेज docker.umami.is/umami-software/umami:postgresql-latest उपलब्ध आहे, ज्यासाठी DATABASE_URL द्वारे तुम्ही आधीच चालवत असलेल्या डेटाबेसशी कनेक्शन जोडणे आवश्यक आहे.

पहिले लॉगिन admin या युजरनेमने आणि umami या पासवर्डने करा. DNS रेकॉर्ड सर्व्हरकडे वळवण्यापूर्वी पासवर्ड बदलून घ्या, कारण एकदा DNS रिझॉल्व्ह झाले आणि प्रॉक्सीने प्रतिसाद दिला की हे इन्स्टन्स इंटरनेटवरून कोणालाही उपलब्ध होईल. Docker Compose चे तपशील, environment files आणि restart policy साठी, तुम्ही न वाचलेला स्टॅक कॉपी करण्याऐवजी VPS वरील Docker Compose स्टॅक पहा.

याचे रिसोर्स फुटप्रिंट म्हणजे एक 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

ऑगस्ट 2026 पर्यंत आवृत्ती v3.2.1 ही सध्याची आवृत्ती आहे आणि clone कमांड मुद्दाम तीच आवृत्ती निश्चित करते. हा स्टॅक तीन भागांचा आहे: ॲप्लिकेशन, खाती आणि सेटिंग्जसाठी Postgres, आणि इव्हेंट डेटासाठी ClickHouse. SECRET_KEY_BASE किमान 64 बाइट्सची स्ट्रिंग असणे आवश्यक आहे, जी openssl कॉलद्वारे तयार केली जाते.

Plausible च्या स्वतःच्या गरजांनुसार किमान 2 GB रॅम असणे आवश्यक आहे, जेणेकरून ClickHouse आणि ॲप्लिकेशन 'out of memory killer' चा बळी ठरणार नाहीत. तसेच, ClickHouse साठी SSE 4.2 किंवा NEON ला सपोर्ट करणारा CPU आवश्यक आहे. ही दुसरी अट VPS खरेदी करण्यापूर्वी तपासणे महत्त्वाचे आहे आणि ARM आणि x86 VPS मधील निवड करताना हा एक व्यावहारिक फरक ठरतो. ClickHouse उपलब्ध असलेली सर्व मेमरी वापरण्याचा प्रयत्न करते, म्हणून शेअर केलेल्या सर्व्हरवर Compose मध्ये कंटेनर मेमरी मर्यादित करणे यानुसार तिची कमाल मर्यादा निश्चित करा.

BASE_URL हे सार्वजनिक URL शी तंतोतंत जुळले पाहिजे. जर ते जुळत नसेल, तर तुम्ही लॉग इन करताच ॲप्लिकेशन चुकीच्या होस्टवर रिडायरेक्ट होते आणि सेशन कुकी अशा डोमेनसाठी लिहिली जाते ज्यावर तुमचा ब्राउझर नाही. परिणामी, कोणतीही त्रुटी न दिसता तुम्ही पुन्हा लॉग इन फॉर्मवर येता.

दिलेल्या compose फाईलमध्ये पोर्ट पब्लिश केलेले नाही, कारण त्यासमोर एक प्रॉक्सी असणे अपेक्षित आहे. एक ओव्हरराइड जोडा जो डीफॉल्ट ॲप्लिकेशन पोर्ट फक्त 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
  }
]

ऑगस्ट 2026 पर्यंतची ही Matomo ची प्रकाशित केलेली किमान आवश्यकता आहे, या मार्गदर्शिकेसाठी घेतलेली मोजमापे नाहीत. दरमहा 100,000 पेजव्ह्यूजपर्यंत, यासाठी 2 CPU कोअर्स, 2 GB RAM आणि 50 GB SSD ची आवश्यकता असते आणि एकच सर्व्हर ॲप्लिकेशन आणि डेटाबेस या दोन्ही गोष्टी हाताळतो. 1M/month वर हे प्रमाण 8 GB RAM आणि 250 GB डिस्क इतके होते. 10M/month वर Matomo दोन सर्व्हरची शिफारस करते आणि शेवटची ओळ डेटाबेस सर्व्हर दर्शवते: 16 GB RAM आणि 400 GB डिस्क. हे डिस्कचे आकडे सिंगल बायनरी पर्यायांच्या बाजूला वाचा, जिथे संपूर्ण डेटासेट एकाच SQLite फाईलमध्ये असतो.

आर्कायव्हिंग ही गोष्ट लोकांना आश्चर्यचकित करते. डीफॉल्टनुसार, जेव्हा कोणी डॅशबोर्ड उघडते तेव्हा Matomo त्याचे रिपोर्ट तयार करते, त्यामुळे जसा डेटा वाढतो तसा डॅशबोर्ड धीमा होतो आणि शेवटी टाइमआउट होतो. याचे दस्तऐवजीकरण केलेले निराकरण म्हणजे जनरल सेटिंग्जमध्ये ब्राउझर-ट्रिगर केलेले आर्कायव्हिंग बंद करणे आणि त्याऐवजी Matomo डिरेक्टरीमधून, Matomo फाईल्सच्या मालक असलेल्या युजरद्वारे cron वरून आर्कायव्हर चालवणे.

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

Matomo त्याच्या प्रक्रिया केलेल्या रिपोर्ट टेबलच्या बाजूला रॉ लॉग टेबल देखील ठेवते आणि ते जुना रॉ डेटा आणि जुने रिपोर्ट एका वेळापत्रकानुसार हटवू शकते. हे फिचर डिस्क पूर्ण भरण्यापूर्वी, इन्स्टॉलेशनच्या वेळीच सुरू करा. Matomo सर्व्हर ॲक्सेस लॉग देखील इम्पोर्ट करू शकते, ज्यामुळे हे यातील एकमेव उत्पादन ठरते जे दोन्ही प्रकारच्या डेटाला एकाच वेळी कव्हर करते.

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 चा वापर करते. Caddy पोर्ट 443 घेते आणि तुम्ही दिलेल्या डोमेनसाठी प्रमाणपत्र (certificate) मिळवते. ज्या सर्व्हरवर आधीच nginx पोर्ट 443 वापरत असेल, तिथे हे स्क्रिप्ट बाइंड होऊ शकणार नाही. अशा वेळी, प्रोजेक्टच्या मॅन्युअल Compose पद्धतीचा वापर करा आणि त्याला तुमच्या अस्तित्वात असलेल्या proxy च्या मागे ठेवा. डॉक्युमेंटेशननुसार यासाठी किमान 2 GB RAM आवश्यक आहे. हे Ubuntu 24 LTS वर टेस्ट केलेले आहे आणि ClickHouse मुळे ARM वर ARMv8.2-A किंवा त्यापुढील आर्किटेक्चर आवश्यक आहे.

कोणत्याही नवीन प्रोजेक्टसाठी एक महत्त्वाची सूचना: यामध्ये फीचर्स वेगाने येतात आणि त्यासोबतच ब्रेकिंग बदलही (breaking changes) होऊ शकतात. नेहमी विशिष्ट टॅग (tag) पिन करा, अपडेट करण्यापूर्वी release notes वाचा आणि त्याआधी डेटाबेसचा बॅकअप घ्या.

रिटेंशन आणि डिस्कची वाढ: तुमच्या स्वतःच्या सर्व्हरवर मोजमाप करा

डिस्कची वाढ ही प्रत्येक इव्हेंटसाठी टूल किती डेटा साठवते यावर अवलंबून असते. GoatCounter हिट्सना काउंटरमध्ये एकत्रित करते, त्यामुळे त्याची फाईल कच्च्या डेटापेक्षा विशिष्ट पेजेस आणि दिवसांनुसार जास्त वाढते. Umami आणि Matomo प्रत्येक इव्हेंटसाठी स्वतंत्र ओळी (rows) साठवतात, आणि 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"

आकडा नोंदवून ठेवा, एक आठवडा वाट पाहा, पुन्हा आकडा तपासा आणि त्यातील फरकाला डॅशबोर्डवर दिसणाऱ्या त्या आठवड्यातील पेजव्ह्यूने भागा. तो आकडा तुमच्या साइट आणि बॉट फिल्टरिंगवर आधारित असल्याने, कोणत्याही प्रकाशित सरासरीपेक्षा तो अधिक महत्त्वाचा आहे. त्यानंतर, आकडा लहान असतानाच रिटेंशनची मर्यादा सेट करा. डिस्क पूर्ण भरल्यास केवळ ॲनालिटिक्सच नाही, तर VPS वरील सर्व सेवा बंद पडतात. डेटाबेस व्हॉल्यूम अशा ठिकाणी ठेवणे, ज्याबद्दल df -h तुम्हाला सावध करेल, हा सर्वात महत्त्वाचा युक्तिवाद आहे. जर तुमच्या सर्व्हरवर आधीच मोठी फाईल किंवा डेटा असेल, तर हा धोका अधिक गंभीर ठरतो, कारण सेल्फ-होस्टेड फोटो सर्व्हर कोणत्याही ॲनालिटिक्स डेटाबेसच्या आधीच डिस्क पूर्णपणे भरून टाकेल.

रिव्हर्स प्रॉक्सीच्या मागे सबडोमेनवर हे कसे कार्य करते

कलेक्टरला ज्या साइटचे मोजमाप करायचे आहे, तिच्या सबडोमेनवर ठेवा, उदाहरणार्थ stats.example.com. यामुळे कलेक्टरची विनंती 'फर्स्ट पार्टी' बनते, त्यामुळे थर्ड पार्टी विनंत्या रोखणाऱ्या ब्राउझरच्या नियमांचा त्यावर परिणाम होत नाही.

कंटेनर पोर्ट पब्लिश करताना ॲप्लिकेशनला लूपबॅकवर बाइंड करा. Docker स्वतःचे फायरवॉल नियम ufw च्या आधी लिहितो, त्यामुळे -p 3000:3000 म्हणून पब्लिश केलेला कंटेनर इंटरनेटवरून उपलब्ध होतो, जरी ufw status ने पोर्ट नाकारल्याचे दर्शवले तरीही. दुसऱ्या मशीनवरून curl http://SERVER_IP:3000 वापरून चाचणी करा, तुम्हाला डॅशबोर्ड दिसेल. -p 127.0.0.1:3000:3000 म्हणून पब्लिश केल्यास, त्याच चाचणीमध्ये Connection refused असा प्रतिसाद मिळेल आणि फक्त प्रॉक्सीच त्यापर्यंत पोहोचू शकेल.

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

येथे फॉरवर्डिंग हेडर्स ऐच्छिक नाहीत. X-Forwarded-For शिवाय, प्रत्येक भेट 127.0.0.1 वरून आल्यासारखी दिसते, त्यामुळे देशाचा अहवाल रिकामा राहतो आणि युनिक व्हिजिटर्सची संख्या एकावर येते. प्रत्येक प्रोजेक्ट कोणत्या हेडरवर विश्वास ठेवतो आणि कोणत्या सेटिंग अंतर्गत ठेवतो हे ठरवतो, त्यामुळे गृहीत धरण्याऐवजी एकदा त्याच्या प्रॉक्सी डॉक्युमेंटेशनची खात्री करा. Caddy हे हेडर्स स्वतः सेट करते आणि याच कामासाठी Caddyfile फक्त दोन ओळींची असते.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

जर तुम्ही अद्याप प्रॉक्सी निवडली नसेल, तर nginx, Caddy आणि Traefik ची तुलना काही सबडोमेन्स असलेल्या एकाच सर्व्हरसाठी कोणती प्रॉक्सी योग्य आहे, हे स्पष्ट करते.

तुम्ही स्वतः सर्व्हर होस्ट करत असाल, तरीही तुम्हाला कुकी बॅनरची गरज आहे का?

सेल्फ-होस्टिंगमुळे डेटा कोणाकडे आहे हे बदलते, पण डेटाबाबतचे कायदे बदलत नाहीत. दोन नियम वेगळे ठेवा. ePrivacy संमतीचा नियम अभ्यागताच्या डिव्हाइसवर काहीही साठवण्याबद्दल किंवा वाचण्याबद्दल आहे. त्यामुळे, जे साधन कोणतीही कुकी सेट करत नाही आणि लोकल स्टोरेजमध्ये काहीही लिहित नाही, ते या विशिष्ट नियमाच्या कक्षेबाहेर राहते. GDPR हे वैयक्तिक डेटावर प्रक्रिया करण्याबद्दल आहे आणि IP ॲड्रेस हा वैयक्तिक डेटा मानला जातो. त्यामुळे, तुमच्याकडे कायदेशीर आधार, डेटा साठवण्याची मर्यादा आणि कोणी विचारल्यास त्यांच्याबद्दल तुमच्याकडे काय माहिती आहे याचे उत्तर असणे आवश्यक आहे.

Plausible, Umami, GoatCounter आणि Medama हे बाय-डिफॉल्ट कोणतीही कुकी सेट करत नाहीत. प्रत्येक साधन काय माहिती गोळा करते हे प्रोजेक्टनुसार आणि आवृत्तीनुसार बदलते, त्यामुळे सारांशावर अवलंबून न राहता त्या प्रोजेक्टचे स्वतःचे प्रायव्हसी डॉक्युमेंटेशन वाचा. Matomo मध्ये IP anonymisation आणि opt-out एंडपॉइंटची सुविधा आहे, जी तुम्ही ॲडमिन इंटरफेसमध्ये इनेबल करू शकता.

विविध देशांतील नियामक संस्थांचे निष्कर्ष वेगवेगळे असू शकतात. उदाहरणार्थ, फ्रान्सची CNIL अशा अटी प्रकाशित करते ज्या अंतर्गत प्रेक्षक मोजमाप (audience measurement) संमतीतून मुक्त असू शकते. हा विभाग केवळ तथ्यात्मक सारांश आहे, कायदेशीर सल्ला नाही. खऱ्या वापरकर्त्यांसह असलेल्या वेबसाइटसाठी, तुमच्या अधिकारक्षेत्रातील वकिलाचा सल्ला घ्या.

एक महत्त्वाची गोष्ट जी अनेकदा दुर्लक्षित केली जाते: ॲक्सेस लॉग (access log) हा देखील वैयक्तिक डेटा असतो. GoAccess पेजवर कोणतीही स्क्रिप्ट जोडत नाही, तरीही ते IP ॲड्रेसवर प्रक्रिया करते. त्यामुळे, लॉग-आधारित ॲनालिटिक्स आपोआप नियमांच्या बाहेर नसते.

Ad blockers आणि तुमच्या आकड्यांमध्ये होणारी घट

Filter lists हे hostname आणि URL pattern वर आधारित असतात. होस्ट केलेले analytics उत्पादन फिल्टर करणे सोपे असते, कारण प्रत्येकजण ते एकाच सुप्रसिद्ध hostname वरून लोड करतो. collector ला तुमच्या स्वतःच्या subdomain वर हलवल्यामुळे विनंतीमधून तो hostname निघून जातो आणि तुम्ही निवडलेल्या path वरून script सर्व्ह केल्यामुळे सुप्रसिद्ध filename देखील निघून जाते. या दोन्ही गोष्टींमुळे filter list ला ज्या गोष्टी जुळवायच्या असतात, त्या बदलतात.

या पोस्टमध्ये हिट रेटचा कोणताही दावा केलेला नाही, कारण त्याचे मोजमाप केलेले नाही. किती अभ्यागत (visitors) एखादी विशिष्ट सेटअप ब्लॉक करतात, हे तुमच्या प्रेक्षकांवर अवलंबून असते; सामान्य प्रेक्षकांच्या तुलनेत डेव्हलपर प्रेक्षक अधिक प्रमाणात ब्लॉक करतात. त्याऐवजी तुमच्या स्वतःच्या डेटा मधील तफावत मोजा. एकाच आठवड्यात, GoAccess वापरून access log मधील HTML पृष्ठांच्या विनंत्या मोजा आणि तुमच्या script-आधारित टूलने नोंदवलेल्या pageviews शी त्यांची तुलना करा. यातील फरक म्हणजे ब्लॉक केलेल्या भेटी आणि तुमच्या साइटवर cache मधून सर्व्ह केलेली पृष्ठे होय.

होस्ट केलेल्या उत्पादनाकडून स्वतःच्या सेटअपवर स्विच केल्याच्या दिवशी एकूण आकड्यांमध्ये बदल होण्याची अपेक्षा ठेवा आणि या बदलाचा काही भाग हा ब्लॉकिंगशी संबंधित नसेल हे लक्षात घ्या. pageview म्हणजे काय, single page application मधील route बदलणे म्हणजे एक pageview मानले जाते का, आणि session कधी संपते, यावर विविध उत्पादनांची मते भिन्न असतात. ट्रॅफिक कमी झाले असा निष्कर्ष काढण्यापूर्वी अनेक आठवड्यांच्या ट्रेंडची तुलना करा.

कोणत्या साइटसाठी कोणते साधन निवडावे

• वैयक्तिक साइट किंवा ब्लॉग (दरमहा 50,000 पेक्षा कमी पेजव्ह्यूज): 1 GB VPS वर GoatCounter किंवा Medama वापरा, ज्यासाठी बॅकअप म्हणून फक्त फाईल कॉपी पुरेशी आहे.
• अशी साइट जिथे तुम्ही स्क्रिप्ट जोडू शकत नाही किंवा जिथे वापरकर्ते मोठ्या प्रमाणावर ट्रॅकिंग ब्लॉक करतात: अशा वेळी शेड्यूलनुसार चालणारे GoAccess वापरा, जे थेट सर्व्हर लॉग्सवरून माहिती घेते.
• लहान व्यवसायाची साइट जिथे डॅशबोर्ड इतर कोणीतरी पाहणार आहे: Postgres कंटेनरसह Umami वापरा.
• अशी साइट जिथे तुम्हाला गोल्स (goals) आणि फनल्स (funnels) हवे आहेत आणि तुमच्याकडे 2 GB किंवा त्यापेक्षा जास्त RAM असलेला सर्व्हर आहे: Plausible Community Edition वापरा, किंवा जर तुम्हाला नवीन डॅशबोर्ड हवा असेल आणि तुम्ही एका नवीन प्रकल्पाशी जुळवून घेऊ शकत असाल तर Rybbit निवडा.
• अनेक साइट्स, अनेक युजर अकाउंट्स किंवा कच्चा डेटा (raw data) स्वतःच्या रिटेंशन पॉलिसीनुसार ठेवण्याची गरज असल्यास: Matomo वापरा, ज्याचा आकार वर दिलेल्या मार्गदर्शक तत्त्वांनुसार ठरवा.

तुमच्या प्रश्नाचे उत्तर देणाऱ्या सर्वात लहान साधनाने सुरुवात करा. नंतर GoatCounter कडून Plausible कडे जाण्यासाठी तुम्हाला फक्त एक सबडोमेन आणि काही जुना इतिहास गमवावा लागेल. मात्र, Matomo कडून इतर कोणत्याही साधनाकडे जाण्यासाठी तुम्हाला एक कठीण मायग्रेशन करावे लागेल, जे तुम्हाला आवडणार नाही. जर तुम्ही अजूनही त्याच सर्व्हरवर इतर काय असावे याचा विचार करत असाल, तर व्यापक सेल्फ-होस्टिंग राउंडअप मध्ये त्यासोबत काय बसू शकते याची माहिती दिली आहे. आणि जर तुम्हाला अभ्यागतांच्या संख्येपेक्षा ॲप्लिकेशनच्या विनंत्यांचे (request level tracing) ट्रॅकिंग हवे असेल, तर सेल्फ-होस्टेड ऑब्झर्व्हेबिलिटी सर्व्हिस हे त्यासाठी योग्य साधन आहे.

FAQ

स्वतःहून ॲनालिटिक्स होस्ट केल्यामुळे कुकी बॅनरची गरज संपते का?

नाही, आणि हे दोन्ही प्रश्न वेगळे आहेत. ePrivacy अंतर्गत संमतीचा नियम अभ्यागताच्या डिव्हाइसवर काहीही साठवण्याशी किंवा वाचण्याशी संबंधित आहे, त्यामुळे जे साधन कोणतीही कुकी सेट करत नाही आणि लोकल स्टोरेजमध्ये काहीही लिहित नाही, ते या विशिष्ट नियमाच्या कक्षेत येत नाही. GDPR हा एक वेगळा नियम आहे आणि तो वैयक्तिक डेटावर प्रक्रिया करण्याशी संबंधित आहे. IP ॲड्रेस हा वैयक्तिक डेटा मानला जातो, त्यामुळे कुकी नसली तरीही तुम्हाला कायदेशीर आधार आणि डेटा साठवण्याची मर्यादा असणे आवश्यक आहे. स्वतःहून होस्ट केल्यामुळे डेटा तुमच्या सर्व्हरवर येतो आणि तुम्ही त्यासाठी जबाबदार ठरता. तुमच्या स्थानिक नियामक प्राधिकरणाचे मार्गदर्शन तपासा आणि तुमच्या केससाठी कायदेशीर सल्ला घ्या.

VPS वर स्वतःहून होस्ट केलेल्या ॲनालिटिक्ससाठी किती RAM लागते?

हे डॅशबोर्डवर नाही, तर डेटास्टोअरवर अवलंबून असते. GoatCounter आणि Medama एका फाईलवर एक प्रोसेस म्हणून चालतात आणि Medama च्या डॉक्युमेंटेशननुसार लहान साईट्स 256 MB RAM असलेल्या मशीनवर चालू शकतात. Umami मध्ये Node ॲप्लिकेशनसोबत एक Postgres कंटेनर लागतो. Plausible Community Edition आणि Rybbit दोन्ही ClickHouse वापरतात आणि दोन्ही प्रोजेक्ट्सनुसार किमान 2 GB RAM आवश्यक आहे. Matomo च्या स्वतःच्या मार्गदर्शनानुसार, दरमहा 1,00,000 पेजव्ह्यूजसाठी 2 CPU कोअर्स आणि 2 GB RAM लागते.

माझ्या जुन्या ॲनालिटिक्सच्या तुलनेत स्वतःहून होस्ट केलेल्या ॲनालिटिक्सचे आकडे कमी का आहेत?

याची दोन खरी कारणे आहेत. फिल्टर लिस्ट काही कलेक्टर विनंत्या ब्लॉक करतात, त्यामुळे स्क्रिप्ट-आधारित प्रत्येक टूल अशा भेटी गमावते. तसेच, प्रत्येक प्रॉडक्ट मोजणी वेगळ्या पद्धतीने करते; पेजव्ह्यू म्हणजे काय आणि सेशन कधी संपते, याचे निकष त्यांच्यात वेगवेगळे असतात. तुमच्या ॲक्सेस लॉगवरून एका आठवड्यातील HTML पेज विनंत्यांची तुलना त्याच आठवड्यातील स्क्रिप्ट-आधारित पेजव्ह्यूजशी करा. हा फरक म्हणजे ब्लॉक केलेल्या भेटी आणि कॅश केलेली पेजेस आहेत, जे कोणाच्या तरी प्रकाशित दरावरून मोजण्याऐवजी तुमच्या स्वतःच्या साईटवर मोजले जातात.

मी ARM VPS वर Plausible किंवा Rybbit चालवू शकतो का?

दोन्ही ClickHouse वापरतात आणि ClickHouse ला x86 वर SSE 4.2 किंवा ARM वर NEON ची आवश्यकता असते. Plausible च्या गरजांमध्ये हे स्पष्ट नमूद आहे आणि Rybbit च्या डॉक्युमेंटेशननुसार ARM सिस्टिमला ARMv8.2-A किंवा त्यापुढील व्हर्जन आवश्यक आहे. सध्याचे ARM सर्व्हर कोअर्स हे निकष पूर्ण करतात, पण जुने कोअर्स करत नाहीत. अशा वेळी ClickHouse सुरू होत नाही आणि ॲप्लिकेशन लॉगमध्ये दिसण्याऐवजी इन्स्ट्रक्शन सेट एरर (instruction set error) येतो. लहान ARM बॉक्सवर, सिंगल फाईल टूल्स वापरल्यास हा प्रश्न उद्भवत नाही, कारण त्यापैकी कोणतेही टूल ClickHouse वापरत नाही.

ट्रॅकिंग स्क्रिप्ट वापरण्याऐवजी मी सर्व्हर लॉग्स पार्स करावेत का?

जेव्हा तुम्ही स्क्रिप्ट जोडू शकत नाही, जेव्हा तुमचे प्रेक्षक मोठ्या प्रमाणावर ट्रॅकिंग ब्लॉक करतात, किंवा जेव्हा तुम्हाला क्रॉलर्ससह मोजणी हवी असते, तेव्हा लॉग पार्सिंग वापरा. GoAccess तुमच्या सर्व्हरने आधीच लिहिलेला लॉग वाचते, त्यामुळे ते पेजवर कोणताही भार टाकत नाही किंवा डेटाबेस वापरत नाही. यामध्ये ब्राउझरच्या आत घडणाऱ्या गोष्टींची माहिती मिळत नाही आणि CDN किंवा ब्राउझर कॅशवरून सर्व्ह केलेले पेज मोजले जात नाही, कारण ती विनंती तुमच्या सर्व्हरपर्यंत पोहोचत नाही. अनेक साईट्स दोन्ही पद्धती वापरतात आणि त्यांना दोन वेगळी मोजमापे मानतात.