Classify ads with labels and naming rules

On this page you can attach labels (classification markers) to search terms, ASINs, and campaigns so you can read sales and ad spend along the axis of an ad role — like “Hero,” “Defensive,” or “Cut” — or a product line. You can also standardize campaign naming rules. Judging thousands to tens of thousands of keywords one at a time is impossible, so the goal is to be able to handle them in bulk by role.

About this page

Item	Details
What you can do here	Design a label taxonomy, auto-label competitor products, bulk-label search terms, and manage campaign naming rules
Applies to	Search terms, ASINs, SP campaigns, and Amazon DSP line items (across all of them)
Data / connections needed	Search-term data from a connected account. Auto-labeling competitor products uses the Amazon catalog data (product name and brand) that Picaro retrieves
Scope	Updates Picaro-side labels and naming rules after approval (analyze / propose → review → apply). It does not change the ad settings themselves (bids, budgets, keywords)

In Picaro, only one label can be attached per search term / ASIN / campaign. When you assign a new label, the existing one is silently overwritten and is not automatically reverted.

For this reason, use label-assignment prompts as a 2-step flow: review the execution plan first → run for real if it looks good. Just ask “show me the plan first” to review the content before anything is written.

When no overwrite occurs, the message can mean either “the target’s column is empty” or “the same label is already attached,” and the execution result alone cannot tell them apart. Don’t conclude “it was newly attached” — read it as “no overwrite will occur (it may already be identical).”
For products (ASINs) there is no way to check the current label in advance, so an overwrite cannot be detected even at the execution-plan stage. Assume that any existing shared label will be lost.
There is currently no way to retrieve a list of Amazon DSP line item IDs. If you want to label DSP line items, look the IDs up in the Amazon DSP console first and then specify them.

When to use this

You want to auto-classify thousands to tens of thousands of keywords into the 5 ad roles: Hero / Profit Engine / Defensive / Exploration / Cut
You want to automatically label competitor products (ASINs) that have slipped into search terms by product name and brand
You want to apply a label rule you designed once, in bulk, to existing search terms
You want to standardize campaign naming rules so report aggregation stays stable
You want to manage ACoS / ROAS / budget-allocation targets separately per label

Why you need labels

Amazon’s ad console aggregates primarily by campaign and ad group. A number like “overall ACoS was 35%” tells you the total, but it does not reveal whether your Hero keywords are working, whether your defense is breaking down, or whether cut candidates are eating ad spend.

Once keyword counts reach the thousands or tens of thousands, judging each one individually is impossible. Unless you group keywords by ad role — which group earns profit and which runs in the red — operations stop scaling. The same applies to agencies managing multiple clients: trying to explain “why ACoS got worse” with data tends to mean hand-processing CSVs.

Labels close this gap. By attaching classifications like “Hero,” “Defensive,” or “Cut” to search terms, ASINs, and campaigns, you can aggregate and compare the same spend and sales data along a role-based axis. The basis for bid adjustments and reports shifts from gut feel to data, and you can give an AI agent high-level instructions like “review the bids on my Hero keywords.”

What labels change

Without labels (today)

“This month’s overall ACoS was 35%, 3pt worse than last month.”

With labels (after applying Picaro labels)

Label	Share of sales	ACoS	Assessment
Hero (own-brand branded search terms)	42%	12%	Keep scaling
Defensive (brand + category)	18%	18%	Maintain efficiency
Profit Engine (niche use-cases)	20%	18%	Room to expand gradually
Exploration (new, still-learning search terms)	10%	32%	Keep observing
Cut (competitor products, low-ROAS terms)	10%	78%	Cleanup candidate

Viewed by label, you can immediately pinpoint “the ACoS decline is because the Cut group is eating ad spend.” For an agency, the client conversation shifts from “a list of numbers” to “an explanation of strategy,” and you can set a separate target ACoS per label for bid adjustments.

Picaro’s recommended label design — 2 patterns

There are broadly 2 patterns for designing a label taxonomy. Neither is the single right answer; choose based on how many product lines you have and the main axis of your analysis.

	Pattern A: Ad-role first	Pattern B: Product-line first
