Plausible Analytics

How to check your own website traffic accurately

2026-07-28T12:00:00+00:00

Checking your website traffic can sound like a matter of finding one number. In practice, it starts with a more useful question: are people finding the site, and what happens when they do?

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

Add your website to the analytics tool.
Copy the tracking snippet or select the relevant integration.
Add it to your website, either directly or through your content management system, framework or tag manager.
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.

Metric	What it tells you	Simple example
Visitors	How many distinct people or devices visited during the selected period	One person visits twice: one visitor
Visits or sessions	How many separate browsing sessions happened	The same person returns later: two visits
Pageviews	How many pages were loaded	They view three pages in each visit: six pageviews

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?

“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:

Confirm the timing. Find the day or hour the change began and compare it with a normal period.
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.
Separate visitors, visits and pageviews. If only pageviews changed, navigation or duplicate tracking may be responsible. If all three moved, the audience probably changed.
Find the affected segment. Is the change sitewide or concentrated in one source, campaign, page, country, device or browser?
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.
Match the dates to real events. Check launches, newsletters, ad budgets, press coverage, social posts, outages, holidays and seasonal demand.
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.

First-party analytics	Competitor traffic estimate
Collected from real activity on a site you control	Modeled from sources available to the provider
Can show pages, campaigns, events and conversions recorded on your site	May show estimated search traffic or modeled traffic across several channels
Useful for operating and improving your own website	Useful for rough benchmarking and discovering competitors
Affected by your setup, consent approach, bot filtering and blocked scripts	Affected by the provider’s data coverage and model; smaller sites can have sparse or volatile estimates

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:

Set the last seven days and compare with the previous seven days.
Check visitors, visits and pageviews for unusual movement.
Review sources and campaigns to see what caused the change.
Review entry pages to see where acquisition grew or declined.
Check conversions and conversion rate to judge traffic quality.
Investigate only the segments that changed materially.
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.

EU-hosted analytics isn’t the same as EU-owned analytics

2026-07-09T10:50:55+00:00

More analytics tools now advertise “EU hosting”, “EU data residency” or an “EU region”. That sounds reassuring, especially if you’re choosing an analytics tool for privacy or GDPR reasons.

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.

What EU-hosted usually means
What EU-owned adds
How this helps you decide
Why this became a bigger issue after Schrems II
Examples from analytics tools
What Plausible means by EU-owned analytics
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:

Layer	What it tells you	What it does not tell you
EU-hosted	The data is stored or processed in a European data center	Who owns the company or infrastructure
EU-operated	The service is provided by an EU or EEA legal entity	Whether all infrastructure and subprocessors are European
EU-owned infrastructure	The servers or cloud infrastructure are owned by European companies	Whether the analytics product itself is privacy-friendly

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?

Do ad blockers block Plausible Analytics?

2026-06-26T09:00:00+00:00

Short answer: Plausible can be blocked, but far less often than other privacy-invasive tools such as Google Analytics. And if missing visits from blockers matter for your site, you can proxy Plausible through your own domain to bypass most of the remaining blocks and get more accurate stats.

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.

Why Plausible is blocked less often than Google Analytics
How the Plausible proxy reduces ad blocker impact
Is using a proxy ethical?
Proxy options in Plausible
Why your own Plausible visit might not show up
Why Plausible and GA4 numbers are often different
Should you worry about ad blockers when using Plausible?
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

Do ad blockers block Plausible Analytics?

What is PII? Meaning and examples of personal data you shouldn’t send to analytics

2026-06-17T15:20:20+00:00

Website analytics is useful when it helps you understand what people do on your site. It becomes risky when it starts collecting details that can identify a person.

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.

What PII means
1. PII vs personal data
2. Sensitive PII and special category data
Common PII examples
What not to send to analytics
How Plausible avoids collecting personal data
How to redact URL identifiers with custom locations
A quick PII review checklist
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:

Where it appears	PII example	Why it is risky	Safer analytics version
URL path	`/customers/cus_7H3kL9`	The ID can map to a specific customer in your systems	`/customers/:id`
Query parameter	`/reset-password?email=jane@example.com`	The email address identifies a person directly	`/reset-password`
Form tracking	`Demo request from Jane Smith`	The event includes submitted form values	`Demo request form submitted`
Custom property	`user_id=184291`	The property can identify one user or account	`logged_in=yes` or `plan=business`
Email link	`/unsubscribe/jane@example.com`	The URL exposes the subscriber	`/unsubscribe`
Site search	`jane@example.com`	Search terms may contain names, emails, phone numbers or order details	Track that a search happened, or use broad search categories
Ecommerce event	`order_id=order_20493`	The order can be tied back to a customer	`Checkout completed`
Support flow	`ticket_id=88421`	The ticket can reveal a private support case	`Support form submitted`

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

