أفضل أدوات تحليلات الويب على VPS صغير

ما أداة تحليلات الويب المستضافة ذاتياً التي ينبغي تشغيلها على VPS؟

تنقسم تحليلات الويب المستضافة ذاتياً إلى عائلتين. ويكلفك اختيار العائلة الخاطئة أكثر من اختيار المنتج الخاطئ. تشغّل إحدى العائلتين نصاً صغيراً في متصفح الزائر، وتخزّن البيانات التي يرسلها ذلك النص. أما العائلة الأخرى فتقرأ سجل الوصول الذي يكتبه خادم الويب لديك بالفعل. وكل ما يأتي بعد ذلك، بما في ذلك قاعدة البيانات والذاكرة التي تحتاج إليها، يتحدد وفق هذا الاختيار الواحد.

الإجابة المختصرة لخادم صغير: يعمل GoatCounter وMedama على 1 GB، لأن كل واحد منهما عبارة عن عملية واحدة تتعامل مع ملف واحد. يضيف Umami حاوية Postgres، ويوفّر لوحة معلومات يستطيع الشخص غير التقني قراءتها. يشغّل كل من Plausible Community Edition وRybbit قاعدة بيانات ClickHouse، لذلك خطط لتوفير 2 GB من RAM أو أكثر. Matomo هو المنتج الكامل، ويحتاج إلى خادم يتناسب حجمه مع حجم حركة المرور لديك. أما GoAccess فلا يضيف شيئاً إلى الصفحة، لأنه يقرأ سجلاً موجوداً بالفعل.

وسم script أو سجل الخادم: ما الذي يمكن لكل منهما رؤيته

يقيس وسم script المتصفحات. تُحمَّل الصفحة، ويعمل script، ثم يرسل طلباً واحداً إلى أداة التجميع لديك. أي خلل في هذه السلسلة لا يظهر لك: تعطيل JavaScript، أو قائمة ترشيح تحظر الطلب، أو فشل الطلب المرسل إلى أداة التجميع، أو زاحف لا يشغّل scripts.

يحلّل محلّل السجلات الطلبات. يكتب خادم الويب سطراً واحداً لكل طلب، سواء ثبّتَّ أي شيء أم لا، لذلك تكون البيانات موجودة على القرص مسبقاً. وهو يرى كل زاحف وكل طلب لملف لا يحتوي على وسم script. لكنه لا يستطيع رؤية ما حدث داخل المتصفح، ولا يستطيع رؤية صفحة قُدّمت من ذاكرة التخزين المؤقت للمتصفح أو من CDN (شبكة توصيل المحتوى) موجود أمام خادمك، لأن ذلك الطلب لم يصل إلى خادمك.

لن يتطابق الرقمان، ولا يعني ذلك أن أحدهما خاطئ. يستطيع Matomo تنفيذ الطريقتين، ويوثّق ما تفقده عملية استيراد السجلات مقارنةً بمتتبّع JavaScript الخاص به: دقة الشاشة وعناوين الصفحات، والأحداث، وتتبع المحتوى، والخرائط الحرارية، وتسجيلات الجلسات، وتحليلات النماذج. هذه هي تكلفة عدّ الطلبات بدلاً من عدّ المتصفحات.

تشكل حركة مرور الروبوتات النصف الآخر من الفارق. تشمل الإحصاءات المعتمدة على السجلات الزواحف ما لم ترشّحها، وتكون حصة الزواحف في الموقع العادي كبيرة بما يكفي لتغيير استنتاجاتك. يرشّح كل من GoAccess واستيراد السجلات في Matomo الروبوتات المعروفة. ولا يستطيع أي منهما ترشيح زاحف يزوّر User-Agent الخاص به، ولذلك من الأفضل الجمع بين أي عملية عدّ معتمدة على السجلات وحظر زواحف الذكاء الاصطناعي على الخادم، وقراءة السجل بعد الحظر لا قبله.

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 للمستخدم العادي، لأن سجل nginx في Ubuntu مملوك للحساب 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. يحتاج هذا الوضع إلى منفذ ثانٍ وقاعدة proxy مستقلة. بالنسبة إلى معظم المواقع، يكفي تقرير كل ساعة يكتبه cron، كما أن تأمينه يتطلب جهداً أقل.

GoatCounter: ملف Go ثنائي واحد وملف SQLite واحد

يُوزَّع GoatCounter كملف ثنائي مُجمَّع بشكل ثابت، لذلك لا تحتاج إلى تثبيت بيئة تشغيل. نزّل إصداراً من صفحة الإصدارات وشغّله، أو استخدم الصورة.

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

