Data and Methodology | Blue Tees Usage

Reference

Sources, definitions and limits

The counts on these dashboards come from production data and can be regenerated on demand. Two things need care: definitions, since "users" means users who recorded a shot rather than users who opened the app, and coverage, since several metrics only begin on the date we started recording them. Both are set out below, along with the one measurement problem we know of.

LAUNCH data through — · GAME data through —

Source

MongoDB

Production Bluetessdblive. Full population every time, never a sample

How it is built

Scripted

LAUNCH and GAME each rebuild from their own refresh script

Excluded

3 groups

Internal @blueteesgolf.com accounts, deleted accounts, guest accounts

Day boundary and units

America/New_York days. Stored metric, displayed imperial (yd, mph, °F)

Data sources

From capture to display

01 Capture The Rainmaker and the mobile apps write to production MongoDB (Bluetessdblive), shared across all Blue Tees products. One LAUNCH panel, phone vs tablet, comes from Firebase Analytics instead, because MongoDB records the Rainmaker but never the handset the app runs on.

02 Aggregate A script rolls raw rows up to day level and per club, version and device, excluding internal accounts as it goes.

03 Publish Only those aggregates are written to Firestore. No raw rows, emails, account ids or device serials ever leave the database.

04 Display These pages sign you in with Google, fetch the aggregate document, and convert to imperial at render time.

Reproducibility

Each product rebuilds from its own refresh script: scripts/refreshLaunchData.js for LAUNCH, which runs the same aggregation as the scheduled rollup/rainmakerDailyRollup.js job, and a matching script for GAME. Run either again and you get identical figures.

Nothing on these pages is hand-typed, so any number can be independently regenerated and checked against the source. A figure that looks wrong can be traced back to the rows behind it.

Exclusions

Internal accounts. Every MongoDB-sourced metric drops accounts whose email ends in @blueteesgolf.com. This happens inside the aggregation, not in the browser, so it cannot be toggled off by accident.
One exception: the LAUNCH phone vs tablet panel comes from Firebase Analytics, which carries no user id for this app. The Launch app never calls setUserId, so there is nothing to join to an email address. Staff running the public build are counted there and nowhere else. Non-production builds (dev, sandbox, preprod) are filtered out, which removes the bulk of internal testing but not all of it.
Deleted and guest accounts are excluded from all GAME metrics.
Nothing else. No shot is dropped for looking odd, and no round is dropped for being unusually good or bad. There is no quality filter on measurements.

Time, units and freshness

Days are America/New_York in both the pipeline and the display. A shot recorded at 9pm in California lands on the next reporting day.
Units are converted, never rewritten. The database stores metric (meters, m/s, °C); the dashboards convert to imperial when drawing. Stored values are untouched.
Refresh is triggered by hand for both products and needs a laptop on the VPN, so the data can lag by a day or two. Read the "data through" date in the header rather than assuming today. Moving this to a scheduled job is the next infrastructure step.

Confidence by metric

What each number counts

Definitions

Exact A direct count of records matching a stated rule. Reproducible to the row.

Derived Inferred with a rule, because the database has no explicit field for it.

Point in time Read from a field that only holds a current value. Cannot be rebuilt for a past date.

Sampled Computed from a bounded recent sample, not the full population.

Estimate Bridges two systems that cannot be joined. Directional only; do not quote precisely.

