Prize winning tickets and probability...

[shellgrip]

Hello! I'm a web programmer and have been commissioned to develop a simple site that accepts a 'ticket number' and then tells the visitor instantly whether they have won a prize or not. What seemed originally like a simple problem has, under further thought, proven to be nothing of the sort and I need expert help.

 

The problem is largely that of ensuring that the prize allocation is fair, logical, and evenly distributed. This aim is complicated by the following factors: The competition is based upon physically received leaflets following a visit to a store. The competition will run for three months or thereabouts. The number of prizes is very small in comparison to the number of entries.

 

What all this means is that I cannot simply use a 'random number' device to decide upon a winner. Doing so presents a finite possibility that all the prizes will be won in the first week or that none are won at all. Neither can we limit prize winning based upon those already won (we can't say a prize has been won this week so no one can win now until at least Monday morning) as this would be demonstrably unfair.

 

My current thinking is that the best solution is to perform some kind of operation on all, or part, of the 'ticket code' (the structure of which is entirely up to me) such that there is a specific probability of winning for any ticket, which matches the number of prizes and the anticipated entrants. So, for example, if there are 10 prizes and 10,000 entrants, I want the operation to result in a probability of 1 in 1000 that this ticket is a winner. The operation must work on all ticket numbers so that every one has the same chance of winning and should preferably, be somewhat flexible such that if, as the competition progresses, it becomes obvious that we're not going to get 10,000 entrants but only 6,000, or 20,000, that the odds will automatically alter.

 

To introduce a truly 'random' element into the selection process I'm considering using the time of entry as part of the operation.

 

Although I've got this far in the thought, I'm afraid the actual math is beyond me - I think. Can anyone help with what I should be doing here, or suggest an alternative approach? My need has become rather urgent as the customer is itching to start printing the leaflets and I haven't got a code structure to give them yet!

 

Jon

[Bignose]

How about accepting n entries, then hold the drawing every Sunday evening where the odds of each ticket winning a prize is 1/n based on how many entries there were in the previous week?

 

The only other option, is, as you said, to have each code associated with a prize.

 

Most places do it one of those two ways. They are simple to program/understand and usually considered pretty fair. The problem with a changing probability is that not everyone will be given the same chance.

 

As an alternative, you could just set up the system so that every 10,000th entry is a winner, and of course, you wouldn't publish what number the counter is on. The first one should be some random number between 1 and 10,000... say 4,823. But, then make the next winner the 14,823rd person to enter a code, then the 24,823rd, etc. Just set up frequencies for all the prizes like that, and it will be effectively random since none of the people entering the contest will know where in the chain you are.

[shellgrip]

Hi Bignose, thanks for the reply.

 

IF the client decides they're happy with a 'delayed' draw then doing it that way is certainly a lot easier, it's just that at the moment they're saying they want it to be an 'instant' notification: you type the code in, press submit and are told straight away whether you've won or not.

 

I like the 10,000th entry idea - I'll admit that's something that completely slipped by me and it's a good one. The only problem is of course that 9,999 people simply cannot win after a prize is awarded but I guess the 'luck' factor there is in where you are in the counter when YOU choose to enter the comp.

 

At the moment we're leaning towards pre-selection. I'm going to generate all the numbers to be used in the comp (using various checksums, etc. to prevent random entries) so it's a simple task to pick X winners from that list. My only problem here is that I'll know which are winning tickets (including the code to type in) or could fake a win. I guess that's something that applies to lots of online comps though.

 

Thanks again, any more ideas, suggestions, keep 'em coming

 

Jon

[Willa]

How about this:

 

If there are X prizes available, generate X random date/times within the duration of the competition. So for example:

 

2:03:08 p.m. on 8/27/08

4:11:58 p.m. on 9/1/08

etc.

 

These would be generated beforehand (though not necessarily known by you) and stored by the program. Then the winner of each prize would be the first person who buys a ticket after each "winning time."

 

 

The flaw with this would be that some times of day would be much busier than others, so somebody who knows the algorithm could possibly gain an advantage. With such a small number of prizes, though, it might not make much of a difference.

[shellgrip]

Hi Willa,

 

We've ended up going with a frequency based approach described by Bignose. What we'll do is analyse the number of entries against the expected number of entries and the number of prizes. So, if after 8 days of a 100 day competition there have been 500 entries, we estimate a total number of entries of 6250 and with 10 prizes that means a prize every 625 entries.

 

I think, in theory, this should be 'self-adjusting' which we'll need since we can't accurately (or even approximately to be honest) know how many entries there'll be.

 

Your suggestion is equally valid, I think, although I'd still be concerned that this might end up with all the prizes in a bunch. Plus, of course, since these dates would need to be stored somewhere the administrators would be able to find them. Since that's only really me, that's not a problem but I prefer the idea that even I won't know exactly when a prize will be awarded.

 

My next step (today hopefully) is to code a test routine to ensure my code for the frequency system works...

 

Thanks for the response and the suggestion. If the frequency route doesn't work it may still be the way we do it!!

 

Jon