DEV Community: Eddie Glush

Millions of odds snapshots: what the bookmaker margin actually looks like

Eddie Glush — Fri, 18 Sep 2026 03:53:56 +0000

The price of placing a bet is never printed anywhere. There is no line item, no fee, no receipt. It is folded into the odds themselves: both sides of a coin flip pay less than even money, and the gap is what the bookmaker keeps. That gap, the margin or overround, is the single most important number in betting, and almost nobody measures it.

So we did, continuously, and published the result as a daily index with a free CSV.

What the numbers say

Two things are on the site. The Margin Index is a live daily panel; on the day this was written (17 September 2026, 79 days into the series) it measured 2,747,603 markets across 68 bookmakers in a single day, with a headline two-outcome margin of 4.92%. The State of the Vig 2026 quarterly report is the fixed summary: 69.6 million pre-match market observations across 53 bookmakers and 14 sports, 1 July to 8 September 2026.

The clearest finding is that the type of bet matters far more than the sport.

Market type	Mean margin	Markets that day
Head-to-head (two outcomes)	4.92%	415,503
Handicaps / spreads	5.11%	517,201
Totals (over / under)	5.94%	827,759
Match result (three outcomes)	7.19%	668,945
Player props	7.65%	305,981

Read that as a price ladder. The simpler the bet, the less it costs. A player prop carries roughly 60% more margin than a simple who-wins bet, 7.6% against 4.8% on the quarter's numbers, and props are simultaneously the fastest-growing market type. In the quarterly panel, props were 23.8 million of the 69.6 million observations.

A third outcome is expensive too. Three-way match-result markets, where a draw is possible, ran at about 7.5% over the quarter, half again the two-outcome figure.

The sport gap is real, and bigger than people assume

Same bet type, two-outcome who-wins, split by sport, on the latest day measured:

Sport	Margin	Cost on $100	Markets	Books
NFL	4.36%	$4.36	52,100	21
College football	4.43%	$4.43	100,933	19
MLB	4.70%	$4.70	64,330	52
NHL	4.93%	$4.93	37,270	22
UFC / MMA	5.02%	$5.02	41,366	24
NRL	5.28%	$5.28	4,129	19
NBA	6.00%	$6.00	61,611	35

Over the full quarter the pattern is the same and the spread is wider: baseball was the cheapest sport to bet at 4.34%, and T20 international cricket the dearest at 6.24%, about 44% more margin on the same kind of bet. The big American leagues cluster tightly between 4.3% and 4.7%, which is what competition does to a price: those are the markets where the most bookmakers are quoting.

The quarter also caught a seasonal move. Spreads went from 4.96% in July to 5.73% by early September, and totals from 5.57% to 6.37%, as NFL and college football lines came online and displaced the baseball lines that dominated July. Football lines simply carry more margin.

How it is measured

For every bookmaker quote on every market, convert each price to an implied probability (1 ÷ decimal price), sum them, and subtract 100%. A fair market sums to 1.00; the surplus is the margin. Every quote is a separate observation, so a market quoted by 40 bookmakers contributes 40 measurements rather than one blended average. That matters, because the average of a cheap book and an expensive book is a price nobody can actually get.

Handicap markets are paired on the absolute value of the line, since the two sides carry opposite numbers. Observations resolving outside 0–30% are mispaired or stale quotes and are dropped; on the latest day that filter removed at most 0.63% of observations in any market type. In-play prices, suspended markets and betting exchanges (which charge commission instead of margin) are excluded from the quarterly report.

The index publishes aggregates only, no odds, no prices, no bookmaker identities, which is exactly why it can be given away under CC BY without redistributing licensed market data.

Use the data

import pandas as pd
import requests
from io import StringIO

URL = "https://betbetter.world/studies/margin-index?format=csv"
raw = requests.get(URL, timeout=30, headers={"User-Agent": "margin-demo/1.0"}).text

# two leading '#' lines carry the source and licence
df = pd.read_csv(StringIO(raw), comment="#")
print(df.columns.tolist())
# ['as_of_date', 'market_class', 'shape', 'markets_n', 'books_n',
#  'mean_pct', 'median_pct', 'dropped_pct']

