Pick N combination pools are popular within the racing & sports betting spheres across the world. They’re frequently populated with ’outside money’, creating carryover pools/jackpots, with takeout percentages miles below standard numbers [takeouts as high as 30-40 % are fairly standard for non-carryovers], & in some special cases even generating negative vigs. Due to the excellent liquidity offered by these pools, they naturally become great targets for the high-scale, high-volume informed bettor.

Publicly available tools

In a standard Pick N pool, the following tools/information are available/transmitted to the public/bettors:

- Turnover figures.

- Pool size/carryover numbers.

- Race-level stake distributions.

- Batch betting functionality.

If complemented with,

- An abstract, internal set of ’true’ race-level probability distributions,

a sweet opportunity, at least in theory, to stake [a subset of] the underbet combinations arises.

Limitations

However, to make things more complex there are usually factors that [assuming you’re in possession of perfect fair odds distributions, which in themselves are quite demanding to come up with] increase the difficulty of taking ’proper’ advantage of the pools:

- Combination-level stake distributions/odds not transmitted to the public, rather hidden internally with the pool provider [PMU, TAB, HKJC, etc.].

- Batch betting and/or staking limitations. Rules governing what’s allowed & what’s not, generally meant to restrict sharper high-volume bettors from ’cleaning up completely’.

Approaching those limitations

The second one is trivial to handle. You simply adhere to the relevant rules, and/or, if elite, lighten them up by ’qualifying for special treatments’ from the parimutuel provider/the partner you’re routing your action through.

The first limitation however, the lack of combination-level granularity, is more complicated & requires the construction of a [mental?] model for how to move from what’s publicly available [race-level stake distributions] to what’s of actual interest [combination-level stake distributions]. A given set of combination-level stake distributions maps uniquely to a specific set of race-level distributions, but the reverse does not hold true [a single set of race-level distributions can be explained by many different combination level ones], hence the issue.

A standard, yet kind of naive way of handling this is to assume that the combination-level probabilities can be well approximated by a simple multiplication of the race-level probabilities. I.e. if a specific combination consists of 6 horses all wagered at 20 % of total stakes, this naive computation would yield an expected payoff of 1/0.2^6 = 15625. As you’ll swiftly note in practice, this kind of estimation is frequently *off by quite a margin*, though on average [probably?] correct [many such cases in betting]. The key question becomes: is there an order to the chaos/does there exist a way of accurately modelling/predicting the direction & magnitude of this deviation?

Subscribe now

Representation

Let’s define a discrete function C that takes [a vector of] the N winners [winner of each of the N races] as input, counts what share of the total pool has been wagered on the specified combination, & returns the given share.

As gamblers we don’t get to see C a priori [& after the fact we’re generally limited to observing it only for the winning combination [or well, sometimes for a slightly larger subset, but rarely for the full universe of all possible combinations]], hence the interest in developing an estimation routine that predicts it as well as possible [parimutuel is PvP → no need to arrive at the truth, just make sure to be closer to it than what your counterparties are].

To predict C, we develop a separate routine, X∗, whose sole goal is to return as good of an approximation to C (the true combination-level payoffs) as possible. In order to ’perfect’ this approximation, we use whatever [relevant] parameters are available to us at the time of estimation. This includes but is not limited to measures such as the race-level stake distributions [including changes/deltas in those], any internal/proprietary win probabilities, publicly available information regarding the horses/selections & public/widely known tipster/model figures.

Mapping all of the above information into a reasonable decision framework can, as should be expected, be both difficult & performed in a multitude of ways [your imagination is the only limitation here]. One such route is via the development of a ’similarity measure’ whose purpose is to measure the amount of similarity/correlation between the different winners in any provided combination/Pick N-vector. The thinking goes; the larger the similarity, the higher the likelihood of the combination being *overbet* relative to the naive race-level probabilities estimation.

A similarity measure

Section removed by LL OPSEC dept.

Effects on parallel/standard markets

Significant carryover pools can have quite interesting effects on the remainder of the marketplace.

- Clear incentives to psyop early markets if, on a relative basis, cheap enough to do so [throws off counterparties that are guided by those numbers]. Even non-psyop-maxis are clever enough to understand that they’re heavily *disincentivized* from providing early markets with any kind of insightful information [assuming they’re pushing significant volume into the jackpot pools].

Effect: Inefficient [fixed odds] early markets [& yes, you can ’potentially’ use the late steam in those carryovers to pick off parallel market offers.]

- Extra effort is put into the study of races included in ’carryover sets’ → this in- formation propagates into the closing numbers in exchange, parimutuel & fixed odds markets. Effect: Sharper ’standard markets’ as soon as the large, attractive pools are closed for betting.

Until next time…

33 days ago the Cartoon Horse officially resigned as a Substack writer.

33 days later & he’s back at it.

giving up/exiting the game/leaving the table is a powerful little trick in life. why? it helps you find the way. you quit & get quiet for a while and bam, you know where you are. and where you’re heading.

will never understand the ‘never give up’-crowd & their love for artificial ideas

one of the reasons behind the birth of this blog was to earn some ‘real’, non-gambling money that could enter a company sheet & perhaps, if lucky, help the author larp as an [insert entrepreneurial title] IRL & avoid having to live with the inevitable degenerate gambler limitations in everyday life. one thing led to another & even if the blog itself didn’t print [in fact, ‘twas closer to the inverse], it helped in opening paths to other, more lucrative biz options. today we’re gambling as never before & larping [‘data reseller’ & ‘software provider’] as never before. mission accomplished.

all previous posts have gone from paid → free by the way. happy reading to the poors.

presidential election thoughts

interesting betting market event last week [zero interest in politics, trump’s a chad though].

• presidential election markets are beautiful in that they allow for incredibly deep dives for ‘tism bettors. loads of perspectives & data points to cover and understand, in particular if aiming to trade in-play markets. except for some extraordinary, truly rare events [do happen every now and then], everyday betting is mostly about clicking the same angles over and over again. one-off events such as this one provide an intriguing contrast.

• a combination of the market & a well designed model is probably superior to either of the two alone. make sure you build this 'stacked' model yourself though and avoid having it fed to you by another gambler/modeller

• the change in, & disconnect between, the EC & the popular vote markets, esp at betfair [go ahead and compare the last week of trading or so with the action at polymarket and kalshi], implied a lot of the probability should be put on the 'trump EC, kamala PV' outcomes. the closer to election day, the more the probability mass shifted towards these outcomes. reasonable? i don't think so. max likelihood explanation? bookies laying off trump-action.

• throughout the 'election period' there was a lot of money coming for trump. to think all of it was retarded $'s is in itself kind of retarded. tbh clueless about who potential counterparties were but to think all of it was just degens, arbers & hedgooors is probably wrong. when you don’t know your counterparty you should definitely be scared on average.

• with three large platforms you inevitably observe some interesting stuff by properly tracking them all in parallel.

• an order at platform A is just an arbitrage away from accessing the liquidity at platform B. yes there can be costs involved, but there are not seven or eight different markets. there’s one market, and one only.

• if i find myself laying a horse [trump] in repeated fashion & it ends up winning very, very comfortably, i never assume 'the degenerate counterparty was just lucky'. however, in case it's a runner with tons of predicted 'performance variance', i’m usually not as worried

• in hindsight, everything looks brilliant. & sometimes it is. some conduct private polls in political markets while others [yard enjoyoors] study whether the set of selections they’re about to pick from are erect or not. in both cases it’s hard to quantify the ‘brilliance’ without seeing the full picture.

• public modellers, such as silver, usually get tons of criticism from the gambling community. they’re running a complex & difficult modelling project [clever] but keep blending this piece of the puzzle with straight out retarded comments/statements → i kind of agree with the sentiment.

to succeed in betting markets you need two things. +EV [or well, +ROI] and volume. very simple.

• don’t take bad bets [unless you’re doing it for the sole purpose of learning, then it’s okay]. profitability = running a set of [highly] profitable strategies. if any given bet doesn’t pass the filters of at least one of the strats, it’s not bet. very simple. yes, this means your volume will be terrible until you’ve constructed a set of such strategies.

• +EV can be found literally everywhere. volume is more difficult. before you embark on a 6 month modelling journey, take a proper look at the relevant market & compute a couple of base estimates for what kind of volume it’d be possible to push through this market/strategy. unless it’s scalable, it’s useless. *scalability is king*.

  in particular, if you’re new [& serious about, if you ‘just love modelling’ then go ahead, lol] to this there are good chances you’ll end up wasting tons of time before you notice: ‘ah I’ll never be able to make much out of this angle’.

• dumb edges are good edges. not everything has to be built bill bettor-style.

• modelling provides great assistance in identifying +EV. automation helps a ton in pushing volume. conclusion: learn how to use computers.

  absolutely zero excuses in 2024 with chadgpt on your side. a lot of content on this blog re scraping, bet-botting & data analysis.

• +EV, +ROI is neat, but -EV, +ROI is amazing.

• if you’re 10 % of the volume, ask yourself: why aren’t you 11 % of the volume?

• outsourcing bet placement is necessary to stack up volume. there are two ways to do this: either you work with a bot, or you work with a human. if possible, the robot route is in many cases the most efficient one. but life happens between humans. hence, combine. [work with people, but make sure both parties have something to offer. also, ensure that any sort of deal/partnership yield great returns for everyone involved. things become so much easier when everyone prints [$’s or knowledge]].

you think you can handle variance.

until you experience variance.

racing thoughts

it should come as no surprise for readers of this blog that we’re primarily [financially & emotionally] invested in horse racing markets around here.

the racing scene is made up of three types of ‘matching engines’ [except for citibet [keen on accessing: if you’ve got any recommendations for smooth ways to join the movement, feel free to get in touch] which seems to be built upon an interesting combo between the first two of them. the exchange model, the parimutuel model & fixed odds betting.

in easy-to-beat order:

• fixed odds: the easiest design to beat. you’re essentially up against [especially if betting at open/early] a relatively uninformed market maker [bookmaker] who’s forced to price literally every horse in every race correctly [or well, within the range true price +- their ‘spread’]. sniping these counterparties shouldn’t be too hard if you know what you’re doing.

• exchange markets [betfair]. difficult to beat as the ‘volume-weighted competition’ is very sophisticated, i.e. hard to get matched at good prices with decent size. to your advantage: if you find ways to match against & restrict your action to less informed participants you need not worry about outperforming the sharks. also there are situations where fills pretty much remove information [usually in betting it’s the other way around]. a large block trade occurring between two sharps at a given price doesn’t [mechanically] stop the market from jumping around with the same curiosity it did before the trade took place.

• pools: always competing against the volume-weighted opinions of the rest of the market. fee structures [as in the exchange case] important, if your counterparty is on rebates and you’re not you’re playing a very difficult game. price is uncertain as odds aren’t finalized until the pool closes. certainly see how this both could and should be a huge issue for the recreational gambler, but if you’re trying to operate on a professional level it shouldn’t matter too much?

  most likely the hardest *design* to beat, given a predetermined group of counterparties/competitors. in practice, whether you’ll be profitable or not will of course depend less on the design and more on how your numbers fare against the volume-weighted opinions of the rest of the market.

all for today,

until next time…

BowTiedBettor Products

• BetPicks.

• BetStreams.

Winners Win.

forced content, not so much.

if this is the last post that goes out to my subscribers?

either it is. or it isn’t.

it’s 50/50 really.

at some point, the thoughts might be back in motion.

for now, all subscriptions have been paused [indefinitely].

thank you for your time.

& if you’re a horse racing bettor.

don’t miss out on The Revolution.

see you in the order books & carryover pools.

/Cartoon Horse

Share BowTiedBettor

Ping!

Your Bot just sent an order to the exchange.

Ping!

Bet went unmatched, a competing Bot claimed the offer. Outstanding order removed.

A shame you missed out on it. Well, back at it… Next time you’ll be quicker!

Ping!

A new opportunity! Your Bot just sent another order.

Ping!

Successful match, bet went through.

“Ha, there we go! Easy.”

Peacefully you move on with your life. However, as you check in on the bets a few hours later, you notice an interesting thing: the first bet turned out to be significantly better than the second one.

‘Ah, just variance’, you think. ‘Tomorrow I’ll be back to being Lady Luck’s favourite bettor.’

Not so fast.

What is Adverse Selection?

Adverse selection refers to situations where either you or your counterparty [a bookie, another bettor, the market] possess information [broadly speaking] the other part of the trade is missing and use this informational asymmetry to create advantageous positions, oftentimes in a way that goes past the adversely selected market actor.

More concisely: your counterparty’s willingness to enter a trade/deal/contract with you is negatively related to the true value of the trade [from your perspective]. In a zero-sum game an excellent proposition for you is necessarily a terrible one for your counterparty. Thus, the only real reason for him to trade with you, is that he considers the price a good one & consequently there’s great signal in his desire to enter the deal.

Note: these are *theoretical claims*, there are plenty of players in actual, real-world markets that act on vague ‘yeah I really think this horse will win today’-instincts or simply overestimates their level of sophistication [pseudo-sharps].

Spotting situations where you might potentially be/become a victim of adverse selection can often be difficult due to the subtle nature of the concept. Unlike standard fees/charges ‘adverse selection fees’ aren’t well documented but rather hidden behind game theoretical reasoning and unless you develop a proper understanding of markets, counterparties & what the game and its structure is really all about there’s a good chance you’ll simply fail to notice what’s happening [&, as usual, pay for your lack of knowledge].

To illustrate the many shapes & forms adverse selection may take in betting markets we’ll share and dive into a list of examples we’ve encountered during our time in the world of prediction.

The best trades & why you keep missing them

Any procedure you’ll ever run will consist of several groups of bets:

• -EV bets.

• Slight +EV ones.

• Good bets.

& finally:

• The Excellent Ones.

Your final EV/ROI, what you’ll actually observe, will be a volume-weighted combination of these subsets. The goal is to get enough money on in the last three [two?] categories to make up for the -EV positions you’ll inevitably acquire [no matter how sophisticated your methodology].

Now here’s the problem: in most cases you won’t catch [or even see ;)] the absolute best ones. Why?

A liquid, perfect bet/trade usually match the condition of many different strategies, effectively generating a much larger group of competitors than what you usually observe in your day-to-day action. You can have 10 sharp bettors operating in the same market without too much collision on an everyday basis [they look for different things, bet during different ‘limit periods’ etc.], but whenever an outstanding bet appears on the screen the likelihood of such a collision increases rapidly → all sharps [even average gamblers] enter the same bet → trade gets very crowded → time until the mispricing is taken care of [your opportunity window] goes down dramatically.

Think of a horse race being fully determined by three features. Bettor A successfully trades the first feature, Bettor B the second & Bettor C the third. Along comes a super bet that ticks all boxes, sending signals to all three. Competition up, probability of you being the first to click it down.

On the other hand, what do you think will happen when the next -EV bet [as for the horse racing example, looks profitable if zooming in on feature A but left -EV if including the effect of B & C] pops up? Yep, plenty of time for you to take it!

Result: Easy to invest in the unprofitable subset, significantly harder in the profitable one.

Subscribe now

Autist note: We love to think in distributions. A perfect illustration of adverse selection using probability distributions: imagine plotting your naive expectations [before considering the goals of your counterparties] of how your EV will be distributed over future bets/trades. Let’s say most of the probability mass will be located close to 0.13, your 'long-term EV’, & more or less all of it contained between -0.09 & 0.29. Now, if dropping the naive assumptions of competitors being indifferent towards you winning [i.e. allowing for the strategic aspects of a market with competing actors] you’ll likely observe a shift in the distribution [to the left, negative direction]. Perhaps you may even notice a fatter left tail [trivial to acquire all of the terrible positions], and a smaller right one [miss most of the great opportunities]. This is the effect of adverse selection.

Peer-to-peer: there’s information in you being matched

One of the main homes for adverse selection in gambling markets are P2P markets & a popular phrase illustrating its omnipresence at the exchanges is that ‘you only get filled when you don’t want to’. Due to exchanges’ natural matching of [skilled] individuals with different opinions and/or asymmetric info & their clarity in providing a [often unique and well informed] direct, single counterparty, they become an excellent playground for learning & embracing the concept.

Counterparties in other markets are usually not as explicit [standard sportsbooks rarely actual bookmakers, usually just uninformed copy pasta machines [far from the ‘real’ source behind potentially opposing information] & weighted averages of customers’ insights, parimutuels a volume weighted average of clients/customers opinions], making them somewhat more difficult to break down. On the other hand, the mechanics of the exchange markets make it clear as day that it’s Player A vs Player B.

Note: Often hearing marketing companies [also known as sportsbooks] complain ‘ah, of course we can’t keep taking your action if too much of it is just steam/value vs other shops’. In fact, they’ve even managed to psyop some bettors into agreeing with the statement, lol. Find it pretty funny since these companies’ entire business models [appended with a couple of additional scam products] are built upon the very same concept of moving according to/listening to action at [predominantly] sharper places, baking some extra margin into everything & letting highly uninformed counterparties enjoy these terrible propositions. A bookmaker learns from the market & you applaud him: ‘impressive bookmaking’. A bettor learns from the market & you conclude: ‘parasitic behaviour’. Bookie Derangement Syndrome.

Below we list a couple of exchange market examples where adverse selection plays a huge role.

If you’re planning on becoming an active P2P market participant: best think long & hard about the reasons/models/frameworks behind the opinions & decisions the people you’re being matched against chooses to go with. Well, either that or enjoy being humbled, fren.

Liquifying illiquid markets

The 1v1 aspect of the exchange game is as clear as it gets in early markets, where you generally observe high spreads, low liquidity & low amounts of information.

High spreads & low liquidity may create an illusion of a perfect market to deal/make/provide liquidity to and pick up easy dollars from [quote wide, let the degens pick their favourite soccer teams]. However, in practice, especially at platforms such as Betfair with a bunch of sophisticated actors, you run a real risk of only getting matched on outcomes you’ve quoted incorrectly.

Generally two ways around this:

• Minimal offers only [no one good will care about looking].

• Brutally wide quotes [good traders ignore the market].

However, none of them are fancy solutions since they heavily restrict the amount of money the what-looked-like-a-free-lunch-strategy can generate. Nevertheless better than posting real offers that you’ll just get picked off on [oh, did we just figure out why the early markets were illiquid with huge spreads in the first place?].

To get rid of poor liquidity you need some participants to be able to run profitable strategies, & since the obvious solution here is one that’ll get slaughtered by adverse selection, it shouldn’t come as a surprise that people prefer to wait a bit before ‘posting their thoughts’, especially the ones that are wrapped into more sizeable offers [need higher confidence & the attention of non-professional participants].

Note: If you’re a bookmaker with access to plenty of retard $’s this ‘liquifying illiquid markets’-strategy works perfectly fine, provided you’re actually able to get the sharks out of your pool of bettors. Like being a Betfair market maker with ‘only dumb counterparties’ coded into your Bot. Of course it’ll make money.

Maker meets maker

Trivial. You’re both making a market & thus compete against each other. You post an offer, he posts another one right before you, you continue and on it goes. At one point he stops posting new offers. So you win. Front of the queue! And wow, you just got matched! Great news.

Well, at least until you realise that it was nothing but the very same guy turning around and picking you off as a result of him having sharper fairs & [probably] a passion for psyop.

If there are several makers in your market and you’re posting offers they aren’t interested in competing with, be cautious. Unless you know the reason [e.g. you’re in possession of an excellent fee structure], total silence contains tons of information.

Bettors awaiting sufficient liquidity

Common phenomenon. Several bettors waiting for increased liquidity on the same horse/outcome. If it’s actually a good bet, there will be a quick race for the available offers as liquidity comes in, and you'll only get a fraction of what you'd like to have. If it’s a poor one, you’ll be free to take however much you want. Simple really, good bets move quick & lack a crowd of counterparties, bad bets tend to meet a neverending stream of happy takers.

What will happen in practice [think of having an edge you’re sharing with a few others]:

• Usually: as more liquid players come in they’ll do so at lower & more correct prices. Current price nothing but an illusion.

• Less frequent: liquidity pops up at the current price & there’ll be a brutal race to get it.

Note: Compare with limit increases in fixed odds/standard sportsbook betting. If limits are raised from $250 to $2 000 “to win” at 9AM, you better be quick at taking decisions & clicking buttons if your goal is to get any of the value. [Especially if competitors employ machines for clicking the buttons for them…]

The above relates to another important intersection between adverse selection and betting, bet movements. You'll generally see counterparties move their offers on your action, and if they don't, what do you think that means? Only the naive bettor fails to realise that if you're betting into a ‘hidden wall’ the likelihood of it being a good bet automatically decreases.

If the bet is as ‘perfect’ as you hope it to be, the price *will* move. As an example, perfect bets often a result of an uncertain bookmaker *forced* to take action on an outcome despite insufficient knowledge. Such a counterparty is well aware of their unawareness & will adjust heavily and quickly to your action, especially if you’ve been profiled [rare since your average bookmaker takes three bets then bans your account] and/or deploy decent size.

5-15 secs spinner, then denied or accepted

Ah, the good old spinning wheel after requesting a bet! An excellent example of adverse selection.

