[ALION]
Everything, in detail

Every feature, every problem it kills.

On this page
01 5 features

Lead Routing & Distribution

Every lead goes to the right buyer on its own, split by whatever rules you set, with a backup buyer ready when one says no.

Tier-1 English leads from a native source and tier-3 push traffic shouldn't land on the same desk, but sending everything to one buyer or splitting it by hand is usually the only alternative on offer. Alion routes on up to four dimensions, traffic source, landing page, country, language, in any order you choose, with each branch ending in a weighted pool of flows.

Example
German push traffic goes to buyer A. German native traffic goes to buyer B.

A buyer's CRM going down used to mean lost leads. Each lead draws a primary flow by weight, and every other flow in the pool becomes an ordered fallback, if the first buyer rejects it, the next one is tried automatically.

Example
70 percent to buyer A, 30 to buyer B. If A rejects it, B gets it anyway.

Manually rebalancing weights as buyer performance shifts is a weekly chore nobody actually does. Alion recalculates routing weights every 30 minutes based on trailing earnings per delivery, moving volume toward what's actually paying, continuously, while new flows still get a guaranteed floor of traffic to build a sample.

Example
Buyer A earns you 12 per delivery, buyer B earns 7. A starts getting more.

Leads sent over cap are unpaid leads. Any buyer whose daily, weekly, or contract cap is full is silently removed from that lead's candidate list, making overdelivery structurally impossible instead of something you catch at month end.

Example
Buyer caps at 200 a day. Lead 201 goes somewhere else instead of nowhere.

Your tracker and your internal systems need to know about every lead, not just the one a buyer happens to win. Fire an additional delivery, a postback, a Telegram message, an internal webhook, in parallel with the main routing decision, without it affecting the outcome.

Example
Every lead also fires your Keitaro postback and a message to your team chat.

02 5 features

Lead Quality & Fraud Protection

Junk gets caught before a buyer ever sees it, so you stop paying for bots, recycled phone numbers and traffic pretending to be somewhere it is not.

Sending junk to a buyer costs you the lead fee and the relationship. Every lead is scored on IP, email, phone, and device fingerprint through IPQS, and if the fraud provider goes down, leads keep flowing and get enriched retroactively instead of stalling.

Example
A datacenter IP with a disposable email scores high and gets held back.

Buyers reject leads for reasons they rarely explain, so your rejection rate stays a mystery. 22 independently configurable checks, IP reputation, email quality, phone quality, device and behavioral signals, and geo consistency, catch most of it before delivery.

Example
Turn on VPN blocking and phone validation, leave email quality off.

Selling the same lead twice to the same buyer is the fastest way to lose an account. Matches on email, phone, or IP, and once flagged, a duplicate is permanently blocked from redelivery to any destination in its chain, and to every other CRM belonging to that same buyer.

Example
Same phone number, same buyer, three days apart. Blocked automatically.

When a buyer disputes a duplicate, you need the full picture in seconds, not a database query. Walk a lead's entire duplicate history, back to the original and out to every descendant, showing which field matched and where each one landed.

Example
Shows the original from March and the two copies that followed it.

A third-party outage shouldn't take down your lead intake. Five consecutive fraud-provider failures opens a short circuit that protects live traffic from retry storms while the provider recovers.

Example
Provider is down ten minutes. Leads deliver, scores fill in afterwards.

03 6 features

Status Tracking

Four buyers speaking four different languages about the same lead, turned into one set of statuses you can actually compare.

Four buyers means four different status vocabularies and no way to compare them. Every lead outcome resolves to one shared vocabulary, FTD, Callback, No Answer, Unqualified, and 23 more, making buyer quality directly comparable for the first time.

You shouldn't have to ask a buyer to change their systems just to work with you. Each buyer's own status strings map into the canonical taxonomy, and anything unmapped surfaces in a triage panel instead of silently disappearing.

When a buyer insists a lead was always Unqualified and you remember it as a Callback last week, someone has to be provably right. Status changes are recorded as permanent rows, never overwritten, so the full sequence stays available.

