Two different things share the word “clicks” here. The first is the click data your published site records — every link and button press, on every plan, forever. The second is the overlay, a view in the CMS that draws those counts as badges over a live preview of the page itself, so you read them in place rather than as a list of element ids.
What a click records
Every click and middle-click on your site is classified into one of four types before it is sent:
| Type | When it applies | Example |
|---|---|---|
internal | The link’s host matches the host of the page it was clicked on | A link from your pricing page to your docs |
outbound | The link resolves to any other host | A citation pointing at a vendor’s site |
file | The link’s extension is in the tracked download list — pdf, docx, xlsx, zip, mp4, mp3 and about two dozen more | A whitepaper download |
other | A tracked element that is not a link — a <button>, or a link with no href | A JavaScript-driven “Show more” control |
Alongside the type, each click carries the destination URL with its query string stripped, the anchor fragment if the link pointed at one (#pricing is recorded as pricing), and the identity of the element that was clicked.
That last part is what makes per-element counts possible. Leed resolves the clicked element by walking up from the click target to the nearest ancestor carrying a data-id attribute, and records both the id and whether it was found on the clicked element itself or inherited from a parent. Blocks authored in the CMS editor carry a stable data-id automatically — you never add one. Elements in templates you write yourself do not, and adding them is what makes those elements countable; the attribute contract is in how Leed tracks visitors.
Clicks that would otherwise be lost
Three deliberate choices keep the counts honest, and each of them fixes a way that naive click tracking undercounts:
- Middle-clicks and open-in-new-tab clicks count. The tracker listens for
auxclickas well asclick, so a reader who opens six links in background tabs registers six clicks, not zero. - A same-tab navigation is delayed by 100 milliseconds so the beacon lands before the page unloads. You will not notice the delay; without it, exit links would be systematically undercounted. Links with a
target, links opened with Ctrl/Cmd/Shift held, and links carrying adownloadattribute are left entirely alone — the browser handles those, and interfering with adownloadlink would silently turn a file save into a navigation. - Listeners run in the capture phase, which reaches the tracker before any of your page’s own handlers. A component that calls
stopPropagation()on a click — Leed’s own documentation menu does exactly that — cannot hide the click from tracking.
What is not tracked
span, div and img are not treated as click targets in their own right. A click landing on one of them walks up looking for an enclosing <a> or <button>; if it does not find one, nothing is sent.
An other click with no resolvable element id is dropped outright. A button with no data-id anywhere above it produces no row, because a count with nothing to attribute it to is not usable.
Reading clicks as a table
The same data in tabular form is the internalClickMetric list metric. It is scoped to one page — a request without a pageId is rejected — and returns three columns, sorted by unique users descending:
| Column | What it counts |
|---|---|
| Element ID | The data-id value the click was attributed to |
| Unique Users | Distinct persistent visitor ids that clicked it |
| Total Clicks | Every click row, including repeats by the same person |
The click-count overlay
Where it appears
Open one of those pages from your page list and it renders inside a preview frame, with a badge over every element that carries an id.
Turning it on
The switch is Show analytics overlay, at the bottom of the filter block in the right rail’s Analytics tab — the panel headed Page Analytics. It is on by default, and your choice is remembered in your browser across visits rather than for the current tab only, so turning it off once turns it off everywhere until you turn it back on.
The switch appears only on repository pages; the panel on a CMS-authored page has no such row.
Reading a badge
Every element carrying an id gets a ring around it and a small count chip at its top-right corner:
| Appearance | Meaning |
|---|---|
| Pink ring, pink count chip | The element was clicked at least once in the selected window |
Muted gray ring, gray count chip reading 0 | The element is trackable and was clicked zero times in the window |
| No badge at all | The element carries no data-id, so nothing can be attributed to it |
The hover popover
Hovering a badge opens a small card beside it:
| Field | What it shows | When it is hidden |
|---|---|---|
| Element label | The element’s own text, so you can tell two similar links apart | Never |
| Total clicks | Every click on that element in the window | Never |
| Device | The device split, as percentages, most common first | Never — an element with no recorded device shows — |
| Browsers | The top three browsers, as percentages | Never — shows — when no browser was recorded |
| Top dest | The destination most clicks led to | Hidden when the element is a plain link that only ever led to one place, because the row would repeat what the link already says |
That last rule is worth knowing so its absence does not read as a bug. The row stays for containers whose inner links go to several places, for JavaScript-driven buttons whose destination the text does not reveal, and for links whose destination changed during the window because you republished the page.
Filters and scroll
The badges obey the same controls as the rest of the Analytics panel — there is no separate overlay filter:
| Filter | Same as the panel? |
|---|---|
| Date range | Yes |
| Remove Bounces | Yes |
| Session Start (all sessions, or email-driven) | Yes |
| Specific email send | Yes |
| Minimum Active Time | Yes |
So narrowing Session Start to a single email send repaints the badges as “clicks made by readers who arrived from that send” — which is the fastest way to tell whether a campaign’s readers behaved differently from your organic traffic. The controls themselves live in the Page Analytics panel.
Badges follow the page as you scroll, so a long page can be read top to bottom without losing alignment.
Below Growth
The switch is still there and still turns on. What changes is what it produces:
- Instead of badges, a dismissible upgrade banner appears across the top of the preview area.
- No click query is issued at all. The CMS checks your plan before asking, so there is no failed request behind the scenes and nothing to retry.
- Once you dismiss the banner it stays dismissed in that browser, and the preview then simply shows your page with no badges on it.
flowchart TD
A["Overlay switch turned on"] --> B{"Growth plan or above?"}
B -- Yes --> C["Click query issued<br/>badges drawn on the preview"]
B -- No --> D["No click query issued at all"]
D --> E["Dismissible upgrade banner<br/>across the top of the preview area"]
E --> F["Page renders with no badges"]
Capture is unaffected. Every click your visitors make is still recorded while you are below Growth, so upgrading turns the badges on over history you already have. If the upgrade banner is not something you can act on yourself, billing and developer access explains who in your workspace can.
How the preview is built
The preview is not your live site in a frame. Leed serves the page through a proxy that removes every script, form and embedded frame from it and injects one small measuring script of its own. That script does one job: it reports the position and identity of each element carrying a data-id back to the CMS. The counts are fetched separately, by the CMS, from your analytics — and the two are joined in the browser to place the badges.
sequenceDiagram
autonumber
participant CMS as CMS editor
participant Proxy as Page proxy
participant Frame as Preview frame
participant Agent as Measuring script
participant API as Analytics API
participant D1 as Click events
CMS->>Proxy: Request the page for preview
Proxy->>Frame: Script-free copy + one measuring script
Frame->>Agent: Page loads, script starts
Agent->>CMS: Position and id of every identified element
CMS->>API: Click counts for this page and window
API->>D1: Aggregate clicks by element id
D1-->>API: Counts, unique users, device and browser splits
API-->>CMS: One row per element
CMS->>Frame: Join positions with counts, draw badges
Note over CMS,Frame: Scrolling moves the badge layer only — nothing is refetched
Two consequences follow from that shape and are worth stating plainly. The preview is inert: your site’s own JavaScript never runs in it, forms are stripped rather than disabled, and clicking a badge does nothing. And the numbers on the badges are the same numbers the panel’s tables use — they come from one query, not from a separate measurement of the preview.