Have you got conversion values that are over 100%? In other words, have you got more people starting a form than you have visits? Or more people finishing a form than starting it? Or more people getting to step 2 of a form than actually starting it?
This is a pretty common problem and stems from the way your event metrics have been set up.
But, did you know that with Derived Metrics, you can fix it without going back and re-implementing, and without using additional success events?
Ok, so the problem you’re experiencing is called serialisation. You’re counting every instance of the form event being set, be it form start or form complete or whatever.
And so the problem you see is when the form re-loads or they re-start the form…each time the event fires again. The result is that you can end up with more starts than visits, or more completes than starts etc.
Enter Derived Metrics.
Your metric in shining armour.
You can create a calculated metric that has the same outcome as a “serialised” metric. And if you’ve forgotten what a serialised metric is, it’s one that is used to count an event once per visit. So it doesn’t matter how many times someone starts a form, or submits a form; they’re only counted once.
But wait – derived metrics can be used to count not only once per visit, but once per visitor as well – something that’s a little harder to do.
Ok, so to the how…
First thing you need to do is create a new segment. Derived metrics are not only calculated metrics, they’re also segmented metrics.
So, step 1: create a new segment and name it.
You want to define this segment at the Visit level.
Next, drag in your event name – lets say this is Form Start. Set the selector to “Exists”.
So, now you have a segment where you want to include any Visit where a Form Start occurred.
Go ahead and save your segment.
Now go over to the Metric Manager and add a new metric.
Name your metric something like “Form Start (S)” and give it a meaningful description, such as “Form starts counted only once per visit”.
Then select the Segment you previously created and drag it onto the metric canvas.
Next, from the metrics selection, drag Visits onto the metric canvas.
Save the metric.
You have now created a new metric, where the metric is calculated as “the number of Visits that contains a Form Start” which is the equivalent of an Event, set once per Visit.
If you had dragged on the Visitor metric, you would have a new metric that is calculated as “the number of visitors that did a form start during any of their visits”.
This methodology can be used across pretty much any metric that is set to count on every instance (by default) and enables you to effectively serialise the event at both the visit and visitor level, without any implementation change, giving you a more accurate unique count of the event happening.
And, as it’s calculated in real-time, it’s available across historic reports..simply apply it to any report.
Derived metric sourcery. Now, if only we’d be able to include a calculated metric as part of a segment, we’d be golden. Let’s keep our fingers crossed, and see what they announce at Summit.
