By Marius Pahomi · Published 2026-06-07 · Last updated 2026-08-29
Custom labels 0 through 4 are five free-text fields in a Google Shopping feed that exist for exactly one purpose: letting you split products into groups that Google Ads and Meta can bid on differently. Google attaches no meaning to the values — "hero", "clearance" and "banana" are all equally valid — which is precisely what makes them powerful. The meaning comes from your data.
The highest-leverage way to fill them is with performance data from Google Analytics 4. GA4 already knows, per product, the revenue, the number of purchases, the item views and the view-to-purchase conversion rate for any window you care about. Turn those metrics into a segment — top sellers, products that convert well but sell little, products nobody buys — write that segment into a custom label, and every campaign in Google Ads or Meta can suddenly treat a proven winner differently from dead weight. Advertisers who split campaigns this way stop spending bestseller budget on products that have never produced a single transaction.
This guide covers the full pipeline: what custom labels are and what Google actually does with them, which GA4 metrics matter, how performance segments are computed, a slot convention that keeps all five labels useful, campaign structures that exploit the segmentation in Performance Max and Meta, and the honest limitations — including what happens when your GA4 property has no item-level data at all.
Validate your feed first — free, in your browser — free, in your browser, no account needed.
The Google Shopping feed specification defines five optional attributes — custom_label_0 through custom_label_4 — that accept any string value. Per Google’s attribute documentation, each product can carry one value per label, and an account can use up to 1,000 unique values per label across the catalog. Google never interprets the contents: the values exist solely so that you can reference them when structuring campaigns.
That neutrality is the feature. Unlike structured feed attributes (price, availability, GTIN), which Google validates and uses for matching, custom labels are a private channel between your data pipeline and your bidding setup. Whatever segmentation logic you can compute, you can ship.
In Google Ads, custom labels appear as a subdivision dimension for listing groups (Shopping and Performance Max): you can split a product group by custom_label_3 and assign different bids, budgets or exclusions per value. In Performance Max, labels are the practical way to route products into separate campaigns with separate budget envelopes.
Meta supports the same five fields in catalog feeds, where they drive product set definitions — the filters that decide which products an Advantage+ or dynamic ads campaign may show. The same label value therefore segments both ecosystems from a single feed pipeline.
Most merchants start with hand-assigned labels: "summer", "premium", "new-arrivals". These rot. A product tagged "bestseller" in March may have stopped selling in May, but the label persists because nobody re-evaluates 5,000 SKUs by hand. Campaigns keep allocating budget based on a snapshot that no longer describes reality.
Static labels also encode opinion rather than measurement. "Premium" describes what you think of a product; a 90-day conversion rate describes what buyers actually did. When the two disagree, the money follows the label — in the wrong direction.
A label computed from a rolling GA4 window re-evaluates itself on every sync. A product that stops selling slides out of the top-revenue segment automatically; a long-tail product that starts converting climbs in. The campaign structure stays still while the products flow through it — which is exactly how bidding systems want to consume segmentation.
This is the same principle that makes smart bidding work: feed the algorithm honest, current signals and let it allocate. Custom labels are how you make product-level performance one of those signals.
GA4’s item-scoped reporting exposes, per item_id: item revenue, items purchased, items viewed and items added to cart. From views and purchases you derive the fifth signal, the view-to-purchase conversion rate. Those five numbers, over a 30-day window, are sufficient to segment any catalog meaningfully.
The window length is a real decision: 7 days reacts fast but is noisy for low-traffic catalogs; 90 days is stable but slow to demote a product that died. 30 days is the default compromise and matches how most merchants review campaign performance.
None of this works unless the store sends GA4 ecommerce events — view_item, add_to_cart, purchase — with a populated items[] array whose item_id matches the product IDs in your feed. That matching key is the whole bridge: analytics rows join to feed rows on it.
When IDs don’t match exactly (Shopify variant IDs vs feed SKUs is the classic case), a fallback join on item name can recover a useful fraction, but every unmatched product simply has no performance data — and should be labeled accordingly rather than guessed.
GA4 processing introduces a 24–48 hour lag between a purchase happening and the item metrics reflecting it. For segmentation this is harmless: segments computed over 30 days of data do not meaningfully change because the last day is missing. Resist the urge to chase real-time labels — bidding systems penalise signal churn more than they reward freshness.
Absolute thresholds ("hero = over €1,000 revenue") break the moment you change catalog size or currency. Percentile ranking does not: each product is ranked 1–100 against your own catalog on revenue, transactions and views. A hero in a 50-product store and a hero in a 50,000-product store are both simply at the top of their own distribution.
FeedArc computes exactly this: per-product percentile ranks over the trailing 30 days, then a segment from the combination of ranks and conversion rate.
The five segments, in ladder order:
These names and definitions are not marketing copy — they are the literal segment values the engine writes, so what you read here is what appears in your feed.
Hero and dead stock are obvious; promising is where money hides. A product converting above the catalog average on thin traffic is a scaling candidate: it has proven the offer works and only lacks impressions. Routing the promising segment into its own campaign with a growth budget is the single most common win from performance labeling — it surfaces products a revenue-sorted report never shows you.
Five labels means five independent segmentation axes — if you keep them independent. The convention that scales:
custom_label_0 — revenue tier (top_performer / steady_seller / low_performer)custom_label_1 — margin tier (high / medium / low / negative), if cost data existscustom_label_2 — seasonality or lifecycle (evergreen / seasonal / clearance)custom_label_3 — GA4 performance segment (the five-segment ladder above)custom_label_4 — reserved for experiments and temporary splitsMixing axes in one slot ("summer-bestseller-highmargin") destroys the ability to subdivide on each dimension separately in listing groups — the entire point of having five fields.
Google allows up to 1,000 unique values per label, but campaign structures want 3–6. Every distinct value is a potential listing-group branch someone has to manage. Lowercase, underscore-separated, stable spellings ("dead_stock", not "Dead Stock!" one month and "deadstock" the next) prevent silent campaign-filter breakage when a value drifts.
The canonical structure splits Performance Max spend into two or three campaigns filtered by label: a winners campaign (hero + bestseller) with the dominant budget and an aggressive target, a growth campaign (promising) with a modest budget and looser targets, and optionally a maintenance campaign for the rest. Budget stops leaking from proven products to products that have never converted, and each campaign’s automated bidding optimises within a coherent population.
In Meta Commerce Manager, define product sets filtered on the same label values — a "hero + bestseller" set for prospecting Advantage+ campaigns, a separate set for retargeting that may include promising products. Because the labels travel inside the catalog feed, Google and Meta segmentation stay synchronized by construction: one pipeline, two ad ecosystems.
Dead stock has three defensible treatments: exclude it from paid campaigns entirely (the default — zero transactions earns zero budget), route it to a clearance campaign with deep-discount creative, or leave it in organic-only surfaces where impressions are free. The wrong move is leaving it mixed into your main campaign, where smart bidding will keep probing it with money that proven products would have converted.
A product can sit comfortably in the bestseller segment while losing money on every sale — high ad spend against a thin margin. Revenue-based labels cannot see this; a margin tier in custom_label_1 can. With cost-of-goods data, classify each product into high / medium / low / negative margin and subdivide the winners campaign one more level: high-margin bestsellers earn the most aggressive targets.
Profit on ad spend (POAS) reframes bidding from "revenue per ad euro" to "profit per ad euro". The label pipeline is the delivery mechanism: margin tiers in the feed give bidding systems a profit-aware segmentation without waiting for Google to support native margin bidding. Merchants whose platforms expose cost data (Shopify, WooCommerce and others carry cost fields) can automate the entire layer.
Recompute segments when the analytics window moves meaningfully — daily for most catalogs, weekly for low-traffic stores. Each sync re-ranks the catalog, rewrites labels, and the next feed generation carries the update. More frequent than daily adds churn without information: a 30-day window barely changes hour to hour.
A product hovering at the 80th revenue percentile can oscillate between bestseller and not-bestseller on alternate days, dragging itself between campaigns and resetting learning each time. Two stabilisers help: ranking over a window long enough to smooth noise (30 days), and treating segment changes as events worth reviewing rather than auto-applying instantly when a product sits within a point or two of a boundary.
The labeling pipeline is only worth its complexity if the split campaigns outperform the unsplit baseline. The clean way to know is an A/B test on the feed itself — identical products, with and without the segmentation applied — evaluated with statistical significance rather than eyeballing a dashboard. Feed-level experiments with chi-squared significance testing turn "it feels better" into a defensible number.
If only 40% of feed products matched a GA4 item, the other 60% have no data — and a pipeline that silently labels them "dead_stock" is lying. Unmatched products deserve an explicit no-data value (or an empty label) so campaign filters can treat "we don’t know" differently from "we know it doesn’t sell". Check the match rate before trusting any segment distribution.
The structure should be stable; the products flow through it. Merchants who rename label values or re-cut segment boundaries monthly force their own campaigns into perpetual relearning. Choose the convention once, document it, and let the automation do the moving.
Custom labels segment products; they do not fix disapprovals, missing GTINs or rejected images. A product that Google won’t serve is invisible regardless of how cleverly it is labeled. Feed hygiene — resolving Merchant Center disapprovals — comes first; segmentation multiplies the value of products that are already eligible.
FeedArc computes these five performance segments automatically from your GA4 data and writes them into custom labels with one rule template — then lets you prove the effect with built-in statistically tested feed A/B experiments.
Custom labels 0 through 4 are five free-text fields in Google Shopping feeds used to segment products for bidding — typically populated from Google Analytics 4 performance data so high-revenue products can be bid on differently from low-revenue ones.
POAS (Profit On Ad Spend) measures the gross profit generated per unit of ad spend — (revenue minus cost of goods minus ad spend) divided by ad spend — instead of the gross revenue measured by ROAS.
Feed rules are transformations applied to a product catalog before export — mapping internal field names to channel-specific schemas, filtering out ineligible products, enriching data, or applying conditional logic per channel.
A product feed is a structured file (XML, CSV, TSV, or JSON) that lists every product in your catalog with the fields advertising and marketplace platforms need to display them.
Build a Google Shopping XML feed that clears Merchant Center review. FeedArc maps required attributes and fixes GTIN and category errors before export.
Generate a Meta Catalog feed for Facebook Shops, Instagram Shopping, and Dynamic Ads. FeedArc catches row-level validation errors, applink included.
Apply this playbook to your own product feed in minutes. Free to start, no credit card needed.