Inclusion and exclusion lists you can defend in review

A working inclusion list for in-app display in Southeast Asia lands somewhere around 400 to 900 bundle IDs. Most accounts I inherit have the opposite: an exclusion file of eleven thousand lines, assembled over four years by people who have since left, where nobody can say what evidence put any given entry there. That file is not a control. It is an archaeological site. This engagement replaces it with a list short enough to defend line by line. How an entry earns its place: Every inclusion carries a reason, and there are four acceptable ones: it delivers volume at a CPM you would pay again, it has been bought direct and reconciled, it passes the supply path test below, or it is strategically required and someone senior has signed for it. Everything else is a preference. Preferences go in a separate file that nobody buys from. The supply path test is the part most lists skip. For each bundle ID or domain I count how many distinct paths reach it — reading app-ads.txt and ads.txt for DIRECT and RESELLER declarations, then walking sellers.json to see which intermediaries sit in between and whether the seller_id chain terminates where the publisher claims. Where six paths exist to the same inventory, five of them are paying somebody, and we collapse to one or two, usually through a curated deal rather than the open exchange. Where the store listing and the declared bundle ID disagree, the entry does not go on the list at all. What you receive: Two files per platform, formatted for direct ingestion into The Trade Desk and DV360 inside their list size limits, plus a source table with one row per entry: identifier, publisher, declared path, evidence, date added, review date, accountable person. The list without the source table is worthless within six months, which is precisely how the eleven-thousand-line file happened. Refresh: Lists decay. Apps change SDKs, publishers change resellers, bundle IDs get sold. The review cycle runs quarterly, with a rule that no entry survives without a fresh reason and that additions require the same evidence as the original build. Removal has to be as easy as addition, or the file only ever grows. Where I say no: I will not add a publisher because somebody in the brand team saw an ad they disliked next to it. That is a suitability question, it belongs in a different conversation, and it needs different evidence. I will not build from a purchased blocklist alone. Bought lists are a starting position and they are consistently weak on Indonesian, Vietnamese and Thai-language inventory, which is exactly where a regional account bleeds. I will not maintain the file for you indefinitely. The governance rules are the deliverable. If they cannot survive without me, they were the wrong rules. Not for you if: Your buying is already mostly PMP and direct. You have solved this, and the remaining open-exchange tail is too small to pay for the work. You need the list to expand reach. Done properly this reduces addressable supply, sometimes by a third, and CPMs rise before efficiency does. If next quarter's plan depends on impression volume holding flat, do this after that plan rather than during it. Working languages are English and Mandarin, which matters here: a real part of the review is reading store listings and publisher pages in the local language rather than trusting a classification field somebody populated once.