Implementing the Products Variable with Events in Adobe Analytics

If there is one variable in Adobe Analytics that punishes carelessness, it is s.products. Most variables hold a simple string, but products are different, because a single event like a purchase can involve several products at once, each with its own quantity, price, and attributes. To pack all of that into one variable, s.products uses a structured, delimiter-based format, and the catch is that any syntax error silently drops the entire product string. There is no warning, no error, just missing data. This article covers the exact format, how s.products pairs with events, and the two advanced features, product-level events and merchandising eVars, that make it powerful.

The Six-Field Syntax

Each product entry holds up to six fields separated by semicolons, in a fixed order: category, product name, quantity, total price, an incrementor for product-level events, and a merchandising eVar. When an order contains more than one product, the entries themselves are separated by commas.

// Single product on a purchase
s.products = "Women;Fur Trim Ski Jacket;1;129.99";
// Multiple products in one hit, separated by a comma
s.products = "Women;Fur Trim Ski Jacket;1;129.99,Men;Alpine Parka;2;299.98";
// Product view, with quantity and price omitted
s.products = "Women;Fur Trim Ski Jacket";
// Cart add, typically with quantity but no price
s.products = "Women;Fur Trim Ski Jacket;1";

The amount of detail you populate depends on the moment. A product detail view needs only the category and name, since nothing has been bought or added yet. A cart add usually carries the quantity too. A purchase carries quantity and total price so revenue can be recorded. The fields you fill follow the stage of the journey.

How the Fields Work

The six positions each have a defined role. The first, category, maps to the category dimension in the Products report and is optional. The second, product name, is required for any product-level reporting at all. The third and fourth, quantity and total price, are required on a purchase. The fifth, the incrementor, fires a product-level custom event, and the sixth holds a merchandising eVar scoped to the product rather than the visit.

The single most important rule is that the fields are positional. If you skip a field in the middle, you must leave it empty by keeping its semicolon, never by removing it.

// Correct: the price field is empty but its semicolon is preserved
s.products = "Women;Fur Trim Ski Jacket;1;;event5=10.00";
// Wrong: a missing semicolon shifts everything left
s.products = "Women;Fur Trim Ski Jacket;1;event5=10.00";

In the correct version, the empty fourth field tells Adobe there is no price, and event5=10.00 correctly lands in the fifth position. In the wrong version, with one fewer semicolon, event5=10.00 collapses into the price field, and the data is corrupted. Every missing semicolon shifts all the fields after it one place to the left, which is exactly how a small typo silently ruins a product hit.

Products and Events Travel as a Pair

A crucial point that catches beginners: setting s.products alone fires nothing. The event itself must also appear in s.events, and the two variables only work together.

// Product detail view
s.products = "Women;Fur Trim Ski Jacket";
s.events   = "prodView";
// Add to cart
s.products = "Women;Fur Trim Ski Jacket;1;129.99";
s.events   = "scAdd";
// Purchase
s.products   = "Women;Fur Trim Ski Jacket;1;129.99";
s.events     = "purchase";
s.purchaseID = "ORD-2024-98765";

The s.products value sets the product context, the s.events value fires the metric, and on a purchase the s.purchaseIDdeduplicates the hit so a page refresh or back-button press cannot count the order twice. When several products are involved, the comma inside s.products separates the line items while a single purchase event covers them all.

Product-Level Events in Field Five

The fifth field lets you fire a custom event with a value scoped to one specific product rather than to the whole hit. This is how you track per-item things like product-level discounts, shipping costs, or loyalty points.

s.products = "Women;Fur Trim Ski Jacket;1;129.99;event7=15.00,Men;Alpine Parka;2;299.98;event7=0.00";
s.events   = "purchase,event7";

Here event7 carries fifteen for the ski jacket and zero for the parka, and because the values sit in each product’s fifth field, they attribute to the correct item and still roll up correctly at the hit level. The rule that trips people up is that any event used in field five must also be declared in s.events. If event7 is not listed there, Adobe silently ignores the field-five value entirely.

