For data teams, an online prize draw is a practical example of event processing and data governance. Paid and free entry feeds need stable identities and consistent eligibility records, so a reviewer can trace the selected ticket back to the exact pool used.
- Give each entry an identity
- Record enough to explain each decision
- Reconcile incoming records before closing the pool
- Freeze the pool and preserve evidence of that freeze
- Keep the selection receipt with the winner mapping
- Control access and retain a correction history
- Make the data rules match the promotion
- Hand over a bundle someone else can inspect
- Frequently asked questions
Suppose one customer holds three valid tickets, but a repeated webhook creates four rows. An idempotent ingestion step can prevent that duplicate. Versioned entry records make later corrections traceable. Build those controls before freezing the entry pool, then keep the selection evidence with it.
A prize draw audit trail is a data-governance record linking eligible entries to their rules, frozen pool and saved selection result. Give tickets stable identities, reconcile incoming events, and preserve the exact pool used for selection. Keep the receipt and winner mapping together so a reviewer can follow the decision through to prize delivery.
- Deduplicate repeated event deliveries while preserving separate tickets allowed by the published rules.
- Freeze a versioned entry snapshot and document exclusions before selecting a winner.
- Verify the saved random result against its receipt and entry mapping; a fresh draw produces new evidence.
Give each entry an identity
Consider an online prize draw with paid entries through a website and free entries recorded from another permitted route. Both feeds reach the same entry register. Keeping the route on each record helps you reconcile the feeds; it should not give one route a different winning weight.
In this proposed design, a participant reference identifies the person and an entry ID identifies a ticket. Someone holding three valid tickets has three entry IDs. Removing rows just because the participant reference repeats would erase legitimate entries.
Suppose event evt_204 creates ticket entry_731. The sender retries after a timeout. Your handler recognises the event ID and records the repeated delivery without creating another ticket. These identifiers are illustrative. A single event may also contain several tickets, so save the relationship between the event and each entry it creates.
Scope the event key to its source if different systems can issue the same ID. PostgreSQL’s constraint documentation explains how unique constraints cover individual columns or combinations. A unique source-and-event key can support this design. Apply that uniqueness rule to the event ledger; each ticket keeps its own entry ID. A one-person-per-draw constraint would impose a different business rule.
Record enough to explain each decision
The following fields are a proposed entry record, not a regulator-prescribed schema. Keep a versioned copy of the published terms alongside it, including eligibility, entry limits, closing rules and prize delivery arrangements.
| Field | What it records |
|---|---|
entry_id | Stable identity of one ticket, retained through corrections. |
draw_id | The draw this ticket belongs to. |
participant_ref | Pseudonymous reference linked to separately restricted contact details. |
entry_route | Origin of the entry, used to reconcile incoming records. |
source_event_id | Incoming event reference, with its source namespace. |
received_at | Recorded receipt time and timezone, with evidence appropriate to the route. |
eligibility_status | Pending, accepted or excluded, linked to the decision reason. |
rule_version | The published rules used to assess the entry. |
payment_ref | Nullable transaction reference where payment applies. |
correction_event_refs | Links to corrections recording the previous value, reason and responsible actor. |
Keep processing time separately. A record entered by staff on Tuesday may describe something received on Monday. The evidence and closing rules determine whether it qualifies; the time of data entry alone cannot settle that question.
Reconcile incoming records before closing the pool
Validate required fields and the draw reference on arrival. Persist the event or its rejection reason before acknowledging receipt, and track failures that need investigation. A rejected event should remain visible to the operator responsible for reconciliation.
Retries are an ordinary integration problem. Stripe’s webhook documentation describes duplicate deliveries and warns that event ordering is not guaranteed. It recommends recording processed event IDs to handle repeats. That delivery behaviour is useful background for ingestion design.
Make recording the event and creating its tickets one atomic operation, or use an equivalent recoverable workflow. Otherwise, a crash between those actions can leave an event marked as processed with no entries attached. Check eligibility and any payment condition against the published rules. A free entry can legitimately have no payment reference.
Reconcile each source against accepted, pending and rejected records. Separate delivery counts from ticket counts, since retries and multi-ticket events make those totals different. Resolve pending decisions before freezing the pool.
For online submissions, use a controlled server receipt time for the closing decision. A browser clock is unsuitable as the authoritative record. Define how delayed notifications and other late arrivals are handled, retain the evidence, and record the decision under the applicable rule version.
Freeze the pool and preserve evidence of that freeze
Export the eligible entries into a saved snapshot. Choose a deterministic ordering, such as sorting by entry ID, and assign each row a selection index. Record the pool version and count, the ordering method, and a hash of the exact saved file. Specify the file format and hash algorithm so another reviewer can check the same bytes.
A database constraint prevents specified invalid writes. An append-only application log records changes through the application. Administrators with wider access may still alter the underlying storage. Timestamps alone do not make either record tamperproof.
A matching hash helps detect a changed file, provided the reviewer has a trusted copy of the original hash. It cannot establish that every eligible entry was included or that the file existed before selection. For independent evidence of timing, you could lodge the pool hash and version with an external reviewer before the draw and retain their dated acknowledgement. Reconciliation still supplies the evidence for completeness.
If you find an error, preserve the earlier snapshot and create a correction record. Explain who authorised the change and which version was used for selection. A correction after selection also needs a documented decision under the published rules; silently replacing the file destroys the history.
Keep the selection receipt with the winner mapping
RANDOM.ORG’s signatures documentation describes how to authenticate saved signed output. Verify the saved response and signature. A fresh request for true randomness samples again; repeating the request does not replay the earlier selection. The signature authenticates the output’s origin and integrity. It does not establish the completeness or eligibility of your entry pool, or show that an operator accepted the first result.
For an integration using the RANDOM.ORG API, retain the actual service response and relevant request settings. In the proposed audit bundle, also record your draw reference, pool version, index range, and version of the method that maps an index to an entry ID. Check that the configured range matches the frozen pool.
Keep the sequence of requests, including failed or abandoned attempts, with reasons for any repeat selection. Restrict who can initiate another call. A reviewer should be able to follow the accepted result to one row in the saved pool and then to the winner record. Keeping only the final successful response leaves earlier attempts unexplained.
Control access and retain a correction history
Give reviewers read access to the audit bundle and limit correction privileges to designated staff. Record changes under individual identities. NIST’s Guide to Computer Security Log Management discusses log integrity, access controls and retention policies. It provides general logging guidance, not prize-draw compliance requirements.
Keep contact and delivery details separately from the selection file. A reviewer checking an index usually needs an entry ID, not a home address. Pseudonymous references may remain linkable to people, and hashing a file neither encrypts its contents nor anonymises them. Set retention and deletion rules against actual business and legal requirements, including unresolved disputes, with responsibility assigned to a named role.
Make the data rules match the promotion
In Great Britain, free draws and skill competitions are distinct arrangements. The Gambling Commission’s guidance explains the conditions for free draws with paid and free routes, including equal promotion and no distinction between routes in prize selection. Skill competitions must meet a substantive skill, judgement or knowledge test; simple multiple-choice questions rarely qualify.
The DCMS Voluntary Code of Good Practice addresses transparency for prize draw operators. It is voluntary, and competitions based solely on skill are outside its stated scope. Keep any commitments your business adopts with its versioned rules.
For a longer commercial explanation, Nera Marketing covers how to run a raffle legally in the UK. Take advice from a solicitor with relevant promotions experience about your specific arrangement and jurisdiction. Data architecture cannot establish that a promotion is lawful.
Hand over a bundle someone else can inspect
Before closing the draw record, check that a reviewer can open these records and follow their references:
- The frozen entry snapshot, count, version, hash and applicable published terms.
- Reconciliation totals, exclusions with reasons, and any correction history.
- The saved selection receipt, settings and sequence of attempts.
- The mapping from the accepted result to the winning entry.
- The prize delivery record, including any unresolved fulfilment issue.
Frequently asked questions
Does a signed random result prove the whole draw was fair?
The signature covers the saved output. Pool reconciliation, eligibility decisions and the request history supply separate evidence about how the draw was conducted.
Can one person have more than one valid entry?
The published rules determine entry limits. Preserve each permitted ticket with its own entry ID. Deduplication should remove repeated ingestion of the same event without deleting distinct valid tickets.
