Wel­come back to the Site­Cat­a­lyst Finance Fun­da­men­tals blog series. In this series we are dis­cussing 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.

Very often, web ana­lyt­ics is con­cerned with mak­ing sure web­site users con­vert from a prospect to a cus­tomer by buy­ing some­thing, open­ing an account, or per­form­ing some other key con­ver­sion process. But what often gets left out is track­ing actions taken on the web­site once users become customers.

Self-Service Trans­ac­tion Overview

Self-service trans­ac­tion track­ing is the finan­cial ser­vices fun­da­men­tal that con­cerns itself with mon­i­tor­ing how users inter­act with the post-login por­tion of a web­site. The def­i­n­i­tion of “self-service trans­ac­tion” can be pretty broad, but I like to go with the idea that a self-service trans­ac­tion is any process a user per­forms on a site, post-login, that isn’t directly tied to another KPI, but pro­vides value. What a mouth­ful! The exam­ples below should clar­ify this.

Some typ­i­cal self-service trans­ac­tions for finan­cial ser­vices com­pa­nies can include:

  • Edit­ing user pro­files – chang­ing pass­word, updat­ing mail­ing address, etc.
  • Pre-login pass­word reset process
  • Enrolling in paper­less state­ments or billing
  • Order­ing checks or replace­ment credit cards
  • Request­ing a credit limit increase
  • Adding an account fund­ing or pay­ment source
  • Enrolling in auto­matic payments
  • Mak­ing a loan payment

Or any other post-login account main­te­nance activ­ity. Really, the sky’s the limit when it comes to what can be tracked!

Self-Service Trans­ac­tion Track­ing Implementation

The first and most impor­tant step in track­ing self-service trans­ac­tions is to iden­tify which actions and processes on the site are con­sid­ered to be “self-service.” Often, ana­lysts give cod­ing instruc­tions to their devel­op­ment teams with­out defin­ing what con­sti­tutes a self-service trans­ac­tion, and report­ing dis­ap­point­ments result from key trans­ac­tions that aren’t avail­able for reporting.

Once the trans­ac­tions have been iden­ti­fied, on to the fun part (in my book)! Self-service trans­ac­tion track­ing requires the use of the fol­low­ing variables:

  • Two events – one for Self-Service Starts and one for Self-Service Completes.
  • One eVar – used to iden­tify the self-service type. It should be con­fig­ured to expire on page view.

At Adobe Bank, let’s say that the oper­a­tions group wants to see how often users enroll in the auto­matic loan pay­ment process, a 3-screen process that is acces­si­ble from the post-login site.

On the first screen of the process, trig­ger the Self-Service Start event (event1 in the exam­ple below) and set the name of the process in the eVar (eVar10 below). On the com­ple­tion screen, set the Self –Ser­vice Com­plete event (event2 below).

This for­mat can be fol­lowed for any trans­ac­tion process flow, no mat­ter how many pages or steps. Once you’ve suc­cess­fully imple­mented the code above, your report should look some­thing like this:

We’ve cov­ered the basics of self-service trans­ac­tion imple­men­ta­tion in this post. In part 2, we’ll cover report­ing and opti­miza­tion when self-service trans­ac­tion track­ing has been fully implemented.

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 svertree (at) adobe​.com and I will do my best to answer it on this blog so every­one can learn! (Don’t worry – I’ll keep your name and com­pany confidential).