Event serialisation

22 Nov 2020 » Analytics Tips

As I explained in my post on metrics and and dimensions in Adobe Analytics, events (or custom events) are the way to track metrics. In general, you want a metric to increase or decrease depending on the user’s behaviour. However, you may only want it to happen under certain circumstances. More importantly, you do not want to write complex code to manage that.

Use cases

Adobe Analytics cannot cater for all conditions of when to fire an event. Say, for example, that your website has 3 metrics:

  • Searches
  • Log-ins
  • Submit a form

In an ideal world, you would want to configure in Adobe Analytics the conditions to fire the events, without having to write a single line of code. This could be possible if the next page after any of the three cases above was always a specific URL. You could then write a simple processing rule that triggers an event if it it sees that URL. However, if you use AJAX calls or there is no pattern to identify these events, you have no other option than to add some code or rules in a tag manager.

On the other hand, there certain cases where Analytics can help you. Consider the following use cases regarding the metrics above:

  • Searches. You want to track every time a user performs a search, even she uses multiple times the same search term.
  • Log-ins. You only want to track one log-in per visit. So, if a user logs in, then logs out and later logs in again, you only want your report to show one log-in.
  • Submit a form. You run a survey platform and you are only interested in tracking when a user submits a survey for the first time. Any subsequent submissions of the same survey by the same user should not be tracked in Analytics.

For the latter 2 options, you could write code or use a database server-side to only set the events when you want. Or you could send always the event and use a simple Adobe Analytics feature, letting the tool take care of the duplicates. It is in the Report Suite Manager, in the Success Events configuration page, and it is called Unique Event Recording:

Always record event

This is the default case. Whenever you enable a new event in Adobe Analytics, it is set to always count. In other words, every time Adobe Analytics sees the event in the s.events string, it increases it by one. This is what you probably want in +90% of the cases.

Record once per visit

As its name implies, you only want to track a maximum of one event per visit. And, by visit, we mean the Adobe Analytics definition of it. With this setting, no matter how often you send the event, Adobe Analytics will only count it once during a visit. You need to start another visit to get the metric incremented again.

This feature removes the burden from the developer to track if an event has already been sent. Think about the following pseudo-code:

  • If conditions to send eventX happen
    • If cookie c does not exist
      • Send eventX
      • Set a cookie named c, with an expiration of 30 minutes from now
    • If cookie c exists
      • Do not send eventX
  • On every page view AND if cookie c exists
    • Update cookie 8c* expiration to 30 minutes from now

Now, compare it with just setting s.events="eventX" when the right conditions happen, regardless of whether you have already sent it. Then, configure Adobe Analytics to do the rest server-side. Which one do you prefer?

Use event ID

This is the most complex and least used option. The functionality works as follows: Adobe Analytics will only record the event if it has never seen the associated event ID before. All subsequent times Analytics sees that event ID, it will not increase the event counter. You send this event ID as shown here: s.events="event1:abc123" , where abc123 is the event ID. Obviously, you also need to configure the event in Adobe Analytics to expect this type of deduplication.

Let me explain it a bit further. Adobe Analytics keeps a table of event IDs for each event and report suite level. Therefore, in order for an event to count, its associated event ID has to be unique for that event and report suite. You can repeat the same event ID in different events and different report suites.

Some additional properties of this feature:

  • Event IDs never expire
  • Analytics keeps track of event IDs across all visitors. If two different visitors show the same event ID, only the first one will count. This is an important difference with the previous case, which is per visit, which, in turn, is limited to a visitor.
  • The event ID must be alphanumeric and with a maximum of 20 characters.
  • The event ID is applied per event, not at the s.events string level. For example, in s.events="event1:abc123,event2" , if abc123 has already been seen, event1 will not be counted, but event2 will.
  • If there is no event ID, it will always count.

More information in the official help section: event serialisation.

Special case: purchaseID

There is one special case: the purchase event. This event has its own event ID variable: s.purchaseID and it is always enabled. Check this example on how to use it:

s.events="purchase";
s.products=";sku1;1;2.50";
s.purchaseID="abc123";

If Adobe Analytics has already seen one particular s.purchaseID, not only it ignores the purchase event, but also the whole s.products string and all eVars and all events set on that page. This is very useful on the order confirmation page, which users sometimes refresh or bookmark. As long as the s.purchaseID is the same, no increase in orders, units, revenue, eVar or events will happen.

More information in the official help section: purchaseID.

Recommendations

While I cannot summarise all the use cases in the world for each of the deduplication methods, I can offer some tips.

Baskets

It is good practice to enable visit serialisation (record once per visit) in the scOpen. The idea is that this metric should count how many visits have resulted in a user adding something to the basket. If a user starts adding products to the basket, then clears the basket and starts again, you only want to count as one basket. If you count it more than once per visit, you may get the sensation that more people have started to add products to the basket that the actual number.

From a coding perspective, it as simple as setting s.events="scAdd,scOpen" every time a user adds a product to the basket. Adobe Analytics will take care of the scOpen serialisation.

Checkouts

Similarly to the previous case, I recommend to enable visit serialisation to the scCheckout event. You should use this metric to count the number of visits when a user starts the checkout process. Again, if a user starts the checkout process multiple times, because she has forgotten to add products to the basket, you only want to count the first time. Otherwise, you numbers will be inflated.

Duplicate serialised events

When you configure Adobe Analytics to serialise an event, you are actually losing information. Your reports will look fine, as I have explained in the two cases before, but you will not have the full picture. My recommendation is, for each event that is not always counted, to duplicate it in another event and configure it to always count it. You can do it in JavaScript, your tag manager or processing rules. You can then create a calculated metric, where you divide this new event by the serialised event, to get the relation between the two.

Using the previous examples, while I would not do it with the scOpen event, it makes sense to do it with scCheckout.

 

Photo by Ricardo Gomez Angel on Unsplash

Related Posts