Plausible vs Umami vs GA4: Privacy, Self-Hosting, Consent & Analytics

Plausible, Umami, and Google Analytics 4 (GA4) can all measure website activity, but they are designed around different priorities.

Plausible and Umami emphasize privacy-oriented analytics and can both be self-hosted, but their current feature sets are no longer identical to the older “simple page counter” category. GA4 remains a managed Google platform with a broader advertising, attribution, audience, ecommerce, and Google marketing ecosystem.

The decision becomes more complicated when self-hosting enters the picture. Running analytics on your own infrastructure also makes you responsible for operating systems, databases, application upgrades, backups, monitoring, storage growth, TLS, administrator access, and incident recovery.

If you are researching an Umami alternative, the real comparison is broader than feature count: Plausible offers a simpler publisher-oriented reporting model with a heavier self-hosted database stack, while GA4 offers much deeper advertising and marketing measurement but is not self-hosted.

A better question than “Which analytics platform is best?” is:

Which measurement model gives me the information I actually need at an operational and privacy cost I am prepared to maintain?

Last verified: September 24, 2026. Platform features, deployment requirements, privacy controls and consent behavior can change; verify current vendor documentation before implementation.

---

---

1. Plausible vs Umami vs GA4: Quick Comparison

---

2. What Self-Hosted Analytics Actually Means

Self-hosting means more than choosing where analytics records are stored.

You become responsible for:

• Operating-system security.
• Docker or runtime maintenance.
• Application updates.
• Database updates.
• Database backups.
• TLS certificates.
• Reverse-proxy configuration.
• Storage capacity.
• Monitoring.
• Administrator access.
• Incident recovery.

This operational cost should be included when comparing a self-hosted product with a managed service.

---

3. Plausible Community Edition Architecture

The current Plausible Community Edition repository documents a Docker-based deployment that uses PostgreSQL and ClickHouse.

Plausible Community Edition is not simply one application container and one small SQL database.

The current official deployment uses:

Browser
   ↓
Plausible Application
   ↓
 ┌─────────────────┐
 ↓                 ↓
PostgreSQL      ClickHouse
Users / config  Analytics events

PostgreSQL stores application/user data while ClickHouse stores analytics event data.

This makes Plausible CE a more substantial infrastructure deployment than many lightweight single-database applications.

---

4. Plausible CE v3.2.1 Server Requirements Matter

The current Community Edition repository recommends at least 2 GB RAM for running Plausible and ClickHouse without risking out-of-memory failures.

The same repository states that the CPU must support SSE 4.2, NEON, or a higher compatible instruction set because ClickHouse depends on it.

Therefore, do not assume that the smallest possible VPS will run Plausible CE reliably simply because the frontend tracking script is lightweight.

---

5. Plausible CE Installation Should Follow the Versioned Repository

The official Community Edition project provides a versioned Docker Compose deployment.

A typical installation pattern is:

git clone -b v3.2.1 --single-branch \
  https://github.com/plausible/community-edition plausible-ce

cd plausible-ce

Version note: v3.2.1 is the verified tag used for this September 24, 2026 update. Recheck the official repository before a future production installation rather than assuming this tag remains current.

Then configure required environment settings such as BASE_URL and SECRET_KEY_BASE according to the current release documentation. The current repository requires the secret to be at least 64 bytes.

Do not copy an old Plausible Compose file from a tutorial written for an earlier major release.

---

6. Preserve Plausible's Application Secret

Plausible CE requires a strong application secret.

Treat it as sensitive configuration:

• Generate it securely.
• Do not publish it.
• Do not commit it to a public repository.
• Include it in your protected recovery documentation where required.

---

7. Back Up Both Plausible Databases

Because Plausible CE uses PostgreSQL and ClickHouse, a recovery strategy needs to account for both data stores.

A complete recovery plan should consider:

• PostgreSQL data.
• ClickHouse analytics data.
• Plausible configuration.
• Application secrets.
• Compose configuration.
• Reverse-proxy or TLS configuration where applicable.

