WooCommerce Custom Labels for Google Shopping Campaigns

WooCommerce custom labels for Google Shopping campaigns

WooCommerce custom labels for Google Shopping campaigns provide a controlled way to organise products for reporting, bidding and campaign-level product grouping. When custom_label_0–4 values are planned carefully and submitted through a supported product-data workflow, merchants can separate products by factors such as season, price range, margin group, selling rate or commercial priority without changing the customer-facing product page.

Custom labels are optional Merchant Center product attributes.

They are not product titles, WooCommerce categories, Google product categories, feed labels or customer-visible badges.

They are merchant-defined values created for internal campaign organisation.

Google currently provides five custom-label fields:

• custom_label_0
• custom_label_1
• custom_label_2
• custom_label_3
• custom_label_4

Each field should represent one documented commercial dimension.

For example:

custom_label_0 = season
custom_label_1 = selling_rate
custom_label_2 = price_band
custom_label_3 = margin_group
custom_label_4 = release_year

A product then receives one applicable value in each field:

custom_label_0 = summer
custom_label_1 = best_seller
custom_label_2 = 100_250
custom_label_3 = high_margin
custom_label_4 = 2026

These values can later help organise applicable Performance Max, Shopping or Demand Gen campaign inventory.

They do not guarantee campaign inclusion, impressions, clicks, conversions or sales.

The short answer

A reliable WooCommerce custom-label workflow should:

1. Define the commercial decision each label field will support.
2. Reserve one meaning for each of the five available fields.
3. Create a limited and documented set of allowed values.
4. Identify the authoritative WooCommerce source for every value.
5. Decide whether values apply to products, variations or both.
6. Avoid customer, order or personally identifiable information.
7. Keep spelling and separators consistent.
8. Prevent temporary values from creating uncontrolled label growth.
9. Map the WooCommerce values to the correct Merchant attributes.
10. Submit only one value per custom-label field for each product.
11. Verify the processed values in Merchant Center.
12. Confirm that Google Ads can use the intended product groups.
13. Review existing campaign filters before changing active labels.
14. Prevent another data source or rule from overwriting the values.
15. Recheck the labels after scheduled product synchronisation.

The label structure should be designed before values are added to a large catalogue.

A technically valid label can still be commercially useless if administrators do not know what it means, where it came from or how it should be maintained.

What is a Google Merchant Center custom label?

A custom label is a merchant-defined product attribute used to create specific product filters for applicable Google Ads campaign structures.

Google’s current custom label documentation explains that these attributes can be used for reporting and bidding on groups of products in Performance Max, Shopping and Demand Gen campaigns.

The submitted information is not shown to customers in ads or free listings.

This makes custom labels suitable for internal commercial classifications such as:

• Seasonal group
• Selling-rate group
• Margin group
• Price band
• Release period
• Clearance status
• Campaign priority
• Stock-depth group
• Catalogue role
• Promotional eligibility

Custom labels should not be used to hide inaccurate public product data.

A product still requires accurate customer-facing information, including its title, description, price, availability, identifiers, images and landing page.

The custom label adds an internal grouping layer. It does not replace any required product attribute.

Custom-label format and limits

Google’s current requirements include:

Requirement	Current rule
Available fields	custom_label_0 through custom_label_4
Requirement status	Optional for each product
Values per field	One value for each custom-label field
Value type	String
Length	1–100 characters
Character support	Unicode, with ASCII recommended
Case handling	Not case sensitive
Unique-value limit	Up to 1,000 unique values per custom-label field across the account
Total theoretical limit	Up to 5,000 values across all five fields
Customer visibility	Not shown to customers
Schema.org property	None

The 1,000-value limit applies separately to each field.

If the account exceeds the unique-value limit for a field, Google states that additional values will not be considered for reporting and bidding. Product-group membership involving the additional value may then be evaluated as if that label were not set.

The correct solution is not to move uncontrolled values continually between fields.

The value-generation logic should be corrected and the number of unique values reduced.

One field should have one meaning

A custom-label field should not mix unrelated concepts.

An unsuitable structure would be:

custom_label_0 = summer
custom_label_0 = high_margin
custom_label_0 = clearance
custom_label_0 = 2026

The values describe season, margin, promotion status and release year.

Although only one value would be submitted for any individual product, the field itself has no stable definition.

A better structure is:

custom_label_0 definition: season
Allowed values: spring, summer, autumn, winter, all_season