So what’s the idea behind the ‘your bet is being processed, please wait‘-spinner? Usually a light ban on the account. Can think of it as a bookie hedge for betting accounts they haven’t confirmed will be profitable, but have great suspicion will [remember false positives are terrible for bookies as their livelihood depends on robbing degenerate problem gambler prospects [no, not how they'll frame it in next week’s ads]].

Your bet is sent to them, they either just put you on hold or 'refer to trader' & what happens in practice is the following: the extra time window induced by the spinning wheel gives your counterparty [the bookie] an opportunity to level up their information levels & in some cases even acquire more info than what you could possible have had at the time of your bet [especially for time-sensitive stuff such as in-play betting/just before post/steam chasing]. Essentially, they're using time to skew the rules against you:

• Deny all bets that seem +EV after a brief analysis of both the event and/or possible market movements. Of course steal the bettor’s information by adjusting your odds accordingly.

• Happily accept the ones that turn out bad/seem to have been a result of a ‘fake’ market move [rapidly reversed].

Imagine being allowed to put up prices on everything with an option to cancel your offers as soon as someone hits them. Then adding an additional 5-15 seconds ‘thought window’ to the already rigged setup.

& STILL losing to some customers.

Bookmakers truly are impressive.

Example I: You place a fixed odds bet ~10 seconds to post on a horse -> 15 secs spinner -> horses jump & your horse is off to a TERRIBLE start [e.g. breaks stride in harness racing] -> bet goes through.

Example II: You place a fixed odds bet ~10 seconds to post on a horse -> 15 secs spinner -> horses jump & your horse is off to a FANTASTIC start -> bet denied, market closed.

You ask for internal logs after being scammed in a similar fashion for the fourth time this year. Referred to customer support, ‘hey there Cartoon sorry you seem to be a bit upset, can’t share that, highly confidential information, any other questions today?’.

Managed to get heaps down?

Note: This point is largely irrelevant for gamblers that aren’t operating at or around max market capacity.

One of the main struggles for a serious bettor is to get liquidity down on favorable opportunities. By design, this *must* be a difficulty problem to solve since building such a position is entirely dependent on another actor taking the other side of the trade. & why would they be fine with that, unless they themselves believe the trade they’re taking is in fact in their favor? Again, there’s [negative] information in the fact you’re finding people to trade good size against you. Generally the more you get on *without a proper reason for it*, the worse the bet. As the ‘without a proper reason for it’-statement suggests, there are exceptions:

• You construct a well-sized bet by betting max limit from 5-10 bookmaker accounts/shops in parallel. In such cases it’s extremely difficult [impossible] for the bookie/s to react until it’s too late. Risk of having all accounts banned of course so not necessarily an optimal kind of execution, that said a Degen Gambler needs some real action every now & then.

• Counterparty [bookmaker/platform/bettor] is stressed & needs to move out of a position.

• Counterparty is closing an outstanding *great* trade & isn’t as careful as usual with the execution of the second leg.

• Most of the sharps are all in on an outcome already & something irregular/unexpected takes place that forces weird price movements.

  Related but not the exact same thing: if you’re betting into a market with max cap $2 500 to win & the intelligent segment of the market ‘empties their limits’ at open, what could this [potentially] mean for price movements taking place later on during the betting period?

• Counterparty is running some sort of marketing campaign that you’ve properly decomposed & built a clever strategy around.

Conclusion: Get heaps down → most likely a bad position. Price moves just as you start building your bet → probably a good position. Again easy to invest in unprofitable ‘assets’, significantly harder in profitable ones. Adverse selection.

An amazing edge? Won’t last long…

Again it all boils down to analyzing what your P&L means for your counterparty’s profits/losses. If you continuously keep robbing a single counterparty on decent dollars day in day out, it won’t be long until it’s well noticed by him/them [and if it isn’t, please start pondering the probability of not being paid at all]. When [not if] it’s noticed, the part of their operation that give rise to the bulk of your profits will be well investigated & likely cut off/heavily adjusted → edge vanishes. This is *by design*.

As mentioned earlier, EV’s/ROI’s are generally generated by volume weighted averages of different strategies/subsets of bets. This is of course just as applicable to your counterparty as it is for you. Hence, your mission is to find & hit such players on subsets they’re grouping with other stuff & empty their pockets at a ‘perfect pace’, i.e. one that makes it well worth it for you but at the same time doesn’t have them perform deep investigative analysis on what’s happening.

A scalable, long-term edge/angle is one that cuts into the profits of *otherwise profitable* operations in subtle ways that are difficult to decipher.

Example: You’ve spotted an incredible ‘manipulation’ opportunity in a certain kind of tote pool. If you go full retard & launch your new strategy by pushing prices 50 % back & forth in a matter of seconds you’re guaranteed to attract unwanted, intelligent attention within a few trades. If instead you handle things responsibly might get away with what you’re doing for quite some time.

Disagreeing with the market? A point estimate is always wrong, but in which direction?

Numbers give you a false sense of security. Behind every number there's a probability distribution. [Why we’ll always keep shilling Bayes].

The more experienced you become, the more you notice the following phenomenon: - whenever you/your model [think of a non-market-based one] disagrees with the market you're always wrong [in terms of the size of the inefficiency] & always in the wrong direction.

I.e. if the market says 0.50, you say 0.60, the distribution [yes, there is one whether you choose to see it or not] around your estimate should 100 % be shifted & skewed towards the market’s estimate.

No better example of this than the below from Benter’s “Computer Based Horse Race Handicapping and Wagering Systems: A Report” paper [read it here].

Wrap up & an explanation of the first part

Now that we’ve handled a good bunch of different examples of adverse selection, it’s time to return to the subject of the initial section of this post, a Betting Bot that’s missing out on certain trades. Recall the situation:

Ping!

Your Bot just sent an order to the exchange.

Ping!

Bet went unmatched, a competing Bot claimed the offer. Outstanding order removed.

A shame you missed out on it. Well, back at it… Next time you’ll be quicker!

Ping!

A new opportunity! Your Bot just sent another order.

Ping!

Successful match, bet went through.

“Ha, there we go! Easy.”

Peacefully you move on with your life but then, as you check in a few hours later, you notice an interesting thing: the first bet turned out to be significantly better than the second.

‘Ah, just variance’, you think. ‘Tomorrow I’ll be back to being Lady Luck’s favourite bettor.’

At this point the issue should stare at you: the reason our Bot is ‘faster’ in some situations isn’t really due to it being particularly fast, but rather a result of the competing Bot being *turned off* for those trades. The other Bot is probably built on better infrastructure [perhaps even backed by more precise/accurate fairs] and therefore quicker than ours, so whenever we actually get a match it’s due to our competitor *actively skipping it*.

& by now I guess we all realise what that means…

All for today.

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Do you have a friend who likes betting and would like to sharpen his/her action? Help them on their path by sharing the BowTiedBettor Substack. Win and help win!

Share BowTiedBettor

Welcome Degen Gambler!

It’s time to enter one of the most dangerous territories in betting markets, the Betfair Exchange.

Since

1. There is a decent barrier to entry [knowledge-wise],

2. It’s one of very few places where you won’t be thrown out for winning a bet or two,

you’ll naturally be up against the creme de la creme of gambling markets. Therefore, tread carefully or get rekt [& poor].

Betfair is peer-to-peer, i.e. every time you get matched on a trade there’s another gambler out there taking the other side of it, much like classic order book action in crypto/stock markets. Compared to the other ‘real’ betting alternative, parimutuels [where everyone places their bets & the odds are calculated at post time], this gambler-to-gambler matching is *a great feature* since it only requires you to beat *one counterparty* as opposed to a complete market [weighted average of many opinions]. Not really a relevant fact in highly liquid instruments [why?] but far from every market is perfectly liquid. Finding one degen is easier than finding a whole army of them [the latter may present a far superior opportunity though].

Now, since we’re on this side of the web we won’t just enter the exchange markets with boring, manual trading.

Instead we’ll utilize one of the great advantages of Betfair, the Betfair API, & code up a Betting Bot that will do the work for us.

For a gentle introduction to the Betfair API, see this post.

So what’s a Betting Bot?

It’s simple, really.

You have *an idea/a potential edge* which [if your plan is to make any money from it] can be converted into A Trade.

With this idea/trade setup, you’ve got two options.

Option Number One: stay at the desk 24/7, scan the markets manually to look for opportunities where you could run The Trade, & then run it if certain conditions/requirements are satisfied.

Option Number Two: map your thoughts/conditions into code & let your computer perform the tasks for you.

Needless to say, Option Number Two is the better option.

Note: We’re assuming you’re in it to *win it* [long-term] here. If you’re only going to place a trade or two on rare one-time events it of course makes no sense to do it programmatically.

But how do we *actually go through* with Option Number Two, i.e. Build & Deploy A [hopefully profitable] Betfair Bot?

Well, that’s what this post will explain.

Note: Our coding/programming material assumes that you have some familiarity with Python. If you don’t, go learn it or be left behind.

Except for Betfair’s guides [takes some time to find the good stuff, but check this site out] there really isn’t much content available on this online. Ran some quick searches & all we could find was a bunch of third-party software begging you to tell them all about your potential edges [our interpretation].

The Process

The Process of Building & Running A Betfair [or really any betting bot] Bot can be split into four phases.

1. Research/idea generation. This is the part where you’re supposed to come up with the potential inefficiency you want to take advantage of. If you’ve never been particularly active in the exchange markets your creativity levels will most likely be terrible at this point. That’s expected: no one invents theorems without studying math, similarly no one invents +EV models/angles without studying the markets. If this is the case for you [brain fog], use this guide solely to set up collection/storage of hard-to-find data & then start analyzing that same data. Might find something…

2. Design. When you’ve discovered and want to begin trading an edge, it’s more than helpful to create proper designs for both the program that will execute your instructions & the exact trading methodology that’ll underpin your strategy.

   • Gathering Information/Updates.

     Will you subscribe to a stream of order book updates & handle them one by one, or rather perform a quick check every five seconds or so [e.g. after some background calculations have been completed]? Maybe a combination where you switch to ‘stream mode’ closer to post time?

   • Integration With Other Systems.

     • At the very least you’ll probably want to call a couple of routines on the Betfair Data you’re receiving from the feeds mentioned above to determine whether you’ll be trading that particular horse/game or not.

     • More advanced users may want to use new updates as input to a more sophisticated model that’ll be called & run repeatedly.

     • Perhaps [most likely] you want to manipulate & write/store the data to a database/in memory, will this be done sequentially within the ‘trading process’ [time between you receive an update & it being fully handled by your trading module goes up] or from a separate, parallel one?

     • If your trading depends on the evolution throughout the last 1 000 updates, where will you store this data? How will you access it? In a proper database? A local JSON file? Keep it in memory [what if the Bot has to be relaunched]? Questions that need to be addressed.

     You either think this part through at this step [before writing a single line of code], or find yourself frustrated & wasting tons of time downstream.

   • Low-Level Trading Decisions.

     • What will your execution look like? Maker/taker orders, or a combination of them? Iceberg/hidden orders to avoid showing your intentions or visible ones [positive for queuing position & getting degen attention to your trades]?

     • How are you going to determine your sizing?

     • Trading in/out of positions repeatedly?

     • Checking for liquidity before sending trades? What if the liquidity disappears while your orders are on their way to the exchange?

     • Will you introduce caps on max exposure/number of trades in a particular market [maybe first & foremost to prevent bugs]?

     • Any other exception handling?

3. Construction. Now that you’ve created a great design for your project, it’s time to actually build it all out. Recommend you do it yourself [or at least that you’re well involved with the coding] but in case you’re uncomfortable with coding/not willing to spend time learning it, it’s of course an option to outsource this part.

   The actual programming will naturally give rise to plenty of implementation details/questions you’ll want to think through properly so in practice most likely to find yourself iterating between (2) & (3).

4. Continuous re-evaluation. The first draft will never be the optimal version of a gambling bot. Optimization is an ongoing process & as the Bot keeps taking trades day in day out you’ll automatically find yourself asking a bunch of questions about its performance, strategy & execution. And adjust accordingly. By continually running this sort of trial & error you get closer & closer to the perfect version of your strategy, until one day you simply deem it good enough & ‘let it run’ [at least until a stupid nerd comes along & starts stealing your trades, heh]. In order to complete this evaluation/optimization stage as efficiently as possible it’ll be necessary to log & store everything that has even the slightest chance of providing answers to future, often yet unknown, questions [just log it all]. Two examples:

   • Bet Logging. Hard to improve a ‘betting system’ without proper logging of the bets/trades/positions it’s taking. Many ideas that ‘should work’ actually do when sufficiently constrained, but people never find out because they group them with other -EV bets & end up never seeing the difference.

   • ‘Action’ logging. When the Bot performs any action whatsoever [e.g. sends a trade to the exchange], you log it & store it for future [error?] analysis. Simple as that. Aim to surveil the Bot like a bank would do a bettor & you’ll be good to go.

   Champions adjust.

The overall concept & a clear, precise process of how to make the transition from a vague idea to a complete, proper implementation has now been defined.

With the recipe laid out in front of us, it’s time to cook up a [the best?] Betting Bot.

Code repository available here. As usual recommended to move back & forth between text and code to make sure you’re actually following while reading.

(1) Research/Idea Generation

Repeatedly been shilling the importance of staying up-to-date on the *exact* rules/features of the platforms/exchanges you’re using. Whether it’s sports, crypto or tradfi doesn’t matter. Why?

• The ‘fun stuff’ is what keeps the people excited & their dopamine levels high → no one takes the time to actually read through the rules/docs *properly*. The crowd prefers pure guessing & yelling ‘SCAM’ as they’re caught by surprise when a market is settled according to the rules, but against their ‘logic’. Conclusion: If you’re one of the few who’ve studied the design of the game diligently beforehand, you’ll be taking their money when this happens.

• Larger players are in many cases constrained and/or incentivized in different ways by such rules & consequently forced to adjust their action. You’re much more likely to understand how & why certain things [will] play out if you can put yourself in the perspective of a main market participant and think about his/her optimal strategies under different setups/conditions.

Example: Free sizing is an important ingredient for improved market efficiency since [in general/on average] high stakes gamblers possess higher value opinions. Now what if the max stake per ID/account in the ‘should be highly efficient’ parimutuel pool is capped at ~1/1000 of the total pool size?

Really doesn’t take much time & thinking to either create new edges and/or improve/increase confidence in existing ones by integrating ‘rule-inspired’ ideas.

To illustrate the advantage of staying up to date on new features, we’ll have today’s Betting Bot targeted at a fairly recent addition to the Betfair website/UI, the ‘Betfair Price Beacons’.

No, don’t believe this will be a money making machine [or it wouldn’t be shared here]. Hopefully slightly more interesting than your average tutorial though.

[Haven’t checked potential profitability so in case you appreciate the angle & spend some time sharpening it might earn a dollar or two ;).]

Beacons FAQ.

The Idea we’ll be trading is the following:

Traders trust trends & enjoy catching on to larger price moves. The new ‘Beacon Feature’ makes it easier for manual traders to do so. Therefore, if we position ourselves in front of them & have our orders meet theirs just as the thresholds of the beacons have been passed, we’re more likely than usual to get matched at a price of our choice.

(2) Design

As with business ideas, coming up with something that *potentially could be a clever trade* is easy, while the implementation & the conversion of thoughts into money is the difficult part.

Side Note: Obvious ideas will get you into crowded trades. Yes, in theory [perhaps even in backtests] they might work out well but in practice you’ll always see a quicker/smarter nerd come along & pick the profits up in front of you. Solution: either become that nerd [hard] or develop more sophisticated angles [again hard].

Before we proceed with construction we’ll have to define & clarify exactly how our thesis is supposed to be transformed into real world $’s.

Recall the idea.

Traders trust trends & enjoy catching on to larger price moves. The new ‘Beacon Feature’ makes it easier for manual traders to do so. Therefore, if we position ourselves in front of them & have our orders meet theirs just as the thresholds of the beacons have been passed, we’re more likely than usual to get matched at a price of our choice.

Trading Methodology

• *Manual traders* are mentioned [find it hard to believe bots will be influenced by the emojis, but who knows]. Which markets have high manual activity & when are those manual gamblers active? Honestly don’t know → we’ll just run the strategy 24/7 on all UK races for now & see what happens.

• The anchor price [from which the 7.5 % drop/drift is determined] will be crucial to get right, as everything depends upon it. It’ll be necessary to construct a get_anchor_price routine that when fed a horse/a runner book [or possibly a sequence of them] returns the correct anchor price for the selection.

• A reasonable execution of this trade should be the following [we’ll handle the dropping odds/steamer case here, equivalent for drifters but in the opposite direction]:

  1. Compute both the anchor & threshold prices [7.5 % below the anchor price].

  2. Analyze the order book around the threshold price & add lay orders within a few ticks of the threshold price.

     What’a few ticks? 1? 10? There’s a tradeoff between likelihood of being matched & profit size per successful trade to consider here.

  3. Whenever a price trends towards the threshold price, add extra pressure with a bunch of back orders to push the price past the threshold point & have the manual traders pile in to back it.

     Note that the ‘Betfair Beacon’ [the information symbol] will disappear if the price reverses & crosses the 7.5 % line again. Might make sense to move our trade one or two [or more] ticks to the left.

  EXAMPLE: Jumeira Vision trades at ~4.50-4.60 with an anchor price of 4.70 [threshold price of 4.3475]. We’ll prepare for a potential trade by adding lay orders at 4.20 & 4.10 [want decent queuing positions]. As the ‘best available back price’ transitions to 4.30, we’ll back it & thus have the symbol ‘turned on’. If our thesis is correct, backers will come in & join the steam [more precisely we, on average, hope to see ‘more backers than layers’ under this setup].

  4. Include additional order book checks to avoid taking the back side on horses with a wall of lay orders before ours [unlikely to be matched on the second leg of the trade].

Bot Design

• Our Bot will be built in Flumine → won’t have to worry too much about the communication with the Betfair Engine/Servers, Flumine takes care of this for us.

• We’ll connect to a Betfair data stream which pushes all order book updates. As an update comes along, we’ll run our trading logic on it & process/add/remove orders + store relevant parts of the data for analysis/logging purposes.

• At the completion of a trade [back & lay orders fully matched], we’ll log it in a local file & possibly send information about it via Email/Telegram or any other notification service.

• The infrastructure for the Bot will consist of three main parts/mini-modules:

  • Trading & Help Routines: Necessary and/or helpful functions (for instance get_anchor_price for a given horse/object, send_to_telegram for notifications… ). Called while processing order book updates and/or orders from within the Strategy discussed below.

  • Strategy: Defines our Strategy/Trade Idea as a Python Class. Methods such as check_market_book, process_market_book, process_orders. Uses functions from the Trading & Help Routines to beautify & readify the code.

  • Trading Instance/Execution Program: Responsible for defining trading parameters, launching the Flumine Instance & feeding it our Strategy.

(3) Construction

At this point our idea has been well defined & the design completed.

Thus, it’s time to dive into the code.

We’ll only comment on the most important aspects here & let you investigate the implementation for yourself over at Github.

Quick overview of Flumine specifics [bot.py file]:

1. At initialization, the Flumine Framework/Trading Bot is basically ‘naked’, it sits there & awaits further instructions.

2. Next we equip it with the most basic information: login details + which events/races to ‘listen to’ [receive updates from]. Bot completes the stream listening part by setting up subscriptions to the relevant Betfair Order Book Feeds [the markets matching your criteria/filter], essentially sends a ‘hey set me up for these races’-request to Betfair.

3. We then add strategies [implemented as Python Classes] to it. In our case we only run one [BetfairBeacons] but there’s nothing stopping you from running a bunch of them. When receiving new updates, the Bot will simply redirect/forward the content to each one of your strategies & run them more or less in parallel [well, we skip the ‘tism details here].

4. Finally we adjust the Trading Controls & [possibly] add custom Background Workers.

   Trading Controls are hard stops that prevent the Bot from executing certain transactions. Example: StrategyExposure checks that orders doesn’t invalidate max caps [that you’ve determined yourself] on order size & total selection exposure [how much is risked on a given horse].

   Background Workers are code routines that are being run in the background to keep everything clean & up-to-date and/or handle ‘outside tasks’.

   Example I: Every 45 seconds, update numbers/parameters by fetching & manipulating data from a third-party source.

   Example II: If more than 30 seconds has passed since the last race of the day went In-Play, terminate the Bot.

For more information on the inner workings of Flumine, check the docs.

The lowest level parts of the implementation were left undone, would simply take too much time for no return at all. Brief comments on what needs to be done for the Trading Bot to be 100 % ready for deployment:

• Implementation of the update_anchor_prices routine [tradingroutines.py file]. Seems like it will be enough to hold the latest version of each RunnerBook [Order Book for a runner] in memory & compare the traded runner volume between version N & version (N+1). Whenever it crosses the required volume for the given odds range (i.e. traded selection volume at time N is below the Betfair threshold, volume at (N+1) above), the anchor price has been determined. Add the selectionId & the anchor price as a key-value pair & return the updated dictionary.

  

• Exact trading logic. Probably best implemented completely within the process_market_book method [strategies.py file]. Whenever a new anchor price is determined, initialize a Trade for the selection. Then at each new stream update you may want to calibrate/adjust this Trade with new orders/removal of orders & so on. Tons of freedom here and there’s really no correct way to do this.

  Note that you’ll need to consider precise Betfair Order Rules [price, order size etc.] to avoid getting a bunch of violations.

(4) Continuous Re-evaluation

This is where the trial & error begins. Now that the Bot is launched and up and running on the exchange, we’ll of course be interested in monitoring, analyzing and improving its performance. Different strategies give rise to different analysis and for our specific trading strategy it may be beneficial to put some extra emphasis on questions such as:

• Given the first leg of the trade, what percentage of the time is the next leg matched on the correct/wrong side of it?

• Would the performance be improved if we moved the whole trade/parts of it two ticks to the left/right? Don’t just try 1 000 angles here & go with the one that fits your data best, statistical common sense [Bayesian Thinking] still applies.

• What percentage of the size of the second leg do we tend to get matched on when we get matched? If ~100 %, increase size. If less, reduce size?

• Given the price crossing our threshold price, what does the price distribution look like over the next 1/5/10/15 minutes?

***ALWAYS PLOT EVERYTHING***

Then, given answers, we adjust the code and deploy GamblingBot v2.

& repeat.

Iteration yields magic.

Always Be Iterating.

Summary & general BowTiedBettor notes

Turned into one of our longer posts, we hope you enjoyed the read. More Betfair content will be shared but might take some time since most of our subscribers are US based & don’t have access.

Note I: Prophet Exchange is available in NJ & appears to offer all their customers API access. If in NJ, give it a try. Never checked it out so no clue about liquidity/spreads etc., feel free to share any findings.

Note II: With a high-gambling-volume election coming up we wouldn’t be too surprised if we could invent a post or two that could spur some American curiosity.

Feel free to use the Comments section [& the Discord] as much as you please if you found today’s content interesting & feel like getting to work.

General BowTiedBettor notes:

• Currently working on a ‘The Path To $100 000 in Betting Profits’-post. Will lay out the most efficient route to make a decent chunk out of gambling markets *without* having to devote your life to it. Includes [of course] but not limited to bonus rugging. Can think of it as a one-time-robbery. When you’re done you’re *done* [won’t be any easy money left for you to collect]. Stay toon’d!

• Our promise of ‘high volume streams of top quality bets’ at the launch of BowTied BetPicks has been kept very well so far.

  • UK Horse Racing Channel is averaging ~50 bets per day, ROI ~20 %.

  • US Sports Channel at ~70 bets per day with a ~8 % ROI.

  Note: Real, practical figures probably slightly lower since bets arrive while you sleep and/or live life [affects volume] + a subset of them are hard to catch at the logged price but still offer value at the tick [or ticks] below [affects ROI].

  Personal BetPicks bets [currently have two guys tailing as much of the action as possible ;)] has generated a 17 % ROI over ~1 300 bets for the horses & a 9 % ROI over ~750 bets for sports.

Think that’s all for today.

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Degen Gambler!

Today it’s time for an exhaustive overview of odds moves in betting markets & as you’ll notice along the way there’s *a lot* to say about them.

There’s somewhat of a division into two camps within the betting community: steam chasers [with the standard angle being: check odds at Pinnacle & look for/chase large deviations at soft books] & anti-steam chasers/’originators’.

Quick Explanation: “Chasing Steam” is a strategy where a bettor can move quickly to get down a wager at a slower sportsbook that has yet to change their line with the rest of the market.

Weird ideas prosper in both groups.

A subset of the steam chasers, especially the newer ones, think chasing steam is the only ‘mathematically sound’ way to make money from betting markets. If they can’t see clear value against the rest of the market, there cannot be +EV involved. Delusional.

On the other hand, the ‘originators’ [meme term since >80 % are just memorizing [either manually or by use of computers] what the market has revealed to them before, not much ‘originality’ in doing that] have transcended the steam chasing stage and instead transitioned into the art of dunking on the chasers. Strange phenomenon as they’d probably increase their profits quite a bit by paying more [automated] attention to what’s happening in the marketplace during game/racedays. Many cases where it makes sense to listen to what other ‘originators’ are trying to tell you.

The reality? As usual the whole is greater than the sum of its parts.

Tracking moves at sharp books/exchanges to beat soft books can be a clever way to increase volume early on in your ‘betting career’, but as you get thrown out by sportsbook after sportsbook the game changes & you’ll at some point have to build/come up with something more sophisticated.

On the other hand, efficient extraction of information by tracking market moves will always be an excellent complement to a fundamental model [if you disagree/are doubtful you’ve probably never *really* tried it out], so why not spend some time trying to figure this part of the game out as early as possible?

Note I: This isn’t going to be another *boring* ‘how to chase steam’-post. If you’re looking for that stuff please ask ChatGPT or visit any of the hundreds SEO-maxxing/affiliate gambling websites. We’ll try to keep our content on a somewhat more interesting level, heh.

Note II: A hidden advantage of tracking as much as possible in the marketplace is that you occasionally stumble upon fairly lucrative edges ‘by chance’. Relates to another concept: how to look for an edge in a given market. Don't just sit there & observe the market manually like a [redacted]. Track *all* the info within the marketplace for a few months, store it, then do some heavy analysis with a million plots & see what you find.

Reasons to track odds moves & things to be aware of

A couple of reasons for why it might make sense to track what’s happening to prices/liquidity/volume throughout a day.

1. Using a highly liquid ‘source’ to beat lower liquidity markets. Example: Using Betfair Horse Racing prices to take advantage of inefficient Quaddie Jackpot Pools in Australia. A quadrella bet, affectionately known as the quaddie, is a bet where your objective is to select the winner of four consecutive races. Exotic bets such as the Quaddie usually attract a decent amount of -EV bettors [small chance to win huge] & when pools are enlarged with ‘Jackpot’-money there are times where those exotics present opportunities with even negative track takes [no *need* for negative track takes, usually it lets you increase your sizing quite dramatically though]. Combine a positive sum game with a crowd of clueless gamblers & you know what that means.

   Note: We don’t know anything about Quaddies & have never bet them so might not be as lucrative as indicated. However, speaking from similar experiences: we’d at least have a look!

   What’s *very important* with this strategy of using highly liquid markets to beat less liquid/dumber ones is to verify that your source [Betfair in this case] really is a source:

   • It must have a significantly larger handle than any other platform [or combination of platforms] that’s making markets on the same events and/or [even more important] learning from the source. If the turnover in the Quaddie Pool is 10X the early Betfair Liquidity & every ‘+EV gambler’ is checking BF prices to come up with Quaddie bets, you should take a moment to think about the incentives this structure generates.

   • The source should learn continuously & react appropriately to/from the information it obtains from its market participants. For instance, if your source is a standard sportsbook it’s a great advantage if they’ve profiled their customers & adjust pricing not only on volume but on the pair (volume/size, customer ID).

   • Preferably limits are raised/increased to a ‘high enough’ level throughout the day. Otherwise you can have situations where a few sharp bettors lock in their max limits at open [often best +EV offered here] just to see a crowd of noisy gamblers do all kinds of weird things to the prices throughout the rest of the day [the sharps can’t correct anything since they’re ‘all in’/bet their limits already]. As long as you know that this is the case can still use ‘non-limit-increasing’ sources though [trust super early action, ignore the rest].

   • A recommended read.