Do not treat a backup of only PostgreSQL as a complete Plausible analytics backup.

---

8. Plausible Cloud and Plausible CE Are Operationally Different

Do not automatically copy managed Plausible Cloud infrastructure claims to your own Community Edition deployment.

When self-hosting, you determine:

• Server region.
• Hosting provider.
• Backup location.
• Administrator access.
• Data residency.
• Database security.

A managed service's hosting location or operational controls do not automatically describe a self-hosted instance.

---

9. Umami v3.4 Has a Simpler Core Database Architecture, but a Broader Feature Set

Umami's current installation documentation supports PostgreSQL and provides an official Docker Compose path that starts both the Umami application and PostgreSQL.

The current Umami self-hosting model uses PostgreSQL. For a source installation, current documentation requires Node.js 18.18 or newer and PostgreSQL 12.14 or newer, and recommends keeping the database in UTC.

A typical architecture is:

Browser
   ↓
HTTPS / Reverse Proxy
   ↓
Umami
   ↓
PostgreSQL

The official Docker Compose deployment contains both the Umami application and PostgreSQL. The current published release is v3.4.0; production operators should read release/migration notes and avoid assuming a tutorial written for Umami 2.x or early 3.x still matches current behavior.

---

10. Change Umami's Initial Administrator Password

The current official Docker installation documentation provides an initial administrator account for first login.

Change the default password immediately before treating the installation as production infrastructure.

Also protect:

• PostgreSQL credentials.
• Application environment variables.
• Administrator accounts.
• Backups.

Current Umami 3.x releases have also expanded the administration/security surface. Version 3.3 added two-factor authentication, while 3.4 added account API-key management and further API/integration capabilities. If you enable these features, protect recovery material and API keys just as carefully as database/application secrets.

---

11. Keep Analytics Databases Private

Neither PostgreSQL nor ClickHouse needs to be globally reachable simply because a web analytics application uses them.

Prefer:

Internet
   ↓
HTTPS Analytics Endpoint
   ↓
Application
   ↓
Private Database Network

Expose database services remotely only when the architecture genuinely requires it and access is appropriately restricted.

---

12. Put Self-Hosted Analytics Behind HTTPS

Use HTTPS for public tracking endpoints and administrative sessions.

A normal self-hosted architecture can be:

analytics.example.com
        ↓
      HTTPS
        ↓
Reverse Proxy / Application TLS
        ↓
Analytics Application
        ↓
Private Database(s)

Plausible CE can also handle HTTPS within its documented deployment when configured accordingly, while other architectures may terminate TLS at a reverse proxy.

---

13. Do Not Blindly Copy One Reverse Proxy to Every Analytics Platform

Plausible, Umami, GA4, and other platforms have different routes, application ports, header requirements, caching behavior, and deployment models.

Use each application's current reverse-proxy documentation instead of assuming one generic Nginx block is universal.

---

14. What Umami Tracks by Default

Current Umami documentation describes default pageview data including information such as:

• Hostname.
• Browser language.
• Referrer.
• Screen dimensions.
• Page title.
• URL.
• Website identifier.

Umami also supports custom events and session-related data. Current 3.x documentation additionally includes funnels, journeys, retention, revenue, heatmaps, session replays and optional real-user Core Web Vitals collection.

---

15. Umami Is Cookie-Free by Default, but Configuration Still Matters

Umami's normal anonymous tracking model does not depend on browser tracking cookies.

Its current session documentation describes anonymous sessions using a generated hash based on factors including the visitor's IP address, user agent, and website identifier.

This is different from setting a persistent browser cookie.

---

16. Do Not Say “Umami Can Never Collect Personal Data”

Current Umami tracker functions support distinct IDs and custom session data through umami.identify(), so privacy behavior depends partly on implementation.

Current Umami versions include APIs that allow developers to identify a session or attach custom session data.

For example, an implementation can deliberately call functionality conceptually like:

umami.identify(user_id, {
  plan: "pro"
});

The platform documentation even supports custom data associated with identified sessions.

Therefore, privacy characteristics depend partly on how you configure and use the tracker.

---

17. Umami Can Collect Real-User Core Web Vitals

Since Umami 3.1, the tracker can optionally collect Core Web Vitals from visitors' browsers by enabling its performance-tracking configuration.

<script
  defer
  src="https://analytics.example.com/script.js"
  data-website-id="YOUR-WEBSITE-ID"
  data-performance="true">
</script>

That makes Umami useful for combining traffic analytics with field-performance observation, but it does not replace PageSpeed Insights, CrUX or a dedicated RUM/performance workflow when you need deeper diagnosis. Enabling more telemetry also means documenting what you collect and why.

---

18. Custom Analytics Events Need Data Governance

Regardless of platform, avoid sending sensitive information in analytics events.

Do not send:

• Passwords.
• Authentication tokens.
• Payment-card details.
• Private support messages.
• Full form submissions.
• Unnecessary email addresses.
• Other personal data without a legitimate measurement requirement.

---

19. GA4 Uses a Different Measurement Model

GA4 is an event-based managed analytics platform.

It can support measurement including:

• Page views.
• Sessions.
• Events.
• Key events.
• Ecommerce.
• Audiences.
• Campaign analysis.
• Google Ads integrations.

This broader model can be useful when marketing and advertising analysis is central to the site.

---

20. GA4 Default Data Collection Is Broader Than a Simple Page Counter

Google's current documentation states that a default Google Analytics implementation can collect data including:

• User counts.
• Session statistics.
• Approximate geolocation.
• Browser information.
• Device information.

Enhanced Measurement can collect additional supported events when enabled.

---

21. GA4 Uses a First-Party Client Identifier When Analytics Storage Is Allowed

Google's current data collection documentation states that Google Analytics stores a client ID in the first-party _ga cookie and does not store that client ID when analytics storage is disabled through Consent Mode.

Google Analytics can use a first-party _ga cookie containing a client identifier to distinguish users and sessions.

Current Google documentation notes that the client identifier is not stored when analytics storage is disabled through Consent Mode.

---

22. Google Consent Mode Does Not Create a Consent Banner

Google's current Consent Mode documentation explicitly states that Consent Mode works with an existing consent mechanism; it does not provide the banner itself.

This distinction is important.

Consent Mode is not itself a cookie banner or consent-management platform.

It receives consent choices from your banner or consent solution and modifies Google tag behavior accordingly.

---

23. Basic vs Advanced Google Consent Mode

This technical behavior is important when comparing analytics privacy architectures.

---

24. GA4 Data Retention Settings Need to Be Understood Separately From Standard Reports

GA4's data-retention setting controls how long user-level and event-level data is kept for features such as explorations and funnel reporting; it does not remove aggregated standard reporting in the same way.

For standard GA4 properties, Google's current documentation provides 2-month or 14-month retention options for user-level data, with the same retention applying to key-event data. Some longer retention options are limited to Analytics 360.

This is a different retention model from self-hosting, where database growth, deletion policy and backup retention become your operational responsibility. Do not compare “data ownership” without comparing retention and deletion behavior too.

---

25. Google Updated Analytics / Ads Consent Controls in 2026

Google's current data-controls update states that from June 15, 2026, Consent Mode became the single control for Google Ads cookies and identifiers originating from the Google Analytics tag and SDK in Ads-related use cases.

The Google Signals setting now has a narrower role for associating Analytics-sourced data with signed-in user information for behavioral reporting. This is one reason older GA4 consent tutorials should be reviewed before reuse.

Google also provides data-transmission controls that can block analytics data collection when analytics_storage is denied. These controls are separate from Consent Mode itself and should be validated in the exact Google tag/server-side-tagging architecture you use.

---

26. Analytics Software Does Not Provide Automatic Legal Compliance

Do not publish universal claims such as:

“Install this tool and your site is automatically GDPR compliant.”

Legal obligations can depend on:

• Jurisdiction.
• Purpose of processing.
• Data collected.
• Retention.
• Identifiers.
• Advertising technologies.
• Other trackers.
• User consent.
• Contractual/data-processing relationships.

Vendor privacy documentation is useful evidence, but it is not a substitute for evaluating the whole website's implementation. The answer can change when you add advertising pixels, custom identifiers, session replay, user-linked event properties, third-party embeds or other processing outside the analytics product's default configuration.

---

27. “No Cookies” and “No Consent Required” Are Not Identical Claims

A tracker that does not store cookies may simplify some privacy and consent questions, but cookie usage is not the only possible privacy consideration.

A site can still process:

• IP-derived information.
• Custom event data.
• User identifiers.
• URLs containing sensitive query parameters.
• Form-derived data.

Evaluate the complete implementation rather than the existence of one cookie.

---

28. Self-Hosting Does Not Automatically Mean “First-Party Data” in Every Legal or Marketing Sense

The phrase first-party can describe several different concepts:

• Data collected directly through your own website.
• A script served from your own hostname.
• Infrastructure operated by your organization.
• Marketing data obtained directly from customers.

Use precise wording instead of treating “self-hosted” and “first-party” as exact synonyms.

---

29. Analytics Scripts Can Affect Performance

No analytics script has literally zero cost.

A tracker can add:

• Transferred bytes.
• DNS/TLS/network work.
• JavaScript parsing.
• JavaScript execution.
• Event listeners.
• Collection requests.

The relevant question is whether that cost is material on your actual page. Measure the complete implementation—including tag manager, consent platform, advertising integrations, session replay and proxies—not only the core analytics script.

---

30. Do Not Use Vendor Script Size as the Entire Performance Benchmark

A small JavaScript file can still perform meaningful runtime work.

A larger file can be cached and execute relatively little code on a specific page.

Measure:

• Transferred bytes.
• JavaScript execution time.
• Main-thread activity.
• Request count.
• Long tasks.
• Core Web Vitals impact.

---

31. Load Analytics According to the Vendor's Supported Integration

Many analytics trackers are loaded asynchronously or with deferred execution.

A generic example is:

<script
  defer
  src="https://analytics.example.com/script.js">
</script>

However, use the exact current code supplied by the analytics platform rather than rewriting its integration unnecessarily.

---

32. Umami's Tracker Supports Configuration

Current Umami tracker configuration includes controls for behavior such as:

• Automatic pageviews.
• Automatic tracking.
• Host URL.
• Allowed domains.

This is useful for staging environments and custom tracking architectures. Umami also supports excluding URL search parameters from collected page URLs; that can reduce accidental collection of sensitive or noisy query-string values.

---

33. Avoid Collecting Staging Traffic

Development and staging traffic can pollute production analytics.

Depending on the platform, use:

• Domain restrictions.
• Separate site/property IDs.
• Environment conditions.
• Internal traffic filters.

---

34. Do Not Stack Trackers Without a Measurement Reason

Running all of these together:

• GA4.
• Plausible.
• Umami.
• Advertising pixels.
• Heatmaps.
• Session replay.
• Multiple tag managers.

can increase frontend work, reporting complexity, privacy obligations, and debugging difficulty.

Every tracker should answer a defined business or editorial question.

---

35. Different Platforms Will Report Different Numbers

Do not expect GA4, Plausible, and Umami to produce identical visitor totals.

Differences can result from:

• Visitor definitions.
• Session definitions.
• Cookies and identifiers.
• Consent behavior.
• Ad blockers.
• Bot filtering.
• Timezone.
• Event processing.
• SPA navigation handling.

Numerical disagreement does not automatically prove one platform is broken.

---

36. Do Not Call One Platform “Most Accurate” Without a Test Definition

A meaningful analytics comparison would need to define:

• Ground-truth traffic.
• Browser mix.
• Consent status.
• Ad-blocker conditions.
• Bot traffic.
• Session methodology.
• Test duration.
• Event definitions.