custom_label_1 definition: selling_rate
Allowed values: best_seller, standard, slow_mover, new_product

custom_label_2 definition: price_band
Allowed values: under_50, 50_100, 100_250, 250_plus

custom_label_3 definition: margin_group
Allowed values: low, medium, high

custom_label_4 definition: commercial_status
Allowed values: core, clearance, launch, limited

This structure remains understandable across products and campaigns.

It also makes rules, audits and future migrations easier to manage.

Custom labels are not feed labels

Custom labels and feed labels are frequently confused.

They solve different problems.

Value	Primary purpose	Product identity	Typical level
Custom label	Groups products for reporting and bidding	Does not form the Merchant product identity	Individual product
Feed label	Identifies and organises product-data combinations and campaign-selectable sources	Participates in Merchant product identity	Product input and data source
Content language	Declares the product-data language	Participates in Merchant product identity	Product input
Offer ID	Identifies the merchant’s offer	Participates in Merchant product identity	Individual offer
Product type	Represents the merchant’s own product taxonomy	Does not normally form Merchant identity	Individual product
Google product category	Places the product in Google’s taxonomy	Does not normally form Merchant identity	Individual product

Merchant API product identity uses the content language, feed label and offer ID combination.

A custom-label change does not create a different product identity in the same way that changing the feed label can.

For example:

en~GB~SKU-100

can remain the same Merchant product identity while its customLabel0 value changes from:

winter

to:

spring

The operation still needs to update the correct product input through the correct data source.

Custom-label updates should not be treated as feed-label migrations.

Custom labels are not WooCommerce categories

WooCommerce categories organise the public or administrative store catalogue.

A category can describe what a product is:

Clothing > Men > Jackets

A custom label can describe how the merchant wants to manage that product commercially:

custom_label_0 = winter
custom_label_1 = best_seller
custom_label_2 = 250_plus
custom_label_3 = high_margin
custom_label_4 = core

The category and custom labels can coexist.

Automatically copying every WooCommerce category into a custom-label field is rarely a complete strategy. Deep category structures can create unnecessary values, inconsistent paths and groupings that do not support a real campaign decision.

If a WooCommerce category is useful for bidding or reporting, it can be mapped deliberately.

The mapping should still have:

• A documented field
• A defined purpose
• A controlled value format
• A fallback rule
• A variation rule
• An update rule
• An owner

Custom labels are not WooCommerce tags

WooCommerce tags can be created for merchandising, search, administration or public navigation.

Stores often accumulate tags such as:

Featured
New
Popular
Summer
Homepage
Gift
Sale
2026
Blue
Premium

Copying all tags into one Merchant custom-label field is not supported because each custom-label field accepts only one value per product.

Selecting the first tag is also unsafe. The first stored tag may not be the most commercially important tag, and its order may change.

If a tag controls a label, create an explicit mapping:

WooCommerce tag: Summer collection
Merchant field: custom_label_0
Merchant value: summer

Do not assume that every tag should be sent to Google.

Custom labels are not product attributes

WooCommerce attributes commonly describe actual product characteristics:

• Colour
• Size
• Material
• Pattern
• Capacity
• Length
• Style

These may be customer-facing attributes and can define variations.

A custom label generally describes an internal business grouping.

For example:

WooCommerce attribute: Colour = Black
Merchant colour: Black
Merchant custom_label_3: high_margin

The colour should be submitted through the supported colour attribute when applicable.

It should not be moved into a custom-label field merely because custom labels are easier to configure.

Custom labels should support campaign organisation, not replace accurate product attributes.

Custom labels are not promotion IDs

A promotion ID connects eligible products with an applicable Merchant promotion.

A custom label can potentially help define or select a group, but it is not automatically a promotion.

For example:

custom_label_4 = clearance

does not create a discount, coupon or Merchant promotion.

The product price, sale price, promotion terms, promotion dates and applicable promotion data must still be accurate.

Google’s promotions data specification includes supported ways to include or exclude products using applicable custom-label values. This is a separate promotions workflow with its own requirements.

Planning the five label fields

The five fields are limited resources.

They should not be assigned casually.

A useful planning table can look like this:

