Bluesky campaign tracking with UTM
Bluesky, built on the AT Protocol, can be accessed through the main app and third-party clients, so referrer hostnames vary and link cards are fetched server-side. UTM parameters on the shared link are the reliable way to attribute Bluesky traffic across the app and alternative clients.
AT Protocol and varied clients
Bluesky runs on the AT Protocol, and posts can be read in the official app or numerous third-party clients. That means a single post can drive clicks whose referrers differ by client, scattering attribution if you rely on referrer hostnames.
A UTM parameter on the link is client-independent: tag the URL with a stable convention such as utm_source=bluesky and utm_medium=social and the channel groups cleanly no matter which client forwarded the click.
- AT Protocol — official app plus third-party clients
- Referrers vary by client; UTM on the link does not
- Use a coarse source value like bluesky
Link cards are server-side
When a link is posted, a service fetches it to build the preview card. These automated fetches are bot traffic, not human visits, and should be excluded from campaign counts. The precise fetch behaviour can change as the platform evolves, so it is described as a pattern and the entry is marked partially verified.
Measure the human click on the tagged URL and keep the card fetches in your bot view for a clean campaign number.
How it appears in analytics and logs
A tagged link arriving with utm_source set to bluesky identifies Bluesky-driven traffic regardless of which client the click came from. Server-side fetches that build link cards are bots, not human clicks, and belong in your bot view.
Diagnostic use case
Attribute clicks from Bluesky posts to a single campaign by tagging the shared URL, rather than relying on referrers that differ across the app and third-party AT Protocol clients.
What WebmasterID can help detect
WebmasterID separates server-side Bluesky link-card fetches from human clicks on tagged links, so your campaign count reflects people rather than card-generation requests.
Common mistakes
- Relying on referrers that differ across Bluesky clients.
- Encoding a handle or DID in utm_source.
- Counting link-card fetches as human campaign clicks.
- Using inconsistent source values so the channel fragments.
Privacy and accuracy notes
Use a coarse label such as bluesky in utm_source; do not encode a user handle or DID. UTM values describe the campaign, not the individual posting or clicking.
Related pages
- Fediverse campaign tracking with UTM
Federated microblogging is decentralised: links are posted across thousands of independent instances, so referrer hostnames vary and link previews are fetched by instance servers. UTM parameters on the link itself are the reliable way to attribute this traffic, since they travel with the URL regardless of which instance a click came from.
- Threads campaign tracking with UTM
Threads is a mobile-first app where most clicks open in an in-app browser, so referrer data is often missing or shows a generic value. UTM parameters on the shared link are the dependable way to attribute Threads traffic, since they travel with the URL through the in-app webview.
- UTM parameters and bot traffic
Tagged URLs get fetched by more than humans: crawlers, link-preview unfurlers, security scanners, and uptime monitors all follow UTM links. Counting them as campaign clicks inflates results. This page explains why bots hit tagged URLs and how to separate automated traffic from human campaign visits.
- Bot vs human
Separate link-card fetches from real Bluesky clicks.
Sources and verification notes
- Bluesky / AT Protocol documentationAT Protocol supports multiple clients; link cards fetched server-side.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.