Adobe Analytics : Product Syntax – a complete guide

This article will be nothing fancy but more or less a document to gather the information about the Product syntax for Adobe Analytics.
Why that ? Because Adobe documentation about products tracking about it is quite scattered and I find it not even complete.

Anyway, instead of looking always here and there for the information, I decided to create my own documentation article. Maybe I will be mentioned by Adobe one day 😉

The Product Variable

Let’s start with the basic, what is the product variable. Is it a prop or an eVar ?
It is neither… it the product variable and it comes with different consideration for tracking your product.

The product syntax has several different characteristics that you would need to consider when implementing it:

• It lasts a Hit
  If you want to track a product during a funnel, you need to send it to Adobe Analytics for each of your calls.
• It is composed of different elements.
  We will see each one of them later but it is not retrieving one variable or information. It can do much more than that.
• It doesn’t have any limitation
  The product variable on itself, the complete product variable, don’t have any limitation in length. So you can have multiple products tracked at the same time within the product variable.
• You don’t track Product Name but Product ID
  Due to some limitation, it is best practice to track Product ID and not Product Name within the product variable. You can then apply classification on it.
• the prodView event is automatically attached to it
  If you don’t set any other product event, then the prodView event is considered for the tracking of your product variable.
• Amount of product and total value are only retrieved when you are using the “purchase” event.

List props are the closest variables from the products variable. It really feels like the s.products is an advanced list prop variable at some point, with some classification (numerical or not) automatically attached to it.

Actually I would recommend you set another listprop at the same time than the purchase in order to do cross-product comparison. We will see that a bit later.

Basic Product Syntax

So here we will see how you should write the s.products variable :

So here goes the explanation:

• Category: the product category associated with the product id. It has been suggested for a long time to not used this one but do a merchandising eVar instead.
  The problem was that product may be in 2 categories and that was not handle by this dimension.
  This is supposed to be fixed but I would still recommend to use Merchandising Evars, which I find clearer and more flexible.
  
• Product ID: You product id 😉
  
• AmountOfProduct : So here it is an integer that needs to be pass. It represents how many values it
  
• TotalValue : This is a float that you can pass (with 2 digit after the dot). So it will be something like this : “10.24”
  It represents the total amount, not the price of one product.
  Some people struggle if they should add the VAT or not, the shipping cost and so on…
  My recommendation : No. Use the Merchandising events for that.
  
• Merchandising Events : A way to add specific events to your Product Variable event. We will see that in detail below.
  
• Merchandising Evars : You can add dimension to your Product Variable event, and assign conversion to it. Explain in detail below.

In case you would like to track multiple products at once, it is possible. They just need to be separated with a comma.

I found that the Merchandising elements or dimensions are one of the most powerful features of Adobe Analytics. It is quite restricted to product usage but for that purpose it gives you quite an unique way to measure and track information related to product.
It can actually be a game changer for many organization.

Merchandising events

The merchandising events are a way to attach a specific event to a product variable, at the time of that event.
You can add a numerous amount of event and really customize the calculation of the product dimension.
You will see later on that the product variable is attached by default to some events, but why stick to those? You can create all sort of events attached to your product.
Do you want to count the number of times a product is seen within a particular context? Be my guest and create this specific event that is attached the product variable.

From my point of view they are 3 main cases that you want to cover with the merchandising events:

• Sum the value adding to cart.
  The value of the cart is not retrieved by default by Adobe. What you can do is attach an event to the cart addition event that increment the amount added to cart.
  You can then compare it to the revenue and see the gap that you are missing.
  You will also be able to create a metrics that will tell you the difference between value added to cart and revenue for specific products.
  Showing that to your Head of Onsite optimization or Digital Strategy is usually a game changer on how to approach onsite tracking.
  
• Sum the value removed from the cart
  There is an event that is often overlook and that is the cart removal event. The same way you track the value added to cart, you can track the value remove from cart. Identify which product is losing the most value later on.
  
• Amount of product added to cart
  It seems strange but Adobe doesn’t support natively the amount of product added to the cart and sometime it may be interesting to know it for your website optimization.
  You will be able to identify when to create a bundle from this kind of information.
  
• Shipping cost and Tax
  On the final page, you will be able to retrieve the tax (if your refer to your prices as net) or the shipping cost that are due by the customer.
  You can then check if the % of shipping cost relative to the total amount paid is having an impact.
  
• Specific order type
  You can also use the event as counter to count the number of order or cart addition done with a specific context. (containing a bundle, or a promo code).
  I would rather choose to do that with Merchandising eVar but having an event can make sense as well.

When you implement the events, you will need to respect this methodology:

• The events needs to be declared in your “s.events” variable
  Lots of people forget about that.
  
• You can stack multiple events with the pipe character : “|”

At the end, with the merchandising events, your products variable could look like that:

Merchandising eVars