Is an email address PII?

How to investigate a spike in your website traffic?

2026-06-11T10:30:00+00:00

Are you seeing a spike in your website traffic? That can be either good news or a warning sign.

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.

Is it bot traffic?
Check your traffic sources
Check the pages report
1. [Examples] How to read clues together
Check devices and browsers
Cross-check with other sources
Could it be an attack or abuse?
Check whether your team caused it
Monitor whether the spike repeats
So, what did the spike mean?
How much traffic spike is enough to investigate?
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 still judge them by engagement, conversions and whether they bring the kind of visitors you want.

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.

Website Journey Analytics: How to track user journeys on your website

2026-06-04T14:58:06+00:00

People do not experience your website one page at a time. They arrive with a goal, move between pages and events, get answers, get stuck, compare options, drop off, or convert. User journey data helps you see those paths instead of looking at each page in isolation.

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.

What is website journey analytics?
How user journeys compare to other analytics methods
What you can learn from visitor paths
How to track user journeys on your website
1. How Plausible User Journeys works
GA4 Path Exploration vs Plausible User Journeys
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.

How simplifying our homepage helped increase trial signups by 84%

2026-05-12T09:00:00+00:00

April 2026 was our best month ever. We added more new paying subscribers than in any other month in our seven-year history. For three months running, from February through April, we set new all-time records for both trial signups and new paying customers.

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%.

Month	Trial signups	Register page conversion	Visitor-to-trial rate
January	2,423	38%	2.65%
February	2,656	48.8%	3.09%
March	3,608	52.8%	3.64%
April	4,464	57.3%	4.80%

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.

The boring way to build a startup

2026-04-29T09:59:41+00:00

Most startup stories that get glorified are dramatic.

“We almost ran out of money.” “We had to pivot.” “It nearly failed.”

Ours didn’t really have moments like that. It was mostly a long stretch of building, talking to users, fixing things, and trying not to make decisions that would put us out of business.

A lot of startup advice is about growing at all costs, raising money, setting ambitious targets, moving quickly and figuring things out later.

It all sounds reasonable. It just didn’t feel like something we could follow without taking risks we couldn’t afford.

So, we kept things simple: no bets we couldn’t afford to lose, no growth at all costs, no unrealistic targets.

That ruled out a surprising number of “normal” startup decisions. It’s what kept us alive and thriving for seven years.

Sustaining the startup beats breakout growth
It’s okay to stay self-funded
It’s okay to keep things small
Charging from day one simplified things
Organic growth beats manufactured growth
It’s slower, and that’s the trade-off
Most of it is just the “boring” work
Seven years later, it adds up
You don’t need to chase the dramatic story

Sustaining the startup beats breakout growth

A lot of startup advice pushes you to take bigger risks, faster moves, higher stakes. That works sometimes. But if your goal is to still be around in a few years, avoiding certain situations helps.

We avoided bets where the downside was losing the company. We didn’t spend money we didn’t have. We didn’t set targets that forced us into risky decisions just to hit them.

Instead, we started out with our own pocket money, built something people would find useful, let them use the tool, provide feedback, stick around and bring more people.

The focus was on the things that would help the business survive.

It’s okay to stay self-funded

It’s okay to self-fund if you can, and if the nature of your business allows it. We’re 100% user-supported to this day and a good breakdown of how we did that is here.

We have deliberately turned down hundreds of investing offers. Staying self-supported forced us to not postpone figuring out how the business works. There was no runway to fall back on, no buffer to absorb bad decisions.

If something didn’t work, we felt it immediately.

That forces a certain kind of clarity. You don’t build features “just in case.” You don’t chase ideas that might pay off later. You focus on what works now and improve from there. That makes you keep things simple, even if you don’t realize it while it’s happening.

It also removes a layer of pressure.

We didn’t have to grow at a specific pace or work toward a predefined outcome. We just had to make something people would pay for and keep using.

That decision simplifies a lot of things. If customers are the ones funding the business, the product has to be useful. There’s no fallback.

