What Does 1,000 Success Events Really Mean?

In the last year, Adobe Analytics introduced the ability to have over 1,000 Success Events. That was a pretty big jump from 100 previously. As I work with clients I see some who struggle with what having this many Success Events really means. Does it mean you can now track more stuff? At a more granular level? Should you track more? Etc… Therefore, in this post, I am going to share some of my thoughts and opinions on what having 1,000 Success Events means and doesn’t mean for your Adobe Analytics implementation.

Knee Jerk Reaction

For most companies, I am seeing what I call a “knee jerk reaction” when it comes to all of the new Success Events. This reaction is to immediately track more things. But as my partner Tim Wilson blogged about, more is not necessarily better. Just because you can track something, doesn’t mean you should. But let’s take a step back and consider why Adobe enabled more Success Events. While I cannot be 100% certain, since I am not an Adobe Analytics Product Manager, it is my hunch that the additional Success Events were added for the following reasons:

1. It is easier to increase Success Events than other variables (like eVars) due to the processing that happens behind the scenes
2. Success Events are key to Data Connector integrations and more clients are connecting more non web-analytics data into the Adobe Marketing Cloud
3. Some of the Adobe product-to-product integrations use additional Success Events
4. Having more Success Events allows you to push more metrics into the Adobe Marketing Cloud

I don’t think that Adobe was saying to itself, “our clients can now only track 100 metrics related to their websites/apps and they need to be able to track up to 1,000.”

This gets to my first big point related to the 1,000 Success Events. I don’t think that companies should track additional things in Adobe Analytics just because they have more Success Events. If the data you want to collect, has business benefit, then you should track it, but if you ever say to yourself, “we have 1,0000 Success Events, so why not use them?” there is a good chance you are going down a bad path. For example, if you have thirty links on a page and you want to know how often each link gets clicked, I would not advocate assigning a Success Event to each of the thirty links. If you wouldn’t do it when you had 100 Success Events, I would not suggest doing it just because you have more.

But there will be legitimate reasons to use these new Success Events. If your organization is doing many Data Connector integrations, the amount of Success Events required can grow rapidly. If you have a global organization with 300 different sites and each wants to have a set of Success Events that they can use for their own purposes, you may decide to allocate a set of Success Events to each site (though you can also double-up on Success Events and not send those to the Global report suite as well). In general, my advice is to not have a “knee jerk reaction” and change your implementation approach just because you have more Success Events.

Use Multiple Success Events vs. an eVar

Another thing that I have seen with my clients is the idea of replacing or augmenting eVars with multiple versions of Success Events. This is a bit complex, so let me try and illustrate this with an example. Imagine that one of your website KPI’s is Orders and that your stakeholder wants to see Orders by Product Category. In the past, you would set an Order (using the Purchase Event) and then use an eVar to break those Orders down by Product Category. But with 1,000 Success Events, it is theoretically possible for you to set a different Success Event for each Product Category. In this example, that would mean setting the Orders metric and at the same time setting a new custom Success Event named Electronics Orders (or Apparel Orders depending upon what is purchased). The latter would be a trend of all Electronics Orders and would not require using an eVar to generate a trend by Product Category. If you have fifty Product Categories, you could use fifty of your 1,000 Success Events to see fifty trends.

This raises the question, is doing what I just described a good thing or a bad thing? I am sure many different people will have different opinions on that. Here are the pros and cons of this approach from my point of view:

Pros

1. While I would not recommend removing the Product Category eVar, in theory, you could get rid of it since you have its core value represented in fifty separate Success Events. This could help companies that are running out of eVars, but still not something I would advocate because you can lose the great attribution benefits of eVars (especially across multiple visits).
2. Today, it is only possible to view one metric in a trended report, so if you want to see more than just Orders for a specific Product Category (say Orders, Revenue and Units for Electronics), you can’t do so using an eVar report. But if each of these metrics were tied to a separate Product Category event, you could use the Key Metrics report to get up to five metrics trended for a particular Product Category. But keep in mind that you would need fifty Success Events for each metric you want to see together, which can make this a bit un-scalable. Also keep in mind that you can trend as many metrics as you want using the Adobe ReportBuilder tool.
3. You can create some cool Calculated Metrics if you have all of these additional Success Events, such as Electronics Orders divided by (Electronics Orders + Apparel Orders) that may be more difficult to produce in Adobe Analytics proper without using Derived Metrics or Adobe ReportBuilder.
4. Having additional metrics allows you to have Participation enabled on each, which can provide more granular Participation analysis. For example, if you enable Participation on the Orders event, you can see which pages lead to Orders. But if you enable Participation on a new Electronics Orders event, you will be able to see which pages lead to orders of Electronics products. The latter is something that isn’t possible (easily) without having a separate Electronics Orders Success Event.
5. If you want to pass Adobe Analytics data to another back-end system using a Data Feed, there could be some advantage to having a different metric (in this example for each Product Category) vs. one metric and an eVar in terms of mapping data to an external database.