2. Identifying short time-frame bets/trades. Been talking about this from time to time on Twitter. There’s a ton of action that you won’t notice for one reason and one reason only: you’re not looking. How do you expect to see that “12 % of the pool”-bet that came in last second, if you didn’t log the price & volume before and after it came in? What about the weird orders that occasionally come in & eat the books ~25 minutes to post time for the UK dogs? Ah, you haven’t seen them? Of course you haven’t, they’re gone as fast as they come in. The alert trader knows that he must take them off the table before anyone notices, or he’ll gain competition. But he won’t trap us, right?

3. Learning how to optimally get your size on & understanding how other large punters are operating. Let’s say there are seven sportsbooks offering odds on your main market & each one of them takes ~$200 on an outcome [on average]. By tracking the bookmakers in parallel and placing a couple of large bets spread across all sites, you’ll soon realise that sportsbook 6 looks at/learns from sportsbook 3 which looks at sportsbook 1 & 2. However, sportsbook 1 & 2 is much larger than the rest so they don’t care too much about what’s happening at the other places. Then, what are you supposed to do with this information? Well:

   • Unless you’re happy taking lower prices, you’ll of course place your bets in the order (6) → (3) → (1 & 2). This way you’ll be safe from bookies noticing your money/information *before* you hit them.

   • Now that you know how *you* should operate, you also know how *other sharps* are [or at least should be] operating. Conclusion: you set up notifications for sharp drops at sportsbook 6 & join the movement.

4. Finding huge discrepancies & large deviations. Not much to say here, as obvious as it gets. If there’s a 40 % drop/drift in an outcome you’ll want to know this. If a $20 000 order/bet [insider info/rich owners or perhaps both? or a misclick/bot going crazy [yes, has happened several times]] comes in at the exchange/in the parimutuels, you want to get this information. If all bookies have 2.10 but the liquid one runs to 1.60, again you want to know this. Just. Track. It.

How to do it?

Generally two options on how to actually take your ‘odds tracking ideas’ from ideas to real world implementations.

• Join existing software services. Example: Subscribe to a couple of information feeds & sign up for an odds screen service.

  Advantages:

  • Efficient, doesn’t have to build anything & can get started tomorrow.

  Disadvantages:

  • Can be pricey.

  • Miss out on the opportunity to learn [& stumble upon other things] while you’re building.

  • Restricted to the exact logic provided by the software vendor.

  • Effectively handing the software provider your data [assume everything is logged & analyzed] for free [or even at a huge cost depending on what you’re doing].

• Build it yourself. [Recommended route, in particular for the many devs we have in our subscribers list].

  Advantages:

  • Learning while doing.

  • Full generality, can choose to look at whatever you’d like to investigate.

  • Removes/reduces your dependency on other actors in the ecosystem.

  Disadvantages:

  • Costs both time & money.

Note that ‘building it yourself’ doesn’t mean building it *yourself*. If you don’t enjoy/have time for hours & hours of coding, focus on properly designing everything and then outsource the actual construction to others. has all you need to know for this, read his Substack & check his Twitter. Also if possible get yourself a partner [but make sure it’s a great partner].

Related: Sincerely believe that you could run a profitable business in Australia only by tracking odds moves across horse racing bookies & hitting them at sites that are lagging. Shouldn't take long before you learn in what order the 'real' punters place their wagers [even without having to become one] which should help tremendously. Would definitely do this ourselves if we were AUS based. Exists a couple of similar services but the greatest EV when it comes to these things always lies in specialized software, i.e. software that's looking for specific setups, not just tracking everything & spending tons of time behind an odds screen trying to infer things [inefficient].

If you’re serious, happy to help with & discuss anything. Twitter DM’s or comments section below.

Final stretch

Not a single picture in today’s post… ;)

• Been spending a decent amount of time at the intersection of horse racing & machine learning lately, hopefully ready to share some of that stuff soon. Have a couple of brutal racing autists reading this Blog & they need their fair share of content as well…

• BetPicks US has now been launched. Don’t expect ROI’s on par with the UK/AUS Horse Racing versions but should get better & better for each update, and probably fairly good already [letting it run for a few weeks until we perform an analysis on the notifications posted in the Channel, to see if there are ways to make it sharper].

Finally, something to think about until next time:

That’s all for today.

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Avatar!

Today we’ll discuss something we’re fairly certain our readers will love to read about, the act of applying automation to different betting market pursuits.

Before we begin, a side note:

As with all things automation you’ll always find a bunch of larps looking to automate everything despite having no idea regarding *what* they’d like to automate. They want to build betting bots, but have zero clue about what the bots are supposed to bet/trade. They’re currently scraping the whole web on sports data, but haven’t spent a single thought on how they’re going to use it. Don’t fall for this automation/coding psyop. Sounds smart, is completely deranged. You think you’re moving forward [ahhh I’m cooooding] but you’re literally just wasting precious time.

The real path is instead:

• Spend some time in the betting markets.

• Come up with an angle/idea.

• Think everything through properly.

• Define proper requirements [what you require from your program/what your program is supposed to do for you].

• *Then* build.

When you find yourself performing a repetitive, well-defined *money-making* pattern on an everyday basis, you automate. Not before.

Possible coding projects within the betting sphere

Now that we’ve warned you not to initialize time-consuming projects without a proper design of how they’re expected to evolve through time, let’s jump into the fun stuff & discuss a couple of plausible use-cases for code in betting.

• News trading systems. Trainer just reported a change in horse equipment? Scratch in a race that changes the expected pace/tactics in the race and/or doesn’t affect rest of the field linearly? Player out in tonight’s NHL game & prop bets lagging for the one taking his place in the PP unit? Doesn’t require much thinking to get this right [of course even better if you manage to come up with a set of subtle second order effects] & there are tons of easy +EV-dollars to pick up. In particular a great complement to an existing operation.

  There are people out there reading this thinking “what stops the bookie from reacting to the news flash before you get the chance to do so?”. If this is you, unsubscribe & enjoy your crickets.

• Scrapers in general. An absolutely fundamental part of any serious betting endeavour. Data will be necessary. How do you get data? You scrape it. You’ll need odds, how do you get odds? You scrape it. News trading systems without scrapers? Lol!

  

• Oddscheckers. Building bots to avoid spending hours each day scrolling through pages & pages of odds only to check whether they meet your criterias or not is most likely one of the most efficiency-generating upgrades you’ll ever do to your betting. Define a bunch of basic checks that will filter out plausible bets within a reasonable margin of error (no need to be perfect here since you’ll have a second look & place the bets manually anyway).

• API’s for parimutuel providers/sportsbooks. Far from all gambling actors offer their customers Betting API’s & simple programmatic ways to enter their pools & books. If that’s the case and you nevertheless find yourself having a bunch of daily action [in particular if triggered by events you can integrate with your code] at such places it may make sense to construct a basic API for automation of the final step of the betting process, i.e. the actual wagering. No need to build something crazy, a browser automation session coupled with a small collection of elementary routines [create_order, send_order, generate_submission_file, log_order etc.] can take you far.

  

• Exchange algos. Infinite number of angles at the exchanges for a programming wizard with an understanding of betting markets. Betfair offers an Exchange API [learn more here] that lets you enter the chaos in a straightforward manner. Zero constraints. Think, map your thoughts into code, put money behind it & let your creativity earn you money. Heaven on betting earth? Perhaps.

  Don’t worry about the ‘exchange market efficiency’ crowd. Real ‘tists enjoy maximum freedom [for everyone]. & worst case you’ll obtain a lesson in adverse selection!

• Fundamental systems. In our opinion the end game for any *serious* [if this isn’t your job, this doesn’t apply to you. Keep collecting your dollars & don’t worry about how you do it lol…] gambler. Steam chasing, news trading & the rest of that stuff does a *great* job at *accompanying* a more [mentally] rewarding project. As you go beyond your first steps on your path to the riches you’ll lose that intense feeling of ‘wow, I can actually make money by clicking buttons’ & will thirst for something more stimulating [as with all advice it’s possible that this only refers to the author’s personal experience/view, but whatever]. After all you’ll spend hours & hours each and every day on this. Move forward, build something cool.

  *Not everything is numbers on a screen.*

  Finally, harnessing [:D] the power of ML/stats/data analysis for something as beautiful as horse racing will deepen your understanding of statistical learning techniques & software development, which translates very well into several other fields/career paths. Moreover, such a project is guaranteed to yield tons of insights into the equine world… Might come in handy when you decide to launch your ‘Moneyball-style’ thoroughbred/standardbred breeding operation in 10 years!

• Optimizations & similar engineering stuff pop up more or less everywhere no matter what you’re doing. Examples:

  • Your #1 bot has always managed to find a great amount of good opportunities each day but since approx. a month ago this number has decreased dramatically. After looking into it you find this new Degen Bot that somehow manages to get in front of 90 % of “your” trades & literally steals your EV right in front of your [your bot’s] nose. No way you’ll let that continue, right?

  • A steam chasing program seems to offer potential but since the current version of the code only lets you visit each market/selection once every 3 minutes your hypothesis is that you miss out on a bunch of short timeframe +EV bets! Time to upgrade the codebase.

  • This absolute Autist Play that on rare occasions puts in a ‘decent’ amount of late money into the parimutuel pools got you deeply rekt last time when only ~35 % of the supposed bets were entered successfully. Again a speed issue.

  Easy to see that efficient, clever & optimized code might have a substantial effect on the P&L you end up with after it’s all said & done.

Development/job/projects opportunities

Having introduced & discussed a fair amount of plausible betting projects, let’s turn to what may turn out to be an interesting opportunity for some of our readers/subscribers out there.

We’re constantly working on stuff that’s heavily related to the bullet points above and it is very much possible that we’ll start outsourcing parts of it going forward.

Therefore, if you believe you’d find it stimulating to work on such projects, feel free to get in touch with us via Twitter DMs/Discord etc. with the following information:

• A brief overview of your coding/programming/software development experience.

• A list with a subset of the above use-cases which you’d guess would be most suitable for you to help work on.

Note that there is nothing [*zero*] available at this very moment, consider this an early hint about upcoming *future* projects.

How it will work:

• Cartoon Horse will get in touch with you with a detailed set of instructions/design guidelines [could be for a smaller part of a larger project, could be for a full project].

• Discussions back & forth to make sure the project is OK with you & that everything is clear.

• You implement the requirements.

• Computer coins switches owners.

Please spare us psyopping edge extractors [or well, we have a few dead end projects in store for you guys]. Also our bets are -EV anyway.

Conclusion

THE END. Yep, this is a short one today.

Until next time…

New to the gambling world? Do bonus rugging and make thousands of dollars from bookies' welcome offers alone.

Routined bettor? Check out the rest of our Substack/Blog [with millions of readers] & have a look at BowTied BetPicks, a +EV data feed that continues to deliver 30-40 profitable Horse Racing Picks on a daily basis with amazing results.

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Degen Gambler!

Today we’ll touch on an important & very interesting topic: running simulations to obtain a better understanding of the future. There’s no doubt that the ability to run & learn from simulations is a crucial tool for any bettor trying to recognize what the future may have in store for him. Without it he’ll naturally fall victim to the #1 predator in gambling, randomness.

We’ll illustrate the power of simulations by having a look at two different questions.

1. A UK Horse Racing gambler has recently signed up to the BowTied BetPicks Premium Service & has, during his first week, placed a total of 100 bets on different Bot recommendations. He’s been placing flat bets of £100/bet & is interested in learning what an arbitrary week/month/year may have in store for him if he keeps rollin’ at the same pace!

2. A Longshot Enjoyooor is placing one $10 000 longshot bet a week with the following payoff structure: There’s a 1/100 chance that he wins a million & a 1/8 chance that the bet returns $30 000. At 37.5 % EV he understands that the structure could be an opportunity of a lifetime, but he’s curious to whether his portfolio will be able to stand the variance or not. After all, he values being comfy & cool while emptying the market’s pockets.

Note: Case 2 above may sound like a very much invented problem. It’s not. IYKYK.

Why simulations?

Mathematics offer a tremendous amount of tools to understand reality. However, the closer you get to real world phenomena [which are unique, flexible & rarely adhere to standard mathematical rules], the more advanced & complex the models become.

Instead of spending countless hours on manipulating unintuitive formulas only to at best find a couple of non-precise upper/lower bounds, a better [& easier] way to approach such problems [to understand reality/a real world process] is to code up a close approximation of it & iterate through that coded version of the process a large number of times to see what happens.

Under the assumption that the coded version is a reasonable approximation of the real world process, the simulation will yield a set of alternative realities that behave very much like the one that awaits you. & by analyzing those invented realities you’ll gain the insights you need to avoid a lot of the real life confusion you’d otherwise have to deal with [rule #1: *your* intuition for randomness is beyond terrible & simply much, much worse than you think].

Note I: Of course not saying mathematics is outdated and/or useless here. As usual, the real magic lies in the combination of maths with a second subject, in this case simulations. Without math:

• You don’t *really see* the assumptions underpinning the simulation results.

• You can’t determine whether your simulations are properly constructed and/or whether they are any accurate at all.

Note II: Code is more flexible than pure math models. That said, it’s not as flexible as reality. The Map Is Not The Territory. Example: your amazing backtest is more likely to be a result of a bad map [poor backtesting assumptions/model] rather than a signal of a true edge.

Case 1: Horse Racing Bettor

A UK Horse Racing gambler has recently signed up to the BowTied BetPicks Premium Service & has, during his first week, placed a total of 100 bets on different Bot recommendations. He’s been placing flat bets of £100/bet & is interested in learning what an arbitrary week/month/year may have in store for him if he keeps rollin’ at the same pace!

To help our bettor understand the kind of risk he’s taking as well as what he’s to expect profit-wise we’ll utilize a combination of two clever statistical concepts, bootstrapping & simulations.

Theoretical explanation:

Bootstrapping is a statistical method that involves resampling from the original dataset to create new samples that are used to estimate statistical properties of the population. The idea is to simulate the process of randomly drawing new samples from the same population to better understand the uncertainty associated with our estimates. Bootstrapping is useful because it allows us to simulate random processes and estimate the variability of our estimates without having to make assumptions about the underlying distribution of the population.

Simulations/Monte Carlo methods are a class of computational techniques that use random sampling to estimate numerical solutions to problems that may be difficult or impossible to solve using ‘standard’ methods.

Practical explanation:

You have a dataset of 100 bets at your disposal. However, you’d like to investigate what the P&L in a sequence of 1 000 similar bets may look like. To solve this seemingly unsolvable problem you use the information provided in the dataset to generate an *artificial sequence of bets*. How? You repeatedly roll a “100 sided die”. If it comes up 64, you pick the 64th bet in your dataset & denote this ‘bet #1’. Next you throw the die a second time and in case it lands 27, you, exactly as before, pick the 27th bet in your dataset & set this to be ‘bet #2’. Then you keep rolling until you’ve built up a full series of bets that matches whatever length you wish it to have [in our case 1 000 bets]. Simple, right?

Having obtained the set of 1 000 bets, it’s time for the simulation/Monte Carlo part of the procedure. For this purpose we’ll assume [NOTE ASSUMPTION] that the closing odds equals the true probability. Is this a valid assumption? No, but it’s likely to be good enough for what we’re doing.

Each row of the dataset contains the following information: the outcome, the stake [in our case always 100 GBP], the odds & the closing odds.

Simulation recipe: 

1. Visit bet #1. The closing odds is 6.40, implying a true probability of 15.6 %. 

2. Generate a random number between 0 and 1. 

3. If the random number falls below 0.156, consider it a 'win'. Otherwise, a 'loss'. 

4. If it’s a win, add the net profits to the P&L. Else subtract the net losses. 

5. Visit bet #2. 

Continue until you've looped through all 1 000 bets [& make sure to track your P&L at each step of the process]... 

Note I: Bootstrapping methods require that the dataset/sample you’re working with [in our case the set of 100 bets] is a reasonable representation of the distribution that is generating them [both now & in the future, the ‘underlying distribution’ must stay stable]. If for some reason the Bot starts delivering completely different bets going forward and/or our 100 bet sample happens to be a huge outlier, we’ll be fooled by using the now misrepresentative dataset as a basis for our analysis. Good thing here is that there’s no particular reason to expect this pitfall to be of much relevancy for us, thus validating the use of the methodology.

Note II: The line of thinking presented here can of course be generalized far beyond betting. Stock market performance [use hourly data from the last ten High Vol days to simulate what a full month of high volatility may cause]. Crypto trading [analyze your P&L]. Sales analysis. Expected ad revenues… The list goes on. Before you begin though: understand what you’re doing. Read up on the theory & try to come up with cases where bootstrapping methods would be straight out dangerous to use [example: fat-tailed domains, rare events likely to be unseen in small samples/tail behaviour not properly captured by 50/100 data points].

To really hammer it home, here’s a step-by-step breakdown of the approach:

1. Assumption: We assume that the 100 bets we have are representative of the true underlying distribution that generates the bets. Essentially saying that the empirical distribution is a great approximation the true/real distribution.

2. Resampling: For each simulation [let's call it a run], we resample 1 000 bets from our original 100 bets with replacement [bet #64 can appear several times]. This is our sample A.

3. Compute P&L: For each of these 1 000-bet samples [like A], we compute the P&L.

4. Repeat: We repeat the resampling and P&L computation process for multiple runs [B, C, D, etc.] until we've done it enough times to get a good estimate of the mean/variance/distribution of the P&L over 1 000 bets.

5. Analysis: After all runs, we can analyze the distribution of P&L values from all the samples [A, B, C, etc.] to estimate the distribution of the real P&L over 1 000 bets.

Now let’s get to work. Excel file with the data for the 100 bets provided below. Python code available here.

Betpicksdata

14.8MB ∙ XLSX file

Download

Download

Analysis, results & graphs

First, let’s recall the underlying assumptions of our analysis.

• Betfair Closing Odds = True Probability. [Could be reduced to saying that Betfair Closing Odds is an unbiased measure (correct on average) of the True Probability, but the lighter the assumptions, the more complicated the model… & it would yield frustrating [but perhaps instructive] edge cases]

• Flat Bets of £100 GBP/bet.

• Future bets are well described by the 100 bets taken so far.

Since launch there has been an average of 27 bets per day. Assuming the typical subscriber is able to tail ~10 bets/day [not meant to be a full-time job, but rather an enjoyable [& profitable, ofc] experience], we consider 1 000 bets to be a natural number to begin the analysis at. This is ~3 months of using the service and if you aren’t able to run a strategy for at least 3 months without changing things, betting markets aren’t for you anyway. Consumed by Randomness.

1 000 bets

Below you find an illustration of 50 different runs of 1 000 bets. You can think of it like 50 subscribers taking bets in parallel [well, not really since their performances would be heavily correlated, but you get it] until they’ve all placed a thousand bets. Throughout this time we track their performance & plot it on a bet-by-bet basis. Their final P&L’s are determined by the height of where their individual P&L graphs end.

As you can see, despite an obvious advantage over the sportsbooks [graphs trending up on average], there’s still a risk they end up losing money to them. & this is after 1 000 bets! Meanwhile Mr Average Bettor tries the service for 2 weeks & either declares you the King Of Horses or jumps the ship.

Next diagram is a histogram over final wealths for the above runs, but with the number of runs extended to 1 000 instead of 50. I.e. a distribution describing where the paths tend to end up. As you can see: very clear +EV, but with a considerable variance.

The Degen Gambler looks at the above two graphs & conclude: LFG! However, there’s this guy that doesn’t really enjoy the variance and so he comes up with an idea, what if he could hedge all the bets just before the market closes at Betfair and never take any outcome risk? And, to make things even better [or so he believes], he realises that this would allow him to increase his size heavily *while reducing the variance*. I.e. keep the same EV per staked pound, but reduce the variance. & increase the number of staked pounds. The magic formula?

Well, there’s some truth to what he’s saying, but it’s not that easy. Couple of things to consider:

• Taking trades at Betfair/Smarkets/any other exchange *costs money*. You pay spread fees & commissions. Expect to lose at least 2-3 % of the value of your initial position from this alone. With an ordinary EV of 10 % that’s 20-30 % of your expected profits *erased*. However, if it lets you double your size, then it doesn’t really matter, does it? Nuanced.

• Hedging things properly takes time. Contemplate the Opportunity Cost of spending 1-2 hours/day doing this.

• Depending on your size, your exchange action might influence the pricing, making it a challenge for you to hedge your bets at prices you’d obtain as a low stakes bettor. Eats into your profits + won’t be long until counterparties [Cartoon Horse!?] observe that there’s yet another impatient gambler to take advantage of.

Anyway, lets simulate it. We’ll assume hedges are matched at (Closing Odds + 3 %) & commissions = 2 % [standard Betfair fee] to incorporate the thoughts in the above bullet points into our model. Results below.

Looks good! Note that all paths go +ROI [& stay there] almost immediately.

Note: We’d recommend combining the two strategies. Sometimes you hedge, sometimes you don’t. If a 10/10 bet comes along [example, drop from 4.00 → 3.00, Unibet remains at 3.85], no reason not to hit it as hard as you possibly can [assuming it won’t get you instantly banned by the bookie] & hedge your position at Betfair. Free money.

Below we repeat the above analysis but for 10 000 bets instead of 1 000. The #1 insight: with time, the law of large numbers comes into effect & pushes more or less *all* paths into profitability.

10 000 bets

Note: As you may have understood by now: simulations are incredibly powerful. & they’re just as good for small, finite samples as they are for arbitrarily large ones. Remember, your betting career is finite. Meanwhile many mathematical results rely on asymptotic/limit theorems. The question you got to ask yourself: will I be able to run far enough to those theorems into play? If not, beware putting too much trust into them.

Case 2: Longshot Gambler

Since the first part of this post blew up we’ve decided to handle [& add in some extra twists] Case 2: The Longshot Gambler properly in a future write-up instead. Graphs shared below [for the curious reader] though. Code here.

Recall the situation: A Longshot Enjoyooor is placing one $10 000 longshot bet a week with the following payoff structure: There’s a 1/100 chance that he wins a million & a 1/8 chance that the bet returns $30 000. At 37.5 % EV he understands that the structure could be an opportunity of a lifetime, but he’s curious to whether his portfolio will be able to stand the variance or not. After all, he values being comfy & cool while emptying the market’s pockets.

Conclusion

As usual ‘near email length limit’. A few notes before we leave you for today:

• Sincerely hope we’ve managed to convince you of The Power Of Simulations with this post. The frameworks presented within this treatment are strikingly effective when used correctly.

• The “simple path” to success in betting markets now updated:

  1. Do BR, continue until no more promotions.

  2. Repeat BR on friends/family.

  3. Transition into +EV betting [BowTied BetPicks], continue until limited/banned.

  4. Repeat +EV betting on friends/family accounts.

• The real world path for our personal BowTied BetPicks bets will unfold at https://betpicks.bowtiedbettor.com/stats-graphs. Stay toon’d & let’s pray and hope for that pink one!

• BR posts coming up next on the Blog. First one on the #1 offer in the USA, a freebet packaged inside a risk-free bet. Second one on taking advantage of casino bonuses. If you have more suggestions/requests, please share them in the comments section.

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Avatar!

When we first set up the Substack, one of the primary reasons was to sharpen our action. & being forced to map those latent thoughts hidden in the back of our heads into well crafted explanations has indeed been a clever trick [as noted by many before us] to perfect our edges.

Don’t misinterpret this as us being against the act of letting thoughts exist without further inspection. Definitely not. To be fair, in 99 % of the cases the time spent on deeper knowledge for an arbitrary niche question will yield zero. Nada.

& there’s some magic removed when certain concepts are made into 'study material'. Love to have a thought hanging around for a while [or forever] until the time has come for it to be handled properly…

Warning: This post could come along as somewhat disorganized. Much of the content is a direct function of a late night thought process, a process that gets bored to death by organization. Love to read organized posts. Hate writing them. How lucky we don’t have to read our own posts! :)

Thought A [Market efficiency]

Seen a lot of brain dead arguments [mainly by data enjoyooors] 'supporting' market efficiency. Everywhere. All the time. Excellent example of how repetitive & boring people are in general [everyone parrots & circulates what others are saying & travels through knowledge, devoid of context].

So, what is market efficiency?

The market’s perceived ability to price objects according to their underlying, ‘true’ probabilities (if we allow for such an abstraction). Effectively creating an environment where all strategies should be equivalent [profit-wise]. So how would you go about proving market efficiency?

Two options:

• Show that each outcome is perfectly priced by the market.

• Prove that no matter the strategy employed, profit expectations remain the same.

Can either be shown in real life? Of course not. This yields our first insight: since in practice market efficiency cannot be proven, any attempt at such a proof must naturally fall apart. There is no escaping, there’s no place to hide. Might be hard to find, but somewhere there *must* be a crack in the argument. Your mission: find this crack & *see*.

All there can ever be is *beliefs* about market efficiency. & whose beliefs should you trust? The practictioner's. If you wonder whether a specific market is efficient, refuse to ask the confused but of course very certain ‘data scientist’ & try to find yourself an autist gambler betting the market on an everyday basis to answer the question instead.

Random note: the greatest advantage of building great mental models? Don’t have to waste time cleaning, reading & manipulating data. Who enjoys working with data anyway? 100 % the most boring part of any ‘research process’.

Thought B [Bayes, Bayes, Bayes]

We’ll return to market efficiency, but the path towards it will have to be somewhat roundabout. Enter thought B. Bayes. Have been said many times by the cartoon horse before: Bayes is incredibly powerful. Why? Learning how to think in conditionals & inverses opens the door to a new dimension. The Bayes Dimension. And how do you learn to do such a thing? By studying Bayes. We preach Bayes all the time & of course the mids don’t see why. With no room for abstraction, they look at the formula & conclude: “nothing special about that”. It’s *a framework*. *Not* a formula.

Ability to think in conditionals = accustomed to & can entertain “if, then”-scenarios, even in complex cases. An arbitrary example: a sentence like “what is the probability of Brazil winning the 2018 World Cup, given them winning it in 2022?” doesn’t cause any confusion [conditional probability on a probability space is time independent] whatsoever.

Ability to think in inverses = appreciates that to truly answer the question in one direction, one must in many cases understand the reverse one. If you’ve never thought about the probability of a market price, given a true, underlying probability, how can you infer the [in practice] more important answer: the probability of a true, underlying probability, given a certain market price?

Mixing these two abilities with a suitable generative [either theoretical or practical, doesn’t matter] model is what we really mean when we repeatedly shill Bayes. Some would claim it isn’t an optimal mental framework in order to *think with precision*. Some are wrong.

Bayes is #1.

Intelligence guaranteed to skyrocket when *getting it*.

Back to market efficiency

Every single day tons of people ask: “given a market price, what’s the true probability?” They want to combine a bunch of sportsbooks to reach a fair number, then use it to beat whatever bookie they’re up against. A legitimate idea, but not the one we’ll investigate in this passage. Instead, we’ll have a look at a much less analyzed one, the inverse question. It’s interesting on its own, and, as noted above, it’ll most likely help us understand the reverse one better.

Q: “Given a true, underlying probability [e.g. a horse winning a race], what does the probability distribution of the market price look like?”

The answer to this question is the ultimate & only *real* measure of market efficiency.

In an efficient market, the distribution must collapse at the true price.

In an inefficient one, the price distribution might either be biased or spread out, or both.

& different degrees of market efficiency are perfectly incorporated in this model simply by varying the shape of the distribution.

Note: In general there is no need to come up with parameters & plots. Close your eyes and visualize the distributions instead. Mind > Python. & if what you see is a normal distribution, NGMI… ;)

