feat(analytics): add Plausible alongside GA4 - #168
Conversation
✅ Deploy Preview for masterpoint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Adds Plausible Analytics to run in parallel with the existing GA4/GTM
setup, ahead of a possible GA4 retirement.
Three deliberate choices worth noting:
- Not consent-gated. GA4 and GTM load as type="text/plain" with
data-category="analytics", so CookieConsent blocks them until a visitor
accepts. Plausible is cookieless and stores no personal data, so it
loads unconditionally. This is the point: it sees the traffic GA4
never has. Expect the two tools to report very different totals.
- Proxied first-party via netlify.toml rewrites under /mpx/, so ad
blockers don't strip the tracker. The rewrites sit above the catch-all
404, which would otherwise swallow them. Installing via GTM was
rejected: GTM is both consent-gated here and widely ad-blocked, which
would forfeit both accuracy gains.
- Production only, guarded on HUGO_ENV, which Netlify sets in the
production and split1 contexts but not in deploy previews. Without the
guard, preview traffic would be attributed to the live site.
Scroll depth and time-on-page need no configuration. Outbound links,
file downloads, and form submissions are enabled in plausible.init().
plausible.html is added to .prettierignore for the reason that file
already documents: prettier mangles Hugo's {{ }} actions. It collapsed
the Go template comment and rewrote the init snippet into a form CI's
prettier then disagreed with.
Verified with hugo --minify in both contexts: rendered in production,
absent with HUGO_ENV unset.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
791a0f5 to
b192a78
Compare
|
Verified against the deploy preview, which is the real Hugo 0.162.1 + Netlify build rather than a local approximation. The The proxy works. Even on the preview, where the tag is deliberately not rendered, both rewrite rules resolve and serve Plausible's real infrastructure rather than our 404 page: The script body starts Also fixed since the first push: One caveat on the local side, unrelated to this PR but worth flagging: |
2 participants
what
layouts/partials/plausible.html, called fromhead.htmljust above the gtag block.netlify.tomlrewrites under/mpx/that proxy the Plausible tracker and event endpoint through our own domain.why
We use GA4 but effectively never log into it, and it has never been usable for a non-power-user. Plausible is the replacement candidate. This PR runs both side by side so we can compare before deciding whether to retire GA4.
Three deliberate choices, each worth a look during review:
1. Plausible is not consent-gated, on purpose.
GA4 and GTM load as
type="text/plain"withdata-category="analytics", so CookieConsent blocks them until a visitor accepts. Plausible is cookieless and stores no personal data, so it does not require consent and loads unconditionally.This is the main reason to adopt it: every visitor who ignores or declines the banner is currently invisible to GA4. Expect the two tools to report very different totals. Plausible will be meaningfully higher, and that gap is traffic GA4 has never shown us. Compare trends and rankings, not absolute numbers.
2. Proxied first-party, and not installed via GTM.
The
/mpx/rewrites serve the tracker from our own domain so ad blockers do not strip it. Plausible's dashboard suggests a GTM install instead; that was rejected on two counts. Our GTM container is itself consent-gated, so Plausible would inherit the gate and lose benefit 1. Andgoogletagmanager.comis widely ad-blocked, so the tracker would be blocked whenever GTM is, which the proxy cannot fix because the blocked resource would be the container rather than the tracker.Note the rewrites must stay above the catch-all
/*to/404.htmlrule, which would otherwise swallow those paths.3. Production only.
Guarded on
HUGO_ENV, which Netlify sets in theproductionandsplit1contexts but not in deploy previews. Without the guard, preview traffic would be attributed to the live site, since Plausible counts against the configured site rather than the actual hostname.verification
Built locally with
hugo --minify(matching the Netlify build command) in both contexts:HUGO_ENV=production: Plausible renders with all four init options, GA4 untouchedHUGO_ENVunset: Plausible absent entirely, GA4 untouched<script async>with notype="text/plain"and nodata-category, confirming it sits outside the consent gatetrunk checkpasses clean on all three files.Local build used cached Hugo v0.146.4 rather than the pinned v0.162.1, because
aqua installcurrently fails to fetch that version (hugo_extended_0.162.1_darwin-universal.tar.gzis not published under that name). The template features used are old and stable, but the Netlify build is the real check.after merge
Worth confirming on the deployed site, especially the negative cases:
/mpx/js/script.jsreturns 200 and/mpx/api/eventreturns 202If Netlify Asset Optimization rewrites the script URL, either disable
Bundle JS/Minify JSor switch thesrcto an absolute URL.references
🤖 Generated with Claude Code