Merchant field	Business definition	Example values	WooCommerce source	Update frequency
custom_label_0	Season	spring, summer, autumn, winter	Product metadata	When collection changes
custom_label_1	Selling rate	best_seller, standard, slow_mover	Controlled reporting rule	Scheduled review
custom_label_2	Price band	under_50, 50_100, 100_250, 250_plus	Current product price	When price crosses a band
custom_label_3	Margin group	low, medium, high	Protected commercial field	When cost or price changes
custom_label_4	Catalogue role	core, launch, clearance, limited	Product metadata	Manual commercial review

The table should be stored in an internal operational document.

Administrators should know:

• Who defines each field
• Where the source value is stored
• Which values are allowed
• What happens when the source is empty
• Whether values are inherited by variations
• When values are recalculated
• Which campaigns use the field
• Whether historical values may be removed
• How changes are tested
• How values are reversed

Choosing useful custom-label dimensions

A useful label leads to a real reporting, bidding, inclusion or exclusion decision.

Before reserving a field, ask:

1. Will products be managed differently because of this value?
2. Can the value be calculated or maintained reliably?
3. Does the value remain meaningful across the catalogue?
4. Can every administrator understand the definition?
5. Does the value expose confidential or personal information?
6. Will it create too many unique values?
7. Can it be verified after submission?
8. Can campaigns continue to work if the value changes?
9. Does an existing product attribute already solve the problem?
10. Is the label worth using one of only five available fields?

If there is no operational answer, the label may not be necessary.

Seasonal labels

Seasonal values can support product grouping such as:

spring
summer
autumn
winter
all_season
holiday

Do not generate the value from the current month unless that is genuinely the store’s documented commercial logic.

A winter coat does not become a summer product simply because it remains in stock in July.

The label should describe the planned commercial group, not an accidental calendar condition.

Selling-rate labels

Possible controlled values include:

best_seller
standard
slow_mover
new_product

The store must define how a product enters and leaves each group.

Avoid using an exact number of sales as the label:

sales_137
sales_138
sales_139

This creates unstable values and can quickly increase unique-value counts.

Use bands based on a documented review period and commercial rule.

Do not describe a product as a best seller publicly unless the claim is accurate. Custom labels are not customer-visible, but the underlying business classification should still be based on reliable data.

Price-band labels

A price-band field can support groups such as:

under_50
50_100
100_250
250_500
500_plus

The bands should:

• Use one currency basis
• Avoid overlapping ranges
• Define boundary handling
• Reflect the submitted product price
• Account for sale-price rules
• Be recalculated when the price changes
• Treat variation prices consistently
• Remain stable enough for campaign use

A product priced exactly at 100 should not unpredictably enter both 50_100 and 100_250.

Define whether the first range includes its upper boundary or the second range includes its lower boundary.

For multi-currency stores, do not compare unconverted values from different currencies as if they were equivalent.

Margin labels

Margin labels can support internal commercial grouping:

low
medium
high

Cost and margin data may be commercially sensitive.

If a label is submitted, use a broad group rather than exposing exact cost or profit values.

Avoid values such as:

cost_18_47
margin_13_26_percent
supplier_price_21_90

Use a controlled classification calculated in the merchant’s trusted system.

WooCommerce should remain the authoritative commercial source or receive the result from an authorised upstream system.

Do not guess missing cost data.

A product with unknown cost should not automatically be labelled high_margin.

Stock-depth labels

Possible groups include:

low_stock
normal_stock
deep_stock
preorder

Availability should still be submitted through the supported availability attribute.

A custom label does not replace:

IN_STOCK
OUT_OF_STOCK
PREORDER
BACKORDER

Stock-depth labels can change frequently. Recalculate them carefully and consider whether frequent group movement will disrupt campaign analysis.

Never allow a stale custom label to override the actual availability submitted for the product.

Commercial-status labels

A stable catalogue-role field may contain:

core
launch
clearance
limited
test_group

The meaning of each value should be documented.

clearance should not automatically mean that a product has a sale price.

launch should not remain indefinitely after the introduction period ends.

test_group should not be applied to production products without an actual testing purpose.

Labels should describe the current operational decision.

Product and variation planning

WooCommerce variable products require offer-level review.

Variations can differ by:

• Price
• Sale price
• Stock
• Availability
• Margin
• Market eligibility
• Seasonal relevance
• Commercial priority
• Landing-page configuration

If every variation has the same commercial classification, inheriting a parent-level label may be appropriate.

For example:

Parent product: Winter jacket
All variations: custom_label_0 = winter

