Tracking Form Abandonment

We used to have a plugin for Analytics that would allow people to track form abandonment. It was -wait for it- abandoned somewhere around the move from s_code.js to AppMeasurement.js. If you want to find out where in your forms people give up, you have to improvise come up with a solution yourself.

The following might help.

Principles

In case you are wondering what I am on about: your friendly marketer, on seeing how many times a certain form page has been opened, often wonders why those who abandoned the form did abandon it. Sometimes, she wants to change the form to make it better.

While the first choice for this use case is an A/B-testing tool, there are reasons why it might be a good start to analyse where exactly in the form people bail out.

If you can figure out which field was the last one that the visitor changed, then the idea is that the next field after it might have put them off.

So much for the theory.

But how do you track that?

As I said in the intro: there used to be a plugin for that, but in the times of tag management, that plugin was no longer really necessary. (To be completely honest: some people (including yours truly) thought it hadn’t been necessary in the first place, because seriously: A/B-testing!)

But since I have been asked, and since tag management is a thing now, here we go.

Choices

Before we go into any technical details…

When we track a process — say a checkout on an ecommerce site — that contains a bunch of pages, we like to put up markers, so to speak, and see how many people get past the markers.

Each marker usually represents a page in the process, and tracking like this allows your friendly marketer to conclude things like “Wow! 78% drop between putting in their address and their card details!”, which would ideally lead to some A/B testing and reworking of the process.

It is pretty easy to put up these markers on a page level, i.e. if every step of your process is a page.

If the process happens on a single page, with sections expanding and reducing as necessary (somewhat like a Single-Page Application), then the markers need to be set explicitly (exactly like in an SPA).

And sometimes, as I said above, you want more granular markers. This is what form abandonment usually is about: markers that apply to individual fields, rather than steps of the process.

For markers on fields, there are three different options:

1. for text or password fields, you can put a marker on the visitor either entering or leaving the field, and
2. for tick boxes, selections, lists, buttons, and such, you can put a marker on the change of selection.

I am in favour of putting the marker on leaving the field, rather than entering it, because it sort of aligns with the change marker on the other types of fields, but YMMV.

More choices

Then there is the question: how much is it worth to know that a marker has been passed?

If you answer: “anything”, then you can simply use the marker to track. That would usually mean sending some sort of Success Event into Adobe Analytics right when it happens.

The down side: cost. Analytics is billed by the number of server calls, so each time you send one, you up the bill (by a small amount).

The alternative is to remember any markers until the next tracking call (e.g. the next page load), then send them all at once, or rather the latest one.

This is cheaper, but it means that if people actually abandon a form and never come back to your site at all, you won’t see the last markers.

Ouch.

Your friendly marketer will have to find a good trade-off.

DTM

Using DTM, you can implement markers using Event-based Rules, plus some custom Javascript.

All three triggers mentioned above can directly be selected in DTM in the “Event Type” drop down: “focus” (when visitor enters the field), “blur” (when visitor exits the field), and “change” (when the field value has changed).

Depending on whether your marker is of the “don’t mind the cost” type or not, you will either configure the EBR to fire a tracking request, or to store the marker.

Firing a request works as usual, and don’t forget to specify an Event.

If you are conscious of cost and want to remember markers, then send them (or just the latest) on next call, you can use a “Javascript / Third Party Tags” script.

The only thing left to do is to read the cookie on subsequent page loads, track it, then clear the value so it doesn’t get tracked over and over again.

You could do that in doPlugins, or you could make a Page Load Rule for it.

Launch

The whole thing is actually not that different in Launch.

There are, of course, no Event-based Rules, but a simple Rule will do just fine.

Start with an “Event”, same as above (“blur”, “focus”, or “change”), then either track or remember, as above.

Tracking would mean adding two “Actions” to the Rule, one “Analytics Set Variables”, and one “Analytics Send Beacon”.

Leading to this:

Or, if you are optimising for cost, go for a “Core Custom Code” Action.

Then add code into the editor, actually a lot like above, except that _satellite.setCookie() is deprecated in Launch and you should now use _satellite.cookie.set().

With Launch, reading the remembered value and clearing the cookie can be done pretty easily by adding two Actions to any Rule (preferrably one that fires on all page loads).

The first action would read the cookie and write it into an eVar (using a Data Element, of course), while the second Action would clear the cookie using Core Custom Code and _satellite.cookie.remove().

Bare Javascript

Don’t. Just don’t.

But if you have to, refer to Tagging Forms (w/o Losing Money) on this very blog.

Notes

Some people say that forms are the archetype of testable UI elements, meaning you can and should A/B test the living daylights out of them.

I agree.

There are a lot more approaches to forms than to overall web site layout, and you can test number of fields, order, layout, whether you partially hide and reveal, show everything at once, what sort of helpers you implement, and a thousand other things on a form.

With that much freedom, Analytics is harder than testing.

The only time when Analytics beats testing for forms, is when you do not have enough form completions or other success markers to be able to run a test.

A test can only give valid and relevant results if it includes a good amount of traffic. This is a somewhat complex topic, but fear not, the help article called Plan an A/B Test has background information on that, and it includes a sample size calculator.