What should a lookalike site list pass before approval?
Part of Lookalike websites
The short answer
Before approval, each site on a lookalike list should match the original seeds' theme, trace back to a named seed with matching articles, pass quality and suitability review, show an authorized seller, show readers in the target market, and appear once per owner. Unresolved sites go to named reviewers, and planning, ad operations and the client each sign their part.
Key takeaways
- Approve a lookalike list against written evidence per site, not against a general impression of the list.
- Each site should name the seed it resembles, the round that found it and the articles that prove the match.
- Duplicates hide in subdomains, shared owners and shared sellers, so normalize domains and read ads.txt with sellers.json.
- Flag missing data, conflicting seller records and borderline suitability for a person instead of deciding by rule.
- Split the sign off: planning owns theme and provenance, ad operations owns identifiers and sellers, the client owns exceptions.
What should a lookalike site list pass before approval?
A lookalike list is approved once and then used for weeks, so the approval step is where errors are cheapest to catch. The checklist below is the final gate, run after the search and review work is done. Each line is a yes or no question with evidence attached. A site that cannot answer yes moves to the review table, not onto the list.
Final approval checklist for a lookalike site list
- Theme fit: the site's recent sampled articles match the written description of the original seeds.
- Seed tracing: the site names the seed it resembles, the search round that found it and at least two matching articles.
- Publisher status: the site is a real publisher with its own editorial pages, not a store, brand site or marketplace.
- Quality: the site passed the made-for-advertising and page quality review, with the date of the review.
- Suitability: the site's content sits within the client's tolerance for each suitability category in the brief.
- Sellers: the site's ads.txt lists the seller the plan will buy through, and the exchange's sellers.json confirms it.
- Market audience: data shows readers in the campaign's country, or the gap in the data is recorded.
- Language: the sampled articles are in a language the brief allows.
- Duplicates: the site appears once after domains are normalized and owners are grouped.
- Import: the domain is written in the format the buying platform expects and imports without errors.
How do you trace each site on a lookalike list back to a seed?
Seed tracing turns a list into something a client can question line by line. The idea borrows from data documentation. Gebru and coauthors' Datasheets for Datasets (opens in a new tab) proposes that each dataset come with a datasheet that "documents its motivation, composition, collection process, recommended uses, and so on." A site list is a small dataset, and its collection process is the chain from seed to round to site.
| Field | What to record | Why it matters at approval |
|---|---|---|
| Seed | The seed site or page the candidate resembles | Shows which client favorite the site extends |
| Round | The search round that found the site | Late rounds deserve a closer look for drift |
| Matching articles | Two or more article URLs that match the seed's subject | Lets a reviewer confirm the match in minutes |
| Content category | An IAB Tech Lab Content Taxonomy category, with the version used | Gives a shared label the client and buyer read the same way |
| Checks and dates | Quality, suitability, seller and audience results with dates | Shows the evidence is current at approval |
| Verdict | Approved, held for review or left out, with one line of reason | Makes each decision reversible and explainable |
The category field uses the IAB Tech Lab Content Taxonomy (opens in a new tab), the shared vocabulary for contextual targeting. Recording the version matters because Tech Lab lists Content Taxonomy 3.1 with a December 2024 release date, and a label from an older version may not match a buyer's current tools. A site that cannot name a seed or two matching articles fails the trace, however good it looks. Such sites can still be useful, but as adjacent ideas outside the lookalike list, as the guide on lookalike drift explains.
How do you check a lookalike list for duplicates and networks?
Duplicates do not always look like duplicates. The same publisher can appear as a root domain and a subdomain, as two brands under one owner, or as a set of sites sold by one company. The ads.txt 1.1 specification (opens in a new tab) gives the tools to sort them. It defines the root domain as "the 'public suffix' plus one string in the name" and adds OWNERDOMAIN, which "Specifies the business domain of the business entity that owns the domain/site/app."
Five steps to find duplicates and networks
- Normalize each domain. Strip protocols, paths and www, then reduce each entry to its root domain under the public suffix rule.
- Keep real sections apart. Leave a subdomain as its own entry only when its ads.txt is declared from the root domain or its editorial content differs.
- Group by owner. Read OWNERDOMAIN in each site's ads.txt and group sites that name the same owner.
- Confirm with sellers.json. Check that each exchange's sellers.json record for the site names the same business domain.
- Decide one entry per network. Keep the strongest site of each owner group on the lookalike list and note the others.
The cross check in step four is what IAB Tech Lab's implementation guidance (opens in a new tab) asks for: "These validations of OWNERDOMAIN and MANAGERDOMAIN require a check against ads.txt AND sellers.json." The sellers.json specification (opens in a new tab) classifies each seller as "PUBLISHER, INTERMEDIARY, or BOTH" and lets a seller mark its identity as confidential. A confidential record or a mismatch is not proof of a problem, but it is a reason to flag the site rather than approve it on the files alone.
Which lookalike sites should be flagged for human review?
A flag means the evidence is incomplete or conflicting, not that the site is bad. Google's content suitability help (opens in a new tab) makes the underlying point: content that is "in compliance with our policies, may not be the right fit for your brand or business." Platform eligibility does not settle fit, so a person decides the close cases.
| Flag | What triggered it | Who reviews it |
|---|---|---|
| No market audience data | The site is absent from Chrome UX Report country data | Planner, with any other audience evidence |
| Seller conflict | OWNERDOMAIN and sellers.json name different businesses, or the seller is confidential | Ad operations |
| Borderline suitability | Some sampled articles touch a category near the client's tolerance | Client brand lead |
| Thin trace | Only one matching article, or a late round find | Planner |
| Borderline quality | Heavy ad load or templated pages without a clear made-for-advertising call | Planner and ad operations together |
| Owner group | The site belongs to an owner already represented on the list | Planner |
Missing audience data needs particular care. Chrome UX Report country values (opens in a new tab) are "inferred from users' IP addresses," and "Country dimensions are not available in the CrUX APIs," only in the BigQuery dataset. A small site can be missing from that data and still have loyal readers in the market, so a gap is a reason to ask the publisher for its own figures, not to drop the site.
Who signs off a lookalike site list?
One signature for the whole list hides who checked what. Split the sign off by the evidence each role can actually judge, and record each signature with the date and the list version it covers.
Ad operations also confirms the list loads where it will run. In Display & Video 360, channels (opens in a new tab) "are custom groups of related websites or apps" that can serve as "a preset, targetable list of brand-appropriate publishers," and the platform says "You will be alerted to any problems with the URLs or App IDs you entered." A clean import confirms the format, not the quality of the sites, which is why it sits last.
How does PlacementGraph support the approval of a target list?
What does a lookalike list approval look like on a real brief?
Fictional example
A fountain pen and ink maker in New Jersey and Delaware
An unnamed Wilmington maker of fountain pens and bottled ink has a lookalike list of thirty four sites built from two seeds: a stationery review blog and a handwriting and calligraphy magazine. The campaign targets readers in New Jersey and Delaware.
The planner runs the checklist. Three entries turn out to be one publisher: a root domain, a calligraphy subdomain without its own ads.txt declaration and a sister site naming the same OWNERDOMAIN. They collapse to one entry. Two sites cannot name a matching article beyond one post each and move to an adjacent ideas tab. One planner journal site is absent from the country data and is flagged; the publisher supplies its own reader figures.
One office supply blog lists a seller whose sellers.json record is confidential, and ad operations holds it pending an answer from the exchange. The client brand lead reviews two sites that cover vintage pen auctions and approves both. The final version carries twenty nine sites, three signatures and one open item.
Frequently asked questions
What if two seeds lead to the same site?
Record both seeds in the site's lineage. A site that resembles two of the client's favorites is a strong candidate, and the double trace helps explain it. Count it once on the list, and check that it does not crowd out more specific sites for either seed's theme.
Can part of a lookalike list be approved while flags are open?
Yes, if the approved version names the open items. Approve the sites that passed, keep flagged sites in a held group with their reviewer and question, and add them in a later version once closed. Mixing held sites into an approved list without a note defeats the purpose of the flags.
Does a passed checklist guarantee where the ads will appear?
No. The checklist approves sites, not delivery. Targeting settings, deal terms and the platform's own rules decide where impressions land. Google Ads (opens in a new tab), for example, notes that combining placements with topics or keywords can widen where ads show, so check the campaign setup against the approved list as well.
Should the lineage record go to the client?
A summary should. A client may not need every column, but the seed each site resembles and one matching article per site let them see why a site is there. Keep the full record on file for the planner who handles the next brief or a question mid campaign.
Sources
- Datasheets for Datasets (opens in a new tab)Gebru et al., Communications of the ACM (arXiv, revised December 1, 2021)
- Content Taxonomy (opens in a new tab)IAB Tech Lab
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab
- Sellers.json specification (opens in a new tab)IAB Tech Lab
- Supply Chain Validation: Implementation Guidance (opens in a new tab)IAB Tech Lab
- About content suitability (opens in a new tab)Google Ads Help
- CrUX methodology: dimensions (opens in a new tab)Google Chrome for Developers
- About channels (opens in a new tab)Display & Video 360 Help
- Placement targeting: Definition (opens in a new tab)Google Ads Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.