That kind of independence is hard to give up.

Being open source is part of what makes it credible. The code is public. People can see exactly what the product does with their data. You don’t have to take our word for it.

It’s okay to keep things small

We’re still a core team of 10 folks. We didn’t hire fast. We didn’t build a big team to feel like we’re growing while the real metrics (like profit, number of users, goodwill, etc.) would reflect otherwise.

We didn’t take on costs assuming future growth would cover them. Partly because we couldn’t. Partly because we didn’t want to.

That constraint ended up being useful.

When you don’t have much room, you focus on what actually matters. You cut scope more aggressively. You don’t add complexity unless you really need it. You ship smaller improvements instead of big, risky changes.

It also changes how you think about risk.

When it’s your own business, not a runway from investors, big bets feel different. You start avoiding the kind of decisions that could wipe you out.

So instead of trying to jump ahead, we just kept things manageable and kept going.

Charging from day one simplified things

We chose a subscription model from the start.

In a market where most people default to Google Analytics 4, that’s not the obvious move, scary even. But it simplified things for us.

We’re not trying to match every feature or collect as much data as possible. We’re not trying to lock people in.

If someone is paying, the product has to make sense quickly. There’s no room for confusion or unnecessary complexity.

So we kept it simple. Focused on the core use case. Avoided building features we didn’t really believe in.

We just built something simpler. Something you can understand quickly. And something that respects user privacy by default.

Over time, it became clear why someone would pay for a simpler, privacy-friendly alternative instead of sticking with free.

We also didn’t need a second business model. No ads, no selling data, no trade-offs hidden behind “free.”

Just a product people pay for because it’s useful.

Organic growth beats manufactured growth

We didn’t run ads. We didn’t build aggressive funnels. We didn’t define a narrow Ideal Customer Profile and optimize everything around it.

We also avoided a lot of the usual tactics that come with that approach.

No retargeting. No tracking people across the web. No popups or intrusive calls to action. No email sequences trying to “nurture” people into paying. No sales calls.

That wasn’t some grand strategy. It just didn’t feel like how we wanted to build. Most of our growth came despite not doing these things.

Instead, people found us through content, trying the product, and telling others.

That’s it.

It’s slower. There’s no obvious spike you can point to.

It took us 324 days to reach the first $400 MRR. Took us 3 years to make $1M ARR. And another 3 to multiply it several times over. And we were profitable within the first few years.

But it’s simpler, it sticks, and the compounding tends to outlast anything you could manufacture.

It’s slower, and that’s the trade-off

This approach isn’t faster.

You grow more slowly. You get less attention. There are long stretches where it feels like not much is happening, especially when other companies are moving quicker.

We felt that too.

But the upside is you don’t have to make decisions just to keep up. You don’t have to take risks that don’t make sense for your situation.

You just keep going.

Tortoise does beat the hare.

Most of it is just the “boring” work

There’s this idea that building a startup is a series of intense, high-stakes moments. In our case, it might not be as true. Most weeks look the same:

Work on the product. Work on the communication. Fix something that’s broken or confusing. Talk to users. Ship an improvement.

Do that again next week.

It’s not exciting. It doesn’t give you that “we’re onto something big” feeling all the time. But it keeps things moving and sometimes gives great results too.

Seven years later, it adds up

Seven years is a long time to keep doing something. That’s probably the real outlier.

Not a big pivot or a lucky break. Just continuing long enough for the small things to compound.

We’re still here. We’re profitable. We’re independent.

No big moment got us here. It was just consistency and not making decisions we’d regret later.

And we still enjoy working on it.

You don’t need to chase the dramatic story

This isn’t the only way to do things.

Some companies raise money, move fast, take big risks, and build something huge. That works for some. This is what worked for us.

Build something useful. Charge for it. Keep your costs under control. Improve it steadily.

Give it time.

It won’t make for the most glamorous story. But you might still be here in seven years.

Survival matters more than it gets credit for. Profitability gives you options. Independence keeps things simpler. And if you still enjoy the work after a few years, that’s a very underrated win.

How to manage Plausible Analytics across multiple client sites with Google Tag Manager

2026-04-27T09:00:00+00:00

If you manage analytics for more than one site, you already know the frustration. Every time a client switches themes or their developer updates the codebase, the analytics snippet breaks. Every new tracking requirement means a code change, a developer ticket, a waiting period, and another round of testing.