If variation margins differ, applying one parent margin label to every variation can be misleading.

For example:

Small black variation: custom_label_3 = high
Large red variation: custom_label_3 = low

The integration should determine which WooCommerce record supplies the Merchant offer.

A variation should not receive another variation’s value merely because they share a parent product.

Record:

• Parent product ID
• Variation ID
• SKU
• Merchant offer ID
• Source field
• Inheritance rule
• Final submitted value

Custom labels in Merchant API

Google’s current Merchant API ProductAttributes reference exposes the five values as:

customLabel0
customLabel1
customLabel2
customLabel3
customLabel4

A simplified product-attribute example can look like:

{
  "title": "Example waterproof jacket",
  "link": "https://example.com/product/example-waterproof-jacket/",
  "availability": "IN_STOCK",
  "customLabel0": "winter",
  "customLabel1": "best_seller",
  "customLabel2": "100_250",
  "customLabel3": "high",
  "customLabel4": "core"
}

This is only a simplified attribute fragment.

A real product operation also requires the appropriate Merchant account, API data source, product identity and other applicable product information.

A successful request does not prove that:

• The values reached the intended product
• The correct variation was updated
• Another source did not override them
• Google Ads can already select the values
• The campaign contains the product
• The product is approved
• The product is eligible in every country
• The label strategy is commercially useful

The processed product and campaign structure must also be reviewed.

Missing values should be handled deliberately

Not every product needs all five custom labels.

Google describes the fields as optional.

If a value is unknown, the store can:

• Leave the field empty
• Use a documented fallback such as unclassified
• Stop the product operation when the field is business-critical
• Place the product in a controlled review queue

Do not use several inconsistent fallbacks:

unknown
Unknown
not_set
none
n_a
other
-

Although case differences may not create separate campaign meanings, inconsistent representations make internal management difficult.

Choose one documented fallback only where a fallback is genuinely useful.

Leaving a field empty can be more accurate than assigning a misleading value.

Use a controlled vocabulary

A controlled vocabulary is a list of approved values for each field.

For example:

custom_label_0:
- spring
- summer
- autumn
- winter
- all_season

custom_label_3:
- low
- medium
- high
- unknown

Products should not create values freely from arbitrary text.

Without controls, administrators may submit:

best_seller
best-seller
bestseller
best seller
top_seller
Best Seller

Even where case handling is not significant, different words and separators can create different values.

Use one format consistently.

Lowercase ASCII values with underscores can be easy to maintain:

best_seller
high_margin
all_season
price_250_plus

This is an operational convention, not a Google requirement.

Do not use personally identifiable information

Custom labels are product-data fields.

They should not contain:

• Customer names
• Customer email addresses
• Telephone numbers
• Order numbers linked to individuals
• Delivery addresses
• User IDs
• Advertising identifiers
• Payment information
• Private account details
• Internal authentication values
• API keys
• Access tokens
• Licence keys
• Supplier credentials

A label should describe the product’s commercial grouping.

It should not describe an individual customer or expose protected business credentials.

Avoid high-cardinality values

High-cardinality values create many unique labels.

Unsuitable examples include:

updated_2026_07_30_14_33_02
order_84752
visitor_19382
session_a81d3
stock_137
sales_482
random_ab91f

These values can consume the account-level limit without providing reusable product groups.

Better values are stable bands:

updated_recently
deep_stock
high_sales
priority_group_a

Only use these when their definitions support a real campaign decision.

Choosing the authoritative WooCommerce source

Each custom label needs a single authoritative source.

Possible sources include:

• Dedicated product metadata
• A controlled custom taxonomy
• A selected WooCommerce category
• A selected WooCommerce tag
• Product price
• Sale status
• Stock quantity
• Publication date
• A protected margin classification
• An ERP-supplied commercial group
• A manual review field

The source should not change depending on which scheduled task runs first.

For example, avoid this situation:

Manual product field: high
Nightly import: medium
Campaign rule: high_margin
Supplemental source: priority

The final processed value becomes difficult to predict.

Define source precedence before submission.

Automatic calculation versus manual assignment

Automatic labels are useful when the source data and rule are reliable.

Examples include:

• Price bands
• Stock-depth bands
• Product age groups
• Sale-status groups

Manual labels are useful when commercial judgement is required.

Examples include:

• Core catalogue
• Launch priority
• Clearance approval
• Strategic product
• Protected test group

