The reason why we should be looking for trends in Web Analytics data instead of the absolute values, is because… for web data, data loss is commonplace. Data loss can be due to poor user network connectivity, users surfing anonymously, technological limitations, and many other reasons.
We can all agree that there is little we can do about data loss (we can’t force users to NOT surf anonymously right?), but for data inaccuracy, that’s a different story.
Data inaccuracy can be due to various reasons, and one of them can be attributed to erratic online user behavior. What do I mean by that?
While you were surfing the web, how often do you reload a page? More than you would have realized. Why do we tend to reload web pages so often then? Here’s a list:
- Web page loading slowly
- Missing elements (text, image, etc) due to incomplete loading
- “What’s that advertisement that flashed by?”
- Just because we can
Sometimes, there is simply no good reason why we do something, and that’s something we have to somehow live with.
Does that mean… our Analytics must suffer?!
Example: Application Form
A good example will be application forms for different products.
As a client, I would LOVE to know the form completion rate (% of instances where a form was completed once it has been started). This tells me how each product is doing and which is doing better.
And also, it would be GREAT to understand the next-step conversion rate (% of instances where an user moves from step X to step X+1). This tells me where are users dropping off during the application process, and allows me to investigate the cause for high drop-off rate.
Coming up with these success metrics is not difficult at all, right? The tricky part is making sure the data is accurate.
If we were to capture the necessary data the normal way, this might be how the result will look like:
|Form step 2||107|
|Form step 3||65|
|Form step 4||42|
Let’s calculate the success metrics!
Form completion rate = Form completed / Form started = 58 / 125 = 46.4%
Step1 to Step2 conversion rate = Form step 2 / Form started = 107/125 = 85.6%
Step2 to Step3 conversion rate = Form step 3 / Form step 2 = 65/107 = 60.7%
Step3 to Step4 conversion rate = Form step 4 / Form step 3 = 42/65 = 64.6%
Step4 to Step5 conversion rate = Form completed / Form step 4 = 58/42 = 138.1%
Notice how Step4 to Step5 conversion rate is more than 100%? That does not make sense at all, but it happens.
It is quite common for web users to reload the completion page for various reasons stated earlier.
So the question is… should we be worried about data inaccuracy?
As we all should know by now, Web Analytics is about trends, not absolute data. But that doesn’t mean we can afford to have such inaccuracies in our data.
In another article (Characteristics of Good Data), we have talked about how important it is to have consistent and accurate data.
What we want to capture is the number of times an application form has been successfully completed, which means… we can’t afford to capture the data TWICE just because the user refreshes the page.
So… what can we do about it?
In Adobe Analytics, there is this thing that we call event serialization. What does it do? This capability enables us to capture a piece of data ONCE and only ONCE, no matter how many times we try. This is particularly useful for the example above!
Instead of inflating the number of times an application form has been completed, with event serialization, no matter how many times an user refreshes the page, the form completed event will only be captured once. This removes the noise data that we were struggling with when calculating Step4 to Step5 conversion rate.
Oh, if you want to know more about Adobe Analytics, here’s an article for you.
What do we need?
In order for this to work, we need to have a few things ready:
- A system-generated unique ID that persist throughout the form application, but is unique for each different form application instance
- Access to Report Suite
- Access to DTM
How do we set it up?
Firstly, login to your DTM (Dynamic Tag Management) and create a Data Element. An example configuration will be:
- Name: event-uniqueID
- Type: JS Object
- Path: digitaldata.form.uniqueID
Just a sample of how to create a new data element, as I currently can’t access my DTM 🙁
With the newly created Data Element, we can then go ahead and modify our direct call rules that capture the form data.
In this example, we are capturing event210 whenever a form application has been started.
In order to serialize it, we will add this event as usual, and in the Serialize from value field, we put in the name of the newly created Data Element (eg. %event-uniqueID%).
We have heard of many complaints from different Web Analytics guys that event serialization doesn’t work for them. That’s because, there’s 1 final step that is crucial and often overlooked.
Login to your Report Suite. Navigate to Edit Settings > Conversion > Success Events.
Notice the column Unique Event Recording? By default, the value is Always Record Event.
In order to enable event serialization, we need to change it to Use event ID. This will ensure that the system will make use of the unique ID we have prepared earlier on, to de-duplicate the events captured accordingly.
And that’s it! Event serialization is a very powerful capability in Adobe that is not available in Google Analytics. Not many know of this capability even, so… congratulation to you! Go share it with your analytics friends and they will be eternally grateful to you (:
If you need more information on event serialization, below are a couple of materials that would be mighty useful: