Methodology

How Geod computes every number, and why the answer survives committee.

We document everything: data sources, aggregation logic, scoring weights, snapshot dates, and the boundaries of what the model does and does not claim. When the CFO asks where a number came from, the brief already contains the answer.

Every analysis answers three questions

1

Who can you reach?

The trade area defines who could realistically visit a site. We build trade areas from actual travel time, not arbitrary radii.

2

How much demand exists?

Within that trade area: how many people, how much spending power, what's the density? Demographics aggregated to the catchment.

3

How crowded is it?

How many competitors are already serving that trade area? Is there room for another, or is it saturated?

For a closure, conversion, or opening, the fourth question is the one that matters: What happens to your existing stores? Per-store demand transfer, sibling recapture, and net new opportunity, computed against the network as it stood on the effective date.

For site access, we keep reach separate from accessibility. Reach describes the travel-time catchment. Accessibility describes whether the site can be used: ingress, egress, turns, parking, stacking, pedestrian or transit path, and confidence in those inputs. When curb-level access has not been verified, we mark it unavailable instead of turning catchment size into an access score.

Trade areas: how we define “who can reach”

Travel-time isochrones, not radii

A 10-minute drive isn't a circle. It's shaped by roads, intersections, traffic patterns. We generate real isochrones using road network routing.

Time-of-day aware

Rush hour traffic changes the shape. A site's 10-minute catchment at 8am is different from 2pm or 7pm. We let you specify the time window that matters for your concept.

Multiple rings

Standard output: 5, 10, and 15-minute drive times. Need different thresholds? Configurable by scenario.

Stored and versioned

Every trade area gets a deterministic ID. Reference it later, compare across analyses, audit months after the decision.

What we use: Mapbox Isochrone API with traffic-aware routing.

Demographics: how we measure demand

Source evidence

We use Census and American Community Survey estimates where their source is verified. Briefs distinguish those inputs from estimates whose original survey source or vintage has not been established.

Aggregated to your trade area

Where block-group or tract Census inputs are used, we aggregate them to your catchment using area-weighted interpolation on an H3 hexagonal grid.

Metrics where supported

  • Total population
  • Total households
  • Population density (per sq mi)
  • Median household income
  • Average household income
  • Median age
  • Age distribution brackets
  • Household size
  • Owner vs. renter
  • Educational attainment
  • Commute patterns

Source vintage disclosed

Briefs show a Census or ACS vintage when the source evidence supports one. When it does not, the brief says the original survey vintage is unverified.

Why source evidence matters: Census data is a defensible input when its lineage is known. The brief should distinguish that evidence from modeled or unknown-vintage estimates.

Competition: how we measure saturation

Source: Foursquare Open Places

Indexed place records are used where the full trade area has verified source coverage. The brief shows the source date and its limits; a record does not prove that a distinct business is currently operating.

Filtered to relevant categories

We match indexed records to the selected business category, such as coffee or fitness. Network projects can also use a curated competitor list.

Counted and listed when covered

  • Category-matched indexed place-record count in the trade area
  • Indexed place records per square mile
  • Nearest indexed records by distance in Network briefs
  • Names and addresses when present in the source and plan

Operating-status limits

Foursquare records can include closure dates, but the currently served indexed extract has not been independently verified for closure filtering. Listed records are not proof of currently operating businesses, and state license data is not used to reconcile their operating status.

Bring your own competitors

In Network plans, upload your competitive set. Your intel, your definitions, supplementing or replacing our defaults.

Scoring: how we combine it into a recommendation

Weighted linear model

The score is a weighted sum of components. No neural networks, no hidden layers. Arithmetic you can verify.

Default components

  • Reach: Population and customer base within the travel-time trade area
  • Demand: Income index relative to baseline
  • Competition: Inverse of competitor density (more = lower score)
  • Accessibility: Site-access usability and confidence signals where available

Default weights

Reach: 30% | Demand: 30% | Competition: 25% | Accessibility: 15%

Fully transparent

Site scores 74 = Reach (28) + Demand (31) + Competition (-12) + Accessibility (27)

