Trust and quality
Traffic and
ad quality.
Real people, authorized sellers, clean ads. Zurla, a large language model made for advertising, keeps invalid traffic out before the auction, checks again after the ad runs and scans every ad before it serves.
-
Website · Pellbrook Media · last week
3,120
bot requests kept out of the auction
-
App · Brindle Blocks · two weeks in
2,480
emulator requests kept out of the auction
-
Every ad · before it serves
Scanned
for malware, forced redirects and heavy files
Illustrative data
Before the auction
Bad traffic stays out.
Buyers bid with confidence.
Before any buyer sees a request, Zurla checks four things: a real person is behind it, the seller is authorized, the page is safe and the person’s privacy choices are read. Here it is at work for Orrinth Exchange, an RTB platform that runs on Zurla under its own brand.
Brisvale’s weather app tripled its requests at noon. What reached our bidders?
Brisvale’s real traffic, all of it. Two of every three new requests came from computers in data centers posing as the app, and I kept those out.
- Checked on arrival: data-center addresses
- Those requests kept out before the auction
- Brisvale’s real app traffic untouched
- Details sent to Brisvale’s team
Will buyers see any of it?
None of the requests I kept out. My checks after ads serve add a second layer.
- Reasons shown in Brisvale’s partner dashboard
Fake traffic kept outBefore the auction
Requests posing as Brisvale’s weather app are kept out before the auction, and Brisvale’s real traffic still reaches bidders. 6.5% of today’s requests were kept out before any buyer saw them, and more checks run after ads serve.
How it works
Checked before the auction.
Checked again after the ad runs.
Some invalid traffic is easy to spot on arrival. Some is built to look human and takes more signals to find. So Zurla checks twice, and what it learns after serving feeds the checks before the next auction.
Before the auction
Every request, on arrival
General invalid traffic (GIVT) · a few milliseconds
- Real peopleKnown bots, crawlers and data-center addresses kept out
- Authorized sellerThe site’s ads.txt or the app’s app-ads.txt, matched to sellers.json
- Real site or appThe domain, or the app’s bundle ID and store listing, matches the request
- Privacy choices readIAB TCF v2.3 and GPP, before anything is sent
- New ads scannedMalware, forced redirects and file size, before an ad can serve
Between the two layers, the auction runs in under 100 ms, then the ad runs.
After the ad runs
Signals that take longer to read
Sophisticated invalid traffic (SIVT) · from serving on
- Emulators and device farmsSoftware posing as phones, and racks of phones run by scripts
- SDK spoofingFake requests that pretend to come from a real app
- Live ads watchedAn ad that changes once it’s live is blocked from every later auction
- Verification signalsYour verification company’s signals feed the same checks
What layer 2 flags is kept out of later auctions
Ad quality
Clean ads,
scanned before they serve.
Zurla scans each new ad before it can win an auction: for malware, for forced redirects that send people to another page or an app store without a tap, and for heavy files that slow a page down. Once an ad is live, Zurla keeps watching it.
Tovrin & Co. sent a new ad this morning. Is it cleared to run on our pages?
Yes. I scanned it before it could serve, and it passed every check.
- No malware
- No redirect without a click
- File size within your limit
- Set to run in a sealed frame
Ad clearedBefore it served
Plain words
The terms,
without the jargon.
- Invalid trafficAlso called IVT
- Ad requests and views that don’t come from a real person: bots, scripts and fake devices. Buyers want real people, so Zurla keeps it out.
- General invalid trafficAlso called GIVT
- The kind that’s easy to spot on arrival: declared crawlers, known bots and requests from data centers. Zurla filters it before the auction.
- Sophisticated invalid trafficAlso called SIVT
- Traffic built to look human, such as emulators, device farms and SDK spoofing. It takes more signals to find, so Zurla checks after the ad serves and keeps what it flags out of later auctions.
- Data-center traffic
- Requests from servers in data centers, not from people’s phones and computers. Servers don’t read pages or play games, so these requests never reach buyers.
- Authorized seller
- A company a site or app lists in its ads.txt or app-ads.txt file, and that lists the site or app in its sellers.json. Zurla checks both ends. More in ads.txt and sellers.json.
- Ad scanning
- Checking an ad before it serves: for malware, for forced redirects (sending people to another page or an app store without a tap) and for heavy files. Live ads are watched too.
On every side
The same checks
on every side.
Publishers, app developers, agencies and RTB platforms all get both layers. What changes is what each one needs checked.
Publishers
Real readers.
Ads that leave your page alone.
On the Zurla SDK or a programmatic integration, every request from your pages is checked before Zurla’s buyers see it, and every ad is scanned before it reaches your page.
Zurla for publishers- Invalid traffic
- Known bots filtered before the auction (GIVT), with deeper checks (SIVT) after the ad serves
- Ad scanning
- Creatives scanned for malware and forced redirects before they serve
- Heavy ads stopped
- Creatives over a size limit are blocked before they serve, and ads that misbehave at run time are removed
- Sealed ads
- Banners run in a sealed frame that can’t read or change your page. Native ads are drawn from plain parts, and any tracking script a buyer sends runs in a sealed frame, or is refused.
App developers
Real players.
Real phones.
Your app runs Zurla’s SDK, and Zurla runs the mediation itself, so every request is checked the same way, whichever buyer wins.
Zurla for app developers- Invalid traffic
- Known bots and invalid devices filtered before the auction (GIVT), with deeper checks after the ad serves (SIVT) for emulators, device farms and SDK spoofing
- App identity
- Your bundle ID and store listing, matched to your app-ads.txt
- Ad scanning
- Creatives scanned for malware and forced redirects, including jumps to an app store without a tap
- Later auctions
- Traffic the deeper checks flag is kept out of later auctions
Agencies
Every client’s budget
reaches real people.
Before it bids for any client, Zurla checks each placement for a real person, an authorized seller and that client’s own brand rules.
Zurla for agencies- Not bid on
- Requests from known bots and data centers (servers, not people) are never bid on, so none are paid for
- Authorized sellers
- Each seller checked as authorized to sell that ad space
- Later buys
- Checks continue after ads run, and sites that fail them are left out of later buys
- Your verification company
- Its signals can feed the same checks, with counts matched as campaigns run
RTB platforms
Both sides of your auction,
checked under your brand.
Your platform runs on Zurla under your own brand. Zurla checks the requests your supply partners send and the ads your buyers return.
Zurla for RTB platforms- Supply, on arrival
- Invalid traffic, authorized sellers and brand-safety rules (yours, each publisher’s and each buyer’s), before any bidder sees a request
- Buyers’ ads
- Scanned before they run, and watched once they do
- Partner dashboards
- Each supply partner sees what was kept out, and why
- Quality reports
- Proof of quality for buyers, sent under your brand
Questions
Good to know.
Illustrative data
How does Zurla keep traffic clean?
In two layers. Before any buyer sees a request, Zurla checks that a real person is behind it, that the seller is authorized and that the site or app is what the request says. After the ad runs, deeper checks look for traffic built to look human, such as emulators, device farms and SDK spoofing, and what they flag is kept out of later auctions.
Does anyone pay for traffic Zurla keeps out?
No. Requests kept out before the auction never reach buyers. When Zurla buys for an agency’s clients, it doesn’t bid on known bots and data centers, so none of those requests are paid for.
We already work with a verification company. Can we keep it?
Yes. A verification company is an outside firm that checks where ads ran and who saw them. Its signals can feed the same checks, and for agencies its counts are matched with Zurla’s as campaigns run, not at month-end.
How are new ads checked?
Each new ad is scanned before it can serve: for malware, for forced redirects (sending people to another page, or to an app store, without a tap) and for file size. Once it’s live, Zurla keeps watching. An ad that changes is blocked from every later auction, and the buyer is told why.
Can an ad read or change my page?
No. Banners run in a sealed frame that can’t read or change your page. Native ads are drawn from plain parts, such as a headline, an image and a Sponsored label, and any tracking script a buyer sends runs in a sealed frame, or is refused.
Do the checks slow the auction down?
No. The checks before the auction take a few milliseconds, and Zurla’s auctions finish in under 100 ms. The deeper checks run after the ad serves, so they add no time to the auction. Auctions walks through one request step by step.
How does Zurla know an app is real?
It matches the app’s bundle ID and store listing to its app-ads.txt, a public file on the developer’s website that lists who may sell the app’s ad space. Requests that pretend to come from the app (SDK spoofing) are caught by the deeper checks and kept out of later auctions.
Can we see what was kept out?
Yes. Reports show what was kept out, by site or app, with the reason for each. RTB platforms on Zurla also show each supply partner the reasons in its own dashboard, and can send buyers quality reports under their own brand.
Every request checked. Every ad scanned.
See what Zurla keeps out of your auctions, with the reason for each, from day one.