So where are they actually coming from?

Direct means your analytics couldn’t identify the source of the visit. Typing your address is one way to get there. Clicking an untagged newsletter link, opening a recommendation in a messaging app, or following a link that loses its source information can produce the same result. In Plausible, these visits appear as Direct / None.

Some of this can absolutely reflect brand strength: people remember you, choose to come back, or recommend you to someone else. The question is how much of your traffic reflects that familiarity, and how much you could identify with better campaign tagging.

If you’re looking at Google Analytics, its (direct) / (none) label refers to the same basic issue: no clear source for the traffic. The concerns below apply there too; the dashboard steps are for Plausible.

1. Why is direct traffic my biggest source?
2. Nobody is typing these long URLs. Where are those visits coming from?
3. Why are new visitors showing up as direct? They’ve never heard of us
4. We sent a newsletter. Why did direct go up instead of email?
5. We already added UTMs. Why is traffic still showing as direct?
6. Are browsers and privacy tools hiding the source?
7. Direct traffic suddenly spiked. Is it bots?
8. How can I make my traffic reports more accurate?
   1. First, check where visits start and what has changed
   2. Tag your campaign links with UTMs
   3. Use a proxy to count visits that blockers would hide
   4. Exclude internal and test traffic
9. Can I find out where the rest of my direct traffic came from?
10. Should I worry about a high direct share?
    1. Doesn’t direct traffic also show brand strength?
    2. What should I actually be concerned about?

Why is direct traffic my biggest source?

Because Direct can collect visits from several places whose sources aren’t identifiable for some reason.

Google, Bing, LinkedIn, an AI assistant or a referring website each represents an identifiable source. Direct combines returning customers, email readers, private recommendations and other visits with missing source information. That mixture can be bigger than any individual source, or even a whole channel such as organic search or social.

You don’t need to be a famous brand for direct traffic to be your biggest source.

If you run a product that customers return to every day, some of those visits may simply be people opening a bookmark or choosing your site from their browser history. Your own team can contribute visits too.

Nobody is typing these long URLs. Where are those visits coming from?

They don’t have to type them. Someone can reach a specific product page or article through:

• A link in an email, WhatsApp message, Slack conversation or another app.
• A link in a PDF, slide deck or downloaded document.
• A copied URL pasted into the address bar.
• A bookmark or a suggestion from their browser history.
• A QR code pointing to the page.

When a browser opens a link, it can tell your site where the visitor came from. That information is called the referrer. Apps and documents don’t always supply one, and an untagged URL may offer no other clue.

Traffic with an unknown origin is often called dark traffic. When it comes from private sharing, such as a recommendation in a group chat, you’ll also hear dark social. That describes one part of the list above, so a long URL alone isn’t enough to tell you it was shared privately.

You can still see how many visits you received, which pages people viewed and whether they converted. It’s the source of those visits that’s unknown.

App behavior varies depending on the app, device and how the link opens. Plausible recognizes some Android app referrals when that information is available.

For a particular article or product page, check where you’ve recently shared it. A direct spike on the day it appeared in a newsletter gives you something concrete to investigate, even if it doesn’t identify every visit.

Why are new visitors showing up as direct? They’ve never heard of us

Someone recommends your product in a private message. The recipient has never heard of you, but opens the link. If there’s no referrer or campaign information, their very first visit can be direct. They don’t need to know your address or have visited before.

The reverse is also worth remembering: someone who knows your brand and searches for it on Google normally arrives as organic search when they click an unpaid result. Brand familiarity and traffic source are different things.

We sent a newsletter. Why did direct go up instead of email?

Check the links in the email you actually sent. Do they include UTM tags?

Without tags, a click from an email client that supplies no useful referrer can appear as direct. Your newsletter may be bringing people in without getting named in the report.

UTM tags give the link a source and campaign name your analytics can read. If you haven’t used them before, there’s an example below.

Not every untagged campaign becomes direct. A social network may still identify itself, but you might lose the distinction between a paid ad and an organic post. Tags help with that too.

We already added UTMs. Why is traffic still showing as direct?

Adding tags to a spreadsheet or an ad setup isn’t the final check. They need to reach the page where your analytics records the visit.

Open the actual published link and follow it through to the destination. Check these three things:

• Did a redirect drop the tags? A shortener, email click tracker or redirect from an old URL may discard the query parameters. Redirects don’t always do this, so test yours before blaming them.
• Does the landing page record visits? If tracking is missing there, your analytics may only see the visitor after they click further into the site, without the original campaign information. Check the tracking installation on that specific page (here’s how to do it in Plausible).
• Are you testing during an existing session? In Plausible, clicking another tagged link during an active session doesn’t replace that session’s original source. For a reliable test, use a device and network combination that hasn’t visited in the past 30 minutes. Opening an incognito window may not be enough. See our UTM testing notes.

Are browsers and privacy tools hiding the source?

They can, but “privacy” doesn’t explain every direct visit.

A referring site can suppress the referrer, and browser settings or extensions can restrict it. If no usable campaign information arrives either, a recorded visit can end up as direct.

But browsers often remove only the specific page, while keeping the referring website. A click from thatblog.com/article may tell your analytics thatblog.com. You still know the source. Our referrer policy post explains that loss of detail.

The common browser policy also drops the referrer when navigating from HTTPS to HTTP. Going from HTTP to HTTPS doesn’t inherently do the same. MDN’s policy reference covers the differences.

And if a blocker prevents analytics from recording a visit altogether, that visit is missing from the report. It doesn’t automatically become direct. You can’t use the Direct percentage to count people using privacy tools.

Direct traffic suddenly spiked. Is it bots?

Possibly. Automated visits can inflate Direct if your analytics counts them without source information. But the source label alone doesn’t tell you whether a visitor is human.

Look at when the increase started. Did you send a campaign, get a mention, change redirects or update tracking? If a known source dropped at the same time, test its links. That timing is a clue, not proof that all those visits moved into Direct.

Then look at the spike itself. Repetitive page requests, unusual bursts, an unexpected device or location mix, and little meaningful activity together are reasons to investigate bots. A high bounce rate or a particular country alone isn’t enough. Our traffic spike investigation goes through the checks.

Plausible filters bot traffic automatically. We exclude known bots and crawlers, traffic from known data center IP ranges, known referrer spam, and traffic patterns that look automated. These filters are on by default and we update them as new patterns emerge. Here’s how the filtering works.

We also ran a controlled bot experiment, sending automated visits to a test site, including visits that identified themselves as ordinary browsers. Google Analytics counted the simulated traffic; Plausible rejected it in our tests.

Some bots can still get through. If suspicious traffic persists in Plausible, contact us with the dates and patterns you’ve noticed. Adding UTMs won’t fix bot traffic: they identify campaign links, while filtering excludes automated visits from your stats.

How can I make my traffic reports more accurate?

Start by checking which visits you’re trying to understand. Then you can decide whether you need better campaign tags, help counting missed visits, or a way to keep your own testing out of the reports.

First, check where visits start and what has changed

Check where those visits start. In Plausible, click Direct / None in Sources, then look at Entry Pages. Lots of visits to a login page or dashboard suggest a different explanation from lots of visits to a newly published article. For homepage visits, check whether people go on to log in or explore the product.

Also check the actual count, not just the percentage. If direct stays at 200 visits while total visits fall from 1,000 to 500, its share doubles from 20% to 40%. In that case, investigate what happened to your other traffic sources.

Tag your campaign links with UTMs

UTM tags give the link a source and campaign name your analytics can read. For example:

https://example.com/new-feature?utm_source=newsletter&utm_medium=email&utm_campaign=september-update

This identifies the source as newsletter, the medium as email, and the campaign as september-update.

Start with external links you control: newsletters, ads, social profiles and posts, partner placements, and downloadable documents. In Plausible, open Campaigns to see tagged traffic and filter by the campaign to check activity and goal conversions.

Use our UTM builder to create the links, or the UTM checker to check ones you’ve already made. The full UTM guide covers naming conventions and the other parameters.

Keep UTMs on incoming campaign links. Use events or goals for clicks within your own website, and keep personal information such as email addresses out of the tags.

Use a proxy to count visits that blockers would hide

For those missed visits, Plausible offers a proxy setup. It serves the analytics script through your own domain, helping it get past many blockers so more visits are counted.

A proxy does not restore a referrer or UTM tags that were stripped before the visitor arrived, though. It can improve overall traffic accuracy, without necessarily reducing Direct.

Exclude internal and test traffic

If your team regularly tests the site, Plausible’s traffic exclusion controls can keep those visits out of your stats. You can exclude your office IP addresses or your own browser. If staging or preview sites use the same tracking setup, a hostname allowlist lets you record only your live website’s hostnames. These controls stop unwanted visits from being recorded; they don’t identify the sources of the remaining direct traffic.

Can I find out where the rest of my direct traffic came from?

If the source information wasn’t collected, you can’t reliably reconstruct it from the Direct total. Adding UTMs now won’t identify past visits.

For future visits, start by getting your own campaign links in order. That still leaves links other people share without tags, and customers returning through bookmarks. Those visits won’t all become identifiable just because your campaigns are tagged correctly.

Even tagged links have limits. If someone forwards your newsletter URL into a group chat, its UTM tags can still say newsletter. You know which campaign link was used, but not every place it was shared.

Should I worry about a high direct share?

Doesn’t direct traffic also show brand strength?

Yes, some of it does. People remembering your address, bookmarking your content and returning to buy are signs that you’ve given them a reason to come back. Recommendations shared privately can also reflect trust in your brand, even when analytics can’t identify the conversation.

The limit is that Direct mixes those visits with untagged campaigns and other missing-source traffic. You can’t count the whole row as brand-driven demand, or assume that a rise means awareness has grown.

Ask customers how they heard about you, especially when recommendations or offline activity matter to your business. Their answers, more searches for your brand, and direct visitors taking meaningful actions give you a stronger case than the Direct percentage alone.

What should I actually be concerned about?

Unexplained changes and campaigns you can’t evaluate deserve attention. A high direct share by itself isn’t a reason to assume something is wrong.

There isn’t a universal “healthy” direct percentage. Compare against your own history, using the same metric and similar periods.

After you fix your tags, Direct may fall while Email or another source rises. That can be the same traffic becoming easier to identify. You haven’t necessarily lost visitors; you’ve learned more about where they’re coming from.

Those are simple questions, but answering them well can help you decide what to publish, which campaigns to continue and where your website needs work. This guide covers how web analytics works, the metrics worth knowing and how to put the data to use.

1. What is web analytics?
2. Why is web analytics important?
3. How does web analytics work?
4. Important web analytics metrics
   1. Sources, pages and campaigns
   2. Goals, funnels and journeys
5. How to set up web analytics
6. Common web analytics mistakes
7. Choosing a web analytics tool
8. Web analytics with Plausible
9. Frequently asked questions

What is web analytics?

Web analytics is the collection, measurement and analysis of website data. Most of it falls into three areas:

1. Acquisition: How visitors find you through search, referrals, social media, email and campaigns.
2. Engagement: Which pages and actions visitors interact with.
3. Conversion: Whether they complete an important outcome such as a purchase, signup or enquiry.

Put together, these reports show the journey from arrival to outcome. An ecommerce store, for example, can see which campaign brought visitors to a product page, how many started checkout and how many purchased. A publisher can find the articles that attract search traffic and lead to newsletter signups.

Why is web analytics important?

Without analytics, you are largely guessing whether your website is doing its job. With it, you can:

• understand which channels bring useful traffic;
• find popular and underperforming content;
• compare campaigns using conversions rather than clicks alone;
• identify drop-off in signup or checkout funnels;
• prioritize mobile, browser or location-specific improvements; and
• investigate unexpected traffic spikes and drops.

The purpose is not simply to collect numbers. It is to find what is working, what needs attention and what to do next.

That does not mean every decision has to begin in a dashboard. Analytics is most useful when it gives context to something you have already noticed or helps you check an assumption. If customers say that checkout is difficult, the funnel can show how widespread the problem is. If an article suddenly gets more attention, the sources report can show where those readers came from and whether they explored anything else.

How does web analytics work?

Most tools use a small JavaScript snippet added to each page. When someone loads a page, it sends a pageview event containing information such as the page URL, referrer, campaign parameters, device and browser.

The analytics service then turns those events into familiar reports for visitors, visits, pages, sources and conversions. Along the way, it may filter known bots and group individual sources into broader channels.

You can record custom events beyond pageviews, including form submissions, downloads, signups, cart activity and purchases.

Some tools use cookies or persistent identifiers to recognize browsers across visits. Others, including Plausible, provide cookieless web analytics without creating persistent visitor profiles.

JavaScript is the most common method, but it is not the only one. Server logs can see requests that browser scripts miss, although they also include bots and requests for files. Server-side events are useful for actions confirmed by your backend, such as a completed payment. Some websites combine these methods because each captures a different part of the activity.

Important web analytics metrics

An analytics dashboard can show dozens of metrics, but you can understand most websites with a relatively small set. Start with the size of the audience, learn where it came from, then look at what those visitors did. Add more measurements only when they help answer a real question.

You will find most of these metrics in any general web analytics product. Their exact definitions can differ, though, so check how each tool calculates them before comparing dashboards. Here are Plausible’s metric definitions.

Sources, pages and campaigns

Source reports show whether visitors came from search, referrals, social media, email, advertising or direct traffic. Entry pages show where visits began; top pages show what people viewed; exit pages show where visits ended.

These reports are most useful together. A list of top pages tells you what is popular, but not why people reached those pages or whether the visits were valuable. Filtering the dashboard by a page connects that content to its sources, audience and goals.

Direct is a fallback when referral information is unavailable, not only people typing your address. Use UTM parameters on campaign links to make attribution clearer.

Traffic is only the starting point. Filter a source or page and look at engagement, goals and revenue too. A smaller source with a strong conversion rate may be much more valuable than the one sending the most visitors.

Goals, funnels and journeys

A goal can be a thank-you page or an event such as Signup or Purchase. A funnel measures a known sequence, for example Product page → Cart → Checkout → Purchase.

This makes it easy to see where visitors stop. If you do not know the path in advance, website journey analytics can instead show what happened before or after a particular page or event.

Not every website needs a complicated funnel. A personal site may only need to measure contact-form submissions. A publication may care about newsletter signups. The point is to choose actions that reflect why the site exists rather than turning every click into a goal.

How to set up web analytics

It is tempting to design a complete tracking plan before installing anything. For most websites, a smaller start works better. Set up the basic traffic reports and one or two meaningful goals, use them for a while and let real questions guide what you add next.

1. Define the website’s purpose. Choose one or two primary outcomes.
2. Choose a suitable tool. Consider reports, privacy, ease of use, performance and cost.
3. Install it on every relevant page. Include subdomains or checkout pages where needed.
4. Verify the installation. Visit the site and confirm the pageview appears once in real time.
5. Configure and test goals. Measure completed outcomes where possible.
6. Tag campaigns consistently. Use agreed lowercase UTM values, but never add UTMs to internal links.
7. Review useful comparisons. Compare periods and segment by source, page, campaign, device or country.

Our guide to checking your own website traffic walks through the complete process.

Once data starts arriving, give it enough time to become representative. Real-time reports are useful for confirming that tracking works, but a handful of visits cannot tell you whether a page or campaign is successful. Look at an appropriate date range and compare it with a similar period.

Common web analytics mistakes

Most analytics mistakes come from reading a number without asking what produced it or what the page was meant to do. The dashboard may be accurate while the conclusion drawn from it is not.

Treating more traffic as automatic success. A spike looks encouraging, but it may come from bots, an irrelevant referral or visitors who have no interest in what you offer. Traffic matters when it reaches the intended audience and produces useful outcomes.

Judging engagement without page context. A visitor can find an answer on one page and leave satisfied. An exit from a thank-you page is expected; an exit halfway through checkout is more interesting. A bounce or exit is not automatically bad.

Expecting different sources to match. Search engines count search clicks, ad platforms count ad clicks, servers count requests and web analytics products apply different visitor and session rules. Read why analytics numbers do not match.

Tracking everything. It is easy to assume that data may become useful later. In practice, hundreds of undocumented events make reports harder to trust and create unnecessary privacy risk. Collect events that answer real questions and make sure everyone understands what they mean.

Choosing a web analytics tool

Start with the decisions you need to make, since products with similar labels can solve quite different problems. General website analytics products such as Plausible and GA4 cover traffic, pages, campaigns and conversions. Behavior analytics products add heatmaps or session replay, while product analytics focuses on user histories, feature adoption and retention. Competitive analytics products estimate other websites’ traffic, but they cannot replace first-party analytics on a site you own.

You may need more than one category, but you probably do not need every category. A content site may be perfectly served by general web analytics and search-performance data. A software company may use web analytics for its marketing site and separate product analytics inside the application.

Compare tools using:

• reports and integrations;
• ease of use;
• data collection and privacy;
• documented metric definitions;
• script performance;
• data ownership and hosting; and
• subscription and operational costs.

If you need multi-month user or account retention, you may need product analytics too. Our web analytics vs product analytics guide explains the difference.

Whichever product you choose, test it with the people who will actually use it. A long feature list is not much help if answering a routine question requires specialist training or another custom report.

Web analytics with Plausible

We’re Plausible Analytics, and we have been building a simpler approach to web analytics since 2019. We bring visitors, visits, pageviews, sources, campaigns, pages, locations, devices, goals, revenue, funnels and journeys into one real-time dashboard. You can start with the overview, then click any entry to filter the rest of the dashboard and investigate further.

We do not use cookies, collect personal data or create persistent visitor profiles. Our script is lightweight, our cloud service is hosted in the EU and our code is open source.

We built it this way because most website owners do not need an individual history of every visitor. They need to understand what brings people to the site, which content works and whether visitors complete the actions that matter. Keeping those answers together also makes the dashboard useful to people who are not full-time analysts.

If that sounds like the kind of web analytics you need, you can explore our live public dashboard or start a free 30-day trial.

Frequently asked questions

That looks like one customer journey. In analytics, however, it contains two different sets of questions:

• Web analytics: Where did the visitor come from? Which landing page and campaign led to the signup? Where did people leave the signup flow?
• Product analytics: Did the new account reach its activation milestone? Which features did it use? Did it return in week two? Do invited teams retain better than solo users?

The difference is not simply “website data” versus “app data.” Both types of tools can track pages, events and funnels. The more useful distinction is the decision you are trying to make and the level of continuity the answer requires.

Web analytics is mostly used to improve acquisition, content and conversion. Product analytics is used to improve how people activate, adopt features and receive value from a product. The data needed depends on the question: a feature count is much simpler than a retention cohort that follows the same accounts for several months.

This guide explains where that line sits, where Plausible fits and when you should use a dedicated product analytics platform instead.

1. What is web analytics?
2. What is product analytics?
3. Web analytics vs product analytics at a glance
4. Where Plausible fits
5. Where Plausible is not trying to compete with product analytics tools
6. SaaS use cases Plausible does cover
   1. Signup funnels
   2. Marketing attribution through to a meaningful conversion
   3. Custom events and properties
   4. A/B test result tracking
7. How to choose between web analytics, product analytics or both

What is web analytics?

Web analytics helps you understand how people find and use a website, and whether they complete the actions the website is designed to encourage.

It is best suited to questions such as:

• How much traffic did we get, and which sources sent it?
• Which search queries, referral sites and campaigns brought qualified visitors?
• Which landing pages attract traffic and lead to signups?
• How many visitors viewed pricing, started registration and completed it?
• Did the new homepage or campaign improve the conversion rate?

The core web analytics workflow is acquisition → engagement → conversion.

Acquisition reports cover referral sources, search, paid and organic campaigns, and UTM parameters. Content reports cover landing pages, popular pages, entry and exit pages, and engagement. Goals and funnels connect that activity to outcomes such as a demo request, newsletter subscription, trial signup or purchase.

This is useful beyond the marketing department. Founders, content teams and growth teams all need to know what brings the right audience to a site and what helps that audience convert.

What is product analytics?

Product analytics helps you understand how people use a software product and whether that experience delivers value. It can be as simple as counting uses of a feature or as involved as following the same users and accounts across days, weeks or months.

It is built for questions such as:

• What percentage of new accounts reaches the activation milestone?
• How often is a particular feature or workflow used?
• Did usage of a feature increase after a release?
• How long does activation take?
• Which onboarding steps predict successful adoption?
• Do people who use a particular feature retain better?
• What is the day 7, week 4 or month 3 retention rate?
• How does behavior differ by signup cohort, plan or account type?

The core product analytics workflow is activation → engagement → retention.

Questions about total feature usage or changes after a release may be answered with aggregate events and properties. Retention and behavioral cohorts require the events in the analysis to be associated with the same users over time. Product analytics platforms use user identifiers for this purpose; some also support separately configured group identifiers for account- or workspace-level analysis. A user profile is not always required simply to record events, but a consistent identifier is what lets the platform group people by actions they took and calculate whether they returned later.

Identity does not define product analytics. It becomes necessary for a particular class of questions: who did something, what else they did and whether they came back later. “Who” may mean a pseudonymous user, workspace or account rather than a named person.

Web analytics vs product analytics at a glance

The categories overlap. A web analytics tool may support custom events and funnels. A product analytics tool may report acquisition sources and landing pages. The presence of an “events” or “funnels” feature does not settle which category a tool belongs to. What matters is whether you are trying to improve how people find and convert on a website or how they use and get value from a product.

Start instead with two questions:

1. What are you trying to improve? Acquisition, content and website conversion usually point to web analytics. Activation, product engagement, feature adoption and retention point to product analytics.
2. What continuity does the answer require? Counting uses of a feature is one thing. Building retention cohorts or tracing account journeys across sessions requires a stable user or account identifier.

The first question identifies the analytical job. The second identifies the data model and type of tool needed to do it.

Where Plausible fits

Plausible is a web analytics tool. It measures traffic and behavior without cookies, personal data or persistent identifiers. That focus does not prevent it from answering selected questions about product usage.

Its natural strengths are:

• Traffic acquisition and marketing attribution
• Pages, landing pages and content performance
• Referral sources, channels and UTM campaigns
• Goals, conversion rates and revenue attribution
• Custom events and properties
• Defined conversion funnels and open-ended user journeys

For a SaaS business, that covers the journey from a campaign, search result or referral through to a trial signup or another meaningful conversion. You can also send selected events from the product, such as Created Project or Invited Teammate, to measure their frequency or include them in a conversion funnel.

Plausible can therefore answer questions like:

• Which campaign drove the most trial signups?
• Which landing page visitors are most likely to create a project?
• Where do visitors drop out between pricing, signup and onboarding completion?
• Which plan or experiment variant has the higher conversion rate?
• How often was a feature used during a selected period?

Feature usage is a product analytics question that does not always need an individual history. Plausible can count a feature event and segment it using non-personal custom properties. It cannot tell you whether the people who used the feature in January returned in February.

That limitation follows directly from Plausible’s privacy model. A person who visits on different days may be counted as a different visitor because Plausible does not use a persistent identifier to recognize them. Do not send names, email addresses, account IDs, pseudonymous cookie IDs or other personal identifiers as custom properties.

Where Plausible is not trying to compete with product analytics tools

Tools like Amplitude and Mixpanel are event-based analytics platforms with reports for product questions such as funnels, behavioral cohorts and retention. In both tools, events can be associated with a user identifier so activity from the same user can be analyzed together. Their documentation also describes separate group-level features for analyzing companies, workspaces or other account-like entities; these require additional instrumentation and may depend on the product or plan.

Plausible overlaps with a portion of product analytics; it is not trying to reproduce that persistent behavioral model with a simpler interface. It does not provide:

• Persistent user profiles or separately configured account/group profiles
• Multi-day user-level histories
• Signup cohorts followed through later periods
• Retention curves such as day 1, day 7 or week 4 retention
• Comparing later retention for cohorts defined by earlier product behavior
• User-level feature adoption or frequency analysis

Suppose 500 people sign up in August. Plausible can answer “How many project-creation events happened in August?” It cannot answer “Of that August signup cohort, how many activated within seven days and were still active four weeks later?” The second question requires connecting each account’s signup, activation and return events over time. Plausible deliberately does not maintain that connection.

Plausible can instead tell you how many visitors completed a signup or activation event during August, the sources and campaigns associated with those conversions, and where visitors dropped out of a defined funnel. Those are useful answers, but they are not a retention cohort.

This is also why a “unique visitor” in web analytics should not be treated as a SaaS user count. Your billing system or product database is the source of truth for accounts, subscriptions and churn.

For a broader view of other use cases outside Plausible’s scope—including session replay, retargeting and user-level tracking—read when Plausible is not the right fit.

SaaS use cases Plausible does cover

The boundary does not mean Plausible stops being useful when someone clicks “Sign up.” Many SaaS teams need a focused set of product and growth signals without building a full user-level analytics system.

Signup funnels

You can combine pageview goals and custom event goals into a funnel such as:

1. Viewed pricing
2. Started signup
3. Completed registration
4. Created first project

Plausible shows how many visitors complete each step and the drop-off between them. You can filter the funnel by source, campaign, landing page, device, location or another available dimension to find where a particular segment struggles.

This works well for a defined conversion or onboarding path. It is not a substitute for following a signup cohort through a 30-day lifecycle. See the funnel analysis documentation for setup details and current limits.

Marketing attribution through to a meaningful conversion

A signup count alone can reward channels that bring a lot of low-intent traffic. A more useful setup sends a later milestone—such as Created Project, Booked Demo or Upgraded—as a goal.

You can then filter that goal by referral source, channel, UTM campaign or landing page. This answers questions such as “Which campaign brought visitors who reached activation?” without building profiles for those visitors.

Attribution has limits in any privacy-friendly system. Plausible is strongest when the journey happens within the same visitor session across your site and subdomains. It is not designed to stitch a person across devices or recognize a lead who returns weeks later from another browser.

Custom events and properties

Custom event goals let you measure actions that do not produce a distinct pageview: CTA clicks, form completions, video plays, project creation or any other event you choose to send.

Custom properties add non-personal context to a pageview or event. A SaaS team might attach:

• plan=starter or plan=pro to a signup event
• role=admin or role=member to a feature event
• logged_in=true to separate public-site and in-product activity
• variant=A or variant=B to an experiment exposure or conversion

For example, you could attach logged_in=true or logged_in=false to a goal event. Plausible can then show the visitors, total events and conversion rate for each value. This helps you compare how the event is used in logged-in and logged-out contexts, but it does not create a history of what each logged-in user did before or after that event. You can explore this kind of property breakdown in our live demo.

Properties let you filter and compare behavior. They must not contain information that identifies or persistently singles out a person.

A/B test result tracking

Plausible can measure the outcome of a website A/B test. Send the assigned variant as a custom property, then compare goal completions and conversion rates for each variant.

Plausible does not split traffic, assign variants, manage feature flags or decide whether a result is statistically significant. You need your own code or an experimentation tool for those parts. Plausible measures the resulting visits and conversions.

Our guide to A/B testing a website explains the setup and the statistical cautions.

How to choose between web analytics, product analytics or both

Use web analytics when your main questions are about traffic, content, campaigns and conversion:

• Where are visitors coming from?
• Which pages and campaigns generate signups or revenue?
• Where does a short signup or checkout funnel lose people?
• Did a landing-page experiment improve conversion?

Use product analytics when your main questions are about activation, product engagement, feature adoption or retention:

• How often is a key feature or workflow used?
• Did overall usage change after a product release?
• Which signup cohorts retain after 30 or 90 days?
• How does retention differ between people who did or did not use a particular feature?
• How does feature adoption develop over a customer’s lifecycle?
• Which individual accounts have or have not reached an activation milestone?

The first two questions only require overall usage totals. The remaining questions need events to be linked to the same users or accounts, using a dedicated product analytics system or your own product data.

Use both when acquisition and product retention are both important enough to analyze deeply. This is common for a growing SaaS company: Plausible can provide a simple, privacy-friendly view of the marketing site and acquisition funnel, while Amplitude, Mixpanel or another product analytics system provides the linked event data needed for cohorts and retention.

The numbers from two tools may not match exactly because they use different identity models, time windows and definitions. That does not make either one automatically wrong. Define which system owns each metric: for example, Plausible for website visitors and campaign conversions, your application database for accounts and revenue, and a product analytics tool for cohorts and retention.

If your needs sit in the overlap, write down the exact question. “Can it track events?” is too broad. Ask instead:

• Do we need an event total or a history for each user?
• Is this a conversion funnel or a multi-week lifecycle?
• Do we need to compare traffic segments or behavioral cohorts?
• Is identifying the same account later essential to the answer?

Those questions make the choice much easier.

Plausible is built for teams that want clear answers about acquisition, website behavior and conversion without tracking people across the internet—or across months of product use. It can also measure selected activity inside a product. If that matches your needs, explore Plausible for SaaS or start a free 30-day trial. If you need retention cohorts or long-term user and account histories, choose a dedicated product analytics tool, whether or not you also use Plausible for your website.

The most accurate way to answer that question is to install a web analytics tool on the site you own. This gives you first-party data based on visits that actually happened, rather than an outside tool’s estimate.

This guide helps you set up measurement, learn to read the dashboard, and gradually turn raw traffic into something you can act on. The examples use Plausible Analytics, but the same basic questions apply to any web analytics.

1. 1. Install analytics on your website
   1. Make sure your analytics is working
2. 2. Choose a useful date range
3. 3. Check visitors, visits and pageviews
4. 4. Find where your traffic comes from
5. 5. Check which pages people visit
6. 6. Check campaign traffic with UTM parameters
7. 7. Check conversions and goals
8. 8. Diagnose a traffic spike or drop
9. Why a public traffic checker can never measure your site accurately
10. A simple weekly website traffic check

1. Install analytics on your website

Before you can interpret traffic, you need somewhere reliable to record it. A website traffic checker can only estimate a site’s traffic numbers; it cannot tell you exactly how many people visited. For that, your website needs to send data to an analytics platform.

Most analytics tools do this using a small JavaScript snippet. You add the snippet to the <head> of every page you want to measure. Depending on how your site is built, you may instead use an official plugin, an integration, or a tag manager.

The exact setup depends on the analytics tool and how your site is built, but the basic process is usually:

1. Add your website to the analytics tool.
2. Copy the tracking snippet or select the relevant integration.
3. Add it to your website, either directly or through your content management system, framework or tag manager.
4. Visit your website and verify that your visit appears in the dashboard.

If you are using Plausible, our installation guides cover popular platforms and frameworks.

Make sure your analytics is working

After installing analytics, it is a good practice to check that it is receiving visits. You can open your website in a private window, visit a page, and look for that visit in your tool’s real-time report. If it appears, your basic tracking is working.

Some tools make this easier. Plausible, for example, has an automatic integration verification tool that checks whether the tracking script is installed correctly. You can also run it again from your site settings after changing your setup.

If your test visit does not appear, use our tool-independent guide to checking whether analytics is working. It covers common causes as well as less-common setups involving single-page applications and subdomains.

If tracking works but your totals differ from Google Analytics, Search Console, an advertising platform or another source, that does not automatically mean something is broken. These tools measure different things in different ways. Our guide to why analytics numbers do not match explains how to interpret those differences.

Once visits are coming through, resist the urge to judge the first number you see. A traffic total only becomes meaningful when you place it in time.

2. Choose a useful date range

The useful date range depends on what prompted you to open the dashboard. Are you checking a campaign you launched this morning, reviewing an ordinary month, or wondering whether the site has grown over the past year?

• Use Today or Last 24 hours to check a launch, active campaign or sudden incident.
• Use Last 7 days for recent operational changes.
• Use Last 30 days for a steadier view of normal performance.
• Use 6–12 months to see seasonality and long-term direction.

Turn on a comparison with the previous period or the same period last year. “10,000 visitors” has little meaning on its own. “10,000 visitors, up 18% from the previous 30 days” gives you context.

In Plausible, the date picker lets you compare your selected range with the previous period, the same period a year earlier or a custom period. See the documentation on comparing your stats over time.

Use a same-length previous period to understand recent momentum, and a year-over-year comparison to see how the site has changed over a longer cycle. Comparing the same dates across years is also useful for separating real growth from seasonal effects. For example, comparing December with November could make a retail site look unusually strong; comparing it with the previous December gives you a fairer view of its growth.

With that context in place, you can read the headline numbers without mistaking normal fluctuation for a meaningful change.

3. Check visitors, visits and pageviews

Start with visitors, visits and pageviews. Together, they move you from how many people came, to how often they came, to how much they explored.

For example, a visitor who loads five pages during one session generally produces one visitor, one visit and five pageviews. If that person returns in a separate session, visits increase again. The exact definitions vary: analytics products use different identification methods and session rules, so numbers from two tools should not be expected to match exactly.

If you are looking at a Plausible dashboard, the metrics definitions explain exactly how each number is calculated.

Which metric matters most depends on your question:

• Use visitors to understand audience size.
• Use visits to understand how often the site is used.
• Use pageviews to understand how much content was consumed.
• Use views per visit, visit duration and bounce rate to add engagement context.

Do not treat pageviews as people. A documentation site may have many pageviews because visitors need several pages to solve a problem. A single-purpose landing page may succeed with one pageview if the visitor submits the form or buys the product.

These totals tell you the size and shape of the activity, but not what created it. The next question is where those visitors came from.

4. Find where your traffic comes from

Open the Sources or Acquisition report. This turns an anonymous traffic total into a more understandable story: people may have discovered you through a search, followed a recommendation, clicked a campaign, or returned directly.

In Plausible, these reports sit together under Sources. This guide to channels, sources and campaigns explains how incoming traffic is classified and how to move from a broad channel to a specific referrer or campaign.

Depending on your analytics tool, traffic may be grouped into channels such as:

• Organic Search
• Direct
• Referral
• Organic Social
• Email
• Paid Search or Paid Social
• Affiliates
• AI referrals

Start with channels for the broad picture, then drill into exact sources. If Organic Search grew, was it Google, Bing or another search engine? If Referral traffic spiked, which site linked to you? If AI traffic increased, did it come from ChatGPT, Perplexity or another service?

Our guide to AI traffic analytics explains how to connect those referrals to landing pages, engagement and conversions.

“Direct” does not always mean someone typed your address into the browser. It is the fallback when reliable referral or campaign information is missing. Bookmarks, untagged emails, private messages, apps, redirects and links that strip referral information can all appear as Direct.

To judge traffic quality, click a source to filter the rest of the dashboard. Then check its landing pages, engagement and conversions. The source with the most visitors is not necessarily the most valuable source.

For search queries, connect Google Search Console or view its Performance report. Analytics tells you what visitors did after arriving; Search Console tells you which Google queries and pages produced impressions and clicks. Plausible users can connect Search Console to bring those queries into the dashboard.

Knowing where someone came from gives you one half of the journey. To understand what drew them in, and whether the visit delivered on its promise, you need to pair the source with the page they reached.

5. Check which pages people visit

Your pages reports continue the story from acquisition into behavior. They answer three related questions:

• Top Pages: Which pages received the most views?
• Entry Pages or Landing Pages: Where did visits begin?
• Exit Pages: Where did visits end?

Plausible’s pages report guide shows where to find these views and how to filter the rest of the dashboard by a page.

Start with entry pages when evaluating acquisition. A landing page with growing traffic may have gained search visibility, been shared, or received a campaign push. Filter by that page and check which sources delivered its visitors and whether those visitors converted.

Use Top Pages to see what people consumed after arriving. Review engagement alongside traffic: a high-traffic page with poor engagement and no conversions may attract the wrong audience, fail to answer the query, or simply do its job quickly. Context matters.

Exit pages are clues, not automatic problems. Every visit has to end somewhere. An exit from a thank-you page can signal success, while frequent exits from the first step of checkout deserve investigation.

Our guide to analyzing landing pages shows how to combine page, source and conversion data.

Sometimes the source and landing page are enough to explain a visit. But when you are responsible for the link, such as an ad, newsletter, QR code or social post, you can make that trail much clearer before the visitor even arrives.

6. Check campaign traffic with UTM parameters

That is the role of campaign tagging. Referral data alone is not enough for reliable campaign tracking. Links in email, apps, QR codes, documents and private messages may otherwise be recorded as Direct, and a platform name alone cannot distinguish one campaign from another.

UTM parameters are labels added to the destination URL. A tagged link can look like this:

https://example.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=summer-launch&utm_content=top-button

The five standard parameters are:

• utm_source: the specific platform or sender, such as newsletter, linkedin or google
• utm_medium: the type of marketing, such as email, social or cpc
• utm_campaign: the initiative, such as summer-launch
• utm_content: the creative or link variation, such as top-button
• utm_term: commonly used for a paid-search term or another useful targeting label

At minimum, use a consistent source and campaign name. Lowercase values and a shared naming convention prevent Newsletter, newsletter and news-letter from fragmenting your reports.

If UTM tagging is new to you, this guide to UTM parameters explains how the tags work and how to name them consistently. You can then create correctly formatted links with our free UTM builder. After people click them, open the Campaigns report and drill into source, medium, campaign, term or content. Then filter by the campaign to see the pages viewed, engagement and goals completed by those visitors.

Tip: Never add UTMs to ordinary internal links on your own site. Doing so can overwrite the visitor’s original acquisition information and split one journey into misleading campaign data.

Now you can connect a visit to the effort that brought it in. But traffic, even perfectly attributed traffic, is not the final outcome. The next step is to ask whether the visitor did something valuable.

7. Check conversions and goals

Traffic tells you that people arrived. Conversions tell you whether the visit accomplished something that matters to the visitor, to your organization, or ideally to both.

A conversion might be:

• Reaching a thank-you or order-confirmation page
• Submitting a lead or contact form
• Signing up for a trial or newsletter
• Completing a purchase
• Downloading a file
• Clicking a key button, outbound link or email address

etc.

In Plausible, you can configure a pageview goal for a destination such as /thank-you, or use a custom event for actions that do not create a new pageview. The goal conversion guide walks through both options. Ecommerce and subscription sites can also attach revenue data to suitable conversion events.

Once goals are collecting data, check both conversions and conversion rate. A source may bring fewer visitors but convert a much larger share of them. Filter by a goal to see which sources, campaigns, landing pages, countries and devices are associated with the result.

Test every goal yourself after setup. Confirm that one real action produces one conversion, the event name is correct, the value or currency is right where relevant, and routine page loads do not trigger the goal accidentally.

At this point, the dashboard is no longer just a counter. You can trace a line from acquisition to behavior to outcome. That same line becomes especially useful when something suddenly looks wrong or unexpectedly good.

8. Diagnose a traffic spike or drop

When traffic changes suddenly, it is tempting to jump straight to an explanation. Instead, retrace the path you have just built: confirm the measurement, establish the timeframe, identify the affected metric, then narrow the change by source, page and outcome.

Start by confirming that the data is trustworthy. Do not begin rewriting content or increasing ad spend until you have ruled out a tracking issue.

Work through these checks in order:

1. Confirm the timing. Find the day or hour the change began and compare it with a normal period.
2. Check the analytics setup. Look for a removed or duplicated script, a recent site release, consent changes, a domain or subdomain change, broken single-page-app tracking, or a new exclusion rule.
3. Separate visitors, visits and pageviews. If only pageviews changed, navigation or duplicate tracking may be responsible. If all three moved, the audience probably changed.
4. Find the affected segment. Is the change sitewide or concentrated in one source, campaign, page, country, device or browser?
5. Check engagement and conversions. A spike with almost no engagement or conversions may be bot or spam traffic. A drop in traffic with stable conversions may be less serious than it first appears.
6. Match the dates to real events. Check launches, newsletters, ad budgets, press coverage, social posts, outages, holidays and seasonal demand.
7. Investigate search separately. Use Search Console to compare clicks, impressions, queries, pages, countries and devices. Check for ranking changes, indexing problems, algorithm updates and changes in search demand.

Add annotations for launches, site releases and campaigns so future changes are easier to explain. Keep a simple record of what changed, when it changed and which segment moved.

For a deeper checklist, read how to investigate a drop in website traffic. If the graph moved in the other direction, see our guide to investigating a traffic spike.

Why a public traffic checker can never measure your site accurately

If you have searched for a quick way to measure your traffic, you have probably found public tools that ask you to enter a domain. It is important not to mistake their output for your real website data.

These tools can be useful for rough competitor research, but they do not have access to a site’s analytics account. They are estimating from the outside rather than measuring visits as they happen. That is why installing analytics is essential when you want to understand your own site.

Many SEO tools estimate organic search traffic using the keywords a site ranks for, the estimated number of searches for each keyword, its ranking position and an assumed click-through rate. They then add those predicted clicks together. This can provide a useful indication of a site’s visibility in search, but it does not count visits from direct traffic, social media, email, referrals or offline campaigns.

Some products, including Semrush Traffic Analytics and Similarweb, also estimate total traffic and its channel mix. They use samples of browsing activity, often called clickstream data, along with statistical models and other public data to estimate direct, social, referral, search and other traffic. These reports cover more than search, but they are still projections from a sample rather than actual visits recorded on the website itself. Estimates are especially less dependable for small or niche sites where the provider has little data.

So, before using a public traffic number, check what it represents. An organic traffic estimate and an estimated total visits figure are not interchangeable.

An estimate is not necessarily “wrong” because it differs from your analytics. It simply answers a different question with different data. Even first-party tools can disagree because they define visitors and sessions differently, filter bots differently, and may be blocked at different rates.

For measuring your own site, the takeaway is simple: use a well-configured first-party analytics tool as your main source and validate important outcomes, such as purchases or signups, against your own records.

Use public estimates only for rough competitor comparisons, not to measure your website.

A simple weekly website traffic check

You do not need to analyze every report every day. In fact, repeatedly refreshing a dashboard often creates anxiety rather than insight. A calm weekly routine is enough for most websites:

1. Set the last seven days and compare with the previous seven days.
2. Check visitors, visits and pageviews for unusual movement.
3. Review sources and campaigns to see what caused the change.
4. Review entry pages to see where acquisition grew or declined.
5. Check conversions and conversion rate to judge traffic quality.
6. Investigate only the segments that changed materially.
7. Add an annotation for any launch, campaign, outage or site update.

The goal is not to collect the largest possible number of metrics. It is to keep hold of that trustworthy chain from where people came from, to what they viewed, to what they did next, and to notice when any part of that story meaningfully changes.

To see how these reports work together, explore the Plausible live demo alongside the guided dashboard tour. You can filter the dashboard by sources, pages and goals without creating an account.

When you are ready to measure traffic on your own site, you can start a free trial.

But EU-hosted does not always mean EU-owned. And that difference matters.

EU hosting tells you something useful about data location. It does not, by itself, answer who owns the company, who controls the infrastructure or which jurisdiction applies to the provider.

This is not legal advice. It is a practical guide to the questions worth asking when you review analytics vendors. If your organization has strict GDPR, procurement or data transfer requirements, involve your legal or data protection team.

1. What EU-hosted usually means
2. What EU-owned adds
3. How this helps you decide
4. Why this became a bigger issue after Schrems II
5. Examples from analytics tools
6. What Plausible means by EU-owned analytics
7. What to ask before choosing an analytics tool

What EU-hosted usually means

When vendors say “EU-hosted”, they often mean one of several different things:

• Your data is stored in an EU data center.
• You can select an EU region when creating a project.
• EU visitor traffic is routed through EU infrastructure.
• Some data stays in the EU, while other processing or support access may still happen elsewhere.
• EU residency is available only on certain plans or only if you configure the SDK correctly.

Those details matter.

That is why “EU-hosted” should be treated as the start of the conversation, not the end of it.

What EU-owned adds

EU-owned analytics answers a different set of questions:

• Who is the legal entity providing the service?
• Is the company incorporated in the EU or EEA?
• Who owns and operates the infrastructure?
• Are there US-owned cloud providers or subprocessors touching visitor data?
• Is EU processing the default, or a configuration option?
• Is the provider subject to foreign jurisdiction, such as US disclosure laws?

Think of it as three layers:

For example, a tool could store analytics data in Frankfurt but still be operated by a US-incorporated company. Another tool could be incorporated in Europe but rely on a US-owned cloud provider for key parts of its service. Both setups may be perfectly acceptable for some organizations, but neither is the same as an EU-owned analytics provider using European-owned infrastructure by default.

The difference is not just theoretical. 18 USC 2713 says that a provider of electronic communication service or remote computing service must comply with obligations to preserve, back up or disclose covered information within its “possession, custody, or control” regardless of whether that information is located inside or outside the United States.

Whether and how that law applies to a specific analytics vendor is a legal question. But it illustrates the broader point: server location alone does not answer every jurisdiction question.

How this helps you decide

EU-owned analytics makes the most sense when your goal is to reduce the number of privacy and procurement questions you need to resolve.

If a vendor is non-EU-owned, or if it relies on non-EU-owned infrastructure for visitor data, you may need to spend more time reviewing:

• whether personal data is transferred outside the EU or EEA
• which transfer mechanism applies
• whether additional safeguards are needed
• whether foreign disclosure laws are relevant
• which subprocessors can access visitor data
• whether EU residency is the default or something your team must configure correctly

That does not mean a non-EU provider is automatically unsuitable. It means the review is usually more involved.

The European Data Protection Board’s Recommendations 01/2020 exist because international transfers can require transfer tools and supplementary measures to ensure an EU level of protection. If you can choose an analytics provider where the company, hosting and visitor-data infrastructure are all European, you can often avoid a lot of that extra transfer analysis in the first place.

That is the practical reason EU-owned can make more sense. It is not a magic compliance badge. It is a simpler, lower-friction starting point for teams that care about privacy, GDPR and vendor risk.

Why this became a bigger issue after Schrems II

The reason people care about this is not because of a vague preference for European vendors. It comes from years of legal uncertainty around EU-US data transfers.

In 2020, the Court of Justice of the European Union invalidated the EU-US Privacy Shield in the Schrems II ruling. The Court’s press release explains that GDPR transfers to a third country generally require an adequate level of protection, or appropriate safeguards and enforceable rights.

The EU-US Data Privacy Framework is the current adequacy mechanism for participating US companies. The European Commission says the framework was adopted after new US safeguards were introduced to address points raised by the Court in Schrems II. The need for that framework itself shows why jurisdiction remains part of the privacy conversation.

So when a vendor promotes EU hosting, the useful follow-up is: EU hosting under whose control?

Examples from analytics tools

You can see the difference across the analytics market.

Some tools offer EU data residency while remaining operated outside the EU.

PostHog’s privacy policy says its hosted services are offered by PostHog Inc., and that PostHog is headquartered in the United States. Its privacy compliance documentation says PostHog Cloud EU is a managed version with servers hosted in Frankfurt. Again, the EU cloud option may be useful for many teams, but it is not the same claim as being an EU-incorporated analytics provider on European-owned infrastructure.

Mixpanel’s EU residency documentation says that Mixpanel stores user data on US servers by default, while giving customers the option to process and store customer personal data in Europe through its EU Data Residency Program. It also says new EU projects must send data to the EU endpoint, and that projects using the wrong residency location need to create a new project and migrate data.

Google’s Analytics documentation for EU, Switzerland and UK data says that data from devices in those regions is collected through local domains and servers before traffic is forwarded to Analytics servers for processing. Google’s data processing terms also say that Google may process customer personal data in any country where Google or its subprocessors maintain facilities. That is a useful example of the distinction: regional collection is not the same thing as EU-only processing or EU ownership.

Matomo is a good reminder that not every non-EU example is the same. Its Cloud privacy policy says personal data in a customer’s Matomo Cloud instance and backups are stored in Europe, while InnoCraft, the company behind Matomo, is based in New Zealand. Matomo also notes that New Zealand has an EU adequacy decision, which the European Commission lists among its adequacy decisions. That is a different legal posture from a US-operated provider, but it still shows why “where data is stored” and “who operates the service” are separate questions.

This distinction is now showing up in SaaS vendor research too. For example, FoundersDeck’s EU SaaS Jurisdiction Database separates legal entity, hosting, EU residency and CLOUD Act exposure instead of treating “EU region available” as the whole answer. Databases like this can be useful starting points, but you should still verify each vendor’s legal entity, infrastructure and subprocessors against the vendor’s own documentation.

The important thing is not to assume based on a badge or a landing page phrase. Check the legal entity, infrastructure and subprocessors.

What Plausible means by EU-owned analytics

At Plausible, EU hosting is not a checkbox or an enterprise add-on.

Plausible is incorporated in Estonia, built by a team based in the EU and hosted on infrastructure owned by European companies. Visitor data is processed and stored in the EU. It is not transferred to the United States or any other country outside the EU.

In practice, that means:

• Visitor data is processed and stored in the EU.
• We store visitor data on servers owned by Hetzner, a German company, in Falkenstein, Germany.
• We use UpCloud, a Finnish company, for database hosting and storage of data exports.
• We use Bunny, a Slovenian company, as our CDN, while analytics processing and storage stays on our EU infrastructure.
• These are the only three providers that touch visitor data, and all three are European-owned.
• We do not use US-owned cloud providers such as AWS, Google Cloud or Microsoft Azure to store or process visitor data.
• We do not sell visitor data, share it with advertising companies or use it to build profiles across websites.

This is not a regional toggle we added for compliance purposes. It is a deliberate infrastructure decision. It is EU-ownership by design.

For the fuller version, including links for legal and procurement teams, see our EU-hosted analytics page, data policy, privacy policy and DPA.

This ownership and infrastructure setup is only one part of the privacy story. Plausible is also designed for simple reach measurement without cookies, cross-site tracking or advertising profiles. For the consent and data minimization side, see this independent legal assessment of Plausible under GDPR and the ePrivacy Directive written by Steffen Gross, a data protection expert and lawyer.

This is the difference between saying “your data can be hosted in Europe” and saying “your analytics runs under European ownership and European infrastructure by default”.

What to ask before choosing an analytics tool

If you’re choosing analytics for privacy, GDPR or procurement reasons, don’t stop at the hosting claim. Ask three simple questions:

• Where is visitor data processed and stored?
• Who owns the company, infrastructure and subprocessors involved?
• Is EU handling the default, and can the vendor document it clearly?

Plausible is a privacy-friendly, cookieless analytics tool. We do not track people across websites, build user profiles, sell visitor data, or use persistent identifiers. Our data policy explains exactly what we collect and why. Because of that, Plausible is not treated the same way as Google Analytics by many privacy-conscious people, browsers and blocklists.

But ad blockers are not one single thing with one single policy. Some block only ads. Some block known invasive trackers. Some block anything with “analytics” in the URL. Some users configure their browser to block all JavaScript. So the most accurate answer is:

• Plausible’s default script is blocked far less often than Google Analytics.
• Some aggressive blockers can still block Plausible because they block all analytics tools, not just privacy-invasive ones.
• If you want the most complete data, you can run Plausible through a proxy, which makes the script and event endpoint load from your own domain.

Let’s unpack what that means in practice.

1. Why Plausible is blocked less often than Google Analytics
2. How the Plausible proxy reduces ad blocker impact
3. Is using a proxy ethical?
4. Proxy options in Plausible
5. Why your own Plausible visit might not show up
6. Why Plausible and GA4 numbers are often different
7. Should you worry about ad blockers when using Plausible?
8. Frequently asked questions

Why Plausible is blocked less often than Google Analytics

Ad blockers and browser privacy protections do more than block ads. They can also block known tracking domains, third-party scripts and requests that match tracking patterns. When a script does not load, the analytics tool cannot record the visit.

Google Analytics is specifically targeted by many of these protections because it is part of Google’s advertising and tracking ecosystem. Plausible does not use cookies or persistent identifiers, track people across websites or collect personal data, so it is much less likely to be blocked.

Firefox and Safari block Google Analytics by default, but not Plausible. At the time of writing, uBlock Origin’s own Privacy list contains specific Google Analytics rules but no plausible.io entry. That is not a guarantee that every uBlock Origin setup allows Plausible: visitors can enable other lists or custom rules, and DNS blockers, company firewalls and disabled JavaScript can all block analytics requests.

In one Plausible study, we compared Google Analytics and Plausible on a site that received a large amount of tech-savvy traffic from Hacker News and Reddit. Plausible was installed using a proxy to get the clearest view of total human traffic, while Google Analytics was installed normally.

The result: Google Analytics missed 58% of visitors in that audience.

That is an extreme case, because Hacker News and Reddit audiences are more likely to use ad blockers, privacy browsers and stricter browser settings than average visitors. But it shows the underlying problem clearly: if your audience uses privacy tools, Google Analytics can miss a large share of real traffic.

GA4 has the same structural issue. It is still Google Analytics, still integrates with Google’s ad ecosystem and is still commonly blocked. Plausible can still be blocked, but it cannot and should not override someone deliberately disabling JavaScript or blocking all measurement. For blockers that target a known analytics domain, proxying is the practical option.

How the Plausible proxy reduces ad blocker impact

A Plausible proxy lets you serve the Plausible script and send events through your own domain instead of plausible.io.

For a standard installation, the site-specific script URL looks like this:

https://plausible.io/js/pa-XXXXX.js

With a proxy, your site can load it through a first-party URL on your own domain, such as:

https://yourdomain.com/js/script.js

The exact script and event URLs depend on your proxy setup, but the principle is the same: the browser sees the analytics request as a first-party request from your own website, not as a request to a known analytics service.

This bypasses most blockers that target third-party tracking domains and known tracking URLs. It does not affect visitors who disable JavaScript or block your own domain.

Is using a proxy ethical?

Proxying changes how the request reaches Plausible, not what Plausible collects. It still does not build advertising audiences, identify individual visitors or use cookies. You can review the details in our data policy. Visitors who disable JavaScript or block your own domain can still avoid being counted.

Proxy options in Plausible

Choose the setup that fits your site:

• WordPress: enable the proxy in the official Plausible Analytics WordPress plugin.
• Developer-managed site: use the proxy documentation for Cloudflare, Netlify, Nginx, Vercel and other supported setups.
• Enterprise: use Managed Proxy, where you point a CNAME at our infrastructure and we handle the ongoing setup.

Why your own Plausible visit might not show up

One reason people ask “does Plausible get blocked by ad blockers?” is that they visit their own site and do not see themselves in Real-Time.

Before assuming an ad blocker is the cause, run Plausible’s integration verification tool. If it confirms that tracking works, the issue is usually specific to your own browser, account or network rather than your visitors’ traffic.

If you use the official WordPress plugin, logged-in administrator visits are excluded by default. You can enable the Administrator role in the plugin’s “Track analytics for user roles” setting when you need to test your own visits.

Otherwise, check your browser’s Network tab after reloading the page. Look for the Plausible script request, which starts with pa-, and the event request. A blocked request usually identifies the extension or policy responsible. Other common causes are an incorrect snippet or domain, a Content Security Policy, testing a staging site, network-level blocking or missing pageview tracking in a single-page app.

We have a full guide on checking whether your analytics setup is working correctly, plus a Plausible troubleshooting guide.

Why Plausible and GA4 numbers are often different

If Plausible shows more visitors than GA4, that is usually expected.

GA4 can be blocked, prevented from running after a consent decline, or use modeled data to fill gaps. Plausible does not need cookies or a consent banner from our side, and a proxy can reduce its remaining ad blocker gap. The tools also define visitors, sessions, bot traffic and attribution differently, so not every difference comes from blocking. In our bot-filtering test, GA4 counted simulated bot traffic that Plausible excluded. Read our guide on why analytics tools never show the same numbers.

Should you worry about ad blockers when using Plausible?

It depends on your audience and how precise you need the numbers to be.

If you run a general website, Plausible’s standard script is likely enough. You will already avoid the biggest accuracy problems that affect GA4: cookie consent gaps, heavier tracking, Google-specific blocking and privacy-hostile design.

If you run a site for developers, privacy-conscious users, open source communities, security professionals or other technical audiences, you should consider proxying Plausible. Those audiences use ad blockers and privacy tools at much higher rates.

If you make business decisions from small changes in conversion rate, traffic source performance or campaign ROI, proxying can also be worth it. A small amount of missing data can matter when you are optimizing at the margins.

Frequently asked questions

That is where PII comes in.

PII, or personally identifiable information, is any information that can identify a specific person either on its own or when combined with other data.

This guide explains what PII means, common examples to watch for and how to keep your analytics clean and privacy-friendly.

1. What PII means
   1. PII vs personal data
   2. Sensitive PII and special category data
2. Common PII examples
   1. In URLs
   2. In forms
   3. In user IDs
   4. In emails
   5. In search queries
3. What not to send to analytics
4. How Plausible avoids collecting personal data
5. How to redact URL identifiers with custom locations
6. A quick PII review checklist
7. Frequently asked questions

What PII means

PII stands for personally identifiable information.

The useful test is simple: could this value help you identify, single out or contact one specific person?

If the answer is yes, do not send it to your analytics tool.

Some information is directly identifying:

• Email address
• Full name
• Phone number
• Mailing address
• National ID number
• Payment details
• Medical, legal or financial details

Some information may become identifying when combined with other data:

• Internal user ID
• Customer ID
• Order ID
• Invoice ID
• Appointment ID
• Support ticket ID
• Exact location
• Search query that contains a name, email or phone number

Different privacy laws and internal policies may define personal data differently, so treat the examples in this article as a practical analytics hygiene guide rather than legal advice. When in doubt, collect less.

PII vs personal data

PII and personal data overlap a lot, which is why they often sound like the same thing. The difference is mostly about where the terms come from and how broadly they are used.

PII is commonly used in the US. NIST defines PII as information that can distinguish or trace someone’s identity, either alone or when combined with other linked or linkable information. In plain terms: can this data point identify or point back to a person?

Personal data is the term used by GDPR. The European Commission explains personal data as information that relates to an identified or identifiable living person. This can be broader in practice because it includes data that may not name someone directly, but can still relate back to them when combined with other information.

For example, jane@example.com is obviously both PII and personal data. A random-looking customer ID may not look personal on its own, but if your systems can connect it to one customer, it should be treated as personal data for analytics purposes too.

Sensitive PII and special category data

Some personal information needs extra care because misuse can create higher risk for the person involved.

In US-style PII language, this is often discussed as sensitive PII: information such as:

• government ID numbers
• financial account details
• medical records
• biometric data
• passwords
• other details that could lead to harm if exposed

Under GDPR and UK GDPR, some types of personal data are treated as special category data. The ICO lists these categories as data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, sex life and sexual orientation.

For analytics, the guidance is simple: do not send this type of data. For example, track:

Appointment request submitted
Resource downloaded
Application form submitted

Do not track:

Therapy appointment requested by Jane Smith
Diabetes guide downloaded by user_184291
Disability accommodation request from jane@example.com

Common PII examples

Here are common places where PII can accidentally leak into analytics, and safer ways to measure the same thing:

Let’s get deeper into the some of the most common places where personally identifiable information appears.

In URLs

URLs are one of the most common places where personal information accidentally reaches analytics tools.

This usually happens when a website puts user-specific identifiers in the path or query string:

/users/jane.smith@example.com
/profile/123456789
/customers/cus_7H3kL9
/orders/order_20493
/invoice/INV-2026-1044
/booking/appointment-88421
/reset-password?email=jane@example.com
/checkout?phone=15551234567

Even if a URL only contains an internal ID, it may still be sensitive. If that ID maps to a specific customer, account, order or person in your systems, sending it to analytics creates another place where linkable personal data is stored.

Query parameters need special attention. It is common for marketing, checkout, email and support tools to append parameters to URLs. Campaign parameters such as utm_source, utm_medium and utm_campaign are usually fine when used properly. Parameters such as email, name, phone, user_id, customer_id, token, session_id or address are not.

Plausible automatically discards query parameters from page URLs, except for campaign and referrer parameters used for attribution. You can read the full details in our data policy.

In forms

Forms collect the exact kind of information analytics should not store.

Avoid sending form field values such as:

• Email address
• Name
• Phone number
• Company address
• Billing address
• Free-text messages
• Passwords or password reset tokens
• Any health, financial, legal or employment details

This matters for any form where people can enter personal or sensitive information, including newsletter forms, signup forms, contact forms, checkout forms, quote request forms, application forms, surveys, support forms and search forms.

For analytics, you usually only need to know that a specific form was submitted, not what the person typed into it. In Plausible, that is enough to analyze form performance: total submissions, unique submissions, conversion rate, the top pages that drive submissions, referral sources, countries and devices.

To analyze one specific form, click on its URL in your dashboard to filter your stats by that form’s submissions. This gives you a complete overview of how that individual form performs without storing the submitted values.

For example, track:

Newsletter form submitted
Signup form submitted
Contact form submitted
Demo request form submitted
Checkout form submitted
Support form submitted

Do not track:

Signup form submitted by jane@example.com
Demo request from Jane Smith at Acme Corp
Checkout completed by customer_98431
Support request: "My phone number is 555-123-4567"

The first set tells you whether the form is working. The second set tells you who filled it out, which is exactly what analytics does not need to know.

In user IDs

User IDs can feel harmless because they are often internal strings rather than names or emails. But they can still identify people inside your system.

Avoid sending values like:

user_id=184291
customer_id=cus_93Hsk2
account_id=acct_58291
member_id=mem_77731
subscriber_id=sub_9340

If the value maps to one person, one account or one household in your database, treat it as personal data for analytics purposes.

This is especially important for product analytics, SaaS dashboards and logged-in areas. It can be tempting to send a user ID with every event so you can understand individual behavior later.

Track aggregate behavior instead:

Plan: free
Plan: business
Role: admin
Logged in: yes
Feature: reports

Those properties can be useful for understanding product usage without exposing the identity of a specific person.

If you use Plausible custom properties (same thing as custom dimensions in GA4), use them for broad, non-identifying labels and never for emails, names, user IDs or other identifiers. See the custom properties documentation for how to attach extra context safely.

In emails

Email addresses are direct identifiers. Do not put them in page URLs, event names, custom properties, referrers or search parameters.

Watch for patterns like:

/unsubscribe/jane@example.com
/newsletter/preferences?email=jane@example.com
/invite?recipient=jane@example.com
/account/jane@example.com

Email tools sometimes generate links with subscriber identifiers or email addresses in the URL. If those pages are tracked, the values may end up in analytics unless they are stripped, redacted or replaced before tracking.

A safer pattern is:

/unsubscribe
/newsletter/preferences
/invite
/account

You can still measure visits and conversions on these pages. You just do not need to store who the page was for.

In search queries

Search queries are easy to overlook because most searches are harmless. People search for things like “pricing”, “refund policy”, “analytics dashboard” or “integration docs”.

But search boxes also get used for personal information:

jane@example.com
Jane Smith
555-123-4567
order 20493
invoice INV-2026-1044
appointment for Jane Smith

If you track internal site search, avoid sending raw search terms when your users may search for people, customers, orders, tickets, invoices, email addresses or other sensitive records.

For public content sites, tracking popular search terms can be useful. For logged-in tools, CRMs, support systems, health portals, finance apps or admin dashboards, it is safer to track only that a search happened, or to categorize searches without storing the exact query.

