Multi-CDN steering earlier in this series established the architecture; this is the article about the decision itself. When a resolver asks where a user should go, the answer can come from geography, from measurement, or from economics, and the differences are visible in your percentiles.
Geographic steering, the honest baseline
Map the resolver (or the client subnet, where ECS provides it) to a location, return the nearest configured endpoint. It is simple, predictable, debuggable, and wrong in every case where network distance diverges from map distance: peering disputes make neighbors distant, undersea routes make distant POPs near, and mobile carriers backhaul traffic to interconnection points far from users. Geography is where steering starts, never where good steering ends.
Measurement-driven steering
Feed the decision with data: synthetic probes per region per endpoint, or better, RUM measurements from real clients (community measurement pools and your own beacons), aggregated into per-network, per-endpoint performance tables. The steering answer becomes whoever is actually fastest for this user population right now, which automatically absorbs peering changes, regional incidents and provider drift. The engineering caveats: measurement freshness versus flap-damping (react in minutes, not milliseconds), and coverage honesty for long-tail networks where data is thin.
The ECS nuance deserves its paragraph because it moves real percentiles: steering sees the resolver by default, not the user, and public resolvers concentrate huge populations behind few addresses, so decisions optimize for the resolver’s location unless EDNS Client Subnet forwards a user prefix. ECS support varies across resolvers (privacy trade-offs keep it partial by design), which means your steering quality differs by your users’ resolver choices, a cohort split worth adding to RUM attribution. Estates with heavy public-resolver populations sometimes find their worst steering decisions correlate perfectly with one resolver’s catchment, an insight that turns a mysterious regional slowness into a solvable routing-policy ticket.
The full policy stack
Production steering layers more inputs: endpoint health (fail fast on probe failure), load and capacity (shed from hot regions before they degrade), and cost (route the indifferent middle of the distribution toward cheaper delivery, our commercial articles’ leverage made algorithmic). Mature platforms express this as ordered policy: health gates, then performance bands, then cost tiebreaks, with stickiness controls so users do not oscillate between near-equal endpoints and fragment caches.
In practice
Audit what your steering actually uses: pure geo is common and quietly expensive in exactly the geographies where networks are messiest. Instrument decision outcomes (which endpoint, why) into your unified logs, verify with RUM that steered users beat the counterfactual, and revisit the policy quarterly with the cross-provider report, because steering policy is where all this series’ measurement infrastructure finally cashes out as routed traffic.
Steering-policy audits are a standing module in multi-CDN engagements: inputs, outcomes, counterfactual RUM. The gap is the report.