Event Serialization [Inside Omniture SiteCatalyst]

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

What is Event Seri­al­iza­tion?
Event Seri­al­iza­tion is the process of de-duplicating the fir­ing of Suc­cess Events.  As you know, when a nor­mal counter Suc­cess Event is set, Site­Cat­a­lyst increases the Suc­cess Event met­ric by one and asso­ciates the suc­cess with any val­ues cur­rently exist­ing in Con­ver­sion Vari­ables (eVars).  How­ever, there are many cases in which a user’s action can trig­ger a Suc­cess Event mul­ti­ple times (inad­ver­tently or inten­tion­ally).  For exam­ple, a user may log into your web­site sev­eral times a day, mak­ing your “Logins” met­ric unrep­re­sen­ta­tive of unique Logins.  Alter­na­tively, a vis­i­tor may hit the “back” but­ton in their browser while in the con­ver­sion process trig­ger­ing a sec­ond “Cart Add” event to be fired.  Most of the time, these dupli­cated Suc­cess Events are nom­i­nal, but as a web ana­lyst, part of your respon­si­bil­ity is to safe­guard the met­rics you report so that you can trust them to make sound busi­ness deci­sions so there may be cases where you need to ensure this is not hap­pen­ing.  That is where Event Seri­al­iza­tion comes into play.  Through Event Seri­al­iza­tion, you can ensure that only the first instance of a Suc­cess Event will be counted in Suc­cess Event and Con­ver­sion Vari­able (eVar) reports.

How Does Event Seri­al­iza­tion Work?
The imple­men­ta­tion of Event Seri­al­iza­tion is very sim­ple.  Every­thing is the same as set­ting a nor­mal Suc­cess Event except that you include a unique alphanu­meric string after the Event Num­ber in the syn­tax.  For exam­ple, instead of the nor­mal syn­tax of

s.events=event12

You would add a “:” and a unique string (20 char­ac­ters or less) so that your syn­tax looked like this:

s.events=event12:123456789

If Site­Cat­a­lyst sees any Suc­cess Events come through with the same event num­ber and seri­al­iza­tion string, it will ignore it.  For those of you who sell goods/services online, the con­cept is some­what sim­i­lar to the idea of Pur­chase ID, but in this case is meant for cus­tom events.

Impor­tant Things To Know About Event Seri­al­iza­tion
The fol­low­ing are some impor­tant things to know about Event Serialization:

1. As men­tioned above, the string must be alphanu­meric and less than 21 characters
2. Seri­al­iza­tion strings per­sist for­ever so be care­ful when cre­at­ing them to avoid exclud­ing Suc­cess Events unintentionally
3. You can also use Event Seri­al­iza­tion with Incre­men­tor Events

Real-World Exam­ple
In this exam­ple, a media sub­sidiary of Greco Inc. has a site that is heav­ily focused on video con­sump­tion.  For this site, they want to see how often logged-in vis­i­tors watch all of the var­i­ous videos hosted on the site.  To do this, they set a series of video-related Suc­cess Events, such as “Video Starts” and “Video Com­ple­tions” and use an eVar to track the “Video ID.”  While it wants to see a raw count of Video Starts and Com­ple­tions, one of their busi­ness require­ments is to see how many “unique” Video Starts and Video Com­ple­tions take place such that the same logged-in vis­i­tor is not counted as see­ing the same video more than once.  By doing this, Greco Inc. can com­pare the de-duplicated met­rics to the raw met­rics to see how often videos are being watched repeatedly.

To accom­plish this, Greco Inc. cre­ates four Suc­cess Events, two for raw data and two for de-duplicated data.  Since it knows the User ID of the logged in vis­i­tor, Greco Inc. decides that it can use that as part of the seri­al­iza­tion string, but there is a prob­lem.  If it uses the User ID to seri­al­ize the Suc­cess 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 seri­al­iza­tion string (their User ID).  This is where Event Seri­al­iza­tion can get a bit tricky!  Instead, Greco Inc. would need to com­bine the User ID with a unique string for each video so that the com­bi­na­tion of the User ID and Video ID would only be counted once!  Hence, if the cur­rent User ID is “123456789” and the first video they watch is Video ID “news119987,” the syn­tax might look some­thing 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 Site­Cat­a­lyst in “event14,” but will be counted again in “event13.”  The same would apply for the Video Com­ple­tions events with one being set nor­mally and the other being seri­al­ized using the same string shown above.

That is pretty much all you need to know about Event Seri­al­iza­tion.  Let me know if you have any questions…

 

Have a ques­tion about any­thing related to Omni­ture Site­Cat­a­lyst?  Is there some­thing on your web­site that you would like to report on, but don’t know how?  Do you have any tips or best prac­tices you want to share?  If so, please leave a com­ment 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 every­one can learn! (Don’t worry — I won’t use your name or com­pany name!).  If you are on Twit­ter, you can fol­low me at http://​twit​ter​.com/​O​m​n​i​_​man.

Learn more about Omni­ture Consulting

Learn more about Omni­ture University