Graph Theory for Data Analysts: What You Actually Need to Know

You do not need a CS degree to use network analysis on operational data. For the Mobi Vancouver bike-share work I modeled 264 stations as nodes and trips as weighted edges, then asked which stations are load-bearing and which are quietly expensive. The published case study uses the September 2024 extract — 150K+ trips through an R ETL into igraph. The three ideas that actually changed the recommendation were not textbook-complete graph theory. They were clustering, centrality, and degree ratio.

Clustering first: invert edge weights so frequent routes read as close, then let Ward's method partition the network. Four communities fell out (84, 80, 74, and 26 stations). That is an operations map — where cohesion is high, where it is weak — not a pretty dendrogram for its own sake.

Centrality second, and more than one lens. Betweenness (mean 239.2) named the bridges traffic must flow through — stations 222, 76, and 223 in this extract. Eigenvector pointed at hubs wired to other busy nodes (209, 105, 103). Closeness (mean 0.566) ranked reachability. Together they are a priority list: keep the bridges stocked, do not treat every dot on the map as equal.

Degree ratio third. No sink nodes — every station sent and received — but Node 982 absorbed far more than it dispatched (ratio 3.5). That is the station you send the truck to before the dock fills. Dashboards that only show current bike counts never say why. The graph does.

Those three are enough to go from "the network feels uneven" to a zone-based rebalancing plan. The rest of the theory can wait until the operator asks a question the graph has not already answered.