# margin by market class, weighted by how many markets were measured
w = (df.assign(num=df.mean_pct * df.markets_n)
       .groupby(["market_class", "shape"])[["num", "markets_n"]].sum())
print((w.num / w.markets_n).sort_values().round(2))

# the headline series: two-outcome head-to-head, day by day
h2h = df[(df.market_class == "h2h") & (df.shape == "2way")]
print(h2h.set_index("as_of_date").mean_pct.tail(14))

Links and citation
Daily Margin Index (and the CSV): https://betbetter.world/studies/margin-index
State of the Vig 2026, Q3: https://betbetter.world/studies/state-of-the-vig-2026
Market calibration study: https://betbetter.world/studies/market-calibration
Our publicly graded record, losses included: https://betbetter.world/results

Suggested citation: Glush, E. (2026). The Bet Better Margin Index: daily measured bookmaker margins across market types. Bet Better. https://betbetter.world/studies/margin-index

How we grade hundreds of sports picks a day in public

Eddie Glush — Fri, 18 Sep 2026 03:33:01 +0000

Most sports prediction sites will tell you how good they are. Very few will show you the losses. We decided early that our record would be a public page rather than a marketing claim, and that decision ended up shaping the whole pipeline. This is a write-up of how the grading works, what it costs, and what we learned when we pointed the same machinery at the betting market itself.

The shape of the pipeline

There are four stages, and each one is a table you can query.

1. Publish before the game. A pick only counts if it exists before the event starts. Models run on a schedule, write their selections to a table, and every row is stamped with the time it was written and the price that was on screen at that moment. Nothing is allowed to be added later. This is the part everyone skips, and it is the only part that matters: a record that can be edited after the result is not a record.

2. Wait for the official result. A separate job pulls final scores. Scores arrive messy: a game is postponed, a player withdraws, a line is voided, two feeds disagree on whether the match went to extra time. Every one of those cases needs an explicit rule written down in advance, not a judgement call made when you can already see whether the pick was going to win.

3. Grade. Join picks to final scores, apply the market rule (did the total go over, did the side cover, did the favourite win), and write win, loss or void. A pick graded once is frozen. We do not regrade history when a model changes; the old era's record stays as it was, closed and dated.

4. Show it. The graded rows go straight onto a public page, newest first, with the price we published, the result, and what $100 would have done. Every dip stays in the chart.

The non-obvious engineering lesson: stage 1 and stage 3 must not be able to touch each other. Our worst bug in this system was not a modelling error. It was a grading job and a settlement job running at the same time on the same rows, so a read during a delete saw a half-finished world. Grading is a lock-ordering problem long before it is a statistics problem.

Why publishing the losses is the whole point

Three reasons, in increasing order of how much they surprised us.

The obvious one: it is honest, and it is the only defence against the survivorship problem that makes every tipster's record look good. If you can delete a pick, your record means nothing, and nobody can tell from the outside whether you did.

The second one: it makes you define things. You cannot publish a result without deciding, in public and in advance, what a push is, what a void is, which price counts, and what happens when a game is abandoned. Half the value of a public record is the rulebook it forces you to write.

The third one, which we did not expect: it changes what you build. When every loss is visible, a model that wins slightly more often but explodes in a bad week looks worse on the page than it does in a backtest summary. The public chart, with the drawdowns left in, is a better product decision-making tool than any single aggregate number.

Our live record, as published at the time of writing, covers 242 picks since the current selling rules were rebuilt on 5 September 2026, and the era before it graded 3,222 picks: 2,440 won, 782 lost. Both eras are on the page together, the retired one frozen.

What happened when we graded the market instead of ourselves

Once you have a grading archive, you can point it at a much more interesting question: is the betting market itself a good forecaster?

We took every settled two-outcome market in the archive, 18,238 of them across five sports from November 2024 to July 2026, stripped the bookmaker's margin out of each price to turn it into a probability, and checked how often those things actually happened. Both sides of every market are included, so the dataset nets to 50/50 by construction and contains no information about anyone's selections.

The answer is uncomfortable if you sell predictions: the market is very well calibrated. Across every probability band, real outcome rates land within about two percentage points of the margin-free price. Something priced as a 65% chance happened about 63% of the time; a 25% chance happened about 27% of the time.

