Contest hosts want to maximize the number of times a person can vote.  If you do not wish to have users log in to vote, they can vote repeatedly.  Although this can translate into page views, more and more UIs are moving to a stationary experience, where pages are more dynamic and don’t require page refreshes.  In order to prevent people from just hacking away at it, or writing scripts to vote automatically, we always require a captcha.  Why not just disable the vote button and set a session cookie?  This is unreliable because some users (like my paranoid dad) have cookies disabled for various reasons.  This means some people will never know that they are not meant to have unlimited votes.

There are a number of options for a voting process if you require the person to log in.  Our system is able to attribute votes to a logged-in user and hence regulate the frequency of voting ie. voting once per day, once per entry, etc… Daily voting generates more engaging page views, as users return repeatedly to complete the experience (however short!).

The main problem with having people log in to vote, is that they have to register. Registration pages are notoriously bouncy: people hit them and split.

This is a good primer on bounce and exit rates.

Long site registration forms can be the touch of death, but there are ways to minimize the bounciness with shorter forms and potentially, services like Facebook Connect, Google Friend Connect,  and other single sign-on systems.

A two-step process would make it easier for a person to engage the site and as a result, lower the bounce rate on that page. The first step is a fast and simple, one-click register experience.  Once a person is logged in, he can vote and comment. He has a display name, an avatar, and all the fixins.  You can see this happening on this very blog using Facebook Connect.

If the person wishes to submit an entry to the contest, we need some more information.  Another form is presented to them, asking for name, address, etc… At this point, we would not require a captcha.

In the case where a 3rd party identity isn’t used, users must at least enter a password and confirm their email in order to participate.

Here are some ways people try to log fraudulent votes, and what to do about it:

1) A cheater can register repeatedly with phoney email addresses, and basically get unlimited votes. Without centralized identity, we can mitigate this by sending activation emails (yuk). The alternative is the contest host being prepared to manually search a vote log xls file and disqualify votes.

2) The cheating bastard could write a script to break your captcha and vote like crazy, automatically. A good programmer can use a combination of OCR software and other methods to read and crack a captcha. A better captcha makes this possible for only the more rare wily hacker. At that point, we can usually detect a crazy number of vote requests coming in via IP address. The user is denied access, and we can determine an estimated number of fraudulent votes.

3) The best fail safe is to simply reserve the right, in the rules, to use discretion in selecting a winner. If some jerk does manage to cheat, turf him.

I think voting is fun and effective for UGC contests.  If publishers and sponsors take the appropriate care, ensure a reasonable user experience, and allow discretion in the rules and regulations, voting can contribute greatly to the success of the project.