While there is not much to the topic of Event Serialization, I have run into numerous clients who did not know that it existed so I thought that it would merit a brief mention here on the blog.  This short post will cover the main things you need to know about Event Serialization.

What is Event Serialization?
Event Serialization is the process of de-duplicating the firing of Success Events.  As you know, when a normal counter Success Event is set, SiteCatalyst increases the Success Event metric by one and associates the success with any values currently existing in Conversion Variables (eVars).  However, there are many cases in which a user’s action can trigger a Success Event multiple times (inadvertently or intentionally).  For example, a user may log into your website several times a day, making your “Logins” metric unrepresentative of unique Logins.  Alternatively, a visitor may hit the “back” button in their browser while in the conversion process triggering a second “Cart Add” event to be fired.  Most of the time, these duplicated Success Events are nominal, but as a web analyst, part of your responsibility is to safeguard the metrics you report so that you can trust them to make sound business decisions so there may be cases where you need to ensure this is not happening.  That is where Event Serialization comes into play.  Through Event Serialization, you can ensure that only the first instance of a Success Event will be counted in Success Event and Conversion Variable (eVar) reports.

How Does Event Serialization Work?
The implementation of Event Serialization is very simple.  Everything is the same as setting a normal Success Event except that you include a unique alphanumeric string after the Event Number in the syntax.  For example, instead of the normal syntax of

s.events=event12

You would add a “:” and a unique string (20 characters or less) so that your syntax looked like this:

s.events=event12:123456789

If SiteCatalyst sees any Success Events come through with the same event number and serialization string, it will ignore it.  For those of you who sell goods/services online, the concept is somewhat similar to the idea of Purchase ID, but in this case is meant for custom events.

Important Things To Know About Event Serialization
The following are some important things to know about Event Serialization:

  1. As mentioned above, the string must be alphanumeric and less than 21 characters
  2. Serialization strings persist forever so be careful when creating them to avoid excluding Success Events unintentionally
  3. You can also use Event Serialization with Incrementor Events

Real-World Example
In this example, a media subsidiary of Greco Inc. has a site that is heavily focused on video consumption.  For this site, they want to see how often logged-in visitors watch all of the various videos hosted on the site.  To do this, they set a series of video-related Success Events, such as “Video Starts” and “Video Completions” and use an eVar to track the “Video ID.”  While it wants to see a raw count of Video Starts and Completions, one of their business requirements is to see how many “unique” Video Starts and Video Completions take place such that the same logged-in visitor is not counted as seeing the same video more than once.  By doing this, Greco Inc. can compare the de-duplicated metrics to the raw metrics to see how often videos are being watched repeatedly.

To accomplish this, Greco Inc. creates four Success Events, two for raw data and two for de-duplicated data.  Since it knows the User ID of the logged in visitor, Greco Inc. decides that it can use that as part of the serialization string, but there is a problem.  If it uses the User ID to serialize the Success Events that would make it so any videos beyond the first one for that User ID would not be counted since the user would always have the same serialization string (their User ID).  This is where Event Serialization can get a bit tricky!  Instead, Greco Inc. would need to combine the User ID with a unique string for each video so that the combination of the User ID and Video ID would only be counted once!  Hence, if the current User ID is “123456789” and the first video they watch is Video ID “news119987,” the syntax might look something like this:

s.events=event13,event14:123456789-news119987

By doing this, if User ID “123456789” ever views Video ID “news119987″ again, it will be ignored by SiteCatalyst in “event14,” but will be counted again in “event13.”  The same would apply for the Video Completions events with one being set normally and the other being serialized using the same string shown above.

That is pretty much all you need to know about Event Serialization.  Let me know if you have any questions…

 

Have a question about anything related to Omniture SiteCatalyst?  Is there something on your website that you would like to report on, but don’t know how?  Do you have any tips or best practices you want to share?  If so, please leave a comment here or send me an e-mail at insidesitecatalyst@omniture.com and I will do my best to answer it right here on the blog so everyone can learn! (Don’t worry – I won’t use your name or company name!).  If you are on Twitter, you can follow me at http://twitter.com/Omni_man.

Learn more about Omniture Consulting
Learn more about Omniture University

 

3 comments
vickyman007
vickyman007

Hi Adam, i have scneario here. On Event5 which is COUNTER and i have serialized the event5 just with numeric value. will the counter will increase by one or will increase by the numeric value.

sibel akcekaya
sibel akcekaya

Dear Adam, Right now we are in the middle of Omniture Implementation for our new website. I found out that something like event serialization exists by your blog. Thanks for that. But I have one challenge here. I think I can not use this for evars. So I have a success page with some evars and events and when a visitor reloads the page all of the variables will be fired again. Now I know how I can fix events, but what about evars? How I will prevent it being recounted when the page reloads. Thanks

David
David

nice post, i can see the value in using this for tracking media rich sites, or sites that seem to have problems with users always using the back button because their existing shopping cart may not have a facility to go back one step. Your reports will show users re-entering the funnel later in the process...