UTM Tracking for ShareASale: How to Build and Validate Affiliate Campaign Links

How ShareASale's tracking architecture interacts with UTM parameters

ShareASale (now part of Awin Group) is one of the largest affiliate networks for US-focused e-commerce, software, and financial services merchants. When a publisher shares a ShareASale affiliate link, the click goes to ShareASale's tracking infrastructure first. ShareASale records the click and assigns its own click identifier before redirecting the browser to the merchant's destination URL configured in the program settings.

This redirect architecture has one important consequence for UTM tracking: UTM parameters belong on the merchant destination URL, not on the ShareASale affiliate link. ShareASale's tracking link carries ShareASale's own parameters (including its click ID used for commission attribution) that are separate from your GA4 UTM data. UTM parameters added to the ShareASale tracking link itself are not reliably forwarded to your destination. The reliable approach is to configure UTM parameters on the destination URL inside the ShareASale merchant dashboard.

GA4 attribution works by reading utm_source, utm_medium, and utm_campaign from the URL at page load time — the URL the browser is on when the GA4 tag fires. For GA4 to correctly attribute affiliate traffic from ShareASale publishers, those parameters must be present on the final destination URL after ShareASale's redirect resolves. If any redirect in the chain strips them, the session lands in GA4 as Direct or Referral, and the affiliate team has no conversion data to attribute to the publisher or program.

ShareASale's own platform records click and conversion data independently of GA4, using its own publisher tracking IDs and SAS click identifiers. Both systems coexist: ShareASale tracks affiliate conversions via its own click IDs, GA4 tracks via UTM parameters on the destination URL. For a broader overview of how UTM parameters work and why redirect survival matters, see the UTM tracking for developers guide.

Building per-publisher UTM destination URLs for ShareASale with mlz build

ShareASale programs typically have publishers across several categories — content sites, coupon platforms, loyalty networks, influencers, and deal aggregators — each needing a distinct utm_source so GA4 can attribute conversions to the right publisher type. Generating these manually introduces inconsistencies: mixed casing, misspelled source names, missing parameters. mlz build generates normalized, validated destination URLs from structured input and stores each link for an auditable record of what was configured in ShareASale.

The standard convention for ShareASale is utm_source=[publisher-type], utm_medium=affiliate, and utm_campaign=[campaign-name]. Use utm_content to differentiate creative variants within the same publisher type.

$ mlz build \
  --url "https://brand.example.com/lp" \
  --source "shareasale-content" \
  --medium "affiliate" \
  --campaign "summer-2026" \
  --content "banner-top" \
  --validate

{
  "tracked_url": "https://brand.example.com/lp?utm_source=shareasale-content&utm_medium=affiliate&utm_campaign=summer-2026&utm_content=banner-top",
  "params": {
    "utm_source": "shareasale-content",
    "utm_medium": "affiliate",
    "utm_campaign": "summer-2026",
    "utm_content": "banner-top"
  },
  "destination_url": "https://brand.example.com/lp",
  "link_id": "lnk_sas_sum26_bn",
  "campaign_id": "cmp_summer-2026",
  "stored": true,
  "created_at": "2026-06-29T08:14:22.000Z"
}

For a coupon or deal publisher on the same campaign, change --source to reflect the publisher category:

For a loyalty or cashback publisher:

The tracked_url value from each mlz build call is what you paste into the destination URL field in the ShareASale merchant dashboard when creating or editing your affiliate links. Each publisher category gets a distinct utm_source. For naming conventions across affiliate, coupon, and loyalty publisher types, see the UTM naming conventions guide. To generate these at scale via the API or npm, see how to build UTM links programmatically.

Validating the ShareASale redirect chain with mlz check

Once you have the UTM destination URL, validate it end-to-end before setting it in ShareASale. mlz check follows the complete redirect chain from your destination URL, confirms the server responds with a 200, and verifies there are no configuration issues that would strip UTM parameters. Run it before the ShareASale program activates — not after a quarter of data shows every session from publishers landing in GA4 as Direct.

$ mlz check "https://brand.example.com/lp?utm_source=shareasale-content&utm_medium=affiliate&utm_campaign=summer-2026"

{
  "url": "https://brand.example.com/lp?utm_source=shareasale-content&utm_medium=affiliate&utm_campaign=summer-2026",
  "valid": true,
  "checks": [
    { "check": "url_format", "status": "pass", "message": "URL format is valid." },
    { "check": "ssl", "status": "pass", "message": "URL uses HTTPS." },
    { "check": "resolution", "status": "pass", "message": "Destination responded with 200.", "details": { "status_code": 200, "response_time_ms": 218 } },
    { "check": "redirects", "status": "pass", "message": "No redirects detected." },
    { "check": "response_time", "status": "pass", "message": "Response time: 218ms.", "details": { "response_time_ms": 218 } }
  ],
  "status_code": 200,
  "response_time_ms": 218,
  "validated_at": "2026-06-29T08:15:01.000Z"
}

