All you have to know about pre-filling forms

Why use form pre-filling?

From various independent tests we can safely assume that pre-filling forms increases the Conversion Rate. More people will submit the form if it's pre-filled.

That's why we've built a number of tools that allow you to pre-fill forms and get your applications working seamlessly with Impact Stack. The newest development in this area is a new backend independent JavaScript (Open Source) which is now available on github. When mentioning a Java Script in this blogpost we're referring to this one specifically.

How does it work?

There are different ways form pre-filling can work. As of today Impact Stack supports every possible source of data for form pre-filling. We'll take some time to explain each method in this section.

Pre-filling using URL parameters

When using URL parameters to pre-fill forms you simply add small bits of data to the URL that are then used by the JavaScript to "save" this information and present it in the form.

It looks like this: http://act.careinternational.org.uk/node/38?utm_source=blog#p:first_name=Florian&last_name=Engel

The advantage of this system is that you can easily add data from your email marketing tool to the URL and transfer it to the landing page. It's very flexible and all you have to do is get the most up to date and accurate data in your email marketing tool.

The downside of this approach is that you are putting personal information in an URL and you're probably sending your supporters an email with this URL. If your supporters forward this URL to a friend they can see the data transferred, which is not great.

If you'd like to know more about security I'll address it in detail further down in this blogpost.

URLs are also a great way to provide the user with a good consistent experience while using multiple tools in the background. For an example if you're using different tools for your donation pages and your email to MP actions you could use URL parameters to redirect users once they have completed the MP action to land on a donation page. The donation page could be pre-filled receiving data via the URL.

When using URLs don't forget to tell Google Analytics about this (blacklist URL parameters you're using).

Pre-filling forms using Cookies & Local Storage

Cookies. They are small bits of information your browser saves to allow websites to personalise the experience or perform tracking of some kind.

Cookies have been a standard in the industry for many years because they provide the user with a certain degree of control. You can set your browser to accept cookies, you can remove them and you can control how long they can stay there (= when to be deleted).

For this scenario let's say you're signing a petition. The JavaScript on the page would take your data and save it to the cookie. When you come back later the data in your cookie will be still around so it can be used to pre-fill the form.

Cookies are tied to one domain name. If this website drops a cookie it will be tied to www.impact-stack.org and its subdomains (so testing.impact-stack.org would also work). That's the limitation of this approach so you can only use the cookie to pass data between different systems when they are on the same top level domain.

Local storage could be described as the modern version of cookies with a few limitations but also a number of advantages. I'll spare you the details at this point. Local storage is something browsers have built in to store information and a website can use it to save data for the user.

The downside of local storage for our specific scenario is that local storage is tied to one specific domain. If you are leaving this domain it doesn't work (e.g. it would only work on www.impact-stack.org and not on testing.impact-stack.org).

Form pre-filling using session storage

Sessions are complicated things browsers handle for you every day. Don't worry too much about it. But what you should know: a session starts when you visit a website and ends the second you close the tab / browser window.

Session storage is a way for browsers to save information for the duration of a session only. That means the data will be gone once the user closes the tab.

If you submit a form on the Impact Stack website, for an example our newsletter signup form, all data you've submitted will be saved in the session storage. As a result further forms on this site that are part of the same user journey and the same application running in the background will be pre-filled with this data.

The advantage of this approach is that it's very secure. You're only saving data for the specific interaction, when the browser window is closed it's gone.

The downside is that this option does not allow you to share data between different applications unless you use URL parameters. But in combination with URL parameters this option works really well. The data is transferred via the URL and saved in the session storage. From there all forms the user encounters will be pre-filled.

Building your own "data vault"

If you have a number of different applications it can sometimes be challening to keep them all in sync. Especially when pre-filling forms you want to make sure that the data used for pre-filling is the most up to date information you have from this user.

In this scenario you will need a "data vault". This is a small piece of technology that holds the most up to date records for every contact. It's not a CRM, you can imagine it more like a spreadsheet with an "API" (these things software uses to talk to each other).

You then have to make sure that your CRM or other systems keep this application up to date at all times.

This option only works if you force users to log in or if this user comes from email you can attach a "password" to the URL the user receives via email. Let's assume the user comes from a link in an email. The link would look like this http://act.careinternational.org.uk/node/38?key=6e4673f6046127ccfe77cbe5... (This link won't actually do anything, it's just an example).

The key here is "6e4673f6046127ccfe77cbe5e6fb3903" which is unique to this user and can be used to access personal information. It's impossible to guess so only this person has access.

That is unless the user forwards this email with the link, containing a key to all data previously handed over. To find out more about this and potential solutions read the next section about security.

Keeping data secure while pre-filling

Protecting your users' data is very important and we should always be aware of potential threats in the area of data protection. As campaigners and fundraisers we have to handle a lot of data every day and sometimes it can be challenging to navigate this field.

There are a few ways to think about form prefililng and security:

• What's the data transferred?
• How could this data end up in the hands of someone else and how can we minimise this risk?

Each area has specific advice on which decisions to make and how to implement them.

What's the data transferred?

There is a difference between the risk of exposing people's first name or their email address. In case you're using the "recent signers" live ticker on the website you would make people's first name public anyway. However, the email address is clearly private.

If you are very concerned about privacy we would advise that you only pre-fill information that is not very personal and ideally not easy to link directly to one person.

Caution: you should certainly never transfer payment information through any of these methods.

How would data end up in the hands of unauthorised people?

The most obvious scenario how people get access to the data transferred for form pre-filling is when the user forwards the email and their friends click on the link (that contains personal information).

That's a problem because users are often not aware that they are sharing their personal information when forwarding an email. It's hidden from the user.

A simple improvement is to add a section to the email that users can forward that doesn't contain the personalised URL. You can also make it more transparent to the user, for example by adding an appropriate label to the URL such as "Your personal invitation to take action". But we all know that split testing emails for Click-Through-Rates is what's going to happen.

There is an even better way to solve this issue. When combining a "cookie" with a "save vault" you can do the following:

• The user receives a link with a secret "password" (as seen above)
• The landing page uses the "password" to decrypt the information stored in the cookie
• If this has been successful the landing page has all information needed to ask the "data vault" for the information for this user
• The information for this user is returned and the form is pre-filled

This is by far the most secure way because it means that information can only be accessed if the person uses a device he/she has used before (where the user has the cookie from) and received a link with the "password" to identify him/her.

The multi-platform challenge

We understand you all use a range of different tools. Impact Stack is just one of them.

That's why we've built the form pre-filling in a way it works for a lot of different scenarios and setups. You can also use the JavaScript and extend it in any way you see fit. You can add new sources that bring information to Impact Stack and you can use the JavaScript on your main website.

If you need help setting this up or you'd like to discuss how it can be developed further feel free to reach out.