Metric	Confidence	What it actually counts	Read it with care
LAUNCH: Rainmaker and Launch app
Shots	Exact	Every recorded shot from a non-internal account.	Includes warm-ups, mishits and indoor practice. Nothing is filtered for quality.
Users who tracked a shot	Exact	Distinct accounts with at least one recorded shot.	Not app openers. Firebase's active-user counts are legitimately much higher.
Sessions, indoor and outdoor	Exact	Practice sessions, split on the recorded environment.	A session with no environment recorded appears in the total but in neither split.
Shots per session	Derived	Shots in the period divided by sessions created in the period.	Both sides are exact, but they are not a matched pair: a session created near the period edge can hold shots that fall outside it, and shots whose session no longer exists still count in the numerator. Read it as practice depth, not as a per-session average you could reproduce session by session.
Session types	Derived	Sessions grouped into practice, target and speed by the mode the Rainmaker was in.	The mode is a number the device sets, not a label the golfer picked, and it is mapped to a name by rule. Per-type shot counts drop shots whose session no longer exists, about 1%, reported separately as unattributed rather than folded into a type, so the three types will not sum to total shots.
Average ball speed	Exact	Unweighted mean across every shot in range.	Directly measured, so the most trustworthy metric the device produces. Still an average across all clubs and skill levels.
Average carry and smash factor	Derived	Unweighted mean of values the device's flight model produces.	Modeled, not measured. See the RCT bias below before quoting these as device performance.
Connected vs standalone	Derived	A capture with no app version recorded is treated as standalone: the Rainmaker was used with no phone attached and synced later.	Inferred from missing app metadata, not an explicit flag. It cross-checks exactly against app-version counts. An explicit firmware flag would make it definitive.
Active devices	Derived	Distinct Rainmaker serial numbers seen that day.	The serial is only present when the app was attached, so this undercounts by roughly the standalone share.
Shots hit with an RCT ball	Exact	Share of recorded shots flagged as using a radar-capture-technology ball, which the Rainmaker reads spin and launch angle off directly.	The complement of the RCT-off share quoted under RCT bias below, and the reason that section matters: every shot outside this slice has spin and launch angle inferred by the flight model rather than measured. The share is small, so treat the club spin and launch-angle averages on the dashboard as modeled figures.
App version mix	Exact	Captures per recorded app version.	Standalone captures have no version and are excluded here. That is why capture mode and app version are two separate charts. Adding them together double-counts.
Firmware mix (Rainmakers)	Exact	Each Rainmaker counted once, on the newest firmware version it has been seen reporting.	A Rainmaker only reports its serial number and firmware while the app is attached, so one used exclusively standalone has never appeared here at all. Counts Rainmakers seen in use, not Rainmakers sold. Firmware below 1.40, the first mass-production build, is excluded as internal pre-production hardware; the excluded counts are stated on the panel.
Firmware mix (shots)	Derived	Recorded shots attributed to a firmware version. About two thirds carry a version of their own; the rest are attributed from the same golfer's nearest-in-time connected session.	The Rainmaker only reports firmware when the app is attached, so standalone captures have none and are inferred. Two assumptions: that a golfer has one Rainmaker, and that firmware did not change during a standalone-only stretch, which makes the inference lag slightly toward older versions. A small remainder is resolved only from the Rainmaker's registration record, which stores the version it shipped with and is never updated afterwards, so treat that slice as a floor. Roughly 2% of shots cannot be attributed at all and are excluded rather than assigned. The measured share is shown on the panel itself.
Rainmakers never updated	Derived	Rainmakers that have only ever reported one firmware version.	Only updates that happened between two connected sessions are visible. A Rainmaker that shipped, updated and then was only ever used standalone reads as never updated. The figure is therefore an upper bound on how stalled the rollout is.
My Bag customization	Derived	Golfers with a bag record, and how many changed it from the starting set of clubs.	Which clubs ship in the starting bag is not stored anywhere we can read, so it is inferred from the clubs golfers have removed, so a default nobody has ever removed is invisible to us. Bag holders also outnumber shot recorders, and the two groups are not nested, so these descending counts are not a funnel and no step conversion should be read off them.
Activation rate	Estimate	Firebase monthly app users compared against accounts that recorded a shot.	A ratio between two populations that cannot be joined per person, and the Firebase side still includes internal staff. Roughly a third, and approximate.
Dormant users (30-day)	Point in time	Golfers whose most recent recorded shot falls 31–60 days before this data's last refresh, with none since, set against golfers who have recorded a shot in the most recent 30 days. Current figures: load once you're signed in.	A snapshot tied to the pipeline's last refresh, not the page's date-range picker, so it does not move when you change the range. Anyone whose last shot is more than 60 days old falls out of both buckets rather than inflating dormant indefinitely. Excludes internal accounts, same as every other MongoDB-sourced LAUNCH metric.
Phone vs tablet	Exact	Devices that opened the Launch app, split by whether Firebase reports the handset as a phone or a tablet. Public App Store/Play build only.	The only figure on these dashboards that still includes Blue Tees staff. Firebase is the sole source of form factor. MongoDB records the Rainmaker but never the handset, and the Launch app sends no user id, so there is nothing to join to an email address. Dev, sandbox and preprod builds are excluded, which removed roughly 9% of devices and moved the split about three points. It counts devices that opened the app, not golfers and not practice sessions, so it will not reconcile against either. Coverage starts Jul 25, 2026 (when the export was switched on) and rolls forward on a 60-day window, so it is not all-time and does not follow the date-range picker.
GAME: mobile app and connected devices
Total GAME users	Exact	Non-deleted, non-guest, non-internal accounts with an iOS or Android GAME version recorded.	Not "every account ever created". The recorded-app-version requirement is part of the definition, so this is a cleaned base, not a raw total.
New users per day	Exact	Cleaned accounts created that day.	Reliable from Jun 5, 2023. Eight isolated accounts predate filterable history.
Platform split	Exact	Cleaned GAME accounts by the platform recorded on the account.	Platform is also what makes an account a GAME user at all: storefront records created on the web are not app signups and are excluded from every GAME metric. This is the account's platform, not a per-session device, so a golfer who moved from Android to iOS counts once. LAUNCH has no equivalent.
Daily, 7-day and 30-day active users	Point in time	Accounts whose last-active timestamp falls inside the window.	Means "opened the app", not "played golf". Each account stores only its latest value, so there is no historical daily-active series and these tiles cannot be recomputed for a past date.
Active golfers (daily series)	Exact	Users completing at least one valid round that day.	A stricter definition of "active" than the tiles above. The two will disagree; both are correct.
Completed rounds	Exact	Rounds marked complete with at least one played hole and recorded strokes.	Abandoned rounds are excluded by design, so this is lower than the raw round count. History starts Sep 30, 2024.
AI interactions and AI users	Exact	Logged Scout AI recommendation requests, and the distinct users making them.	Exists only from Dec 31, 2025, when the public beta opened. Nothing before that is missing data. The feature did not exist.
AI response time (median, 95th)	Sampled	Latency across the most recent block of roughly ten thousand cleaned interactions.	A recent sample, not full history. Use it as a current health check, not a trend.
AI error rate	Sampled	Errors logged within that same sample.	Counts failures we log. Silent timeouts and client-side failures may not appear, so read it as a best case.
Feedback sentiment	Exact	In-app feedback responses, split positive, neutral and negative.	Respondents are self-selected, so this measures the people who chose to answer, not the whole base. Collected from Aug 18, 2025.
Device mix	Point in time	Registered devices per user, counted per product.	Current state, not history. This panel does not follow the date range and will not reconcile against a past date.
Device ownership	Derived	Registered products per golfer, and how many own more than one.	The trap most likely to produce a wrong headline. Two of the "products" in the source are app-side registrations with blank serials rather than hardware; leaving them in turns multi-device ownership from roughly — into roughly —, so they are excluded here. Registrations are also lifetime, making this cumulative ownership rather than devices in use today.
Dormant golfers (30-day)	Point in time	Golfers whose most recent completed round falls 31–60 days before this data's last refresh, with none since, set against golfers who have completed a round in the most recent 30 days. Current figures: load once you're signed in.	A snapshot tied to the pipeline's last refresh, not the page's date-range picker, so it does not move when you change the range. Anyone whose last round is more than 60 days old falls out of both buckets rather than inflating dormant indefinitely. Excludes internal accounts, same as every other GAME metric.
Rounds per golfer	Point in time	Completed rounds recorded per golfer over the trailing 365 days, as a median, a set of percentiles and a distribution. Headlined for golfers with at least one round; the all-accounts median (which is 0) ships beside it.	The median badly understates the panel on its own — the mean is more than double it, because a small group playing 24+ rounds a year carries the total. Read the distribution, not the median. The gap between rounds excludes golfers who played exactly once, since they have no gap; they are the largest single bucket, so that figure describes returning golfers only. A snapshot tied to the pipeline's last refresh, so it does not follow the date-range picker.
Scoring adoption	Point in time	Share of GAME accounts that have ever recorded a completed round, for all accounts and for those active in the past 90 and 30 days.	“Active” here is app-level activity (the account's last-active timestamp), deliberately not “recorded a round recently” — that would be circular and read 100%. It is also not the account's update timestamp, which something server-side touches on every record and reads 100% at any window. Roughly 1.3% of accounts carry no last-active value and fall out of the two active cohorts, never out of the all-accounts row. About 18% of the user ids appearing in the rounds data belong to deleted, guest or storefront accounts rather than current GAME accounts; they are excluded from numerator and denominator alike, so each share divides a population by itself.
Membership mix	Estimate	Users grouped into legacy, Core and Intelligence plans.	The weakest figure on either dashboard. These are pinned values rather than a live query, and the rule that sorts a user into a plan is still unconfirmed. Read the shape, not the totals.

LAUNCH notes

Rainmaker and Launch app, from May 27, 2026

What to trust

The counts are exact and rebuildable. One script regenerates every figure from the source collections.
It is the full population, every recorded shot since launch. No sampling, no extrapolation.
Internal activity is out, removed in the aggregation rather than filtered afterwards.
Ball speed is measured, making it the device metric that carries the most weight.

What to qualify

"Users" means users who recorded a shot. Someone who opens the app and never hits a ball is not in these numbers, by design.
The most recent days undercount and revise upward. Standalone captures only arrive when the Rainmaker next meets the app, around three days later on average, measured late July 2026. Yesterday's figure is provisional.
The standalone share (roughly a sixth of captures) is inferred, not flagged.
We cannot split LAUNCH by iOS and Android. The app does not send the platform with its data, and the account-level platform field records where the account came from, such as Shopify. The platform is not instrumented.
Firmware on a standalone capture is inferred. The Rainmaker reports its version only while the app is attached, so around a third of shots borrow a version from the same golfer's nearest connected session. Rainmakers are registered in the database, but the firmware stored there is what the unit shipped with and is never refreshed after an update, so it is a floor rather than a reading. Versions below 1.40, the first mass-production build, are internal pre-production units and are excluded from the firmware figures.
Averages are unweighted. Clubs, ball types, indoor and outdoor, and every skill level are mixed together.

Spin and launch angle with RCT off

With RCT disabled, which covers about — of all recorded shots, the Rainmaker reports total spin roughly — lower than it does with RCT enabled, consistently across every club, and launch angle — low. Measurement details load once you are signed in.

This is a systematic model bias, not dirty data. The RCT-off spin values are clean, with no zeros or negatives and almost nothing outside a plausible range, and they barely move as ball speed rises, which indicates the flight model is falling back to a club-typical default instead of tracking the actual strike. A flat correction therefore would not fix it; the correction has to restore sensitivity to ball speed. Launch angle being low under the same conditions points to one shared cause in the flight model rather than two separate faults.

Practical guidance: spin and launch-angle figures drawn from this data are biased low and should not be used as device accuracy claims. Ball speed is unaffected. Carry sits in between, since it is modeled from launch conditions. The bias is quantified and being worked on.

GAME notes

Mobile app and connected devices

When each metric starts

Jun 5, 2023User and account history begins.
Sep 30, 2024Round tracking begins. There is no round data before this date, not for 2023 and not for most of 2024.
Aug 18, 2025In-app feedback collection begins.
Dec 31, 2025Scout AI public beta. Every AI metric starts here.
Jun 17, 2026Intelligence tier launches. Membership mix changes meaning from this date.

Coverage dates

A zero before a start date means "not recorded", not "did not happen". Any chart spanning one of those dates shows a step change caused by instrumentation, not by golfer behavior, and comparing two metrics across a long range compares two different coverage windows. The dashboard labels these dates on the coverage strip and in the AI panel.

Other definitions

There are two definitions of "active". The headline tiles count app opens from a current-state field; the daily series counts golfers who completed a round. Both are correct.
Total users is a cleaned count, not every account ever created.
AI latency and error rate come from a recent sample, so they describe how the service is behaving now rather than how it has behaved.

Shared limits

Applies to both LAUNCH and GAME

This is a live database, not a warehouse. There are no historical snapshots. If rows are deleted, corrected or backfilled at the source, a past day's number can change after the fact. The numbers are re-derivable, not immutable, so keep a copy of anything you cite in a document, with the date you pulled it.
A day with no activity has no row at all. A day is written only when something happened on it, so a completely quiet day is absent rather than stored as a zero. LAUNCH has two, 30 and 31 May 2026 in its first week, which is why its coverage reads 77 days across a 79-day span. Counting rows is therefore not the same as counting days: a seven-day average spanning that gap would divide by five and read about 40% high. A day whose only activity came from internal accounts disappears the same way, since those are excluded before the day is counted, so an absent day means no external activity, not certainly none at all.
Demo, retail and review units count as customers. Beyond excluding internal email addresses there is no flag for a demo unit, a retail floor device or a reviewer's sample. Assume a small upward bias in LAUNCH user and device counts.
There is no shared identity across systems. The LAUNCH app does not tag its analytics with our user id, so Firebase app behavior and MongoDB product activity cannot be joined per person. Every figure combining them is a ratio between two populations, which is why activation is an estimate.
One timezone for everyone. All reporting days are America/New_York, including for golfers on the west coast and overseas.
Averages are unweighted throughout. A single heavy user can move a daily average, and no metric is normalized per user unless it says so.

Common questions

Yesterday's number changed. Is the data broken?

Almost certainly not. Recent LAUNCH days revise upward as standalone captures sync from Rainmakers that were used without a phone, around three days on average. Beyond that, every refresh recomputes from the live database, so corrections and account deletions at the source flow through to history.

A day that moves by more than a few percent a week after the fact is worth raising.

Why doesn't this match the number in Firebase?

Because they measure different things. Firebase counts app opens and sessions; these dashboards count product activity: a recorded shot, a completed round. Firebase is legitimately higher, and it also still includes internal staff because it has no email to filter on.

The two cannot be reconciled per person today, so treat Firebase as the source of truth for app reach and these dashboards as the source of truth for product usage.

Can we split LAUNCH usage by iOS and Android?

Not today. The LAUNCH app does not send the platform alongside its data, and the account-level platform field records acquisition source, such as Shopify, rather than device OS. Firebase can answer platform questions about app opens, but those cannot be tied to shot activity.

Is the spin number our device produces accurate?

With RCT enabled, spin and launch angle look consistent. With RCT disabled, about — of recorded shots, spin reads roughly — low and launch angle — low. It is a known, measured, systematic bias with a single likely cause in the flight model.

Do not quote dashboard spin averages as a device specification. Ball speed is unaffected.

Why is there no GAME round data before late 2024?

Because it was not recorded. Round tracking began Sep 30, 2024, feedback in Aug 2025, and AI in Dec 2025. Earlier gaps are instrumentation history, not lost data, and cannot be backfilled.