A hybrid workflow can calculate a proposed value and require manual confirmation.

The best method depends on:

• Catalogue size
• Update frequency
• Source reliability
• Staff responsibilities
• Campaign sensitivity
• Available audit records

Automation should not be used merely because it is possible.

Merchant Center attribute rules

Google allows applicable attribute rules to create or transform custom-label values from submitted product data.

For example, a rule can assign price-band labels based on a submitted price.

Google’s custom-label guidance provides price-range rules as an example.

Before relying on a Merchant Center rule, record:

• Source attribute
• Conditions
• Output value
• Data source
• Country or language scope
• Rule priority
• Expected product count
• Test result
• Owner
• Last review date

Use test and preview functions where available before applying a rule broadly.

A Merchant Center rule can override or transform a value supplied by WooCommerce.

When the processed value differs from the API request, inspect rules before repeatedly resubmitting the same product.

Multiple data sources can create conflicts

Custom-label values may be affected by:

• Merchant API inputs
• Older Content API integrations
• Scheduled XML files
• Uploaded files
• Google Sheets
• Supplemental data sources
• Merchant Center attribute rules
• Previous WooCommerce plugins
• ERP integrations
• Supplier imports
• Manual Merchant Center edits

For each active source, record:

• Data source ID
• Source name
• Input type
• Product identity
• Custom-label fields supplied
• Update schedule
• Applicable rules
• Owning integration
• Last successful update

Do not assume that disabling an old plugin removes or stops every value it previously submitted.

Do not create another source merely because one label appears incorrectly.

First identify the source responsible for the processed value.

Google Ads product and listing groups

Google’s current product and listing group guidance explains that Shopping campaign inventory can be subdivided using attributes such as:

• Google product category
• Product type
• Brand
• Condition
• Item ID
• Custom label 0–4

This can allow applicable product collections to be included, excluded, reported on or assigned different bid treatment.

A possible structure is:

All products
└── custom_label_4
    ├── core
    ├── launch
    ├── clearance
    └── everything else

Another level may then use a second attribute:

clearance
└── custom_label_3
    ├── high
    ├── medium
    └── low

The exact options depend on the campaign type and current Google Ads interface.

Do not create overly fragmented groups without enough products or a real management purpose.

Custom labels make segmentation possible. They do not prove that every segment needs a different bid or budget.

Allow time for campaign availability

Google’s product-group documentation currently advises allowing approximately 24–48 hours for recently added or updated custom labels to become available in Google Ads product groups.

This is guidance, not a guaranteed processing time.

Do not repeatedly change a correct label simply because it does not appear immediately.

Record:

• Submission time
• Merchant processing result
• Processed product value
• Google Ads visibility
• Campaign status
• Time of final verification

If the value remains unavailable, confirm the Merchant account link, product identity, campaign source, feed label and product eligibility.

Changing active labels safely

Before changing a label used by an active campaign:

1. Identify every affected product.
2. Identify the current value.
3. Record the replacement value.
4. Find every campaign using that field.
5. Review product and listing groups.
6. Review inventory filters.
7. Review exclusions.
8. Review reports that depend on the value.
9. Update a small representative product group.
10. Verify the processed Merchant values.
11. Wait for the values to become available in Google Ads.
12. Update campaign structures where required.
13. Confirm that products remain included or excluded as intended.
14. Expand the change in controlled batches.
15. Review results after scheduled synchronisation.

Deleting an old value before the new campaign structure is ready can leave products in an unintended “everything else” group.

Changing label meaning while retaining the same value can also corrupt historical comparisons.

Do not redefine a field silently

Suppose custom_label_0 originally means:

Season

It should not suddenly be redefined as:

Margin

while existing campaigns still interpret values as seasons.

A field-definition change is a migration.

The migration should include:

• Old definition
• New definition
• Affected values
• Affected products
• Affected campaigns
• Update sequence
• Rollback procedure
• Validation evidence
• Completion date

If historical reporting matters, consider whether a different unused field can support the new dimension.

PW Merchant API and custom labels

PW Merchant API provides an API-oriented product-management workflow between WooCommerce and Google Merchant Center.

Depending on the installed version, supported field mappings and configuration, it can help merchants:

• Read supported WooCommerce product information
• Identify simple products and variations
• Maintain stable offer IDs
• Prepare supported Merchant product attributes
• Submit product operations through Merchant API
• Update previously submitted products
• Record successful or failed operations
• Review applicable processed product information
• Synchronise supported WooCommerce changes

