invisit vs Umami

How much does Umami Cloud cost compared with invisit?

On raw price, Umami Cloud is usually the cheaper of the two, as long as its Pro plan has what you need. As of November 2026, Umami’s pricing lists a free Hobby plan up to 100K events, Pro at $20 a month for 1M events and Business at $200 a month for 10M. invisit is free to 20K events, then $14 for 100K, $49 for 1M and $199 for 10M.

Two details narrow the gap. Umami counts every stored event property as one more event, and session data saved with umami.identify() counts too, so umami.track('signup', { plan: 'pro', source: 'ad' }) uses three events. invisit bills that call as one event. And heatmaps, unlimited websites and unlimited team members are on Umami Business, which costs $200 at any volume up to 10M.

So a SaaS with 300K page views a month pays $20 on Umami Pro or $49 on invisit, and $200 on Umami if it wants heatmaps. Event-heavy tracking flips the order, as the last row shows. Above 7M events a month, Umami Business costs less than Pro.

Overages work differently. Umami bills extra events automatically ($0.00003 each on Pro, $0.00002 on Business) and keeps collecting, unless you set a spending budget that stops recording when the estimate passes it. invisit warns at 80% of your plan, records all of a first month over, and pauses new events at the limit only in a second month over in a row.

Which Umami features need the Pro or Business plan?

Umami gates features by plan, while every invisit paid plan has every feature. Umami’s reports (funnels, goals, journeys, retention, UTM, attribution, and revenue sent from code) are on all of its plans; teams, integrations and the heavier features are not.

Retention matters most over time. Umami Hobby keeps six months of data and Pro two years (Umami’s retention FAQ); invisit keeps data forever on every plan, free included.

Revenue imports look alike on paper. Umami Pro and Business import payments and refunds hourly from Stripe, Paddle, Lemon Squeezy, Dodo Payments, Polar or WooCommerce, from the day you connect (Umami’s payment providers). invisit reads payments, refunds, disputes, fees and net from Stripe, Paddle, Polar, Lemon Squeezy, Creem or Dodo Payments, with totals and charts on every plan, and reads the last 90 days of payments when you connect.

Can you self-host Umami instead of paying for Cloud?

Yes. Umami is open source under the MIT license, and the self-hosted edition has the same analytics as Umami Cloud, session replays and heatmaps included. invisit is hosted only: its tracker and SDKs are MIT, but its dashboard and backend are not available to run yourself.

Umami’s installation guide asks for a Node.js server (20.19 or newer) and a PostgreSQL database (12.14 or newer), from source or Docker Compose. Umami v3 dropped MySQL, so an older MySQL install moves to PostgreSQL first. Self-hosted data is kept until you delete it.

What you take on is the server: updates, backups, scaling and the database. Scheduled email reports and the streaming API stay Cloud only, per Umami’s pricing FAQ, and the payment-provider and Search Console integrations are documented for Cloud. The MCP server is off on a self-hosted instance until you set MCP_ENABLED=1.

Does Umami need a cookie banner, and how does it tell visitors apart?

Neither Umami nor invisit sets cookies, and both are built to run without a cookie banner for their own tracking. The difference is how long a visitor stays recognisable. Umami hashes the website ID, IP address, user agent and a salt that rotates monthly by default (Umami’s visitor identification), so a returning visitor is linked for up to a month. invisit’s hash rotates every day, so nobody is followed from one day to the next.

Browser signals differ too. invisit can honour both Global Privacy Control and Do Not Track, with data-respect-gpc and data-respect-dnt, and has an optional consent mode (privacy guide). Umami honours Do Not Track only when you add data-do-not-track="true" to its script, and its tracker has no Global Privacy Control check.

For signed-in users, Umami stores the Distinct ID you pass to umami.identify() as you send it, up to 50 characters, and its docs leave what goes into that ID and into session data to you. invisit hashes the user id you pass to identify() and redacts email addresses in property values.

Umami Cloud stores analytics in a US or an EU region chosen at signup, which you cannot switch in settings later. invisit stores everything in Falkenstein, Germany, with Cloudflare in front for DNS and CDN, and a DPA is available.

Does Umami show ChatGPT and other AI assistant traffic?

Umami does, more narrowly than invisit. As of November 2026, Umami’s Channels report has an LLM channel for visits referred by chatgpt.com, claude.ai, copilot.microsoft.com, gemini.google.com, meta.ai and perplexity.ai (Umami’s source). It matches the referrer domain only, so a visit that arrives with utm_source=chatgpt.com and no referrer lands outside it.

invisit recognises 19 assistants (ChatGPT, Claude, Perplexity, Gemini, Copilot, DeepSeek, Grok, Le Chat, Meta AI, Qwen, Kimi, NotebookLM, Google AI Studio, Doubao, You.com, Phind, Poe, Character.AI and Duck.ai) by referrer and by utm_source, in their own AI tab (how it works).

Crawlers are the other half. Umami drops requests from bot user agents before storing them, so there is no record of search or AI crawlers reading your pages. invisit records crawler reads server-side with @invisitdev/server, including user-triggered fetches like ChatGPT-User, and never bills them.

Where Umami is the better choice

Umami is the better pick in these situations, and some are things invisit does not do at all.

• You need to self-host. invisit has no self-hosted edition.
• Your usage is light and Pro’s limits are enough. Hobby is free to 100K events, five times invisit’s free allowance, and Pro covers 1M events for $20 when 20 sites and 10 team members are plenty.
• You want product analytics around your traffic: retention reports, cohorts and segments, journeys, first-click and last-click attribution, and on Business, session replays. invisit has no session recordings or retention cohorts.
• You want error tracking. Umami Cloud added it in October 2026, grouping JavaScript errors into issues next to sessions and replays (Umami’s error tracking).
• You want scheduled email reports, Google Search Console data in the dashboard, or your history imported by Umami’s team. All three are on Umami Pro; invisit has none of them.
• You count every byte. Umami’s script is about 4 KB gzipped; invisit’s core is about 8.5 KB.
• You sell through WooCommerce, which Umami imports revenue from and invisit does not list.

Switching from Umami to invisit

Run both side by side before you remove anything. Both trackers are cookieless and can sit on the same pages.

1. Install invisit next to the Umami script and leave Umami running for two to four weeks, so you can compare the numbers.
2. Replace each umami.track() call with track() and each umami.identify() with identify(), as below. Attributes you kept as Umami session data, like a plan, can go on the events where you need them.
3. Rename events and trim properties. Umami accepts names up to 50 characters with spaces and up to 50 properties; invisit event names use letters, digits and _ . : -, with up to 32 properties. A data-umami-event="Signup button" attribute becomes data-invisit-event="signup_button".
4. Drop the revenue and currency properties and connect your payment provider instead.
5. If you proxied Umami’s script past ad blockers, the @invisitdev/server proxy does the same for invisit.
6. Export your Umami history before you cancel, because invisit cannot import it. In Umami Cloud, open Settings, choose Data and click Export: Umami emails a link to gzipped CSV of a website’s page views, events, sessions and event data, on every plan (Umami’s export guide). Hobby keeps only six months, so export early. Self-hosted, your history is already in your PostgreSQL database.

// Umami: the script tag defines window.umami
umami.track('signup', { plan: 'pro' })
umami.identify(user.id)

// invisit
import { identify, init, track } from '@invisitdev/web'

init({ site: '<site id>' })
track('signup', { plan: 'pro' })
identify(user.id)

See identifying signed-in users for when to call identify().