Google Tag Manager was designed to solve exactly that. You deploy one GTM container snippet and manage everything else from a dashboard, without touching source code. For agencies and freelancers who manage several client sites, it changes the entire workflow.

Plausible has an official template in the GTM gallery. Here’s how to use it to manage privacy-friendly analytics across multiple sites without depending on clients’ developers.

Why GTM makes sense for multi-site management
The official Plausible GTM template
Setting up the template for a client site
Managing multiple containers efficiently
Keeping analytics off when you need to
What GTM can’t do
Taking it further with Data Studio
Get started

Why GTM makes sense for multi-site management

The direct Plausible script is the simplest setup for a single site you control. But when you’re managing analytics for five or ten client sites, “simplest setup” means something different. It means:

No deployment dependency. You can update tracking without a code change.
Consistent configuration. Every site gets the same event tracking structure.
Faster onboarding. A new client gets analytics live in minutes once GTM is on their site.
One place to audit. You can check what’s firing on any site from your GTM account.

The tradeoff is that GTM has to be on the site in the first place. For most clients, that’s already true. If it isn’t, getting a single GTM snippet added is a one-time request that unlocks everything else forever.

The official Plausible GTM template

Plausible has a template in the Google Tag Manager community gallery. It’s built and maintained by the Plausible team, which means it tracks what’s in the product, works with current script configurations, and won’t silently break when the Plausible API changes.

You can find it in the GTM template gallery or search for “Plausible Analytics” directly from the Templates section of your GTM account.

Unlike GA4’s approach, Plausible’s GTM template involves zero configuration for privacy compliance. No consent mode settings, no cookie configuration, no data retention toggles. Plausible doesn’t collect personal data or use cookies, so there’s nothing to configure. You add it, it works, and your clients don’t need a cookie banner for it.

Setting up the template for a client site

The setup is the same for every site. Once you’ve done it once, it takes about five minutes per new client.

Step 1: Create a GTM container for the client

Give each client their own GTM container. This keeps configurations separate, makes auditing clean, and means a change for one client can’t affect another.

Step 2: Add the Plausible template to the container

In the client’s GTM container, go to Templates, click Search Gallery, and search for “Plausible Analytics.” Add it to the workspace.

Step 3: Create the Initialization tag

Create a new tag using the Plausible Analytics template. Select Initialization as the type.

You’ll need the Plausible Script ID for the client’s site. You can find this in Plausible under Site Settings > General > Site Installation > Tag Manager. Paste it in, then scroll down to the Triggering section and select “All Pages” with “Page View” as the trigger type.

Before publishing, use GTM’s Preview mode to confirm the Plausible tag fires correctly. Once verified, publish the container. That’s everything required for basic pageview tracking. The client’s site now sends data to their Plausible dashboard.

Step 4: Enable enhanced measurements

The Initialization tag has built-in checkboxes for the most common tracking needs. No triggers, no custom configuration required. Just check the boxes for what you want to track:

Outbound link clicks: track clicks leaving the client’s site
File downloads: track PDF, image and other file downloads automatically
Form submissions: track form completions across the site
404 error pages: catch broken links and missing pages

Check what applies, save, and those measurements are live.

Step 5: Add custom event tracking for anything else

For interactions specific to a client’s site (a particular button, a pricing page CTA, a video player), you can use the Custom Event tag type without touching any code.

Create a trigger in GTM that fires on the interaction (a click matching a CSS selector, URL, or element text)
Create a Plausible Custom Event tag attached to that trigger
Name the event, verify in Preview mode, and publish

The event shows up in the client’s Plausible dashboard under Goals once you’ve set up the matching goal in Plausible settings.

Managing multiple containers efficiently

Once you have the pattern established, a few GTM practices keep multi-site management clean.

Use consistent naming for custom events. Outbound links, form submissions and file downloads are named automatically by the template. For any custom events you create yourself, use the same naming pattern across all clients: Signup Click, Demo Request, Video Play. This makes it easy to recognise configurations when you switch between containers.

Use GTM variables for site-specific values. If you have event names or properties that vary per site, store them as GTM variables rather than hardcoding them in each tag. Easier to update, less room for error.

Use workspaces for changes. GTM workspaces let you draft changes separately from the live container. Test in preview mode before publishing to make sure events fire correctly.

Document the trigger logic. Add notes to GTM tags explaining what they’re tracking and why. The GTM dashboard is a shared space, and client developers sometimes have access.

