How to Add Google Analytics to Notion Pages and Sites
Someone in marketing asks how many people read the new careers page. The careers page lives in Notion, published to a custom domain, and it looks like a real website. So you open the page settings expecting a field for a measurement ID, and there is nothing there. You search for a Notion Google Analytics option in the workspace settings, in the site settings, in the integrations gallery, and you keep finding the same answer written five different ways: Notion does not let you paste a script tag into a page.
That answer is correct and also incomplete. There are working paths to Google Analytics on Notion-published content, they differ in cost and fragility, and each one has a boundary it cannot cross. This guide covers all of them in order, plus the part almost every tutorial skips: internal page views inside your private workspace are a completely different problem, and no amount of GA4 configuration will solve it.
Why Notion Google Analytics is not a settings toggle
Notion renders both the app and published pages as a JavaScript application it fully controls. There is no theme layer, no template file, no head section you can edit, and no user-supplied HTML block. The embed block runs third-party content inside a sandboxed iframe, which is deliberately isolated from the parent page, so an analytics snippet dropped into an embed measures the iframe and effectively nothing else. Custom code blocks in Notion display code, they do not execute it.
This is a product decision rather than an oversight. Arbitrary script execution on pages that anyone can duplicate into their own workspace would be a serious security problem, which is why Notion has resisted head-code injection for years while website builders shipped it early.
The consequence is simple: to run a Google Analytics tag against Notion content, something other than Notion has to serve the HTML, or Notion has to add the tag for you through a first-party field. Everything below is a variation on one of those two ideas.
Decide which question you are actually asking
Three very different questions get filed under Notion analytics, and they have three different answers. Sorting yours first will save you a week.
Public site traffic. You published pages to notion.site or a custom domain and you want sessions, sources, landing pages and conversions. This is a normal web analytics problem and GA4 is a reasonable answer once you solve the delivery problem.
Internal page views. You want to know whether the team actually reads the handbook, which SOPs are dead, and who opened the Q3 planning doc. This is a workspace telemetry problem. GA4 cannot see inside an authenticated Notion app session, and it never will.
Content usage inside databases. You want to know which templates get duplicated, which tasks stall, which knowledge base entries get linked most. This is a data question about your Notion content, not a traffic question, and it belongs closer to the reporting approach described in Business Data Analysis: A Practical Process for Teams than to an analytics tag.
Most frustration with a Notion analytics integration comes from asking question two while following instructions written for question one. Name your question before you pick a path.
Path one: Notion's built-in site analytics and custom domains
Notion publishes pages to a public URL, and paid plans can map a custom domain to a published site. Notion also exposes its own site analytics for published content, showing views over time without any tag of your own. Availability of specific fields moves with plan tiers and product releases, so check your site settings before assuming: Notion has been adding capability to the Sites product steadily, including analytics-related fields on higher tiers.
Start here for a practical reason. If a first-party measurement ID field exists on your plan, you paste your GA4 ID, save, and you are done in ninety seconds with nothing to maintain. Check the published site settings panel, not the workspace settings, and look under the site or domain section rather than under integrations.
Notion's own numbers are coarse: view counts and trends, without acquisition sources, conversion events, or any way to join traffic to something else you measure. For a small documentation site that is enough. For anything where you need to know that organic search sent forty percent of the visitors to a page that then drove signups, it is not.
The hard limit on this path: if your plan has no measurement ID field and no code injection, there is no workaround inside Notion. Do not spend an afternoon looking for one.
Path two: add Google Analytics to Notion with a site host that injects code
The most common working answer is a hosted layer that sits in front of Notion. Tools in this category, including Super, Potion, Simple.ink, Bullet and Popsy among others, pull your Notion page content and serve it from their own infrastructure under your domain. Because they control the HTML, they can offer exactly the thing Notion will not: a head code field.
The setup sequence is the same across all of them.
- Create a GA4 property and a web data stream for the domain you will actually use, not notion.site. Copy the measurement ID.
- In the host's dashboard, find the code injection or custom head field for the site.
- Paste the standard Google tag snippet, or a Google Tag Manager container snippet if you expect to add more tags later. GTM is worth the extra layer if more than one team will ever want a pixel on this site.
- Point your domain at the host per their DNS instructions and publish.
- Verify in GA4 Realtime and in DebugView before you tell anyone it works.
Two details catch people. First, some hosts have a dedicated Google Analytics field separate from the general head injection field, and pasting the tag into both produces double counting, which shows up as an implausibly low bounce metric and doubled page views. Pick one. Second, these hosts cache Notion content aggressively, so a change to your injected code may need a manual republish or a cache purge before it appears.
The cost is a recurring per-site subscription. That is the real trade: a small ongoing fee converts a closed publishing surface into a normal website you can measure, style and index. Weigh it the way you would weigh any tool in the Collaboration Software: How to Choose It Without the Bloat category, by asking whether the capability earns its line item every month.
Path three: a reverse proxy you run yourself
If you would rather not add a vendor, you can put your own edge worker in front of Notion. A Cloudflare Worker, a Netlify or Vercel edge function, or an nginx configuration with response rewriting all do the same job: fetch the Notion-published HTML, rewrite the links and the internal domain references, inject your analytics snippet into the head, and return the modified response under your domain. Cloudflare's HTMLRewriter API makes the injection part genuinely short, and community projects have shipped variations of this pattern for years.
The advantages are real: no per-site subscription, full control over the head, and the ability to add security headers, redirects and a proper robots and sitemap setup on the way through.
The cost is maintenance, and it is not theoretical. Your proxy depends on the shape of Notion's rendered output, so when Notion changes its markup, routing or asset paths, your rewrite rules can break quietly: the page still loads, but internal navigation stops firing analytics, or a stale page title gets attached to every view. Nobody notices for six weeks because the numbers still look like numbers.
Take this path if you already run infrastructure and someone owns it. Do not take it if the reason you publish from Notion is that nobody on the team wants to own infrastructure.
Path four: leave Notion for the public layer
The fourth option is to stop publishing from Notion and keep authoring in it. Pull page content through the Notion API into a static site framework, or export and commit the content, and serve a site you fully control. Analytics becomes trivial because it is just a website again, and you get proper metadata, structured data and redirects at the same time.
This is the right answer more often than people expect, specifically when the Notion pages in question are marketing pages or a public knowledge base you want ranking in search. It is the wrong answer for an internal wiki that occasionally gets shared outside, where the whole value is that publishing takes one click.
A generated site needs a build pipeline and someone to fix it. If your team's documentation practice is already fragile, adding a build step usually makes it worse, and the selection logic in Document Management Software: How to Actually Choose One applies directly: match the tool to the discipline you actually have, not the one you intend to develop.
Comparing your Notion Google Analytics options
| Path | GA4 possible | Ongoing cost | Fragility | Best for |
|---|---|---|---|---|
| Default notion.site URL | No | None | None | Sharing a page, not measuring it |
| Notion custom domain, first-party analytics field | Only if your plan exposes the field | Notion plan | Low | Small sites that need view counts |
| Third-party Notion site host | Yes, full head injection | Monthly per site | Low to medium, vendor dependent | Marketing pages, help centres, most teams |
| Self-run reverse proxy | Yes, full control | Near zero, plus your time | Medium to high | Teams that already run edge infrastructure |
| Rebuild as a static site | Yes, native | Build and hosting effort | Low once stable | Public content that must rank and convert |
| Private workspace pages | No, and no workaround | n/a | n/a | Use Notion's own workspace analytics |
Read the table by the last two columns, not the first. Almost everyone can get a tag firing somehow. The question is which failure mode you are willing to live with.
Making a Notion Google Analytics setup accurate, not just present
A tag that loads is not the same as measurement you can trust. Five checks separate the two.
Single page application navigation. Notion-derived sites often move between pages without a full document load. GA4's enhanced measurement includes browser history events, which usually catches this, but you must verify that the page path and page title update on each navigation rather than sticking at the entry page. Click through four pages in DebugView and read the page_location and page_title on each event. A site reporting every view against the homepage title is the classic symptom.
Referral pollution between domains. If any part of the journey bounces through notion.site while the rest is on your domain, GA4 will record notion.site as a referrer and split sessions. Add notion.site and your host's default domain to the unwanted referrals list in the data stream settings.
Duplicate tags. Check the rendered page source for more than one gtag or GTM snippet. Hosts that offer both a dedicated analytics field and a general code field make this easy to do by accident.
Consent. If you have European visitors, the tag needs to respect a consent signal. Most site hosts include a cookie banner option, and Google Consent Mode expects the signal before the tag fires. Wiring the banner after launch is far more painful than wiring it during.
Events worth having. Enhanced measurement covers scroll, outbound clicks and file downloads, which is most of what a documentation site needs. If a page's job is to drive a signup, define that as a key event now, while you remember why the page exists.
Verification is not optional. Use GA4 Realtime for a smoke test, DebugView for event detail, and Google Tag Assistant to confirm the tag fires once. Then wait forty-eight hours and check standard reports, because Realtime being right does not guarantee processing is right.
Track Notion page views inside the workspace: the honest limits
This is where the tutorials go quiet. You cannot track Notion page views inside your private workspace with Google Analytics. There is no injection point in the authenticated app, and Notion would not be doing its job if there were. What exists instead:
Per-page view data in Notion. Notion shows view information on pages, including who has viewed a page recently, with the depth of that data varying by plan. It answers "did the team read this" reasonably well for a specific page you care about.
Workspace-level analytics for admins. Higher tiers expose aggregate workspace analytics covering content and member activity. This is the closest thing to an internal traffic report and it lives entirely inside Notion.
Audit logs on enterprise plans. Useful for governance rather than engagement questions.
The gap is aggregation. Notion tells you about a page when you open that page. It will not tell you, unprompted, that the onboarding checklist stopped being opened three weeks ago, which is exactly the question that matters. If you are evaluating a dedicated search and analytics layer over your workspace to close that gap, understand the cost profile first: Glean Pricing: What Enterprise Search Costs Per Seat covers what that category charges, and it is a different order of magnitude from a site host subscription.
The honest summary: public Notion site traffic is a solved problem with a delivery workaround, and internal Notion page views are a Notion-only capability that you work with rather than around.
Where Skopx fits, and where it does not
Start with what Skopx does not do, because that is the part that saves you time. Skopx does not install tracking code. It will not inject a tag into a Notion page, it does not replace GA4, and it is not a dashboard builder, a data warehouse or an ETL tool. If your problem is "the tag will not load," nothing on this page's product side helps you. Solve that with one of the four paths above.
What changes after the tag is live is the reporting loop. Skopx is an AI workspace that connects nearly 1,000 tools a company already uses, Google Analytics and Notion among them, and once both are connected the questions you would otherwise answer by opening two tabs become chat questions with cited numbers behind them. Which pages drove signups last week. Whether the help centre page you rewrote on Tuesday moved. Whether the drop on the careers page is real or a comparison against a launch week. The citation matters more than the speed: an answer you cannot trace is an answer you will re-check manually, which means you did not save anything.
The morning brief is where this earns its place. Instead of remembering to open GA4, the movements worth noticing arrive with the rest of your morning context, and the insights engine flags anomalies you were not looking for, which is the category of thing dashboards are structurally bad at surfacing. You can also describe a recurring check in chat and get a workflow out of it, which is covered in more depth on the workflows page. Pricing is Solo at $5 per month and Team at $16 per seat per month, so the maths against a reporting habit that eats an hour a week is not complicated.
Weekly Notion site traffic check
Monday 08:00
Runs before the weekly marketing standup
Read GA4 pages report
Sessions, source and key events for the published Notion paths
Compare to prior week
Same weekday range so day-of-week effects cancel out
Keep material moves only
Ignore anything under the threshold you set in chat
Append to the Notion log page
Keeps the history where the content lives
Post the summary to Slack
Two lines plus the numbers, cited back to GA4
A weekly rhythm that keeps the numbers useful
Once notion website analytics are flowing, the failure mode shifts from missing data to ignored data. A short rhythm prevents it.
Pick one primary comparison and stick to it. Week over week catches incidents quickly and is noisy. Four weeks against the previous four smooths the noise and delays detection. Year over year is the only comparison that survives seasonality, and most Notion-published sites are too young to have it.
Report at the page level, not the site level. A site total of flat traffic frequently hides a help centre page that halved and a pricing page that doubled. The page is the unit you can act on.
Keep a change log next to the numbers: publishes, structural edits, domain changes, campaigns. Without it, every movement is a mystery, and mysteries do not get investigated. With it, the report proposes its own first hypothesis.
Decide in advance what a material change is. Percentages alone lie at low volumes: a page going from four views to eight is a 100 percent increase and means nothing. Set a floor in absolute numbers as well as a percentage.
Finally, be clear about which decisions this data can support. Traffic to a published Notion page tells you about interest and discovery. It says very little about whether the content did its job. For that you need the outcome the page exists to produce, a different measurement conversation worth having before you compare tools in the way Software for Market Research: What Each Tool Is Really For lays out.
Frequently asked questions
Can I add Google Analytics directly to a Notion page?
Not through a code block or an embed. Notion has no head injection field for page content, and analytics snippets inside embed blocks run in a sandboxed iframe where they measure almost nothing useful. The only first-party route is a measurement ID field in the published site settings if your plan exposes one. Otherwise you need a site host, a reverse proxy, or a rebuilt site serving the HTML.
Does Notion have its own analytics?
Yes, in two separate places that people often confuse. Published sites have view data for public visitors, and workspace pages have view information about members, with depth varying by plan and admin-level workspace analytics on higher tiers. Neither gives you acquisition sources, conversion events, or the ability to join Notion site traffic to anything else you measure, which is why teams add GA4 for the public layer.
Will Google Analytics track internal Notion page views?
No. GA4 cannot run inside the authenticated Notion app, so there is no way to track Notion page views for your private workspace with a Google tag. Use Notion's own page and workspace analytics for internal reading behaviour, and treat public site measurement as a separate system with separate tooling.
Do I need Google Tag Manager, or is the plain tag enough?
The plain Google tag is enough if analytics is the only thing you will ever add. Add GTM if you expect ad pixels, a consent management platform, or event tracking that someone outside engineering needs to change. On a host with a single code injection field, GTM also saves you from editing that field repeatedly.
Why do my Notion site numbers not match Search Console or the host's own stats?
Because they measure different things at different points. Search Console counts impressions and clicks as Google sees them, with a two to three day lag and privacy filtering. GA4 counts sessions after the page loads and after any consent signal, so blocked scripts and abandoned loads never appear. Host dashboards often count server requests, which include bots. Pick one source per question and document the choice instead of reconciling them every quarter. The same discipline applies to any customer-facing record you keep, which is the point made in CRM Contact Management: From Spreadsheet to Real Database: the number is only useful if everyone agrees what it counts.
Is it worth paying for a Notion site host just to get analytics?
If analytics is the only reason, usually no. If you also want a custom domain that behaves properly, control over metadata and indexing, faster page loads, and the ability to add other tags later, the subscription is buying a working website rather than a measurement tag. Decide on the full list of capabilities, and if the only item you need is a view count, Notion's built-in numbers may already answer the question you have.
Skopx Team
The Skopx engineering and product team