What Is a TDS in Affiliate Marketing? Traffic Distribution System

A TDS, short for traffic distribution system, is a service that sits between your ad and your offer. The ad points to a TDS link, and the TDS decides in a few milliseconds where each click goes: which offer, which landing page, or which fallback page. The decision depends on rules you wrote in advance.

If you search "what is a TDS in affiliate marketing" you will find definitions that range from a one-line redirect to a full tracker. This article sticks to the practical meaning: what happens to a click, what you can do with a TDS, how it differs from a plain redirect and a URL shortener, and what to check before you pick one.

What happens to a click

Follow one click from start to finish. Someone sees your ad on a social network, a push notification or a native widget and taps it. The ad's destination URL is not your offer. It is a link on your own domain that belongs to the TDS.

1. The request reaches the TDS. The browser asks your domain for the link. The TDS receives the IP address, the user agent, the language header, the referrer and any URL parameters your ad network appended.
2. The TDS enriches the click. From the IP and headers it works out the country, the city, the provider, the device type, the operating system and the browser.
3. The bot check runs. The click is compared against the filter you configured. A visitor that looks like a data-center address, a headless browser or an empty-header script is marked as a bot.
4. Rules are evaluated. Humans go through your routing rules. In most systems they are read from the top down, and the first rule that matches wins.
5. The visitor is sent on. The TDS answers with a redirect (or serves a page) and the visitor lands on the offer or landing page. Bots go to a page you set for them.
6. The click is logged. The record keeps the time, the geo, the device, the decision and, for filtered clicks, the reason.

All of this takes a fraction of a second, and the visitor sees only a brief redirect. What matters for you is step 4: the logic lives in the TDS, not in the ad. You can change it at any moment and the ad stays exactly as it was approved.

What a TDS is used for

Splitting traffic by geo and device

A single campaign often brings visitors from several countries on several kinds of phones. Offers rarely accept all of them. A typical rule set looks like this: visitors from Germany on Android go to offer A, visitors from Germany on iOS go to offer B, everyone else goes to the main URL. The conditions that matter most in practice are country, city, device type, OS, browser, provider and language. The geo side is covered in more detail in Geo redirects without the headache.

Split tests

If two landing pages might perform differently, you want to send equal shares of traffic to each and compare. In a TDS you list both URLs in one rule and each click picks one at random. For uneven shares, such as 50/30/20 across three offers, a rotator with weights does the same job and the shares can be changed later without touching the link.

Bot filtering

Paid traffic always carries some share of automated clicks: scanners, crawlers, scripts, sometimes proxies and data-center addresses. You pay for them, they inflate click counts, and they skew your conversion rate. A TDS checks each click against a set of signals and sends the suspicious ones to a page you choose, so offers and landers see mostly real visitors. How the signals differ and where each one fails is explained in JS fingerprint vs IP blocking.

Swapping offers without touching the ad

Offers get paused, caps run out, payouts drop. If the ad points straight at the offer link, every change means editing the ad, which can mean a fresh review and a reset in the delivery system. With a TDS link in the ad you change the destination in one place and the ad itself is left alone.

Time-based and referrer-based rules

Some offers only convert, or only accept leads, during certain hours or days. A time-of-day or day-of-week condition handles that. Referrer conditions let you treat traffic from one placement differently from another, as long as the source passes a referrer at all.

TDS vs a plain redirect vs a URL shortener

These three are often mixed up because all of them take a link and send someone to another link. The difference is how much the system knows about the visitor and how many outcomes it can produce.

A plain redirect, for example a 301 in a web server config, always does the same thing for everyone. A shortener makes a link shorter and counts visits, and some let you edit the target. Neither one makes a decision per visitor. If you need "this visitor here, that visitor there", you need a TDS. We go deeper on the difference between a smart link and a dumb redirect in Smart link vs dumb redirect.

How the visitor actually gets moved

"Redirect" covers several mechanisms, and a TDS usually supports more than one. The common ones are the HTTP redirects 301 and 302, a meta refresh tag, a JavaScript redirect, and serving a page inside an iframe. Some systems add double meta refresh, a button the visitor presses, a preloader screen or an image redirect. TDS.SO lists 10 or more methods, including a landing page served on your own domain.

Which one to use depends on the source and on what you want to measure. A 302 is the usual default for routing because it tells browsers and caches that the destination may change. A 301 says the move is permanent, so browsers may cache it, which is a poor fit when you rotate offers. JavaScript and meta-based methods let you run a browser check or pass along the referrer in different ways. Check what your traffic source allows before you pick one. The page on redirect methods lists what TDS.SO supports.

Cloud or self-hosted

A TDS runs either as a hosted service or as software you install on your own server. Both exist and both work. The trade-offs are practical.