Keeping analytics off when you need to

The Initialization tag has two options that are useful during development and testing:

Capture on Localhost: unchecked by default. Leave it off during local development so test traffic never reaches the client’s Plausible dashboard.
Auto Capture Pageviews: if unchecked, the Plausible script loads but sends no pageviews automatically. Useful for staging environments where you want the script present but not actively tracking.

For your own traffic, Plausible ignores it automatically once you add the exclusion setting to your browser. You can also pause or unpublish tags in GTM entirely without removing them, which is useful when auditing a staging environment.

What GTM can’t do

GTM is powerful but it’s not universal. Some tracking requires server-side instrumentation: revenue data from payment processors, backend conversion events, authenticated user actions. For those, you’d use Plausible’s server-side events API rather than the GTM template.

For everything that happens in the browser, including most of what agencies track for clients, GTM handles it cleanly.

Taking it further with Data Studio

Once your client sites are tracking reliably through GTM, the next question is often reporting. Plausible’s own dashboard is clean and easy to share, but some clients want custom layouts, branded reports or views that combine analytics with their ad spend.

The official Plausible Data Studio connector connects directly to your Plausible data. Build once, share a live link with the client, and it updates automatically. It’s available on the Business plan and works with any Plausible site, regardless of how it was installed.

Get started

The Plausible GTM template is in the Google Tag Manager gallery. The full setup guide covers initialization, custom events, and advanced configuration options.

If your clients are on WordPress, the official WordPress plugin is an alternative to GTM that handles everything natively within WordPress, including WooCommerce revenue tracking, author and category stats and automatic form tracking.

Attribution Modeling: What it is and How to do it with Plausible Analytics

2026-03-05T11:38:13+00:00

Attribution modeling is how marketing teams decide where growth really comes from. In other words, it’s about attributing the touchpoints (specific channels, campaigns, ads, etc.) that led someone to take a desired action (like purchase, sign up, etc.) in your business.

There are multiple ways of doing this, i.e., various models for assigning weightage to different touchpoints and it depends on how deep you want to go into this analysis and what suits your business.

But eventually, it’s about key business questions and informing marketing, sales, product, finance teams, etc., about budget decisions, campaign strategy, and even product direction.

What is attribution modeling in marketing?
1. Different Attribution models
  1. Single-touch
  2. Multi-touch
Why is traditional attribution becoming less reliable?
1. Clarity about what you can and cannot measure
2. Choosing an attribution model based on business size and complexity
What is Plausible Analytics and how to use it for marketing attribution?
1. How Plausible collects and presents data
How to do attribution modeling in Plausible?
Bringing it all together

What is attribution modeling in marketing?

Attribution modeling is simply assigning credit to different interactions (touchpoints) in a buyer’s journey that lead to a desired outcome, like a signup, demo request, or purchase. For eg., did a blog post lead to awareness? Did an ad campaign nudge more people to convert? Or was it a good old email newsletter that sealed the deal?

Different Attribution models

There are largely two models:

Single-touch

First-touch: All credit goes to the first interaction in the buyer’s journey that introduced someone to your offering/brand. It is usually useful for understanding high-level awareness drivers. Like, ads or social media content that get people to discover you).
Last-touch (last-click): All credit goes to the interaction right before conversion. Useful for understanding what closed the deal. Like, somebody visiting the product page on your ecommerce store directly for purchasing.

Multi-touch

Credit is shared across multiple interactions. This can be evenly shared, weighted by position, or determined by a more data-driven algorithm. There are several sub-models in this type.

Each model has a purpose and a context where it’s most relevant. Which one a business uses depends on what questions they want answered.

But eventually, the goal is to answer relevant business questions like where to allocate budget, which campaign to stop, which to keep running, etc.

Why is traditional attribution becoming less reliable?

For years, attribution models relied heavily on tracking individual users across websites, sessions, and devices. The model has been that if you could follow a person’s path closely enough, you could assign credit with precision.

But third-party cookies have been restricted or eliminated by most browsers. Even user-level tracking breaks at many points due to reasons like rejected consent banners, ad blockers blocking non-privacy-respecting scripts like GA’s. As a result:

Not every visit can be stitched to previous sessions
Returning users may appear as new
Cross-site journeys break
Data gaps increase

Many attribution systems now rely on modeled estimates to fill those gaps rather than direct observation. The numbers might look precise, but they are partially reconstructed almost always.

