Self-hosted web analytics के लिए बेहतरीन VPS विकल्प

VPS पर कौन सा self-hosted web analytics tool चलाना चाहिए?

Self-hosted web analytics दो श्रेणियों में आते हैं, और गलत श्रेणी चुनने का नुकसान गलत product चुनने से कहीं अधिक होता है। एक श्रेणी visitor के browser में एक छोटा script चलाती है और वह script जो रिपोर्ट करता है उसे store करती है। दूसरी श्रेणी उस access log को पढ़ती है जिसे आपका web server पहले से ही लिख रहा है। उसके बाद की हर चीज, जिसमें database और आवश्यक memory शामिल है, इसी एक चुनाव पर निर्भर करती है।

छोटे server के लिए संक्षिप्त उत्तर यह है। GoatCounter और Medama 1 GB RAM पर चल जाते हैं, क्योंकि प्रत्येक एक file पर आधारित एक ही process है। Umami एक Postgres container जोड़ता है और आपको एक ऐसा dashboard देता है जिसे कोई गैर-तकनीकी व्यक्ति भी पढ़ सकता है। Plausible Community Edition और Rybbit दोनों ClickHouse का उपयोग करते हैं, इसलिए 2 GB या उससे अधिक RAM की योजना बनाएँ। Matomo एक पूर्ण product है और आपके traffic के अनुसार server के आकार की मांग करता है। GoAccess page पर कुछ भी नहीं जोड़ता है, क्योंकि यह केवल पहले से मौजूद log file को पढ़ता है।

Script tag या server log: प्रत्येक क्या देख सकता है

Script tag ब्राउज़र को मापता है। पेज लोड होता है, script चलती है, और यह आपके collector को एक request भेजती है। जो कुछ भी उस श्रृंखला को तोड़ता है, वह आपको दिखाई नहीं देता: JavaScript का बंद होना, request को ब्लॉक करने वाली filter list, collector तक request का विफल होना, या ऐसा crawler जो कभी scripts नहीं चलाता।

Log parser requests को मापता है। आपका web server प्रत्येक request के लिए एक line लिखता है, चाहे आप कुछ भी install करें या न करें, इसलिए data पहले से ही disk पर मौजूद होता है। यह हर crawler और ऐसी file पर होने वाली हर hit को देखता है जिसमें कोई script tag नहीं होता। यह यह नहीं देख सकता कि browser के अंदर क्या हुआ, और यह browser cache या आपके box के सामने मौजूद CDN (content delivery network) से serve किए गए पेज को नहीं देख सकता, क्योंकि वह request कभी आपके server तक नहीं पहुँची।

दोनों संख्याएँ मेल नहीं खाएंगी, और उनमें से कोई भी गलत नहीं है। Matomo दोनों काम कर सकता है, और यह document करता है कि log import अपने JavaScript tracker की तुलना में क्या छोड़ देता है: screen resolution और page titles, events, content tracking, heatmaps, session recordings और form analytics। वह सूची ब्राउज़रों के बजाय requests को गिनने की कीमत है।

Bot traffic इस अंतर का दूसरा आधा हिस्सा है। Log-आधारित गणनाओं में crawlers शामिल होते हैं जब तक कि आप उन्हें filter न करें, और एक सामान्य site पर crawler का हिस्सा इतना बड़ा होता है कि वह आपके निष्कर्षों को बदल सकता है। GoAccess और Matomo का log import दोनों ज्ञात bots को filter करते हैं। उनमें से कोई भी ऐसे crawler को filter नहीं कर सकता जो अपने user agent के बारे में झूठ बोलता है, जो कि किसी भी log-आधारित गणना को blocking AI crawlers at the server के साथ जोड़ने और block करने से पहले के बजाय बाद में log को पढ़ने का एक अच्छा कारण है।

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 एक statically compiled बाइनरी के रूप में आता है, इसलिए इसमें कोई runtime install करने की आवश्यकता नहीं है। release पेज से एक build लें और उसे चलाएं, या image का उपयोग करें।

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