Now, having developed this distributional market efficiency framework, we’re ready to have a look at the problem with standard market efficiency studies. The ordinary reasoning goes somewhat like this:

1. Collect historical data on closing prices.

2. Sort them into different price buckets, odds in [1.00, 1.20], (1.20, 1.50], (1.50, 2.00] and so on.

3. For each price bucket, compute the fraction of wins for the observed data points.

4. Note that this fraction lies close to the implied probability & conclude market efficiency.

Since, as established before, market efficiency cannot be practically proven, and any attempt at doing so will inevitably crumble, we now find ourselves compelled to uncover the erroneous reasoning within this argument.

Having spent many hours in Bayes Boot Camp, we see it at first glance.

There are a ton of alternative realities [wherein markets are assumed to be inefficient] that could have generated the same data.

A common application of Bayes is to update your beliefs regarding different, alternative realities as you observe new evidence. Thus, you get used to asking yourself: what alternative frameworks could have generated the data I’m seeing? Unless there’s only one such framework, you can never, ever conclude anything simply by observing the new piece of information. All you can do is to reweight your probabilities/beliefs regarding the different scenarios.

The problem here [& definitely not only here, see this all the time]: a complete failure to consider any alternative realities. Yes, if markets *were* efficient, then you would expect to see this data. But that does in no way imply the reverse, i.e. that if you see this data, then markets must be efficient. Why? Because even if markets aren’t efficient, there may still be many ways for this data to be seen, and unless you have successfully disproven *all* such situations, you really haven’t proven anything & you definitely cannot conclude that your framework is correct.

• A bookmaker prices all NBA games during a full season at even odds, i.e. 2.00 for the home team, 2.00 for the away team. At the end of the season, his data analytics team comes up to him & reveals that his pricing has indeed been very efficient. The 2.00/50 % outcomes won half of the time! Yet he’s infinitely poor.

• Onto the second bookmaker! When this dude puts up an odds of 10.00, the outcome is equally likely to possess a true probability of either 5 or 15 %. In hindsight, again, his pricing is very sharp since his 10.00 horses wins a tenth of the time. The problem? Also this bookie is infinitely poor.

• The third bookie [well, the real bookie] possesses an odds/probability distribution that is centered at the fair odds [unbiased], but with some spread around it. His 10.00 horses are as likely to be a 8 % horse as a 12 % horse & so on. He rarely misses by a huge margin, but there’s still some wiggle-room when he puts up a price. Again, “market efficiency”. Again, a negative result at the end of the year.

Do you see it yet?

This relates to another phenomenon: in previous posts & in many Bird App tweets we’ve repeatedly been saying the following: "If you have *more information* than your counterparty, you’ll always end up taking his/her money over time” [at least as a bettor/price taker].

Having come this far in our distributional thinking, we’re now ready to see why [a picture tells more than a thousand words…].

Note: Information ≠ data. Information = data + ability to process data.

Question for Plato: Under what circumstances will the Autist Gambler in the picture above place a bet with the market/bookie?

Note: A bookie & a market can in many cases be different names of the same thing. Hint: What makes the bookie adjust his odds?

This post has been yet another proof that people waste too much time thinking about averages [IYKYK].

Final note: Some of our arguments in this post haven’t been perfected yet. If you can see why, congratulations on being an absolute turbo!

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Degen Gambler!

It’s time for a post discussing the practical aspects of betting. Less theory, more day-to-day stuff.

As we’ve mentioned multiple times before, thinking doesn’t translate into profits. *Doing* does. No matter what kind of ingenious model/edge you’ve managed to develop, it won’t make you any money unless you keep showing up day after day for [at least] a couple of years. Thus, since this part of the game is guaranteed to take up such a great chunk of your time, why not optimize it?

In today’s post we’ll share a few things we’ve picked up along our path that relates to increasing the efficiency and profitability of a betting operation.

Note I: Some will truly believe that they can start tomorrow & “build a betting bot and let it print while spending time at the beach“. As delusional as it gets.

Note II: Real winners enjoy the infinite hammering & refinements of their edges. The Grind. Why? No doubt there’s a charm in it. For me personally there’s not much that beats a meeting where “I know everything about everything”. Completely prepared & in sync with what happens both at the racetrack and on the odds boards/in the pools. Magic.

Note III: One of our earlier posts, So you’re gonna be a bettor, huh?, is somewhat along the same lines and is a recommended read if you for some reason haven’t read it already.

Note IV: Since there are more or less an unlimited amount of things to say on this subject we’ll be back with a follow-up to this post in a few weeks. Will treat the practical parts of the Banking & Data segment of betting [unfortunately an important piece of the puzzle].

Structure of the post: a division into several subsections with each section containing a bunch of bullet points. Zero time wasted, tons of information.

Enjoy!

Limits

Limits [how much you’re allowed to bet] are a huge problem in betting. Some bookies offer fixed, equal limits for everyone, others (the marketing companies) decide the limits on a customer by customer basis. Profitable +EV bettors → kicked out as soon as possible. Casual punters with no clue/degenerate -EV enjoyooors → limits increased. Can discuss this for years but it is what it is.

• The natural question to ask: how can I avoid being hindered by those limits? Several answers to this. If you insist on using sportsbooks, jump to the next bullet point. If not, betting exchanges [e.g. Betfair] or parimutuel betting [primarily available for horse racing] are possible solutions. However, no solutions without problems.

  • The ease of getting volume down attracts other sharps, i.e. makes the market more competitive & harder to beat.

  • Liquidity issues are common if you look beyond the most popular markets in the top leagues/games/meetings. On exchanges: significant spreads + no one willing to take the other side of your trades. In parimutuel pools: pool sizes too small to allow for appropriate sizing [your bets move the odds].

• Multi Accounting is a popular technique to avoid limits/restrictions. You pay someone a fraction of the net profits/a lump sum to use their bookie/s account/s [win-win] & repeat this process ad infinitum. -EV accounts with high volume are optimal purchases, such accounts can be worth tons of money. Even new accounts can be made somewhat valuable if you artificially make them look -EV by placing a bunch of dummy bets before going full ‘tism.

  

  Subscribe now

• Another plausible solution is Staking. Not staking in the sense of staking ETH lol. Instead: you’re a gambler with an edge in the NHL prop market. Meanwhile, your autist fren is an expert in the corners market for soccer games. Both of you are using a bookmaker that employs equal limits for everyone & both of you consider this limit [e.g. $ 500] too low. To avoid this problem you agree on sending all your bets to your gambling fren which places/stakes them on your behalf [effectively doubling your size]. As part of the deal you do the same when he finds something worth pursuing. Notes:

  • Be clever. There’s a reason for the limits being there in the first place and if you abuse them to a great extent there’s a risk of *all the accounts* being closed down due to ‘syndicate betting’. Don’t bet an outcome from multiple accounts at the same exact moment.

  • Requires trust between the people involved.

  • There are many versions/varieties of the deal described above. E.g. could be that your wanted size is $700 and so the guy places $200 on your behalf and keeps the other $300 of the bet for himself. Countless ways to come up with reasonable terms for the partnership.

• Parlays can often be a clever trick to get more size down. In some cases it can be as simple as betting max limit on bet A, max limit on bet B, and finally combining them into a third bet, a double, to increase your stakes even more. In other cases: due to the nature of parlays [occasional, huge wins] bookies often allow higher max net profits from a parlay than they do for a single. For instance, let’s say that max return for singles are capped at $2K while it’s $10K for parlays. You have found a great bet at an odds of 4.00.

  • Alternative 1: Bet $500 at it.

  • Alternative 2: Pick a high RTP two-way market, say A: 1.96 - B: 1.96. Bet $1 275 on parlay A which is your 4.00 bet & outcome A, and $1 275 on parlay B [your 4.00 bet & outcome B]. Instead of $500 at 4.00 you now have $2 550 deployed at 3.92.

  • Alternative 3: Parlay it with a 1.01 outcome [what’s known as a ‘sure thing’ ;)] and bet ~$2.5K.

Information advantage

Betting is in large part an information game. If you’re a winning bettor you either:

1. Have access to better/more information.

2. Possess a stronger ability to learn from available information.

No matter which of it it is, getting the information streams set up correctly to strengthen your information advantage is crucial for a successful day-to-day operation.

• Running automated sportsbook comparisons & therefore always knowing where to find the best prices without having to spend 15 minutes comparing them is extremely helpful. For main markets in top leagues there are more often than not tons of sites/services that help you do this, but for smaller/special markets you may need to build out the infrastructure yourself [lots of content on this here at BowTiedBettor]. Saves you time, earns you dollars. A necessity.

• Receiving notifications when odds are released/limits are increased is another must-have. At odds release it’s *you against the bookie*. The bookie must put up a price for *all* outcomes. Meanwhile, all that’s required from you is to find *one* error. 20 minutes later a decent amount of gamblers have had a look at the offered odds already and almost surely corrected the most obvious mispricings [money you’re leaving at the table due to laziness & poor infrastructure].

  & it’s of course much easier to beat *one counterparty* compared to a whole army of gamblers. Choose your battles wisely.

  

  Again, have a look at our coding content and our Unibet scraper for inspiration on how to build this. If you don’t know how to do it yourself, hire someone to do it for you. Take action.

• A third thing we do *all the time*. Observe the market action. What are other bettors doing? Where are prices moving? When did the moves take place? Why did they happen? Who’s behind the move? Did all the bookies react [appropriately] to the new information? Was the information even informative, or nothing but noise?

  Setting up clever software systems to monitor the markets is an obvious way to get ahead. Common examples:

  • A horse drops from 10.00 to 7.50 over a span of 4 minutes. We have a second look at the horse and find that we’ve missed a change in equipment. Result: increased precision in our probability estimates.

  • 30 minutes into our preparations for a specific race we have a clear picture of how a certain race will evolve. However, after taking a really deep dive into the race we discover something that turns our previous beliefs upside down. The premarket action may now serve as a proxy for how sharp the competition is for the given day.

    In many cases the market sticks to the naive scenario, confirming that our competitors don’t *really* know what they’re doing. We understand what they’re doing but we don’t agree. An optimal situation.

    In other cases we are confused by what’s happening → often a sign of us lagging [knowledge-wise] the bettors behind the moves.

  • Perhaps the most obvious reason: Use what’s happening at bookie/exchange A to beat bookie/exchange B.

    Example: Scan the Betfair price action for UK horse racing and whenever you observe a price move that Bet365/Unibet etc. haven’t reacted to, bet the horse at those sites [you’re of course free to use any bookie and/or *arb* against the exchange if you prefer]. How can you do this? Well, we’ve already built it for you. Check out the BowTied BetPicks Website & join the Telegram Channel! Full launch later this summer. Stay toon’d!

Betting

General points on betting.

• Understanding the price discovery process of the markets in which you’re operating is important. At the surface level it indeed seems like a difficult proposition to beat tens of independent bookies using their advanced AI/ML models to come up with perfect prices & identify hidden patterns in their customers’ action. Well, sounds cool, until you actually enter the markets. And see the reality. *One* bookie/exchange with a dozen of active sharps. The rest of them copy pasting this “source of truth”. It’s not you versus the masters you’re fearing. It’s you versus a confused dude at the bookie’s office [indeed must be confused if working at a sportsbook, even if we couldn’t beat them would never join them] and a couple of other gamblers that are more or less copies of yourself [sadly most likely read the same books → have the same ideas, yes that’s how boring we are].

  • Identify these “sources of truth”. Could be Betfair, could be Pinnacle, could be a local bookie allowing volume due to well developed systems for domestic leagues/games/races.

  • Identify the copy pasta machines, i.e. the bookies [marketing companies] that have given up already & simply reposts the prices observed at the price discovery bookie.

  • Learn what’s required to move prices at different places. Should you trust the price action at a bookie that moves an odds 20 % due to a $200 bet? A $2 000 bet?

    If $700 is all that’s required to manipulate the “source of truth”-odds & get thousands of dollars down at other places, is the “source of truth” perhaps a “source of manipulation”? Think hard about such things & Plan Accordingly.

  • Would you include the opinions of/price action at a bookie whose sole profitability derives from restricting & banning sharp customers in your “averages”?

    

  • If the “source of truth” is a parimutuel pool then there’s not really much price discovery taking place until the very last minute. Zero incentives for a knowledgeable bettor to correct any mispricings prior to the last few ticks.

• Odds/prices are not fixed through time. They are in constant motion until kick-off/post time. Yes, part of the job is the ability to answer whether the odds posted on a certain object is too high. A more sophisticated part of it is to further strengthen this ability by developing the skill to predict the future price path. Not the same thing.

  • If you’re interested in obtaining a given position you’d of course always prefer to maximize your average odds. Thus, even if what you observe right now is +EV, the correct decision may be to wait.

  • Exchanges allow you to trade in and out of your positions. If you’re good at predicting price movement this is an excellent opportunity to convert this knowledge into dollars. [& if you’re less of a trader but still find some of these obvious mispricings from time to time, load up a huge position and sell it at the exchange closer to kick-off. Can be hard to execute in practice due to limits/large transactions but once in a while it may make a ton of sense.]

  • The art of predicting price paths is not about advanced mathematics but rather about learning & understanding how other market participants are acting/what they’re valuing. Read what others are doing. As mentioned before there are situations where *I understand why a price is likely to move in a certain direction*, but don’t agree with the theory backing it up. The trade is +EV, keeping the position is not. CLV is not all there is to it, after all.

• Who’s on the other side of your trade? Betting is an information game. In a bet/trade, there are two persons/entities involved & the person possessing the more precise probability estimates is destined to take the less sophisticated one out of business over the long term. Therefore: make sure not to be the NGMI-dude. More on this in a heavily autistic post coming up at the Substack.

• An obvious one: keep a record of your bets. If you’re not running some kind of performance analytics once in a while you’re 100 % missing out on profits. All edges/angles can be refined/perfected. Log all your bets in a detailed manner in order to create a sufficient dataset that may provide an insight or two later on. Literally takes ~10 seconds to log a bet
  *manually* so it being a ‘time consuming’ process is pure cope.

  Then use the theory in the below two posts to analyze & learn from the record.

The Ultimate Setup

A combination of the above ideas together with a fair bit of Banking/Data [the relationship between a bettor and his bank, KYC, Source of Wealth & Affordability Checks, data collection, data storage, data analysis and so on… [coming up at the Substack]] magic yields The Ultimate Betting Setup. And, as you might have noticed, there’s a reason we call it a betting *operation*. This is not something you get done by spending 1-2 hours a week for a short period of time after falling victim to a random ‘betting is cool’ thought.

& we’re of course *not* saying this is something the average reader should get to work on, though we hope he/she may have found the read interesting anyway.

If you’re one of the serious ones, a great deal of the information you need is now out there. “The rest is up to you”.

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Degen Gambler!

Bayes Craze! It’s time for the second part of our Bayesian series, a series which aims to introduce you to the world of Bayesian learning & put you in a Bayesian state of mind, or dare we say, a correct state of mind.

If you haven’t read part 1 yet, begin there.

The concepts presented in this series are relatively tough to grasp and unless you have had a proper amount of training with thinking in conditionals, there’ll be a lot of hidden insights that you simply won’t *see* at first glance. Therefore, take your time with the material. Read. Think. Read again. Or, equivalently: Have a belief. Read. Update your belief.

NHL-learning

In the conclusion of Part 1, two problems were posed. The first, the investigation of a backtest/sequence of bets, was handled in a comprehensive manner in “Bet Sequences, an analysis”. Today we’ll have a deep look at the second problem:

After having read our posts on web scraping, you have just scraped and stored all the NHL data from the previous season. You are now interested in learning as much as possible about it. For example, since you find live odds intriguing, you wonder what the probability of a team winning a game, conditional on taking a lead into the third period, is.

We’ll examine this question on multiple levels.

First, we’ll do the most basic thing: collect data on prior NHL games, look at the subset of games where one team has taken a lead into the third period and from there determine how often those teams have been able to maintain their lead. This will provide us with a simple, fundamental fraction to keep in mind while e.g. betting same game parlays in the NHL.

As soon as we’re done with this initial step, we’ll advance the analysis with an alternative perspective, a Bayesian perspective. By approaching the problem from these two angles, the deficiency & NGMI-level of the former will become apparent. As we’ll see, there can be huge differences between “learning” and *learning*.

Throughout the post we’ll do our best to discuss details to consider when running similar statistical analyses *in real life*. Remember, we’re not here to write papers, we’re here to back our beliefs with real world money. Thus, we cannot afford to overlook or misinterpret important features related to the management & understanding of data.

A trivial conditional measure

Let’s begin with the basics. We’ve fetched the regular season data for the NHL 2022/2023 from what we believe is the official NHL API [EXAMPLE of full game data for the first 2022-2023 game]. Relevant data for our purposes has been stored in the file below.

Nhldata

44.2KB ∙ XLSX file

Download

Download

Python code for this post can be found in this folder in our RandomSubstackMaterial repo on Github.

Collecting the data and performing a quick check for the fraction we’re interested in yields a value of 82.94 % [1 312 games in total, 1 008 of those had one of the teams in front after two periods, 836/1 008 kept the lead & won the game]. Conclusion: absent better information, the probability of a team ending up as winners in a game *given a lead after two periods* is ~ 83 %.

Before we continue, let’s have a look at the different problems with the above approach.

• All we’re left with is a number. The world is far too uncertain to reduce all our knowledge into simple numbers.

  Numbers give you a false sense of security. Behind every number there's a probability distribution.

  One of the beauties with Bayes is that it allows us to quantify our levels of uncertainty, i.e. helps us determine how sure we can be that our numbers [or intervals] are correct or at least approximately so.

• What we obtain using this method is a very, very general measure/average. In practice, this won’t help much unless we are able to split our dataset into more specific subsets, with each such subset being a collection of teams/setups possessing similar features.

  A huge underdog taking a lead into the third period is *less likely* to win the game than a favourite in the same position. Priors matter. In reality we’d like to condition on more than “team in the lead after first two periods” to actually learn useful stuff.

  ---

  This leads us to an interesting truth concerning data.

  YOU NEVER HAVE BIG DATA. Why? Cause if you do, you should immediately dive deeper into your dataset, find clusters within it [observations with similar features] & repeat your analysis on each one of those clusters. Effectively, in practice you’ll always have to ask yourself “small data questions” or you’re likely doing things wrong.

  Bayes comes in handy here since Bayesian inference is more or less made for “small data problems”. And, since all data problems should, if possible, be reduced into small data problems, Bayes must be the way to go!

  ---

  Note: The amount of data increases the rate at which you’re learning in at least two ways:

  1. More data yields more certainty [variance goes down with more observations] in the “population” estimations [full dataset averages, medians etc.].

  2. More data creates better opportunities to condition on multiple factors at once [understand how the values of quantities differ between subsets/clusters].

Now that we’ve hinted at there being a better way of observing the world, let’s actually try to analyze the data from this somewhat more sophisticated viewpoint. At the end, it will be clear that the results yield superior answers to our inquiries.

The Bayesian perspective

Time for a truly Bayesian interpretation of the problem! Recall from this part of Bayesian thinking & inference, part 1 that Bayes Theorem is the mathematical formula that allows us to move from a prior belief to a posterior one [updated beliefs after observing the data], hence the term “Bayesian”.

The image below illustrates a simplified version of the typical Bayesian workflow. As we progress through this process for our particular NHL-question, we will elaborate on each step and emphasize the key points to keep in mind.

Note: Like for any practical learning or modelling process, numerous aspects need to be considered at each step of the Bayesian workflow. However, since our main goal with this post is to present the core & power of Bayesian methods rather than overwhelm you with details, such issues will be left out of this piece.

Bayes, step 1

Step 1 in the Bayesian workflow is to assign our variable/s of interest a prior distribution. This probability distribution should include the *prior information* we have regarding the variable/parameter. Different people choose different priors, and since priors are an important part of determining our posterior distribution [prior updated with new data], it’s important to get them right. Precision in the prior translates into precision in the posterior [our updated beliefs].

Absent domain knowledge it’s common to assign an uninformative/flat prior to problems one hasn’t investigated before. This has two effects:

• Less precision in the output unless you have *a lot* of data.

• Decreased risk of obtaining heavily biased estimates due to poor prior beliefs.

For simplicity we’ll be using an uninformative/flat prior, i.e. assume all probabilities between 0 and 1 are equally likely [*obviously* false but the idea of this post isn’t to construct a clever model, it’s to push our readers in the right direction to come up with one themselves]. In reality, a more natural way of approaching the problem would be to run an equivalent model on earlier seasons, a process that would have yielded an “aggregated posterior”. This distribution would then be tweaked with domain specific knowledge [such as beliefs regarding changes to the game that is expected to have an effect on the probability of a team winning a game, conditional on taking a lead into the third period] and subsequently used as a prior for the analysis of the latest season.

Note I: Read a [for some reason popular] terrible take on Twitter last week:

