How it works, answered properly.

Alion sits between your traffic and your buyers' systems: it sends every lead to the right buyer, tracks what happens to it, and works out exactly what you are owed.

No. Your buyers keep whatever system they already use. Alion is the layer that decides where leads go, delivers them, and reconciles the money afterwards. It never asks your buyers to change anything on their side.

No, and it is not meant to. Your tracker measures your traffic and your spend, which is the half of the equation before the form is submitted. Alion handles everything after. Click IDs from Binom, Keitaro, Voluum and RedTrack are recognised and carried through to postbacks, so conversions land back in your tracker automatically and the two halves finally add up.

Yes, all of them. Those tools work on getting traffic to your page. Alion starts once a lead exists. Nothing in your current stack gets replaced.

Anyone running paid traffic and getting paid on results across more than one buyer. Media buyers, affiliates, affiliate networks and agencies. The point where it starts paying for itself is usually two or more buyers and enough daily volume that spreadsheets have become a real job.

Less so. With one buyer you get fraud filtering, the delivery audit trail and automatic revenue tracking, which are all real, but the routing and recycling sides only matter once there is somewhere else for a lead to go.

You build a rule structure that branches on traffic source, landing page, country and language, in whatever order suits you. Each branch ends in a pool of possible flows with a weight on each, so you can send 70 percent of German native traffic to one buyer and 30 to another. Every new campaign or GEO drops into the same logic without a manual handoff.

The next buyer in the fallback chain is tried automatically. Every flow in the pool becomes an ordered backup, so a rejection costs you a few seconds instead of the lead.

Same mechanism. The lead moves on, and the failure is recorded with the exact request sent and the exact response received. When you raise it with the buyer later, you are quoting their own system back to them rather than describing it from memory.

Yes. Performance mode recalculates weights every 30 minutes using trailing earnings per delivery, moving volume toward whoever is actually paying. New flows keep a guaranteed floor of traffic so they get a fair sample before being judged.

Any buyer whose daily, weekly or contract cap is full is removed from that lead's candidate list before the decision is made. It is checked on every routing attempt with no queue or pending state, so overdelivery is structurally impossible rather than something you catch at month end.

Yes. Caps resolve as a specific date override first, then a day-of-week rule, then unlimited. A buyer who takes 200 Monday to Thursday, 50 on Friday and nothing on holidays is a normal setup, not an edge case.

You set remaining-capacity thresholds per agreement and get a Telegram alert, normally at 80 percent, so you can rebalance before traffic starts going nowhere. Alerts are deduplicated, so the same threshold never spams the team twice.

Every lead is scored on four signals together: IP, email, phone and device fingerprint. On top of that there are 22 independently configurable checks covering IP reputation, email quality, phone quality, device and behavioral signals, and geo consistency. You decide which ones are on.

VPNs, proxies, Tor exit nodes, datacenter addresses, disposable email domains, honeypot addresses and dead phone numbers, at intake. Geo consistency checks then compare what a lead claims against what its IP and phone number say, which is what catches a German form fill arriving from another country with a mismatched prefix.

Matching runs on email, phone or IP. Once a lead is flagged as a duplicate it is permanently blocked from redelivery to any destination in its chain, and to every other system belonging to that same buyer. That last part is what stops the same person being sold twice to one buyer through two different routes.

The full duplicate chain: the original, every copy that followed, which specific field matched, and where each one was delivered. It takes seconds rather than a database query.

Leads keep flowing and get scored retroactively once the provider recovers. After five consecutive failures a circuit breaker opens for a short period, which protects live traffic from retry storms instead of stalling your intake behind somebody else's outage.

Two ways, and most setups use both. Buyers can push status changes to Alion the moment they happen, or Alion pulls updates from them on a schedule. Either way you are not waiting for a morning CSV.

Each buyer's own status strings map into one shared vocabulary of 27 canonical statuses, so FTD means FTD no matter which buyer said it. Anything unmapped surfaces in a triage panel instead of disappearing quietly, and the buyer never has to change their system.

No. Status changes are stored as new permanent rows and never overwrite the previous one, so the full sequence stays available. If a buyer says a lead was always unqualified and you remember a callback last week, the record settles it.

