Once Per Visit Success Events

Recently, while working with a new client, I noticed something that I have seen a few clients do related to Once per Visit Success Events. These clients set a bunch of Success Events with event serialization set to Once Per Visit as seen here in the Admin Console:

In these situations, the client tends to have the same Success Event unserialized in a different variable number. For example, they might have event10 set to Form Completions and then event61 set to Form Completions Once per Visit.

So why would a company do this? In most cases, the company wants to have a count of cases in which at least one instance of the event took place within the session. While there are some good reasons to use Once per Visit event serialization, in most cases, I feel that duplicating a large swath of your Success Events in order to have a Once per Visit version is unnecessary. Doing this adds more data points to your implementation, causing the need for more QA and potentially confusing your end-users. In this post, I will share an alternative method of accomplishing the same goal with less tagging and work in general.

Derived Metrics Alternative

As I have discussed in previous blog posts, it is easy to use the Calculated Metric builder to make brand new “derived” metrics in Adobe Analytics. In many cases, this is done by adding a segment to another metric in a way that makes it a subset of the metric. As such, derived metrics can be used instead of duplicating your Success Events and making a Once per Visit version for each. To illustrate this, I will use an example with my blog.

In this scenario, let’s imagine that I have a need to view a metric that shows how many website visits contained a blog post view. I already have a Success Event that fires whenever a blog post view occurs, so I can see how many blog post views occur each day, but that is not what is desired in this case. Instead, I want to see how many visits contained a blog post, so using the method described above, I could create a second Success Event that fires each time a blog post view occurs and serialize it as Once per Visit. This second Success Event would only count once regardless of how many blog post views take place in the session. If I compare this new Success Event to the raw Blog Post Success Event metric, I might see something like this:

Here you can see that the serialized version is less than the raw version, with the difference representing visitors who viewed multiple blog posts per visit.

But as mentioned earlier, this required creating a second Success Event which I don’t really want to do. I can get the same data without any additional tagging work by leveraging derived metrics in Adobe Analytics. In this example, I will start by building a segment that looks for visits in which a blog post view existed:

Next, I will add this new segment to a new Calculated Metric along with Visits as shown here:

Now I have a new derived metric that counts visits in which a blog post took place. If I add this new metric to the table shown above, I see the following:

As you can see, the new derived metric is exactly the same as the Oncer per Visit Success Event, but any user can create it with no technical tagging or additional QA needed! Sometimes, less is more! You can create as many of these derived metrics as you need and share them with your users as needed.

Caveats

There is one important thing to remember when considering whether to set additional Oncer per Visit Success Events or use derived metrics. Derived metrics are a form of Calculated Metrics and Calculated Metrics cannot be used everywhere within Adobe Analytics. For example, Calculated Metrics cannot be used in segments (i.e. Calculated Metric X is > 50), cohort analyses, histograms, DataWarehouse, etc. Therefore, it is important for you to think about how you will use the metrics before deciding whether to make them actual Success Events or derive them via Calculated Metrics. My advice is to begin with the derived metric approach and see if you run into any limitations and, only then, create new Once per Visit Success Events for metrics that need it.