Clarity about what you can and cannot measure

No tool can fully reconstruct every touchpoint in a modern buyer journey.

Cross-device behavior, private browsing, internal link sharing, offline conversations, and dark social, all do create blind spots.

For many teams, especially smaller B2B or SaaS companies, the question is not “Can we track everything?” but:

“Can we understand which channels and campaigns are influencing results at a reliable level?”

Choosing an attribution model based on business size and complexity

More advanced attribution systems make sense when:

You have large paid media budgets
You operate across too many channels
You need account-level or multi-touch revenue modeling
You have the data infrastructure to support it

For other teams who do not operate at that scale, a simpler attribution framework that focuses on:

First-touch signals
Last-touch performance
Campaign-level analysis
Funnel progression

…is more than often enough to guide strategy and overall direction.

What is Plausible Analytics and how to use it for marketing attribution?

Plausible Analytics (we) is a lightweight, privacy-friendly web analytics tool designed to show how people find and interact with your website. It’s also a much simpler alternative to Google Analytics.

Since we’re privacy-first, most privacy-friendly browsers and adblockers don’t block our script, which is why our stats are much more accurate than other tracking tools.

This also means we don’t need to rely on modeled data, nor try to reconstruct complex user journeys. Everything you see on the dashboard is 100% real data.

How Plausible collects and presents data

Plausible does not use cookies or persistent identifiers. It does not track users across devices or build behavioral profiles. We track website level data and aggregated analytics only.

Take a look at our live demo but here’s an overview of the main data you can see in the dashboard:

Unique visits, bounce rate, scroll depth, and other engagement signals
Traffic sources and referrers
UTM campaign parameters
Top, Entry and Exit pages
Goal conversions
Location and device information
Custom properties (aka custom dimensions)

All of this is presented in a clean dashboard without heavy modeling.

How to do attribution modeling in Plausible?

Even without user-level tracking, you can apply several practical attribution models using Plausible’s existing reports. The key is understanding how to interpret the data provided.

Below is a simple framework you can apply right away.

1. Start with clear conversion goals

Attribution only works if you define what you’re attributing. In Plausible, set up goals for meaningful actions such as:

Demo requests
Contact form submissions
Signups
Purchases
Trial activationsetc.

Once goals are defined, every report can be filtered by conversions. This turns traffic data into attribution data.

2. Use the Sources tab for last-touch attribution

Effectively, Plausible gives you a last-touch view by default since the analytics are sessions based.

You can filter by any goal in the dashboard for any time period.

Tip: You can also filter your dashboard by specific regions or devices/browsers to add context to your analysis.

The Sources section is your most essential area for attribution.

Here you can analyze:

Which channels drive the most conversions
Conversion rate by source
Campaign performance
Referral contributions

This tells you which channels are capturing new interest and driving immediate action. Use this to answer:

Which acquisition channels deserve more budget?
Which campaigns are converting efficiently?
Where are we seeing high-intent traffic?

How to use this info:

Increase budget where conversion rates are strong
Optimize or pause campaigns with traffic but no outcomes
Identify high-intent channels that deserve more focus

This is especially useful for paid campaigns, email, and bottom-of-funnel activity.

3. Use Entry pages to approximate first-touch attribution

To understand what creates demand, look at your Entry pages report, while still having the dashboard filtered by the goal in question.

Entry pages show where sessions begin. When you filter by conversions, you can see which landing pages tend to start journeys that result in goal completions.

This is your practical first-touch view as you’ll discover:

Which blog posts introduce converting users
Which feature pages attract high-intent visitors
Which content pieces generate qualified traffic
Which landing pages (esp. if they’re from an ad/marketing campaign) converted

How this informs decisions:

Double down on high-performing content topics
Improve internal linking from strong entry pages
Refine messaging on pages that attract traffic but don’t lead to action

This is particularly valuable for SEO, content marketing, and awareness campaigns.

P.S. Bonus read: How to analyze top landing pages and exit pages on your website?

4. UTM parameters for campaign-level attribution

UTM tagging is critical for clean campaign attribution. You can standardize parameters such as utm_source, utm_medium, utm_campaign. Use the UTM builder to generate correctly formatted links, or the UTM checker to validate and clean existing ones.

When links are consistently tagged, Plausible lets you break down conversions by campaign.

