Plausible and CodeWords: analytics with less of everything

Plausible is a deliberate reduction. No cookies, no cross-session identity, a small set of metrics, and a dashboard that fits on one screen. Teams choose it because the numbers are comprehensible and because there is no consent banner to argue about.

That reduction is also the thing to understand before automating against it. Several questions other analytics tools answer are simply not answerable here, and building around an assumption that they are is the way this goes wrong.

What we'll cover

• What you give up
• What the Plausible API reaches
• Goals, which are simpler than you expect
• Connecting it to CodeWords
• Seven automations worth building
• Reporting without over-claiming
• Self-hosted or cloud
• Where a public dashboard beats a report
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

What you give up

Worth stating plainly, because each of these is a question somebody will eventually ask.

Individual user journeys. There is no identified visitor to follow, so "what did this person do" has no answer by design.

Cross-session attribution. Somebody arriving from an advert today and converting next week is two visits, not one journey.

Deep funnels across sessions. Funnel support exists within its model and does not reconstruct a multi-week path.

Cohort retention. Without persistent identity, returning-visitor analysis is approximate rather than measured.

Arbitrary segmentation on user attributes, because there are no user attributes.

None of this is a defect. It is the trade for measurement that does not track people, and the right response is to decide whether the questions you need answered are inside that boundary before building a reporting pipeline on it.

What the Plausible API reaches

The Stats API returns aggregate metrics, time series, and breakdowns by dimension, with filters.

Custom properties attached to events can be broken down, which is where most of the useful depth lives.

Goals report conversions, as either pageview goals or custom events.

The Events API accepts events sent from a server, which is how you record things a browser cannot see.

Sites can be managed on plans and deployments that support it, which suits provisioning per customer.

Shared links produce a public dashboard, which is sometimes a better answer than building a report.

That list is short, and the shortness is the point. There is very little API surface to learn, and what exists is well-defined.

Goals, which are simpler than you expect

A goal is a pageview on a matching path, or a named custom event. There is no condition builder and no multi-step definition.

Custom events carry properties, which is how you attach the detail — plan, source, category — that makes a conversion reportable.

Revenue can be attached to events where your plan supports it, which turns conversion counts into something commercial.

Name events for what happened, since the name is what you will read in six months and there is no description field to explain it.

Keep the set small. The dashboard is one screen by design, and forty goals defeat the reason to be here.

Send server-side for anything that matters. A payment confirmed in your own system is more reliable than a pageview on a thank-you page, which misses everybody who closed the tab.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which site, which metrics or goals, and where the answer goes.
3. Authorize the connection with an API key for the site, read-only for reporting.
4. Describe the exceptions: a figure outside a plausible range, a goal that has stopped converting, an empty result.
5. Run it against a period where you already know roughly what the answer should be.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Weekly reporting with comparison. The handful of numbers somebody checks, delivered with the movement stated, which is most of what this tool is for.

Traffic anomaly detection. Against the same weekday over recent weeks rather than against yesterday, since weekly rhythm is strong and a flat comparison alarms every Monday.

Goal conversion monitoring. A goal that has stopped converting usually means something broke, and it produces no error anywhere.

Server-side conversion events. Payments, signups, and anything confirmed in your own systems, sent through the Events API rather than inferred from a page.

Cross-site reporting for anybody running several sites, since the dashboard is per site and the question usually is not.

Campaign reporting joined to outcomes. Plausible knows sources and conversions; your own systems know revenue. Reporting them together is the useful version.

Content performance digests. Which pages gained and lost, delivered to whoever writes them, which is the report content teams ask for and rarely receive.

Reporting without over-claiming

The discipline that keeps a Plausible-based report honest.

Say what a visitor is. Plausible's notion of a unique visitor is a daily approximation without persistent identity. Reports that imply otherwise will be questioned.

Do not sum daily visitors into a weekly figure. They are not deduplicated across days in the way people assume.

Report sources as attribution of a visit, not of a customer, since the tool cannot follow somebody across sessions.

Compare like periods, week against week with the same weekend days.

State the range and the timezone, which accounts for a surprising share of disagreements.

Be clear about what the tool cannot answer, once, in the report. It prevents somebody building a decision on a number that does not mean what they assumed.

Self-hosted or cloud

Cloud removes the operations, and the API is the same.

Self-hosted gives you the underlying database, which means arbitrary queries and no retention constraint beyond your own storage.

