ESPN auction-draft assistant · Last updated 2026-08-06
What this extension does
AlphaDraft reads the live data stream of an ESPN auction fantasy draft
while you are on an ESPN draft page, and turns it into real-time bid/pass guidance. To do that it
observes the WebSocket messages the ESPN draft page already exchanges (nominations, bids, the clock,
and sales) and forwards a normalized version of them to its configured receiver.
What data is handled
Draft event data from the active ESPN auction draft: nominated players, bid
amounts and the seats that placed them, the draft clock, and completed sales. This is
fantasy-sports gameplay data, not personal browsing history.
Draft context data read from the draft page to make the above usable: the
league ID, the team display names and team IDs in your draft, each team's budget and roster (the
player names, positions, and prices they've won). Team/owner display names are league-chosen
labels that can contain real names or usernames — this is the in-draft state visible to your
league, not your personal account data.
A cached copy of the latest draft snapshot and a sold-player index, written to
Chrome's local storage on your own device so the war room can resume after a page
reload. These hold the draft-context data above; they live only on your machine and are cleared
when you remove the extension.
A short, bounded local retry queue of draft events awaiting forwarding, so a
brief network or relay hiccup doesn't drop picks. It is held in Chrome's local storage on
your device only (never synced), is capped in size, and is cleared when you remove the extension.
In the Chrome Web Store build, draft events captured before you grant the hosted permission are
held in this on-device queue and are forwarded only once you grant it.
Your extension settings, stored by Chrome: the configured forwarding
destination (in the developer / side-load build you can pick Local or Hosted; the Chrome Web Store
build uses Hosted), whether forwarding is enabled, the optional raw-capture toggle, and the status
of the last forward.
An in-page overlay credential (only if you turn on the optional in-page
overlay): a short-lived, read-only access token and the war-room room id, written to
Chrome's local storage on your device only (never synced) so the on-page advice can
authenticate. It is never sent anywhere except as an authorization header to the war-room service
when fetching your own draft advice.
A draft-capture write credential and a local transition ledger (only if you
authorize draft capture for a war-room room from the hosted dashboard): authorizing issues the
extension a single-draft, room-scoped, expiring write credential, held in Chrome's
local storage on your device only (never synced) and sent nowhere except as an
authorization header to the hosted war-room service when forwarding that room's draft capture.
Alongside it the extension keeps a local ledger of the draft's lot transitions and a
queue of not-yet-acknowledged capture records (draft gameplay facts — which player's
auction opened or closed, in what order) so a browser or page restart cannot lose or reorder
them. The credential and ledger are readable only by the extension itself (never by web pages),
are replaced only through a fresh dashboard authorization, and are cleared when you remove the
extension. The extension uses Chrome's identity permission solely
to run that authorization redirect against our own service — it never requests, reads, or
receives your Google account identity.
The extension's content scripts run on ESPN domains — it reads and acts on your live auction-draft
page. The extension also declares a small content script on the AlphaDraft war-room site
(alphadraft.ai; the developer / side-load build also covers the legacy war-room address
draft.ninetalents.com) whose only job is to receive the short-lived overlay
access token you enable when you turn on the optional in-page overlay — it reads
no other website's content and does nothing until you turn the overlay on. The only
non-ESPN addresses the extension can reach are
the receiver destinations for the draft data it forwards: a local receiver on your own computer
(loopback) or the hosted war room — which one is the default depends on how you installed the
extension (see below). It does not track your browsing, contains no
analytics or advertising SDKs, and the extension itself does not collect your name, email, contacts,
location, or financial information.
Where the data goes (this is the important part)
Where the extension forwards your draft events depends on how you installed it.
(If the extension's options page offers only a hosted receiver, you have the Chrome Web
Store build; if it offers both a local and a hosted receiver, you have the developer /
side-load build.)
Chrome Web Store build — the default destination is the hosted war room. The
published package is preconfigured to forward draft events to the hosted AlphaDraft
war room at https://alphadraft.ai. Forwarding is enabled, but Chrome does
not let the extension send to that hosted receiver until you grant the
optional site permission it must have to forward there — requested on a deliberate click,
not granted automatically at install.
Before you grant it, no draft events or snapshots are sent to the hosted receiver.
After you grant it, draft events are sent to and stored by the hosted service, as described under
"Storage and retention" below. The Store build does not include the local-receiver option.
Developer / side-load build — the default destination is your own computer. The
beta / developer build is preconfigured to forward draft events to http://127.0.0.1:8971
— a server running on your own computer (the loopback address). If you have not
started that local receiver, nothing is received and nothing leaves your machine. This build sends
to the hosted war room only if you switch the receiver to "Hosted" and grant the hosted site
permission. Older side-load builds configured for the legacy war-room address
(draft.ninetalents.com) keep working — it is the same hosted AlphaDraft service,
which currently answers at both addresses.
What the defaults are, per build: event forwarding is enabled by default in both
builds, but the default destination differs. In the Chrome Web Store build
the default destination is a remote server (alphadraft.ai); your draft data
reaches it only after you grant the hosted site permission Chrome prompts for. In the
developer / side-load build the default destination is your own computer (loopback),
and no draft data is transmitted off your device unless you switch to the Hosted receiver and grant
that permission.
Raw capture (off by default, local only)
The options page has an optional "Capture the raw frame stream" toggle used for diagnostics. It is
off by default, and the extension structurally refuses to send raw frames
to any non-local address — raw capture only functions when the receiver is the loopback
address, and that setting is stored locally and is never synced to other devices. (Because the
Chrome Web Store build has no local receiver, raw capture cannot send anywhere in that build.) This
guard exists because a raw frame can embed session/room material.
Signing in to the hosted war room (Google)
The hosted war-room service at alphadraft.ai is access-controlled, so if you opt
into it you sign in with Google. We request the standard, non-sensitive sign-in
scopes openid email profile — that is your email address and basic profile (your name
and profile picture), which we use to identify your account and gate access. We do
not request access to Gmail, Google Drive, your contacts, your calendar, or any
other Google data. The browser extension itself does not sign you in and requests no Google
permissions.
Storage and retention
Settings are stored using Chrome's storage API on your device (non-sensitive
preferences in your Chrome profile sync; the raw-capture toggle in local storage only). In
addition, the latest draft snapshot and a sold-player index are cached in Chrome's
local storage on your device (never synced) so the war room can recover after a
reload — this is draft-context data, held locally, not personal account data. You can clear all of
it by removing the extension.
The extension itself does not maintain a server-side database of your data. When the
Hosted receiver is used (the default in the Chrome Web Store build, once you grant
the site permission), the AlphaDraft service stores the
room state needed to run and support your war room on its server: the draft events and snapshots
you forward, the engine's decisions, capture/health diagnostics, your account profile (your email
and Google display name), and the league setups you save. This is retained while you use the
service and for support; you can request deletion via the contact below. You can also turn
draft-data retention off from your signed-in home page ("Draft-data retention"):
that stops the service keeping the draft records for drafts you run from then on — it does not
delete what was kept earlier (use the contact below for that) and does not affect your account
or saved league setups.
If you sign in with Google and your account has not been given access, we record your
access request — your email address, your Google display name, and when you
asked — so the operator can approve or decline it. No account is created unless it is approved.
A request is kept until it is acted on, and afterwards as the record of that decision — except
that once a request has been approved — at which point your address is on the access list and
an account is created the next time you sign in — its record may be dropped as older entries age out. Ask via the contact below to have it deleted. The alert the operator receives about a new request contains
no personal data: it says only that someone asked, and the details are read on
our own server.
The Local receiver writes files on your own machine that you control entirely.
How the data is used
Solely to provide the draft-assistant functionality: turning the live draft into bid/pass guidance
for you, and (for the hosted service) identifying your account so your war room is yours.
Usage analytics
To understand whether the site is reaching and helping people, we keep a small amount of
first-party, aggregate usage analytics on our own servers. We never use
advertising-company analytics (such as Google Analytics), and we set no tracking
cookies.
We also use Umami, a privacy-focused, cookieless analytics service, hosted for us by Umami Cloud, to measure how the site is used. Umami sets no cookies and stores nothing in your browser, and we send it no account identity. For each page view or usage milestone it receives standard web request data — the address and title of the page on our site (our configuration strips any query parameters), the referring site, your browser, operating system, device type, screen size, and language, and — like any web server — your IP address, which it uses to derive an approximate location and to distinguish visits using rotating, anonymized identifiers computed on its servers (never placed in your browser; the provider states it does not store the IP address itself). We use the resulting statistics to understand aggregate usage, never for advertising or to identify you. For exactly how the service processes this, see Umami’s privacy policy.
What we keep on our own servers are aggregate counts — plus, only so we can de-duplicate (count a
session or an account once), a one-way, salted digest we cannot
reverse back to the underlying id. We never store the raw ids themselves:
Anonymous page activity and the within-visit sign-in funnel — counts of
landing-page views, "Sign in" clicks, reaching the signed-in app, and reaching a live draft
recommendation in the app. To understand the sign-up funnel within a single visit —
how many sessions that arrive go on to sign in and use the tool — your
browser generates a random, anonymous session id and keeps it in your browser's
session storage. That id is temporary — scoped to the browser
tab session and normally cleared when that tab session ends — first-party, is not a
cookie (and not local storage), and is never used for
advertising, third-party analytics, or cross-site tracking. Our server never stores the
id: it keeps only a one-way, per-day salted digest of it so it can count distinct
sessions, and surfaces only the totals — never the id itself. We store no IP address and no
browser fingerprint as part of these analytics. (Like any web server, our host may keep
operational request logs, which can include an IP; those are not part of these analytics and are
not used to profile you.) Because this id lives only in your browser and only for the session,
these counts are best-effort — clearing storage or a new tab session generally starts a new
session id — so they tell us how sessions moved through sign-in, not who arrived or how many
people. These analytics keep no persistent identifier in your browser: an
earlier version of the service kept a persistent local-storage visitor id to count returning
browsers — that id is retired (the site now deletes it if your browser still
holds one), and the aggregate de-duplication digests it fed are pruned on their short
retention window. (Ordinary functional preferences you set, such as the display theme, are
stored in your browser but are not identifiers and are never sent to us as analytics.)
Signed-in activity counts — how many distinct accounts were active on a given
day, how many leagues were created, how many drafts got going, and the aggregate outcome of
sign-in attempts (how many succeeded versus were turned away — for example because an email is not
yet invited). These are plain counts with no account attached to them. For the daily-active count we
store only a one-way, salted digest per day so we can count distinct accounts without keeping a list
of who was active; we surface only the totals.
Onboarding & reliability counts — how many times an ESPN league was looked
up to import it and the outcome (found, incomplete, or couldn't be read), and an aggregate count
of extension "test connection" reachability pings. The league-lookup counts come from signed-in
sessions and count the lookup/preview step, not saved leagues; the reachability ping is
unauthenticated, so — like the page-activity pings — a refresh or bot can inflate it. All are
plain counts with nothing about you attached; they tell us whether onboarding is working.
Where visits come from, and coarse device / browser — for anonymous
landing-page views we keep aggregate counts of the broad source a visit came
from (for example a search engine, a social site, or "direct"), derived from the referring
site's host — we never keep the full referring web address or any search terms
in it — together with a coarse device class (desktop / mobile / tablet),
browser family (Chrome, Safari, and so on), and the nearest network
edge region a visit arrived through. The device and browser are derived from your
browser's user-agent, which our server reads once, in the moment, and
then discards: we do not store the raw user-agent, we do not build a
device fingerprint, and we do not join any of this to your session id or account.
The edge region is a coarse, approximate "which part of the world" signal read
from a network header our hosting provider adds (the nearest point at which your visit entered
its network) — not a precise country, city, or location, and distinct from
where our servers run. We do not read or store your IP address for these
analytics — the region comes from a header, never from an IP — and we do not
collect a precise country, city, or location. If the landing URL carries a
utm_source label (typically from a campaign link, though anyone can put one in a URL,
so it is unverified), we keep a bounded, sanitized copy of it. Like the other landing counts
these are best-effort and can be inflated by a refresh or bot, so they tell us how visits arrive,
not who or how many people.
AI-generated explanations (optional)
Some hosted war-room features use an AI provider (Anthropic) to put the engine's
reasoning into plain English. The recommendation itself is always made by our own deterministic
engine, not the AI. These features only run when the hosted service is configured for them; if it is
not, nothing is sent to any AI provider. Two paths use it:
The automatic one-line "why." Next to a recommendation, the service sends a
curated, allow-listed set of decision facts for the current player — projections,
your roster needs, and the market math the engine used — to phrase a single sentence. This
projection is structured to exclude your account identity and other managers' or
league display names, so that identity data is not sent.
The interactive advisor (only when you ask it). If you open the advisor to argue
a case for a player, the text you type is sent to the AI provider along with the
target bid and the same curated facts, so it can weigh your argument. Because this is free text,
treat it like any message to an AI service: don't type anything into it you wouldn't want
sent to the AI provider.
What we never do
We do not sell or rent your data.
We do not use it for advertising or to build advertising profiles.
We do not use advertising-company analytics (such as Google Analytics) or
tracking cookies — usage analytics are first-party aggregate counts on our own servers, plus a
cookieless privacy-focused analytics service if one is running. The
"Usage analytics" section above states whether one is running right now, and exactly what it
can see.
We do not transfer it to third parties except: the receiver the extension
forwards your draft data to; if a cookieless analytics service is running (see "Usage
analytics" above), the standard web request data it receives on each page view — including
your IP address — which that section enumerates in full; — only for the optional
AI explanation features described above — the data those features send to our AI provider (the
curated decision facts, plus the text you type if you use the interactive advisor); and, when
we email you, your email address and the message itself — which greets you by the
name your Google account gave us, when we have one — to the mail provider that delivers it,
since that is the only way an email can reach you at all. The only messages we send are about your access to
the service: a confirmation when you ask for access, a notice if you are approved, and — if
the operator puts your address on the access list without you asking — one message telling
you that you can sign in and how. (Asking again later, being approved after an earlier
decline, or being invited again after being removed can produce another of those — they are
the only kinds there are.) There is no marketing or newsletter mail, and no mailing list to
be added to.
We do not use it for any purpose unrelated to the single purpose stated above
(consistent with the Chrome Web Store Limited Use requirements).
Affiliation and trademarks
AlphaDraft is an independent tool compatible with ESPN Fantasy. It is
not affiliated with, endorsed by, or sponsored by ESPN, The Walt Disney Company, or
the National Football League. "ESPN" is a trademark of its respective owner and is used here only
nominatively, to describe what the tool is compatible with — not to imply any partnership. The tool
reads the draft data shown in your own authenticated ESPN session, on your behalf; it does not
circumvent ESPN's access controls or speak for ESPN.
Changes
Material changes to this policy will be reflected here with an updated "Last updated" date.