Best when	1–2 product lines / thousands of keywords or more	3+ product lines / multiple sub-brands
Top tier (1st)	Ad role (Hero / Profit Engine / Defensive / Exploration / Cut)	Product line / sub-brand
Mid tier (2nd)	Product line or topic	Product variation / customer stage
Low tier (3rd)	Match type or specific term	Term type (branded / generic / competitor)
Strength	Instantly shows how each term contributes to advertising, leading straight to action	Easy to manage ACoS and margin independently per product line

Pattern A: Ad-role-first type

A design that classifies thousands to tens of thousands of keywords by their impact and role in advertising. You can instantly grasp “how this keyword contributes to the whole account,” leading directly to bid adjustments, exclusion decisions, and budget allocation. Best when you have few product lines and many keywords.

Top tier	Meaning	Typical examples	Bid / budget stance
Hero	High-ROAS × high-volume sales driver	Own-brand branded terms, key terms for staple products	Prioritize scaling, generous budget
Profit Engine	High-ROAS × mid-low-volume hidden gem	Niche-demand, high-margin product terms	Maintain, expand gradually
Defensive	Brand-term / competitor-defense slot	Own brand + category, competitor brand name terms	High bid, efficiency-focused
Exploration	New, still learning (insufficient signal)	New terms from Auto, Manual terms in the launch phase	Observe on low budget
Cut	Low-ROAS, slated for cleanup	Zero-purchase terms, ACoS over 2× target	Move toward exclusion, gradual pause

3-tier example (a brand running thousands of keywords):

Hero (top tier)
└── Product line A (mid tier)
    ├── Exact match (low tier)
    ├── Phrase match
    └── Product targeting
Profit Engine (top tier)
└── Niche use (mid tier)
Defensive (top tier)
├── Own brand (mid tier)
└── Competitor brand (mid tier)
Exploration (top tier)
└── New-term pool
Cut (top tier)
└── Cleanup-pending pool

Why this pattern works:

You can coarsely group thousands to tens of thousands of keywords into 5 roles, so operational decisions scale
Labels translate directly into action (Hero → scale, Cut → exclude, etc.)
Dashboards instantly show “Hero ROAS dropped” or “the Exploration slot is over budget”
You can instruct an AI agent at a high level, like “review the bids on my Hero keywords”

Pattern B: Product-line-first type

A design that places the product line (sub-brand) at the top. When ACoS targets and margins differ by product, cutting by product line first keeps KPIs from getting mixed up. Placing “branded / generic / competitor” at the lowest tier lets you drill down to “what is the ACoS for product line A × generic.” Placing “new / repeat” at the mid tier lets you manage acquisition cost and retention cost separately, enabling LTV-aware decisions.

Quick reference

Goal	What you get	Changes	Prompt
Manually assign labels to search terms / ASINs	A list of targets × assigned label	Assigns labels after approval (overwrite)	Prompt 3
Assign labels to campaigns / DSP / products	A list of targets × assigned label	Assigns labels after approval (overwrite)	Prompt 4
Check, add, initialize, or delete the label taxonomy	Per-operation results	Add / update / initialize / delete	Prompt 5
Register or infer campaign naming rules	A list of naming patterns × match rate	Registers naming rules	Prompt 6

Prompt 1: Manually label search terms and ASINs

Without using auto-matching, directly assign search terms or ASINs to a label you specify.

When to use — when you want to deliberately, manually label targets that auto-classification can’t catch.

What you need — the destination label name (show the current state in Prompt 5 to see the list) and the target list.

For the label "{{LABEL NAME (e.g., Competitor / high-price)}}",
directly assign the following search terms / ASINs:
{{TARGET LIST (e.g., term1, term2, B0XXXXXXXX)}}

Let me review the content first, then run for real if it looks good.

What you can change — the label name and the target list (search terms or ASINs).

What you get back — a table of target × type (search term / ASIN) × existing label × post-assignment label. Targets that already have a label are clearly flagged as “this will overwrite.”

