Real SSP or Reseller? 10 Checks Any Publisher Can Run Themselves

connect@connectad.io (ConnectAd) — Tue, 18 Aug 2026 20:20:20 GMT

In Q1 2026, Pixalate measured that 20.8% of all authorized web inventory globally was resold rather than sold publisher-direct. On mobile app it was 16.2%, on CTV 4.1%. Nearly one in five of the SSPs Pixalate ranks operate as primary arbitrageurs in at least one country.

That matters to you in three concrete ways. Every extra hop takes a cut before the money reaches you. Every extra hop adds latency and a duplicate bid request, which degrades your auction rather than deepening it. And when something goes wrong — a brand-safety incident, a discrepancy, a payment delay — you are two companies removed from anyone who can fix it.

The problem is that a reseller's website looks exactly like an exchange's website. So don't read the website. Run these ten checks instead. Most of them take under two minutes, none require a login, and none require the vendor to tell you anything.

Part 1 — Who they are

Four independent registries and datasets that a company cannot self-declare into.

01. Are they on Google's DV360 exchange list?

Display & Video 360 is the single largest source of open-market demand for most European publishers. Google publishes the complete list of exchanges buyable in DV360 — currently 90 entries — and maintains it directly.

Some rows carry a (via BidSwitch) suffix. Both routes count. A BidSwitch-intermediated integration is still reviewed, approved and enabled by Google on a per-exchange basis, and it appears in the same buyer-facing exchange picker as a direct integration. The meaningful distinction is not direct versus BidSwitch — it is being on the list at all.

Where to look: support.google.com/displayvideo/table/3267029 — public, no login. Search for the company name.

Real SSPA row with their own name on it, whether or not it says "via BidSwitch".

Wanna-beNot on the list — but the deck promises DV360 demand. That demand is reaching them through somebody else's seat.

02. Do they have their own TCF Global Vendor List registration?

If a company sells European inventory, it needs a GVL ID. Without one, no TCF consent management platform can signal consent for it, which means an EU publisher cannot lawfully pass a consent string to it at all. Registration requires a signed participation agreement with IAB Europe, an annual fee, and public declaration of legal bases, purposes, retention periods and a device-storage disclosure URL.

Where to look: vendor-list.consensu.org/v3/vendor-list.json (1,202 vendors as of list version 172). Search the JSON for their company name and check the id.

Two things to verify beyond mere presence. First, the ID must belong to them — a Prebid adapter can declare any GVL ID that exists, and Prebid only validates that the number is real, not that it is theirs. Compare the vendor name in the list with the company you are talking to. Second, GVL IDs are issued sequentially: a two- or three-digit ID means registration in the 2018 TCF launch era; a four-digit ID means they registered recently.

Real SSPOwn GVL entry under their own legal entity, no deletedDate, and a working deviceStorageDisclosureUrl.

Wanna-beNo GVL ID while selling EU traffic — or an adapter carrying a GVL ID registered to a different company.

03. Does their TAG ID in your ads.txt actually resolve?

Field #4 of an ads.txt record is the certification authority ID — in practice, the vendor's TAG ID. Most publishers paste it in without ever checking it. It is trivially verifiable, and a fabricated ID is detectable in one request.

Where to look: take the ID from the ads.txt line they asked you to add (or from the identifiers[] block of their sellers.json) and enter it at tagtoday.net/registry-search. The search accepts the raw TAG ID and resolves to the company record.

Being found in the registry is the bar. It means TAG has independently verified that this company is a real, identified legal entity — the "Verified by TAG" programme. Additional audited seals (Certified Against Fraud, Certified Against Malvertising, Brand Safety Certified) exist and are a genuine plus, but they are a separate, higher tier and their absence tells you nothing about whether the company is an exchange or a reseller.

Real SSPThe ID resolves, and the name on the record matches the company on your contract.

Wanna-beNo TAG ID at all, an ID that returns nothing, or an ID that resolves to a different company than the one invoicing you.