What not to send to analytics

As a rule, do not send anything to analytics that identifies a person, account, household, transaction or private case.

Avoid sending:

• Email addresses, names, phone numbers and physical addresses
• User IDs, customer IDs, account IDs and membership IDs
• Order IDs, invoice IDs, booking IDs and ticket IDs
• Authentication tokens, password reset tokens and session IDs
• Payment details, coupon codes tied to one person or billing metadata
• Free-text form submissions
• Internal search queries that may include personal data
• IP addresses or full user agents as custom data
• Any health, legal, financial, employment or other sensitive information

The goal is not to make analytics useless. It is to measure the thing you actually need:

• A signup happened
• A file was downloaded
• A form was submitted
• A plan type converted
• A feature was used
• A campaign brought visitors
• A page performed well

You rarely need to know exactly which person did it inside your web analytics dashboard.

How Plausible avoids collecting personal data

Plausible is privacy-first by design. It is built for aggregate website analytics, not individual tracking.

We do not use cookies. We do not generate persistent identifiers. We do not track people across websites, devices or days. We do not store IP addresses. We discard full user agents after deriving limited browser, operating system and device information. All visitor data is processed and stored in the EU.

Plausible measures only essential website analytics data such as page URL, referrer, browser, operating system, device type and approximate location such as country, region and city (instead of precise coordinates). The goal is to show overall trends in your website traffic, not to build profiles of individual visitors.

You can read the full list of what Plausible collects, how unique visitors are counted without cookies and how data is handled in our data policy. For a broader overview, see our guide to privacy-focused web analytics.

That said, your implementation still matters. If your website puts personal data in page paths, event names or custom properties, you should redact it before it reaches analytics.

How to redact URL identifiers with custom locations

Sometimes your website needs user-specific URLs for the product to work:

/users/184291
/customers/cus_93Hsk2
/orders/order_20493
/invoices/INV-2026-1044

For analytics, those should usually be grouped into privacy-friendly paths:

/users/:id
/customers/:id
/orders/:id
/invoices/:id

In Plausible, you can do this by configuring a custom location before the pageview is sent. This lets you replace the actual URL with a clean, non-identifying version in your reports.

For example, instead of recording many separate pages like:

/profile/123
/profile/456
/profile/789

you can record them as:

/profile/:id

That improves privacy and makes your Pages report easier to read. Instead of fragmented rows for each person or record, you get one useful aggregate row.

Follow the setup steps in our custom locations documentation. This is the main tool to use when identifiers live in the URL path.

If the extra context you want to collect is not identifying, such as plan type, content author, logged-in status or button placement, use custom properties instead. Keep those values broad and non-personal.

A quick PII review checklist

Before sending a value to analytics, ask:

• Does this identify a person directly?
• Can our team link this ID back to a person, account, order or ticket?
• Could this field contain free-text personal information?
• Is this a token, session ID, password reset link or private URL?
• Can we replace it with a grouped path like /customers/:id or a broad label like plan=business?

If a value points to a person, remove it, replace it with a generic label or group it into a non-identifying pattern before it reaches analytics.

Good analytics should help you understand what works on your website without making your visitors identifiable. Measure the pattern, not the person.

Frequently asked questions

Sometimes a traffic spike means your content is gaining attention. A blog post may have been shared in the right community, a newsletter might have mentioned you, or a search query could suddenly be driving more visitors to your site.

But not all traffic spikes are worth celebrating. The increase could be caused by bot traffic, referral spam, internal visits, a broken campaign tag, search crawlers, or even a seasonal trend you overlooked.

Before you celebrate or panic, it’s important to understand where the traffic is coming from and what’s actually causing the spike.

1. Is it bot traffic?
   1. Check engagement metrics
   2. Check the locations
   3. Check for data center and spam patterns
   4. Next steps: What to do if it is non-human traffic?
      1. Are you a Plausible Analytics subscriber?
2. Check your traffic sources
   1. If the spike came from Direct
   2. If the spike came from Organic Search
   3. If the spike came from AI referrals
   4. If the spike came from Organic Social
   5. If the spike came from Referral
   6. If the spike came from a paid campaign
3. Check the pages report
   1. [Examples] How to read clues together
4. Check devices and browsers
5. Cross-check with other sources
6. Could it be an attack or abuse?
7. Check whether your team caused it
8. Monitor whether the spike repeats
9. So, what did the spike mean?
10. How much traffic spike is enough to investigate?
11. A traffic spike is a question, not an answer

Is it bot traffic?

This is usually the first thing to check because a spike caused by bots is not something you want to report as growth. There is no single dashboard clue that proves “this is definitely a bot”. But a few strong signals together can make the answer pretty clear.

Quick tip: Before starting your investigation, set the right time period in your analytics tool. For a sudden spike, Last 24 hours, Today and Yesterday are often more useful than a broad monthly view. In Plausible, you can also compare the spike period with the previous period, yesterday, or a custom range for a better comparison view.

Check engagement metrics

The instant tell-tale of bot traffic is that it does not behave like actual people. Bots often leave quickly, hit one page, do not scroll naturally and do not convert. So your engagement would look unnaturally low.

If you’re looking at your analytics dashboard right now, observe the engagement metrics like:

• Bounce rate (is it too high?)
• Visit duration (is it too low?)
• Views per visit (is it almost nil?)
• Scroll depth (is it too low?)
• Even goal conversions or other event triggers

So if your traffic spiked but visit duration collapsed, bounce rate shot up and conversions did not move, be skeptical.

That said, low engagement is not always bot traffic. Viral social traffic can also bounce quickly for instance. A short reference page can have low time on page because people got the answer and left. A landing page built for one action may not create many pageviews per visit.

So the useful question is: does this spike traffic behave differently from the same source, page or audience during normal periods?

This is why you should start isolating the increased traffic by segmenting your dashboard by the exact traffic source, location, page, and/or browser that the spike is coming from.

Using Plausible? Click a country/city, source/channel, page or any other report entries to filter the full dashboard by that segment.

Check the locations

Open your Locations report and look for regions that do not match your normal audience.

For example, unusual traffic spikes from places such as Ashburn or Council Bluffs almost always means that visits are coming from data centers rather than real users.

That does not mean every visit from these places is fake, and it does not mean every unexpected location is suspicious. It just means you should keep looking for supporting evidence.

Unexpected locations can have very normal explanations too. For example:

• Your website URL may have ended up in a local forum or community.
• Your customers’ customers may be reaching out to you instead of your customer because of some confusion. (For example, an agency’s client may click your analytics link thinking you provide support for that agency’s site.)
• A blog article may be ranking internationally because the topic is universal.
• A newsletter or social post may have reached a new country you do not normally get traffic from.

P.S. If a country is genuinely irrelevant to your site and keeps polluting your stats, you can exclude countries from your stats in most analytics tools (here’s how to do it in Plausible). But treat that as cleanup after you have understood what is happening, not as the first move.

Check for data center and spam patterns

Some spikes can come from scrapers, uptime monitors, vulnerability scanners, AI crawlers, spam bots, click farms or automated tools. Common warning signs include:

• A sudden spike with no matching campaign, launch, press mention or seasonal reason
• Very low visit duration
• Very high bounce rate
• No conversions or meaningful events
• Traffic concentrated in odd locations or data center-heavy areas
• Unusual spike from a specific browser. For example, we recently noticed any and all unnatural traffic queries coming from Chromium browsers.
• A strange referral domain
• A large Direct traffic spike with no brand or campaign explanation
• Many visits to random, old or sensitive-looking paths

If you suspect non-human traffic, compare your analytics with server logs, CDN logs or hosting metrics if you have access. If the traffic caused server load, involve your engineering team. If it only polluted reporting, exclude the spike from your analysis and check whether your analytics setup can filter the obvious spam source.

Next steps: What to do if it is non-human traffic?

At this point, if you are reasonably sure that the spike was not from real visitors, you have two jobs:

• keep the traffic from misleading your analytics,
• and understand whether there is anything deeper to fix.

First, keep that traffic out of your analysis. Do not use it to judge campaign performance, conversion rates, content performance or business growth. If your analytics tool allows it, filter or exclude the affected traffic by source, country, IP address, hostname, page path or any other clear pattern you identified.

Next, check whether your analytics provider can help. Some tools can remove obvious spam traffic, improve their filters, or guide you toward the right exclusion settings.

If support is not available, look for product-specific documentation or community discussions. Bot and spam traffic issues are common, so there is often a known workaround for a specific pattern.

If you use GA4, for example, you may need to handle some of this manually using comparisons, explorations, unwanted referrals, internal traffic rules, data filters, or custom reports depending on what caused the spike.

The exact fix depends on whether the traffic came from a spam referrer, an internal source, a suspicious location, a campaign tagging issue, or a page-specific pattern.

Finally, investigate why the spike happened. If it was only analytics spam, cleanup may be enough. But if the traffic hit login pages, signup forms, checkout flows, API routes, admin-looking URLs or caused server load, treat it as a possible abuse or security issue. In that case, involve the appropriate team and treat it as an urgent issue.

Are you a Plausible Analytics subscriber?

Plausible filters a large amount of bot and spam traffic automatically.

We block known crawlers based on their User-Agent, exclude traffic from many data center IP ranges, filter referrer spam, and apply additional checks to detect non-human traffic patterns.

Because of this filtering, Plausible typically records far fewer pageviews than raw server logs, which count every request including bots and automated scans. In one test we ran, server logs recorded about 18× more pageviews for the same site due to bot traffic.

In another test we ran, we saw how Plausible successfully blocked bot traffic while GA couldn’t.

That said, no analytics system can block every bot. Some sophisticated bots try to mimic real browsers and may occasionally appear in analytics data. We continuously improve our filtering to reduce this.

If you identify traffic you’d like to exclude, you can also filter it manually by IP address, country, page, or hostname. If you are convinced unnatural traffic has made it to your Plausible dashboard, feel free to contact us and we’ll take a look.

Check your traffic sources

Once bot traffic is less likely, the next question is: where did the spike come from?

In Plausible, you can start with Channels and drill into Sources and Campaigns (Or start with Sources or Campaigns directly). If you use GA4, start from the traffic acquisition report.

The main thing to look for is whether all traffic rose together, or whether one source caused the spike.

Depending on your site, the spike could come from Direct, Organic Search, AI referrals, Organic Social, Referral, Email, Paid, Affiliates or any other channel. The investigation logic is the same: isolate the source, check the pages it landed on, and compare engagement with your usual baseline. Our guide to checking your own website traffic accurately explains how to read these reports together during a normal traffic review.

This goes hand in hand with the pages report (explained in the next section): sources tell you where people came from, pages tell you what they came for.

Here’s what that would look like in the Plausible dashboard:

If you filter the dashboard by a source, compare that filtered view with yesterday, the previous period or a custom period too. That helps you confirm whether this source is truly spiking or just following its usual pattern.

If the answer is obvious at this stage, you may not need to keep digging. For example, if you launched a newsletter at 10 AM and Email traffic spiked at 10:05 AM with normal engagement, that is probably your answer. Note it down, compare the outcome with your expectations, and you can move on.

Here is what spikes from different sources mean.

If the spike came from Direct

A “Direct/none” traffic spike can mean several things.

It could be good: more people are typing your URL, using bookmarks, searching your brand and clicking through, or sharing your link in private places such as Slack, Discord, WhatsApp, email or newsletters. This is often called dark traffic because the original source is not passed along.

It could also mean attribution got messy. Maybe a campaign link was shared without UTM parameters, a redirect stripped the referrer, or a newsletter tool did not pass source information correctly.

If the spike is Direct, has weak engagement, comes from odd locations and does not convert, it was probably bots.

If the spike came from Organic Search

An organic search spike can happen because a page jumped in rankings, Google started showing it for new queries (especially if they’re trending), a topic became more popular, or your content appeared in a search feature.

If Organic Search is responsible, check whether the spike came from:

• One page (or a group of similar intent pages)
• One query (or a group of similar intent queries)
• One location
• A wider increase across many pages

In Plausible, you can use the Google Search Console integration to see search terms inside your dashboard. You can also open Search Console directly and compare clicks, impressions, average position and CTR for the spike period.

Google’s guidance for debugging search traffic changes recommends looking at the Search Console performance report, comparing date ranges, separating search types and checking whether the change is limited to specific pages, queries, countries or devices.

If the spike came from AI referrals

AI tools such as ChatGPT, Perplexity, Claude and others are now real referral sources.

They may not send traffic at Google scale, but they can cause visible spikes every now and then, when an answer cites your page, when a topic starts trending in AI chats, or when an AI tool changes something about its working.

We have seen this ourselves at Plausible. For instance, we noticed an increase in ChatGPT traffic after ChatGPT made inline clickable referrals more visible. Earlier too, we saw a ~2,200% surge in AI referral traffic from sources such as ChatGPT, Perplexity, Claude and Phind.

