🔗 Remove UTM tracking from documentation links

[JFWooten4]

I get the allure of having this tracking. Marketing and tracking all the data can be fun. But the docs are a natural source of community information, not a venue for promoting products and services.

I first experienced this in 2023 when I added tracking to our own regulatory and compliance disclosure site in blocktransfer/issuer-disclosures@b9df49d. You can even see me tweaking the tags to normalize page refs the next year in blocktransfer/issuer-disclosures@96cf8fc. But this is bad policy that distracts the editor and reader from the core documentation efforts.

I have no problem with primary commercial sites, like the root domain, highlighting and referring to anything desired. But our source of truth as an information center should not burden visitors with this tracking. They already have to expose their cookies to tracking, which I believe we should keep away from developers in their earliest learning phase.

[Copilot]

Pull request overview

Removes UTM tracking parameters from external documentation links.

Changes:

• Cleans Asset Sandbox and Alchemy URLs.
• Leaves no remaining UTM parameters under docs/.

Recommendation: MERGE-READY — correct and complete.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
docs/tools/developer-tools/asset-tools.mdx	Removes tracking from the Asset Sandbox link.
docs/data/apis/rpc/providers.mdx	Removes tracking from the Alchemy link.

[ElliotFriend]

there was some (at least a little) rationale and context about adding the UTMs to the links, actually.

• Alchemy: in a review comment on Add Alchemy as a new RPC provider #2321 (alchemy specifically requested it)
• Asset sanbox: in a review comment on asset sandbox #124 (we lifted the link from the root stellar.org site)

i don't think it's so much that we're promoting any service or product. often, these campaign URLs can provide insights into where traffic originates for the other provider (alchemy or cheesecake, in these examples). if anything, it can provide to them signals that a lot of interest or buzz could be originating from the stellar documentation.

[JFWooten4]

I understand that a project would request it, as it's in their interest (as opposed to the interest of a simple documentation environment). And Bri's comments that #124 (comment) came from the blog in line with that being the norm on the SDF's site—OK.

But that's specifically the point. That example is a direct collaboration between an outside organization and the Foundation, and hence it should be strictly promoted as such through the Foundation's resources rather than as a community documentation asset.

We see this continued in #2321 (comment), when an internal team member specifically adds the tracking codes "so that we can track sign-ups from our website[,]" citing an internal Slack channel¹ for justification (emphasis added). Hence, they were left in as specifically migrated from a Foundation resource (and actually not included in Sydney's initial commit).

Their signal of interest should be real adoption of the network for their services, from their own SEO. Anything else is marketing feel-good metrics disguised as progress.

Footnotes

1. I've said it before, and I'll say it again: Stellar docs, not the SDF docs. I doubt this introduced substantial new documentation basis. ↩