For this, keep your dashboard filtered by the goal in question, go to: Campaigns tab dropdown → Select from UTM mediums, sources, campaigns, contents, or terms, depending upon the depth/purpose of your analysis.

Now you can compare:

Paid ad variations
Email sequences
Partnership traffic
Influencer campaigns

…among absolutely anything you want to track using UTMs.

How this informs decisions:

Scale winning campaigns
Reallocate budget from underperformers
Test variations with clearer performance benchmarks

This layer is often the most actionable because it directly informs where marketing spend should increase or decrease.

5. Use funnels to understand progression

Plausible does not reconstruct multi-session journeys, but you can build funnels by stitching together goals to understand if and how many visitors are moving between key steps, what and where the dropoffs are, etc.

For open-ended path analysis, you can also use User Journeys to see what visitors did before or after a conversion. We explain the strategy and examples in our guide to website journey analytics.

Here are some funnel examples:

Blog post → Pricing page → Signup
Landing page → Demo request
Feature page → Contact form

Then segment funnels by source or campaign.

This helps you identify:

Which channels drive deeper engagement
Where drop-offs happen
Which paths convert at higher rates

What to do with this info?

Improve underperforming steps in the funnel
Adjust landing page messaging
Focus acquisition on sources that drive deeper progression

This also adds behavioral context to your source-level attribution.

Taken together, this gives you:

A demand capture view through sources
A demand creation view through entry pages
A campaign optimization layer through UTMs
A behavioral layer through funnels

Without needing user-level tracking or complex multi-touch modeling.

For teams that require deeper modeling, Plausible data can be exported and layered into broader analytics systems, making it a clean acquisition-level input rather than a closed environment. Check out our APIs, export options, and Data Studio Connector for this purpose.

Bringing it all together

Attribution modeling does not have to be complicated to be useful. Many teams make meaningful decisions about budget allocation, content strategy, paid campaigns, and website optimization using the framework given above.

New here? Learn more about us. And start your free trial here (no CC needed).

Plausible Analytics

How to check your own website traffic accurately

1. Install analytics on your website

Make sure your analytics is working

2. Choose a useful date range

3. Check visitors, visits and pageviews

4. Find where your traffic comes from

5. Check which pages people visit

6. Check campaign traffic with UTM parameters

7. Check conversions and goals

8. Diagnose a traffic spike or drop

Why a public traffic checker can never measure your site accurately

A simple weekly website traffic check

EU-hosted analytics isn’t the same as EU-owned analytics

What EU-hosted usually means

What EU-owned adds

How this helps you decide

Why this became a bigger issue after Schrems II

Examples from analytics tools

What Plausible means by EU-owned analytics

What to ask before choosing an analytics tool

Do ad blockers block Plausible Analytics?

Why Plausible is blocked less often than Google Analytics

How the Plausible proxy reduces ad blocker impact

Is using a proxy ethical?

Proxy options in Plausible

Why your own Plausible visit might not show up

Why Plausible and GA4 numbers are often different

Should you worry about ad blockers when using Plausible?

Frequently asked questions

What is PII? Meaning and examples of personal data you shouldn’t send to analytics

What PII means

PII vs personal data

Sensitive PII and special category data

Common PII examples

In URLs

In forms

In user IDs

In emails

In search queries

What not to send to analytics

How Plausible avoids collecting personal data

How to redact URL identifiers with custom locations

A quick PII review checklist

Frequently asked questions

How to investigate a spike in your website traffic?

Is it bot traffic?

Check engagement metrics

Check the locations

Check for data center and spam patterns

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

Are you a Plausible Analytics subscriber?

Check your traffic sources

If the spike came from Direct

If the spike came from Organic Search

If the spike came from AI referrals

If the spike came from Organic Social

If the spike came from Referral

If the spike came from a paid campaign

Check the pages report

[Examples] How to read clues together

Check devices and browsers

Cross-check with other sources

Could it be an attack or abuse?

Check whether your team caused it

Monitor whether the spike repeats

So, what did the spike mean?

How much traffic spike is enough to investigate?

A traffic spike is a question, not an answer

Website Journey Analytics: How to track user journeys on your website

What is website journey analytics?

How user journeys compare to other analytics methods

Customer journey analytics

User journey mapping

Funnels

What you can learn from visitor paths

See what visitors do after landing on key pages

Work backwards from conversions

Understand drop-offs

Compare journeys by traffic source, campaign, device or country