04. What does Pixalate's Seller Trust Index say about their arbitrage ratio?

This is the closest thing the industry has to an objective answer, and it is free. Pixalate's Seller Trust Index 2.0 is a quarterly, per-country, per-SSP ranking whose explicit headline framing is arbitrage versus publisher-direct. It parses ads.txt and app-ads.txt for claimed DIRECT relationships and cross-checks them against SupplyChain Object analysis of actual measured impression flow — so it validates the claim against observed transactions rather than trusting the file.

The ranking combines three components: the arbitraged inventory ratio (share of impressions with no authorized direct path), direct impression volume, and DIRECT publisher penetration (how many publishers actually declare the seller DIRECT). A seller is classed as primarily a reseller when more than half of its measured impressions lack an authorized direct path.

Where to look: ratings.pixalate.com/rankings/domain/seller-trust-index (web), plus /app/ and /ctv/. Filter to your market. The two most recent quarters show the actual numeric ratios without registration.

Real SSPRanked in your market with a low single-digit or sub-1% arbitrage ratio and thousands of DIRECT publishers.

Wanna-beDouble-digit or majority arbitrage ratio — or absent from the index entirely in the market they are selling you.

One caveat, in fairness: Pixalate's MRC accreditation covers impression counting, viewability and invalid-traffic detection. It does not extend to the arbitrage methodology, which is proprietary. Treat the index as strong independent evidence, not as an audited certificate.

Part 2 — What they actually built

Four checks against open-source code that nobody can edit to flatter themselves.

05. Is their Prebid.js adapter a real adapter — or an alias?

A Prebid alias is a pure rename. It inherits the parent's buildRequests, its interpretResponse, its user syncs, and it posts to the parent's endpoint. Only the string changes. Of 771 bidder codes in Prebid.js, 271 are aliases — roughly 35%. Several parents carry 15 to 35 differently-branded children each.

Quick check: docs.prebid.org/dev-docs/bidder-data.csv, column aliasOf. Be aware it is incomplete — it captures about 169 of the 271.

Authoritative check: metadata/modules.json, generated automatically from the running build:

curl -s https://raw.githubusercontent.com/prebid/Prebid.js/master/metadata/modules.json \
 | jq -r '.components[] | select(.componentType=="bidder" and .aliasOf!=null)
          | "\(.componentName) -> \(.aliasOf)"'

Live check: open any page running their adapter and type pbjs.aliasRegistry in the console, or compare bid.bidderCode with bid.adapterCode in pbjs.getBidResponses().

Important: the documentation page will not tell you. The rendered bidder page at docs.prebid.org/dev-docs/bidders/<code>.html does not display the aliasCode field, even when it is present in the source. Read the raw .md or the CSV.

06. Is there any actual code in it?

Even without a formal alias declaration, file size gives it away. Serious exchanges run to several hundred or a few thousand lines: their adapters carry their own bid construction, their own ORTB mapping, their own user-sync logic, their own viewability and renderer handling. White-label derivatives are typically 17 to 20 lines and import every meaningful function from a shared vendor library.

Where to look: github.com/prebid/Prebid.js/blob/master/modules/<name>BidAdapter.js (try .ts too). Then check the imports.

Imports from libraries/ortbConverter, libraries/urlUtils or similar are Prebid core utilities available to everyone. Neutral to positive.
An import of an entire libraries/<someVendor>Utils/bidderUtils.js that supplies buildRequests, isBidRequestValid and interpretResponse wholesale means the adapter is a thin shell over another company's stack. The largest such library in the repo is shared by 43 differently-named "SSPs".
Missing gvlid, missing getUserSyncs, no onBidWon/onTimeout handling — all signs of a shell.

Real SSPHundreds of lines, own gvlid, own sync endpoints, own request logic.

Wanna-beUnder 60 lines, all logic imported from another vendor's library, no GVL ID, maintainer contact on a free mail domain.

07. Do they have a native Prebid Server adapter?