Yes. You configure a sub-flow that fires whenever a lead reaches a chosen status. Firing a conversion postback the moment a lead hits FTD is the most common use, since your ad platform can only optimise on conversions it knows about.

CPL, CPA, hybrid and CRG, all at the same time, priced separately per buyer and per country. They are native rather than bolted on, which matters because modelling four models at once in a spreadsheet is exactly where reconciliation errors start.

Nothing. Pricing is versioned: a price change creates a new version and never overwrites the old one. Every delivered lead also captures the agreement terms as they stood at that exact moment, so what you were owed in March cannot be rewritten by a June negotiation. This is the single most important protection in the platform.

Contracted volume times contracted conversion rate produces a guaranteed per-lead rate. Three scenarios, seller protected, buyer protected and seller capped, make explicit who carries over- and under-performance before a batch closes, rather than after.

Yes, and every historical FTD gets re-evaluated against the new cap. A dry run shows exactly what would flip before anything commits, so you see the financial consequence first.

Yes. You configure which bad-status leads get taken off billing, so your expected revenue matches what a buyer actually remits instead of always sitting higher than reality.

Automatically, oldest first, with partial settlement supported. A fresh pass runs on every delivery, payment and conversion confirmation. Matching payments to leads by hand is the largest time cost in lead operations and the place money quietly goes missing.

Historical revenue can be re-priced after an agreement correction, with a preview that flags overpayment and underpayment risk on money you have already settled, so you see the damage before committing rather than discovering it later.

No. A buyer is connected by filling in a request template with variable substitution and header authentication, then picking the fields you want out of their response with an interactive picker. If a buyer accepts leads over HTTP, you can connect them yourself.

No. There is no integration list. Anything with an API or a webhook can be connected today.

Under an hour for a first live route: one buyer, one country agreement, one destination, one flow. Everything after that is minutes each.

Five destination types are supported: a buyer's CRM, a postback URL, Telegram, email and a generic webhook. Pass-through flows fire extra deliveries in parallel with the main routing decision, so your tracker and your team hear about every lead without affecting where it actually goes.

No, and this is worth understanding. Many systems reply with HTTP 200 and bury an error inside the response body. Success here is judged on the body rather than the status code, so failures do not get recorded as successes and you do not bill for leads that never landed.

Yes, by CSV.

A lead nobody converted still has value. Recycling re-routes unconverted leads to different buyers, matched on country, traffic source, campaign, original destination and current status. Most operators leave this money alone because doing it by hand is not worth the effort.

A lead is never re-sent to a destination it has already reached, and converted leads are unconditionally excluded from recycling. Reselling a lead that already deposited is the worst mistake available in this business, so it is blocked structurally rather than by policy.

Yes. Geo eligibility is verified before a lead is assigned and again right before it is sent, and the split across target buyers uses exact proportions rather than random assignment, so the distribution you configured is the one you get.

No, it runs on a schedule. Recycling only earns money if it happens consistently, which manual processes never do.

Separation is enforced at the database level rather than in application code, so one workspace structurally cannot read another's data. You are routing commercially sensitive lead data, so isolation should not depend on careful coding.

Yes, and these are separate controls. There are 25 independent permissions, deny by default, so a media buyer can see lead flow without seeing what you pay per lead. Separately, phone, email, IP and buyer contact details can each be masked per user. Owners always see the real data.

No. One account can belong to several workspaces, each with its own role, which is how agencies and consultants keep clients apart without juggling credentials.

No. The public ingestion endpoint is locked to a landing page identifier, with an optional server IP allowlist on top.

Yes. One month free, automatic on signup, no card required. A month is long enough to see how your own traffic actually behaves.

Three plans. 399 a month for small teams with clear limits, 1,399 a month for unlimited routing and full feature access, and custom pricing for high volume operations that need dedicated infrastructure and custom SLAs.

Card through Stripe, with instant prorated upgrades, or crypto through Coinbase Commerce. A large share of this industry does not or cannot pay by card, so both are first class.

It stops and prompts an upgrade. Nothing is ever billed as overage, so a traffic spike cannot turn into a surprise invoice.