Without that methodology, use wording such as “reports differently,” not “more accurate.”

---

37. Pageviews, Visitors and Sessions Are Different Metrics

A pageview measures a viewed page or route.

A session groups activity according to a platform-specific session model.

A visitor/user metric attempts to distinguish entities according to the analytics platform's identification methodology.

Do not use these terms interchangeably.

---

38. Track Business Events, Not Every Possible Click

Useful events can include:

• Affiliate CTA click.
• Newsletter signup.
• Contact-form completion.
• File download.
• Checkout completion.
• Search use.
• Lead submission.

Collect events because they answer a decision question—not because the analytics platform makes unlimited event creation easy.

---

39. Analytics for Digital Bhatti Should Focus on Useful Decisions

For a technical publication such as Digital Bhatti, useful editorial measurements can include:

• Article landing pages.
• Organic-search entry pages.
• Navigation into pillar pages.
• Clicks from informational guides into commercial comparisons.
• Affiliate CTA clicks.
• Returning visitors.
• Important geographic traffic segments.

Do not collect sensitive visitor information merely because deeper segmentation is technically possible.

---

40. Plausible Can Be a Strong Fit for Simpler Publisher Analytics

Plausible is worth considering when your main questions are:

• Which pages receive traffic?
• Where does traffic originate?
• Which campaigns work?
• Which simple events convert?

The trade-off for Community Edition is the additional PostgreSQL + ClickHouse operational stack.

---

41. Umami v3.4 Can Be a Strong Fit for Flexible Open-Source Analytics

Umami is worth considering when you want:

• Open-source self-hosting.
• PostgreSQL.
• Custom events.
• Session reporting.
• Funnels, journeys, retention and broader behavior analysis.
• Optional session replay, heatmaps and Core Web Vitals measurement where appropriate.
• API-driven integrations and account API keys.

Remember that newer identification/session functionality means privacy behavior depends on how you use those features.

---

42. GA4 Is Strongest When the Google Marketing Ecosystem Matters

GA4 remains particularly useful when the site depends on:

• Google Ads.
• Conversion measurement.
• Advertising audiences.
• Ecommerce events.
• Attribution workflows.
• Google marketing integrations.

If those functions are unnecessary, a simpler analytics system may reduce reporting and implementation complexity.

---

43. You Can Use Two Analytics Systems, but Define Why

A hybrid strategy might be:

Plausible / Umami
        ↓
Editorial traffic + simple events

GA4
        ↓
Google Ads / ecommerce / advanced marketing analysis

Only keep both if each has a distinct decision-making purpose.

---

44. Self-Hosted Analytics Needs a Backup Strategy

A self-hosted analytics server can become an important historical dataset.

Your backup design should include:

• Application database(s).
• Application secrets.
• Environment configuration.
• Compose/deployment configuration.
• Reverse-proxy configuration.
• Restore documentation.

---

45. Keep Backups Outside the Analytics Host

A single-server architecture should not place production and the only recovery copy on the same disk.

A better pattern is:

Analytics VPS
      ↓
Local / provider recovery copy

Analytics VPS
      ↓
Independent protected backup

---

46. Test Analytics Restoration

Do not assume database files or dumps are useful until a restore has been tested.

Verify that recovery restores:

• User accounts.
• Sites/properties.
• Historical analytics.
• Events.
• Configuration.

---

47. Monitor Self-Hosted Analytics Externally

A self-hosted analytics instance should be treated like production infrastructure.

Monitor:

• HTTPS availability.
• TLS certificate expiration.
• Application health.
• Database health.
• Disk space.
• Memory.
• Container restarts.

Use the Uptime Kuma Monitoring Guide for this layer.

---

48. Analytics Collection Can Fail While the Dashboard Still Loads

A healthy administrator dashboard does not prove that visitor events are arriving.

After upgrades or proxy changes, verify:

• Tracker JavaScript loads.
• Collection requests reach the server.
• Responses are successful.
• New pageviews appear.
• Custom events arrive.

---

49. Test Tracking With Browser Developer Tools

Use the browser's Network panel to check:

• Tracker script request.
• Collection request.
• HTTP status.
• Blocked requests.
• Unexpected redirects.
• Content Security Policy failures.

This is more reliable than assuming analytics works because the script tag exists in page source.

---

50. Ad Blockers Can Change Analytics Totals

Browser extensions and privacy tools may block known analytics scripts or collection endpoints.

This is another reason analytics numbers should not be treated as a perfect census of every human visitor.

A tracker missed by fewer blockers is not automatically “more accurate” unless you define the measurement objective and ground truth.

---

51. Be Careful With Analytics Proxying

Some implementations proxy analytics scripts or events through a site's own domain.

This adds:

• Reverse-proxy configuration.
• Caching considerations.
• Upgrade dependencies.
• Debugging complexity.

Do not add a proxy merely to disguise analytics traffic from visitor tools or consent mechanisms.

Use proxying only when there is a legitimate architecture or reliability reason and follow the vendor's supported configuration.

---

52. Do Not Cache Collection Requests Blindly

Analytics collection endpoints represent distinct measurement events.

A generic CDN rule that caches those requests can prevent events from being processed correctly.

Distinguish:

• Static JavaScript assets.
• Dashboard assets.
• API routes.
• Analytics ingestion endpoints.

---

53. Protect the Analytics Dashboard

The dashboard may reveal commercially useful information even when visitor tracking is privacy-oriented.

Protect:

• Administrator accounts.
• Passwords.
• MFA/TOTP where the platform supports it.
• Application versions.
• Database access.
• Backup credentials.

Remove old staff or contractor access when it is no longer required.

---

54. Self-Hosted Analytics Should Be Patched

Running an open-source analytics product does not eliminate application-security maintenance.

Keep current:

• Analytics application.
• PostgreSQL.
• ClickHouse where applicable.
• Docker.
• Operating system.
• Reverse proxy.

---

55. Review Release Notes Before Major Updates

Do not blindly run an automatic major-version update against production analytics. Where the project supports version tags, pin a known application/image version instead of treating latest as a permanent production strategy.

A safer process is:

Review Release
      ↓
Read Migration Notes
      ↓
Back Up Databases
      ↓
Back Up Configuration
      ↓
Upgrade
      ↓
Review Logs
      ↓
Test Dashboard
      ↓
Test Collection
      ↓
Monitor

---

56. WordPress Analytics Installation

For WordPress, use one controlled integration method.

Options can include:

• The vendor's supported WordPress integration.
• A carefully implemented theme hook.
• A tag-management system where justified.

Avoid inserting the same tracker through both a plugin and theme template because duplicate tracking can inflate metrics.

---

57. Blogger Analytics Installation

On Blogger, a lightweight tracker can normally be inserted through the theme HTML in an appropriate location according to the analytics provider's instructions.

Before editing the Blogger theme:

• Back up the theme.
• Add the tracker once.
• Verify it on post and page templates.
• Confirm it is not duplicated on mobile/conditional markup.
• Test collection in browser developer tools.

---

58. Analytics and Core Web Vitals Are Related but Separate

A large marketing stack can increase browser work, but poor Core Web Vitals may also come from:

• Slow TTFB.
• Large hero images.
• Render-blocking CSS.
• Heavy page builders.
• Third-party ads.
• Large JavaScript bundles.

Use the Core Web Vitals Guide to diagnose the actual bottleneck.

---

59. Analytics Platform Decision Matrix

---

60. Recommended Analytics Deployment Workflow

