Wel­come to the Site­Cat­a­lyst Finance Fun­da­men­tals blog series.  In this series we will dis­cuss the imple­men­ta­tion basics and exam­ple analy­sis of each fun­da­men­tal solu­tion that Finan­cial Ser­vices cus­tomers should con­sider lever­ag­ing.  Stay tuned and please feel free to con­tribute your thoughts/experience as we dis­cuss each solution.

One of the most impor­tant Finan­cial Ser­vices Fun­da­men­tals is Appli­ca­tion Con­ver­sion.  This solu­tion tracks key mile­stones in the appli­ca­tion process.  From my expe­ri­ence, almost all Finance clients have some vari­a­tion of this solu­tion imple­mented, but I’d like to dis­cuss the best prac­tices that have devel­oped over the years.  Today’s post will focus on imple­men­ta­tion best prac­tices and a future post will cover report­ing and analy­sis tips.

Fun­da­men­tal Implementation

At the most basic level, this solu­tion lever­ages three Site­Cat­a­lyst variables:

1)      Appli­ca­tion Start (event)

2)      Appli­ca­tion Sub­mis­sion (event)

3)      Appli­ca­tion Type (eVar)

 I rec­om­mend using the same events for all prod­uct lines rather than using dif­fer­ent events for each prod­uct line.  The Appli­ca­tion Type eVar is used to describe the appli­ca­tion and/or prod­uct being applied for.  This approach pro­vides scal­a­bil­ity as fewer events are required.

The Appli­ca­tion Start event should be set on the first page of the appli­ca­tion, while the Appli­ca­tion Sub­mit event is set on the thank you page.  The Appli­ca­tion type eVar should be set on the same page as the events.

Application flow

I rec­om­mend set­ting the eVar to expire on page view with most recent allo­ca­tion.  Since the eVar is always set with the event and it is describ­ing the event, there isn’t a need to per­sist it.  By expir­ing it on page view, it removes the risk of con­fu­sion in report­ing as users might try to pull in non-application events into the report.

eVar settings

Be sure to also enable par­tic­i­pa­tion on the App Sub­mit event.  This is a back-end set­ting so ask your Adobe Con­sul­tant or Client­Care to enable this for you.

Com­mon Pitfalls

I’ve been asked “why bother with the events when I can just report on the page names?”   The answer is that lever­ag­ing events greatly sim­pli­fies report­ing.  When an event is used, it becomes avail­able for report­ing against any eVars that might be per­sist­ing from pre­vi­ous pages.  When you use events to track appli­ca­tion starts and sub­mis­sions, it is eas­ier to mea­sure how effec­tive other reports (like cam­paigns, tools etc) drive users to appli­ca­tion submissions.

Avoid the temp­ta­tion to set an event on each step of the appli­ca­tion process.  Since there are a finite num­ber of events avail­able, they should only be used for track­ing the most valuable/optimizable activ­i­ties.  Yes each step is impor­tant to con­ver­sion and yes they should be tracked, but not with events.  If each page is uniquely named, then the Fall­out pathing reports can be used to iden­tify where users drop out in the appli­ca­tion process (in a future post we will cover page nam­ing best practices).

Appli­ca­tion length changes over time and can vary from prod­uct to prod­uct.  A credit card appli­ca­tion might only be three steps, while a mort­gage appli­ca­tion could be five to ten.  Track­ing mul­ti­ple events can result in con­fus­ing report­ing as busi­ness users might not know why cer­tain steps are miss­ing from some prod­ucts, but not oth­ers.  These events are almost never used in dash­boards (and they shouldn’t be, reserve the space in your dash­board for the KPIs).  From my expe­ri­ence, the clients that have setup an event for each step in the appli­ca­tion process tend to not use them and just end up wast­ing the events.

Advanced Imple­men­ta­tion

I’ll only briefly touch on rec­om­mended advanced imple­men­ta­tion solu­tions as these each war­rant their own posts.

Dedu­pli­ca­tion: Dedu­pli­cat­ing events can improve the accu­racy of report­ing.  This is par­tic­u­larly impor­tant if the app start page is a form page that reloads when there are user related errors (e.g. a invalid email address).  If the page reloads and the event is set both times, then it would by default be tracked as two appli­ca­tion starts, when it real­ity it is one.  Ide­ally, appli­ca­tion starts for a prod­uct would only be recorded once per prod­uct per visit.  There are a few dif­fer­ent ways to dedu­pli­cate the events.  The most com­mon approach is with event seri­al­iza­tion.

Appli­ca­tion ID: Another best prac­tice is to cap­ture a unique appli­ca­tion ID on the thank you page in a eVar that is set to expire on page view.  This ID can be very use­ful for debug­ging online data against offline sys­tems, but it is also handy for report­ing and offline data integrations.

Offline Data: Since appli­ca­tions are not the final con­ver­sion, it is rec­om­mended to import offline con­ver­sions (like approved appli­ca­tions or funded accounts) into Site­Cat­a­lyst.  This can be accom­plished with trans­ac­tion ID data sources.


We have cov­ered the imple­men­ta­tion basics in this post.  In the next post, we will go over the reporting/analysis ben­e­fits and exam­ples avail­able from this solution.

Have a ques­tion about any­thing related to Site­Cat­a­lyst for the Finan­cial Ser­vices indus­try?  Do you have any tips or best prac­tices to share?  If so, please leave a com­ment here or send me an email at tucker (at) adobe​.com and I will do my best to answer it on this blog! (Don’t worry – I’ll keep your name and com­pany name confidential).