27 October 2014

Tracking User Activity Across Browsers and Mobile Devices

I'm often asked whether we can track user activity at a more granular level than what's currently provided with Login History, Setup Audit Trail, and other existing monitoring features in Salesforce.

When I tell them yes, people's imaginations immediate kick into over-drive. Without understanding what is possible, people begin to imagine every possible way data can be accessed whether through a button click, running a report, viewing a list view, hovering over a related list, or looking at search results.

There are many ways users may interact with data in Salesforce. This blog post is designed to separate out fact from fiction when understanding how granular we can track user activity while working with the new Event Log Files functionality.

Event Log Files provides self-service access for customers to server generated log records. This means that a server interaction had to happen in order to record the event. The most typical server interaction is the change in a URI (uniform resource identifier, analogous to the URL you see in your address bar).


For example, when I clicked on the Marc Benioff contact record from the Home tab, the URL in the address bar changed by adding the contact id. As a result, the entry in the log file shows a Referrer URI of /home/home.jsp and a URI of /0033000000Vt4Od.

This URI interaction unto itself is powerful considering salesforce grew up as a native web application. Most things that we click ultimately change the URI. The easiest way to test this is to click something in the application and see if the address bar changes.

De-coding the URIs isn't difficult, it just takes a lexicon:
Standard object based pages:

/d: Detail- Detailing a single record and with its associated records
/m: Hover- HoverDetail page that uses a mini layout and no header/footer
/e: editPage Allowing the editing of a single record
/p: printableView- In a relatively unadorned format, detailing a single record and all of its associated records.
/o: Overview of a single entity.
/l: list- A filtered list of a single entity
/x: Printable list: A filtered list of a single entity. Does not have a help link, since you can't click links on paper.
/r: Refresh list: A stripped down version of a list filtered by ids
/s: special: Special is used for "other" pages where you want to reuse parts of the edit/detail page
/h: history: Show the history (used only in forecasting)
/a: Assign: Entity Owner Change page
/c: calendar: Time-based (Calendar) view of list data
/n: mini edit: Mini layout edit page

Custom Objects based Pages

/d: Detail
/m: Hover
/e: Edit
/p: Printable View
/o: Overview
/l: List
/x: Printable List
/a: Assign
/r: Refresh List

We can now track when someone prints a page or list view, edits a record or creates one, changes ownership, or even refreshes a list.

URI events mainly track what happens in the browser. In order to track similar interactions on a mobile device using a Salesforce 1 application, we have a separate UI Tracking log event.

At Dreamforce 2014's True to the Core session Mark Bruso asked me about this distinction and what we actually track.

Most of the time, when people ask about Salesforce 1 mobile, it's to validate the effectiveness of a BYOD (Bring Your Own Device) mobile strategy with a focus on the type of device, network used, and operating system of choice. The goal is typically to rationalize an investment in mobile in addition to understanding what their users are doing when they are in a Salesforce 1 application.


However, we also track a couple key attributes in the UI Tracking log file including Referrer and Action. This are analogous to the URI and Referrer URI attributes in the URI log file.

When you combine these two data sets, the big picture emerges across these different platforms. Now we can track what's happening with a user regardless of whether they use a browser or a mobile phone.


This is powerful for answering questions like:
  1. What % of my users are in the browser versus on the phone?
  2. Where are users using their mobile devices since they may be on the road?
  3. Where are my users spending their time and on what records?
  4. How frequently are they logging in and what hours of the day?
  5. Who clicked on what, when, where, and how?
Tracking user activity in salesforce isn't rocket surgery. We can't track everything a client side script might, but we can track a lot. And what we track enables us to re-create what a user did and paint a picture that helps address a variety of adoption, troubleshooting, and audit use cases.

No comments:

Post a Comment