Self-hosted means you run it — upgrades, backups, and the database growth that comes with keeping raw event data.

Feature availability can differ between the hosted plans and a self-hosted deployment, so confirm what you have before designing around a capability.

Data residency is yours when self-hosting, which for some organisations is the entire reason.

For most teams, the hosted version plus the Stats API covers everything they will actually do. Self-hosting is worth it for data residency requirements or for the direct database access.

Where a public dashboard beats a report

Plausible has a feature most analytics tools do not, and it removes work that would otherwise be automation.

A shared link publishes the dashboard, optionally password protected, to anybody with the URL.

For a client or a stakeholder who wants to look, this is better than a scheduled report — it is current, it is interactive, and nobody has to maintain it.

Build a report when somebody needs a conclusion, not when they need access. Those are different requests and they get conflated constantly.

A weekly summary answers "what changed"; a dashboard answers "let me look". Most people asking for a report want the first, and giving them a link to the second does not satisfy it.

Share links can be revoked, which is worth knowing before publishing one for a client relationship that may end.

The honest guidance: publish a shared link for access, and automate a short weekly summary for the conclusion. Doing both takes an afternoon and covers nearly every reporting request a small team receives.

Building it so it survives

Use read-only keys for anything reporting, which is nearly everything here.

Handle empty results deliberately. Zero can mean no traffic or a broken filter, and those are opposite situations.

Send server-side events idempotently, keyed on the underlying transaction, since a retry should not double a conversion count.

Keep your own history if you need comparisons beyond the retention your plan provides.

Report the outcome. Which site, which period, and whether anything looked implausible.

Limits worth knowing about

Rate limits apply on the hosted service, so bulk reporting across many sites needs pacing.

No individual-level data is available, which is the product's premise rather than a limitation to work around.

Custom property cardinality matters. A property with unbounded distinct values produces a breakdown nobody can read.

Retention depends on your plan and deployment, which is worth checking before building a report that looks back years.

Some features differ between self-hosted and cloud, so a capability in documentation may not be in your deployment.

What to build first

Goal conversion monitoring: an alert when a goal that normally converts stops, or falls sharply against its own recent baseline. It reads only, it takes very little building, and a broken signup or checkout produces no error anywhere — it just stops happening, which is the most expensive silent failure a website has.

Two habits make the difference. Alert on absence as well as on decline, since a goal going to zero is the characteristic symptom of a break. And compare against the same weekday, because traffic has a strong weekly rhythm and a flat threshold fires every weekend.

Frequently asked questions

Can I track individual users?

No, by design. There is no persistent identity, which is what removes the consent question and also removes individual journeys, cross-session attribution, and cohort retention. Decide whether the questions you need are inside that boundary before building on it.

Do I need a cookie banner?

Plausible is designed for measurement without cookies or personal data, which is why many teams run it without one. Whether that satisfies your obligations depends on your jurisdiction and your full configuration, and it is a legal question rather than a technical one.

Why do weekly visitors not equal the sum of daily visitors?

Because visitor counts are approximations without persistent identity and are not deduplicated across days the way people assume. Report the weekly figure from a weekly query rather than adding daily numbers together.

How do I track conversions reliably?

Send them server-side through the Events API, from the system that knows the conversion happened. A pageview on a thank-you page misses everybody who closed the tab and counts anybody who reloaded.

What should custom properties hold?

Low-cardinality attributes that make a conversion meaningful — plan, category, source type. A property with many distinct values produces a breakdown with hundreds of rows, which nobody reads and which the dashboard is not built for.

Self-hosted or cloud?

Cloud unless you need data residency or direct database access. The API is the same, and self-hosting means owning upgrades, backups, and the growth of the event data.

Is it enough for a business?

For understanding traffic, sources, and conversions, generally yes, and the comprehensibility is a real advantage. If you need to follow individuals across sessions or analyse cohorts by user attribute, it is the wrong tool and no amount of automation changes that.

Should I build a report or share the dashboard?

Both, for different requests. A shared link gives people access to look, needs no maintenance, and is always current. A short weekly summary answers "what changed", which is what most people asking for a report actually want.

What is the best anomaly baseline here?

The same weekday over the preceding few weeks. Traffic has a strong weekly rhythm, and comparing against yesterday produces an alert every Monday, which teaches people to ignore the alerts.

Related reading

• Matomo and CodeWords
• PostHog and CodeWords
• CodeWords integrations and templates