If AI referrals caused the spike, check:

• Which AI source sent the traffic
• Which entry pages/landing pages received it
• Whether the pages answer broad, citation-worthy questions
• Whether the visitors behave like qualified traffic or quick curiosity clicks
• Whether the spike matches a public discussion or trend in your niche

This kind of traffic can be volatile. A page may be cited one week and disappear from answers the next. So treat AI referral spikes as a useful discovery signal, but judge AI traffic by its engagement and conversions, not the spike alone.

If the spike came from Organic Social

If the spike came from social, click into the exact source.

This may be a post on LinkedIn, X, Reddit, HackerNews, Mastodon, Bluesky or another community. A social spike can be valuable, but it is often short-lived. The question is not only “how many people came?” but “did the right people come?”

Look at engagement and conversions. If a social post sends thousands of visitors who bounce quickly and never sign up, it may be a nice awareness moment but not necessarily a business win. If it sends fewer visitors but they spend time, read more pages or convert, that is a stronger signal.

If you can identify the exact post, you can stop the source investigation here and move to understanding the outcome.

For example, if LinkedIn caused the spike, search LinkedIn for your brand, domain or the landing page URL. Maybe someone tagged you in a post, maybe they did not. Either way, once you find the post, check what people were reacting to, whether the comments reveal confusion or interest, and whether the traffic converted.

If you cannot find the post, check the pages report next. The entry page often tells you what the social conversation was probably about.

If the spike came from Referral

If the spike came from a specific referring site, it usually means your link was shared, cited, listed or discussed somewhere there.

Sometimes this is easy to trace. The referring URL may include the exact thread, article, newsletter archive, directory page or documentation page.

You can click into the source, check Referrer URLs if available, search that site for your domain, or search the web for your URL and the date of the spike.

Sometimes you will not be able to find the exact mention. That is okay. You do not always need the exact post.

If you can confirm that the source is real, the traffic is relevant, and the visitors behaved positively, you can stop here and move to understanding the outcome.

If the source is clear but the reason is not, pair it with the pages report. A homepage spike usually means a broader brand mention, while a feature page, docs page or blog post spike points to a more specific conversation.

If you do find the exact mention, read the context. Are people recommending you? Complaining about you? Comparing you with an alternative? Confused about a feature?

That context tells you whether to join the conversation, update the page, add better internal links, or simply save the source and date so you can compare future spikes.

If the spike came from a paid campaign

If a paid channel spiked, first confirm that you expected it.

Did someone increase budget? Launch a new campaign? Change targeting? Turn on a new placement? Forget to pause something?

Then check conversions and cost, not only visits.

A paid traffic spike without conversions is not a win. It may mean the campaign is reaching the wrong audience, a landing page is mismatched, the tracking is broken, or low-quality clicks are getting through.

Check the pages report

Check the pages that got the spike.

In Plausible, use the Top Pages or Entry Pages report (understand more about them here). Entry Pages are especially useful because they show where people started their visit.

This is the other half of the sources investigation: where did they land?

Ask:

• Did one page cause the spike?
• Did a group of related pages cause it?
• Did the homepage or pricing page suddenly get more visits?
• Did logged-in app pages spike instead of marketing pages?
• Did random old pages receive unusual traffic?

The answer changes your next step.

If one blog post spiked, look for where it was shared and what audience it reached. If a product or pricing page spiked, check campaigns, mentions, brand search and conversions. If many random pages spiked at the same time, especially with poor engagement, you may be looking at bots, crawlers or scraping.

This can also be a good place to stop. If the source was LinkedIn and the entry page was your homepage, the likely story may simply be that someone mentioned your brand. If the source was LinkedIn and the entry page was a specific feature page, investigate whether someone discussed that feature.

Similarly, if the source was Reddit and only one blog post spiked, look for that article in relevant subreddits and check whether the discussion explains the traffic.

This is also where you can separate a happy spike from a hollow one. For example, imagine your blog post gets picked up by a big newsletter and sends 10,000 visitors in a day, that is exciting.

Now imagine a smaller spike of 1,000 visitors to a comparison page, and trial signups also increase. That smaller spike may be more valuable to you.

[Examples] How to read clues together

Here are a few simple ways to read your traffic source + page clues together:

• Email + pricing page spike: likely a newsletter, lifecycle email or sales campaign worked. Check conversions and replies.
• Organic Search + old article spike: likely a topic started trending again or Google began ranking the page for a new query. Check Search Console.
• Referral + docs page spike: likely a developer community, GitHub issue, integration guide or support thread linked to your docs.
• Paid Search + low conversions: likely targeting, keyword intent or landing page mismatch. Check spend before celebrating the visits.
• Mobile + landing page spike: likely social or newsletter traffic opened mostly on phones. Check mobile conversion rate and page experience.
• Signup page spike + failed signups: likely fake accounts, abuse or a broken signup flow. Check product and auth logs.

Check devices and browsers

Device and browser reports are useful when the spike is real but still needs explanation.

If traffic rose mostly on mobile, check whether the source was mobile-heavy, like social, and whether the landing page works well on phones. If one browser, OS or device type suddenly dominates the spike, check whether that matches the source or points to something suspicious.

If conversions dropped during the spike, segment by device too. You may discover that the extra traffic was real, but the experience was poor on the device most visitors used.

Cross-check with other sources

Once you have a likely explanation, check whether another tool supports it.

You do not need five tools to investigate every traffic spike, but cross-checking is useful when:

• The spike is large enough to affect reporting.
• The spike is suspicious.
• The spike is tied to SEO or paid performance.
• The spike caused operational issues.
• You are about to make a decision based on it.

For organic search spikes, check Google Search Console. See whether clicks, impressions, queries and pages moved in the same direction as your analytics.

For SEO-related spikes, an SEO tool such as Semrush can help you check keyword movements, ranking changes, backlinks, new SERP features or competitor movement.

For suspicious spikes, check server logs, CDN logs, firewall logs or hosting analytics. These can help you spot crawlers, repeated requests, unusual user agents, data center traffic or pages being hit in a pattern that does not look human.

For campaign spikes, check the source platform too. If a newsletter tool says 400 clicks but your analytics says 8,000 visits, something is off. If an ad platform says spend doubled and your analytics says paid traffic doubled too, that part of the story at least lines up.

Could it be an attack or abuse?

This is different from normal bot traffic.

Some automated traffic is just noise in your analytics. But some spikes can be caused by scraping, vulnerability scans, credential stuffing, spam form submissions, fake signups, checkout abuse or a DDoS-style flood. This is especially common for developer tools, SaaS products, open-source projects and sites with login pages, docs, APIs or public forms.

You may not be able to confirm this from your web analytics dashboard alone. Analytics tools usually show the browser-level visit, not every request that hits your infrastructure.

Look for clues such as:

• A spike in visits to login, signup, password reset, docs, API or admin-looking pages.
• Many hits to strange paths that normal visitors would not open.
• A sudden rise in 404s, 403s, 429s or 500s in server logs.
• Higher server load, bandwidth, CPU usage or CDN traffic.
• Repeated requests from the same IP ranges, hosting providers or data centers.
• A spike in failed logins, fake accounts, spam submissions or suspicious checkout attempts.
• Support messages from users saying the site is slow or unavailable.

If any of this lines up with the traffic spike, get your engineering or hosting team involved. Check server logs, CDN/firewall logs, rate limits, WAF rules and authentication logs. In that case, the priority is not understanding whether the traffic converted. The priority is protecting the site and keeping the data from being mistaken for real demand.

Check whether your team caused it

Not every unexplained spike comes from the outside world. Sometimes the source is internal:

• A paid campaign was launched or changed.
• A new integration, script or monitoring tool started pinging pages.
• A staging, app or admin route began being tracked.
• A product change sent logged-in users through a tracked page more often.
• A QA or automation tool visited the site repeatedly.
• A redirect or tagging change moved traffic into the wrong channel.

This is especially important if the spike appears in app pages, checkout pages, internal dashboards or other URLs that normal marketing traffic would not usually hit.

Ask around before drawing conclusions. A two-minute message in the marketing, product or engineering channel can save an hour of analytics detective work.

Monitor whether the spike repeats

One-day spikes are common. Repeating spikes are a trend.

Check whether the traffic spike happens:

• Every weekday
• Every weekend
• Every Tuesday morning
• At the same hour each day
• Around every newsletter send
• Around every deploy
• Around every billing cycle
• During a known seasonal window

Recurring patterns are usually easier to explain once you know what schedule they match.

If the spike happens every time your newsletter goes out, you have a distribution signal. If it happens every time a crawler runs, you have an automation signal. If it happens only during a holiday shopping period, you may have a seasonal signal.

So, what did the spike mean?

By now, your spike should fall into one of these buckets:

• Noise: bot traffic, spam, broken tracking or abuse. Exclude it from analysis and fix the source if needed.
• Expected traffic: a newsletter, launch, campaign or seasonal pattern. Compare it with your expectations.
• Real opportunity: a mention, ranking change, AI citation or community discussion that brought relevant visitors. Save the source and learn from it.
• Low-quality attention: real people, but not the right people. Note it, but do not overvalue it.

How much traffic spike is enough to investigate?

There is no universal threshold.

It depends on your usual traffic level, business model, and how much the spike could affect decisions.

A small personal blog can reasonably investigate a jump from 100 to 500 visitors because that may reveal a new audience. A large SaaS site may ignore a 2% daily increase unless it affects signups, revenue, support volume or infrastructure.

As a rough rule, investigate when:

• The spike is clearly outside your normal range.
• The spike affects a business-critical page or channel.
• The spike changes conversion numbers.
• The spike causes server load or operational issues.
• The spike is being used in reporting or decision-making.
• The spike has suspicious quality signals.

If the spike is small, explainable and has no business impact, you do not need to turn it into a forensic exercise.

A traffic spike is a question, not an answer

Here’s a visualization of the practical process that you can save for your reference:

If you want an easier way to notice unusual traffic without babysitting your dashboard, you can set traffic spike notifications in Plausible, the simpler and privacy-friendly alternative to Google Analytics. You will get alerted when current visitors cross your chosen threshold, along with the top sources and pages causing the spike.

And if you’re dealing with the opposite problem, we also have a guide on how to investigate a drop in website traffic.

Someone may first find a blog post from Google, visit your homepage, check the pricing page, read the docs, and then sign up. Someone else may land directly on a product page, click through to a comparison page, and contact sales in the same visit.

It is a practical subset of customer journey analytics (that often joins CRM, support, email, ads and offline touchpoints) for website teams.

1. What is website journey analytics?
2. How user journeys compare to other analytics methods
   1. Customer journey analytics
   2. User journey mapping
   3. Funnels
3. What you can learn from visitor paths
   1. See what visitors do after landing on key pages
   2. Work backwards from conversions
   3. Understand drop-offs
   4. Compare journeys by traffic source, campaign, device or country
   5. Examples by website type
4. How to track user journeys on your website
   1. How Plausible User Journeys works
5. GA4 Path Exploration vs Plausible User Journeys
6. Bringing it all together

What is website journey analytics?

Website journey analytics is the process of analyzing the sequence of pages and events visitors go through on your website.

It helps you answer questions like:

• Where do people go after landing on the homepage?
• Which pages do visitors view before signing up?
• What path leads people from a blog post to the pricing page?
• Do visitors from a specific campaign behave differently from organic search visitors?
• Where do visitors drop off after viewing a key page?
• What happened before a form submission, trial signup or purchase?

and so on. Even if you don’t have any questions beforehand, you can do open-ended exploration to discover new paths and behaviors.

In other words, it gives you the context around your website traffic.

How user journeys compare to other analytics methods

There are a few similar-sounding concepts in this area. The difference is mostly about scope and intent.

Customer journey analytics

Customer journey analytics usually looks across many touchpoints: ads, email, CRM, sales, support, product usage and website visits. Plausible User Journeys focuses only on the paths visitors take on your website.

For example, it can show what visitors did after landing on your pricing page, but it will not combine that with sales calls or support tickets.

User journey mapping

A user journey map is a visual artifact a team creates to understand an experience. User Journeys is based on live website behavior: the pages and events visitors actually move through.

For example, a journey map may show the expected path from homepage to signup, while User Journeys may reveal that many visitors go through a blog post, docs or comparison page first.

Funnels

Funnels are for measuring a path you already know and seeing drop-off between steps. User Journeys is for discovering paths you did not know to measure, or working backwards from a conversion.

For example, use a funnel to measure Homepage -> Pricing -> Signup. Use User Journeys when you want to see which pages people visited before signing up.

What you can learn from visitor paths

Here are some useful ways:

See what visitors do after landing on key pages

Your homepage, pricing page, comparison pages, docs, feature pages and top blog posts are not just individual pages but starting points.