Margin-free probability band	Observations	Mean implied	Actually happened	Gap
20–30%	5,263	25.2%	26.7%	+1.4
40–50%	5,515	45.7%	46.4%	+0.7
60–70%	4,945	65.2%	63.0%	−2.2
80–90%	2,157	82.5%	80.9%	−1.6

There is a systematic residual, and it points the same way every time: outcomes priced below 50% happen slightly more often than their margin-free price implies, and favourites slightly less. That is the classic favourite–longshot pattern, documented since the 1940s, measured here on modern multi-sport fixed-odds markets with the margin removed. It is roughly twice as large in player-prop markets as in match-level markets, and those are the same markets that carry the fattest margins.

So the honest framing is not "we beat the market". It is: the market is nearly perfectly calibrated, the cost of a bet is real and measurable, and the only way anyone should judge a prediction service is a record that includes the bad weeks.

Grab the data

The daily bookmaker-margin series behind that de-margining step is published as a CSV, free, updated every day:

import pandas as pd
import requests
from io import StringIO

URL = "https://betbetter.world/studies/margin-index?format=csv"
text = requests.get(URL, timeout=30, headers={"User-Agent": "margin-demo/1.0"}).text

# the file starts with two '#' comment lines
df = pd.read_csv(StringIO(text), comment="#")

h2h = df[(df.market_class == "h2h") & (df.shape == "2way")]
print(h2h.groupby("as_of_date").mean_pct.mean().tail(10))
print("markets measured overall:", int(df.markets_n.sum()))

Columns are as_of_date, market_class, shape, markets_n, books_n, mean_pct, median_pct, dropped_pct. Aggregates only, no odds, no prices, no bookmaker identities, so it can be reused freely.

Links
Our public graded record, wins and losses: https://betbetter.world/results
Market calibration study: https://betbetter.world/studies/market-calibration
The daily margin index and its CSV: https://betbetter.world/studies/margin-index
Free model API and docs: https://betbetter.world/api

I built an engine to reverse-engineer ChatGPT, Gemini and Perplexity rankings

Eddie Glush — Thu, 04 Dec 2025 10:02:31 +0000

We all know SEO is changing. I noticed that my own behavior had shifted—I wasn't Googling "best CRM for startups" anymore; I was asking ChatGPT and Perplexity.

But as a developer, this annoyed me. I have tools to track my rank on Google (Ahrefs, SEMrush), but I had zero visibility into whether ChatGPT/Gemini was recommending my product or my competitor's. I was flying blind.

So, I decided to build a command center to fix that.

The Solution: Answer Engine Optimization (AEO) I built a system I call the AI Command Center. Instead of tracking keywords on a static page, it treats LLMs like dynamic users.

It answers three questions:

Visibility: Does ChatGPT even know my brand exists?

Sentiment: When mentioned, is the context positive or negative?

The "Mystery Shopper": If I ask an unbiased agent to compare me vs. a competitor, who wins?

The Tech Stack I built this into my current .NET stack. Here is the architecture:

Backend: C# / .NET (WebForms & Async Handlers)

Database: SQL Server (storing JSON snapshots of AI conversations)

AI Layer: OpenAI GPT-4o (for analysis) + DataForSEO API (for live SERP/LLM data)

Frontend: Vanilla JS + Chart.js (kept it lightweight)

How the "Mystery Shopper" Works (The Cool Part) This is the feature I'm most proud of. I didn't just want to know if I ranked; I wanted to know why I was winning or losing.

I built a simulation engine that spins up an AI agent with a specific persona (e.g., "Savvy Buyer"). I feed it a prompt like:

"Act as an unbiased consumer. Compare [My Brand] vs [Competitor] based on trust, pricing, and reviews. Who would you buy from?"

The system captures the raw response, parses it, and stores the "Winner" and the "Reasoning" in the database.

Now, instead of guessing why my conversion rate dropped, I can see that ChatGPT/Gemini is telling users: "Competitor X is better because they offer a free trial." That is actionable data I can fix immediately.

The "Self-Healing" Code I took it one step further. If the AI says "I can't find pricing for this product," my system detects that specific failure.

