WooCommerce settings reference
Every option in the WooCommerce section of the GTM4WP settings, what it changes in the data layer, what it is set to before you touch it, and when it is worth changing.
This page describes GTM4WP 2.0.0 and newer. Where the legacy 1.x versions of the plugin behaved differently, the older behavior is marked with a bold GTM4WP 1.x: lead-in.
Where these settings live
Open the GTM4WP plugin settings page and go to the WooCommerce section. The options are split into five groups: General, Product data, Data layer content, Purchase tracking and Advanced. This page follows the same order.
GTM4WP 1.x: the same options live on the Integration->WooCommerce tab, in one long list rather than in groups.
The badges next to some option names
- experimental: whether it works correctly depends on something GTM4WP cannot check on every site, such as your theme, a third party plugin or your hosting setup. Always off by default
- beta: complete, and expected to work on any standard WordPress and WooCommerce install. It stays in beta until it has enough real world use to be called stable
- no badge: stable, proven in the field with no open reproducible issues
General
Track e-commerce
Default: off.
The master switch of the whole WooCommerce integration. While it is off, GTM4WP registers none of its WooCommerce hooks, so nothing on this page reaches the data layer. That includes the order data and customer data controlled by the other groups, even though those options read as if they were independent. Turn this on first.
Product data
These options shape the item data itself, so they affect every consumer of it: Google Analytics 4, a Google Ads remarketing tag of your own, and the product data Google Ads receives through a linked Analytics property.
Products per impression
Default: 10.
Splits product impression data into several events instead of sending one large block with the page view. A category page with many products can otherwise carry more data than the measurement request can hold, and the impressions go missing. Enter 0 to send all impression data with the page view. If you raise the number, 10 to 15 is a sensible floor.
Use SKU instead of ID
Default: off.
Sends the WooCommerce SKU as the product identifier instead of the WordPress post ID. Turn it on when your product feed is built from SKUs, because Google Ads can only connect a product in your feed to a product a visitor viewed when both use the same identifier. A product with no SKU falls back to its ID.
Taxonomy to be used for product brands
Default: none selected.
Names the custom taxonomy that holds your product brands, which GTM4WP then reports as the brand of each item. Leave it unset if you do not keep brands in a taxonomy.
The list of choices is built from the taxonomies registered on the current request. Your stored choice survives a moment when the plugin that registers the taxonomy is inactive, so a deactivation during an update does not silently blank the setting.
Include full category path
Default: off.
Reports the full category path of each product rather than a single category name. On a large catalogue with heavy traffic this can cause performance problems, so watch your page generation times after turning it on.
Google Ads Business Vertical
Default: Retail.
Tells Google Ads which algorithm suits your dynamic remarketing campaign, and decides the name of the item identifier parameter in your tagging. There are nine choices: Retail, Education, Flights, Hotel rental, Jobs, Local deals, Real estate, Travel and Custom.
Flights and Travel send the identifier as destination. Every other vertical sends it as id. A stored value that is no longer valid falls back to Retail. GTM4WP does not send the advanced parameters of the special verticals, such as origin for Flights or location_id for Jobs. The dynamic remarketing guide covers the rest of the setup.
Product ID prefix
Default: empty.
Puts a fixed text in front of the product identifier, for example woocommerce_gpf. Some feed generator plugins prefix the IDs they write into the feed, and the feed and the site tagging have to agree on the identifier.
Fire view_item on parent product
Default: off.
Also sends a view_item event with the parent product data when the page of a variable product loads. Useful when your reporting is organized around the parent product rather than the variation the visitor happens to select.
Persist product list attribution across the funnel (experimental)
Default: off.
When a visitor clicks a product in a list, this remembers which list it was, as item_list_name and item_list_id, in a first-party cookie. It then carries that list onto the later view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info and purchase events, so Google Analytics 4 can attribute a whole funnel to the list that started it.
On a product page the browser merges the list in rather than the server, so the attribution also survives a full page cache. Leave it off if you already do the same with custom JavaScript in Google Tag Manager, otherwise the attribution is written twice.
Data layer content
Cart content in data layer
Default: off.
Adds the current contents of the cart to the data layer on every page. Site personalization tools are the usual consumer. When the cache-safe data layer is enabled, the cart arrives in its own gtm4wp.cartData event instead, which needs a Custom Event trigger in your container. The trigger guide covers that.
Customer data in data layer
Default: off.
Adds the account details of a logged-in customer to the data layer on every page: name, billing and shipping address, email address with its SHA256 hash, and the total number of orders with the total amount spent.
This is also the option that attaches the ready-made user_data object to the purchase event, which is what Enhanced Conversions for Google Ads reads. That object is built from the order rather than from a customer account, so guest checkouts are covered as well. The label of the option does not suggest this, and it is the most common reason Enhanced Conversions sends nothing while reporting no error. The Enhanced Conversions guide uses it.
Order data in data layer
Default: off.
Adds the full orderData object to the order received page: the order attributes, every total, and the billing and shipping details, with SHA256 hashes for the email address, phone number and names.
It works independently of whether the purchase ecommerce event itself is tracked, but it still needs Track e-commerce to be on. Every variable prefixed with “Order Data -” in the container template reads this object, which the Google Ads conversion guide relies on for the discount and shipping fields.
Purchase tracking
Order statuses that trigger the purchase event (beta)
Default: Processing, On hold, Completed.
The purchase event is sent when an order first reaches one of these statuses, which is at order placement rather than when the money physically clears. That is why a Cash on Delivery order (Processing) and a bank transfer order (On hold) are both counted at checkout even though payment arrives later.
Leave Failed, Cancelled and Pending payment unchecked so that unpaid orders are not reported as sales. Developers can change the same list with the gtm4wp_purchase_trackable_statuses filter, documented on the actions and filters page.
Only track orders younger than (experimental)
Default: 30 minutes.
The maximum age of an order, or of its payment, for the purchase event to fire on the order received page. Opening the confirmation page of an older order is treated as a revisit to a purchase already measured in an earlier session, and it is skipped.
Raise it if your customers reach the confirmation page well after ordering, which happens with payment methods that redirect back slowly. If purchases are missing and the orders are old by the time the customer returns, this is the first setting to check.
Exclude tax from revenue
Default: off.
Reports revenue without tax, so the purchase value becomes the order total minus the total tax. The item prices switch to their values excluding tax at the same time, so item level revenue still reconciles with the transaction total. While the option is off, the item price follows the price display setting of your shop.
Exclude shipping from revenue
Default: off.
Subtracts the shipping cost from the reported revenue. The shipping figure itself is still sent with the purchase event, so you keep it for reporting and it is only removed from the revenue total.
Transaction ID prefix
Default: empty, which sends the WooCommerce order number unchanged.
Puts a fixed text in front of the transaction_id of the purchase event, for example to tell several shops apart inside one GA4 property, or to match the order numbering of another system.
Only the purchase event changes. The order number inside orderData and the duplicate tracking guards of the plugin keep using the raw order number, so a prefix cannot cause an order to be counted twice. Set it before you go live if you can, because your reports will otherwise hold two different identifier formats either side of the change.
Do not flag orders as being tracked
Default: off, which is the safe setting.
Leaving this off is what stops an order being counted more than once. The plugin marks each order it has tracked, so reloading the confirmation page does not send a second purchase event to your ad and measurement systems.
Turning it on removes that protection. It only makes sense when something else in your setup owns the deduplication. Turn it on only if you really need it.
Reliable purchase tracking (experimental)
Default: off.
Turn this on when some purchases are missing. If the customer lands on a heavily customized thank-you page, or on the order-pay page instead of the order received page, the purchase event is sent on the next page they view in the same browser session. The tracked flag and the browser cookie still prevent double counting.
It cannot recover an order where the buyer pays through an asynchronous gateway and never returns to your site. That case needs server side tracking.
Custom order received (thank-you) page (beta)
Default: the standard WooCommerce order received page.
Names the page that shows the order confirmation when your theme or another plugin replaces the standard WooCommerce order received endpoint, so that the purchase event fires there. The order is resolved from the current browser session.
Advanced
Clear ecommerce object before new event
Default: off.
Pushes an empty ecommerce object before each new ecommerce event. Google recommends this, but it is not required here, because the GA4 event tag reads only the ecommerce data pushed most recently. Use it if you run into problems with your Google Tag Manager setup, such as values from an earlier event appearing in a later one.
Set maximum timeout for select_item event
Default: 2000 milliseconds.
When a visitor clicks a product in a list, the browser waits for Google Tag Manager to report that the select_item tags have fired before it follows the link. This value is the longest it will wait, and it only comes into play when a tag fails to report back.
Set it to 0 to open the product immediately. The select_item event is still pushed to the data layer, but the click is no longer held back. Use 0, or a value below 2000, if product links feel slow to open. That usually happens when a consent tool blocks Google Tag Manager, so the callback never returns and every click waits out the full timeout.
CheckoutWC compatibility (experimental)
Default: off.
Turn this on if your store uses CheckoutWC, which replaces the standard WooCommerce checkout with its own multi-step template. The classic checkout markers the tracker relies on are not reliably present there, so the add_shipping_info and add_payment_info events are missed. With this option on, the tracker also binds those events to the cfw_step_changed event that CheckoutWC emits.
Checking what an option actually did
Most of these options change what appears in the data layer, and nothing warns you when the result is empty. Open Google Tag Manager preview mode on the page where you expect the data, for example an order received page for anything under Purchase tracking, and read the data layer for the event in question.
If a whole group of values is missing, check Track e-commerce before anything else. It gates every other option on this page.