इसे बाइनरी के रूप में चलाने पर, goatcounter serve पोर्ट 8080 पर listen करता है और ./goatcounter-data/db.sqlite3 पर SQLite फ़ाइल बनाता है। जब instance पहले से ही किसी proxy के पीछे हो, तो web wizard के बजाय command line से पहली site बनाएँ।

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) का उपयोग होता है। यह उन servers के लिए उपयोगी है जहाँ कुछ और नहीं चल रहा है। जहाँ nginx या Caddy पहले से ही पोर्ट 443 का उपयोग कर रहे हों, वहाँ GoatCounter को 8080 पर ही रहने दें और traffic को उस पर proxy करें। प्रोजेक्ट के आंकड़ों के अनुसार tracking script लगभग 3.5K की है, और उन pages के लिए एक tracking pixel भी उपलब्ध है जहाँ JavaScript नहीं है। यदि किसी व्यस्त site पर SQLite सीमा बन जाता है, तो वही बाइनरी goatcounter serve -db 'postgresql+dbname=goatcounter' के साथ Postgres का उपयोग कर सकती है। बैकअप केवल एक फ़ाइल की copy है, जो इस प्रकार के टूल का सबसे बड़ा लाभ है।

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 पर काम करता है, इसलिए यदि आप सर्टिफिकेट से पहले प्रॉक्सी सेटअप करते हैं, तो फॉर्म सही पासवर्ड को भी अस्वीकार कर देगा और इसका कारण प्रदर्शित नहीं होगा। पहले TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) सेटअप पूरा करें, उसके बाद ही लॉगिन करें।

Umami: Postgres, और एक ऐसा डैशबोर्ड जिसे लोग पहचानते हैं

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

यह कमांड एप्लीकेशन को port 3000 पर, उसके साथ एक PostgreSQL container के साथ शुरू करता है। दस्तावेज़ों के अनुसार न्यूनतम आवश्यकता PostgreSQL v12.14 है, या यदि आप source से build करते हैं तो Node.js 18.18 या उससे नया संस्करण चाहिए। एक prebuilt image, docker.umami.is/umami-software/umami:postgresql-latest, उपलब्ध है जिसे एक ऐसे database की आवश्यकता होती है जिसे आप पहले से चला रहे हैं, जिसके लिए DATABASE_URL का उपयोग किया जाता है।

पहला login admin है और password umami है। DNS को इस box की ओर point करने से पहले इसे बदल लें, क्योंकि जैसे ही record resolve होता है और proxy जवाब देता है, यह instance internet से reachable हो जाता है। Compose विवरण, environment files और restart policy के लिए, किसी ऐसे stack को copy करने के बजाय जिसे आपने पढ़ा नहीं है, a Docker Compose stack on a VPS देखें।

इसका footprint एक 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

Version v3.2.1 अगस्त 2026 तक का नवीनतम संस्करण है, और clone command इसे जानबूझकर पिन करती है। यह stack तीन भागों से बना है: application, accounts और settings के लिए Postgres, और event data के लिए ClickHouse। SECRET_KEY_BASE कम से कम 64 byte की string होनी चाहिए, जिसे openssl call उत्पन्न करती है।

Plausible की अपनी आवश्यकताओं के अनुसार कम से कम 2 GB RAM की आवश्यकता होती है ताकि ClickHouse और application को out of memory killer का सामना न करना पड़े। साथ ही, एक ऐसे CPU की आवश्यकता होती है जो SSE 4.2 या NEON का समर्थन करता हो, जिसकी ClickHouse को जरूरत होती है। यह दूसरी आवश्यकता VPS खरीदने से पहले जाँचने योग्य है, और यह ARM और x86 VPS के बीच चयन करने के व्यावहारिक अंतरों में से एक है। ClickHouse उपलब्ध समझी जाने वाली पूरी मेमोरी का उपयोग कर सकता है, इसलिए shared box पर Compose में container memory को सीमित करने के निर्देशों के अनुसार एक अधिकतम सीमा निर्धारित करें।