It then triggers a Schema Generator that writes the correct JSON-LD Product schema, validates it, and (if allowed) injects it directly into the site header. It’s essentially self-healing SEO code.

I built Zyro, a platform to help businesses grow, and I realized that "Growth" in 2025 means winning the conversation inside the AI, not just the blue links on Google.

It was a fun challenge to wire up the "Live" APIs to get real-time data from ChatGPT, Gemini and Perplexity rather than just relying on static databases.

Try it out I'd love to hear what you think of the approach. If you want to run a simulation on your own site, I put it live here: [Link to Zyro.world]

Let me know if you have questions about the C# implementation or the prompt engineering!

Orchestrated AI: what happens when everything finally works together?

Eddie Glush — Mon, 20 Oct 2025 18:27:49 +0000

Every platform claims to help businesses grow.
But most growth still feels like managing a hundred moving parts that don’t talk to each other.

You create content in one app, run tests in another, track performance in a third, and optimize in a fourth. Every click feels productive, but the system itself stays fragmented.

I learned that the hard way.

Where it started

Before Zyro, I built Bet Better - a fully automated sports-betting platform.
At surface level, it predicted games and published articles. Underneath, it was a network of machine learning models, content pipelines, and dynamic SEO engines that all had to stay in sync.

It taught me that growth systems don’t fail because of bad ideas — they fail because of disconnection.
When data, logic, and delivery are aligned, everything compounds.
When they drift, performance collapses silently.

That’s when I started thinking less about tools and more about orchestration — the space between them.
What if an AI system didn’t just generate, or track, or optimize — but understood the relationships between every moving piece?

That became Zyro.

The shift from automation to orchestration

Automation executes tasks faster.
Orchestration aligns entire systems.

Zyro was built around that idea — not to replace existing tools, but to connect them into one intelligent growth brain.
Every module — content, social, testing, analytics — plugs into the same orchestration layer, speaking the same language.

Under the surface, Zyro’s architecture runs on a unified BusinessID model.
That ID ties together everything a company does — content briefs, published articles, social campaigns, experiments, analytics events, feature limits, billing, even smart notifications.
Each component can act independently, but it’s aware of the others through shared context.

The result: instead of juggling disconnected dashboards, Zyro interprets and acts across them as a single system.

The content layer

It starts with content — because that’s still the front line of growth.

Zyro’s Content Library manages the entire journey from idea to published article:

Topic discovery: live keyword trends, Google Search Console data, and DataForSEO metrics feed into a ranked list of opportunities.

Brief Builder: builds an AI-assisted brief using SERP analysis, competitor outlines, entity extraction, and question mining.

Article Editor: generates, edits, and optimizes long-form content with tone, audience, and schema controls.

Automation: every draft, version, and publish event writes back into analytics — closing the loop between creation and performance.

But the real intelligence isn’t in generating text — it’s in understanding connection.
When Zyro creates a new article, it automatically maps where that content fits into your existing SEO structure, which internal pages to link, and which entities to reinforce for topical authority.

That’s orchestration — the brief, the article, the links, the SEO data, all aware of each other.

The social layer

The Social Suite brings the same logic to external communication.
Every connected platform — Meta, Reddit, LinkedIn, YouTube, TikTok, Telegram — feeds analytics into a shared schema.

Zyro tracks performance, schedules posts, and records engagement — but more importantly, it understands why a piece worked.
It can trace a spike in impressions back to a post, link that post to the article it promoted, and measure the conversion ripple that followed.

That’s not “posting.”
That’s a living feedback system between your content and your audience.

The experimentation layer

Growth without testing is just guessing.
Zyro’s built-in A/B testing and feature experimentation platform handles that systematically.

It lets you run visual experiments, bandit optimizations, and behavioral tests across pages, audiences, and device segments.
It uses statistical guardrails — z-tests, Bayesian models, and epsilon-greedy or UCB1 allocation — to decide winners safely and automatically.

Every experiment connects back into the same ecosystem:

Tests are tied to BusinessID and PageURL.

Conversions are logged in Analytics.

Results inform Smart Feed insights and page priorities.

It’s not a separate optimization layer — it’s part of the same brain.

The analytics layer

All of this feeds into Zyro’s analytics engine — the nervous system.

