Tagging Forms (w/o Losing Money)

Our post today will touch on two separate subjects (tagging of forms and limiting server calls (and therefore cost) in certain situations). Those two work together very well, so I decided to mix them together. Two subjects in one posting. Surely that’s a good deal!

Forms

A lot of web sites live entirely to provide visitors a means of entering information. Popular examples are financial sites (where you can open accounts, order credit cards and so on), retail (where you specify delivery and billing addresses), social & health sites (where you provide updates or post content). Even the simple site search is a form, although that one is special (and I have written about it already).

Marketers love forms. When visitors type something in, it provides the marketer with information about that visitor, which will eventually lead to a better understanding.

Product owners and sales need forms so visitors can hand over information that allows them to sell products. Support like forms as well; they streamline case creation and make it easy to ask for feedback.

There is one big problem with forms, though: people eventually get sick of typing stuff into fields in their browser.

How far they go depends on a couple of things, the most important being: how badly do they want what is at the end of the form. The actual form itself plays a big role as well, of course. Make a crap form and you get crap completion rates. A lot of sites got burned when mobile devices became relevant!

Bad conversion rates are bad for a couple of reasons. If people drop out while buying something, your company will not sell as much as it could. If they drop out while they want something and then call instead, your company needs to staff a call centre, which is expensive.

Bottom line: make your forms as easy and well-oiled as possible.

Tracking Forms

When your friendly marketer asks you to track a form for her, this is what she means:

• she wants to see a completion rate — form was called up x times and submitted y times.
• She might want to see a “Form Abandoned” metric.
• She wants to know which field in the form scared people off — by proxy of finding the last field that they did change.
• She might want to know how often one visitor started a specific form — “how often did they fail? did they eventually succeed?”

The first and last requirements are relatively easy to do: track both the form page and the “thanks for submitting your information” page and you can calculate x and y and therefore the form completion rate. You can use a Counter eVar to see how many times people tried (see also Counter eVars by Adam Greco and Visitor Scoring by Ben Gaines for more on those).

But what about requirement two and three?

The naive approach would be to send a tracking request every time the visitor has filled or modified a field in the form using Custom Link Tracking.

But there is a massive issue with that: each tracking call costs money!

That’s how Adobe Analytics is billed — by server call.

So it is in your interest to keep the number of tracking calls as low as possible and forms are a very good playground for explaining one widely used method: cookies plus a call on the next page.

Serve Cookies to Keep Cost Down

The idea is actually really simple. For each state change (a filled form field, for example), you update a cookie. As soon as you track something else, you check the cookie contents and send the state along. Added insight without any more cost.

So let me describe it in more detail.

Step 1 — add plugin [optional, sort of]

Your marketer will want to see last changed form field correlated to the form that the visitor was working on, we therefore need to track the name of the form and the name of the field.

The name of the field comes from the cookie, obviously.

For the name of the form, you have two options: you can store it into the cookie along with the field name, or you can use an existing plugin called getPreviousValue, which will store the name of each page the visitor looks at and return the name of the previous one when needed.

I’ll presume you’ll use the plugin.

Step 2 — find “variable”

For those of you who still put data into “variables”: you will need to find out which variable or variables to use! It is highly likely that your friendly marketer will want you to write the name of the previous page into a prop and the last field name into another. So find out which props she has assigned and use those.

Remember when I wrote about Saving “variables”? Here’s a prime example of that. You put both page and field name into a single prop, then you (or your friendly marketer) would use the Classification Rule Builder or just plain SAINT to make a useful report.

Or you use two props, which in a lot of cases makes sense because you might need the name of the previous page for a couple of different things.

If you are using Context Data or a Data Layer: just send the data with a nice, self-explanatory name.

Step 3 — populate “variable”

Quizz question: when or where do you populate the “variables”?

Answer: on every single page on your site, but only when needed.

If you are rolling your eyes now, then you might have forgotten about the developer’s best friend, the s.doPlugins callback!

The function is called whenever you track something, be it using s.t() or s.tl().

Which means you can put code into that function that handles situations like the one we’re looking at. To be clear: there is no need to add anything to any page.

Within s.doPlugins, you add a block of code that:

1. checks whether the cookie exists and has data
2. reads the values for last page name and last form field
3. writes those values along with a “Form Abendonments” event

Are you using props? Do this:

   s.prop21 = 'Blue Credit Card Application - Form 1|last name';

Using a data layer? Do this:

   dataLayer['prevPage'] = 'Blue Credit Card Application - Form 1';
    dataLayer['lastFormField'] = 'last name';

Step 4 — clear cookie

This is an important and easily-forgotten step: you have to clear the cookie!

Why?

Well, if you don’t then your code will just read it again and it will send all data again, until the cookie expires!

You have to clear it in two places or two situations: when the last form field has been tracked (best done in s.doPlugins after you read the cookie), and also when the form has actually been completed and submitted (you can do this on the click, or in s.doPlugins by checking the name of the current page. If it is the “thank you for submitting our form” page, then there is no need to track abandonment and you can clear the cookie.)

Step 5 — tag your actual form

On the form itself, you want to do two things:

1. save the page name
2. add handlers that store the field names when the user interacts with them

The first one is simple: just add a call to the s.doPlugins function like so:

   var prevPage = s.getPreviousValue(s.pageName,'s_pv');

The second one means you have to hook into the relevant callbacks for all form fields, like onChange, input, keyup or whatever you personally believe works best. I’m pretty sure you’ll be using jQuery or an equivalent life-saver.

Within those handlers, all you need to do is write the name of the field that called it into your cookie. You can use the jQuery Cookie Plugin for that, or you can use a function called s.c_w() that comes with the s_code.js.

   s.c_w('s_lstfldname',field_name,expiry);

It is perfectly safe to omit the expiry parameter, turning the cookie into a session cookie.

Step 6 — test, rigorously

There are a couple of moving pieces in this machinery you just built, meaning you should test it until your dreams are filled with cookies, plugins and form elements. You do remember how to debug, don’t you? Look at the URL!

Notes

The same mechanism is often used with the getPercentPageViewed plugin, which I’ll describe at some point. The plugin measures how far down visitors scroll on a given page, and we’re using cookies with for the exact same reason, cost reduction.

The big assumption behind this method is of course that the visitor will see one more page at some point. If they hate your form so much that they complete walk away from your site, the cookie will rot in their browser forever and you won’t see any data.

If that is the case (and you can find out a couple of ways, one being the Pathing Report), or if you simply don’t care about money as much as you care about data, you could track with a timer instead, meaning that you store state changes in a cookie, but instead of sending the information off on the next page, you track it every 5 seconds or so. If there was a change.

The big issue with that is the analysis. Each visitor will generate a bunch of data points, making reporting and analysis more challenging than with the original method which generates exactly one data point per form.

Some marketers would like to see additional events, like “Form Abandonments”, “Form Errors” and “Form Completions”. “Form Abandonments” can be sent along with the last field name, simple. “Form Completions” can be tracked on the “thank you” page easily.

“Form Errors” are different in that you might actually want to track them when they happen.

There are different types of errors, of course. There might be an actual error with the form, or you might call a violation of data constraints in the form an error. Either way, it is not likely to happen as often as the change of a field, so I’d probably just use Custom Link Tracking as and when it happens.

I’m sure I don’t have to tell you this: the whole article is utterly useless for those visitors who do not accept cookies. But we’re talking about 1^st-party cookies here, so that is pretty rare, especially when the users do want something from you.