What are MFA (made for advertising) sites?
Short answer
MFA stands for made for advertising: sites and apps built to monetise acquired traffic rather than to serve an audience. The tells are commercial, not technical: very high ad density, auto-refreshing slots, slideshow or clickbait content, and paid traffic acquisition. Nothing in OpenRTB marks a request as MFA, and MFA inventory usually passes ads.txt, sellers.json, and payload validation cleanly, so buyers filter it with inventory lists and quality vendors, using signals like imp.refresh, site.cat, and per-domain performance to build those lists.
What the label actually means
MFA stands for made for advertising. It describes properties whose business model is buying traffic cheaply and monetising it with ads, rather than attracting an audience and monetising the attention. The content is a vehicle for the ad slots, not the reason anyone is there.
The category is contested at the edges. There is no industry-wide definition with a bright line, and the same site can be judged differently by two vendors. What is not contested is the economics: a large share of programmatic spend has been shown to land on inventory that delivers impressions efficiently and outcomes poorly.
Why OpenRTB cannot flag it
A bid request describes an impression opportunity. It has fields for who is selling, what the slot is, what device is on the other end, and which rules apply. It has no field for whether the content deserves an audience, and it never will, because that judgement is commercial and contested rather than technical.
MFA operators also tend to be scrupulous about the parts that are checkable. They publish ads.txt, appear correctly in sellers.json, send a complete source.schain, and emit clean payloads, because failing those checks would cut them off from demand. This is the key mental separation: protocol validity and inventory quality are orthogonal. RTBlint answers the first question only, and says so.
The fields that carry a signal
| Field | What it tells you |
|---|---|
imp.refresh.count, refsettings.reftype, minint | How many times this slot has already refreshed, what triggers a refresh, and the minimum interval. Added in OpenRTB 2.6 precisely because refresh behaviour was invisible and buyers were paying for it blind. |
site.domain, app.bundle | The key every inventory list is built on, and the thing to normalise first |
site.cat, sectioncat, pagecat, cattax | Declared content categories, in the taxonomy named by cattax (default 1) |
site.page, site.ref | The exact URL and referrer, which is where paid-traffic patterns show up |
imp[] count, imp.instl, imp.pos | How many slots are being sold at once, and how prominent each claims to be |
Note that all of these are declarations by the seller. They are useful as inputs to a model and useless as guarantees. The one thing you can enforce is consistency: a request claiming a premium placement while imp.refresh.count says the slot has already cycled eleven times is telling you something.
Where validation does help
Not with the MFA judgement itself, but with the noise around it. Inventory lists key on site.domain and app.bundle, so requests that omit them, send a full URL where a domain belongs, or leave site and app ambiguous quietly bypass the list you built. Those are structural errors a validator does catch. Run a sample of live requests through the tester and check the fields your filters depend on actually arrive populated. The broader checklist is in bid request best practices.