A clean result means the destination URL resolves correctly and parameters survive to the final page. If valid is false, the checks array tells you exactly which hop in the chain failed. The most common failure mode in ShareASale setups is a redirect on the merchant's own site stripping query parameters — a CDN rule, an A/B testing framework, or an internal vanity URL redirect that doesn't preserve query strings. A parameter-only validator would show the URL as syntactically valid while this failure goes undetected. For a detailed walkthrough of diagnosing redirect chain failures, see how to check if a redirect strips UTM parameters.

ShareASale UTM tracking gotchas for affiliate managers and merchants

ShareASale's click identifiers are not UTM parameters

ShareASale uses its own click identifiers (the SAS click ID and related tracking parameters) to record which publisher drove a click, handle commission attribution, and produce affiliate reporting inside the ShareASale platform. These are entirely separate from UTM parameters and serve a different purpose. Do not remove ShareASale's parameters to add UTM tracking — doing so breaks ShareASale's commission attribution. Both can coexist on the destination URL: ShareASale's IDs handle affiliate reporting, UTM parameters handle GA4 attribution. Configure UTM parameters on the destination URL and let ShareASale append its own identifiers to the affiliate tracking link.

UTM parameters go on the merchant destination URL, not the affiliate tracking link

The affiliate tracking link ShareASale generates for publishers routes clicks through ShareASale's servers. If you add UTM parameters to the affiliate tracking link directly, they may not survive the redirect to your destination. The reliable approach is to configure UTM parameters on the destination URL field inside the ShareASale merchant dashboard. This is the URL that appears in the browser after ShareASale's redirect chain completes — and the URL where GA4 fires its tracking tag.

Coupon and deal publishers often add their own redirect hops

Coupon aggregators, deal sites, and cashback platforms frequently wrap the ShareASale affiliate link inside their own redirect layer before sharing it with users. Each additional hop is another opportunity for query parameters to be stripped. mlz check follows every hop and confirms UTM parameters survive to the final URL. If a publisher's wrapping strips parameters, the redirects check will flag the failure before you commit to the program launch.

Merchants using vanity URLs on destination links may silently drop parameters

Some merchants configure ShareASale offers using short or vanity destination URLs (e.g. brand.com/sale that internally redirects to brand.com/collections/summer-sale). If the internal redirect is not configured to preserve query strings, UTM parameters are stripped before GA4 fires. Validate the vanity URL directly with mlz check — don't assume the redirect preserves query parameters until you've confirmed it does.

ShareASale's deep link tool requires the base destination URL; add UTM parameters yourself

ShareASale's Deep Link Generator in the merchant dashboard creates affiliate links pointing to specific pages on your site. The tool generates the affiliate link structure but does not add UTM parameters to the destination URL automatically. You must build the UTM-tagged destination URL yourself (using mlz build or manually) and configure it as the destination in ShareASale. The UTM parameters are part of the destination URL, not the affiliate link wrapper.

Frequently asked questions

Where exactly do I add UTM parameters in the ShareASale merchant dashboard?

In the ShareASale merchant account, navigate to your program's link settings. Each link type (banner, text link, deep link) has a destination URL or merchant URL field — this is where you paste the UTM-tagged URL generated with mlz build. The resulting value looks like: https://brand.example.com/lp?utm_source=shareasale-pub&utm_medium=affiliate&utm_campaign=summer-2026. ShareASale appends its own tracking parameters to the affiliate link it generates for publishers; the destination URL you configure becomes the final landing URL after ShareASale's redirect resolves.

Does ShareASale strip UTM parameters during the redirect?

ShareASale's redirect is generally designed to pass the destination URL through intact, including query parameters. However, parameter stripping commonly occurs elsewhere in the chain: secondary redirects on the merchant's own site (CDN configurations, A/B testing tools, internal URL routing rules), or publisher-side link wrapping (coupon sites adding their own redirect hop). Validate the complete chain with mlz check before the program activates. Do not assume parameters survive without testing the full redirect chain.

Can I use one destination URL for all ShareASale publishers, or does each need its own URL?

You need a different destination URL per publisher type if you want per-type GA4 attribution. Each URL should have a distinct utm_source value that identifies the publisher category (content site, coupon platform, loyalty network). The utm_medium, utm_campaign, and utm_content values can be shared across publishers within the same campaign. mlz build generates a correctly normalized URL per publisher category in a single command, eliminating the casing inconsistencies and spelling errors that fragment GA4 data across multiple rows in the same channel.

How is ShareASale's click tracking different from UTM parameters?

ShareASale's click tracking uses its own click identifiers and proprietary attribution system to record which publisher drove a click, verify the conversion, and calculate commission payouts — all within the ShareASale platform, independently of GA4. UTM parameters are read by GA4 (and other analytics tools like Mixpanel or Amplitude) to attribute sessions to campaigns and channels in your analytics reports. Both systems work in parallel: ShareASale uses its own IDs for affiliate reporting, GA4 uses UTM parameters for channel attribution. Configure both and you get complete data in both systems.

How do I validate UTM tracking across all my ShareASale offers before the program launches?

Run mlz check against each destination URL you configure in ShareASale. For a large program with many publisher categories, generate all URLs using mlz build with a script or via the REST API, then validate each one systematically. If you use a CI/CD pipeline to manage campaign configuration, see automating campaign link validation in CI/CD to gate affiliate link changes on a passing mlz check result before the configuration is deployed.