• Self-hosted means you rent a server, install the software, keep it updated, secure it and watch its load. You control the data and the configuration, and you carry the maintenance. Capacity depends on your hardware, so a traffic spike can hit your server directly.
• Cloud means the vendor runs the infrastructure. You connect a domain, create links and write rules. You depend on the vendor's uptime and on their pricing model, and you do not get to tune the machine.

Both approaches expect you to use your own domain for tracking links, since a shared domain used by many customers is easy for ad networks and browsers to flag. In TDS.SO you point the domain's A record to your server, add domains as a list, and SSL is issued automatically.

What to look for when choosing

Features lists look similar across products, so check the details that cost you money when they are missing.

1. Condition coverage. Can you route by country, city, device model, OS, browser, provider, language, referrer, URL parameters and time? Can you combine them with AND and OR?
2. Rule order and fallback. You should be able to see which rule fires first and what happens when nothing matches. A clear default URL prevents lost clicks.
3. Bot filtering that you can tune. A single on/off switch is too blunt. Look for levels, individual signals such as data center, VPN or empty referrer, and a way to send filtered clicks to a page you set.
4. The click log. You need to see each click with its geo, device, referrer and the reason it was filtered or routed. Without that you cannot debug a rule.
5. Redirect methods. Sources and browsers treat 301, 302, JavaScript and meta refresh differently, so it helps to have a choice that fits the source's rules.
6. Domain handling. Can you attach your own domains, how is SSL handled, and does the system check domains for blocks?
7. Limits and pricing. Some services cap clicks, domains or links per plan. Work out your monthly click volume and see what you would pay at that level.
8. Conversion tracking. If you need postbacks and ROI in the same place, check whether the product has a tracker or whether you will pair it with another tool. See Tracker vs TDS for how to decide.

A worked example

Say you buy 1,000 clicks at $0.10 each, so $100, from a push network. Hypothetically, 600 clicks come from country A, 300 from country B and 100 from elsewhere. Offer X pays only in country A on Android. Offer Y pays in country B on any device. You also have a generic offer Z that accepts almost anyone at a lower payout.

The rules, top to bottom, would be:

1. Country A and OS Android: offer X.
2. Country B: offer Y.
3. No match: the main URL, which points to offer Z.

Before the rules run, the bot filter removes, say, 80 clicks that came from data centers. Those 80 go to a page you set and are logged with the reason. The remaining 920 are routed. You still paid for the 80, but you know about them, and you can ask the source for a refund or exclude that placement.

Next week offer X is paused. You open the rule in the dashboard, replace the URL with offer W, and save. The ad was not touched and the link is the same.

A note on the term

"TDS" is also used in security research for malicious redirect chains, where compromised sites send visitors through a series of hops to scam or malware pages. That is a different thing. An affiliate TDS routes your own paid traffic, bought on your own account, to offers you chose to promote. If you came across the term in a security report, the context will usually make clear which one is meant.

Setting one up, step by step

The details vary by product, but the sequence is similar everywhere.

1. Attach a domain. Point its A record at your server and wait for the certificate.
2. Create a link and set the main URL. This is the fallback for every click that matches nothing.
3. Add rules from the most specific to the most general, since the first match wins.
4. Choose the bot filter level and the page for filtered clicks. Start at a standard level and tighten it once you see what gets caught.
5. Put the TDS link into the ad, adding the parameters your source supports.
6. Send a few test clicks from different devices or a VPN, then read the click log and confirm each one landed where you expected.

Do step 6 before you spend real budget. A rule that is one position too low will quietly send everyone to the fallback, and you will only notice from the numbers.

FAQ

Is a TDS the same as a tracker?

Not exactly. A TDS focuses on deciding where a click goes. A tracker focuses on recording what happened afterwards, such as conversions, revenue and cost. Many products combine both. The longer comparison is in Tracker vs TDS.

Do I need a TDS if I run one offer on one landing page?

Not for routing. You may still want bot filtering and a click log, and a TDS link lets you change the offer later without editing the ad. If you run a single offer and never change it, a direct link is simpler.

Does a TDS slow the click down?

It adds one extra hop, so there is some added latency. A well-run service keeps it small, but it depends on where the service is hosted relative to your visitors. Test with a few clicks and look at the load time from your target countries.

Can I use a TDS with any traffic source?

A TDS link is an ordinary URL, so it works anywhere a destination URL can be entered. Each ad network has its own rules about redirects and landing pages, so read the policy of the network you buy from and follow it.

What is the difference between cloud and self-hosted?

With self-hosted software you run and maintain the server yourself. With a cloud service the vendor does that and you manage domains, links and rules. The right choice depends on how much maintenance you want to carry and how much control over the machine you need.

If you want to try the cloud route, TDS.SO has traffic filtering and redirect rules on every plan with unlimited clicks, domains and links, and plans start at $9.99 per week. See pricing for the details.