Pre-filled forms - some thoughts on good practice

Pre-filling your supporter's key details into an action or donation form can massively increase response rates, but can you manage this and protect supporter data?

There's no doubt that helping your supporters along by pre-populating form fields for them will give your response rates a boost. See the 'Three Stories' case studies presentation on the Engaging Networks site for details of how Greenpeace saw a 400% increase in the number of people donating after taking a campaign action when the donation form had basic data pre-filled.

But a few words of caution from ECF list members:

Take care the data can't be forwarded 

“But an action email is different: there's no reason the recipient would imagine that the innocuous 'take action' link contains personal data, certainly beyond name and email which is naturally expected to be part of any forwarded email. They're going to get a shock when they press the 'forward' button in their email client and everyone on the receiving end sees some scary data when they go on to take action from it.

"I think there's a strong argument that the place for anything beyond name and email address data is in a battle-hardened web app where authentication can be managed more completely."

Make sure you don't record personal data unintentionally

"If you're pre-populating via the URL like so: http://example.com/?name=bob&postcode=etc Make sure you filter those personal detail parameters out of your web analytics pageviews data. Recording personally identifiable user data via Google Analytics is a breach of their T&Cs and you wouldn't want to loose your data over something like this. 

"This is easy to do in Google Analytics: under "Profile Settings" there's a field for "Exclude URL Query Parameters".

One way... 

"If you want to do that at all, and I'd give it careful consideration (ie don't), then have it saved in a long lived and encrypted cookie in the browser when a first action is taken, and then only encode the decryption key in the email (which looks like a session ID). That means that people don't have to type repeatedly into the same browser, but they can also forward the link (because the decryption wont work for someone else). If either half is missing or don't match, then it's not prefilled (and can be saved for next time).

"It also puts the security decision in the hands of the browser (ie what's the max length of cookie), without storing trusted content client side (if it's changed, then the decryption wont work)."

… and another

“I might favour not putting personal details in the url, but instead a user id, something to identify the command, and an authentication hash.

"This means your server can then 

1.make sure the link authenticates - could check against a cookie too as Sam suggested, could be time-limited as someone else mentioned. 

2.if unauth'ed they could be redirected to the action page un-pre-filled. (server can record 'email forwarded' against user's account, if required)

3.if auth'ed, the server can access the personal information required for prefill and issue a redirect with info in. 

4.Server can record any user-clicked-link-in-email information if needed. 

It also means the URL stays (relatively) short, which makes it a bit more hardy over email.”

This article summarises a discussion on the eCampaigning Forum email list. Thanks to everyone who contributed.

by ECF Discussion Summaries published Jun 13, 2012,
Filed under: , , ,