Gambling ads are the absolute worst. It’s far from the only harmful product, but unlike alcohol cigarettes fast food etc, these ads’ purpose is to mind fuck you into believing something that’s false: that you can use your sports knowledge to win money.

Couldn’t agree less. Sports knowledge is what perfects your predictive ability. It is exactly the “tweak” mentioned at the end of the above paragraph that makes the difference between reality and what every data nerd sees. We’re not saying everyone in the markets is doing this fancy “tweak the prior”-Bayes stuff we’re trying to explain here. However, if you have a deep enough look at it & allow for some creativity you’ll realise that what we’re really trying to do with these Bayesian models is to approximate the thought processes we constantly perform in everyday life. A prior belief. New data. An updated belief. Thus, in this language “better sports knowledge” can be translated into “more precise priors”, which of course will have a positive effect on the quality of your/our predictions.

Note II: Sample sizes are a big thing in standard statistics. In Bayes World they don’t matter as much. Why? As you let data hit your Bayesian model, it will perfectly incorporate two things: in which direction the evidence points AND the amount of information/certainty that have been gained from it. If your dataset is small, the posterior will be widely spread [estimates are *uncertain*]. As your dataset grows large, the posterior distribution will converge/put all mass on the true value [estimates become *certain*]. Thus, there’s no point in obsessing about sample sizes since they’ll be naturally embodied in the shape of the posteriors.

Bayes, step 2

Step 2 is to use preexisting mathematical models to approximate the data generating process as well as possible. The data you’re looking at has been generated in some way, right? The mission for you is to find, understand & specify this process!

In our case this is fairly easy since we have an excellent mathematical model for the problem at hand, namely the Binomial model. Each data point is determined in the following way: if, after two periods, one of the teams is in front, we assign the data point the value “TRUE” [or 1] if that team goes on to win the game. Otherwise, it’s assigned “FALSE” [or 0]. The event “TRUE” [1] is assumed to occur with probability p [this is the parameter we’re trying to estimate] while the complement, the team being up at 2/3 of the game yet losing it, occurs with probability 1-p.

Note that if there’s a tie in the game after two periods, we exclude it from our research.

Therefore, after N such games, the number of 1’s is distributed according to a Bin(N, p), a binomial probability model with N = number of games with one team in front after two periods & p = probability of a team winning *given* in front after 2/3. Equivalently, since a Binomial is a sum of Bernoullis, our problem could of course be modeled as a sum of N Bernoulli(p) random variables as well.

Bayes, step 3

In step 3 our mission is to code up a Bayesian algorithm that has the ability to learn from the data we’re feeding it. To do this, we’ll be using PyMC, a probabilistic programming language in Python.

PyMC is a probabilistic programming library for Python that allows users to build Bayesian models with a simple Python API and fit them using Markov chain Monte Carlo (MCMC) methods.

For now, don’t worry about the intricacies of PyMC [autism overload]. Bayesian models become mathematically intractable *extremely* fast [they’re terrible to work with using “pen & paper”-methods] & MCMC is simply a class of clever algorithms that despite this helps us find [more specifically: efficiently sample from] the posterior distributions.

A simple

pip install pymc

will install the library & its dependencies.

Next, we initiate a Python program where our modelling will take place by importing PyMC & arviz [visualization library for Bayesian models].

import pymc as pm
import arviz as az

After loading the data,

# load the data, code assumes NHLData.xlsx exists in the same directory
nhldata_df = pd.read_excel("NHLData.xlsx")
case_data_uncleaned = nhldata_df.Case.to_numpy()
case_data = case_data_uncleaned[~np.isnan(case_data_uncleaned)]
number_of_ones = int(sum(case_data))
number_of_games = len(case_data)

it’s time to create our model of how the data was generated.

1. Create a PyMC model object.

   nhl_bayes_model = pm.Model()

2. Within the context of the model, define priors [in our case only one, a uniform for p [recall, p is the probability of a team winning, *given* in front after 2/3] where we assume each value between 0 and 1 to be equally likely] and construct a representation of the data generating process.

   # prior for p
   p = pm.Uniform(name = "p", lower = 0, upper = 1)
   
   
   # given values of p & N, what's the probability of seeing K games satisfying our criterion? this is the data generating process
   likelihood = pm.Binomial(name = "likelihood", p = p, n = number_of_games)

3. Tell PyMC that we’ve observed data for the Binomial random variable [the number of games where the team in front kept the lead & won the game] by adding an extra parameter [observed = number_of_ones] to the “likelihood” variable above.

   likelihood = pm.Binomial(name = "likelihood", p = p, n = number_of_games, observed = number_of_ones)

Using this code, PyMC will now understand that it should run comparisons for all possible p's between 0 and 1 to try to understand which one of those values is most likely [or, more specifically, exactly how likely each such p is] to have generated 836 successes in 1 008 datapoints [our observed value].

Well documented code for this example is available here.

Bayes, step 4

Finally, it’s time to run our model & let PyMC help us update the prior distribution by incorporating the new data. This is generally the point at which the Markov Chain Monte Carlo stuff comes into play. For now we’ll simply consider this a black box thing and instead focus on
*the output*, a close approximation of the posterior distribution, i.e. the prior beliefs updated with whatever information was gained from the observed data.

To actually run the code that produces this posterior distribution we’ll have to add an extra line within the PyMC model context.

inference_data = pm.sample()

This tells PyMC to sample from the posterior distribution [1 000 samples by default] and generate an InferenceData object with the output. The InferenceData object offers multiple methods that allow for further analysis.

Running it yields the below output.

Bayes, step 5

Time to analyze what Bayes has taught us! Our output is currently stored in the inference_data variable/object which contains a ton of information. However, since:

1. We’re primarily interested in a basic level understanding of what the data says,

2. A plot is worth a thousand words,

we’ll limit ourselves to plotting the posterior distribution & investigate and draw conclusions from it from a visual point of view.

This can be done using

pm.plot_posterior(inference_data, show = True)

Result below.

Interpretations, comparisons, remarks

• The posterior distribution puts most of the probability around ~0.83 which makes sense since this coincides with the observed fraction in our dataset. Note however that there are no claims whatsoever of this being “the correct” fraction. Instead, it presents a clear picture of the remaining uncertainty by providing *a distribution* of plausible values of p.

• Given our uniform prior & that our data generating process is a fair represenation of reality, we can be almost certain that the true probability of a team winning a game, conditional on taking a lead into the third period, lies somewhere in the range [0.80, 0.86]. Thus we’ve managed to answer our original question.

• With another prior, we’d have seen a different posterior. For instance, if we play around a little bit and assume the true probability to in fact be 0.82 [and be stable over different NHL seasons], we’d expect to see more certainty [narrower distribution] as well as a horizontal shift towards 0.82 if we were to repeat this analysis after the upcoming season, with *this* posterior used as that season’s prior.

• Remark: Now that we’ve learnt a lot about the average, most generic probability for this kind of question, we’d perhaps like to condition on some factors to nail down more specific probabilities. For example, what about an underdog against a favourite being up exactly one goal after the first two periods?

  

  Remember: subcases like this offer less data. Therefore, if you’ve been inspired by this post and are planning to continue your betting journey by analyzing similar subcases on your own, you better sharpen your priors. If you’re not willing to go several levels down the ‘trees’ [splitting datasets on multiple variables & constantly re-performing the analysis on those mini-problems], then you’ll for sure miss out on the truly interesting aspects of your dataset. All problems are small data problems. Or, perhaps more accurately, all the GMI ones are.

Conclusion

This was a rather lengthy post with a fair bit of advanced content to digest & process. As mentioned earlier, take your time with the material. Read. Think. Read again. Or, similarly: Have a belief. Read. Update your belief.

Next up on the BowTiedBettor Substack is a Q&A.

On another note: currently in the midst of a BowTiedBettor project that will launch later this year. How about a real time data feed containing every single one of the latest *informative* odds drops?

Stay toon’d!

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Avatar!

Today we’ll have a look at a concept we’ve made a lot of money from during our time in the betting markets, namely how uncertainty/variance in a horse’s performance [this thinking can be translated to *any* game/market] affects its probabilities in different markets [win, place, show, H2H etc.].
It’s a beautiful example of how the amount of uncertainty acts as one of the fundamental pieces of the pricing process.

Before we begin: a quick poll, please answer it if [and only if] you’re a frequent reader:

Have received some interesting questions lately → a new Q&A coming up soon. If you have any questions you’d like to have answered, now is the time to ask them!

A simplified model of a horse race

Our initial mission is to construct a basic model [that we’ll be able to generate probabilities from] of a horse race. This will help us prove and clarify the main results of today’s text.

Modelling a horse race isn’t the most trivial thing one can think of.

• Which parameters are you going to include? What’s your assumptions regarding the dependencies between the parameters?
  Note: God does probably use an infinite amount of parameters & parameter-interactions in his models. However, since we’re not gods, we must decide on a finite set of variables that approximates his outputs as well as possible.

• *What* are you even modelling? You’ll probably be interested in devising some function that’ll take your N parameters and map them into a response variable, but what is this response variable going to be?

  • The final position in the race [discrete]?

  • The probability of the horse winning [continuous in [0,1].

    Example: generalized linear regression models [logit, probit etc.].

    

  • *The* finish time [continuous] for the horse?

  • A probability distribution over possible finish times?

  • A rescaled probability distribution over an arbitrary “index/rank variable”?

In the end, we can probably agree on the fact that you, whatever you choose, must somehow define a method to map your model outputs into probabilities. *Which path* to take towards those probabilities is far from obvious though.

Suppose you go with finish time, i.e. how long it takes for a given horse to finish the race. Will your model output be a given number or a probability distribution of ‘plausible’ times?

If it’s a number [the finish time], how do you translate this into probabilities?
[Well, you could of course say that horse A [likely the favourite] will win with certainty & enjoy staying poor.]

If it’s a probability distribution [of plausible times], how do you proceed? Do you let simulations generate the final probabilities?

You simulate a value for each horse, sort this list, let that be the result/order of the simulated race [what are the assumptions here?], and repeat this process for a large enough number of “races” [read: simulations].

As you can see, there are many tricky questions to consider and analyze if you decide to embark on the journey of trying to come up with a great & useful model for horse racing. However, since those questions/problems aren’t the main subject of today’s discussion, we’ll refrain from spending too much time trying to come up with plausible [and complex] answers to them.

Instead we’ll assume a heavily simplified but, for our purposes, informative model:

Model:

• A model of finish times has been constructed, which is capable of generating a normalized probability measure/distribution for each participating horse’s finish time *with perfection*. The normalization is such that the finish time is defined as deviation from average finish time for the race [with the sign flipped to make large number = good number].

  Comment: Normalizing stuff can often be a nice thing.

• Horses are assumed to run independently, i.e. knowing something about horse A’s performance tells you *zero* about horse B’s.
  Comment: Probably not way off for standard horse racing, however less reasonable for harness racing. The reason for the assumption: it lets us avoid having to deal with joint probability distributions [if horse A’s performance told you *anything* about horse B’s, then you’d have to take this fact into effect while running simulations, something we’d prefer to avoid].

• The probability distribution for the finish time of each horse is assumed to be normal.

  Comment: False but the normal distribution is the only one 95 % of you have seen + there’s no cost in keeping at least some parts simple here.

When the probability distributions have been generated, the win probabilities are generated as follows: a value is simulated from each horse’s probability distribution & the horse behind the largest value is assumed to be the winner of the race. This step is repeated 10 000 times. The win probability for a given horse is then defined as the number of wins divided by 10 000.

Horse race with 5 participants

We have a race with 5 horses and want to apply the above model.

Let the probability distribution of horse A be the below [N(0,1) in case you’re interested].

Next we add in the remaining four horses, all with varying means and variances.

Now let’s run the [10 000] simulations and check what the correct odds for the different horses in the race should be!

Before we look at the result, try to answer the below three questions. Write down your answers on a piece of paper:

• Which horse is most/least likely to win the race?

• Which horse is most likely to finish in the top 3?

• In a H2H between horse 3 [green] and horse 5 [purple], which one of them should be the favourite?

Done?

Let’s check the results!

As usual, you find the code for our examples on Github [LINK].

Simulation results

The result of the 10 000 “races”:

Horse 1 won 8 % of the races.

Horse 2 won 31 % of the races.

Horse 3 won 33 % of the races.

Horse 4 won 9 % of the races.

Horse 5 won 19 % of the races.

Conclusion: Horse 3 [green] is most likely to win the race. Horse 1 [blue] is least likely to win the race.

Thus the correct win odds are as follows:

Horse 1 - 12.50

Horse 2 - 3.23

Horse 3 - 3.13

Horse 4 - 11.11

Horse 5 - 5.26

Doing the same thing for the top 3 positions yields the following correct set of show odds:

Horse 1 - 1.60

Horse 2 - 1.57

Horse 3 - 1.81

Horse 4 - 3.45

Horse 5 - 1.12

Conclusion: Horse 5 [purple] is most likely to finish in the top 3, with a probability of ~ 89 %.

Let us now have a look at the final question of the little quiz, the H2H between horse 3 [green] and horse 5 [purple]. Recall that horse 3 was almost twice as likely to win the race.

H2H-probabilities:

Horse 3 [green] - 43 %

Horse 5 [purple] - 57 %.

Conclusion: Even though horse 3 has a significantly higher win probability, it still fails to beat horse 5 on a H2H-basis.

Indeed very interdasting results! Or, perhaps you’re not as amazed as we are?

Well, let us explain and make sense of what we’re talking about by really diving into those results now!

• Before we begin our analysis, note that in reality *you never get to see* the true, underlying probability distributions of each horse, *you only know that they exist*. However, what you *do see* is the odds board for the different available markets, win, place, show, exacta, trifecta, H2H odds and so on and so forth.

  ---

  A DIALOGUE: [not that we do this in practice lol, but it’s an interesting concept]:

  BILL BETTOR: Assume a model. Do some magic to generate the correct probability distributions for each horse in the race. Voila, you can now produce the true odds of any possible bet that may be offered, right?

  Degen Gambler: Sounds cool, but what’s this magic about and how am I supposed to find the “correct” probability distributions?

  BILL BETTOR: You’re not!

  Degen Gambler: What do you mean?

  BILL BETTOR: Are you constantly shown odds of almost any possible bet that may be offered?

  Degen Gambler: Yes, the number of different markets to bet on is just crazy.

  BILL BETTOR: Good. If someone showed you his distributions, would you be able to say whether they were perfect or not?

  Degen Gambler: Yes, probably, no one’s perfect though, right? And it’s definitely easier to find errors than to generate truth.

  BILL BETTOR: Indeed it is. However, some do in fact claim that this guy is perfect. Perhaps they’re right.

  Degen Gambler: Who? I’m confused.

  BILL BETTOR: Look deeper. Someone’s showing you his distributions.

  

• Back to the results.

  Something very interesting: Purple clearly beats Green in the H2H, but Green is much more likely to actually win the race! In fact, since Purple has the *highest mean performance* of all 5 horses, no matter who we match it up against, it *must* be the favourite in the corresponding H2H [for the turbos this is obvious since normal distributions are closed under addition and Purple’s mean is the largest one in our race].

  Thus, against any horse it is the most likely H2H-winner, yet it does only have a winning probability of 19 % [two participants have significantly higher win probs]!

  This is because Purple always delivers approximately the same performance, while the performances of his opponents come with greater variability. Against *a single* opponent he’s the favourite, but as more and more horses [with greater variance] are added it becomes increasingly more likely that *at least one* of the remaining horses will put up a great race, which is enough for Purple to fail to win. Add in another 10 horses and Purple is *down bad*!
  
  Uncertainty matters!

  In a big field, the consistent, “average” horse is without chance.

• Continuing our comparison between Green and Purple we note that Purple has a much higher probability of finishing within the top 3 positions [89 % vs 55 %]. In such a small field, the consistency in Purple’s performances makes it almost certain for the horse to show. Green however is a much more complicated animal, either he puts up an excellent race and wins, or he’s simply not having it and finishes at the back of the field. And this is not a good thing for the place & show markets! Conclusion: the relationship between the win, place and show markets are severely different for the two participants.

• Finally: here’s the main point of this post. Win markets are easy objects. It’s the one thing everyone spends their time on.

  Where is the intuition, the beauty, the fun in 1 200 trifecta permutations? Right, there is none! In win markets all you need is to find the best horse! What a beautiful game. 10 horses racing side by side, fighting to cross the finish line first. Of course you love it.
  And indeed you’re not alone.

  ---

  
  So everyone invests a lot of time and resources into this part of the game. And soon they for sure become pretty good at finding the winner. In some cases, even extremely good.

  
  BUT WHAT DO THEY DO NEXT?

  They notice the rest of the markets. And having obtained great estimates of the win probabilities, they of course do the obvious thing.
  They simply map their win probabilities into place, show, H2H, exacta, trifecta and even more complex probabilities.

  & they spend tremendous amounts of time looking for the “perfect link” [the holy grail] between the win probability and the remaining probabilities. [Go ahead and Google “Harville Formula” [psyop] & all its variations]

  & bookies even include those maps in their algos [think long & deep here ser].

  And somehow [what a surprise] those maps have a tendency to map favourites into favourites, and underdogs into underdogs, *across all markets*.
  Which our dumb little model of normal distributions has just shown can be so incredibly wrong!

Remember:

1. It’s easier to find errors than to generate truth.

2. If you bet multiple [connected] markets, *always* separate them out when analyzing your P&L.

3. Completely random fact but whatever: when you read something online on betting, always assume it’s psyop. Especially when it comes to betting software. “Why am I offered *this* set of functions? What am I *not* offered?” should be your first questions.

That’s all for today.

Next time there’ll be less autism.
Until then…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Betfair is a British gambling company which operates the world's largest online betting exchange. Betting exchanges are important factors in the betting industry since they’re offering more serious actors/bettors a way to participate in betting markets without having to deal with the ordinary, in many cases absolutely terrible, bookmaker model which restricts/limits any sharp action [in fact, standard bookmakers are probably closer to “marketing companies” than they are to “betting companies”]. Owing to this, the exchanges attract a great amount of clever customers which in turn generates liquid order books and significant betting volume.

With a satisfactory share of sharp volume these platforms have evolved into some of the most efficient and informative ones currently available, hence providing an excellent opportunity for aspiring bettors to learn the fundamentals [and more] of how to price uncertainty.

To understand the basics of the betting exchange model, consult our Betting 101.

Note: “Liquid order books and significant betting volume” depends on the specific markets you’re looking at as well as who you’re asking. The point: mostly it’s much better than what’s offered with standard bookies.

Note: There is often hidden liquidity [iceberg orders, see e.g. The impact of hidden liquidity in limit order books, Frey, Sandås] on the exchanges [market books convey information → information affects prices → market participants prefer hiding their intentions and present incomplete information to others → participants send partial orders programmatically instead of huge orders at once] which means you’ll only observe parts of the *real* order book.

Today we’ll familiarize ourselves with the basics of the Betfair API, an API that allows us to retrieve both historical and current betting data in order to learn from and analyze one of the most efficient betting markets, the Betfair Exchange, out there. Furthermore, the API offers all the necessary tools to create and automate betting strategies, i.e. build and launch betting bots.

Access to the Betfair API is restricted to Betfair customers only. For full access [ability to place bets etc.] you’ll therefore have to be a resident in one of the many EU countries in which Betfair is operating. However, we’ve figured out a way for our US subscribers to get partial access [retrieve odds, analyze historical betting data, …] by setting up “dummy accounts” and we believe that should be good enough for 99 % of our subscribers at this point in time.

Let’s go!

Note: Our coding/programming material assumes that you have some familiarity with Python. If you do not, please get started today. Learning Python is definitely one of the most +EV decisions you can make if you are interested in earning WIFI-money. Combine Corey Schafer and Automate the Boring Stuff and you will soon be an excellent herpetologist.

Create a Betfair account

If you’re in the US, follow the account setup guide below.

If you’re in the EU and Betfair *does not* operate in your country, follow the account setup guide below.

If you’re in the EU and Betfair *does* operate in your country, you simply sign up with them the ordinary way. This is the best case since it will allow for full access to the API.

Guide for US subscribers [and EU unless Betfair is accessible in your country]

Step 1: Use a VPN and connect to a UK server. [Any VPN will do, we use Mullvad since they’re crypto & privacy friendly + a great bunch of autists like them].

Step 2: Visit https://www.betfair.com. Click “Join Now”.

Step 3: Fill in the form, just go with dummy details [example in picture below]. However, make sure to remember/write down the email address and the password since you’ll need them to access the Betfair account. Moreover, you may at some point have to verify the email address → use one you’re able to access.

Step 4: After finalizing the previous step, you’ll now arrive at an “automatic check” where Betfair is trying to verify your details. This process will of course fail and you’ll instead be redirected to a new page. Click “All details are correct”. Again you’ll be redirected to another verification page asking you to upload supporting documents to verify your identity. However, at this point we’re already done since the account has been created which is all we need. Close the pop-up window and return to https://www.betfair.com [you should be logged in by default].

Generate an API key

Time to get an API key!

To do this, you’ll want to head over to this website, at which you should be presented with the below view.

Note that you need a Session Token (ssoid). You can find this token by heading back to the Betfair Exchange landing page [if you’re getting more “you need to verify your account” messages, just ignore them] → right click → “Inspect” → “Storage” → “Cookies” → locate the one marked ‘ssoid’. Finally, copy pasta this session token into the box, then click on createDeveloperAppKeys → fill in an [arbitrary] “Application Name” → click on “Execute” at the bottom of the page.

When you’ve completed the above steps your “Application” should show up on the right hand side as in the above picture. Click on it and copy the application key corresponding to the one with version “1.0-DELAY”. Save this key at a place where it’s easily accessible [notes or whatever], it’ll be used every time we write code that calls the API.

Notes:

• The Delayed App Key operates on the live (production) Betfair Exchange and not a testbed/sandbox environment.

• The Delayed App Key should be used for development purposes and any functional testing. The key provides delayed Betfair price data. The delay is variable between 1-180 second snapshots.

Note: If you’re finding this interesting/useful, please consider reading Betfair’s own API documentation as well.

betfairlightweight

Since we’re coding in Python, we’ll be using a [excellent] Python wrapper, betfairlightweight, for all our Betfair API material. This library/package allows for all the available API operations and simplifies the stuff we’ll be interested in doing tremendously. Instead of having to spend an enormous amount of time coding up a bunch of classes [with terrible performance, zero security & thousands of bugs] that sends & handles requests & responses, we take advantage of the fact that a bunch of turbo autists have done this exact thing for us already.

Begin with running

pip install betfairlightweight

to install the library.

Basic operations, set up and close a session

Nothing teaches coding as well as sample code. Hence, let’s jump straight into it and perform a couple of trivial operations in order to get some basic experience with betfairlightweight.

Below we’ll learn how to set up and close a session with the Betfair API.

To begin with, we have to define three variables that are required to establish a connection, username [use the email address you registered], password and API_key. As soon as they have been defined we set up an APIClient object [frequently named “trading” in the betfairlightweight documentation so we’ll go with that here as well] taking those variables as parameters.

Code below.

import betfairlightweight

username = "INPUT EMAIL ADRESS"
password = "INPUT PASSWORD"
API_key = "INPUT API KEY"

trading = betfairlightweight.APIClient(username, password, app_key = API_key)

Now, calling

trading.login_interactive()

establishes a connection/session with the Betfair API. To check whether this connection is up and running you can do

trading.session_expired

which returns False → our session is live.

Note: When the connection is established an automatic timeout of 12 hours is applied.

Doing

trading.logout() 

terminates the session which can be verified by another

trading.session_expired

now returning True.

A couple of useful links below.

Github repository [many hours have to be spent analyzing the code to “fully understand” how everything’s connected]

Documentation [not too much material but at least a couple of brief examples]

Slack group

Summary

Since more fruitful examples require a deeper understanding [of betfairlightweight & the Betfair API] and this is supposed to be a *gentle* introduction, i.e. a brief presentation with a concise set-up guide, we’ll reserve the practical & therefore more interesting content for future posts.

Nevertheless, if you’re curious and would prefer to delve deeper ASAP, we’d recommend checking out our Github Betfair API material, which e.g. contains full support for automation of the hedging process for bonus rugging.

The idea is the following: instead of wasting precious time recruiting & speaking to new BR-prospects 24/7, you hire someone to do this. This person is then responsible for both the communication and the placement of bets on *their* sportsbook accounts. Every evening, he sends you an Excel file [predefined template] with all the new [unhedged] bets → you run the script which reads the Excel file and hedges the bets, one by one, at Betfair. Efficient, right?

[Now repeat this process by hiring a second person ;)]