Where the installed workflow supports custom-label mappings, the five Merchant API fields can be populated from defined WooCommerce sources.

The integration should not invent the commercial meaning of a label.

The merchant remains responsible for deciding:

• What each field means
• Which values are allowed
• Which WooCommerce source is authoritative
• Whether a product belongs to a group
• How margin is calculated
• How sales velocity is measured
• Which campaigns use the value
• When a classification should change

PW Merchant API cannot:

• Guarantee Google approval
• Guarantee campaign inclusion
• Guarantee impressions or sales
• Decide commercial strategy independently
• Calculate unknown cost data accurately
• Convert arbitrary WooCommerce tags into a reliable campaign plan
• Prevent every other active data source from changing a value
• Replace Google Ads campaign management
• Guarantee a custom label will improve performance
• Correct inaccurate WooCommerce source information automatically

WooCommerce remains the authoritative commercial source. PW Merchant API manages supported communication, and Google independently processes the submitted information.

WooCommerce implementation workflow

A practical custom-label implementation can follow this sequence:

1. Export or review the current product catalogue.
2. Identify the decisions custom labels should support.
3. Select no more than five useful dimensions.
4. Define one purpose for every selected field.
5. Create the allowed-value list.
6. Select an authoritative WooCommerce source for each value.
7. Define variation inheritance.
8. Define missing-value behaviour.
9. Define update triggers.
10. Identify existing Merchant data sources.
11. Identify existing Merchant Center rules.
12. Identify existing Google Ads product groups.
13. Test the mapping on a small product group.
14. Submit the products.
15. Record the operation results.
16. Open the processed Merchant products.
17. Confirm all five applicable values.
18. Check for overwritten or missing values.
19. Allow applicable processing time.
20. Review values in Google Ads.
21. Create or update product groups.
22. Confirm intended inclusion and exclusion.
23. Expand the implementation gradually.
24. Repeat the check after scheduled synchronisation.
25. Audit unique-value counts periodically.

This workflow separates label planning from technical submission.

Both stages are necessary.

Example WooCommerce mapping

Consider a variable WooCommerce product:

Product: Waterproof hiking jacket
Parent ID: 420
Variation ID: 431
SKU: JACKET-BLK-M
Price: 179.00 GBP
Season: Winter
Selling group: Best seller
Margin group: High
Catalogue role: Core

The planned Merchant values may be:

customLabel0: winter
customLabel1: best_seller
customLabel2: 100_250
customLabel3: high
customLabel4: core

The merchant should verify:

• The price band uses GBP
• The selected variation costs 179.00 GBP
• The margin group belongs to variation 431
• The winter value applies to this variation
• The product is not already classified differently by another source
• The product operation updates the correct offer ID
• Merchant Center processes the intended values
• Google Ads displays the labels after applicable processing
• Campaign groups use the values as intended

The example is a mapping pattern, not a recommended universal label strategy.

Verifying custom labels in Merchant Center

After submission:

1. Open the intended Merchant Center account.
2. Search for the exact offer ID.
3. Open the processed product.
4. Confirm the owning data source.
5. Confirm the content language.
6. Confirm the feed label.
7. Confirm that the correct variation was processed.
8. Find the processed custom-label values.
9. Compare them with the operation record.
10. Check whether an attribute rule transformed them.
11. Check whether a supplemental source supplied another value.
12. Review product issues.
13. Review country status.
14. Review marketing-method status.
15. Repeat the check after the next scheduled update.

Do not verify a product by title alone.

Several variations or language versions may have similar titles.

Use the complete Merchant identity and data source.

Verifying labels in Google Ads

After the Merchant values are processed and available:

1. Open the linked Google Ads account.
2. Select the intended campaign.
3. Confirm the Merchant Center account.
4. Confirm the feed label or applicable inventory source.
5. Open the product or listing group structure.
6. Select the intended custom-label field.
7. Confirm the expected values appear.
8. Check the “everything else” group.
9. Confirm intended products are included.
10. Confirm excluded products are not unintentionally active.
11. Review applicable product-level reporting.
12. Record the campaign configuration.
13. Recheck after the next product update.

Do not modify bids based only on the presence of a label.

Commercial and advertising decisions should use reliable performance data and appropriate professional judgement.

Common mistakes

Using all five fields without a purpose