BASE_URL का मान public URL के बिल्कुल समान होना चाहिए। यदि ऐसा नहीं होता है, तो आप login करते हैं, application गलत host पर redirect कर देती है, और session cookie उस domain के लिए लिखी जाती है जिस पर आपका browser नहीं है, जिसके परिणामस्वरूप आप बिना किसी error message के वापस login form पर आ जाते हैं।

प्रदान की गई compose file कोई port publish नहीं करती है, क्योंकि यह अपेक्षा की जाती है कि सामने एक proxy मौजूद होगा। एक override जोड़ें जो केवल loopback पर default application port को publish करे।

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

Matomo: संपूर्ण उत्पाद और इसके लिए आवश्यक सर्वर

Matomo, PHP के साथ MySQL या MariaDB पर चलता है। इसका मतलब है कि यह container stack के बजाय क्लासिक web stack के अनुकूल है। यह यहाँ मौजूद एकमात्र ऐसा टूल है जो traffic volume के आधार पर hardware संबंधी मार्गदर्शन प्रकाशित करता है।

[
  {
    "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 pageviews तक के लिए, यह 2 CPU cores, 2 GB RAM और 50 GB SSD की मांग करता है, और एक ही सर्वर पर application और database दोनों चलते हैं। 1M/month पर यह 8 GB RAM और 250 GB disk हो जाता है। 10M/month पर Matomo दो सर्वरों की अनुशंसा करता है, और अंतिम पंक्ति database सर्वर को दर्शाती है: 16 GB RAM और 400 GB disk। उन disk आंकड़ों को single binary विकल्पों के साथ पढ़ें, जहाँ पूरा dataset एक ही SQLite file में होता है।

Archiving वह प्रक्रिया है जो लोगों को आश्चर्यचकित करती है। डिफ़ॉल्ट रूप से, Matomo तब reports तैयार करता है जब कोई dashboard खोलता है। इसलिए, जैसे-जैसे data बढ़ता है, dashboard धीमा हो जाता है और अंततः time out हो जाता है। इसका प्रलेखित समाधान यह है कि general settings में browser triggered archiving को बंद कर दिया जाए और इसके बजाय cron से archiver को चलाया जाए। इसे उस user के रूप में चलाएं जो Matomo files का स्वामी है, और Matomo directory से चलाएं।

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

Matomo अपनी processed report tables के साथ raw log tables भी रखता है। यह एक schedule के अनुसार पुरानी raw data और पुरानी reports को delete कर सकता है। इसे install करते समय ही चालू करें, न कि तब जब disk भर जाए। Matomo server access logs को भी 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 एक वेब सर्वर के रूप में शामिल है, जो port 443 को लेता है और आपके द्वारा दिए गए डोमेन के लिए certificate का अनुरोध करता है। यदि किसी सर्वर पर nginx पहले से ही 443 का उपयोग कर रहा है, तो स्क्रिप्ट bind नहीं हो पाएगी। ऐसी स्थिति में, प्रोजेक्ट के manual Compose तरीके का उपयोग करें और इसे अपने मौजूदा proxy के पीछे रखें। दस्तावेज़ों के अनुसार कम से कम 2 GB RAM की आवश्यकता है, इसे Ubuntu 24 LTS पर टेस्ट किया गया है, और ClickHouse के कारण ARM पर ARMv8.2-A या उससे नया आर्किटेक्चर होना चाहिए।

किसी भी नए प्रोजेक्ट के लिए एक स्पष्ट चेतावनी: इसमें फीचर्स तेजी से आते हैं और साथ ही breaking changes भी हो सकते हैं। एक विशिष्ट tag को pin करें, pull करने से पहले release notes पढ़ें, और सबसे पहले database का backup लें।

Retention और disk growth: अपने सर्वर पर इसे मापें

Disk growth इस बात पर निर्भर करती है कि टूल प्रति event क्या स्टोर करता है। GoatCounter hits को counters में aggregate करता है, इसलिए इसकी फाइल raw volume की तुलना में distinct pages और दिनों के साथ अधिक बढ़ती है। Umami और Matomo प्रति event rows स्टोर करते हैं, और Matomo raw tables के ऊपर processed report tables भी स्टोर करता है। ClickHouse events को columns में स्टोर करता है और उन्हें काफी compress करता है, यही कारण है कि Plausible उस volume को संभाल लेता है जो row store पर दबाव डालती।

यह गाइड प्रति मिलियन pageviews के लिए megabytes का कोई आंकड़ा प्रकाशित नहीं करती है, क्योंकि इसने आपके traffic पर इसे नहीं मापा है। आप स्वयं रीडिंग लें। अपनी Compose फाइल से मेल खाने के लिए service और user names को adjust करें।

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"

संख्या को रिकॉर्ड करें, एक सप्ताह प्रतीक्षा करें, इसे फिर से रिकॉर्ड करें, और अंतर को उस सप्ताह के लिए dashboard द्वारा रिपोर्ट किए गए pageviews से विभाजित करें। वह आंकड़ा आपकी साइट और आपके bot filtering के बारे में है, इसलिए यह किसी भी प्रकाशित औसत से अधिक मूल्यवान है। फिर जब संख्या अभी भी छोटी हो, तो एक retention limit सेट करें। एक full disk VPS पर केवल analytics ही नहीं, बल्कि हर service को down कर देती है, जो database volume को ऐसी जगह रखने का सबसे मजबूत तर्क है जिसके बारे में df -h आपको चेतावनी देगा। वह जोखिम उस सर्वर पर अधिक ध्यान देने योग्य है जिसमें पहले से ही कुछ भारी डेटा मौजूद है, क्योंकि एक self-hosted photo server किसी भी analytics database के करीब पहुँचने से बहुत पहले ही disk को भर देगा।

रिवर्स प्रॉक्सी के पीछे यह कैसे व्यवहार करता है

कलेक्टर को उस साइट के सबडोमेन पर रखें जिसे वह मापता है, जैसे कि stats.example.com। इससे कलेक्टर का अनुरोध फर्स्ट-पार्टी बन जाता है, इसलिए यह उन ब्राउज़र नियमों से प्रभावित नहीं होता जो थर्ड-पार्टी अनुरोधों को ब्लॉक करते हैं।

Container port publish करते समय application को loopback पर bind करें। Docker अपने firewall rules को ufw से पहले लिखता है, इसलिए -p 3000:3000 के रूप में published container internet से reachable रहता है, भले ही ufw status दिखाए कि port denied है। किसी दूसरी machine से curl http://SERVER_IP:3000 चलाकर test करें और आपको dashboard मिल जाएगा। -p 127.0.0.1:3000:3000 के रूप में published होने पर यही test Connection refused देता है और इसे केवल proxy ही reach कर सकता है। यही आदत केवल dashboard को छिपाने से अधिक काम करती है: यह उसी box पर onion service चलाने का मूल सिद्धांत है, जहाँ public interface पर अब भी answer करने वाली कोई भी service hidden address को आपके IP से जोड़ देती है। Collector endpoint को open internet से reachable रहना आवश्यक है, लेकिन dashboard को नहीं। यदि आप दूसरा subdomain publish करने के बजाय इसे private network पर पढ़ना पसंद करते हैं, तो subnet router के साथ VPS network को अपने tailnet में advertise करना port खोले बिना यह संभव बनाता है।

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 की तुलना में यह बताया गया है कि कुछ सबडोमेन वाले सिंगल बॉक्स के लिए कौन सा उपयुक्त है।

क्या self-host करने पर भी कुकी बैनर की आवश्यकता होती है?

Self-hosting से यह बदल जाता है कि डेटा किसके पास है। यह कानून को डेटा के बारे में नहीं बदलता। दो नियमों को अलग रखें। ePrivacy सहमति नियम आगंतुक के डिवाइस पर कुछ भी स्टोर करने या पढ़ने के बारे में है, इसलिए जो टूल कोई कुकी सेट नहीं करता और local storage में कुछ नहीं लिखता, वह उस विशिष्ट आवश्यकता के दायरे से बाहर है। GDPR व्यक्तिगत डेटा को प्रोसेस करने के बारे में है, और IP address व्यक्तिगत डेटा माना जाता है, इसलिए आपको अभी भी एक कानूनी आधार, retention limit और जब कोई पूछे कि आप उनके बारे में क्या जानकारी रखते हैं, तो उसका उत्तर देने की आवश्यकता है।

Plausible, Umami, GoatCounter और Medama डिफ़ॉल्ट रूप से कोई कुकी सेट नहीं करते हैं। प्रत्येक टूल इसके बजाय क्या जानकारी निकालता है, यह प्रोजेक्ट के अनुसार अलग है और वर्ज़न के साथ बदलता रहता है, इसलिए सारांश के बजाय प्रोजेक्ट के स्वयं के गोपनीयता दस्तावेज़ पढ़ें। Matomo में IP anonymisation और एक opt-out endpoint होता है जिसे आप admin interface में सक्षम कर सकते हैं।

नियामक अलग-अलग देशों में अलग-अलग निष्कर्ष निकालते हैं। उदाहरण के लिए, फ्रांस का CNIL उन शर्तों को प्रकाशित करता है जिनके तहत audience measurement को सहमति से छूट दी जा सकती है। यह अनुभाग केवल तथ्यों का सारांश है और कानूनी सलाह नहीं है। वास्तविक उपयोगकर्ताओं वाली वास्तविक साइट के लिए, अपने अधिकार क्षेत्र के किसी वकील से परामर्श लें।

एक बिंदु जिसे लोग भूल जाते हैं: access log भी व्यक्तिगत डेटा है। GoAccess पेज पर कोई स्क्रिप्ट नहीं जोड़ता है, फिर भी यह IP addresses को प्रोसेस करता है, इसलिए log-आधारित एनालिटिक्स स्वचालित रूप से नियमों के दायरे से बाहर नहीं है। किसी सर्विस को अपने स्वयं के बॉक्स पर ले जाने से जोखिम का स्थान बदल जाता है, न कि वह समाप्त होता है, यही कारण है कि एक self-hosted SearXNG instance वास्तव में क्या छिपाता है केवल सर्च इंजन तक सीमित रहता है, जबकि क्वेरी स्वयं आपके अपने लॉग में दर्ज होती रहती हैं।

Ad blockers, और आपकी संख्या में गिरावट क्यों आएगी

Filter lists, hostname और URL pattern के आधार पर मिलान करती हैं। किसी hosted analytics product का मिलान करना आसान होता है, क्योंकि हर कोई इसे एक ही प्रसिद्ध hostname से load करता है। Collector को अपने subdomain पर ले जाने से वह hostname request से हट जाता है, और script को अपनी चुनी हुई path से serve करने पर प्रसिद्ध filename भी हट जाती है। ये दोनों चीजें उस आधार को बदल देती हैं जिस पर list को मिलान करना होता है।

यह पोस्ट किसी hit rate का दावा नहीं करती, क्योंकि इसे मापा नहीं गया है। जो visitors किसी setup को block करते हैं, उनका हिस्सा आपके audience पर निर्भर करता है, और developer audience सामान्य audience की तुलना में कहीं अधिक block करती है। इसके बजाय अपने स्वयं के gap को मापें। एक ही सप्ताह के दौरान, GoAccess के साथ access log में HTML pages के लिए requests की गणना करें, और इसकी तुलना उस pageviews से करें जो आपका script-based tool रिपोर्ट करता है। अंतर, आपकी साइट पर blocked visits और cache से serve किए गए pages का योग है।

जब आप किसी hosted product से switch करते हैं, तो totals में बदलाव की अपेक्षा रखें, और यह भी मानकर चलें कि इस बदलाव का कुछ हिस्सा blocking से संबंधित नहीं होगा। Products इस बात पर असहमत होते हैं कि pageview क्या है, क्या single page application के भीतर route change को एक pageview गिना जाए, और session कब समाप्त होता है। यह निष्कर्ष निकालने से पहले कि traffic गिर गया है, सप्ताह-दर-सप्ताह trends की तुलना करें।

किस साइट के लिए कौन सा टूल चुनें

• एक व्यक्तिगत साइट या ब्लॉग जिस पर प्रति माह लगभग 50,000 pageviews आते हों: 1 GB VPS पर GoatCounter या Medama का उपयोग करें, जिसमें बैकअप के लिए केवल फाइल कॉपी पर्याप्त है।
• ऐसी साइट जहाँ आप कोई script नहीं जोड़ सकते, या जहाँ दर्शक भारी मात्रा में content block करते हैं: मौजूदा log पर schedule के अनुसार GoAccess का उपयोग करें।
• एक छोटा व्यावसायिक साइट जहाँ कोई अन्य व्यक्ति dashboard देखता है: Postgres container के साथ Umami का उपयोग करें।
• ऐसी साइट जहाँ आपको goals और funnels की आवश्यकता हो, और आपके पास 2 GB RAM या उससे अधिक वाला सर्वर हो: Plausible Community Edition का उपयोग करें, या यदि आप नया dashboard चाहते हैं और एक नए प्रोजेक्ट के साथ काम करने को तैयार हैं, तो Rybbit चुनें।
• कई साइटें, कई user accounts, या अपनी retention policy के तहत raw data रखने की आवश्यकता: ऊपर दिए गए प्रकाशित मार्गदर्शन के अनुसार Matomo का उपयोग करें।

सबसे छोटे टूल से शुरुआत करें जो आपके वास्तविक प्रश्न का उत्तर देता हो। बाद में GoatCounter से Plausible पर जाने में आपको केवल एक subdomain और कुछ इतिहास का नुकसान होगा। Matomo से किसी अन्य टूल पर जाने के लिए आपको एक ऐसी migration प्रक्रिया से गुजरना होगा जो कष्टदायक हो सकती है। यदि आप अभी भी यह तय कर रहे हैं कि उसी सर्वर पर और क्या होना चाहिए, तो व्यापक self-hosting roundup में उन चीजों के बारे में बताया गया है जो इसके साथ फिट हो सकती हैं। यदि आप वास्तव में visitor counts के बजाय किसी application की request level tracing चाहते हैं, तो एक self-hosted observability service उस कार्य के लिए सही टूल है।

FAQ

क्या self-hosted analytics का उपयोग करने से cookie banner की आवश्यकता खत्म हो जाती है?

नहीं, और ये दोनों अलग-अलग विषय हैं। ePrivacy के तहत सहमति का नियम आगंतुक के डिवाइस पर कुछ भी स्टोर करने या पढ़ने पर लागू होता है, इसलिए जो टूल कोई cookie सेट नहीं करता और local storage में कुछ भी नहीं लिखता, वह इस विशिष्ट आवश्यकता के दायरे से बाहर हो जाता है। GDPR एक अलग नियम है और यह व्यक्तिगत डेटा के प्रसंस्करण को कवर करता है, और IP address व्यक्तिगत डेटा है, इसलिए cookie न होने पर भी आपको एक कानूनी आधार और डेटा प्रतिधारण सीमा (retention limit) की आवश्यकता होती है। Self-hosting डेटा को आपके सर्वर पर ले आता है और आपको इसके लिए जिम्मेदार पक्ष बनाता है। अपने नियामक (regulator) के मार्गदर्शन की जाँच करें और अपने मामले के लिए किसी वकील से सलाह लें।

VPS पर self-hosted analytics के लिए कितनी RAM चाहिए?

यह निर्णय datastore पर निर्भर करता है, dashboard पर नहीं। GoatCounter और Medama एक फाइल पर एक process के रूप में चलते हैं, और Medama का documentation कहता है कि छोटी साइटें 256 MB वाली मशीनों पर चल सकती हैं। Umami एक Node application के साथ एक Postgres container जोड़ता है। Plausible Community Edition और Rybbit दोनों ClickHouse का उपयोग करते हैं, और दोनों प्रोजेक्ट्स कम से कम 2 GB RAM की आवश्यकता बताते हैं। Matomo का अपना मार्गदर्शन प्रति माह 100,000 pageviews तक के लिए 2 CPU cores और 2 GB RAM से शुरू होता है।

मेरे self-hosted आँकड़े उन analytics से कम क्यों हैं जिन्हें मैंने बदला है?

इसके दो कारण हैं, और दोनों वास्तविक हैं। Filter lists कुछ collector requests को ब्लॉक कर देती हैं, इसलिए हर script-आधारित टूल उन visits को खो देता है। ये प्रोडक्ट्स अलग-अलग तरीके से गणना भी करते हैं, क्योंकि pageview क्या है और session कब समाप्त होता है, यह हर टूल में अलग-अलग होता है। अपने access log से HTML page requests के एक सप्ताह की तुलना script-आधारित pageviews के उसी सप्ताह से करें। यह अंतर ब्लॉक की गई visits और cached pages का योग है, जिसे किसी और के प्रकाशित दर से लेने के बजाय अपनी साइट पर मापा गया है।

क्या मैं ARM VPS पर Plausible या Rybbit चला सकता हूँ?

दोनों ClickHouse का उपयोग करते हैं, और ClickHouse को x86 पर SSE 4.2 या ARM पर NEON की आवश्यकता होती है। Plausible की आवश्यकताएं बिल्कुल यही कहती हैं, और Rybbit के docs कहते हैं कि ARM सिस्टम को ARMv8.2-A या उससे नए की आवश्यकता है। वर्तमान ARM सर्वर cores इस मानक को पूरा करते हैं, जबकि पुराने नहीं करते हैं, और यह विफलता application log में कुछ दिखने के बजाय ClickHouse द्वारा instruction set error के साथ start होने से इनकार करने के रूप में दिखाई देती है। एक छोटे ARM बॉक्स पर, single file वाले टूल इस समस्या से बच जाते हैं, क्योंकि उनमें से कोई भी ClickHouse नहीं चलाता है।

क्या मुझे tracking script का उपयोग करने के बजाय server logs को parse करना चाहिए?

Log parsing का उपयोग तब करें जब आप script नहीं जोड़ सकते, जब आपका audience भारी मात्रा में ब्लॉक करता है, या जब आप ऐसी गणना चाहते हैं जिसमें crawlers शामिल हों। GoAccess उस log को पढ़ता है जिसे आपका सर्वर पहले से ही लिख रहा है, इसलिए यह कोई page weight या database नहीं जोड़ता है। आप वह सब कुछ खो देते हैं जो browser के अंदर होता है, और आप CDN या browser cache से परोसे गए किसी भी page को नहीं देख पाते हैं, क्योंकि वह request कभी आपके सर्वर तक नहीं पहुँची। कई साइटें दोनों का उपयोग करती हैं और उन्हें दो अलग-अलग मापदंडों के रूप में देखती हैं।