Expect more interesting Betfair API material to pop up at a regular basis. In the next post on this subject we’ll probably have a look at historical data and how you can utilize the betfairlightweight library to parse the relatively unfriendly files Betfair provides you with.

Closing note: We fetch and use odds data from the Betfair API multiple times a week to beat less efficient markets [“pick the winner in 7-15 games” and similar multi-game bets are very popular in some parts of the world]. betfairlightweight + itertools, IYKYK.

Until next time…

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Degen Gambler!

Suppose that you’ve managed to develop a promising betting model. The basic backtests have been looking good and by now you believe the time has come to test it live. You’d however prefer to have gained some insight regarding the sequence of bets that you and your model are about to generate prior to launching it. Questions such as the following arise:

• What’s there to “expect” from the bet sequence/process? Which paths are possible, which are plausible?

• What’s the probability of losing money over, say, 420 bets despite having an average EV of, say, 10 %?

• What’s the necessary amount of settled bets to reach any kind of conclusion regarding the efficiency of the model?

Note: Efficiency of a betting model = does it make money or not? Everyone can hit +80 % during a NHL season [bet all the < 1.20 and you should be good], this number alone tells you absolutely nothing. Probabilities don’t put food on the table, payoffs do.

Today, we will make an effort to provide solutions to such inquiries. We will conduct a comprehensive examination, utilizing both classical probability theory and modern simulation techniques, of the cumulative P&L (profit and loss) and ROI (return on investment) - two random sequences/processes created by placing numerous bets within a certain time frame.

A mathematical perspective

When faced with a theoretical problem, one of the most powerful approaches is to break the problem into small pieces, gain insight about those, then reconstruct and give the initial problem a second try, now equipped with the newly attained knowledge and a greater understanding of the matter.

A betting sequence/process is, as the name suggests, a sequence of bets, with bets arriving one at a time. Therefore, by way of the above approach, we begin by breaking the analysis of the full sequence into a smaller subproblem, in this case an examination of a single bet, or perhaps more relevant for our ambitions, the P&L of a single bet.

Note: One could throw away either one of odds, expected value or probability from the above definition without any loss of information (why?). For clarity we’ve nevertheless chosen to include all of them.

What’s a random variable, one might ask? Easy! A measurable function from a probability measure space to a measurable space. WTF? Yep, just kidding.

For our purposes a random variable is a variable that can take a finite amount of values, each with a certain probability and such that the probabilities add up to one.

Example: X, a variable that holds information about the result of a flip of a coin, is known to always evaluate to either 0 or 1. With probability 0.5 [heads] it’s 0 and with the remaining 0.5 [tails] it’s 1. Thus, X is a *random* variable since it depends on the outcome of the coin flip [a *random* experiment].

To proceed in a similar fashion as in the example above, we’d like to come up with a precise “random variable-definition” of the P&L of a bet. Since we want it to possess complete information regarding the result of the bet, we’ll let it take two possible values.

Recall that S = stake and O = odds. In other words the P&L random variable keeps, as the name suggests, track of the net profit/loss obtained from the bet. If the bet wins, it evaluates to the net profit [stake x net odds = net profit]. On the other hand, if the bet loses, the full stake is lost and so the P&L becomes negative the stake [-stake = net loss].

Indeed, this definition seems reasonable.

Having solved this subproblem, we now return to the original mission. To analyze the full cumulative P&L process we’ll have to take all the n bets into account, not only one of them. But this is easy, right? We simply repeat the above procedure for each and every bet in our sequence. Then, when this has been done, we sum them all up to generate the cumulative P&L.

Furthermore, let’s do a slight adjustment and see if anything of interest may appear: we divide the cumulative P&L by the total turnover [sum of all stakes] during the period,

Interesting!

At this point we’ve managed to construct formal random models [random since they both depend on the outcomes of the games the bettor is placing bets on] for two crucial betting processes, the cumulative P&L and the ROI. Thus we are in a good position to further deepen our exploration of them and analyze their different properties:

• Distributional properties. Perhaps we’re interested in the full probability distribution of the ROI after the first 200 bets. Is this possible to obtain?

• Convergence properties. Do the measures converge, and if so, how fast? As mentioned in Betting 101, we somehow ‘feel’ that the ROI should converge to the true, underlying EV as the number of bets increases. Meanwhile, it seems unlikely that the cumulative P&L will converge to anything. If we’re betting +EV games it’ll drift upwards, else it’ll drift downwards, right?

  Autist challenge: can you come up with examples where the cumulative P&L in fact does converge?

Cumulative P&L

As already mentioned we don’t expect interesting things concerning convergence to pop up here.

What about its distributional properties?

In general, with zero restrictions/constraints on the behaviour of the individual bets we cannot say much. Well, we may note some trivialities,

• Being a sum of a collection of discrete random variables, the cumulative P&L must itself be discrete.

• Expectations behave like “expected”.

  

• Assuming independence between bets we discover that the variance increases with increasing n. This agrees with our intuition and is a consequence of the fact that the cumulative P&L is an unnormalized measure.

  

  Note: The assumption of independence between bets could be invalid for many reasons. An example: several bets in one horse race. Another: a degen gambler increasing size with drawdowns to ‘win it all back’.

but to obtain general information regarding the resulting probability distribution we’ll have to resort to Monte Carlo methods.

Monte Carlo methods are a class of computational techniques that use random sampling to estimate numerical solutions to problems that may be difficult or impossible to solve using ‘standard’ methods. With zero structure [as in this case with varying stakes, odds & probabilities], the generation process of the cumulative P&L becomes an excellent example of such a problem.

ROI

In our Betting 101, the following was stated,

There is an interesting connection between the expected value and the ROI measure. If one views the expected value as an abstract concept handling “true” probabilities, the ROI measure is its practical counterpart, only taking a finite, often small, sample into consideration. However, as the number of bets increases one may expect the ROI to converge to the true EV of the betting sequence, making them both more or less equivalent. A more detailed discussion on this is coming! 

Expecting & believing something is one thing. Actually proving it is another. Moreover, during the course of testing a hypothesis, it is common to uncover significant flaws in your current understanding and gain valuable insights that had not been previously considered.

Therefore, let’s try to prove our hypothesis: that the ROI does in fact converge to the true EV as the number of bets grows large.

ROI - Trial #1 [zero assumptions, full generality]:

Recall the ROI measure:

To prove that a random variable [in this case the ROI measure] converges to a given real number, one has to show that by picking a large enough number of bets, one is “guaranteed” to come “arbitrarily” close to the given value.

Autist note: Unfortunately the notion of probabilistic convergence is far from straightforward, making it difficult for us to be 100 % precise here. There are four different kinds of convergence [conv. in distribution, conv. in probability, conv. almost everywhere, conv. in p’th mean], all suitable for different occasions. To simplify matters we’ll restrict ourselves to convergence in probability which translates into the following: you give me *any* probability [say 0.05] as well as *any* small number [say 0.005]. Then, if I’m able to provide you with a large enough number of bets [say 12 000] such that the true probability of the ROI being outside the “small number-distance” [0.005 here] of the EV is *at most* the provided probability [in this case 0.05], the ROI is said to converge in probability to the EV.

With zero assumptions, the statement ‘the ROI converges to the EV’ will however be a very, very difficult proposition to prove. Why? Because it’s simply not true. Without restrictions on the stakes, probabilities and odds, there are a myriad of counterexamples that make any kind of convergence impossible.

Example of a counterexample: A bettor has taken the notion of ‘bet more’ literally and triples his average bet size at every 100’th bet. Thus, his ROI will at all times be heavily dependent on the ~ last 100 bets no matter how far into the future we go, ascertaining that the ROI measure will keep jumping around and refuse to ‘stick’ anywhere.

We conclude that we in fact *have to* introduce constraints if we hope to find any interesting properties.

Note: The code for all examples & simulations throughout this discussion lives here.

ROI - Trial #2 [perfect assumptions, independent, equivalent bets]:

If we instead look at the other extreme, where we assume independence and equivalence of all bets throughout the betting process, we hope to see neat convergence results. If not, well, then we won’t see convergence anywhere, right?

Example: A bettor is betting $1 on 2.00 outcomes, each with a probability of 0.55, over and over again.

Since the EV in the above example is 10 %, we expect the ROI to converge to this value [0.10].

In probability theory, one of many laws of large numbers states the following:

In our case we may identify the S_n variable in the theorem above as the cumulative P&L, and S_n/n the ROI after n bets. Since E[X] equals 0.10, with X being any one of the independent & identical bets of $1 on 2.00 outcomes [having 0.10 EV], the theorem guarantees that the ROI does indeed converge to the expected value. Great news!

The next question: how fast is the convergence? To gain some intuition on this, we’ll look at a couple of simulations prior to delving deep into the theory.

Cool, you think, after glancing at the graph for half a second. INSPECT IT FOR A WHILE, THINK HARD & LEARN INSTEAD! As you can see, it takes time, probably far more than you’d guess, to reach (or at least approximate) ‘truth’.

“Perfect world“ [independent, identical bets] ROI, theory

It’s time to continue our analysis of the ROI and its speed of convergence by going full math ‘tism, i.e. we’ll now examine the question from a purely theoretical viewpoint. To begin with, we’ll have a look at the ROI’s distributional properties. In fact, once the complete probability distribution of the process is derived, determining the process's position at various points in time becomes straightforward. This, in turn, makes it relatively easy to determine characteristics such as the rate of convergence.

Finally, we conclude this section with plots of the probability distributions [pictures tell more than thousands of equations] of the ROI for different N. Code as before on Github [LINK].

Welcome to Monte Carlo!

Now that we’ve analyzed the two edge cases, zero constraints and a maximum amount of constraints, we’d like to see what share of the assumptions we can drop while still retaining the nice convergence properties [since all bettors love to shout about the law of large numbers, it would be sad if it didn’t even apply to their betting, wouldn’t it?].

A non-triviality arises quite quickly though. As we begin dropping off assumptions, the theoretical parts, which by the way are on a quite sophisticated level already, will soon become more or less impossible to handle. Consequently Monte Carlo simulations will be the only reasonable way forward and therefore we’ll at this moment make a full transition into analyzing bet sequences purely on the basis of simulation techniques.

Autist note: If you’ve come this far & actually want to understand [using maths, not code] the precise assumptions one may drop without removing ROI → EV, we’re happy to discuss this further either in DM’s or in our Discord server.

Playing around with and meditating on simplified Monte Carlo simulations, or "alternative histories", is the best way to figure things out.

Simulating alternative realities

To make matters more interesting, we’ll have a look at a real data set containing actual betting data.

Somewhere in the world there’s a bettor applying a specific horse racing model on a daily basis. Earlier this week he placed his 500’th bet for the year with this model and after pondering the result for a while he’s curious to learn how much of an outlier the latest 500 bets have been. From earlier investigations he’s almost certain that the true EV for the model is ~ 0.15. Furthermore, he’s also interested in discovering the likelihood of the ROI conditional on an EV of -0.15, the default margin applied by the bookmakers in the markets he’s operating in.

He’s been kind enough to provide us with an Excel file containing the data for the 500 bets.

Bettingdata

80.3KB ∙ XLSX file

Download

Download

Okay, let’s help the bettor!

We’ll run two experiments. In the first case we’ll assume that the EV is constant at 0.15/bet, in case 2 the assumption will be an EV of -0.15/bet. By using the odds [from the data file], the probability of a given bet winning is easily calculated as:

For each case we’ll then run 10 000 simulations for the cumulative P&L and 10 000 simulations for the ROI to learn a bit about which paths are possible and which are plausible.

Note I: For simplicity we’ll restrict today’s analysis to a sequence of 500 bets, i.e. the exact length of the historical data file. If one would like to investigate the matter on a longer time-frame [e.g. 1 000 or 10 000 bets] and/or begin with a smaller data set, we’d recommend using bootstrapping techniques to generate a sequence of wanted length.

Bootstrapping is a statistical method that involves resampling from the original dataset to create new samples that are used to estimate statistical properties of the population. The idea is to simulate the process of randomly drawing new samples from the same population to better understand the uncertainty associated with our estimates. Bootstrapping is useful because it allows us to simulate random processes and estimate the variability of our estimates without having to make assumptions about the underlying distribution of the population.

Note II: The assumption of a constant EV throughout a bet sequence is *always* invalid in practice, and even more so in cases where the gambler doesn’t operate within a certain odds range [as in our case, take a look at the data]. To illustrate why, suppose there’s a 1.04 bet included in the data. Then this bet automatically disqualifies all the other ones from an EV of above 4 %, which of course is nothing but stupid. However, to incorporate this into what we’re doing we’d have to include both randomness as well as an odds-dependence in the modelling of the EV, a procedure that is better left for the real turbos to perform on their own.

We proceed by creating two new columns with the assumed probabilities for each game. Next we load the updated dataset into Python. After that we’ll simply run the 10 000 simulations and see what happens. Additionally, the total stakes [which is a necessary metric to calculate the ROI] during the bet sequence was $112 768, a number we’ll simply hard-code into the Python program.

Case 1: +15 % EV

Results of the simulations below. Note that the actual ROI for our bettor was ~ 33 %. According to the simulations and assuming a 15 % EV, obtaining either this or an even higher ROI has a probability of ~ 7 %. Moreover, it should be observed that the probability of losing money over this 500 bet sequence, despite the +15 % edge, is about 10 %.

Statistical note: You may recognize this 7 % value from the statistical literature as the p-value [if you’re a p-value guy → definitely NGMI, 100 % a measure made for ‘tards] for the test of “EV is 15 % or less”.

Case 2: -15 % EV [default margin, i.e. betting randomly]

Again results below. This time the probability of obtaining at least such a ROI [33 %] has dropped severely to ~ 1/1000 [good news for our friend!], while the probability of losing money has increased to ~ 92 %.

Inverting the process & learning the truth the Bayesian way

Up until this point we’ve, perhaps without you even noticing, restricted our analysis to a certain perspective. Throughout the exploration we’ve *conditioned* on a specified EV and, *given* this EV, investigated possible real-world realizations. Indeed, if you’re fairly certain about your EV, this is an informative way of learning what the future may have in store for you. However, this is rarely the case in reality, right? In the real world no one really knows their true EV. Therefore, a more realistic and hence more interesting question is the converse: *given* a certain P&L, what conclusions can you draw about your EV?

Having read both our introduction to conditional probability & Bayes Theorem as well as part 1 in the Bayesian thinking & inference-series, the inverted thinking in the above paragraph should remind you of something. Indeed, Bayes!

So far, we’ve been working with the following probability,

however in practice we’re primarily concerned with the converse,

since after observing a ROI for our real world betting, we’d like to learn about the underlying EV to conclude whether our model is any good or not.

Using Bayes Theorem, we have,

with P(EV) the prior probability of the EV [which incorporates our initial beliefs of the quality of the model/bettor] and EV_range the range of possible values the EV might take. In plain english, what we’re doing is the following,

To illustrate the method, we’ll in fact do exactly as in the above description and assume the EV to, with probability one, be in the interval [-0.5, 0.5]. Furthermore, to simplify things we’ll assume a uniform prior over this interval [i.e. our initial belief is that any EV between -50 % and +50 % is just as likely]. Then, we’ll *learn from the data* and update the probability of different EV’s accordingly. As more data arrive we continually adjust our distributions and beliefs.

Note: You’ll never agree with anyone on the choice of prior, but who the f*ck cares. We’re not here to write papers and engage in pointless discussions, but instead to learn betting & make money off that knowledge. If your priors are bad you’ll lose money. If they are good you’ll make money. Easy as that. If you’re investigating a newly launched bet picking service and you believe the founder of it to be extremely talented, of course you’ll want to incorporate that belief into your prior model and probably invest in him at an early stage. On the other hand, if you deem him stupid, you’ll give the negative EV’s greater weight & require him to perform on point for much longer until you’re convinced he knows what he’s doing. Makes sense, doesn’t it?

Output from the Bayesian analysis of the historical bets made by the horse racing bettor below. Inspect our code if you’re curious about the computational aspects [highly recommended, you’ll learn a lot by thinking about the logic of a Bayesian inference tool, in this case a very basic one].

Learning from data is sloooooooow… probably much slower than you’d think before seeing those graphs.

*Note that all the results rely on the constant prior assumption.

Conclusion

If you’ve made it this far you’re a certified autist so congratulations on that!

Concluding remark: what was to be said, has been said. We hope you’ve picked up a decent chunk of knowledge on the development of a bet sequence through time, and wish you best luck with *yours*!

Stay toon’d for more interesting betting material.

Until next time…

Give a gift subscription

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

This is the official “directory” of the BowTiedBettor Substack.

The purpose of this is to provide you with a logical way/order to read the articles.

This page will be updated periodically to keep some type of continuity as we jump into more advanced concepts [this will become increasingly important as you’ll at some point, in some cases already, need to read certain posts before reading the newer ones].

The content has been subdivided into three segments.

• “Start here!”, beginner material. Recommended for everyone but in particular for novices.

• “More involved betting concepts”. General betting material. Requires familiarity with basic betting concepts in order to be properly understood.

• “Coding”. Coding/programming is becoming increasingly important for bettors and this segment covers all things code. Requires basic Python knowledge.

Depending on whether you’re new to betting or have been in the game for a while, there are different recommended paths for you to take.

New to betting?

Welcome!

Begin by reading the “Start here!” stuff thoroughly. If your goal is to actually understand betting, it’s extremely important to build from first principles.

After doing the above, you’re now standing on firm ground. Continue your adventure by delving deep into the “More involved betting concepts”-jungle.

And, if you’re intrigued by coding, complement the “More involved betting concepts” with the “Coding”-segment.

Experienced bettor?

Welcome!

Head straight to “More involved betting concepts” and begin there.

As for the novices, if you’re intrigued by coding, complement the “More involved betting concepts” with the “Coding”-segment.

Start here!

Welcome to the BowTiedBettor Substack! - [Level 1 - NGMI] - Our first post.

Betting 101 - [Level 1 - NGMI] - This post explains the basics of betting and provides solid information on many important betting terms. Odds, probability, implied probability, EV, ROI, variance, RTP…

More involved betting concepts

Conditional probability & Bayes Theorem - [Level 2 - DEEP DIVER] - The art of conditional thinking is most definitely a hack, not only in betting. This post presents the basics of it.

Practical aspects of betting - [Level 2 - DEEP DIVER] - What’s required to run a successful betting operation? A discussion of day-to-day stuff such as limits, multi accounting, price discovery & much more.

Adverse Selection in Betting Markets - [Level 2 - DEEP DIVER] - Start thinking about your counterparties, how they’re reasoning & what they’re doing, or keep getting picked off…

Learning from Odds Moves - [Level 3 - WAGMI] - Is your source a good source? Who’s behind the weird orders in the UK dogs market? Just. Track. It.

A Thought Or Two - [Level 4 - WAGMI 2.0] - A thoughtful treatment of market efficiency via a development of a precise distributional framework. Contains the true reason for why the Cartoon Horse keeps shilling Bayes!

Bayesian thinking & inference, part 1 - [Level 4 - WAGMI 2.0] - Learn how to learn from data, the bayesian way.

Bayesian thinking & inference, part 2 - [Level ∞ - BILL BETTOR] - What’s the probability of a NHL team winning a game, conditional on taking a lead into the third period? This post offers a Bayesian perspective on this fairly trivial question. Includes probabilistic programming in PyMC, an overview of the Bayesian workflow & some deep insights regarding data.

An initial look on the Kelly Criterion - [Level 4 - WAGMI 2.0] - Kelly is our favourite betting concept & it’s so much more than the stupid simple formula everyone refers to. Here’s an introduction to it.

The generalized Kelly Criterion - [Level 5 - SHARP] - A second look at the basics of the Kelly Criterion, now from a multidimensional point of view.

The Power Of Simulations - [Level 5 - SHARP] - Bootstrapping in Monte Carlo? Magic! Get to know one of the most *powerful* frameworks a bettor might equip himself with...

Bet sequences, an analysis - [Level ∞ - BILL BETTOR] - A comprehensive examination of bet sequences - the random sequences/processes that arise when a bettor places numerous bets within a certain time frame. P&L’s, ROI’s, Monte Carlo methods & Bayesian inference.

The art of pricing uncertainty - [Level ∞ - BILL BETTOR] - Discusses how the amount of uncertainty naturally acts as one of the fundamental pieces of the pricing process, as well as how it at times can yield unintuitive results. 

Building & Deploying a Betfair Bot - [Level ∞ - BILL BETTOR] - Option Number One: stay at the desk 24/7, scan the markets manually to look for opportunities where you could run The Trade, & then run it if certain conditions/requirements are satisfied. Option Number Two: map your thoughts/conditions into code & let your computer perform the tasks for you.

Coding

Note: Our coding material assumes that you have some familiarity with Python.

Betting meets automation - [Level 2 - DEEP DIVER] - A brief discussion of what automation can bring to the betting table, combined with a note or two regarding when it does & when it doesn’t make sense to convert ideas into code.

A gentle introduction to the Betfair API - [Level 3 - WAGMI] - Introducing betfairlightweight & the Betfair API. Learn how to set up a Betfair account, generate an API-key and perform some basic operations.

Build your first odds scraper - [Level 5 - SHARP] - This post lets you acquaint yourself with Selenium, a browser automation tool suitable for scraping sports betting websites. Here, we utilize it to fetch NHL data from Unibet.

Scraping time… Selenium too slow! - [Level 5 - SHARP] - The most efficient way to gather online data is to mimic the behaviour of your web browser. Learn how in this post, where we again construct a simple Unibet NHL web scraper, however this time using more straightforward and considerably faster methods.

DraftKings scraping project, part 1/3 - [Level 5 - SHARP] - Nothing teaches you web scraping like a real web scraping project. Follow along as we initialize the creation of a complete DraftKings scraper.

DraftKings scraping project, part 2/3 - [Level 5 - SHARP] - Part 2 of our DraftKings series. As we transition into live odds scraping/streaming, the autism intensifies. For instance, you get to know the basics of the two Python libraries websockets & asyncio.

Levels

As you’ve probably noticed above, the posts within each segment have been assigned a certain level. Level 1 & 2 is meant to offer a simple and straightforward view of the world of betting and will stay FREE to offer insight for possible prospects. 3 & 4 are of medium difficulty while higher levels are intended to be *hard* in order to keep all the turbo autists satisfied.

Level ∞ - BILL BETTOR - Automated betting, exchange-API usage, advanced money management, model building, advanced Bayesian thinking.

Level 5 - SHARP - Exchange trading, web scraping, Bayesian models.

Level 4 - WAGMI 2.0 - Money management, optimizing portfolio growth.

Level 3 - WAGMI - Get started, collect your first 5 000 USTT.

Level 2 - DEEP DIVER - Delving deeper into the world of betting.

Level 1 - NGMI - Explaining the basics.

Note: If you prefer to proceed by level of difficulty, visit the BowTiedBettor website archive to have our posts sorted according to levels.

Finally: Hope you’ll enjoy the content!

Until next time…

Subscribe now

Disclaimer: None of this is to be deemed legal or financial advice of any kind. These are *opinions* written by an anonymous group of mathematicians who moved into betting.

Share BowTiedBettor

Welcome Avatar!

Today we are back with the second part of the DraftKings web scraping project. In case you haven’t read part 1 yet, head straight to DraftKings web scraping project - Part 1/3 and begin there.

First, we begin by recalling what was done in part 1:

• A DraftKings class was constructed for the purpose of holding all our useful scraping methods.

• Two scraping methods were created, the rather lengthy get_pregame_odds [which is used for scraping pregame markets] and the more concise store_as_json which allows us to dump any scraped pregame content into a local file.

• Basic tests for the pregame scraper were performed and everything looked good [unless there’s money on the line, only the virgins care about proper testing procedures].

Since the above three bullet points sum up and confirm the completion of the first part of the project, the pregame scraper, it’s time to take up the next mission, the live odds scraping/streaming.

Background information

A warning: from here on the autism intensifies quite a bit. If you at times feel discouraged while digesting the content and the explanations, you’re definitely not alone. Keep going!

A natural start is to discuss and install the necessary dependencies. DraftKings uses the WebSocket protocol for their live odds data and in order for us to interact with it we’ll need two Python libraries, websockets and asyncio. websockets is built on top of asyncio, hence the need for the latter.

