Recently I moved all conversion tracking for one of our SaaS tools, Dead Mans Snitch, from Google Analytics to KISSmetrics. My goal was to accurately track new sign ups, upgrades, and downgrades, and Event tracking seemed like KISSmetrics’ sweet spot. The transition was smooth, creating Events was easy, and I learned a few things along the way.

KISSmetrics Events

There are multiple ways you can track Events in KISSmetrics: when a user visits a page, visits a page with regular expression, or clicks on an element or submits a form (via ID attribute or class name). I tried the form ID/class method first, but quickly learned our app uses the same ID or class on multiple pages. Since we have four available plans and users can upgrade and downgrade between all of them, that’s 16 total combinations of plan changes, not counting direct signups or account deletions.

My goal was to accurately track new signups to all plans, upgrades, and downgrades. Using the visits a page method seemed promising, but that would have required a unique URL following every signup and plan change which we didn’t have. All pages just redirected to /snitches (the user’s dashboard) after signing up or logging in. I’m a fan of using small funnels to track events but KISSmetrics only allows you to use them in the Reports feature, not Metrics.

A funnel with two steps looks like Google Analytics Goal Funnels.

Dead Man’s Snitch is built in Ruby on Rails. In the past we redirected new signups and upgrades to /snitches and /subscription, respectively. Using the current URLs wouldn’t be an effective way to track plan changes. So instead of creating new URLs we added query parameters to each of the redirect paths.

Query Params for the Win

Query parameters are optional key-value pairs after the “?” in URLs. You’re likely familiar with Google’s URL builder that helps you create URLs like:

https://www.website.com/?utm_source=google&utm_medium=cpc&utm_campaign=version_one

Not all URLs using query params are as long as Googles. Dead Man’s Snitch was recently featured on Product Hunt and they add a simple referral param so website owners know the traffic is coming from Product Hunt.

https://deadmanssnitch.com/?ref=producthunt

Tracking Sign Ups

Previously, when a user signed up they were redirected to /snitches. The code looks like:

redirect_to snitches_path

</code>

But with query params our new code looks like:

redirect_to snitches_path(plan: interactor.try(:plan).try(:slug))

Which produces the URL:

https://deadmanssnitch.com/snitches?plan=lone_snitch

Tracking Upgrades/Downgrades

After a user submits the form to change plans, they were previously redirected to /subscription from:

redirect_to subscription_path

Now, we needed a way to differentiate between the different combinations of plan changes.

Using query params, our new code looks like:

redirect_to subscription_path(plan: plan.try(:slug), old_plan: old_plan.try(:slug))

With the new code it produces the following URL with query params:

https://deadmanssnitch.com/subscription?old_plan=&plan=

Earlier in the code we defined old\_plan = current\_user.plan because once the user submits the form to change plans, the current user’s plan will become the old plan.

Now, instead of having to create new URLs for every new sign up and plan change, the few lines of code does it for us by adding query parameters.

Creating Events

To track each URL separately you have to create an Event for each URL in KISSmetrics.

KISSmetrics has a wonderful thing called a Wildcard that you can use for creating Events using URLs. It’s exactly what you’d think. Wildcards can be placed anywhere in the URL (path or param) and KISSmetrics will only look for a match with the remaining parts of the URL to trigger an Event. This works well for tracking total upgrades from our free plan:

https://deadmanssnitch.com/subscription?old_plan=lone_snitch&plan=*

We could do the reverse and add the Wildcard after `old_plan` as long as we specified a new plan. This tells us that a user’s new plan is Private Eye.

https://deadmanssnitch.com/subscription?old_plan=*&plan=private_eye

However, by specifying a new plan and leaving the old plan as a Wildcard, our total upgrade metric would be inflated when a user downgrades from a higher plan or crossgrades. A crossgrade occurs when a user updates his/her billing information and doesn’t change plans. Once our page loads, our query params are still fired, and it gives us:

https://deadmanssnitch.com/subscription?old_plan=private_eye&plan=private_eye

This is an edge case but it is still something to consider when building Events for the Metrics you want.

Event tracking using URLs (with the help of query parameters) has been extremely effective and easy with KISSmetrics. Now that the Events have been created you can start building a dashboard full of Metrics.

Happy Tracking!