Five fields are available, but merchants do not have to use all five.

Mixing several meanings in one field

Season, margin and clearance values should not share one undefined field.

Submitting multiple values in one string

A value such as:

summer,high_margin,clearance

is one combined string, not three separate custom labels.

Creating a unique label for every product

Values such as individual SKUs defeat the purpose of reusable grouping and can approach account limits.

Copying every WooCommerce tag

One custom-label field cannot reliably represent an uncontrolled collection of tags.

Confusing custom labels with feed labels

Custom labels group individual products. Feed labels have a different data-source and product-identity role.

Using custom labels as public attributes

A custom label does not replace colour, size, condition, availability or other supported product information.

Adding customer data

Product custom labels should never contain personal customer or order information.

Changing field definitions without campaign review

Active campaigns may continue interpreting the field according to its old meaning.

Ignoring variations

A parent-level margin or price band may be incorrect for individual variations.

Creating unstable price bands

Overlapping boundaries can move identical prices into different groups.

Using exact stock or sales totals

Constantly changing numeric values create excessive unique labels and unstable campaign groups.

Assuming a label creates a promotion

A clearance label does not create a sale price or Merchant promotion.

Checking only the API response

Technical acceptance does not confirm the processed value or campaign availability.

Repeatedly resubmitting during processing

Google Ads may require additional time before updated labels appear in product groups.

Ignoring Merchant Center rules

A rule may transform a value after it is submitted.

Ignoring old data sources

Another integration can restore an obsolete value during its next scheduled update.

Frequently asked questions

What are custom labels in Google Merchant Center?

They are optional merchant-defined product attributes used to group products for reporting and bidding in applicable Performance Max, Shopping and Demand Gen campaigns.

How many custom labels can one product have?

A product can use up to five fields: custom_label_0 through custom_label_4. Each field accepts one value for that product.

Are custom labels visible to customers?

No. Google states that the information in these fields is not shown to customers in ads or free listings.

Are custom labels required for product approval?

No. They are optional product attributes. Required product data and applicable policies still determine eligibility.

Can a custom label contain more than one value?

Each field accepts one value. A comma-separated string is treated as one combined value, not several labels.

What is the maximum custom-label length?

Google’s current specification allows 1–100 characters.

Are custom labels case sensitive?

Google currently describes the fields as not case sensitive. Consistent casing is still recommended for reliable administration.

How many unique values can I create?

Google currently permits up to 1,000 unique values for each custom-label field across the account.

Do I have to use all five fields?

No. Use only fields that support a documented reporting, bidding or inventory-management purpose.

Can I use WooCommerce categories as custom labels?

Yes, when a deliberate mapping exists. Automatically copying the entire category structure is not always useful.

Can I use WooCommerce tags?

A selected tag can be mapped through a controlled rule. Copying arbitrary or multiple tags into one field is unreliable.

Can I use custom labels for product colour or size?

Those values should normally use their supported product attributes. Custom labels should not replace accurate product information.

Is a custom label the same as a feed label?

No. Feed labels participate in Merchant product identity and data-source organisation. Custom labels group individual products for applicable campaign use.

Does changing a custom label create a new Merchant product?

Not by itself. Custom labels do not form the same language–feed-label–offer-ID identity combination. The correct existing product input must still be updated.

Can custom labels be assigned automatically?

Yes. Values can be derived from a trusted WooCommerce source or created through applicable Merchant Center attribute rules. The logic should be documented and tested.

Can custom labels use product prices?

A price band can be used. The rule must define the currency, range boundaries, sale-price handling and variation behaviour.

Can I submit an exact profit margin?

A broad controlled margin group is usually safer operationally. Do not expose sensitive exact cost or profit data unnecessarily.

Can a clearance label create a sale?

No. It only groups the product. The product’s price, sale price and any Merchant promotion must be configured separately.

Why is my new custom label missing in Google Ads?

First verify that Merchant Center processed the value for the intended product. Google currently advises allowing approximately 24–48 hours for recently updated labels to become available in Google Ads product groups. This timeframe is guidance rather than a guarantee.

Why did Merchant Center change my submitted value?

Check attribute rules, supplemental sources, other primary sources and previous integrations.

Can the same value appear in different custom-label fields?

It may be technically possible, but each field should have its own documented meaning. Reusing ambiguous values can confuse campaign management.

Can custom labels improve Shopping performance?