Finding out about an FTD the next morning is a day too late. Buyers push status changes to Alion in real time instead of waiting on a scheduled reconciliation.

Your ad platform can only optimize on conversions it actually knows about. Configure a sub-flow that fires automatically whenever a lead hits a chosen status, most commonly a conversion postback the moment it reaches FTD.

"Show me leads no buyer converted" and "show me leads someone marked Callback at some point" are different questions, and most tools only answer one of them. Filter by last recorded status, status at every buyer, status at any buyer, or ever-had status.

04 7 features

Revenue & Commercial Agreements

Every payout model your buyers actually use, priced per country, versioned so old leads keep the old terms no matter what you renegotiate later.

Real buyer relationships run CPL, CPA, Hybrid, and CRG all at once, and modelling that in a spreadsheet is exactly where reconciliation errors start. All four are natively supported here, not bolted on.

The rate you agreed in March should still be the rate that applies to March's leads, no matter what you renegotiate in June. Pricing is set per buyer and per country, versioned over time, a price change creates a new version and never overwrites the old one.

Later configuration changes shouldn't be able to silently rewrite what you were owed on historical leads. Every delivered lead creates an immutable revenue event capturing the agreement terms exactly as they stood at that moment, the single most important protection in the platform.

CRG deals are where the most money and the most arguments live. Contracted volume times contracted conversion rate produces a guaranteed per-lead rate, and three scenarios, Seller Protected, Buyer Protected, Seller Capped, make explicit who carries over- and under-performance before a batch closes.

Renegotiating volume mid-contract is routine. Finding out the financial consequence after the fact is not something you want. Change a cap on a live CRG batch and every historical FTD gets re-evaluated against it, with a dry-run preview showing exactly what would flip before anything commits.

Buyers deduct for bad leads whether or not your own numbers reflect it. Configure which bad-status leads get haircut from billing so your expected revenue actually matches their remittance.

Matching payments to leads by hand is the single largest time cost in lead operations, and it's where money quietly goes missing. Payments are allocated against revenue events oldest-first, automatically, with partial settlement supported and a fresh pass triggered on every delivery, payment, or FTD confirmation.

05 6 features

Cap Management

Daily, weekly and contract limits enforced on every single lead, so overdelivery is not something you discover at month end.

Correcting a pricing mistake normally means either living with it or breaking your settled accounts. This re-prices historical revenue after an agreement correction, with a preview that flags overpayment and underpayment risk on money already settled, showing the consequence before you commit.

Contracts have limits, and enforcing them in a spreadsheet just means arguing about overdelivery later. A contractual ceiling per version stops delivery permanently once it's reached, until a new version opens.

Buyers give you limits at different granularities, and all three need enforcing at once. Overall contract cap, weekly cap resetting Monday 00:00 UTC, and daily cap resetting at midnight UTC, evaluated in that order.

A desk that takes 200 leads Monday to Thursday, 50 on Friday, and nothing on holidays is a normal arrangement, not an edge case. Daily caps resolve as a specific date override, then a day-of-week rule, then unlimited.

Batch cap checks let leads slip through in the gap between checks. Caps are checked on every routing attempt, no queue, no pending state, making overdelivery structurally impossible.

Discovering you filled a cap at 2pm means four hours of traffic went nowhere. Set remaining-capacity thresholds per agreement and get alerted at 80% so you can rebalance before it happens, deduplicated so the same threshold never spams the team twice.

06 7 features

Delivery & Integration

Connect any buyer that takes leads over HTTP, and keep proof of exactly what you sent and what came back.

There's no fixed integration list to wait for. Requests build from a JSON template with variable substitution and header-based authentication, if a buyer accepts leads over HTTP, you can connect them today.

A lead needs to reach the buyer, your tracker, and often your own team. CRM, Postback, Telegram, Email, and generic Webhook, one system handles all of it.

Many CRMs return HTTP 200 with an error buried inside the JSON. Without catching that, you record failures as successes and bill for leads that never landed, so success is defined by the response body, not just the status code.