عند تشغيله كملف ثنائي، يستمع goatcounter serve على المنفذ 8080 وينشئ قاعدة SQLite في ./goatcounter-data/db.sqlite3. أنشئ الموقع الأول من سطر الأوامر بدلاً من معالج الإعداد على الويب عندما يكون المثيل خلف وكيل عكسي.

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 عائقاً على موقع كثير الاستخدام، فيمكن للملف الثنائي نفسه استخدام Postgres مع goatcounter serve -db 'postgresql+dbname=goatcounter'. أما النسخ الاحتياطية فهي مجرد نسخ للملف، وهذا هو السبب العملي الحقيقي لاختيار هذا النوع من الأدوات.

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. بادئة loopback أعلاه مقصودة، ويشرح قسم الـReverse Proxy سبب ذلك. يكون تسجيل الدخول الأول عبر admin باستخدام كلمة المرور CHANGE_ME_ON_FIRST_LOGIN، واسم كلمة المرور هو التعليمات.

هناك حالة فشل موثقة يجب الانتباه إليها. لا يعمل تسجيل الدخول إلا عبر HTTPS أو على localhost، لذلك إذا أعددت الـproxy قبل الشهادة، فسيرفض النموذج كلمة مرور صحيحة ولن يعرض السبب. أكمل إعداد TLS (أمان طبقة النقل) أولاً، ثم سجّل الدخول.

Umami: Postgres ولوحة معلومات مألوفة للمستخدمين

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

يشغّل ذلك التطبيق على المنفذ 3000، مع حاوية PostgreSQL إلى جانبه. تحدد الوثائق PostgreSQL v12.14 كإصدار أدنى، وتحتاج إلى Node.js 18.18 أو أحدث إذا أنشأت التطبيق من المصدر بدلاً من استخدام الصورة الجاهزة. تتوفر صورة مبنية مسبقاً، docker.umami.is/umami-software/umami:postgresql-latest، وتحتاج إلى توجيه DATABASE_URL إلى قاعدة بيانات قيد التشغيل لديك بالفعل.

بيانات تسجيل الدخول الأولى هي admin، وكلمة المرور هي umami. غيّرها قبل توجيه DNS إلى الخادم، لأن المثيل يصبح قابلاً للوصول من الإنترنت بمجرد أن يُحل السجل ويستجيب الـproxy. للحصول على تفاصيل Compose وملفات البيئة وسياسة إعادة التشغيل، راجع حزمة Docker Compose على VPS بدلاً من نسخ حزمة لم تقرأها.

يتكوّن هذا الحل من عملية 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

الإصدار v3.2.1 هو الإصدار الحالي حتى August 2026، ويثبّته أمر الاستنساخ عمداً. تتكوّن الحزمة من ثلاثة أجزاء: التطبيق، وPostgres للحسابات والإعدادات، وClickHouse لبيانات الأحداث. يجب أن يكون SECRET_KEY_BASE سلسلة بطول 64 بايت على الأقل، وهذا ما ينتجه استدعاء openssl.

تتطلب متطلبات Plausible الرسمية ذاكرة RAM بسعة 2 GB على الأقل حتى لا يتسبب ClickHouse والتطبيق في استدعاء قاتل نفاد الذاكرة، كما تتطلب CPU يدعم SSE 4.2 أو NEON، وهو ما يحتاج إليه ClickHouse. يجدر التحقق من هذا الشرط الثاني قبل الشراء، وهو أحد الفروق العملية عند الاختيار بين VPS يعمل بمعمارية ARM أو x86. سيستهلك ClickHouse أيضاً مقدار الذاكرة الذي يعتقد أنه متاح، لذلك اضبط حداً أقصى على الخادم المشترك كما هو موضح في تحديد حد لذاكرة الحاويات في Compose.

يجب أن يطابق BASE_URL عنوان URL العام تماماً. عند عدم تطابقهما، تسجّل الدخول، ثم يعيد التطبيق توجيهك إلى المضيف الخطأ، وتُكتب جلسة الدخول في ملف تعريف ارتباط خاص بنطاق لا يستخدمه متصفحك، فتعود إلى نموذج تسجيل الدخول من دون ظهور رسالة خطأ.

لا ينشر ملف Compose المرفق أي منفذ، لأن التصميم يفترض وجود proxy أمام التطبيق. أضف تجاوزاً ينشر منفذ التطبيق الافتراضي على loopback فقط.

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

Matomo: المنتج الكامل والخادم الذي يحتاج إليه

