Commonly Misunderstood and Underused Features of Adobe Analytics
When you purchase a tool such as Adobe Analytics, you’re making an investment in a data-driven digital marketing ecosystem with the potential for significant returns. You’ve heard the sales pitch; you’ve read the case studies; you’re eager to increase the value of your digital presence. However, simply buying the tool and turning the lights on won’t deliver the results you’re looking for. This is a robust, complex, and highly customizable tool that demands finesse and expertise. If your team doesn’t fully understand the tool or take advantage of its most powerful features, you’re leaving a lot of value on the table.
In this post, we’ll review some of the most valuable features of Adobe Analytics that clients often misunderstand, ignore, or fail to configure properly: Merchandising Variables, Event Serialization, and Segments. Misuse of these features often results in business decisions being made on bad or incomplete data.
One of the most complex features of Adobe Analytics is merchandising variables. Adobe Analytics can collect data in a multitude of ways, which can be used to address a wide variety of business requirements. Merchandising variables are simply one of a number of different variable types. Often, the technical details and specific tagging conditions can frustrate developers during Adobe Analytics implementation, not to mention eluding or confusing business stakeholders. So why do these variables matter, and what are people commonly doing wrong with them?
Merchandising variables allow you to see deeper into how your products and product categories are performing, beyond simply the final revenue numbers. Click & Tweet!
Merchandising variables provide ways for you to allocate revenue beyond purchased products to product-finding methods, product attributes, product ratings, child/parent stock-keeping units (SKUs), whether a product was a cross-sell or upsell, or a number of other product-specific data points that you simply cannot track with normal variables. They’re similar to product-scoped variables in Google Analytics (but much more powerful): they allow you to pass values that are tied to a specific product, without being overwritten by data for a different product. Merchandising variables allow you to see deeper into how your products and product categories are performing, beyond simply the final revenue numbers. This can help answer questions like:
- How are visitors finding the products on our site with the highest margins?
- Are we getting value from our recommendations tool that promotes similar products to visitors?
- Which products have had the most revenue lost due to discounts?
Now that we’ve outlined the value that merchandising variables can provide, let’s review some common points of confusion.
Confusing Conversion and Product Syntax
There are two types of Merchandising eVars: Product Syntax and Conversion Syntax. They both ultimately have the same purpose — attributing a value to a specific product and its revenue — but they’re set differently and address different tagging requirements.
Product syntax is the standard approach, which requires you to set the eVar within the product string. It works by “binding” an eVar value to a specific product ID, and has a predetermined list of standard ecommerce events where binding can occur, such as prodView, cartAdd, and purchase. This is the easier method to understand, but it requires developers to set the value only when these specific ecommerce events occur. It’s generally used for discounts, product attributes, or other product-specific data that are available in the same hit as the product they’re bound to. It must be set at the end of the product string, after all of the other required components:
Conversion Variable Syntax
Conversion Variable Syntax allows you to set the value outside of the product string, as you would with any other eVar. This is commonly done when the attributes you want to bind are not necessarily available in the same hit as the product you want to bind them to. Product Finding Method and Internal Search Term are great examples — you may not have that browsing data available on the Product Detail Page (PDP), but you still want to understand how the user discovered that product.
Let’s take a closer look at the internal search example, where eVar12 is capturing the internal search term:
In this case, you ‘d set the search term as a “normal” eVar outside the product string when the search occurs, and configure it to bind on the prodView event. When the user eventually lands on a PDP, the last search term they entered will be bound to that product. If they make additional searches to find other products, each product will be bound to the search term that discovered it, and that credit will persist through to the purchase.
While this level of customization can be very powerful when implemented correctly, the complexity can be quite a deterrent. Analysts and developers are often confused by the differences between these variable types and the circumstances that merit their use. However, in order to fully realize the benefits of this powerful tool, you’ll need to take full advantage of its features. Once merchandising eVars are implemented correctly, particularly on ecommerce websites, the analysis potential can be a game changer.
Setting Merchandising Events Properly
Merchandising events, like their categorical eVar cousins, are designed to increment metrics that are specific to a given product ID. Product-specific data can take on many forms, and merchandising events are designed to capture associated numeric or currency values, but come with similarly strict implementation requirements.
Merchandising events require you to set the event value with the product string AND in the s.events variable. For instance, if you plan to track a $2.01 discount on a $12.00 product (sku123 in the example below), then you’ll need to update BOTH locations:
It’s common to forget to update the s.events variable when you already added it to the s.products variable. If you forget this step, the purchase will still be tracked, but the event won’t increment with data.
Warning: Merchandising Variables and Adobe Audience Manager (AAM)
One major pitfall to using Merchandising variables in your Adobe Analytics implementation is the lack of support for them in Adobe Audience Manager. Merchandising variables rely on complex attribution logic and post-processing that happens within the Adobe Analytics servers after the data is ingested. Adobe Audience Manager — and many other 3rd party tools that integrate with analytics, for that matter — do not inherit that logic when data is passed to them from the client; even the Server-Side Forwarding (SSF) option sends pre-processed, hit-level data, which does not include merchandising attribution logic. Additional steps will need to be taken to ensure merchandising variable data is passed correctly to those systems. (Hint: we can help!)
One of the most common complaints we hear from clients during the data discovery process is “the data in analytics doesn’t match our back-end systems.” Whether it’s purchases, form submissions, or any other conversion event, we often encounter problems where the data in analytics is overcounting them. Fortunately there’s an Adobe Analytics feature that helps address this: event serialization.
Event serialization works by combining each instance of an event with a unique ID that is specific to the session, user, or transaction. Once the event is configured for serialization, Adobe will only record the event once for each unique ID. If the user triggers multiple events — say, by refreshing the confirmation page — Adobe will only count it once per ID, thereby eliminating issues with double-counting.
Event serialization must be configured in the admin console separately for each event you want to serialize. From there, it’s entirely up to you to determine which ID to pass alongside the event in the tag. This gives you considerable flexibility and control over how to increment events. For instance, some users may make multiple transactions in a single session; serializing checkout steps by a unique Cart ID will allow the logic to refresh if the user starts a new cart.
Setting events without serialization reports every time it is set:
Setting events with serialization allows this event to only be reported once:
If no ID is available, there’s an option to configure the event to “record once per visit.” While less precise, this approach may still be sufficient depending on the use case.
While small discrepancies are normal and expected in the chaotic world of the web, substantial differences can undermine trust in analytics data and in Adobe Analytics as a source of truth for reporting. Bringing your various systems into alignment is a huge step towards establishing a trustworthy foundation for a successful analytics program.
Segmentation is an incredibly powerful Adobe Analytics feature. Adobe offers a robust set of logical constraints and filters that allow for extremely precise control over how data is populated in reports. You may want to only see a set of reports for a certain subset of pages, a specific group of visitors who completed a form, or only the data from visits where a purchase occurred. Segments allow you to build powerful dashboards that curate exactly what stakeholders need to inform their decisions.
However, as a certain famous web “analyst” will tell you, with great power comes great responsibility. We frequently run into problems with end users misunderstanding what a segment is actually doing. With the level of customization that the tool providers, segments can quickly become brain teasers, especially when multiple nested logic statements are in play. For instance, you might intend to build a segment that contains data from “all visits when a visitor has made a purchase,” but you inadvertently end up with “visits where a purchase occurred.” While the resulting data may look similar, the underlying logic has vastly different implications for analysis.
So why do people get confused? Ultimately it’s because there’s no easy way to know if you built the segment correctly. Even the most experienced end users will occasionally run into head-scratchers when dealing with complex segmentation logic. The nuanced interactions of Hit vs. Visit vs. Visitor scoping, OR vs. AND vs. THEN operators, and Include vs. Exclude containers can be quite frustrating to comprehend.
Let’s build a segment from the beginning and walk through some of these gotchas:
Clicking the “Hit” dropdown allows you to select the scope of the container: Hit, Visit, or Visitor. These options are built on standard analytics concepts, which we won’t unpack here, but they have vastly different implications for how data is filtered.
Maybe you want a data set that only includes visits that started with a page that has a pagename containing “landing page”:
Or maybe you want data from all visitors who made a purchase:
Both of these can be completed fairly easily and require no new containers to be added. However, what if you want to see visits where a shopping cart addition occurred, but no purchase was made, and only by visitors who made a purchase in the past? This is what that segment might look like:
That got complicated pretty quickly! In this case, the “Include Visit” setting in the top-level container will apply to all logic to the containers within it, which affects how that data is filtered — and how it should be interpreted for analysis.
Proper Container Scope
It’s fairly common to break a segment on the first pass. It’s not easy to understand how the various containers interact, and a certain amount of trial and error is inevitable. However, it’s imperative that you understand the question or statement that you are answering, and how that question should manifest in the data you want to pull. This may seem obvious, but this is often where the biggest Adobe Analytics mistakes are made!
In the above example, we want the data set to include visits where a shopping cart addition occurred but no purchase was made by a visitor who has made purchases in the past. Let’s unpack this further:
- We want visits, where:
- the visit must have an add to cart
- it must not contain an order
- this visit must be by a visitor who has previously placed an order
- the visit must have an add to cart
If you can form the reporting requirement into a statement like this, it can be much easier to build your segment to match. Understanding which containers should be hit, visit, or visitor is often where the breakdown occurs for incorrectly built segments. You can view the data set numbers changing in the upper right to know if you are close to the numbers you are expecting. If the numbers look wildly off, then you’re likely making a mistake in your segment logic.
If you’re struggling to figure out why your segment isn’t working properly, it may be time to find another knowledgeable Adobe Analytics user to gut check the veracity of your approach. (Even the best analysts in the world have to do this sometimes.) Even when you think you’ve got it, always double- or triple-check your segment settings to make sure you didn’t overlook container levels, operators, or compared values. Little mistakes can make a huge difference here.
When you trust the accuracy of your data and understand how to properly build complex segments, it’s not uncommon to dive much deeper. You can gain considerable value from your data by better understanding how to use segments properly to form more precise and custom data queries.
Harness the Complex Features of Adobe Analytics
Adobe Analytics is notoriously inaccessible to inexperienced users. Without the right expertise, its complexity can certainly be a hindrance to building a successful analytics program at your organization. Fully realizing the value of Adobe Analytics’ capabilities requires expertise, collaboration across teams, and more than a little patience. Once its complex feature set is properly harnessed, it has the potential to deliver considerable value for data-driven decision makers. We’ve seen many clients turn their frustrations around and deliver huge wins and return on investment (ROI) with the right approach.
Don’t just turn the lights on and ignore the most powerful features of Adobe Analytics. With the necessary effort you can turn this behemoth of a tool into a powerful analytics solution that meets your business needs. What features do you see others misunderstand or misuse? Which features could you use assistance with to harness the power of Adobe Analytics? Let us know in the comments. We’d love to have a discussion with you.