August 17, 2011 ↘︎

What are our members doing?

This topic was requested by one of my readers – thanks for the inspiration Dan.

And it comes back to segmentation.  And the value derived from measuring your customers/members behaviors across your digital channels, and the impact they could be having on your conversion rates if you don’t segment.

Ok, so, we’ve all likely got some form of customer – either a lead, or a customer who has purchased, or a member, such as a policy-holder or a service-holder.  For the purpose of this post, I will call members, customers.

Why do we want to measure their activity?

Well there’s a number of reasons.

If we run a self-service site, we might want to know what self-service transactions are being done beyond the login (within the customer self-service portal, nowadays commonly called My{something or other}).

That’s pretty straightforward and you can achieve that with traditional metrics if you are reporting solely within that “site”.

But customers are not all the same.  There are business customers, there are residential customers, there different types of customers within each of those segments – business types, business size, residential locations, MOSAIC-based classifications of customers, demographics and so forth.  And guaranteed they will do stuff differently.  They purchase different products and services.  They’re interested in different content and so forth.

And many self-service sites are purely transactional in nature – change your address, update something or other, check usage of something or other etc.  Most of your content will be on the “outside” and these guys use that content too.  But they have a closer affinity to your brand and will use that content differently.

And the other big thing about them is, they’re customers.  They’ve converted.  Not only are they your golden opportunity to

a) cross-sell/up-sell and
b) observe their activity and figure out why they converted so you can better optimize

but (and possibly more importantly) unless you measure their activity, they are negatively impacting your conversion rates on your regular website and your average revenue per visit is understated.

Huh? Why?

Because they probably go through that site to get to their My{something or other} self-service site.

Consider this:

Let’s say you’re an insurance company.  Your acquisition team wants to know the sites conversion rate for product sales and the average revenue per visit.  You also have a self-service site and the way that most of them get to that site is through your regular homepage.  Suppose your overall traffic to your site is 350,000 visits per month and you get 10,000 product sales per month, with revenue of $500 per sale.  Suppose also that 200,000 visits per month go to your fabulous self-service site where they’re busy updating their info, checking on their policy and so forth.

If you DON’T strip out known customers, you’re under-reporting.

Your average order value is unaffected – it’s still $500.  But your visit conversion rate is showing as 3%, and your average revenue per visit is $14.29.

If you strip out the known customers, your conversion rates just went through the roof.  It’s now 7% (10,000/150,000) and the average revenue per visit is $33.33 ($5,000,000/150,000).

Ok, a little extreme maybe, but you get the general idea.

So, measuring customers not only provides more accurate conversion rates, but also gives you better insights into their activity.

And SiteCatalyst allows you do all that – and more.

Customer segmentation

Right, so you want to measure customer activity for a variety of reasons.

For basic customer segmentation, you’ll need an eVar and an s.prop and one or two success events.  The eVar will enable visibility of conversions back to them (revenue and the likes); the s.prop is used to segment your traffic-based reports by customer/non-customer type and the success events are for things like logins, failed logins etc.

If you’re measuring self-service activity, you’ll have another eVar for self-service transaction type and a counter success event.  These two are set every time the user completes a transaction.  You pass the type of transaction to the eVar and set the success event.  All pretty much no-brainer stuff.

If you really want to get value, you’ll also use an eVar to capture their memberID, userID or some other unique value that can be used for customer-type segmentation.

Basic segmentation – customer/non-customer

When a user does something that only a customer can do, or if they make a purchase, you set the eVar as “customer” or something similar.  You also set the success event, such as login, if that’s what they did.

You will also need to set the s.prop to “customer” and you need to make sure it’s remembered and set again on every single page view.

The way to do this is through the getAndPersistValue plugin – a handy little plugin that will set a traffic prop automatically from a value in the cookie.

For example:

Let’s say that you have a My{something or other} self service site, and the user logs in.  Upon login, you would use the following in your s_code:

/* My Self Service Login */
/* Set User Type */
if((s.pageName.match(/loggedin/)){ // change for your page
/* serialised login and self service success success event*/”event1,event2″;
s.eVar10=”Customer”; // Customer Non Customer
s.eVar11=”Login”; // Self service transaction name
/* Check existence of persisting prop10 – user type */
if(!s.prop10&&!s.eVar10) {
s.prop10=”Non Customer”;
/* Set persisting prop10 to value of the eVar10 */

Basically what happens is when the user logs in, the eVar is set to Customer.  The success events count the number of successful logins and also a general self-service transaction count.

Line 8 says set s.prop10 from the value of eVar10 and store it in a cookie for 365 days.

Under non-logged in status, eVar10 will be empty, so line 9 is true (eVar10 has no value but s.prop10 may have a value).  If that’s the case, set it Non Customer and set the eVar to Non Customer.

Then line 14 re-evaluates s.prop10 from eVar10 and resets itself.  Odd I know, but it works.

You end up with a number of different states:

1) For non customers eVar10 and s.prop10 = Non Customer

2) For customers in the same session, eVar10 and s.prop10 will be Customer

3) For customers in a later session, eVar10 and s.prop10 will be Customer (because of the getAndPersistValue)

A word about the success events:

I’ve used two success events – event1 as a discrete count of logins and another as a general count of self service transactions.  You could combine, but I like the separate count and you can serialise the login event so you only count it once per session – giving an idea of true logins, rather than repeat logins per session.  The self-service transaction type (eVar11) would generate a report of all the different types of transactions by customer type, when viewed using the Self Service Transaction event (event2), or specifically logins (event1).

The Result

Now you have the capability to report on not only logins and self-service transactions types, but also your conversion rates are more representative of real rates by Non-Customers (and Customers – very important for retention purposes), and you can see their behaviors across pages when you use the s.prop.

In v15, or with Discover, you can create and use these two segment values for more analysis to filter out or filter in based on Customer or Non Customer.

Of course, the next thing you’ll want to do is further enhance your Customer segments with demographics, or those additional business segments, using extracts from your customer database.  Take a look at 1 million rows and it still wants more, for an understanding of how that works.

So, segment, strip out your non-customers and re-run your conversion rates.  Now do the same for customers.  And now start looking at what customers did prior to conversion so you can influence those non-customers to do the same thing.

My final tip…use Test&Target to provide more relevant content to Customers or Non Customers…because, now you can identify them.

DB logo
DB logo
DB logo