It captures pageviews, scrolls, conversions, and behavior in real time.
Then it rolls them up into unified views — by day, device, channel, or audience — across DailySummary, DailyByChannel, and DailyByDevice tables.

The same data powers the User Journeys module, visualizing the actual flow through your site: top landing paths, conversion funnels, and drop-offs.
Everything is traceable back to the originating content, campaign, or test that caused it.

And it all runs under one principle:

data should describe movement, not just metrics.

The Smart Feed

Then there’s the intelligence layer — Zyro’s Smart Feed.
It’s the orchestrator watching everything, surfacing what matters in real time.

It doesn’t just push alerts. It interprets:

A page’s CTR drops? You get a notification explaining the change and linking to the Action Plan.

A new content brief is ready based on rising trends? It appears as an opportunity.

Conversion lag spotted after a test? The system queues the fix.

Each notification carries permissions, feature keys, and direct actions — it can open a page, launch a regeneration, or queue a job automatically.
It’s growth guidance without the noise.

Plans, permissions, and scalability

Zyro’s permission and feature system keeps everything modular.
Roles define what users can do.
Plans define what businesses can use.

It’s fail-open on features — meaning nothing breaks if a limit isn’t set — and fail-closed on permissions, ensuring safety by default.
This allows Zyro to scale from individual creators to enterprise teams without changing architecture.

The philosophy behind it

Zyro isn’t about replacing people with AI.
It’s about creating a state of flow — where the system takes care of the coordination so humans can focus on ideas, decisions, and direction.

It’s built on one belief:

Growth should compound, not compete.

When every part of your digital ecosystem works in isolation, you’re always starting over.
When everything works together, you start compounding results you’ve already earned.

That’s what orchestration really means.

It’s not hype. It’s not magic.
It’s alignment — at scale.

Where this leads

The future of growth isn’t more tools — it’s fewer, smarter systems that can think together.

Zyro is built to be that system.
The orchestrated layer that connects content, testing, analytics, social, and insight into a single living network — one that keeps learning, adapting, and improving over time.

When it works, it feels effortless.
Not because it’s simple — but because everything finally moves in the same direction.

Closing thought

I don’t think in “features” anymore.
I think in flows.

The moment everything starts working together — content feeding experiments, experiments shaping analytics, analytics driving strategy — that’s when growth stops being a checklist.
It becomes a living system.

And that’s the world Zyro was built for.

🌱 Building Zyro: From Solo Project to Unified Growth Engine

Eddie Glush — Sun, 21 Sep 2025 19:58:34 +0000

When I started working on Zyro, I wasn’t trying to build yet another SEO tool or analytics dashboard. I was frustrated. Every time I wanted to understand why a site was underperforming, I found myself bouncing between five or more disconnected platforms.

SEO lived in one place. A/B testing in another. Heatmaps somewhere else. Social scheduling on a completely different stack. It felt like duct tape, not engineering.

So I set out to build something different.

The Goal

I wanted one script that could be dropped on any site — WordPress, Shopify, Webflow, custom stacks — and instantly unlock a complete growth toolkit.

Not a collection of random features, but a system where everything talks to each other:

A/B testing results feeding back into SEO strategy

Social campaign data shaping keyword research

Content gaps directly informing automated article generation

At the center of it all: conversions.

The Build

The core stack:

Backend: C# ASP.NET WebForms with SQL Server

Frontend: A JavaScript tracker that captures pageviews, clicks, scroll depth, conversions, experiments, and schema injection

Integrations: DataForSEO, Google Trends, Google Search Console, OpenAI, Google NLP, PageSpeed Insights

From there, I built out the major modules:

Content Hub for AI driven briefs and article generation

A/B Testing Suite with anti flicker, bandit modes, and Bayesian statistics

Insights Overlay with heatmaps, scroll maps, rage click detection, and mobile gesture analysis

Social Hub for trend mining and campaign publishing

Smart Feed that turns billions of signals into actionable alerts

Lessons Learned

Integration is harder than invention. Building each feature was straightforward. Making them work together took months of iteration.

Developers and marketers want different dashboards. I learned to design one system but two lenses.

AI is only as good as the context. OpenAI could generate copy, but without entity analysis and competitor insights, the output lacked edge.