1. Define the business questions you need analytics to answer.
2. Decide whether advanced advertising/ecommerce measurement is necessary.
3. Choose Plausible, Umami, GA4, or another platform based on that need.
4. If self-hosting, verify the current application version, server/database requirements and upgrade path.
5. Harden the host.
6. Keep databases private.
7. Configure HTTPS.
8. Protect administrator accounts and secrets.
9. Create tested database backups.
10. Install one tracker implementation.
11. Verify pageviews and events using browser developer tools.
12. Document privacy and consent behavior.
13. Measure frontend performance.
14. Monitor the analytics service externally.
15. Define retention/deletion requirements and review database growth.
16. Pin/document production versions and review release notes before upgrades.

---

61. Common Analytics Architecture Mistakes

• Assuming self-hosting automatically creates compliance: implementation and jurisdiction still matter.
• Calling every Umami configuration anonymous: custom identification and session data can change the privacy model.
• Describing Plausible CE as a single lightweight database: current CE uses PostgreSQL and ClickHouse.
• Using a tiny VPS without checking ClickHouse requirements: frontend script size does not determine backend requirements.
• Exposing PostgreSQL or ClickHouse publicly: keep databases private where possible.
• Leaving Umami's initial password unchanged: change it immediately.
• Putting secrets in public Git repositories: keep production environment files private.
• Using GA4 without understanding Consent Mode: current basic and advanced implementations behave differently.
• Assuming Consent Mode itself is a banner: it works with a separate consent mechanism.
• Comparing raw visitor numbers as accuracy: measurement methodologies differ.
• Running several trackers without a defined need: complexity and browser overhead increase.
• Sending PII in custom events: collect only what is necessary.
• Caching analytics ingestion endpoints: can interfere with collection.
• Never backing up self-hosted analytics: you own the recovery layer.
• Testing only the dashboard after upgrades: also verify live event collection.
• Claiming zero Core Web Vitals impact: measure the actual implementation.
• Assuming Umami is still only basic pageview analytics: current 3.x releases include a substantially broader analysis and performance feature set.
• Copying an old Plausible tracking snippet: Plausible changed its tracker/snippet model in late 2025.
• Ignoring retention settings: GA4 and self-hosted databases have different retention/deletion models.
• Running moving latest tags without an upgrade plan: pin/document production versions where practical.

---

62. Related Digital Bhatti Guides

• Automation pillar: Web Automation Guide.
• Workflow automation: Self-Hosted n8n with Docker.
• Monitoring: Uptime Kuma Monitoring.
• Security: Essential Website Security Checklist.
• Infrastructure: Shared vs VPS vs Cloud Hosting.
• Frontend performance: Core Web Vitals Optimization.

---

Analytics Platform Checklist

• Define measurement goals before selecting a tool.
• Do not equate more analytics features with better analytics.
• Understand the operational cost of self-hosting.
• Remember that Plausible CE v3.2.1 currently uses PostgreSQL and ClickHouse.
• Check Plausible CE memory and CPU requirements before deployment.
• Back up both Plausible data stores.
• Use current versioned upstream deployment files.
• Remember that current Umami v3.4.0 self-hosting uses PostgreSQL and source installs require the documented Node/PostgreSQL minimums.
• Change Umami's initial administrator password.
• Keep analytics databases private.
• Use HTTPS.
• Protect environment variables and application secrets.
• Describe privacy based on actual tracker configuration.
• Do not claim self-hosting automatically provides legal compliance.
• Do not send sensitive personal data in analytics events.
• Understand GA4's first-party identifier behavior.
• Understand basic vs advanced Consent Mode and current GA4 data-transmission controls.
• Review GA4 data-retention settings separately from standard aggregated reporting.
• Use one primary analytics system per KPI.
• Avoid duplicate tracker installation.
• Exclude staging/development traffic where practical.
• Measure script impact instead of relying on marketing claims.
• Back up self-hosted analytics off-server.
• Test restoration.
• Monitor the analytics platform externally.
• Verify live event collection after upgrades.

Frequently Asked Questions

Is Plausible easier to self-host than Umami?

Not necessarily. Current Plausible Community Edition uses PostgreSQL and ClickHouse, while Umami's standard self-hosting architecture uses PostgreSQL. Operational complexity should be compared using the actual current deployment stack rather than the simplicity of each frontend dashboard.