Server-side is even more explicit, because Prebid encodes the answer in a config field. 110 of 379 bidder configurations in prebid-server are pure alias files. Some are one line long:

# static/bidder-info/<name>.yaml — entire file contents
aliasOf: "someOtherCompany"

Where to look: prebid-server/static/bidder-info/<code>.yaml and the Java equivalent in prebid-server-java/bidder-config/. Check for:

aliasOf: — present means it is not their adapter.
whiteLabelOnly: true — Prebid's own flag for white-label platforms.
A missing endpoint: — the bidder silently inherits the parent's.
maintainer.email — this leaks the real operator even where aliasOf is absent.
In the Java config, vendor-id: 0 means no own GVL registration.

You can also query any live Prebid Server host directly:

curl -s https://<pbs-host>/info/bidders/<biddercode>
# returns {"maintainer":{"email":"..."},"aliasOf":"..."} when it is an alias

An absent aliasOf is not an acquittal. There are adapters in prebid-server that are byte-identical copies of another company's adapter, modulo the name, and declare no alias relationship at all. That is what checks 06 and 08 are for.

08. Whose infrastructure does the bid request actually reach?

The check that no amount of positioning survives. Take the endpoint hostname out of their adapter and resolve it.

python3 -c "import socket; print(socket.gethostbyname_ex('<their-endpoint-host>'))"
curl -s -H 'Accept: application/json' https://rdap.arin.net/registry/ip/<ip> \
 | jq '{handle, name, startAddress, endAddress}'

What you are looking for is co-location. In one documented white-label cluster, 18 separately branded "SSPs" share a single /21; a second netblock holds 12 more, including the platform vendor's own demo host. When a dozen independent exchanges live in the same eight-thousand-address block, they are one platform wearing a dozen name tags.

Two supporting tells: CNAMEs frequently name the parent outright, and entire alias families point at a single parent domain (<brand-a>.parent.com, <brand-b>.parent.com, and so on).

One fair caveat: a CDN or reverse proxy in front of the endpoint hides the origin, and that is normal infrastructure practice rather than evidence of anything. Where you can see the origin, check who owns it.

Part 3 — How they actually sell

The two checks that describe the commercial reality, not the technical one.

09. Are there DIRECT lines — and real publishers in their sellers.json?

The IAB spec is unusually precise here. PUBLISHER means the inventory belongs to the named entity and the advertising system pays them directly. INTERMEDIARY means it does not, or they are not paid directly. In ads.txt, DIRECT means the publisher controls that account through a direct business contract; RESELLER means someone else does.

The decisive test: crawl the ads.txt of 20 to 50 publishers the company names as references and count the lines carrying their domain with DIRECT. A company with zero DIRECT lines across its entire claimed portfolio has no direct publisher contracts at all, whatever it calls itself.

Then fetch https://<their-domain>/sellers.json and check:

The absolute number of PUBLISHER entries — not the ratio. A legitimate exchange can show a high intermediary share for structural reasons; what it cannot fake is thousands of direct publisher relationships.
contact_email, contact_address and an identifiers[] block with a TAG ID. Their absence is a hygiene signal.
A very high is_confidential: 1 share on a small file, which means the actual sources are being hidden.
Spot-check the graph. Pick a handful of seller_ids that are marked PUBLISHER and open the ads.txt of the publisher named in the entry. The seller ID from the sellers.json record must appear in that publisher’s ads.txt, on a line carrying the vendor’s domain — ideally as DIRECT. If the ID is missing on the publisher side, or only appears as RESELLER for a different domain, the sellers.json entry describes a relationship that the publisher does not confirm. A few samples that don’t reconcile tell you how much the rest of the file is worth.

10. In the supply chain object, are they node 1?

Save the best for last, because this one cannot be spun without breaking the standard. The SupplyChain Object is ordered, and node 1 is the entity with the direct relationship to the inventory owner. Everything after it is a hop.

