Financial Services Fundamentals: Self Service Transactions (part 1)

Welcome back to the SiteCatalyst Finance Fundamentals blog series. In this series we are discussing the implementation basics and example analysis of each fundamental solution that Financial Services customers should consider leveraging. Stay tuned and please feel free to contribute your thoughts/experience as we discuss each solution.

Very often, web analytics is concerned with making sure website users convert from a prospect to a customer by buying something, opening an account, or performing some other key conversion process. But what often gets left out is tracking actions taken on the website once users become customers.

Self-Service Transaction Overview

Self-service transaction tracking is the financial services fundamental that concerns itself with monitoring how users interact with the post-login portion of a website. The definition of “self-service transaction” can be pretty broad, but I like to go with the idea that a self-service transaction is any process a user performs on a site, post-login, that isn’t directly tied to another KPI, but provides value. What a mouthful! The examples below should clarify this.

Some typical self-service transactions for financial services companies can include:

• Editing user profiles – changing password, updating mailing address, etc.
• Pre-login password reset process
• Enrolling in paperless statements or billing
• Ordering checks or replacement credit cards
• Requesting a credit limit increase
• Adding an account funding or payment source
• Enrolling in automatic payments
• Making a loan payment

Or any other post-login account maintenance activity. Really, the sky’s the limit when it comes to what can be tracked!

Self-Service Transaction Tracking Implementation

The first and most important step in tracking self-service transactions is to identify which actions and processes on the site are considered to be “self-service.” Often, analysts give coding instructions to their development teams without defining what constitutes a self-service transaction, and reporting disappointments result from key transactions that aren’t available for reporting.

Once the transactions have been identified, on to the fun part (in my book)! Self-service transaction tracking requires the use of the following variables:

• Two events – one for Self-Service Starts and one for Self-Service Completes.
• One eVar – used to identify the self-service type. It should be configured to expire on page view.

At Adobe Bank, let’s say that the operations group wants to see how often users enroll in the automatic loan payment process, a 3-screen process that is accessible from the post-login site.

On the first screen of the process, trigger the Self-Service Start event (event1 in the example below) and set the name of the process in the eVar (eVar10 below). On the completion screen, set the Self -Service Complete event (event2 below).

https://blog.adobe.com/media_7eb98a9a08446b0746b3a5276161aaabbd79c7b8.gif

This format can be followed for any transaction process flow, no matter how many pages or steps. Once you’ve successfully implemented the code above, your report should look something like this:

https://blog.adobe.com/media_ff752483f5162dafcc574d646501ac687c577c2e.gif

We’ve covered the basics of self-service transaction implementation in this post. In part 2, we’ll cover reporting and optimization when self-service transaction tracking has been fully implemented.

Have a question about anything related to SiteCatalyst for the Financial Services industry? Do you have any tips or best practices to share? If so, please leave a comment here or send me an email at svertree (at) adobe.com and I will do my best to answer it on this blog so everyone can learn! (Don’t worry – I’ll keep your name and company confidential).