Custom tracking domains: partner links on go.yourbrand.com

RelayWonder now supports a custom tracking domain for every brand: partner short links, campaign tracking links and the tracking script can run on a subdomain you own, such as go.yourbrand.com, instead of a platform address. Setup is one CNAME record pointing at a target unique to your brand; once DNS resolves, an HTTPS certificate from Let's Encrypt is issued automatically, usually within a minute, and renewed 30 days before it expires. When the domain is active, a click on a partner link writes the referral cookie on your root domain directly in the redirect, so the referral is stored even on pages without the tracking script. This post covers setup, what changes for links, script and cookie, the security rules, and what it does not do.

What a custom tracking domain changes

Without a custom domain, a partner's short link points at a RelayWonder address. It works, but the person deciding whether to click sees a domain they do not recognise. With a custom domain, the same link is go.yourbrand.com/go/anna-review, and the only domain in it is yours. We will not put a number on how much that helps, but the reason it helps is easy to see: a link that matches the product looks like the product.

The second change is where the referral is stored. When the redirect comes from your own subdomain, our tracking server can set the rw_ref cookie on your root domain, yourbrand.com, in the redirect response. Your site can read it on every page and at checkout. Without a custom domain, the cookie the redirect sets lives on the platform domain and only serves as a backup; attribution then relies on the script on your site writing the first-party cookie after the page loads.

How to set up go.yourbrand.com

The whole setup is one DNS record. An admin on your brand account does it in Settings, under Tracking, in the Custom tracking domain section.

1. Choose a subdomain you own and do not use for anything else, such as go.yourbrand.com or link.yourbrand.com. Your root domain itself cannot be used, because it already serves your website.
2. Enter it and save. RelayWonder shows the record to add: type CNAME, name go (or the full hostname, depending on your DNS provider), and a value that starts with rw- followed by 12 characters unique to your brand.
3. At your DNS provider, add that CNAME record exactly as shown. If your DNS is on Cloudflare, set the record to DNS only (grey cloud), not Proxied.
4. Wait. RelayWonder checks the record every minute for the first hour, then every 15 minutes. When it sees the right value it issues the certificate and the status turns Active.
5. Done. New short links, campaign links and the script snippet now use the new domain. Copy the updated script snippet into your site if you embed it manually.

DNS usually updates within minutes, though some providers can take up to 48 hours to publish a new record. You do not need to keep the settings page open; the checks run in the background and the status updates on its own. If you want to check immediately after adding the record, use the Check now button.

Why Cloudflare records must be DNS only

Cloudflare offers two modes per record. In DNS-only mode, a CNAME resolves to the record's actual target and Cloudflare does not route HTTP or HTTPS traffic through its network. In Proxied mode, queries are answered with Cloudflare's anycast IP addresses, and proxied CNAMEs are flattened by default, meaning the CNAME chain is replaced by the final IP address [3].

Both effects break verification. Our check looks for a CNAME pointing at your brand's target, and a flattened record does not expose one. And the certificate challenge has to reach our server: Let's Encrypt's HTTP-01 challenge fetches a token from http://<your domain>/.well-known/acme-challenge/<token> on port 80 [2], and with the proxy on, that request reaches Cloudflare instead. Switch the record to DNS only and both problems disappear. Your main website can stay proxied; only the tracking subdomain needs the grey cloud.

Automatic certificate issue and renewal

Once the CNAME is correct, RelayWonder requests a certificate for your exact hostname from Let's Encrypt using the HTTP-01 challenge. Let's Encrypt places validation requests from possibly several vantage points, our tracking server answers with the token, and the certificate is issued [2]. In most cases the status moves from Issuing certificate to Active within a minute. The certificate is then used for every HTTPS request to the domain.

Let's Encrypt certificates last 90 days, and Let's Encrypt recommends renewing 90-day certificates every 60 days [1]. RelayWonder starts renewal 30 days before expiry, which for a 90-day certificate is the 60-day mark, and if an attempt fails it tries again every 6 hours. Renewal checks the CNAME first, so if the record has been removed or changed, the problem is recorded on the domain and renewal waits until the record is restored. Keep the CNAME in place for as long as you use the domain. The settings page shows the date the current certificate is valid until.