Journey data helps you see what visitors do after those pages.

For example:

• Do homepage visitors go to pricing, docs, product pages or blog posts?
• Do pricing page visitors continue to signup or leave?
• Do blog visitors explore the product or only read and exit?
• Do docs visitors go back into the app, contact support, or stop there?

This is helpful for improving page structure and internal linking. If visitors are not taking the next step you expected, the page may need clearer calls-to-action, better navigation, or more relevant links.

Work backwards from conversions

Conversion path analysis is the other side of the same question.

Instead of starting from a page and asking “what happened next?”, you start from a goal and ask “what happened before?”

For example:

• Which pages did visitors view before signing up?
• Which blog posts or docs pages appeared before a trial activation?
• Did people visit the pricing page before contacting sales?
• Which pages led to a purchase?

This is especially useful for content marketing and SEO. A blog post may not directly convert many visitors on the first pageview, but it may still appear in journeys that eventually lead to signup or purchase.

Without journey data, that content can look less valuable than it is.

Understand drop-offs

Not every visitor will continue to another page or trigger an event. That is normal.

But when many visitors stop after a key page, it is worth investigating.

For example:

• Visitors reach the pricing page but do not continue to signup
• Visitors open docs but do not return to the product
• Visitors hit a 404 page and leave immediately
• Visitors from a paid campaign land on a page and take no further action

In Plausible User Journeys, for instance, this is shown as “No further action” at each step. It helps you see where visitors stopped moving through the tracked journey.

No further action is not always bad. Someone may leave after getting exactly what they needed. But if the page is supposed to lead to a conversion, a large drop-off can be a useful signal.

Compare journeys by traffic source, campaign, device or country

The same page can perform differently for different audiences.

Visitors from Google search may read more content before converting. Visitors from paid campaigns may go straight to pricing. Mobile visitors may drop off earlier than desktop visitors. Visitors from a certain country may prefer different pages or product information.

This is why journey analysis becomes more useful when combined with filters and segments.

For example, you can compare:

• Organic search journeys vs paid campaign journeys
• Mobile journeys vs desktop journeys
• US visitors vs UK visitors
• Newsletter visitors vs social media visitors
• Visitors from a specific UTM campaign

This helps you avoid treating all traffic as one big average.

Examples by website type

Different teams can use the same journey data in different ways:

• SaaS teams can work backwards from a signup or trial goal to see which comparison, pricing, docs or feature pages visitors viewed before converting. If those pages keep appearing in conversion paths, they may deserve clearer CTAs, stronger internal links and regular updates.
• Content and SEO teams can start from a top blog post and see what visitors do next. If most visitors take no further action, the post may need better product links or a stronger next step. If visitors continue to a related feature page, the topic may be attracting qualified traffic.
• Ecommerce stores can work backwards from purchases to see which product, category or campaign pages appeared before checkout. They can also compare paid and organic journeys, or check where mobile visitors drop off.
• Agencies can make client reports more concrete by showing how visitor paths changed: more visitors reaching pricing from SEO pages, a campaign driving traffic but no further action, or a refreshed page sending more visitors toward conversion.

How to track user journeys on your website

If you want a simple and privacy-friendly way to track user journeys on your website, Plausible User Journeys is built for this.

It lets you explore the actual paths visitors take through your site without extra setup, cookies or personal profiles. You just pick a page or goal and see what visitors did next. Or you can start from a conversion goal and work backwards to see what led visitors there.

You can see it in action right now, on our own public analytics dashboard, by scrolling down to the “Explore” tab.

How Plausible User Journeys works

User Journeys is available in the Explore tab alongside Goals, Properties and Funnels. It works with the pages and events already in your dashboard and you don’t need to work with code or even turn on any settings. It’s always there in your single-page dashboard.

You can explore journeys in two directions:

• Starting point: Begin with a page or event and see what visitors did next.
• End point: Begin with a conversion goal and work backwards to see what led visitors there.

For example, you can select a signup goal as the end point and see which pages and events visitors went through before reaching it.

In Plausible, goals can be pageviews such as a thank-you page (codeless setup), custom events such as a signup button click, or optional measurements (plug-and-play) such as form submissions, outbound link clicks, file downloads.

Each column shows one step in the path. Click any entry to keep exploring, and Plausible will load the next step. You can go up to 20 steps, and the conversion rate updates as you build the selected journey.

You’ll also find grouped pages from the same directory to reduce noise. For example, individual blog posts might be grouped under /blog, and documentation pages under /docs. This makes it easier to see section-level patterns instead of getting lost in hundreds of individual URLs, while you can still do individual URL analysis if needed.

Dashboard filters also apply to User Journeys. So you can narrow paths by:

• Traffic source
• Campaign
• Country
• Device
• Landing page
• Any other available dashboard dimension

This helps you compare how different audiences move through your site. For example, you can check whether visitors from a paid campaign go from the landing page to signup, whether mobile visitors drop off earlier than desktop visitors, or whether visitors from a specific country take a different path through your docs or pricing pages.

GA4 Path Exploration vs Plausible User Journeys

Google Analytics 4 has a Path Exploration report. It is powerful, but it lives inside GA4’s Explorations area (custom reporting), which means you need to configure dimensions, node types, segments and events before getting to the answer.

That may be fine for data scientists. But for many website teams, it’s overly complicated and time-consuming.

You’d usually even be missing about half your data with Google Analytics, because its script is commonly blocked by ad blockers and majority of visitors decline consent banners.

If you just want simple and effective answers to questions like:

• What did visitors do after viewing this page?
• What happened before this conversion?
• Where did people stop?
• Does this source or campaign follow a different path?

then Plausible User Journeys is built into the same dashboard where you already analyze pages, sources, goals, funnels, devices and locations.

Bringing it all together

Journey analysis helps you move from isolated metrics to real behavior.

You can still look at pageviews, sources, bounce rate, visit duration and goals. But when you add journeys, you see how those pieces connect.

You can understand where visitors start, what they do next, what happens before conversions, and where they take no further action.

If you want to explore the paths visitors take on your site, open the Explore tab in Plausible and try User Journeys.

We didn’t launch a new feature. We didn’t run any paid ads. We didn’t get a viral blog post or a lucky mention on Hacker News. What happened was much less dramatic than that. In late January, we spent a few days editing our homepage.

We moved some sections around, cut some text and changed the button labels. We expected it to help a little but we didn’t expect it to have this kind of impact.

Here’s what we changed and what the data showed.

What was wrong with our homepage

Our homepage had been roughly the same for a long time. It was working well enough. We were growing steadily with it. But when we looked at it with fresh eyes in January, we realized we were making visitors work too hard to understand what Plausible does.

The homepage still matters a lot for us. From January through April, it was the biggest entry point for non-logged-in visitors, accounting for roughly 43% of entrances. So even small improvements there can affect a large part of the signup journey.

The page opened with our hero section and a screenshot of the dashboard. That part was fine. But right after that, visitors landed on a wall of text. Six subsections of long-form prose about our features, our philosophy, our approach to team sharing and enterprise plans. Hundreds of words before you reached the scannable feature grid.

The feature grid, the part where you can quickly see what Plausible actually does, was buried below all that text. Then came testimonials, then pricing.

If you wanted to quickly figure out whether Plausible was worth trying, you had to scroll through an essay first. That’s not how people browse the web. People scan. They jump around and make snap judgments.

We also looked at our call-to-action buttons. They said “Get started” and “Live demo.” Generic and vague.

The changes we made

Most of the changes were live by the end of January, with a few smaller edits following in early February. You can see them all in our website repo. None of them involved a designer, a new layout or any visual changes. The colors, fonts, images and components are the same as before.

Here’s what we did:

Flipped the page structure

This was the biggest change. We moved the feature grid up so it appears right after the hero section, before any long-form text.

The old order was: hero, long prose (six sections), feature grid, testimonials, pricing.

The new order is: hero, feature grid, testimonials, shorter prose (three sections), pricing.

Now a visitor can scan our eight key features within seconds of scrolling down. No reading required to understand what we do.

Changed the CTA wording

“Get started” became “Start free trial.” “Live demo” became “View live demo.”

“Get started” is probably the most overused button label on the web. It tells you nothing about what happens when you click. Will it cost money? Is this a demo, a signup or a purchase? “Start free trial” answers the important part: this is a trial, not a commitment.

It looked like a tiny copy change, but it changed what the button promised.

Cut the prose in half

The old page had six subsections of text: simple analytics, lightweight script, privacy and GDPR, goals and revenue tracking, team sharing and dashboard sharing, and a smooth transition from Google Analytics. Plus a paragraph about enterprise plans.

We cut it down to three: simple analytics, lightweight script and privacy. These are our strongest differentiators and the things people care about most when evaluating Plausible as their Google Analytics alternative.

We didn’t remove all the prose. Plausible is not just a list of features, and we still want the homepage to explain why we exist. Our philosophy around privacy, simplicity and independence is a big part of what has kept us differentiated in the analytics market.

The change was not to hide that story. It was to stop making every visitor read it before they could quickly understand the product.

The removed sections were either already covered by the feature grid above or only relevant to a small subset of visitors. Less text between understanding the product and seeing the pricing means fewer opportunities to lose people.

Refreshed the testimonials

Our testimonials section used to show a Twitter icon next to each person with their Twitter handle as the identifier. Twitter had changed, and the icon made the section feel dated.

We removed the icon and replaced the handles with people’s real titles and companies. So “@dhh” became “Co-founder and CTO at 37signals” and “@JohnONolan” became “Founder and CEO at Ghost.” When someone scrolling through testimonials sees the company and role rather than a social handle, it’s immediately more credible and easier to relate to.

We also added a new testimonial from Clem Delangue, co-founder and CEO at Hugging Face.

What happened next

We didn’t run an A/B test, so this is not a clean experiment. We can’t prove that every part of the lift came from the homepage changes. But the timing, the size of the increase and the lack of a traffic spike made the change hard to ignore.

Despite being the shortest month of the year and having fewer visitors than January, February set a new all-time record for trial signups. Then March broke that record. Then April broke it again.

Looking only at non-logged-in visitors, trial signups increased 84% from January to April, while traffic increased by only about 2%.

February, March and April were three consecutive all-time records for trial signups in Plausible’s history.

The register page converted better too. More people who reached it completed a trial signup, and the broader visitor-to-trial rate rose from 2.65% in January to 4.80% in April.

The more specific button wording may have helped here. “Start free trial” likely set clearer expectations before people clicked, so visitors who reached the register page were more likely to understand exactly what they were doing.

The paid customer data followed with the usual delay from our 30-day trial. February was also a new record month for paying subscribers, though that month still included many people who had started trials before the homepage changes. March and April were the cleaner signal:

• February: 652 new paying subscribers
• March: 953
• April: 1,156

By April, a much larger share of new paying customers had entered through the updated homepage experience.

And this happened while churn stayed broadly stable. We weren’t just attracting more people, we were still attracting the right people.

The revenue data told the same story. April was our best month ever for new MRR and new customers, while net new MRR was our third best month ever. This wasn’t existing customers expanding more than usual. The main change was that more new people started a trial and became paying customers.

The website traffic and trial signup numbers are visible to anyone in our live demo.

What we take from this

It reminds us of what we learned in the early days of Plausible. When we repositioned our homepage back in April 2020 to clearly explain what we do and how we compare to Google Analytics, that change in communication was what started our growth. The lesson then was the same as the lesson now: be obvious, be clear and don’t make people work to understand what you’re about.

If you’re running a company and haven’t taken a fresh look at your homepage in a while, it might be worth spending a few days on it. Not necessarily a redesign. Just look at the order of information, the words on your buttons and whether there’s text that could be cut without losing anything meaningful.

In hindsight, some of these changes feel obvious. But they weren’t obvious to us while we were deep in the product every day.

Part of what happened is probably inevitable for any product that survives long enough. Over time, you accumulate communication debt.

A new feature launches so you add a section about it. Enterprise customers ask questions so you add clarification copy. You enter a new market so you add messaging for a new audience. Each change makes sense in isolation.

For us, that meant adding more detail about team sharing, dashboard sharing, goals, revenue tracking, enterprise plans and the transition from Google Analytics. All useful things to explain somewhere. But over time, the homepage became the place where too many of those explanations lived.

After years of layering additions on top of additions, our homepage had slowly drifted away from its original purpose. It had become a collection of everything we wanted to say rather than the few things a visitor actually needed to understand.

Our homepage had been “good enough” for years. It had helped us reach more than 15,000 paying subscribers, so it didn’t feel broken. Nothing on the page was individually wrong. Almost every section had been added for a good reason. But together they created friction.

That’s probably true for a lot of mature products and companies. Complexity rarely arrives all at once. It accumulates a paragraph at a time.