They can support more structured reporting and bidding decisions. They do not guarantee improved performance, visibility or sales.

Can PW Merchant API create my label strategy?

The integration can communicate supported mapped values. The merchant must define the commercial meaning, source and maintenance rules.

Does a successful Merchant API response mean the label is ready in Google Ads?

No. Confirm the processed Merchant product and allow applicable synchronisation time before checking Google Ads.

Final custom-label checklist

Before deploying WooCommerce custom labels, confirm that:

• The intended Merchant Center account was identified.
• The linked Google Ads account was identified.
• Existing campaigns were reviewed.
• Existing product groups were reviewed.
• Existing inventory filters were reviewed.
• Existing exclusions were reviewed.
• All active Merchant data sources were identified.
• Previous WooCommerce integrations were identified.
• Scheduled XML sources were identified.
• Supplemental sources were identified.
• Merchant Center attribute rules were identified.
• ERP or supplier imports were identified.
• Every custom-label field had one documented meaning.
• Only useful fields were activated.
• An allowed-value list was created for each field.
• Value spelling was standardised.
• Separators were standardised.
• Case conventions were standardised.
• Values remained within the length limit.
• Unique-value limits were considered.
• Only one value was supplied per field.
• Arbitrary combined strings were avoided.
• High-cardinality values were avoided.
• Timestamps were not used as labels.
• Session IDs were not used as labels.
• Customer information was not used.
• Order information was not used.
• Authentication information was not used.
• API keys were not used.
• Access tokens were not used.
• Licence keys were not used.
• Exact confidential cost information was not exposed unnecessarily.
• The authoritative WooCommerce source was recorded.
• Source precedence was defined.
• Missing-value behaviour was defined.
• Fallback values were standardised.
• Automatic calculation rules were documented.
• Manual classifications had an owner.
• Update triggers were defined.
• Price-band currencies were defined.
• Price boundaries did not overlap.
• Sale-price handling was defined.
• Stock-band logic was defined.
• Selling-rate periods were defined.
• Margin calculations used authoritative data.
• Seasonal classifications were meaningful.
• Commercial-status labels had expiry or review rules.
• Parent-product inheritance was defined.
• Variation-level exceptions were defined.
• Each variation received the correct value.
• WooCommerce product IDs were recorded.
• Variation IDs were recorded.
• SKUs were recorded.
• Merchant offer IDs were recorded.
• Content languages were recorded.
• Feed labels were recorded separately.
• Custom labels were not confused with feed labels.
• WooCommerce categories were not copied without a mapping.
• WooCommerce tags were not copied without a priority rule.
• Customer-facing product attributes remained accurate.
• Custom labels did not replace condition.
• Custom labels did not replace availability.
• Custom labels did not replace colour or size.
• Custom labels did not replace promotion IDs.
• A representative test group was selected.
• Test products included simple products.
• Test products included applicable variations.
• Product operations used the correct API data source.
• Operation results were recorded.
• Processed Merchant products were opened.
• Processed custom-label values were checked.
• Attribute-rule transformations were checked.
• Supplemental-source changes were checked.
• Country-specific status was reviewed.
• Marketing-method status was reviewed.
• Product issues were reviewed.
• Applicable processing time was allowed.
• Values were checked in Google Ads.
• The “everything else” group was reviewed.
• Intended products were included.
• Unintended products were excluded.
• Existing bids were not changed accidentally.
• Campaign reports remained understandable.
• Field definitions were not silently changed.
• Active label migrations had rollback procedures.
• Updates were expanded in controlled batches.
• Scheduled synchronisation did not restore obsolete values.
• Unique-value counts were reviewed periodically.
• No approval or performance guarantee was assumed.

WooCommerce custom labels are most useful when they represent a small, stable and documented set of commercial decisions.

The five fields should not become a collection of arbitrary tags.

Each field needs one purpose, one authoritative source, one controlled vocabulary and one maintenance rule.

Merchant API supports customLabel0 through customLabel4 as product attributes. A WooCommerce Google Merchant Center plugin can communicate supported values, but it cannot determine the merchant’s campaign strategy or guarantee advertising results.

WooCommerce should remain the authoritative commercial source. PW Merchant API can manage supported product communication, while Google Merchant Center and Google Ads independently process and use the submitted information.

A carefully planned label structure helps merchants understand which products belong together, why they are grouped and how campaign decisions relate to reliable WooCommerce data.