Meta ad naming conventions: what Claude can filter on

You ask for last month’s video ads. Back comes a table with a static image ad sitting in the middle of it, because someone called that ad Summer-EVID-02 and the filter was asked for names containing VID. Nothing malfunctioned. A substring match found a substring.

That is the whole subject. Every naming-convention guide for Meta ads is written for a human reading Ads Manager, and for that it is sound. An assistant working through the official connector reads names through a much narrower slot.

What the connector can actually do with a name

Ask the connector’s own field catalogue about name and it answers precisely. Read on 2026-09-12: type STRING, supported at campaign, ad set, ad and account level, filterable: true, sortable: true, and a list of supported operators — EQUAL, CONTAIN, NOT_CONTAIN, CONTAINS_ANY, NOT_CONTAINS_ANY.

Read that list for what is missing. No starts-with, no ends-with, no pattern, no wildcard — nothing that knows a name has parts. Lead with the audience or lead with the objective and the filter behaves identically, because containment has no position. The careful ordering in your convention is doing work for you and none for the tool.

One operator does pay. CONTAINS_ANY takes an array, so a single call pulls every entity carrying any of a set of tokens — a whole cohort of tests, across campaigns, in one request rather than one per token. That is what a token vocabulary is for, and it works in exact proportion to how unambiguous the tokens are.

Naming is one habit inside a routine that has several. The Claude Ads Operator course teaches the weekly loop that uses them, starting from an account that is properly connected.

The catalogue also carries an instruction about names, aimed at the assistant rather than at you. The name entry says, verbatim: Do NOT use the name filter to retrieve metrics, metric breakdowns, or attributes for an ad entity. In those cases, always use the ID filter instead. Names find things; IDs fetch them. A convention that is working gets used once, early, and then the ID takes over — which is also how de-duplicating by creative ID works.

Two more limits. campaign_name and adset_name are returned on ads, so a row shows its parents — but both come back filterable: false and sortable: false, which makes selecting every ad under campaigns matching a token two calls rather than one: filter at campaign level, then pass the IDs down. And the entity tool states that account-level requests support neither filtering nor sorting, so the catalogue’s filterable: true does not reach that level.

What the guides optimise for, and what the tool does

The advice in circulation is not wrong so much as aimed elsewhere. A guide published 10 September 2026 on adamigo.ai puts the promise plainly: a consistent convention “turns every campaign name into a filterable data column”, and its ad set advice is positional — “start every ad set name with the audience.” In Ads Manager both hold. Through the connector the name never becomes columns; it stays one string, and starting with the audience returns exactly what ending with it would.

What to change

1. Make every token a string that appears nowhere else the whole game

   Containment is blind and it is greedy. A country code of US matches AUS. VID matches EVID and DAVID. Pick tokens long enough and odd enough that no other token, product name or person’s name contains them, and every filtered request you make afterwards returns what you asked for.

   The trade: unique tokens are longer and uglier than the ones you would choose for reading, and names have a practical length limit, so something else in the name has to go.

2. Repeat the axis you filter on at every level saves a round trip

   Because parent names are not filterable on the child, a token that lives only on the campaign cannot select ads in one call. If you routinely ask questions at ad level about a distinction recorded at campaign level, that distinction needs to be in the ad names too.

3. Stop encoding what the connector already returns removes a lie

   Objective, status and budget are fields. Asking for them returns the current value; a name saying CBO keeps saying it long after the budget moved to the ad set. Every fact duplicated into a name can go stale silently, and the assistant cannot tell which copy is true.

   The trade: you lose the at-a-glance read in Ads Manager, where those fields are two clicks away rather than in front of you.

A name is not a schema. It is a haystack you get to choose the needles for.

• Retro-fitting the whole account in an afternoon. Renaming goes through ads_update_entity, one entity_id per call, and its own description warns that when the response carries active_errors the edit went into a draft — pending publish, not applied. A bulk rename is many calls and a verification step.
• Trusting a token you chose for how it reads. The tokens that collide are always the short pretty ones. Check a new token against the names you already have before it goes into a hundred ads.
• Expecting the creative listing to behave like the entity listing. ads_get_creatives takes creative IDs, a cursor, a field list and a limit. There is no filtering parameter on it at all, so creative names are paged through, never searched.
• Treating the convention as documentation. It records what you decided, not what is true now — and the fields you assume exist still need checking against the catalogue.

Try this tonight Ask for your ads whose name contains your most-used token, then ask for the ones that do not contain it. The second list is the interesting one: every ad in it is invisible to every prompt you will ever write using that token. Rename the handful that should have carried it, and drop the token entirely if the second list is longer than the first — a token most of your account is missing is worse than no token, because it answers confidently and partially.