يعمل Matomo باستخدام PHP مع MySQL أو MariaDB، ولذلك فهو يناسب حزمة الويب التقليدية، لا حزمة الحاويات. وهو أيضاً الأداة الوحيدة هنا التي تنشر إرشادات للأجهزة وفق حجم حركة المرور.

[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

هذه هي الحد الأدنى المنشور لمتطلبات Matomo حتى August 2026، وليست قياسات أُجريت لهذا الدليل. حتى 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 تقاريره افتراضياً عندما يفتح أحدهم لوحة المعلومات، لذلك تصبح لوحة المعلومات أبطأ مع نمو البيانات، ثم ينتهي الأمر بفشل الطلب بسبب انتهاء المهلة. الإصلاح الموثق هو تعطيل الأرشفة التي يطلقها المتصفح في الإعدادات العامة، وتشغيل أداة الأرشفة عبر cron بدلاً من ذلك، باستخدام حساب المستخدم الذي يملك ملفات Matomo، ومن دليل Matomo.

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 مشروع حديث نسبياً، ويأتي بلوحة تحكم عصرية. يكتب سكربت الإعداد ملف البيئة، ثم يشغّل الحزمة باستخدام Docker Compose. يشغّل ClickHouse، ويضم Caddy كخادم ويب خاص به. يستمع Caddy على المنفذ 443، ويطلب شهادة للنطاق الذي أدخلته. إذا كان nginx يستخدم المنفذ 443 مسبقاً على الخادم، فلن يتمكن السكربت من ربط المنفذ. استخدم بدلاً من ذلك مسار Compose اليدوي للمشروع، وضعه خلف الـproxy الحالي لديك. تذكر الوثائق أن الحد الأدنى للذاكرة هو 2 GB، وأن الاختبار أُجري على Ubuntu 24 LTS. كما تتطلب أنظمة ARM الإصدار ARMv8.2-A أو أحدث بسبب ClickHouse.

النقطة المهمة مع أي مشروع حديث: تصل الميزات بسرعة، وكذلك التغييرات التي قد تكسر التوافق. ثبّت tag محدداً، واقرأ ملاحظات الإصدار قبل تنفيذ عملية السحب، وخذ نسخة احتياطية من قاعدة البيانات أولاً.

قياس الاحتفاظ ونمو القرص: قِسه على خادمك

يعتمد نمو القرص على ما تخزّنه الأداة لكل حدث. يجمع GoatCounter الزيارات في عدادات، لذلك ينمو ملفه وفق عدد الصفحات والأيام المختلفة بدرجة أكبر من اعتماده على الحجم الخام للزيارات. يخزّن Umami وMatomo صفوفاً لكل حدث، ويخزّن Matomo جداول التقارير المعالَجة بالإضافة إلى الجداول الخام. يخزّن ClickHouse الأحداث في أعمدة ويضغطها بكفاءة عالية، ولذلك يستطيع Plausible التعامل مع حجم من الزيارات قد يسبب ضغطاً على مخزن يعتمد على الصفوف.

لا ينشر هذا الدليل رقماً لعدد الميغابايتات لكل مليون مشاهدة صفحة، لأنه لم يقس هذا الرقم على حركة الزيارات الخاصة بك. خذ القياس بنفسك. عدّل أسماء الخدمة والمستخدم لتطابق ملف Compose الخاص بك.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

سجّل الرقم، وانتظر أسبوعاً، ثم سجّله مرة أخرى، واقسم الفرق على عدد مشاهدات الصفحات الذي يعرضه لوحة المعلومات لذلك الأسبوع. يمثّل هذا الرقم موقعك وإعدادات تصفية الروبوتات لديك، ولذلك فهو أكثر فائدة من أي متوسط منشور. بعد ذلك، عيّن حدّاً للاحتفاظ بالبيانات ما دام الرقم صغيراً. يؤدي امتلاء القرص إلى تعطيل كل خدمة على VPS، وليس خدمة التحليلات فقط، وهذا أقوى سبب لوضع وحدة تخزين قاعدة البيانات في مكان ستنبّهك إليه df -h. يستحق هذا الخطر اهتماماً أكبر على خادم يحتوي مسبقاً على شيء كبير الحجم، لأن خادم صور مستضاف ذاتياً سيستنفد القرص قبل أن تقترب أي قاعدة بيانات للتحليلات من ذلك الحد.

السلوك خلف وكيل عكسي على نطاق فرعي

ضع أداة التجميع على نطاق فرعي للموقع الذي تقيسه، مثل stats.example.com. يجعل ذلك طلب أداة التجميع طلباً من الطرف الأول، لذلك لا تتأثر بقواعد المتصفح التي تحظر طلبات الطرف الثالث.

اربط التطبيق بواجهة loopback عند نشر منفذ الحاوية. يكتب 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 ونقطة نهاية لإلغاء الاشتراك يمكنك تفعيلها من واجهة الإدارة.

تتوصل الجهات التنظيمية إلى استنتاجات مختلفة في بلدان مختلفة. فعلى سبيل المثال، تنشر CNIL في فرنسا شروطاً يمكن بموجبها إعفاء قياس الجمهور من الموافقة. هذا القسم ملخص واقعي وليس استشارة قانونية. إذا كان لديك موقع فعلي ومستخدمون فعليون، فاستشر محامياً في نطاق اختصاصك القضائي.

هناك نقطة يغفل عنها البعض: يُعد سجل الوصول بيانات شخصية أيضاً. لا يضيف GoAccess أي script إلى الصفحة، لكنه يعالج عناوين IP مع ذلك. لذلك لا تكون تحليلات السجلات خارج نطاق القواعد تلقائياً.

حاجبات الإعلانات، ولماذا ستنخفض أرقامك

تطابق قوائم التصفية اسم المضيف ونمط عنوان URL. يسهل اكتشاف منتج التحليلات المستضاف، لأن الجميع يحمّله من اسم مضيف معروف وموحّد. يؤدي نقل أداة الجمع إلى نطاق فرعي تملكه أنت إلى إزالة اسم المضيف ذلك من الطلب، كما يؤدي تقديم البرنامج النصي من مسار تختاره إلى إزالة اسم الملف المعروف. ويغيّر كلا الأمرين ما يجب أن تطابقه القائمة.

لا يحدد هذا المنشور معدل اكتشاف، لأنه لم يقس ذلك. تعتمد نسبة الزوار الذين يحظرون إعداداً معيناً على جمهورك، ويحظر جمهور المطورين نسبة أكبر بكثير من الجمهور العام. قِس الفجوة لديك بدلاً من ذلك. خلال الأسبوع نفسه، احسب طلبات صفحات HTML في سجل الوصول باستخدام GoAccess، ثم قارنها بعدد مشاهدات الصفحات الذي تسجله الأداة المعتمدة على البرنامج النصي. يمثّل الفرق الزيارات المحظورة والصفحات المقدّمة من ذاكرة التخزين المؤقت على موقعك.

توقع تغيّر الإجماليات في اليوم الذي تنتقل فيه من منتج مستضاف، وتوقع أن يكون جزء من هذا التغيّر غير مرتبط بالحظر. تختلف المنتجات في تعريف مشاهدة الصفحة، وفي تحديد ما إذا كان تغيير المسار داخل تطبيق صفحة واحدة يُحتسب مشاهدة واحدة، وفي تحديد وقت انتهاء الجلسة. قارن الاتجاهات عبر أسابيع عدة قبل أن تستنتج أن حركة المرور انخفضت.

أي أداة تناسب أي موقع

• موقع شخصي أو مدونة تستقبل نحو 50,000 مشاهدة صفحة شهرياً أو أقل: GoatCounter أو Medama على VPS بسعة 1 GB، مع نسخ احتياطية تكون على شكل نسخ للملفات.
• موقع لا يمكنك إضافة سكربت إليه، أو جمهور يستخدم أدوات حظر على نطاق واسع: GoAccess على السجل الحالي، وفق جدول زمني.
• موقع نشاط تجاري صغير يطّلع شخص آخر على لوحة المعلومات فيه: Umami مع حاوية Postgres الخاصة به.
• موقع تريد فيه تتبّع الأهداف ومسارات التحويل، على خادم بسعة 2 GB من الذاكرة أو أكثر: Plausible Community Edition، أو Rybbit إذا كنت تريد لوحة المعلومات الأحدث وتقبل استخدام مشروع أحدث.
• مواقع كثيرة، أو حسابات مستخدمين كثيرة، أو حاجة إلى إبقاء البيانات الخام وفق سياسة احتفاظ تحددها بنفسك: Matomo، مع تحديد الموارد استناداً إلى الإرشادات المنشورة أعلاه.

ابدأ بأصغر أداة تجيب عن سؤالك الفعلي. الانتقال من GoatCounter إلى Plausible لاحقاً يكلّفك نطاقاً فرعياً وبعض السجل التاريخي. أما الانتقال من Matomo إلى أي أداة أخرى فيتطلب عملية ترحيل لن تستمتع بها. إذا كنت لا تزال تقرر ما الذي يمكن وضعه على الخادم نفسه، فراجع الدليل الأوسع للاستضافة الذاتية لمعرفة ما يناسب تشغيله إلى جانبه. وإذا كان ما تريده فعلاً هو تتبّع الطلبات على مستوى التطبيق بدلاً من إحصاء الزوار، فإن خدمة قابلية المراقبة ذاتية الاستضافة هي الأداة المناسبة لهذه المهمة.

FAQ

هل يلغي الاستضافة الذاتية للتحليلات الحاجة إلى شريط ملفات تعريف الارتباط؟

لا، فالسؤالان منفصلان. تغطي قاعدة الموافقة في ePrivacy تخزين شيء على جهاز الزائر أو قراءته، لذلك فإن الأداة التي لا تنشئ ملف تعريف ارتباط ولا تكتب شيئاً في التخزين المحلي لا تخضع لهذا المتطلب تحديداً. أما GDPR فهي قاعدة مختلفة تغطي معالجة البيانات الشخصية، وعنوان IP يُعد بيانات شخصية، لذلك ما زلت تحتاج إلى أساس قانوني وحد للاحتفاظ بالبيانات حتى من دون استخدام ملفات تعريف الارتباط. تنقل الاستضافة الذاتية البيانات إلى خادمك وتجعلك الطرف المسؤول عنها. راجع إرشادات الجهة التنظيمية في بلدك واستشر محامياً بشأن حالتك.

ما مقدار RAM الذي تحتاج إليه تحليلات مستضافة ذاتياً على VPS؟

يحدد مخزن البيانات ذلك، لا لوحة المعلومات. يعمل GoatCounter وMedama كعملية واحدة فوق ملف واحد، وتذكر وثائق Medama أن المواقع الصغيرة تعمل على أجهزة بذاكرة 256 MB. يضيف Umami حاوية Postgres إلى جانب تطبيق Node. يعمل كل من Plausible Community Edition وRybbit باستخدام ClickHouse، ويذكر كلا المشروعين أن الحد الأدنى هو 2 GB. تبدأ إرشادات Matomo نفسها من 2 نوى CPU و2 GB من RAM لما يصل إلى 100,000 مشاهدة صفحة شهرياً.

لماذا تكون أرقامي المستضافة ذاتياً أقل من أرقام أداة التحليلات التي استبدلتها؟

هناك سببان، وكلاهما حقيقي. تحظر قوائم التصفية بعض طلبات الجمع، لذلك تفقد كل أداة تعتمد على script هذه الزيارات. كما تحسب المنتجات البيانات بطرق مختلفة، لأن تعريف مشاهدة الصفحة ووقت انتهاء الجلسة يختلفان بينها. قارن طلبات صفحات HTML خلال أسبوع واحد من access log لديك مع مشاهدات الصفحات المعتمدة على script خلال الأسبوع نفسه. يمثل الفرق الزيارات المحظورة والصفحات المخزنة مؤقتاً، وفق قياس موقعك أنت لا وفق معدل منشور لجهة أخرى.

هل يمكنني تشغيل Plausible أو Rybbit على VPS بمعمارية ARM؟

يعمل كلاهما باستخدام ClickHouse، ويتطلب ClickHouse دعم SSE 4.2 على x86 أو NEON على ARM. تذكر متطلبات Plausible ذلك تحديداً، وتذكر وثائق Rybbit أن أنظمة ARM تحتاج إلى ARMv8.2-A أو إصدار أحدث. تستوفي أنوية خوادم ARM الحالية هذا الشرط، بينما لا تستوفيه الأنوية الأقدم، ويظهر الفشل على شكل رفض ClickHouse بدء التشغيل بسبب خطأ في مجموعة التعليمات، لا على شكل خطأ في application log. على جهاز ARM صغير، تتجنب الأدوات التي تستخدم ملفاً واحداً هذه المسألة، لأن أياً منها لا يشغّل ClickHouse.

هل ينبغي أن أحلل سجلات الخادم بدلاً من استخدام script للتتبع؟

استخدم تحليل السجلات عندما لا يمكنك إضافة script، أو عندما يحظر جمهورك التتبع بكثرة، أو عندما تريد عدّاً يشمل برامج الزحف. يقرأ GoAccess سجلاً يكتبه خادمك بالفعل، لذلك لا يضيف أي حجم إلى الصفحة ولا يحتاج إلى قاعدة بيانات. لكنك تفقد كل ما يحدث داخل المتصفح، ولا ترصد أي صفحة تُخدَّم من CDN أو من cache المتصفح، لأن ذلك الطلب لم يصل إلى خادمك. تشغّل مواقع كثيرة الطريقتين معاً وتتعامل معهما على أنهما قياسان مختلفان.