How much RAM does Plausible Community Edition need?

The current Plausible Community Edition repository recommends at least around 2 GB of RAM for running Plausible and ClickHouse. Actual requirements depend on traffic, retention and workload.

Does Plausible Community Edition use PostgreSQL?

Yes, but not only PostgreSQL. Current Plausible CE uses PostgreSQL for application/user data and ClickHouse for analytics event data.

Does Umami use PostgreSQL?

Yes. Current Umami self-hosting documentation uses PostgreSQL, including its official Docker Compose installation.

Does Umami use cookies?

Umami's normal analytics tracker is designed to operate without browser tracking cookies. Its current anonymous session model uses a generated hash rather than a persistent tracking cookie.

Is all Umami tracking automatically anonymous?

Not every possible custom implementation. Umami also supports identifying sessions and attaching custom session data. Privacy therefore depends partly on which features you use and what information your implementation sends.

Does self-hosting analytics guarantee GDPR compliance?

No. Product choice alone does not determine legal compliance. The actual data, purpose, jurisdiction, retention, identifiers, consent model and other technologies on the website also matter.

Does Plausible require a cookie banner?

Plausible's current vendor documentation describes its standard analytics model as cookie-free and without persistent user identifiers. Whether your complete website requires consent or disclosures depends on the rest of your implementation and applicable requirements.

Does Google Analytics 4 use cookies?

GA4 can store a client identifier in a first-party _ga cookie when the relevant analytics storage is allowed. Consent Mode can change tag and storage behavior according to configured consent states.

What is the difference between basic and advanced Google Consent Mode?

In basic Consent Mode, Google tags are blocked until the applicable user interaction and consent. In advanced Consent Mode, tags can load with denied defaults and send limited cookieless signals according to Google's documented behavior.

Does Consent Mode create a cookie banner?

No. Consent Mode receives consent choices from a separate banner or consent-management mechanism and changes supported Google tag behavior accordingly.

Which is better for Digital Bhatti: Plausible, Umami or GA4?

For simple editorial and content reporting, Plausible or Umami can provide a cleaner analytics experience. GA4 remains valuable when Google Ads, advanced event attribution, audiences or advertising measurement are important. The best choice depends on which metrics Digital Bhatti will actually use for editorial and monetization decisions.

Can I use GA4 and Umami or Plausible together?

Yes. A hybrid setup can make sense when one platform handles editorial traffic reporting and GA4 handles advertising or ecommerce measurement. Keep both only when each has a defined purpose.

Will switching from GA4 to Plausible or Umami improve Core Web Vitals?

Not automatically. A lighter analytics implementation can reduce some browser work, but LCP, INP and CLS depend on the entire page. Measure the site before and after making changes.

Should I proxy my analytics script through my own domain?

Only when there is a legitimate supported architectural reason. Proxying adds configuration, caching and maintenance complexity and should not be used simply to evade visitor privacy tools or consent controls.

Should self-hosted analytics be backed up?

Yes. Back up the required databases, application configuration, secrets and deployment information, keep an independent recovery copy, and test restoration.

What is the current Plausible Community Edition version used in this guide?

This update was verified against the official Community Edition repository at v3.2.1. Recheck the repository before installing because deployment tags and requirements can change.

What is the current Umami version used in this guide?

This update was verified against Umami v3.4.0. Current 3.x releases include a broader feature set than older comparisons may describe, including sessions, advanced analysis features and optional performance measurement.

Can Umami collect Core Web Vitals?

Yes. Current Umami documentation supports optional real-user performance collection through the tracker's data-performance configuration. Treat it as one RUM signal source rather than a complete replacement for dedicated performance diagnosis.

How long does GA4 retain user-level data?

For standard GA4 properties, Google's current data-retention controls offer 2-month or 14-month options for user-level data, with the same retention applying to key-event data. Standard aggregated reports are affected differently from exploration-level/user-level data.