A worked example of timing: you add the record at 10:00. Your DNS provider publishes it at 10:04. Our next check at 10:05 sees the correct CNAME and starts issuing; the certificate arrives at about 10:06 and the domain is Active. If your provider instead took 3 hours, the first hour of checks would run every minute and the next two hours every 15 minutes, so the domain would become active within about 15 minutes of the record appearing. Around 60 days after issue, renewal runs without any action from you.

What changes for links, script and cookie

Links

Partner short links and campaign tracking links are generated on the new domain as soon as it is active. Long links with the ?via= parameter, which point straight at your site, do not change. Partners see the new links in their dashboard and in the white-label portal if you run one. If you later stop using the domain, short links already shared on it stop working and new links go back to the platform address, so treat the domain as permanent once partners have started posting links.

Script

The tracking script snippet shown in your settings switches to the new domain. The script itself does the same job as before: it reads ?via= from partner links, writes the first-party cookie on your domain and reports the click. Loading it from your own subdomain means one fewer third-party host on your pages, which matters if you keep an inventory of third-party scripts for privacy reviews.

Cookie

When a partner short link on go.yourbrand.com is clicked, the redirect sets the rw_ref cookie on yourbrand.com with the Secure flag and SameSite=Lax, lasting for your program's referral window. Your checkout then reads it and passes the referral id to Stripe as client_reference_id, a field Stripe provides to reconcile a session with your own records [5]. After checkout, every renewal is attributed from the Stripe invoice, not from the cookie.

We want to be precise about one thing. A custom tracking domain does not make cookies immune to browser privacy rules. WebKit states that when Safari detects third-party CNAME cloaking, it caps cookies set in the HTTP response to 7 days, the same cap it applies to cookies written by JavaScript [4]. Plan on the cookie lasting about a week in Safari. That is why the durable parts of attribution remain client_reference_id at checkout and personal coupon codes, which attribute without a click.

Security: a domain only serves its own brand

Custom domains introduce a question every multi-brand platform has to answer: could someone point a domain at the platform and serve another brand's links, or claim a domain that is not theirs? The rules below are enforced by the tracking server and the settings page.

• The CNAME target is unique to your brand. It is derived from your brand's identity with a server-side secret, so another brand that enters your hostname would be shown a different target and could never verify it.
• A hostname can be active for one brand only. If another brand already uses it, saving shows "Another brand is already using this domain."
• A custom domain only serves its own brand's links and script. A request on go.yourbrand.com for a link or script belonging to another brand returns not found.
• Platform domains and their subdomains are reserved and cannot be added.
• Only admins on the brand account can add, change or remove the tracking domain.
• The partner portal domain, if you set one, must be a different subdomain from the tracking domain, such as partner.yourbrand.com, so the two never conflict.

The practical result is that adding a CNAME cannot hijack anything and nothing on your domain can be used to send traffic to someone else's program. If you remove the CNAME at your DNS provider, the domain stops resolving to us and nobody else can take it over on our side, because the target they would need is yours alone.

Troubleshooting common setup problems

• "We can't see the CNAME record yet": the record is not published or the name is wrong. Check that the name is go and not go.yourbrand.com.yourbrand.com, which some providers produce when you type the full name into a field that already appends the domain. On Cloudflare, switch the record to DNS only.
• "This domain's CNAME points to …": an old record exists. Replace its value with the target shown in settings.
• "Use a subdomain, not your root domain": enter go.yourbrand.com, not yourbrand.com.
• "DNS looks good, but the certificate couldn't be issued": something blocked the HTTP-01 challenge on port 80, often a proxy or a CAA record that does not allow Let's Encrypt. Fix it and the automatic retry will pick it up.
• Links still show the old address: links are switched once the status is Active. Refresh the partner dashboard after activation.

What to do this week

1. Pick the subdomain. Short and generic works best: go, link or ref.
2. Add the CNAME from Settings → Tracking setup. If you are on Cloudflare, set it to DNS only.
3. Wait for Active, then update the tracking script snippet on your site if you embed it by hand.
4. Tell partners their short links have moved to your domain. Old links on the platform address keep working.
5. Run one test click in Safari, Firefox and Chrome and confirm the referral reaches Stripe as client_reference_id at checkout.