Cons

1. Setting so many Success Events can be a nightmare for your developers and a pain to maintain in the Administration Console. It may require extra time, logic, TMS data mappings and so on. In the preceding example, developers may have to write additional code to check for fifty product categories. In some cases, developers may only know the Product ID and not the category (which they had planned on being a SAINT Classification), but setting the additional Success Events forces them to write more code to get the product category. If visitors purchase products from multiple product categories, developers have to start defining rules that makes things more complex than originally anticipated. And if product categories change (new ones are added or old ones are removed), that can mean more development work vs. simply passing in different values to an eVar. While using a Tag Management System can make some of this easier, it still creates a lot more work for developers, who are normally already stretched to their limits!
2. Having different versions of the same Success Events can be confusing to your end-users (i.e. Orders vs. Electronics Orders) and can make your entire implementation a bit more confusing
3. Employing this approach too often can force you to eventually run out of Success Events, even with the increased number available. For example, if you set Orders, Revenue, Units and Cart Additions for each Product Category, you are already looking at 200 Success Events. Setting these same events for a different dimension (eVar), would require another 200 Success Events!

While I can see some merits in the benefits listed above, my opinion is that blowing out different Success Events instead of using an eVar is something that can have value in some targeted situations, but is not for everyone. Call me old fashioned, but I like having a finite number of metrics and dimensions (eVars) that break them down. If there is a short list of metrics that are super critical to be seen together in the Key Metrics report and the number of times they would have to be duplicated by dimension is relatively small, then perhaps I would consider adding an extra 10-20 Success Events for each dimension value. But I see this as a bit of a slippery slope and wouldn’t advocate going crazy with this concept. Perhaps my opinion will change in the future, but for now, this is where I land on the subject.

Derived Metrics

Tangentially related to this topic is the concept of Derived Metrics. Derived Metrics are the new version of Calculated Metrics in which you can add advanced formulas, functions and segments. The reason I bring these up is that Derived Metrics can be used to create multiple versions of metrics by segmenting on eVar or sProp values. For example, instead of creating fifty versions of the Orders metric as described above, you could have one Orders metric and then create fifty “Derived” metrics that use the Orders metric in combination with a segment based upon a Product Category eVar. This requires no extra development effort and can be done by any Adobe Analytics user. The end result would be similar to having fifty separate Success Events as each can be trended and up to five can be added to the Key Metrics report. The downsides of this approach is that these Derived Metrics will not be easily fed into a data feed if you want to send data directly to an external database and won’t have Participation metrics associated with them.

It is somewhat ironic that shortly after Adobe provided 1,000 Success Events, it also provided a great Derived Metrics tool that actually reduces the need for Success Events if used strategically with Segments! My advice would be to start with using the Derived Metrics and if you later find that you have reasons to need a native stream of data for each version of the event (i.e. Data Feed) or Participation, then you can hit up your developers and consider creating separate events.

Final Thoughts

So there you have some of my thoughts around the usage of 1,000 Success Events. While I think there can be some great use cases for taking advantage of this new functionality, I caution you to not let it change your approach to tracking what is valuable to your stakeholders. I am all for Adobe adding more variables (I wish the additional eVars didn’t cost more $$$!), but remember that everything should be driven by business requirements (to learn more about this check out my Adobe white paper: http://apps.enterprise.adobe.com/go/701a0000002IvLHAA0).

If you have a different opinion or approach, please leave a comment here.  Thanks!