Accessing Historical Sanook Lottery Data
I spent about three weeks last year building a simple scraper that pulled every Sanook lottery result going back to 2018. The goal was just to have a local copy of the archives so I could run frequency analysis without depending on their live site. What I found was not encouraging, but at least the data was clean. Sanook has a lottery results section that publishes Thai government lottery drawings twice a month — the 1st and the 16th of each month. The archive page itself is thin. It shows recent draws and links backward in roughly three-month chunks. There is no bulk download, no API, no CSV export. If you want more than the last six months, you have to go looking for it or pull it yourself. Here is how I handled it. I wrote a Python script using requests and BeautifulSoup that iterated through the archive URLs, grabbed the table rows for each draw date, and saved everything to a SQLite database. The key fields were the date, the first-prize six-digit number, the front three digits, the back three digits, and the second through fifth prize numbers. I ran it once a month to stay current. A full historical pull from 2018 to present took about forty minutes on a normal connection. The site sometimes returns incomplete tables on mobile user-agent strings, so I forced a desktop header and that fixed most of the missing-row issues.
What the data actually shows
Once the data is in a database, basic frequency analysis is straightforward. I ran digit frequency across all positions, position-specific frequency, pair frequency, and gap analysis between repeated numbers. Here is the boring part: lottery draws are designed to be independent random events. The Thai government lottery uses mechanical drawing machines, and the published results match that model closely enough that any "pattern" you find is almost certainly noise. That does not mean analyzing the archive is useless. It is useful for understanding what randomness looks like when you have enough samples. In my database of roughly 240 draws, the digit distribution across all positions was within 3% of uniform. No digit was meaningfully over or underrepresented. The back-three-digit sequence showed the same behavior. This is exactly what you would expect, and it tells you nothing about future draws.
Common approaches people try
Most pattern-seekers focus on three things. Hot and cold numbers, repeated sequences, and position bias. Hot and cold is the easiest to calculate and the least useful. A digit appearing seven times in the back-three position over two years is not significant. The standard deviation on a uniform distribution with that sample size is wide enough that normal fluctuation explains it completely. Repeated sequences get more traction because they feel intuitive. If the number 123456 appeared, then 234567 appeared six months later, some people treat that as a signal. It is not. The chance of any specific six-digit combination appearing in a given draw is 1 in a million. Over 240 draws, you should expect roughly 0.00024 occurrences of any specific combination. You will not see repeats. If you do, it is either a different prize tier or coincidence. Position bias is the only analysis that occasionally surfaces something marginally worth noting. Some players track whether certain digits favor the front versus the back of the first prize. In my data, there was no persistent bias. Any small deviation I observed disappeared when I expanded the sample window from two years to three. That is the problem with low-sample anomalies in lottery data — they look real until they do not.
Get the Full Details
A real edge case I ran into
One issue that almost cost me two weeks of clean data was date alignment. Sanook sometimes lists a draw date as the evening of the 16th even though the actual drawing happens in the morning. Their archive page titles use the date the results are posted, not the date the draw occurred. If you are matching historical results against official government records, this causes mismatches. My workaround was to cross-reference every Sanook entry against the Royal Thai Government Gazette lottery results page, which lists the exact draw date. I built a simple reconciliation script that flagged any row where the Sanook date differed from the Gazette date by more than one day. About 8% of entries had this discrepancy. I used the Gazette date as the source of truth and kept the Sanook numbers since their digit values matched perfectly. You do not need to build a scraper if you do not want to. Several third-party sites mirror Sanook lottery data, and some offer CSV or JSON exports. The trade-off is data freshness and accuracy. Mirrored sources often lag by a few days and occasionally contain transcription errors. If you go the scraper route, your main risks are site layout changes and rate limiting. Sanook does not aggressively block scrapers, but adding a random delay between requests of two to five seconds keeps you in safe territory. For the database, SQLite is sufficient. You are not dealing with millions of rows. A simple schema with columns for draw_date, first_prize, front_three, back_three, and prize_tiers up to five covers everything most analysts need. Index the draw_date column and you can run date-range queries instantly.
What this cannot do
I want to be explicit about this because it saves people a lot of money. Analyzing past Sanook lottery results cannot predict future winning numbers. No pattern in the data has predictive value. The draws are mechanically randomized, each event is independent, and the house structure of the Thai government lottery means the expected value of any ticket is negative regardless of what strategy you apply. This is not a limitation of the archive or the analysis method. It is a feature of how lotteries work. There are legitimate reasons to study historical data. You can learn about probability distributions. You can verify that a lottery is functioning as intended. You can build a personal record that is faster to query than browsing a webpage. What you cannot do is derive a winning system from it. Any claim otherwise is mathematically incorrect.
Practical workflow
My monthly routine takes about twenty minutes. I run the scraper, import new rows into SQLite, execute a frequency query, and compare the output against the previous month to check for drift. The drift is always negligible. The whole process is more useful as a discipline exercise than as a prediction tool. It keeps you grounded in what the data actually says rather than what you hope it says.