The buyer's own lead ID is what makes later reconciliation possible. Pull it, along with an auto-login URL or status, straight out of the response with an interactive picker, no manual step required.

"We never received that lead" is the most common dispute in this business. Every attempt is recorded immutably, the exact request, the exact response, and a reconstructed curl command you can replay, ending the argument with evidence instead of memory.

Attribution has to survive the whole journey from click to FTD. Click IDs from Binom, Keitaro, Voluum, RedTrack, and ad platforms like Taboola, Google, Meta, and MGID are recognized and carried through to postbacks automatically.

Running several trackers or ad sources means each needs its own conversion endpoint. Postbacks are selected by tracker match, then traffic source match, then universal fallback, chosen automatically per lead.

07 6 features

Lead Recycling

A lead nobody converted is not a dead lead. Send it back out, without ever resending it somewhere it already went.

A No Answer lead is not a dead lead, most operators leave this money on the table because moving leads manually isn't worth the effort. Re-route unconverted leads to new buyers by matching country, traffic source, campaign, original destination, and current status.

An approximate split drifts over time instead of holding to what you configured. Leads are split across target buyers using exact proportions, not random assignment.

Re-sending a lead to a buyer who already rejected it damages the relationship and never gets paid. A lead is never re-sent to a destination it's already reached.

Reselling a lead that already deposited is the worst mistake available in this business. Converted leads are unconditionally excluded from recycling, it simply cannot happen.

Recycled leads are still leads, they have to follow the same commercial rules as fresh traffic. Eligibility is verified before a lead is assigned and again right before it's sent.

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

08 4 features

Reporting & Analytics

The numbers behind the decision you keep having to make: which buyer, which country and which source is actually worth the traffic.

"Which geo and source combination actually makes money at which buyer" is a four-dimensional question, and most reporting only answers one dimension at a time. Group by up to four levels across buyers, countries, agreement versions, traffic sources, and statuses.

The numbers you check every morning aren't the ones you check at month end. Build a drag-and-resize widget board and save it as a named template per view.

When a buyer disputes an invoice, you need to reach the individual lead level in three clicks, not thirty. Drill from country, to agreement version, to the individual leads.

Comparing buyer profitability side by side is the decision the whole system exists to support. One flat feed spans every buyer, country, version, and traffic source at once.

09 6 features

Security & Team Management

Your data stays yours, your team sees only what the job needs, and customer personal data stays hidden from everyone who does not need it.

You're routing commercially sensitive lead data, isolation has to be structural, not a matter of careful coding. Tenant separation is enforced at the database level, not just the application layer.

A media buyer needs to see lead flow. They don't need to see payout rates. 25 independent permissions, deny-by-default, so access matches the job, not a role template.

Team members and contractors need to do their jobs without ever seeing customer personal data. Phone, email, IP, and buyer contact details mask independently per user, owners always see the real data.

Agencies and consultants work across several operations without wanting to juggle logins. One account can belong to several workspaces, each with its own role.

A traffic burst or a misconfigured lander shouldn't degrade the platform for anyone else. Rate limiting is partitioned by workspace, not by IP.

Only your landers should be able to submit leads to your workspace. The public ingestion endpoint is locked to a landing page identifier, with an optional server IP allowlist.

10 4 features

Platform & Account

Sign up, pay how you want, and know that a traffic spike will never turn into a surprise invoice.

Another platform, another password, is how credentials end up reused and eventually leaked. Sign in with the account you already trust, or use email with hashing strong enough that a database breach doesn't hand out working passwords.

You shouldn't have to hand over a card number to find out whether a system fits how your traffic actually moves. Automatic on signup, no card required, a month is enough to know.

A large share of this industry does not or cannot pay by card. Stripe handles cards with instant prorated upgrades, Coinbase Commerce handles crypto.

Nobody wants to discover a usage bill after a traffic spike. Reaching a plan limit blocks and prompts an upgrade, nothing is ever billed as overage.