Open the Instagram profile of almost any small business we talk to and the bio link goes to a page on somebody else's account. Often the freelancer who set it up two years ago. The colours are close to the brand, the buttons point at the right places, and when the owner asks where the clicks come from, the honest answer is a screenshot from a dashboard they can't log into. One marketer on r/marketing put the whole problem in a sentence: "I am trying to get more information about the people clicking on my linktree link, such as where does the people clicking are coming from."
I'm Gabriel, founder of SharpHaw, and this is the second post in a series about SharpOS, the workspace we run every client engagement in. Part one covered the replacement ledger as a whole. This one takes row 11: Spotlight, our link-in-bio surface, and mostly the click pipeline underneath it, because that's the part I'd want to read about.
TL;DR: the link page is the smallest public thing a client owns and the first thing they hand to a third party. Spotlight puts it inside the client's workspace, on their Brand Kit by default, with clicks counted next to everything else we ship for them.
What a link-in-bio page is for, and where a hosted one strains
Instagram won't linkify a URL in a post, so "link in bio" became the one door out of the app, and Linktree and Bio.link built good products around that door. Unlimited links, a theme picker, an analytics tab, a URL you can put on a business card. For a creator running their own account, that's the right tool and I'd tell them to keep it.
Inside a client engagement the same page strains in three places. The brand gets retyped into a theme editor, so the moment the client's colours change, the link page quietly doesn't. The analytics live in an account that belongs to whoever created it, which is why "where do the clicks come from" turns into a screenshot. And the page is the client's front door on the one channel they post to every day, held in a tool nobody in the business owns. A comment on r/SaaS about Linktree's own position says the quiet part: "you don't collect a ton of data about your customers and worst of all it's entirely dependent on Meta's platform." For the vendor that's a business risk. For the client it's their door.
What Spotlight does instead
Spotlight gives each organisation one or more public, branded link pages at a short public address, built in the hub with three tabs: Edit, Design, Share. Links can be grouped, given a subtitle and a real brand icon, dragged into order. Nothing exotic. The part that matters is what happens when nobody opens the Design tab.
Unset means inherit. A colour, font or corner radius left empty resolves from the organisation's Brand Kit before it falls back to a default, so a page nobody styled is already on-brand, and a Brand Kit edit reaches every such page with no per-page action. Even the logo inherits: a page with none of its own serves the kit's wordmark, the dark-surface mark when the page runs dark. Where the kit's colour names don't match the heuristic, a slot can be bound to a named kit entry and it stays read-only until unbound.
Every page has its own analytics view (clicks, views, unique visitors, click-through rate, a ranked list per link), and the organisation's Analytics page has a Spotlight tab that rolls all pages up with source, device, country and campaign breakdowns. Access follows the standard model: internal pages are agency-only, client pages are visible to every member, only platform admins flip that, and click analytics are editor-and-above whichever the page is. The whole surface sits behind a feature flag, off by default. If the organisation has saved tracking codes under Integrations, the hosted page carries them with a consent prompt. You can open a real one here: a fixture workspace's Spotlight surface, browser-only, nothing persisted. The feature page is at sharphaw.digital/features/spotlight.
How the click tracking works
The public page renders each button as a real link that opens in a new tab. There is no redirect in the path. One view is recorded per session when the page loads, and each button press sends a tiny click beacon to our own origin, addressed by the page's permanent token rather than its slug — so a client can rename the slug and every deployed embed keeps reporting. Navigation proceeds whether or not the beacon lands.
Attribution keys off a stable per-link id, never the link's position in the list, so reordering or editing a link never corrupts its history. Each event is one append-only record; nothing is read and then updated, so a burst of clicks produces no contention. Every five minutes the raw events are rolled up into a daily table, clicks, views and unique visitors per link and per page, which is what the dashboard reads. Raw events are pruned after 90 days; the daily aggregates are kept forever.
The decision I'd defend hardest is keeping two identities apart. Abuse control uses an opaque key derived from the edge's trusted network address, and only that key is accepted for rate limiting. Analytics uses a random visitor id generated in the browser and hashed together with the page id before it is stored. Rotating the visitor id cannot allocate more limiter rows, and the page-wide capacity check runs before any per-client row exists, so an attacker who has filled a page cannot grow persistent state by inventing ids. Country and device come from the edge's own request headers, which the browser can't forge; referrer and UTM come from the browser and are reduced to a bare host or an allow-listed value and never rendered as a link. No IP, no coordinates, no raw user agent is stored. Breakdowns count views rather than clicks, because the clicks after an arrival came from the same place and counting them again would flatter the source.
A click also emits an event into Automations, and the whole page model is reachable over REST and MCP, where going live is deliberately two switches: publish the status, then enable the page.
What it doesn't do
Say the limits before anyone else has to. The page lives on our domain today, not the client's. There is no storefront, no payment block, no email capture, no marketplace of add-ons. Unique visitors are a sum of daily uniques and are marketing-grade, not billing-grade; a determined actor can inflate the visitor count even though the ceilings bound what gets accepted. And there is no tracked redirect yet, so a click from a no-JS context or an email prefetcher isn't counted. If a client sells through their bio link, or needs the page on their own domain this quarter, Linktree or Bio.link is still the right answer and I'll say so on the call.
Where it sits in the service
Spotlight belongs to the Content Engine side of what SharpHaw does: the bio link is where the content we ship for a client gets distributed on the channel they post to daily, and now the clicks land in the same workspace as the posts. The service is described at sharphaw.com/services/content-engine, and SharpOS itself, the workspace all of this runs in, at sharphaw.com/sharp-os.
One question for anyone who has built click tracking on a public page: how do you keep the identity you rate-limit on separate from the identity you count on, and did you end up with a redirect anyway?
This is part of the SharpOS, surface by surface series. Part 1, on the whole ledger: We replaced a 12-tool client stack with one workspace we built. Here's the row we couldn't.
Top comments (0)