Advertisers
/library/advertisers is the registry: every company the library holds ads for, alphabetically, with its ad count, the domain it was resolved from, its industry and category, and whether your workspace watches it.
The registry is shared. An advertiser anyone has added is there for every workspace, and adding one pays the ingest once for all of them.
Adding one
Add an advertiser takes three things and needs at least one:
| Field | What it does |
|---|---|
| Website | The advertiser's site, or a bare domain. This is the merge key |
| Name | Used when no domain resolves, and as the row's name |
| Library URL | A Meta, Google, LinkedIn or TikTok ad-library URL, pasted |
The website is the identity. Tempio reduces it to the registrable domain and merges on that, so the same company added twice by two people is one advertiser and not two.
A pasted library URL wins. It carries the archive and that archive's own id for the advertiser directly, which is the override for a company no domain lookup finds. There is no separate mapping to maintain: the pasted identity is the record.
Adding is asynchronous, and the page says so. The advertiser exists the moment you add it; resolving it against each archive that is switched on, and the ingest run that follows, happen behind you. An advertiser with no ads a minute after you added it is a run that has not landed, and the warning on the page says exactly that:
This advertiser has been added and not yet ingested on this source.
A resolution that finds nothing is not an error either. The advertiser exists
with an identity row for each archive that matched, the archives that matched
nothing show source_error against their row, and the way through is to paste
that archive's own URL for the company.
Adding an advertiser changes nothing in your own ad accounts, so it creates no change request and there is nothing to approve.
One advertiser
/library/advertisers/[id] is the whole record for one company.
Per-archive status
An advertiser is known to each archive separately, so there is a row per archive with its own status and its own last run:
| Status | What it means |
|---|---|
| Never ingested | The identity is recorded and no run has landed yet |
| Partial — the last run stopped at its ceiling | These ads are a sample, not the whole |
| Ingested | The last run reached the end of what the archive would give |
Beside it: how many ads the last run found, when it ran, and why it stopped. A run stops for one of five reasons — it reached the archive's last page, it hit the run ceiling, the rate budget for that archive ran dry mid-walk, the archive is switched off in this deployment, or the archive returned an error.
Where a run left more than a reason behind, the row shows it. Under the reason sits our sentence — what happened, what was not ingested, and what happens next — and under that, where the archive gave words of its own, those words, quoted and attributed by archive: Google Ads Transparency said: unrecognized name: ad_format_type. The two answer different questions, which is why both are there: ours says what you can do, theirs says what actually went wrong, and a bad field name and an archive that is simply busy arrive in the same class.
Partial is the one to read carefully. It does not mean the advertiser has few ads; it means the run took as many as it was allowed to take. Every search result naming that advertiser carries the same warning, so you are told on the row and not only here.
Counts and recent activity
Ads by status and by format, and how many appeared in the last thirty days. Every one of those is counted by the query that renders it, never stored, so the number is right at the moment you read it rather than right at the moment somebody last wrote it down.
The landing-page rollup
Every page an advertiser's ads point at, with how many ads point there and when that page was last seen — and a UTM column.
The URL is stored with its query string intact, which is the point. UTM
parameters are the advertiser's own campaign structure, written by them, read
straight off their own tracking: utm_campaign names their campaign,
utm_content usually names the creative variant, and the set of them tells you
how they have split the work. Grouping is on the scheme, host and path, so two
ads pointing at one page with different UTMs roll up together and the
parameters stay visible as a column.
Counts here are computed at read time too, for the same reason. Nothing stores "this page has eleven ads", because the ingest would make it ten a moment later.
Similar advertisers
Same industry, then same category, then overlapping tags, best match first, excluding the advertiser you are looking at. The page states what that means, because it is a narrower claim than it looks:
Similar advertisers are described the same way, not shown to perform the same way.
There is no model and no embedding behind it. It is the tags and the classification the corpus carries, which is a statement about description and nothing else.
Coverage
The advertiser page carries the same coverage warning every search result does, for each archive it is showing you. Four ads here can sit beside forty on the platform's own site without either being wrong — sources explains the four reasons.
From an agent
Over MCP, list_library_advertisers is the registry and the
similar-advertisers read (pass similarTo), get_library_advertiser is this
page, and add_library_advertiser is the form. All three are reachable through
tempio_manage as the library_advertiser entity.
Searching the library
The filter set, the two saved views, what the longevity score measures and what it does not, and how a spend range is derived and labelled.
Tracking and alerts
Watching an advertiser, the four kinds of activity alert and what each one fires on, the Monday digest, and how to turn the mail off without leaving Tempio.