The merchandising eVars are quite complex to set because you have different way to implement them.
You can set them as normal eVar syntax or in the product syntax.
It has quite an importance because the merchandising eVar are considered in a very specific way.

Merchandising eVar are assign to a customer and to a specific product id of this customer.
It means that you can set multiple value for different product for a single customer.
As long as it is always different products, they will not overwrite each other.
It is quite different than with normal eVars as you mostly overwrite one value with another in the report.
They last until you decide to, as you can set their expiration like any of the eVar. I would recommend to use Purchase as expiration event. So you bind that product to that user until purchase.

There is a binding event that you need to set if you select the “conversion variable syntax”. It will set an instance for each of the event you select, if you actually set the eVar at that time (Possible events listed below).

At the end, the 2 ways to set the Merchandising eVar are:

I would recommend to use the first one because it is more granular and you can set different values for different product.
In case you are tracking a Category Page, you may have different product with different information for each of them.

It won’t be possible to track different values through the normal conversion variable setup.

The same way that the merchandising eVents, the merchandising eVars can be stack with the pipe operator.

I have some use-cases that you can have for implementing the merchandising eVars:

• price as string:
  If you track the price as string, for product view and for cart additions you actually could start calculating the elasticity price for your product.
  At which point your product start getting a better performance (cart addition / view).
  
• Product category
  This is a given but you can have more than one product category assigned to one product.
  
• Campaign ID at the time of the cart Addition
  This one I really like, you often have attribution about visits and orders.
  But I feel that we are underestimating the the cart addition events. I already did a post about that. But by tracking the campaign that has been responsible to your cart addition you better track the campaign that add value to your site. Not the one converting (which can be different).
  
• The category of your site where cart addition or product view happens.
  You can clearly see where customers are the most interacting with your product by setting the path or the page name associated with one product.
  As a product could be on multiple page, having this view per product or product category can help your shop optimize the placement.

Merchandising as conversion variable

I explained that the product syntax should be your most preferred way to implement a product merchandising eVar.
However it is still interested to use the conversion variable, especially if you want something to be attached to the whole cart and not to a specific product; like a coupon or a special delivery tax for heavy package.

You can always use it but in my opinion it shouldn’t be the default choice because the product syntax gives you much more flexibility.

Annex to the products variable

The products events

When you set the s.products, you need to understand that a product event needs to be set at the same time. By default the product is attached to a prodView event.
Those are called the predefined adobe events. Documentation

The different possible events and their meanings are:

• prodView : Default event, when a product is view and tracked.
• scView : Success event occurs any time a shopping cart is viewed.
• scOpen : Success event occurs any time a visitor opens a shopping cart for the first time. It is quite tough to set in a proper way. Be careful on the implementation.
• scAdd : Success event occurs any time a product is added to a shopping cart.
• scRemove : Success event occurs any time an item is taken out of a shopping cart.
• scCheckout : Success event occurs on the first page of a checkout.
• purchase : Success event occurs on the final page of a checkout (includes Revenue, Orders, and Units).

The transactionID

A very interesting setup that is native in Adobe Analytics is that it can automatically deduplicate the order. It would avoid the problem of re counting the purchase event twice if people refresh the page.
You can set the transaction id by doing the following:

In order to realize that, you would need to set the transactionID variable with your order id. This alphanumerical number needs to be unique per order.

A less common feature is that it can be used to import additional data into Adobe Analytics. The good thing is that it doesn’t create new visits for your visitors, which is actually pretty neat.
Be careful however, the import is limited to the transaction id of the last 90 days.
I think it is possible to increase that period if you ask Adobe Customer Care.
Documentation about that process : https://docs.adobe.com/help/en/analytics/import/data-sources/data-types-and-categories/datasrc-transactionid.html

A good point, bring from @jonathankfs (twitter) is that order id is an identification information on a visitor level. You want to check how you can apply data enrichment on that because it can be restricted based on the visitor Privacy Consent status.

Bonus : ListProp

A way to trick or by pass Adobe Analytics limitation for cross product analysis is by setting a prop as a list and copy the list of product that the user is having on his purchase page.

Adobe Analytics Workspace doesn’t have this capacity of doing the cross-product analysis.
You usually cannot see which product were bought together with another product that easily.
A report exist(ed) in Reports & Analytics and it was not transposed in Workspace unfortunately.
So the way to go around it is to realize this set up.
You can then classify the product id in your list prop the same way that you do it with your product id.

When you realize the breakdown of one product with the listprop, you need to understand that you will obviously have the same product id in the first row.
Because it is a copy, it is normal to see that the product ID X is in the list prop as well at the time of the purchase.
Ignore that first row and this should be fine.

I hope that article was helpful to understand how to use the product variable within Adobe Analytics. I tried to give you some hint to track your product variable and give you more insights in your Adobe Analytics tool.
Do you think I miss anything ?
Feel free to comment below !