Welcome to the SiteCatalyst Finance Fundamentals blog series.  In this series we will discuss 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.

One of the most important Financial Services Fundamentals is Application Conversion.  This solution tracks key milestones in the application process.  From my experience, almost all Finance clients have some variation of this solution implemented, but I’d like to discuss the best practices that have developed over the years.  Today’s post will focus on implementation best practices and a future post will cover reporting and analysis tips.

Fundamental Implementation

At the most basic level, this solution leverages three SiteCatalyst variables:

1)      Application Start (event)

2)      Application Submission (event)

3)      Application Type (eVar)

 I recommend using the same events for all product lines rather than using different events for each product line.  The Application Type eVar is used to describe the application and/or product being applied for.  This approach provides scalability as fewer events are required.

The Application Start event should be set on the first page of the application, while the Application Submit event is set on the thank you page.  The Application type eVar should be set on the same page as the events.

Application flow

I recommend setting the eVar to expire on page view with most recent allocation.  Since the eVar is always set with the event and it is describing the event, there isn’t a need to persist it.  By expiring it on page view, it removes the risk of confusion in reporting as users might try to pull in non-application events into the report.

eVar settings

Be sure to also enable participation on the App Submit event.  This is a back-end setting so ask your Adobe Consultant or ClientCare to enable this for you.

Common Pitfalls

I’ve been asked “why bother with the events when I can just report on the page names?”   The answer is that leveraging events greatly simplifies reporting.  When an event is used, it becomes available for reporting against any eVars that might be persisting from previous pages.  When you use events to track application starts and submissions, it is easier to measure how effective other reports (like campaigns, tools etc) drive users to application submissions.

Avoid the temptation to set an event on each step of the application process.  Since there are a finite number of events available, they should only be used for tracking the most valuable/optimizable activities.  Yes each step is important to conversion and yes they should be tracked, but not with events.  If each page is uniquely named, then the Fallout pathing reports can be used to identify where users drop out in the application process (in a future post we will cover page naming best practices).

Application length changes over time and can vary from product to product.  A credit card application might only be three steps, while a mortgage application could be five to ten.  Tracking multiple events can result in confusing reporting as business users might not know why certain steps are missing from some products, but not others.  These events are almost never used in dashboards (and they shouldn’t be, reserve the space in your dashboard for the KPIs).  From my experience, the clients that have setup an event for each step in the application process tend to not use them and just end up wasting the events.

Advanced Implementation

I’ll only briefly touch on recommended advanced implementation solutions as these each warrant their own posts.

Deduplication: Deduplicating events can improve the accuracy of reporting.  This is particularly important 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 application starts, when it reality it is one.  Ideally, application starts for a product would only be recorded once per product per visit.  There are a few different ways to deduplicate the events.  The most common approach is with event serialization.

Application ID: Another best practice is to capture a unique application ID on the thank you page in a eVar that is set to expire on page view.  This ID can be very useful for debugging online data against offline systems, but it is also handy for reporting and offline data integrations.

Offline Data: Since applications are not the final conversion, it is recommended to import offline conversions (like approved applications or funded accounts) into SiteCatalyst.  This can be accomplished with transaction ID data sources.

Conclusion

We have covered the implementation basics in this post.  In the next post, we will go over the reporting/analysis benefits and examples available from this solution.

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 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 company name confidential).

0 comments