Why Share This Here

Forem is about builders. Many of you are also creating tools, wrestling with architecture choices, and trying to make something that matters. I don’t see Zyro as just a SaaS. It’s a reflection of a question that has been driving me for years:

What if we stopped stitching tools together and instead built one growth engine that actually understands the whole journey?

What’s Next

I’ll be opening Zyro to early users soon. The early numbers are encouraging:

Automated articles ranking within weeks

Conversion insights surfacing in hours instead of months

Faster SEO execution across entire sites

But the bigger goal is this: make growth engineering accessible for everyone, from solo founders to enterprises.

🚀 How I Built Zyro: An All in One Growth Engine for SEO, CRO, and Social Media

Eddie Glush — Sun, 21 Sep 2025 19:56:33 +0000

For the last two years I have been obsessed with a simple question:

Why are growth tools so fragmented?

Marketers and developers are forced to juggle multiple disconnected platforms. One for SEO audits, one for A/B testing, one for heatmaps, another for social scheduling, and a pile of scripts just to track conversions.

I wanted something different. Something unified. Something that actually puts conversions at the core, not as an afterthought.

So I built Zyro. It is an AI powered growth engine that combines technical SEO, content generation, A/B testing, analytics, and social automation into a single script and dashboard.

⚡ The Vision

One script. Paste it on any site whether WordPress, Shopify, Wix, Squarespace, Webflow, or custom stack and you instantly unlock a full growth stack.

All signals in one place. Heatmaps, scroll depth, clicks, funnels, social performance, SEO metrics, and structured data health, all correlated together.

AI at the core. From article generation to entity gap analysis to predictive testing, every module leverages machine learning.

Conversions first. Every feature, from heatmaps to keyword scoring, is designed to answer the only question that matters: Does this improve conversions?

🛠️ Architecture at a Glance

Backend: ASP.NET WebForms with SQL Server

Frontend: JavaScript tracker that captures pageviews, clicks, scroll depth, heartbeats, conversions, schema injection, and experiment assignment

Data: DataForSEO, Google Trends, GSC, OpenAI, Google NLP, PageSpeed Insights

Core Modules:

AI Content Hub: Brief Builder to Article Generator to Optimizer to Publish

A/B Testing Suite: Anti flicker, bandit modes such as Thompson, epsilon greedy, and UCB1, with Bayesian and frequentist analysis

Insights Overlay: Click heatmaps, scroll depth maps, rage and dead click detection, gesture maps for mobile

Optimization Hub: Portfolio style dashboard that treats web pages like financial assets

Social Hub: Universal composer, trend mining, auto captions, analytics ingestion from Instagram, Reddit, TikTok, YouTube, and LinkedIn

Smart Feed: An alert system that surfaces what actually matters, such as “Conversions dropped 20 percent yesterday on checkout”

🧩 Example: The Smart Feed

Instead of drowning you in dashboards, Zyro condenses billions of raw signals into actionable alerts:

🔥 “Your checkout page scroll depth dropped below 35 percent on mobile”

📈 “Keyword opportunity detected: NBA prop bets trending 200 percent with low competition”

🎯 “Experiment B has reached significance with an 11.4 percent conversion lift”

This is not just analytics. It is a growth assistant.

🤯 What Makes It Different

Competitors are siloed. Ahrefs for SEO. VWO for testing. Hootsuite for social.

Zyro is unified, interconnected, and driven by AI.

Every module talks to the others. A/B tests inform SEO insights. Content gaps inform article generation. Social campaigns loop back into keyword research.

This combinatory power is the difference between tinkering and compounding.

🔮 What’s Next

I am opening Zyro up soon. Early results are already strong:

Five times faster SEO execution

Daily automated content pipelines ranking within weeks

Conversion insights that surface in hours, not months

The goal is clear. Make growth engineering accessible to every website on the planet, from solo founders to global enterprises.

🙌 Let’s Talk

If you are a developer, growth hacker, or founder who is curious about the stack behind Zyro, I would love to swap ideas.

👉 Drop a comment below
👉 Or check out zyro.world
which is launching soon

Closing thought

The future of growth is not juggling more tools.
It is one intelligent engine that makes sense of the chaos.

That is what I am building with Zyro.