Changes — after approval, Picaro assigns the labels on its side (existing labels are overwritten).

Next steps — to label campaigns or products too, go to Prompt 4.

Prompt 2: Assign labels to campaigns, DSP, and products

Assign labels to SP campaigns, Amazon DSP line items (the DSP delivery-setting unit; only for accounts running DSP), and product ASINs so they can be used as aggregation axes on dashboards and in N-gram analysis.

When to use — when you want to classify not just search terms but campaigns and products themselves by role.

What you need — the destination label name and the targets you want to assign.

Assign the following to the label "{{LABEL NAME (e.g., Hero / product line A)}}".
- SP campaigns: {{campaign names or IDs (multiple OK)}}
- Product ASINs: {{ASINs (multiple OK)}}
- DSP line items: {{DSP line item IDs (multiple OK, optional)}}

🔴 This operation can silently erase existing labels and cannot be undone. Follow the order below exactly.

[Premise: 1 entity = 1 column = 1 label]
Picaro silently enforces the constraint that one campaign (line item, product) may carry only one label per column (top-level label).
If you attach a different label while an existing label sits in the same column, the existing assignment is lost and un-assigning will not restore it.

[Procedure]
1. Identify the label. Resolve the internal ID (label_id) from the label name.
   There is no dedicated tool that returns a list of labels, but calling the label-level KPI aggregation tool with different apply_to values
   returns root_label_id / root_label_name / label_id / label_name as a list, so use that as your label ledger
   (apply_to=SA for SA campaign labels, apply_to=ALL for shared labels. The classification rules themselves can also be seen via the taxonomy management tool's show).
   Always present the label_id you identified and which tree (SA / DSP / ALL / SEARCH_TERM) and which tier it belongs to.
   * Assignment fails if the tree does not match. Campaigns take SA or ALL, DSP line items take DSP or ALL,
     and products take ALL only (SA/DSP-specific labels cannot be attached to products).
2. Verify the target IDs exist. If targets were given by campaign name, look them up in the campaign list by partial name match,
   resolve them to campaign_id, and present the name-to-ID mapping. Do not invent IDs by guessing.
   * Campaign names mix half-width | and full-width ｜ as separators.
   Products can be passed as ASINs directly (the tool converts them to internal UUIDs; unregistered ASINs are skipped with a warning).
   Always include the count and the breakdown of skipped ASINs in the output.
3. 🔴 Always preview with dry_run (dry_run is the default). Call the assignment tool with dry_run left on and present, as-is:
   - the resolved label (name / level / apply_to) and the automatically resolved root_id (column)
   - the assignment path (whether it was auto-determined as SA-specific or shared)
   - the number of targets and the target IDs
   - whether overwrites occur (collisions)
   * When there is no overwrite, the message covers both "the column is empty" and "the same label is already attached,"
     and the two cannot be distinguished. Don't conclude "it will be newly attached" — write "no overwrite will occur (it may already be identical)."
   * Products (ASINs) alone have no API that returns the current label, so even dry_run cannot detect an overwrite in advance.
     For products, always warn that "advance detection is impossible; any existing shared label will be lost."
4. Stop and ask for approval. Once you have presented 1–3 above, stop there and get the user's approval before running for real.
5. Run for real with dry_run turned off. After running, re-fetch the label-level KPI aggregation and confirm and report
   that the targets are attached to the intended label.

[If an overwrite is necessary]
When dry_run detects an overwrite, do not set the overwrite flag on your own judgment.
List the existing labels that would be lost, present them to the user, obtain an explicit overwrite instruction from the user,
and then run with that statement attached as a quotation (the tool requires both the confirmation flag and a quotation of the user's statement,
and rejects short boilerplate as insufficient audit evidence).

[Handling DSP line items]
🔴 MCP has no way to enumerate DSP line item IDs.
DSP reports return rows per line item but do not include the IDs, so a name cannot be resolved to an ID.
Therefore look DSP line item IDs up in the Amazon DSP console in advance and have me pass them to you.
If no IDs have been provided, skip the DSP assignment and state explicitly "not executed: DSP line item IDs not provided"
(do not invent IDs by guessing; go ahead with the campaign and product assignments as usual).
* If you aggregate with shared labels (ALL), the ALL mode of the label-level KPI returns SA campaign and DSP results combined,
  so as long as the DSP side has been labeled separately in the console, the aggregation itself still works.

[Output]
Before assigning, present a list of: label_id / label name / tree / column (root_id) / counts per target type / whether overwrites occur /
skipped ASINs / targets left unexecuted and why.

[After running]
Confirm with the label-level KPI, when you next produce a report, that aggregation along the label axis came out as intended.
Note that the label-level KPI aggregates at weekly / monthly granularity only — it cannot slice an arbitrary number of days.

What you can change — the label name and the assignment targets (specify only the ones you want; omit those you don’t need).

What you get back — a table of target × type × existing-label status × post-assignment label. For product ASINs, no upfront duplicate check is possible, so the overwrite risk is clearly flagged as “caution.”

Changes — after approval, Picaro assigns the labels on its side (existing labels are overwritten).

Note — for DSP analysis, see Analyze Amazon DSP delivery performance. On some AI agent environments the label assignment may not be recognized (fix in progress; it may work via the Picaro-connection extension).

Next steps — check how the assigned labels perform in Check KPIs on the dashboard.

Prompt 3: Manage the label taxonomy

Handle the label taxonomy (category hierarchy → labels) in a single prompt — checking the current state, adding, updating, overseas-marketplace setup, initializing, and deleting.

When to use — when you want to tidy up or rebuild the overall label structure.

What you need — the operation you want to run (one of the below).

Manage the label taxonomy. First check the current state with manage_taxonomy(show), then run one of the following:

- Show: present the current taxonomy structure as-is
- Initialize: clone_default from the demo template
- Add / update: {{category hierarchy or label definition (e.g., add the label "Citrus" to the category "Scent")}}
- Overseas marketplace setup: {{target country's Amazon domain, currency, and language (e.g., US / USD / English)}}
- Delete everything and rebuild: **not recommended — it is a destructive operation and has been reported as unstable in hands-on testing**. If you do run it, present the current structure and get approval first

Once the taxonomy is in place, use it as the prerequisite for auto-classifying the competitor products found in search terms (Prompt 1) and for bulk-labeling search terms (Prompt 2).

What you can change — the operation you want to run.

What you get back — results per operation (a list, an add/update confirmation, an initialization completion, etc.).

Changes — showing the state changes nothing. Add / update / initialize / delete modify the structure on Picaro’s side. Deleting everything is destructive, so it runs only after explicit confirmation.

Next steps — after changing match patterns, run Prompt 2 separately to relabel.

Prompt 4: Register and infer campaign naming rules

Register naming templates for campaigns and ad groups to keep naming consistent at creation time. You can also infer a naming pattern from existing names.

When to use — when campaign names are inconsistent and report aggregation isn’t stable.

What you need — a naming template (your own rule), or existing campaign names to infer from.

Manage campaign / ad group naming conventions:

- Infer a draft naming pattern from about {{count (e.g., 50)}} existing campaign names
- Or, register the naming template {{TEMPLATE (e.g., {brand}_{product_line}_{match_type})}}
- Or, update the existing rule

Apply the inferred or registered template to the naming of every campaign created from now on ("Create Sponsored Products (SP) campaigns").

What you can change — the naming template (expressed in braces, like {brand}_{product_line}_{match_type}) and the sample size used for inference (roughly 30–100 is the sweet spot).

What you get back — a table of inferred naming pattern × match rate × example.

Changes — inference (returning a draft) changes nothing. Registering or updating saves the naming rule to Picaro.

Next steps — the registered naming rule is applied automatically at creation time in Create Sponsored Products (SP) campaigns.

Check KPIs on the dashboard — the prerequisite for label-based KPI aggregation
Analyze high-performing search patterns with N-grams — where label-based clustering runs
Analyze where you stumble between search and purchase (SQP) — read market positioning by label
Create Sponsored Products (SP) campaigns — where naming rules and label design are used