GitHub Sponsors campaign tracking with UTM
GitHub drives off-platform traffic from Sponsors profiles, repository READMEs, profile READMEs, and FUNDING links. Many of these are server-rendered and may show github.com as the referrer or none at all, so UTM parameters on the destination link are the reliable way to attribute GitHub-sourced traffic.
Where GitHub links live
Off-platform traffic comes from Sponsors profile pages, repository and profile READMEs, the FUNDING file links shown in the Sponsor button, and documentation pages. These render Markdown server-side, so the referrer is often a coarse github.com or missing, which makes referrer-based attribution blunt.
Tag each link with a consistent scheme such as utm_source=github, utm_medium=referral, and a utm_campaign that names the repository or sponsorship so all of these surfaces roll up cleanly.
- Sponsors profile, READMEs, FUNDING links, docs
- Referrer often a coarse github.com or absent
- UTM on the destination separates the surfaces
Distinguish repos and tiers
Use distinct utm_campaign values to separate clicks from different repositories or sponsor tiers, so you can see which presence drives traffic. Keep values lowercase and consistent across READMEs.
Referrer behaviour for rendered Markdown links can vary, so the pattern is described rather than fixed, which is why this entry is partially verified. Validate a tagged README link lands with its UTM intact.
How it appears in analytics and logs
A tagged link arriving with utm_source set to github identifies traffic from your repository or Sponsors presence even when the referrer is just github.com or absent. A coarse or empty referrer is expected for links inside rendered Markdown.
Diagnostic use case
Attribute clicks from a GitHub Sponsors page, README, or FUNDING link to a campaign by tagging the destination URL, instead of relying on a coarse github.com referrer.
What WebmasterID can help detect
WebmasterID records tagged GitHub arrivals server-side, so you can distinguish README and Sponsors clicks by UTM even when the referrer collapses to github.com.
Common mistakes
- Relying on a coarse github.com referrer to tell surfaces apart.
- Encoding a sponsor or user identity in UTM values.
- Reusing one campaign value across unrelated repositories.
- Casing drift between README copies of the same link.
Privacy and accuracy notes
Use coarse labels such as utm_source=github with a utm_campaign for the repo or sponsor tier. Do not encode a sponsor or user identity; UTM describes the campaign, not the person.
Related pages
- Referral program UTM tracking
Referral programs need their own UTM medium so referred traffic is not confused with organic referrers. This page shows how to label the referral channel and explains why you must not encode individual user IDs in UTM — it leaks personal data and invites abuse.
- Link-in-bio campaign tracking
A link-in-bio page is the single URL in a social profile that fans out to several destinations. Without tagging, every outbound click looks the same and you cannot tell which social platform or which button drove it. Adding UTM parameters to the destination links inside your bio hub, plus the bio link itself, makes each path measurable. This page covers a two-layer tagging approach for bio links.
- UTM naming conventions that survive reporting
Most UTM data problems are naming problems. Because tools treat utm_source=Reddit and reddit as different values, inconsistent casing and spelling fragment one campaign across many rows. This page gives a convention — lowercase, hyphenated, documented allow-list — that keeps reports clean.
- Campaign links docs
Separate README and Sponsors clicks under one scheme.
Sources and verification notes
- GitHub Docs — Displaying a sponsor button (FUNDING)Sponsor links surface via FUNDING file and profiles; rendered 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.