Every component visible. Disagree with the weights? In Network plans, you set your own.

Why linear? Explainability. A linear model can be written on a whiteboard. It survives CFO scrutiny. Complex models score better on benchmarks but die in committee when no one can explain the output.

Cannibalization: how we measure network impact

Share-of-choice allocation

Every resident cell in the trade area is divided among the stores that could serve it: yours and the competitors'. Each store's share is weighted by distance, store draw, and how substitutable that store's category is with the brand being evaluated. A store's demand is the sum of its shares. Overlap is weighted by where people actually live, never by raw square miles of intersection.

Per-store decomposition

A move never reduces to one number. A closure shows the released demand, how much each nearby same-brand store wins back, and how much leaks to competitors, store by store, by name. A conversion shows both sides: what the original brand gives up and recaptures, and what the destination brand's own nearby stores lose to the converted site.

Competition as each brand sees it

The same competitor matters differently to different brands. Every competitor is weighted by category substitutability against the specific brand being evaluated, and the resulting weights are shown in a table you can read, not buried in a score.

Units, stated plainly

Demand figures are residents of the surrounding drive-time area, assigned to the store each is most likely to use. They are not visits and not sales. Converting demand to revenue requires your own store sales data, and until that data is connected we say demand share and nothing more.

No imputed numbers

When a component cannot be computed honestly, it is omitted and labeled as omitted. When a question is degenerate, like adding a brand a site already operates, the model refuses and explains why instead of fabricating an answer.

Network plan feature

Predictions: how we keep score

Every move registers a prediction.

A closure or conversion brief stores its predicted change in demand for each affected store, together with the network state, the parameter set, and the catchment settings it was computed under, and a due date. The brief you export and the prediction on file are the same numbers.

Reconciled against your actuals.

You import sales before and after the move, store by store. Geod reports the predicted change next to the actual change, the signed error per store, and the aggregate error across the set. Stores with a stated confound, such as a remodel or a road closure, stay visible and are flagged rather than dropped. The report exports as a PDF.

Assumed or calibrated, stated in the brief.

Every brief names the parameter set it used and says whether those parameters were assumed defaults or fitted to your reconciled outcomes. Parameter sets are versioned; a refreshed brief cites the new version and the old brief stays as it was.

Early access: sales-anchored forecasts.

Today the transfer figures are demand shares. Anchoring each affected store to its own reported sales so the change is stated in dollars, and separating the effect of a move from the market's background drift with matched controls, are in development and ship as early access. Until then, a brief says demand share and nothing more.

Network plan feature

Data freshness: how we keep it auditable

Snapshot timestamps

Briefs show verified source dates when available and disclose unknown survey vintages or POI coverage gaps.

Deterministic IDs

Trade areas, snapshots, and analyses get stable identifiers. Reference them in reports, compare across time.

Reproducibility

Run the same inputs six months later and get the same outputs, unless the underlying data updated. No stochastic variation.

Methodology in every export

PDF briefs include a methodology section: data sources, aggregation method, scoring weights, snapshot dates.

Why this matters: Deals close months after analysis. Boards review decisions years later. The brief needs to stand on its own.

Current status

Live for all workspaces
  • Travel-time trade areas (Mapbox routing)
  • Demographic estimates where source cells support the metric
  • Competition from indexed POIs where trade-area coverage is verified
  • Explainable scoring with component breakdown
  • PDF brief export with methodology
Live for Network plans
  • Portfolio upload (your locations, brands, and combo stores)
  • Custom scoring weights
  • Closure, conversion, and opening scenarios with per-store transfer
  • Predictions registered and reconciled against imported actuals
  • Historical moves modeled against the network as it stood on the effective date
  • Batch candidate evaluation
In development
  • Transfer stated in dollars from your store sales (demand share today)
  • Matched-control reconciliation to separate a move from market drift
  • Operating-license reconciliation and broader geographic coverage
  • Traffic count integration
  • Foot traffic / mobility data partnerships
  • Enhanced daytime population estimates

We'll update this page as capabilities ship.

Need more detail?

We maintain a technical methodology document with data lineage, validation procedures, and calculation specifics.