Merchandising eVars in Field Six

A standard eVar persists at the visit level and attributes to whatever product is purchased later in the visit. A merchandising eVar is different: it binds to a specific product at the moment it is set, and it travels with that product regardless of what else ends up in the cart. There are two ways to bind one.

The first is product syntax, set directly in field six.

s.products = "Women;Fur Trim Ski Jacket;1;129.99;;eVar3=Outerwear";
s.events   = "prodView";

The two empty fields before it leave quantity-adjacent positions blank so that eVar3=Outerwear lands cleanly in the sixth position, bound to this product alone. The second is conversion variable syntax, where you set the eVar normally in the same hit.

s.products = "Women;Fur Trim Ski Jacket;1;129.99";
s.eVar3    = "Outerwear";
s.events   = "prodView";

The choice between them comes down to whether the value differs by product. Use field-six product syntax when different products in the same hit need different eVar values, and use the s.eVarN conversion syntax when one value applies to every product in the hit. Mixing them up is a common error, because setting the eVar at the hit level when products need different values applies the same value to all of them.

Which Predefined Events Need Products

Most of Adobe’s commerce events expect an accompanying s.products value. The product detail view (prodView), cart view (scView), cart add (scAdd), cart remove (scRemove), checkout (scCheckout), and purchase all require it, because each refers to a specific product or set of products. The one exception is scOpen, which marks the beginning of a cart session before any product has been chosen, so it fires on its own with no product string.

A Complete Purchase Hit

Pulling it together, an order confirmation page looks like this.

s.pageName   = "Purchase:Order Confirmation";
s.channel    = "Purchase";
s.events     = "purchase";
s.purchaseID = "ORD-2024-98765";
s.products   = "Women;Fur Trim Ski Jacket;1;129.99,Men;Alpine Parka;2;299.98";

The page name and channel handle reporting context, the purchase event triggers revenue collection, the purchase ID guards against double counting on reload, and the two comma-separated line items record one ski jacket at 129.99 and two parkas totalling 299.98. One detail worth stressing: you never set revenue separately. Adobe sums the price fields across every line item and records the total as the Order Revenue metric automatically, which is also why field four must be the line-item total rather than the unit price.

Building the String in Your Head

A reliable way to construct a products string is to walk the fields in order for each product. Category is optional and used only if you track categories. Product name is always required. Quantity and total price are required for purchase and cart events, with the price being the line total rather than the per-unit cost. The fifth field appears only when you need a product-level custom event value, and the sixth only when you use a merchandising eVar. Separate the fields with semicolons, separate the products with commas, and never drop a semicolon for an empty middle field.

The Pitfalls That Corrupt Product Data

Six mistakes account for nearly all broken product tracking. Dropping a semicolon for an empty field shifts every later field one position left, so an empty price before a field-five event needs a double semicolon, not a single one. Putting the unit price in field four instead of the line total understates revenue, since two items at 149.99 require 299.98 in field four, not 149.99. Forgetting to declare a field-five event in s.events makes Adobe ignore that product-level value silently. Setting s.products with no matching event populates the Products report dimension but fires no metric, so the products appear with zero counts. Reusing a non-unique purchase ID, such as always sending “1”, makes Adobe deduplicate genuinely different orders into a single purchase, so always pull the real order ID from the data layer. And mixing the two merchandising eVar syntaxes incorrectly applies one value across products that needed different ones.

Conclusion

The products variable is the most syntactically demanding part of an Adobe Analytics implementation, and the discipline it requires is precision about position. Pack each product into up to six semicolon-separated fields, category, name, quantity, total price, a product-level event, and a merchandising eVar, and separate multiple products with commas. Never remove a semicolon for an empty middle field, because positions are everything. Remember that s.products fires nothing on its own and must be paired with a matching value in s.events, that field-five events must also be declared there, and that revenue is summed automatically from the price fields rather than set by hand. Get the syntax exactly right and Adobe builds your entire ecommerce funnel from it; get one semicolon wrong and the whole string vanishes without a trace.