Real SSP nodes.length == 1, complete: 1, asi is their own domain and sid is your seller ID. One hop, one margin.

Wanna-beAlways node 2 or later. They are never node 1 because they never buy from you directly — they buy from whoever is.

How to verify: ask a buyer you trust what arrives in source.schain (OpenRTB 2.6) or source.ext.schain (2.5) on your inventory. Then, for every node, confirm that https://<asi>/sellers.json contains that sid, and that its seller_type matches its position: node 1 should be PUBLISHER or BOTH, later nodes INTERMEDIARY.

A chronic complete: 0 is its own answer. It is a formal admission that the chain is not declared all the way back to the inventory owner — that the company either cannot or will not name its own upstream.

Red flags at a glance

They ask you to set allowAlternateBidderCodes: true. Translation: "we will return bids seated as other companies."
Their Prebid adapter has no gvlid, but they are selling you European traffic.
The Prebid maintainer contact is a free mail address rather than a company domain.
"We're connected to 40+ DSPs" — but they are not on the DV360 exchange list and not in the Seller Trust Index for your market.
Asked what schain they append, you get a vague answer — or a chronic complete: 0.
They cite "Google Authorized Buyer" as proof of SSP status. That is the buy side. It says they purchase inventory, not that they sell yours.
They cite “Google Certified Publishing Partner” as proof of SSP status. That badge means the partner’s people are “trained experts on Google Ad Manager, Google AdSense, and/or Google AdMob” — a services and consulting credential. It does not make them an SSP, an exchange, or an accredited buyer or seller of anything.

The twenty-minute version

Search their name in the DV360 exchange table.
Search their name in the TCF Global Vendor List and check the ID belongs to them.
Put their TAG ID into the TAG registry search.
Look them up in the Pixalate Seller Trust Index for your market.
Grep bidder-data.csv for their bidder code, then confirm against metadata/modules.json.
Open their adapter file. Count the lines. Read the imports.
Fetch their static/bidder-info/<code>.yaml from prebid-server.
Resolve their bid endpoint and RDAP the IP.
Fetch their sellers.json. Count PUBLISHER entries.
Crawl the ads.txt of 20 publishers they name. Count DIRECT lines.

No single check settles it. But a company that fails checks 01, 05, 09 and 10 together is not an SSP, regardless of what the homepage says. And a company that passes all ten belongs to a group you can count on two hands.

We ran the checklist on ourselves

Publishing a test you have not taken is cheap. Here is ConnectAd against all ten, with the evidence public and linked so you can repeat every line of it.

#	Check	Evidence	Result
01	DV360 exchange list	Listed as ConnectAd (via BidSwitch) in Google's supported exchange partners table	Pass
02	TCF Global Vendor List	GVL ID 138, ConnectAd Demand GmbH — a three-digit ID from the original 2018 registration wave. Sole matching entry, no `deletedDate`, device-storage disclosure live at `cdn.connectad.io`	Pass
03	TAG ID resolves	`85ac85a30c93b3e5` — declared in our sellers.json, carried in field #4 of our publishers' ads.txt lines, and resolving in the TAG registry	Pass
04	Pixalate arbitrage ratio	Web Seller Trust Index 2.0, Q2 2026 — Germany: rank 12 of 92, arbitrage ratio 0.066%, 3,526 DIRECT publishers. US: rank 30 of 143, 0.115%, 11,794 DIRECT publishers. Both figures are an order of magnitude below the global 20.8% average	Pass
05	Not a Prebid alias	`metadata/modules.json` shows `connectad` with `"aliasOf": null` and its own `gvlid: 138`. We are a parent: `connectadrealtime` is our alias, not the other way round	Pass
06	Own adapter code	`connectadBidAdapter.js` — 323 lines, own `gvlid`, own `getUserSyncs`, own outstream renderer, own viewability handling. Imports only Prebid core libraries; no vendor `Utils` library	Pass
07	Native Prebid Server adapter	Native Go adapter (`adapters/connectad/`) and native Java adapter (`ConnectAdBidder.java`). No `aliasOf`, no `whiteLabelOnly`, own `gvlVendorID: 138`, own cookie family, maintainer `support@connectad.io`	Pass
08	Own infrastructure	Bid, sync and CDN endpoints all on `connectad.io` (`i.`, `bidder.`, `sync.`, `cdn.`). Our APAC endpoint resolves into a network block assigned to ConnectAd directly — not shared white-label space	Pass
09	DIRECT lines & sellers.json	518 sellers, 241 typed `PUBLISHER`, zero confidential entries, full contact details. `DIRECT` lines under `connectad.io` in the live ads.txt of kleinanzeigen.de, 20min.ch, flightradar24.com, blick.ch, wp.pl, wetteronline.de, vecernji.hr and others	Pass
10	schain node 1	On directly contracted supply we append exactly one node — `asi: connectad.io`, your seller ID, `complete: 1`. Ask any buyer to confirm it from their bid stream; that is the point of the check	Pass

