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 को पढ़ता है जो पहले से मौजूद है।

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

Script tag browsers को मापता है। पेज लोड होता है, script चलती है, और यह आपके collector को एक request भेजती है। इस chain को तोड़ने वाली कोई भी चीज़ आपको दिखाई नहीं देगी: JavaScript का बंद होना, request को block करने वाली filter list, collector को भेजी गई failed 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। यह सूची browsers के बजाय requests को गिनने की कीमत है।

Bot traffic इस अंतर का दूसरा हिस्सा है। Log-based counts में crawlers शामिल होते हैं जब तक कि आप उन्हें filter न करें, और एक सामान्य site पर crawler का हिस्सा इतना बड़ा होता है कि वह आपके निष्कर्षों को बदल सकता है। GoAccess और Matomo का log import दोनों ज्ञात bots को filter करते हैं। इनमें से कोई भी ऐसा crawler filter नहीं कर सकता जो अपने user agent के बारे में झूठ बोलता है, जो कि किसी भी log-based counting को server पर AI crawlers को block करने के साथ जोड़ने और 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 को स्वयं संभाल सकता है, ACME (automatic certificate management environment) का उपयोग करके, जो ऐसे सर्वर पर उपयोगी है जहाँ कुछ और नहीं चल रहा हो। जहाँ nginx या Caddy पहले से ही पोर्ट 443 का उपयोग कर रहे हों, वहाँ GoatCounter को 8080 पर छोड़ दें और traffic को उस पर proxy करें। प्रोजेक्ट के अपने आंकड़ों के अनुसार tracking script लगभग 3.5K की है, और उन पेजों के लिए एक tracking pixel भी उपलब्ध है जिनमें JavaScript नहीं है। यदि व्यस्त साइट पर SQLite सीमा बन जाता है, तो वही बाइनरी goatcounter serve -db 'postgresql+dbname=goatcounter' के साथ Postgres का उपयोग कर सकती है। बैकअप केवल एक फ़ाइल की कॉपी है, जो इस प्रकार के टूल का सबसे बड़ा लाभ है।

Medama: एक सिंगल कंटेनर जो 256 MB RAM का दावा करता है

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 prefix जानबूझकर लगाया गया है और reverse proxy सेक्शन में इसका कारण समझाया गया है। पहली बार लॉगिन admin के साथ होता है और पासवर्ड CHANGE_ME_ON_FIRST_LOGIN है, और उस पासवर्ड का नाम ही निर्देश है।

एक प्रलेखित विफलता (failure mode) आपको परेशान कर सकती है। लॉगिन केवल HTTPS पर या localhost पर काम करता है। इसलिए, यदि आप सर्टिफिकेट से पहले प्रॉक्सी सेटअप करते हैं, तो फॉर्म सही पासवर्ड को भी अस्वीकार कर देगा और इसका कारण स्क्रीन पर नहीं दिखेगा। पहले TLS (transport layer security) सेटअप पूरा करें, उसके बाद ही लॉगिन करें।

Umami: Postgres और एक जाना-पहचाना डैशबोर्ड

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

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

पहला लॉगिन admin है और पासवर्ड umami है। DNS को इस सर्वर पर पॉइंट करने से पहले इसे बदलें, क्योंकि जैसे ही रिकॉर्ड resolve होता है और प्रॉक्सी जवाब देना शुरू करती है, यह instance इंटरनेट से एक्सेस किया जा सकता है। Compose विवरण, environment files और restart policy के लिए, किसी ऐसे stack को कॉपी करने के बजाय जिसे आपने पढ़ा न हो, a Docker Compose stack on a VPS देखें।

इसका footprint एक Node प्रोसेस और Postgres है। यह एक सिंगल बाइनरी से भारी है, लेकिन 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

अगस्त 2026 तक Version v3.2.1 वर्तमान है, और clone कमांड इसे जानबूझकर पिन करती है। यह स्टैक तीन भागों से बना है: एप्लिकेशन, अकाउंट और सेटिंग्स के लिए Postgres, और इवेंट डेटा के लिए ClickHouse। SECRET_KEY_BASE कम से कम 64 बाइट की स्ट्रिंग होनी चाहिए, जो कि openssl कॉल द्वारा उत्पन्न होती है।

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

BASE_URL का मान बिल्कुल public URL के समान होना चाहिए। यदि ऐसा नहीं है, तो आप लॉग इन करते हैं, ऐप गलत होस्ट पर रीडायरेक्ट हो जाता है, और सेशन कुकी उस डोमेन के लिए लिखी जाती है जिस पर आपका ब्राउज़र नहीं है। परिणामस्वरूप, आप बिना किसी त्रुटि संदेश के वापस लॉगिन फॉर्म पर आ जाते हैं।