WebSocket is a communication protocol that allows two-way, realtime communication between clients and servers over the internet. WebSocket communication works by establishing a persistent connection (as opposed to the HTTP request-response structure) between a client and a server, allowing for seamless data transmission in both directions. This makes the protocol ideal for applications that require fast and efficient communication, such as live betting.

What’s the advantage of using the WebSocket protocol to handle live odds updates instead of the standard http response & request framework? It’s, as always, best described by an example!

Suppose BowTiedBettor wants to begin selling bet picks to his 500 subscribers and that there are two different “betting floor architectures” for him to choose between.

Alternative number one is for him to sit inside a small office. Each time one of his subscribers wonders about new bets, they open the door and enter the office [set up a connection]. Then, they get to ask him “hey, do you have any new bets to share?” [send a request], which he answers with either “yes, bet X on X”, or “no, not currently” [receive a response]. The moment they’ve received the response, they exit the office [close the connection]. This is the HTTP protocol.

Alternative number two is for him to buy a huge “betting floor”, allowing *all* of his subscribers, after a quick verification [WS “handshake”, set up a connection], in at once. Now, instead of they having to ask him the same questions over and over again [in many cases for no reason since zero new bet opportunities have arisen], they instead stay silent and *await* his information. The second BowTiedBettor locates a +EV opportunity, he stands up and shouts “BET X ON X, KELLY SAYS 0.9 % OF YOUR PORTFOLIO”. All 500 subscribers receive the information immediately and hit the bookies in tandem. Two weeks later the bookies are zeros. This is the WebSockets protocol.

More formally:

• Reduced latency: With websockets, there is only one connection established between the client and the server. This reduces the latency compared to HTTP, where a new connection needs to be established for each request-response cycle.

  Less overhead: In websockets, the overhead is reduced as the connection remains open, while in HTTP, the overhead increases with each request-response cycle.

  [Subscribers already in the same room, and staying there in between new events]

• Efficient use of resources: With websockets, the server can push data to the client at any time, making it an efficient use of server resources compared to HTTP, where the server only responds to client requests.

  [Subscribers receive the information as soon as BowTiedBettor shouts, don’t have to enter his office and ask]

A brief description of the asyncio library as well below. For our purposes it’ll be enough to know *the absolute basics* here [trust us on this, we know more or less nothing about it].

asyncio is a library in Python for writing asynchronous, non-blocking code. It provides an efficient way to run multiple tasks simultaneously and handle network and I/O-bound programs, making it a popular choice for developing high-performance and concurrent applications. This helps to prevent your program from getting stuck while waiting for a task to complete, allowing you to maximize the use of system resources.

Want to know more about asyncio & websockets? See this post by and combine it with this walkthrough of asyncio.

Note: We’ll be using Firefox throughout this project and recommend you do the same. The reason: its built-in JSON-parser & great web dev tools simplifies the scraping process tremendously.

The installations of the required packages are easily performed by running

pip install websockets asyncio

in your terminal.

Subscribe now

Live odds scraping

Okay, let’s get to it!

Note: Integrating code with Substack posts hasn’t really been optimized yet. If you prefer, you could visit our DraftKings repo and follow along by having the code open in another tab instead (*definitely* recommended).

Step 1 is of course to visit DraftKings and more particularly, their live odds page.

As of the time of this writing, there are two ongoing NBA games, WAS Wizards @ BKN Nets and LA Lakers @ NO Pelicans. Thus we’ll be scraping the NBA today.

As before, right click → inspect to arrive at the Firefox web dev tools. Visit the ‘Network’ tab. To find the relevant websocket, sort on ‘Status’ and click on one of the 101 ones. Click on ‘Response’ on your right and if you’ve found the right one you should see a constantly updating stream of messages going back and forth between you [your web browser is sending and collecting all the messages on your behalf] and the DraftKings server.

Green arrow: message from you to the server.

Red arrow: message from the server to you.

The HTTP 101 Switching Protocols response code indicates a protocol to which the server switches. The protocol is specified in the Upgrade request header received from a client.

Scroll to the top to find the first message sent by your web browser to the server. This is an important message, since it’s the one we’ll try to imitate. It should be something like the below.

In the message, the browser tells the server that we want to subscribe to all information updates related to the games with eventGroupId 42648, which, as we know from before [part 1 discussed how to find the eventGroupId for a specific league], is the id for the NBA.

Click ‘Raw’ on the right and copy the JSON-content.

Now, to establish a similar connection with the server ourselves, we create a new Python file [draftkings_stream.py] and define a function that will connect, subscribe and await new messages. Since we’re using the websockets library [built on top of asyncio] our function has to be asynchronous, a fact we inform Python about by using the keyword async in the construction of the function. A basic code block that defines a function which sets up the connection, awaits the first message and prints it, then closes the connection again, below.

import asyncio
import websockets
import json
from traceback import print_exc

async def stream(uri: str, league_id: str):
    """
    uri is the one you see in the web dev tools
    league_id is e.g. 42648 for the NBA
    """
    try:
        # connects to the server
        ws = await websockets.connect(uri)

        # sends a subscription message with info regarding the odds data we want to receive updates on
        await ws.send(
            json.dumps({"event": "pusher:subscribe", "data": {"auth": "", "channel": f"nj_ent-eventgroupv2-{league_id}"}}
                       )
        )

        new_message = await ws.recv()
        print(new_message)
        
        # closes the connection with the server        
        await ws.close()

    except:
        print_exc()

Running it seems to work just fine with both the connection and the subscription functioning as intended.

To allow for a continuous stream of messages and to handle each and every one of them properly, we expand the functionality of our code by adding a decent chunk of new properties to our function. Code below or on Github. A full description of the function is provided immediately after the code block.

import asyncio
import websockets
import json
from traceback import print_exc


async def stream(uri: str, league_id: str, event_ids: list, markets: list):
    """
    Sets up a connection with the server which is pushing new odds to the DraftKings website.
    Awaits further updates. As soon as updated odds information arrives it prints all the relevant
    information regarding the specific odds update.

    The function is meant to be called from the live_odds_stream method inside the DraftKings class

    :param uri str: URI for the web server
    :param league_id str: Id for the league
    :param timeout int: Number of seconds for the stream to keep on going
    :param event_id list: If a list of event_ids is specified [else it's None], the stream/listener considers updates
                          only if they're updates for those particular games
    :param markets list: If a list of markets is specified [else markets == None], the stream/listener considers updates
                         only if they're updates for those particular markets
                         Hint: If uncertain about market names, run it for a minute for all markets and collect the correct
                         names of the markets this way

    :rtype: Returns nothing, continues collecting and presenting new odds info until stopped
    """
    try:
        # connects to the web server
        ws = await websockets.connect(uri)

        # sends a subscription message to the server with info regarding the odds data we want to receive updates on
        await ws.send(
            json.dumps({"event": "pusher:subscribe", "data": {"auth": "", "channel": f"nj_ent-eventgroupv2-{league_id}"}}
                       )
        )

        while True:
            try:
                new_message = await ws.recv()
                message_json = json.loads(new_message)

                event = message_json['event']
                if not event == "offer-updated":
                    if event == 'pusher:connection_established':
                        print("Connection established!")
                        continue
                    elif event == 'pusher_internal:subscription_succeeded':
                        print("Subscription succeeded, awaits new odds updates...")
                        continue
                    else:
                        # print(f"Update received but for the wrong WS event type: {event}")
                        continue

                content = json.loads(message_json['data'])
                event_id = content['data'][0]['eventId']
                if event_ids:
                    # if a list of event_ids is provided, this checks whether
                    # the update is relevant or not
                    if not event_id in event_ids:
                        # print(f"Update received but for the wrong event_id: {event_id}")
                        continue

                market = content['data'][0]['label']
                if markets:
                    # if a list of wanted markets is provided, this checks whether
                    # the update is relevant or not
                    if not market in markets:
                        # print(f"Update received but for the wrong market: {market}")
                        continue

                # if the WS event type is correct [offer-updated], the event_id is
                # for one of the games of interest & finally the market is included in the list of
                # wanted markets, then the below section is executed
                outcomes = content['data'][0]['outcomes']
                print(f"New odds update for '{market}'")
                for outcome in outcomes:
                    print("Line:", outcome['line'])
                    print("Outcome:", outcome['label'])
                    print("Price:", outcome['oddsDecimal'])
                    if not outcome == outcomes[-1]:
                        print()
                print("Awaits more updates...")
                print()

            except websockets.WebSocketException:
                # if there's a problem with the connection it breaks the while loop
                # and closes the connection [could easily be adjusted to reconnect instead]
                print_exc()
                break

            except Exception:
                print_exc()

        await ws.close()

    except:
        print_exc()

Description of the above stream function:

1. The function takes four parameters.

   • URI for the web server. Easily found in the web dev tools, double click the right websocket in the Networks tab and copy pasta the address.

     

   • league_id. We’ve collected a couple of league_ids in our dictionary in draftkings_class.py, if you’d like to add in more leagues, well, just do it.

   • event_ids. A list of event ids for the games you’re interested in. To simplify the process of finding those, we’ve added a get_event_ids [code below] method to the DraftKings class which returns both the games and their event ids.

     import requests
     
         def get_event_ids(self) -> dict:
             """
             Finds all the games & their event_ids for the given league
             :rtype: dict
             """
             event_ids = {}
             response = requests.get(self.pregame_url).json()
             for event in response['eventGroup']['events']:
                 event_ids[event['name']] = event['eventId']
             return event_ids

   • markets. A list containing the markets of relevancy, e.g. [‘Moneyline’, ‘Total’].

2. As soon as the function is called, it sets up a connection [the initial WS “handshake”] with the DraftKings server and feeds it the necessary subscription information, exactly as before.

3. To allow for a “never-ending” stream of new bet offer updates, an infinite while loop is utilized. At each iteration it awaits a new message and the moment it arrives it proceeds by processing the content. When it’s finished, it continues the wait for new messages.

   Note: Ctrl + C terminates a running Python script. ‘Twas unfortunately learnt the hard way.

4. Okay, a new message has arrived and needs to be handled:

   • Check #1 is to confirm that it’s an updated offer since that’s the only messages we care about. If not, more or less: ignore the message, continue the while loop, i.e. await new, more informative messages.

   • Check #2: examine whether the event_id is included in the list of event_ids. If not, again ignore the message and await new ones instead.

   • Check #3: make sure the odds data is for one of the markets we’re interested in, else skip the message and, just like before, stay toon’d for new ones.

   • If *all three checks* are successful it means that the message is an odds update for an event_id in our event_ids list and a market in our markets list. Hence in this case we’d like to have the function print the details of the update, which it indeed does.

   If an unexpected problem arise during execution, the except blocks inform about it and end the program.

Subscribe now

Practical usage

To call our freshly built stream function from inside our DraftKings class [remember, we want to keep all the available methods for our scraper at one place for improved usability], we add a live_odds_stream method to it. All it does is more or less to import and call the stream function from our draftkings_stream.py file with the correct parameters.

from draftkings_stream import stream

    def live_odds_stream(self, event_ids=None, markets=None):
        """
        Sets up the live odds stream by calling the async stream function with given parameters
        :param event_id list: If a list of event_ids is specified [else it's None], the stream/listener considers updates
                              only if they're updates for those particular games
        :param markets list: If a list of markets is specified [else markets == None], the stream/listener considers updates
                             only if they're updates for those particular markets
                             Hint: If uncertain about market names, run it for a minute for all markets and collect the correct
                             names of the markets this way
        """
        asyncio.run(stream(
            uri=self.uri, league_id=id_dict[self.league], event_ids=event_ids, markets=markets))

Well, at this point it’s indeed getting exciting.

• The get_event_ids function is working as intended.

• The tough one, the stream function, is complete.

• The DraftKings class has been made compatible with the stream function.

Thus, testing time!

Opening the draftkings_script.py, made for *usage* of our code, and feeding and running it with the below lines of code should print all the event ids for the NBA games currently listed at DraftKings.

from draftkings_class import DraftKings

"""
Create a DraftKings class object
"""
dk = DraftKings(league="NBA")

"""
Find all games & their event_ids
"""
game_ids = dk.get_event_ids()
for game, event_id in game_ids.items():
    print(game, event_id)

Great success! Output below.

WAS Wizards @ BKN Nets 28353246
LA Lakers @ NO Pelicans 28353247
LA Clippers @ NY Knicks 28353252
PHO Suns @ DET Pistons 28353250
MIA Heat @ MIL Bucks 28353255
HOU Rockets @ OKC Thunder 28353253
POR Trail Blazers @ CHI Bulls 28353260
DAL Mavericks @ GS Warriors 28353869
ATL Hawks @ DEN Nuggets 28353262
ORL Magic @ CHA Hornets 28360285
CLE Cavaliers @ IND Pacers 28360286

This was the easy one though.

Onto the real test, the test for the live odds scraper!

Let’s restrict ourselves to the Moneyline markets for the two live NBA games [both currently in the 4th quarter] and try to set up a stream containing all the updates for those two events. Complementing the draftkings_script.py script with two more lines of code,

"""
Set up a stream awaiting odds updates for the Moneyline market
"""
dk.live_odds_stream(
    event_ids=["28353246", "28353247"], markets=['Moneyline'])

solves this for us.

Runtime!

Indeed, executing the code sets up the connection → subscribes to the DraftKings live odds feed → awaits new messages → filters out the information we’re interested in → handles it → prints the processed result in the console.

And the most important part: everything is working as expected.

Beautiful!

The output during the first 45 seconds below.

Connection established!
Subscription succeeded, awaits new odds updates...
New odds update for 'Moneyline'
Line: None
Outcome: LA Lakers
Price: 2.4

Line: None
Outcome: NO Pelicans
Price: 1.57142858
Awaits more updates...

New odds update for 'Moneyline'
Line: None
Outcome: WAS Wizards
Price: 1.74074075

Line: None
Outcome: BKN Nets
Price: 2.05
Awaits more updates...

New odds update for 'Moneyline'
Line: None
Outcome: WAS Wizards
Price: 1.71428572

Line: None
Outcome: BKN Nets
Price: 2.1
Awaits more updates...

New odds update for 'Moneyline'
Line: None
Outcome: WAS Wizards
Price: 1.68965518

Line: None
Outcome: BKN Nets
Price: 2.15
Awaits more updates...

New odds update for 'Moneyline'
Line: None
Outcome: WAS Wizards
Price: 1.95238096

Line: None
Outcome: BKN Nets
Price: 1.8
Awaits more updates...

Use the scraper

A fully functioning, properly built DraftKings scraper available within 45 seconds? Yep!

Clone it into your directory with

 git clone https://github.com/BowTiedBettor/DraftKings.git

then simply head over to the draftkings_script.py file and do your thing.

Conclusion

The toughest part of the project, by far, has now been completed. Since the methods responsible for pulling and handling data for both pregame- and live markets have been finished, what remains is to add in some extra methods that are of high practical value, such as sending email notifications and dumping content into Excel files. As soon as this last step has been completed, the scraper will be finished and the project finalized. See you in part 3!

Finally, we close off today’s post with a BR-reminder and a tweet regarding the Betfair API.

BR-reminder: As a reader of this Substack you should have completed BR at least once [your own identity] at this point or you are falling behind. >$5 000 to earn by clicking some buttons and you are still sleeping on it?

Until next time…

Share BowTiedBettor

Welcome Avatar!

As you’re aware of by now, accurate data is central in the construction and implementation of profitable betting models. In betting, there are two sets of data that are of primary interest:

• Historical data - Foundational for learning about the games/teams/markets and thence figuring out the effect certain variables have on outcomes.

• Executional data - Necessary to optimize the actual betting process [when, where and how to place your bets].

So far, we haven’t really handled much of the historical data part on our blog/Substack. Well, an introduction to the concept was provided in Bayesian thinking & inference, part 1, but we’ve still got lots and lots of grounds to cover.

Regarding executional data, we’ve mainly been focusing on the collection of it rather than its applications. By familiarizing ourselves with some common web scraping techniques, we’ve so far learnt how to scrape sports betting websites using both browser automation and http request/response procedures.

Today, the idea is to build on our existing knowledge and take up an even deeper dive on the collection of executional data. This will be done by the launch of a new scraping project, namely to construct an odds scraper (compatible with both pregame & live odds + increased functionality to simplify any practical tasks) for DraftKings.

The DraftKings scraping project will be divided into three main segments. In the first one (today) we’ll build a pregame scraper [primarily for the NHL but easily adjusted to include more leagues] which will allow us send one-time requests to the DraftKings servers and thus collect odds throughout the days leading up to the games (in fact it’ll work fine for live odds as well if one-time-requests is all you want). During the second part we will take care of a slighly more involved subject, the mid-game scraping/streaming, and in part three we’ll complement our scraper with methods that are of high practical value, such as sending email notifications and dumping content into Excel files.

Through the completion of this project, we will further deepen our web scraping knowledge, not only with continued http request/response training but also with guidance on a new, more advanced technique, WebSocket scraping. By familiarizing ourselves with the WebSocket protocol (in part 2, next week), we will gain the last piece of knowledge one needs to have a solid understanding of the art of *collecting* data. Thus, after having finalized this project, we’ll finally be ready for a fully practical perspective, focusing on possible applications and use cases for the data.

WebSocket is a communication protocol that allows two-way, realtime communication between clients and servers over the internet. WebSocket communication works by establishing a persistent connection (as opposed to the HTTP request-response structure) between a client and a server, allowing for seamless data transmission in both directions. This makes the protocol ideal for applications that require fast and efficient communication, such as live betting.

Note: Our scraping material assumes that you have some familiarity with Python. If you do not, please get started today. Learning Python is definitely one of the most +EV decisions you can make if you are even remotely interested in earning WIFI-money. Combine Corey Schafer and Automate the Boring Stuff and you will soon be an excellent herpetologist.

Subscribe now

Pregame scraping [and live, but no updating stream]

Okay, let’s begin with segment number one, the pregame scraping. A necessary package to follow this guide is requests (a simple & elegant HTTP library) and to install it in your current environment you simply run

pip install requests

in the terminal.

Note: We’ll be using Firefox throughout this project and recommend you do the same. The reason: its built-in JSON-parser & great web dev tools simplifies the scraping process tremendously.

Visit DraftKings, locate the data

Step one is to visit DraftKings and locate the NHL odds. A quick exploration leads to this url. To check from where they’re fetching the data that’s presented to the end user, head into web tools and visit the Networks tab. Sort on Type and scroll down to the json objects. The below picture describes the view you should be presented with.

Click on the requests and inspect them, manually, one by one, until you find the one with the correct NHL data response. Doing this shows that the one named 42133?format=json is the one we’re after, with 42133, the eventGroupId, appearing to be a value/index reserved for NHL content.

Double clicking the request takes us to this url, which indeed holds all the information we’re interested in. Picture below.

Manually inspecting this JSON [this is where the Firefox JSON-parser comes into play], we find that the odds content for the different games are stored under eventGroup → offerCategories → list object at position 0 → offerSubcategoryDescriptors → list object at position 0 → offerSubcategory → offers. For each object [an object holds all the information for a specific game] in this list of ‘offers’, there are three different elements. One contains the Puck Line, one the Totals and the third one the Moneyline market. Thus, it seems reasonable to loop through those three elements, extract all the information of interest and finally store that information in a clever way.

Time to build!

Note [I]: Since the game plan is to begin betting the NHL at some point, there’s actually more to the creation of both this and future scrapers than purely educational/inspirational material.

Note [II]: Integrating code with Substack posts hasn’t really been optimized yet. If you prefer, you could visit our DraftKings repo and follow along by having the code open in another tab instead (recommended).

To be slightly more sophisticated and structured than we’ve been in earlier scraping posts (and since we intend to actually use this stuff at some point), we’ll build a DraftKings class and then, as we proceed, continuously add new methods to it in order to solve the different subprojects that’ll naturally arise. Accordingly, we create a Python file (draftkings_class.py) and begin building.

The code below defines the DraftKings class and stores the pregame url [will always stay the same] for the given league as an object attribute (an object attribute is basically a variable/element that’s stored together with the object).

import requests

id_dict = {"NHL": "42133", "NFL": "88808", "NBA": "42648"}

class DraftKings:
    def __init__(self, league = "NHL"):
        """
        Initializes a class object
        Include more leagues simply by adding the league with its ID to id_dict above

        :league str: Name of the league, NHL by default
        """
        self.pregame_url = f"https://sportsbook.draftkings.com//sites/US-SB/api/v5/eventgroups/{id_dict[league]}?format=json"

Now, to begin coding the actual scraper, we create our first class method, a get_pregame_odds which will send a get request to the url above, parse the JSON, collect the sought information/data for all the available pregame markets and return the result. Code with comments below, or if you prefer, on Github.

import requests
from traceback import print_exc

    def get_pregame_odds(self) -> list:
        """
        Collects the market odds for the main markets [the ones listed at the league's main url] for the league

        E.g. for the NHL, those are Puck Line, Total and Moneyline

        Returns a list with one object for each game

        :rtype: list
        """
        # List that will contain dicts [one for each game]
        games_list = []

        # Requests the content from DK's API, loops through the different games & collects all the material deemed relevant
        response = requests.get(self.pregame_url).json()
        games = response['eventGroup']['offerCategories'][0]['offerSubcategoryDescriptors'][0]['offerSubcategory']['offers']
        for game in games:
            # List that will contain dicts [one for each market]
            market_list = []
            for market in game:
                try:
                    market_name = market['label']
                    if market_name == "Moneyline":
                        home_team = market['outcomes'][0]['label']
                        away_team = market['outcomes'][1]['label']
                    # List that will contain dicts [one for each outcome]
                    outcome_list = []
                    for outcome in market['outcomes']:
                        try:
                            # if there's a line it should be included in the outcome description
                            line = outcome['line']
                            outcome_label = outcome['label'] + " " + str(line)
                        except:
                            outcome_label = outcome['label']
                        outcome_odds = outcome['oddsDecimal']
                        outcome_list.append({"label": outcome_label, "odds": outcome_odds})
                    market_list.append({"marketName": market_name, "outcomes": outcome_list})
                except:
                    # if there was a problem with a specific market, continue with the next one...
                    # for example odds for totals not available as early as the other markets for NBA
                    # games a few days away
                    print_exc()
                    print()
                    continue
            games_list.append({"game": f"{home_team} v {away_team}", "markets": market_list})

        return games_list

Concisely: the above method collects all the odds data and returns it as a list (with objects following standard JSON-practice). In order not only to check that the scraper functions as intended but also to prepare for future use cases, we continue by constructing a second method, a store_as_json, which has the sole job of dumping the content into a local JSON-file.

Code for the method:

import json

    def store_as_json(self, games_list, file_path: str = None):
        """
        Dumps the scraped content into a JSON-file in the same directory

        :rtype: None, simply creates the file and prints a confirmation
        """
        if file_path:
            with open(file_path, 'w') as file:
                json.dump(games_list, file)
            print(f"Content successfully dumped into '{file_path}'")
        else:
            with open('NHL.json', 'w') as file:
                json.dump(games_list, file)
            print("Content successfully dumped into 'NHL.json'")

Having the two methods get_pregame_odds and store_as_json coded and completed, we’re now in a good position to actually run the scraper and verify that everything works as expected.

Creating a second Python file, draftkings_script.py [a scripting file for usage of the class we’re building in draftkings_class.py], and running the following few lines of code should scrape the available NHL markets and dump all of it into a new file named ‘NHL.json’.

from draftkings_class import DraftKings

dk = DraftKings(league = "NHL")
games = dk.get_pregame_odds()
dk.store_as_json(games)

First, running the script seems to work out fine.

Now, the real check is of course performed by heading over to the JSON-file and examining it carefully.

Indeed, as you can see in the picture, the NHL content appears to have been both collected and saved correctly. Great success!

Conclusion

Thanks to the successful test, the pregame part of this project is now complete. We strongly suggest you try the current version of the scraper out!

Questions? Feel free to ask them in the comments section below.

BR-reminder: As a reader of this Substack you should have completed BR at least once [your own identity] at this point or you are falling behind. >$5 000 to earn by clicking some buttons and you are still sleeping on it?

Next week we’ll be back with more web scraping material, mainly focusing on the live odds scraping/streaming.

Update: Part 2 is out. You can find it here!

Until next time…

Share BowTiedBettor

Welcome Degen Gambler!

Previously we have covered two concepts which at first glance do not seem related in any way, web scraping and conditional probability.

Having learnt about the two ideas, one may do the following observations:

• Web scraping is useless unless the data you collect is supposed to serve some purpose.

• Mathematical formulas (in this case Bayes Theorem) cannot be expected to produce any valuable output without relevant input.