Two things we will not overstate. Our TAG record shows Verified by TAG, the identity tier — we hold no additional audited seals today. And our DV360 row reads "via BidSwitch", a Google-approved integration route rather than a bilateral one. Both are accurate, both are visible to anyone who looks, and we would rather you read them here than discover them later.

Run the checklist on whoever you are talking to. Then run it on us.

If anything in our answers above doesn’t check out, tell us. If it all does, let’s talk about your inventory.

Talk to ConnectAd

Sources. Google DV360 supported exchange partners (support.google.com/displayvideo/table/3267029) · IAB Europe TCF Global Vendor List v3 (vendor-list.consensu.org) · TAG registry search (tagtoday.net/registry-search) · Pixalate Seller Trust Index 2.0, web/app/CTV, Q1 and Q2 2026 (ratings.pixalate.com) and methodology (pixalate.com/knowledgebase/rankings) · Prebid.js metadata/modules.json, modules/ and libraries/ · prebid-server static/bidder-info/ and prebid-server-java bidder-config/ · docs.prebid.org bidder data · IAB Tech Lab sellers.json v1.0 and ads.txt v1.1 · IAB Tech Lab SupplyChain Object specification.

All figures verified live in August 2026. Repositories, registries and rankings change over time; the methods stay valid, the numbers are a snapshot. Nothing here is a claim about any specific company other than ConnectAd.

Blog

Real SSP or Reseller? 10 Checks Any Publisher Can Run Themselves

Part 1 — Who they are

01. Are they on Google's DV360 exchange list?

02. Do they have their own TCF Global Vendor List registration?

03. Does their TAG ID in your ads.txt actually resolve?

04. What does Pixalate's Seller Trust Index say about their arbitrage ratio?

Part 2 — What they actually built

05. Is their Prebid.js adapter a real adapter — or an alias?

06. Is there any actual code in it?

07. Do they have a native Prebid Server adapter?

08. Whose infrastructure does the bid request actually reach?

Part 3 — How they actually sell

09. Are there DIRECT lines — and real publishers in their sellers.json?

10. In the supply chain object, are they node 1?

Red flags at a glance

The twenty-minute version

We ran the checklist on ourselves

Revenue Per Hop: The KPI Programmatic Should Be Talking About

What Makes an SSP Worth Keeping?

Programmatic Dollar Flow: Why the Future of Media Buying Belongs to Transparent Supply Paths

The Supply Chain Is Broken. Here’s What That Actually Costs You.

The Ad-Tech Tax Is Not One Tax — It’s a Stack of Small Leakages

From Setup to Scale: How Frictionless PMP Activation Can Transform Your Programmatic Strategy

More Media. Less Tax. – How Discipline, Not Excess, Drives Sustainable Growth

2026 Publisher Roadmap: What Really Matters

Why Transparency, Efficiency & Alignment Matter More Than Ever

Transparency Compliance: The Cornerstone of a Trustworthy Programmatic Ecosystem