प्रदान की गई compose फ़ाइल किसी पोर्ट को पब्लिश नहीं करती है, क्योंकि इसके सामने एक प्रॉक्सी होने की अपेक्षा की जाती है। एक ओवरराइड जोड़ें जो डिफ़ॉल्ट एप्लिकेशन पोर्ट को केवल loopback पर पब्लिश करे।

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 को हटा सकता है। इसे 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 एक हालिया प्रोजेक्ट है जिसमें आधुनिक डैशबोर्ड मिलता है। इसका setup script environment file लिखता है और Docker Compose के साथ स्टैक को शुरू करता है। यह ClickHouse चलाता है और अपने वेब सर्वर के रूप में Caddy का उपयोग करता है, जो port 443 को ले लेता है और आपके द्वारा दिए गए डोमेन के लिए certificate का अनुरोध करता है। यदि किसी सर्वर पर nginx पहले से ही 443 का उपयोग कर रहा है, तो script bind नहीं हो पाएगी। ऐसी स्थिति में, प्रोजेक्ट के manual Compose तरीके का उपयोग करें और इसे अपने मौजूदा proxy के पीछे रखें। दस्तावेज़ों के अनुसार इसके लिए कम से कम 2 GB RAM की आवश्यकता है, इसे Ubuntu 24 LTS पर टेस्ट किया गया है, और ClickHouse के कारण ARM पर ARMv8.2-A या उससे नया आर्किटेक्चर आवश्यक है।

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

रिटेंशन और डिस्क ग्रोथ: अपने सर्वर पर इसे मापें

डिस्क की ग्रोथ इस बात पर निर्भर करती है कि टूल प्रति इवेंट क्या स्टोर करता है। 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 आपको चेतावनी दे सके। यह जोखिम उस सर्वर पर अधिक ध्यान देने योग्य है जिसमें पहले से ही कुछ भारी डेटा मौजूद है, क्योंकि एक सेल्फ-होस्टेड फोटो सर्वर किसी भी एनालिटिक्स डेटाबेस के करीब पहुंचने से बहुत पहले ही डिस्क को फुल कर देगा।

Reverse proxy के पीछे subdomain पर इसका व्यवहार

Collector को उस साइट के subdomain पर रखें जिसे वह measure करता है, जैसे कि 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 से reachable होता है, भले ही 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-host करने पर भी कुकी बैनर की आवश्यकता होती है?

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

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

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

एक बिंदु जिसे लोग नजरअंदाज कर देते हैं: access log भी व्यक्तिगत डेटा है। GoAccess पेज पर कोई स्क्रिप्ट नहीं जोड़ता है, फिर भी यह IP addresses को प्रोसेस करता है, इसलिए log-based analytics स्वचालित रूप से नियमों के दायरे से बाहर नहीं होते हैं।

Ad blockers और आपके numbers में गिरावट के कारण

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

यह post किसी hit rate का दावा नहीं करती, क्योंकि इसे मापा नहीं गया है। किसी भी setup को block करने वाले visitors की संख्या आपके audience पर निर्भर करती है, और एक developer audience, सामान्य audience की तुलना में कहीं अधिक block करती है। इसके बजाय अपने स्वयं के gap को मापें। एक ही सप्ताह के दौरान, GoAccess के साथ access log में HTML pages के लिए requests की गणना करें, और इसकी तुलना उस pageviews से करें जो आपका script-आधारित tool report करता है। अंतर, blocked visits और आपकी site पर 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 ब्लॉक करते हैं: मौजूदा log पर GoAccess को एक schedule के अनुसार चलाएँ।
• एक छोटा व्यावसायिक साइट जहाँ कोई अन्य व्यक्ति डैशबोर्ड देखता है: Umami का उपयोग करें, इसके Postgres container के साथ।
• ऐसी साइट जहाँ आप goals और funnels ट्रैक करना चाहते हैं, और आपके पास 2 GB RAM या उससे अधिक वाला सर्वर है: Plausible Community Edition का उपयोग करें, या यदि आप नया डैशबोर्ड चाहते हैं और एक नए प्रोजेक्ट के साथ काम करने को तैयार हैं, तो Rybbit चुनें।
• कई साइटें, कई user accounts, या अपनी स्वयं की retention policy के तहत raw data रखने की आवश्यकता: Matomo का उपयोग करें, जिसे ऊपर दिए गए प्रकाशित मार्गदर्शन के अनुसार आकार दें।

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

FAQ

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

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

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

यह dashboard नहीं, बल्कि datastore तय करता है। GoatCounter और Medama एक फाइल पर एक process के रूप में चलते हैं, और Medama का documentation कहता है कि छोटी साइटें 256 MB वाली मशीनों पर चल सकती हैं। Umami एक Node application के साथ एक Postgres container जोड़ता है। Plausible Community Edition और Rybbit दोनों ClickHouse चलाते हैं, और दोनों प्रोजेक्ट्स कम से कम 2 GB की आवश्यकता बताते हैं। 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 से serve किए गए किसी भी page को नहीं देख पाते, क्योंकि वह request आपके सर्वर तक कभी नहीं पहुँची। कई साइटें दोनों का उपयोग करती हैं और उन्हें दो अलग-अलग मापदंडों के रूप में देखती हैं।