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


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


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:


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


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


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...