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

How Admitad’s tracking architecture interacts with UTM parameters

Admitad is a global performance marketing network operating across more than 100 countries, with particular strength in Europe, Russia and the CIS region, Asia Pacific, the Middle East, and Latin America. Founded in 2009, it connects advertisers with publishers across e-commerce, mobile apps, financial services, travel, gaming, and subscription products. Admitad operates regional platforms and supports both content publisher and cashback/coupon publisher types.

When a publisher promotes an Admitad programme via an affiliate link, the click routes through Admitad’s tracking infrastructure (ad.admitad.com). Admitad records the click for commission attribution, then redirects the browser to the advertiser’s configured destination URL. Admitad’s tracking system operates entirely separately from GA4 UTM tracking and does not depend on or interfere with UTM parameters.

The consequence for UTM tracking: UTM parameters belong on the destination URL you configure in Admitad’s advertiser interface for your programme, not on the publisher-facing tracking link. Paste the UTM-tagged destination URL generated by mlz build into your Admitad programme settings.

Admitad’s subID feature is a publisher-side tracking mechanism that allows affiliates to append their own identifiers to affiliate links: subid1, subid2, through subid8. These parameters identify the publisher’s internal traffic source (e.g., which website section or email campaign drove the click). SubIDs are Admitad’s own parameter format, separate from UTM parameters, and they travel through Admitad’s redirect infrastructure alongside the advertiser-configured destination URL. Both should survive the redirect chain independently. For the full context of UTM parameter redirect chain validation across affiliate networks, see the UTM tracking for developers guide.

Building Admitad destination URLs with mlz build

The most common UTM data quality problem in Admitad programmes is casing inconsistency introduced when teams manage programmes across multiple Admitad regional platforms: one team uses utm_source=Admitad (capitalized), another uses utm_source=admitad, and a third uses utm_source=admitad-eu. GA4 is case-sensitive and records these as separate sources. mlz build eliminates this by enforcing lowercase-hyphenated values from structured input regardless of what the operator types.

The standard naming convention for Admitad programmes is utm_source=admitad, utm_medium=affiliate, and utm_campaign=[program-name-or-season]. Use utm_content to differentiate between creatives or promotional categories within the same programme. For advertisers running separate Admitad regional programmes, use a region-specific source value such as utm_source=admitad-eu or utm_source=admitad-apac to enable cross-region affiliate attribution in GA4.

$ mlz build \
  --url "https://shop.example.com/landing" \
  --source "admitad" \
  --medium "affiliate" \
  --campaign "global-promo-q3-2026" \
  --content "cashback-eu" \
  --validate

{
  "tracked_url": "https://shop.example.com/landing?utm_source=admitad&utm_medium=affiliate&utm_campaign=global-promo-q3-2026&utm_content=cashback-eu",
  "params": {
    "utm_source": "admitad",
    "utm_medium": "affiliate",
    "utm_campaign": "global-promo-q3-2026",
    "utm_content": "cashback-eu"
  },
  "destination_url": "https://shop.example.com/landing",
  "link_id": "lnk_ad_q3_cb",
  "campaign_id": "cmp_global-promo-q3-2026",
  "stored": true,
  "created_at": "2026-07-03T10:00:00.000Z"
}

The tracked_url value is what you paste into the Landing Page URL or Destination URL field in the Admitad advertiser interface when configuring your programme. For regional programmes, generate a distinct destination URL per region using a region-specific source or content value:

For naming conventions and how consistent casing prevents GA4 data fragmentation across affiliate sources, see the UTM naming conventions guide. To generate destination URLs programmatically for large Admitad program catalogs via the REST API, see how to build UTM links programmatically.

Validating the Admitad redirect chain with mlz check

Once you have a UTM-tagged destination URL, validate it end-to-end with mlz check before entering it into the Admitad advertiser interface. mlz check follows the complete redirect chain from your destination URL, confirms the server responds with a 200, and verifies query parameters are not stripped at any hop. Run this before your Admitad programme goes live, and re-run it after any infrastructure change that touches URL handling on your site — particularly important when deploying across multiple regional platforms where server configurations may differ.

$ mlz check "https://shop.example.com/landing?utm_source=admitad&utm_medium=affiliate&utm_campaign=global-promo-q3-2026"

{
  "url": "https://shop.example.com/landing?utm_source=admitad&utm_medium=affiliate&utm_campaign=global-promo-q3-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": 241 } },
    { "check": "redirects", "status": "pass", "message": "No redirects detected." },
    { "check": "response_time", "status": "pass", "message": "Response time: 241ms.", "details": { "response_time_ms": 241 } }
  ],
  "status_code": 200,
  "response_time_ms": 241,
  "validated_at": "2026-07-03T10:01:30.000Z"
}

A valid: true result means the destination URL resolves correctly and query parameters survive to the final page load. If valid is false, the checks array pinpoints the failing hop. The most common failure modes for Admitad programmes are server-side redirect configurations that normalize query strings, HTTP-to-HTTPS upgrade redirects on regional servers that do not preserve query parameters, and e-commerce platform canonical URL enforcements on deep-linked product pages. For a detailed walkthrough of diagnosing redirect chain failures, see how to check if a redirect strips UTM parameters.

Admitad UTM tracking gotchas for advertisers

Configure UTM parameters on the destination URL, not on the Admitad publisher link

Admitad generates publisher-facing tracking links in a format controlled by the platform. As an advertiser, you do not directly control the structure of the publisher link. The configuration point you own is the Landing Page URL or Destination URL in the Admitad advertiser interface for your programme. Paste the UTM-tagged URL generated by mlz build there. When a publisher’s Admitad link is clicked, the network routes through ad.admitad.com and forwards to your configured destination URL, delivering the UTM parameters to your landing page.

Admitad subIDs and UTM parameters must coexist in the redirect chain

Admitad’s subID system (subid1–subid8) is a publisher-side tracking mechanism, separate from UTM parameters. Publishers append subIDs to their affiliate links to identify internal traffic segments. Both subIDs and UTM parameters travel through the Admitad redirect chain. Some server-side redirect configurations that normalize query strings or apply query-string whitelists can inadvertently strip UTM parameters while preserving subIDs (or vice versa), because the server treats them as separate parameter sets. If mlz check shows redirects stripping parameters, confirm that both parameter types are being forwarded by your server’s redirect handler.

Regional Admitad platforms may route through different server infrastructure

Admitad operates regional platforms (EU, CIS, APAC, MENA, LATAM) with separate technical infrastructure. Destination URLs configured for one regional platform may behave differently when accessed from another region’s servers, particularly if your site uses CDN geo-routing that applies different redirect rules by region. For advertisers running the same programme across multiple Admitad regional platforms, validate the destination URL from each regional configuration using mlz check before activating each regional programme.

HTTP-to-HTTPS redirect on regional servers can strip query parameters

Advertisers operating in regions where HTTPS adoption was more recent sometimes have regional subdomains or country-specific landing pages that still perform HTTP-to-HTTPS upgrades via server-side redirects. If these redirects were configured before query-string preservation was standard practice, they may strip UTM parameters during the upgrade hop. Test any regional landing page URL — particularly those on country-specific subdomains — with mlz check before entering it into the Admitad advertiser interface.

Casing inconsistency across regional Admitad programme configurations fragments GA4 reporting

Advertisers running Admitad programmes across multiple regional platforms often have separate teams managing each region’s UTM configuration, introducing casing variations: utm_source=Admitad in the EU programme, utm_source=admitad in the APAC programme. GA4 is case-sensitive and records these as separate sources. mlz build automatically lowercases all input values and replaces spaces with hyphens, producing consistent output regardless of input. For the full explanation of GA4 case sensitivity, see are UTM parameters case sensitive in GA4?

Frequently asked questions

Where do I add UTM parameters in Admitad?

In the Admitad advertiser interface, navigate to your programme settings and find the Landing Page URL or Destination URL field. This is where you paste the UTM-tagged URL generated by mlz build. The URL format is: https://shop.example.com/landing?utm_source=admitad&utm_medium=affiliate&utm_campaign=global-promo-q3-2026. Admitad will use this as the final destination when routing publisher clicks through its tracking redirect. For programmes with multiple creative types or categories, use utm_content to differentiate them within the same programme URL.

How do Admitad subIDs interact with UTM parameters?

Admitad subIDs (subid1–subid8) are publisher-side parameters that publishers add to their affiliate links to identify their own internal traffic sources. They travel through the Admitad redirect chain independently of your UTM parameters. Both sets of parameters should survive the redirect to your landing page. Your server’s redirect configuration needs to forward all query parameters — not just a whitelist of known parameter names — to preserve both subIDs and UTM values through any intermediate redirect your server performs. Use mlz check on the destination URL to confirm parameters survive before activating your programme.

What utm_source value should I use for Admitad traffic?

Use utm_source=admitad as the baseline for all Admitad network traffic. For advertisers running separate programmes on different Admitad regional platforms who want region-level attribution in GA4, use utm_source=admitad-eu, utm_source=admitad-apac, and so on. Keep all values lowercase and hyphenated — mlz build enforces this automatically. Set utm_medium=affiliate consistently across all affiliate network traffic so GA4’s default channel grouping correctly identifies the Affiliate channel.

Does Admitad’s tracking redirect strip UTM parameters?

Admitad’s ad.admitad.com redirect is designed to forward the advertiser-configured destination URL intact, including all query parameters. Parameter stripping typically occurs on the advertiser’s server side after Admitad delivers the visitor: server-side redirect rules that normalize query strings, HTTP-to-HTTPS upgrade redirects that do not preserve the query string, or e-commerce platform canonical URL enforcement on deep-linked product pages. Run mlz check against your destination URL to confirm parameters survive the full chain to the final page load before activating your Admitad programme.

Should I validate Admitad destination URLs in an automated pipeline?

For programmes running across multiple Admitad regional platforms or with a large number of product-specific deep-link destination URLs, automated validation is a practical safeguard. Use mlz check in a script that tests each destination URL before it is submitted to the Admitad interface, failing the submission if any URL returns valid: false. This prevents infrastructure changes — CDN geo-routing updates, server configuration deployments, e-commerce platform upgrades — from silently breaking affiliate attribution across active Admitad regional programmes. For a complete implementation guide including GitHub Actions workflow templates, see automating campaign link validation in CI/CD.