Therefore, since both web scraping and mathematics are insufficient on their own, one might instead hope to *combine them* in a way that generates something of value. Indeed, as we will see in this and the coming posts of this series, by cleverly tying the data collection and the mathematics together, it is possible to construct an excellent framework for learning from data/information, something that is known as bayesian inference*.

Note: In math, 1+1 = 2. In life, 1+1 is often greater than 2. This is an (somewhat autistic) example.

*Inference = learning from data. Geeks would probably involve esoteric terminology to explain the word, we prefer understandable explanations.

Since there is a lot to digest here, the introduction to the subject will be split into (at least) two posts. Today we will begin by gaining some intuition (probably confusion/brain damage as well, probability theory is *hard*) for bayesian thinking and then we will be back with practical applications of the theory to real world data in part 2.

Lack of information

Well, to fully appreciate the beauty of bayesian inference one must first be in a creative, bayesian mood. Therefore we’ll begin with an interesting horse racing example to introduce the bayesian way of viewing the world.

Suppose that there is a race on New Year’s Eve and that your mission is to figure out the win probabilities for all the competing horses. Furthermore, assume that at this point in time you have no information whatsoever regarding the race. Basically, all you know is that there *is* a race. Now, the question is, what is your initial set of probabilities for the race?

Indeed a very strange question, but if we make an attempt at answering it, we can probably begin by agreeing on the following very obvious fact: for a race to take place, at least one horse has to participate. Therefore, let’s zoom in on one (possibly the only one) of the participating horses. If we can estimate the probability for *this* horse winning the race, then, after having done so, we may simply repeat the same procedure with the rest of the horses and thereby find the full set of win probabilities.

Now, we immediately encounter a problem. Since we do not even know the number of competing horses, it’s obviously impossible to narrow our win probability (for the given horse) down to a *single* number. The reason is simple, we lack severe amounts of information.

Nevertheless, let’s continue analyzing the situation. By one of the fundamental axioms of probability we know that the probability must lie between 0 and 1. Furthermore, since horse races commonly contain 8-15 horses we somehow feel that the most plausible values should lie in the range [0.08, 0.12]. However, as mentioned above, we most definitely cannot state *with certainty* that the probability of the horse winning the race is, say, 0.13. Thus, even though we ‘feel like’ we know a little bit about it, we clearly don’t know enough. The lack of enough information makes *the probability itself* uncertain. And this uncertainty that we are now observing in the win probability is the whole point of this opening discussion.

Bayesian thinking

Enter bayesian thinking. Instead of either considering the problem ‘stupid’ or forcing ourselves to agree on some arbitrary number, why not incorporate the uncertainty we are observing into some kind of model? Normally, when we are uncertain about things, we consult probability theory and model the uncertainty using the tools it offers us. Why wouldn’t we do the same in this case?

Accordingly, we describe the uncertainty using a probability distribution over all possible values (the interval [0, 1]) of p, where p is the probability of the horse winning the race. We construct a probability of the probability. Integrating the knowledge mentioned previously (… horse races commonly contain 8-15 horses we somehow feel that, given no other information, that the most plausible values should lie in the range [0.08, 0.12]) into our model, a reasonable representation of our initial distribution of the probability looks something like below.

Autist note: Turbos will recognize this process as the design of a prior. For now this detail is not of much importance to us.

Note: The function representing how the probability is distributed (the blue graph in the picture) is called a probability density function [PDF] in probability theory.

Having built this foundation, we can now continue with this approach to move closer to and hopefully approach reality (after all, in practice we will not make much money modeling races we know nothing about). Taking the above graph as the representation of our initial belief, we now await more data, and as soon as we receive new bits of information, we simply update our current probability distribution (of the win probability) according to what the new information tells us. For example, if later this week the entries are revealed and we’re examining the (now known to be) best horse in the field, then naturally the distribution should be shifted towards higher values of p (why?).

Note: As new information emerges, P(p) must be mapped to P(p|new information).

What however is more subtle is the other thing that should happen to the distribution: the ‘spread’ of it should *decrease*. Why? Remember that the distribution/graph is a measure of how much we know about the probability of the horse winning the race. If for some reason we were certain (think of a coin toss where we *know* that the coin is unbiased) that the probability was 0.5, we would basically put all the mass at that point. And since we’ve just obtained more information, which by assumption is valuable information, we now know more about the race and should therefore be able to estimate the probability with increased accuracy.

If we continue iterating this process until post time, we’ll continually update our distribution of the probability, hopefully with increased precision for each new piece of information. Simultaneously, since we at each step *learn more* of the underlying process (the race), the distribution/graph should concentrate around a smaller and smaller subset (unless there is inherent randomness, as in a coin flip example we’ll soon familiarize ourselves with) of the [0, 1] interval, providing us with increasingly sophisticated estimations of what the correct probability (and odds) is. In particular, and this is important, new information will have less impact on our estimates, which is similar to saying that we’ve already been able to come pretty close to the truth.

An example of the evolution of the process in the pictures below.

Note: ‘Information’ is a very broad term. For instance, as in the example in the graphs above, the way other bettors price a race could most definitely be used to sharpen your predictions. This agrees with the common sense that if a bookie/bettor possesses more information than you do, their actions should be considered valuable information and therefore make you update your current estimations of the probabilities *prior to* placing any bets. On the other hand, when you’ve reached a high degree of certainty in your modeling and a not-so-sharp bookie [doesn’t force you to update anything since their information is not information (your size is not size etc…) + you’re already fairly certain about your estimates] comes along and offers a +EV bet, you hit it without even thinking.

Subscribe now

The perfect world, the real world

In a perfect world where we would reach complete (probability-wise, not in the sense of knowing the result in advance, we’re not gods) information at post-time, the whole distribution would contract/converge to a single point, and there would be no remaining uncertainty regarding the probability of the horse winning the race. In fact, even if there was some kind of maximum information (as in the example below) one could extract from the process, and we managed to describe the remaining randomness flawlessly, this would still suffice to compute the correct win probabilities (proof + intuition below) of the participants.

Example: If you have a bag with two coins, one biased (75-25) and one unbiased (50-50), and pick a coin at random, you may compute the probability of heads by considering the probability distribution [p = 0.75 with prob 0.5, p = 0.5 with prob 0.5] of this probability. In some sense you know everything there is to know (can calculate correct probabilities/odds for a bet on heads), even though you cannot state for certain what the true probability is when the coinflip takes place.

In practice, we never reach neither complete nor maximum information, so we’re always left with some kind of probability density function describing the remaining amount of information and/or randomness. If we assume that the density is a fairly good approximation of reality, then a simple mathematical theorem, which in fact have been used already (in the coin flip case), lets us compute *our estimate* of the true probability.

Observe that we by assumption have complete knowledge of:

• The probability that the horse’s winning probability attains some specific value (e.g. 0.14).

• The probability that the horse in fact wins the race, given a certain winning probability (of course equal to the given winning probability).

Therefore, to compute the true/real world win probability, we can loop over all possible values of p and weigh these p’s with the probability that they are attained, which is completely described by our density/graph/distribution. An experienced observer will quickly conjecture that this operation is equivalent to computing the expected value [EV] of p over its specified probability distribution. Indeed (verified by the below math) this is true.

This method of looping over all potential values of p (0.75 and 0.5) was exactly the method used to find the probability of heads in the earlier bag + coin flip example. In that case the two possible values of p was 0.75 and 0.5, and the probabilities of seeing them 0.5 and 0.5 respectively. Therefore, it immediately followed that the probability of heads was determined by 0.5*0.75 + 0.5*0.5 = 0.625.

Why ‘bayesian’?

The necessary building blocks of bayesian thinking have now been presented and consequently we are ready to go full autism by delving deep into bayesian inference. However, to clear come confusion, what is this ‘bayesian’ thing that keeps popping up? You’ve heard of Bayes & Bayes Theorem, but so far… no sight of him! Why is the stuff called ‘bayesian’?

Well, in the above quite abstract discussion there was a very fundamental notion that was left more or less untouched. How are we supposed to actually move from the prior distribution (pre-information) to the posterior distribution (post-information)? Our current extremely naive method of guessing and drawing some graphs does not take us far, and there is no doubt that a better procedure must be developed.

BAYES!

Bayes formula is, as you should know at this point, an equation which offers the possibility to calculate a conditional probability of something given something else. Handy, isn’t it, since our whole mission is to compute the probability of something (e.g. the probability of a horse winning a race), given data/information. Thus, if we combine the earlier reasoning with Bayes formula, we naturally arrive at bayesian inference.

Conclusion

This post is already pretty dense at this point so to save you some brains for the rest of the night we will save the practical applications for the next post in this bayesian series. Nevertheless, to give you a hint of what is coming we wrap up today’s post by stating two interesting problems that can be handled perfectly by the reasoning we have just developed:

• You have data on your last 473 bets (e.g. testing a strategy/tailing another bettor) and would like to examine whether you/they have an edge or not. Update: This problem was handled in Bet sequences, an analysis.

• After having read our posts on web scraping, you have just scraped and stored all the NHL data from the previous season. You are now interested in learning as much as possible about it. For example, since you find live odds intriguing, you wonder what the probability of a team winning a game, conditional on taking a lead into the third period, is.

Try to figure out how one could answer the above questions, anon.

Then, continue with part two of this Bayesian series!

Until next time…

Share BowTiedBettor

Welcome Degen Gambler!

Today we will extend our current web scraping knowledge by discussing new ways of gathering online information. In our first scraping post “Build your first odds scraper” we consulted Selenium to solve our problems, an open source umbrella project for a range of tools and libraries aimed at supporting browser automation. However, there two major disadvantages with Selenium:

1. It is slow.

2. It is unintuitive. You’re basically extracting data from arbitrary HTML sections containing elements with more or less ‘random’ names. This makes error checking/updating code unnecessarily difficult. Example below.

today_object = driver.find_element(By.CLASS_NAME, "_79bb0")
games = today_object.find_elements(By.CLASS_NAME, "f9aec._0c119.bd9c6")
for game in games:
    team_names = game.find_elements(By.CLASS_NAME, "_6548b")
    ...

What if instead we could find a way to get around this Selenium stuff, and do something more similar to what the website itself is doing? After all, the website is getting their data from somewhere, right? Rarely do things just magically appear.

Background

When you browse the web using a web browser, there’s quite a lot going on in the background. You click a button and the site is (hopefully) updated. That doesn’t happen out of nowhere. In fact, your click executes code with a set of different rules that ensure that what should happen does indeed happen. Someone has built an “on-click” function/method, which, as soon as it receives your click, sends a ‘message’ somewhere. This ‘message’ is then interpreted and handled by new chunks of code that when finished returns a new ‘message’ for the website to handle. Lastly, the returned ‘message’ is used to present the relevant information to the user.

To restrict the above very abstract/general setting into something more practical, we now consider what happens when you visit a sports betting website. Okay, so you’re betting the NHL and so you enter https:// unibet.com/sports/#sports-hub/ice_hockey/nhl into your address bar and hit enter. At this point a huge number of different ‘messages’ are sent and received across the World Wide Web in order to, for example, collect and manipulate information Unibet wants to display to the user. The result: the site loads and all the content (e.g. the odds for the upcoming games) becomes visible. Now here comes the interesting part, what if we could mimic this behaviour of the website and perform the same operations/communications to get access to exactly the content we are looking for?

Web Communication Protocols

Enter web communication protocols. Web communication protocols are a set of technologies used to communicate with web servers and transfer information across the internet. The degree to which users can interact with this information depends on the specific protocol being used. Some protocols are more interactive than others, allowing users to manipulate and customize the information they receive in various ways.

For sports betting purposes, there are two relevant protocols to be aware of, HTTP and WebSocket.

The HTTP protocol is a system used to transfer data over the internet. It consists of a client-server architecture, where requests are sent from a client to a server, and responses are returned in response to these requests. The protocol includes several components that work together to allow this data transfer to happen, including request messages, status codes, headers, and content types.

WebSocket is a communication protocol that allows two-way, realtime communication between clients and servers over the internet. WebSocket communication works by establishing a persistent connection (as opposed to the HTTP request-response structure) between a client and a server, allowing for seamless data transmission in both directions. This makes the protocol ideal for applications that require fast and efficient communication, such as live betting.

Basically, the bookmaker stores its odds/betting information on a server and when you are visiting and interacting with the website your browser sends HTTP requests and/or establishes WS connections to/with this server, then awaits responses containing the requested information and finally presents the data to the user. Hence, if we could learn the *basics* (no wizardry needed) of these communication protocols, we should be able to copypasta the requests/calls/messages and hopefully obtain the same data as the one we’re seeing on the website.

Note: We’re by no means any web scraping experts so if you’re reading this and find that something should be added/rephrased, please share your correction/clarification with the rest of our readers in the comments.

Let’s go!

Enough background information. Let’s scrape some odds!

As you could probably guess from the above section, we’ll be scraping the Unibet NHL odds. A quick check reveals that Unibet is utilizing the standard HTTP-protocol to transfer odds information, therefore we’ll go down the HTTP requests-response route today and return with WebSocket (slightly harder) material later down the line.

Our scraping material assumes you have some familiarity with Python. If you don’t, please get started today. Learning Python is definitely one of the most +EV decisions you can make if you’re even remotely interested in earning some WIFI-money. Combine Corey Schafer and Automate the Boring Stuff and you’ll soon be an excellent herpetologist.

We begin by installing the requests module in our environment by running

pip3 install requests 

in the terminal.

Next, head over to the site you want to scrape, in our case it’s https:// unibet.com/sports/#sports-hub/ice_hockey/nhl. Right-click, click inspect elements and head over to the ‘Networks’ tab in the web dev tools. Reload the page. Click ‘type’ in the menu and scroll down to json (a lightweight data-interchange format, easy for humans to read and write, easy for machines to parse and generate).

As you can see there are a lot of different objects here. We can either just go through them manually (doesn’t take too much time when you’ve done it a couple of times) or try to nail down the range somewhat by searching for terms such as “hockey”, “odds”, “api” in the manual “Filter URLs” bar. A search for ‘hockey’ yields

and clicking on response out at the right on one of the “eu-offering.kam…” requests, we note that this response seems to contain the information we are looking for. Use Firefox (Firefox has an excellent JSON-parser built into the browser) and go to the url [https:// eu-offering.kambicdn.org/offering/v2018/ubusnj/listView/ice_hockey/nhl/all/all/matches.json?lang=en_US&market=US-NJ&client_id=2&channel_id=1&ncid=1667115444478&useCombined=true&useCombinedLive=true] containing the JSON-response and click collapse all on the upper left. The games and the odds info for them are likely listed under ‘events’, so we click events and investigate one of the elements to see if we can find anything of interest.

Indeed, for each event there appears to be three objects, ‘event’ that contains more general information regarding the game, ‘betOffers’ which holds the odds for the different available markets and ‘liveData’ which is updated with the latest information as the game progresses. Inspecting ‘betOffers’ we see that there are three markets offered for every game, "Puck Line - Inc. OT and Shootout", "Moneyline - Inc. OT and Shootout" and "Total Goals - Inc. OT and Shootout”.

Now that we’ve analyzed the existing content, we’d like to extract a subset of it and save it locally to our computer for further use.

Suppose for simplicity we are interested only in the moneyline market odds and would prefer to exclude the games which have already begun. How do we proceed?

Since we’ve found the exact location (the URL above) for all the data related to Unibet’s NHL-odds, we can use the Python library requests and send a get request to this URL. This will return a Python requests.Response object containing all the information we’re interested in and by applying some relevant methods to this object we’ll hopefully be able to get job done. The below code sends the request and stores the response object in a variable we’ve chosen to name unibet_response.

import requests

unibet_response = requests.get("https://eu-offering.kambicdn.org/offering/v2018/ubusnj/listView/ice_hockey/nhl/all/all/matches.json?lang=en_US&market=US-NJ&client_id=2&channel_id=1&ncid=1667115444478&useCombined=true&useCombinedLive=true")

Autist note: Sometimes authorization and/or more is required for a request to be successful. In this case you’ll want to check *exactly* which headers (a request header is a HTTP header that can be used in an HTTP request to provide information about the request context, so that the server can tailor the response) was sent in the get-request and then make sure to include those in the get request you’ll be sending in your Python script. Tools like Postman/Insomnia simplifies this process *a lot* by constructing correct requests for you.

If we now run the above code and do a print(unibet_response) and a print(unibet_response.text) we note that the request was successful and that the data we’ve obtained and stored in unibet_response appears to be the right one.

<Response [200]>

{"events":[{"event":{"id":1018816193,"name":"DET Red Wings @ BUF Sabres","nameDelimiter":"@","englishName":"Buffalo Sabres - Detroit Red Wings","homeName":"BUF Sabres","awayName":"DET Red Wings","start":"2022-10-31T23:00:00Z","group":"NHL","groupId":1000093657,"path":[{"id":1000093191,"name":"Hockey","englishName":"Ice Hockey","termKey":"ice_hockey"},{"id":1000093657,"name":"NHL","englishName":"NHL" ...

Owing to the fact that the content we’re requesting is in JSON format, we may now use the json()-method on our unibet_response object to generate a Python dictionary containing all the information. Since we’re used to working with dictionaries this will simplify the remainder of the scraping process.

import requests

unibet_response = requests.get(
    "https://eu-offering.kambicdn.org/offering/v2018/ubusnj/listView/ice_hockey/nhl/all/all/matches.json?lang=en_US&market=US-NJ&client_id=2&channel_id=1&ncid=1667115444478&useCombined=true&useCombinedLive=true")

unibet_dict = unibet_response.json()

At this point we have everything we need contained in unibet_dict. Furthermore, it is a Python dictionary (which we know how to handle) following the exact same structure as the JSON data we’ve already spent some time analyzing. Therefore, we know quite a lot about how the information is stored and where to find the odds we're searching for.

To clarify: When you’re extracting the relevant data you’ll want to use a JSON-parser (for example the one built into Firefox) to efficiently be able to find the location of what you’re looking for. A

For example, if we’d like to print all the names of the games we can store the list of games in a variable named games and then loop through this list and print the name of the game at each iteration. The below code helps us out with this exact thing.

import requests

unibet_response = requests.get(
    "https://eu-offering.kambicdn.org/offering/v2018/ubusnj/listView/ice_hockey/nhl/all/all/matches.json?lang=en_US&market=US-NJ&client_id=2&channel_id=1&ncid=1667115444478&useCombined=true&useCombinedLive=true")

unibet_dict = unibet_response.json()

games = unibet_dict['events']

for game in games:
    print(game['event']['name'])

It returns

LA Kings @ STL Blues
VGS Golden Knights @ WSH Capitals
OTT Senators @ TB Lightning
PHI Flyers @ NY Rangers
BOS Bruins @ PIT Penguins
MTL Canadiens @ MIN Wild
NY Islanders @ CHI Blackhawks
LA Kings @ DAL Stars
NSH Predators @ EDM Oilers
SEA Kraken @ CGY Flames
NJ Devils @ VAN Canucks
FLA Panthers @ ARI Coyotes
ANA Ducks @ SJ Sharks

which seems correct.

In our previous introduction to the Kelly Criterion, we considered the importance of sizing your bets correctly via a discussion of the concept of expected growth and a presentation of the basics of the theory of bet sizing/portfolio optimization. The main question was whether there for any plausible betting proposition was possible to find a ‘perfect’ bet fraction, one that is optimal in the sense of always outperforming any other fraction. If the bettor’s objective is optimization of long-term growth, both existence and uniqueness (under some mild conditions) of such a fraction was proven.

Now, the realisation of the fact that a solution to the above problem of finding the ‘perfect’ fraction when offered a *single* bet exists, naturally gives rise to another engaging question. Could the same idea hold true in a more general, multidimensional case, where instead of a unique opportunity a full *set* of betting propositions are taken under consideration?

The theme of this post is to answer this question by discussing whether or not a construction of such an extension is achievable.

Quick note: Now that the necessary BR-material has been handled, we have a couple of more general betting subjects coming up on the Substack. After running the below poll earlier this week,

we decided that the release of this mathematical piece should be prioritized to quench the thirst of all the autists in our following.

An updated version of the problem

Note that this text assumes that you have read and understood the one-dimensional case and feel comfortable with increasing the level of abstraction. Since the closing notes in the 1D Kelly intro (which discussed the theory’s practical applications) are as relevant for the n-dimensional case, we recommend you (instead of repeating ourselves) to reread those thoroughly after completing the rest of this treatment. The remainings of this post will consequently be restricted to the mathematical details of the problem.

First, we begin by recalling the situation leading up to the one-dimensional case.

You find yourself in a position with a +EV betting opportunity and realise that you should probably execute a trade, one way or another. This immediately gives rise to a very interesting question, how much should you bet?

If your goal is to simply maximize the expected value in dollar terms, then the correct strategy is to bet as much as possible, i.e. your full portfolio. It does not require much thinking though to realise that this is an extremely unintelligent approach, within only a couple of bets there is a great chance you will have gone bust already and, in fact, with probability one you will go broke sooner or later if you continue indefinitely. It suffices to say we should be able to do better.

At the other extreme, you do not want to completely waste the opportunity, if there is positive expected value offered, you somehow want to collect at least a bit of it.

This leaves us with an intriguing situation, perhaps best summarized in three main objectives:

• +EV opportunity → want to bet more than 0 $.

• Uncertain event → cannot risk full portfolio.

• Want, for self-explanatory reasons, to introduce some dependence on portfolio size → bet a *fraction* of total bankroll.

Translating this thinking into our new setting, what differs is that we are now faced with a *multiple* of favorable betting opportunities, and are aiming to find a ‘perfect combination of fractions’ to wager on the different events such that our long term portfolio growth is maximized. The question is, how do we solve this fairly technical optimization problem?

A naive approach would be to consult the existing 1D Kelly formula repeatedly by feeding it the information for one bet at a time, looping through the bets until the full set of n solutions have been computed. It is however not hard to see why this procedure would fail and an excellent way to understand the intricacies of our extension is to try to come up with counterexamples (there are many) for which this strategy becomes dangerously flawed.

A treatment for the sonic autist

As seen is the previous paragraph, hoping to solve this extended problem by applying our current knowledge does not take us far. Accordingly, we are forced to invent new techniques to handle these kinds of more generalized/less restrictive situations and this is exactly what is done below.

Substack is unfortunately not LaTeX-compatible and since more advanced mathematics more or less requires LaTeX for readability purposes, this part of the post, handling the mathematical statement and solution of the problem, has been attached using images. If preferred, a PDF available for download has been included as well.

Kelly In R^n

165KB ∙ PDF file

Download

Download

LINK TO RESEARCH PAPER

Two examples

After having delved deep into the mathematics, we will now reduce the complexity somewhat by analyzing two fairly simple examples for the purpose of practical insight.

Example 1: You are offered to bet on two independent coin tosses that are to take place at the same point in time. Both coins are loaded, and they have a 60 % probability of coming up heads and a remaining 40 % chance of tails. However, 2.00 is the odds offered by your bookie on all available outcomes and consequently it is clearly in your interest to have a portion of your money invested. The question is, how much should you wager on each coin toss?

By setting up the equations correctly and letting Maple do its job, we obtain the following Kelly surface describing the dependency between the portfolio growth and the different combinations (f_1, f_2), with a maximum attained at (0.16, 0.16). We conclude that both opportunities deserve an equal investment of 16 % of your portfolio.

Example 2: You find that two horses competing in the same race are incorrectly priced by the market. One is available at 3.00 with a 40 % win probability while the other one is offered at 6.00 with a 20 % chance of winning. Both bets are definitely +EV, but what is the optimal set of wagers? According to Kelly, a wager of 13.3 % on the 3.00 horse and one of 6.7 % on the 6.00 option!

What is to come?

Now that we are all Kelly gurus and know how to make optimal use of +EV openings, we are prepared to launch into less abstract/more practical territory in the coming weeks. A few hints on what is to come on our Substack:

• An introduction to the Betfair Exchange API. Why bet manually when you can do it programmatically? The bots are coming!

• Penalty shootout models. World Cup 2022 is not far away and it will be interdasting to see the Jungle move the shootout lines in the playoffs.

• More practical BR-material, specifically guides on the most common offers.

• Web scraping resources, a review of different tools and approaches combined with helpful examples of finalized scripts.

• An outline of the NHL project.

That is all we have got for today!

Until next time…

Do you have a friend who likes betting and would like to sharpen his/her action? Help them on their path by sharing the BowTiedBettor Substack. Win and help win!

Share BowTiedBettor