Offer-to-Order vs Look-to-Book: Measuring Airline Shopping Compute Efficiency

The measurement problem

One traveller search can generate several shopping requests, dozens of evaluated itinerary candidates and many returned Offers, yet produce no confirmed Order. When an airline counts all these as equivalent transactions, a dashboard can appear healthy while conversion falls and computing costs climb. This guide separates Look-to-Book (LTB), Offer-to-Order and CPU-to-Order, then explains how to build a reliable measurement contract around them.

Standards boundary: IATA's October 2025 Look-to-Book publication explicitly introduces Offer-to-Order and CPU-to-Order as emerging metrics and discusses nine practical propositions. The exact formulas, instrumentation, examples and controls below are independent practitioner proposals, not prescribed IATA requirements. The IATA paper describes its work as a starting point for ecosystem discussion rather than a mandatory standard.

Why Look-to-Book needs a precise denominator

Look-to-Book commonly compares shopping activity with completed bookings, but a look can mean a human search, an API request, a seller's retry, a calendar query or a candidate evaluated internally. A metasearch integration may amplify one customer action into many upstream calls, while a seller with a cache may satisfy several actions without contacting the airline. Both channels could serve comparable demand and report very different LTB ratios.

Define the request boundary before comparing sellers or releases. We recommend counting eligible airline shopping requests separately from unique shopper intents, and distinguishing transport retries from genuine new searches. Keep zero-result requests in the traffic denominator: they still consume resources. Exclude synthetic tests from commercial conversion but include their load in infrastructure capacity reporting. An apparently lower LTB is not automatically a better customer outcome.

Three complementary metrics

These are deliberately proposed operational definitions. A returned Offer identifier and a visually distinct customer choice are not necessarily the same thing. An OrderCreate request is not a confirmed Order. For CPU-to-Order, state whether the measure includes search orchestration, price computation, cache lookup, background precomputation and unsuccessful requests. Publish the unit, cohort and exclusions alongside every chart, or the numbers cannot be compared responsibly.

Instrument the funnel, not just the endpoint

Use an event chain of shopper intent → shopping request → candidate evaluation → Offer returned → OfferPrice confirmation → OrderCreate attempt → confirmed Order. Some journeys skip or repeat steps, and implementation varies by message version. IATA's NDC guidance describes the exchange of Offers and Orders, while the AIDM provides shared domain vocabulary; neither dictates a particular telemetry database or trace schema.

Carry a correlation identifier across boundaries without exposing personal data. Record the request class, channel, point of sale, market, itinerary complexity, cache result, Offer count, response latency, CPU attribution and terminal commercial outcome. Each event should have a unique ID for deduplication. Use event timestamps as well as ingestion timestamps so delayed confirmations do not disappear from the reporting cohort. A failed checkout or payment authorisation should not count as an Order until the outcome is reconciled.

A minimal event contract

{
  "eventType": "OfferReturned",
  "eventId": "evt-1283",
  "traceId": "trace-55d",
  "shoppingIntentId": "intent-811",
  "shoppingRequestId": "req-223",
  "offerId": "offer-72",
  "sellerSegment": "metasearch",
  "cacheResult": "MISS",
  "computeCpuMs": 18.4,
  "eligibleForCommercialRatio": true,
  "occurredAt": "2026-10-24T09:00:00Z"
}

This is an illustrative analytics event, not an IATA XML message. It intentionally excludes passenger names and contact details. Keep the mapping between internal events and relevant AirShopping, OfferPrice and Order messages versioned. In a multi-system architecture, missing trace links are a data-quality defect rather than evidence that a booking did not occur. Reconcile confirmed Orders against the authoritative order store before publishing conversion totals.

A worked example that changes the decision

Consider a hypothetical day with 1,200,000 eligible shopping requests, 2,400,000 customer-visible Offer alternatives, 1,000 confirmed Orders and 90,000 attributed CPU-seconds. The proposed ratios are 1,200:1 LTB, 2,400:1 Offer-to-Order and 90 CPU-seconds per Order. These are demonstration figures, not industry benchmarks.

Now suppose a cache change reduces shopping requests by 30% but stale results cause confirmed Orders to fall by 20%. Requests decline to 840,000 and Orders to 800. LTB improves to 1,050:1, even though the business loses 200 Orders. Optimising only LTB would reward a harmful release. A different change might increase CPU per request yet improve relevance enough to lower CPU-to-Order. Always pair efficiency ratios with absolute Orders, successful price confirmations, customer errors and revenue outcomes.

CPU attribution without false precision

CPU-to-Order measures compute, not cloud spend. Container runtime, memory reservation, storage, network transfer and external service fees can be material even when measured CPU-seconds fall. Use observed CPU time where available; otherwise document the allocation method and show an unallocated bucket. Avoid silently attributing zero cost to cached responses, which still require retrieval, network traffic and freshness checks.

Precomputed shopping results present a special accounting choice. You can charge generation cost to the original computation, amortise it over responses served, or report precomputation separately. None is universally correct. The crucial requirement is consistency and an audit trail. Maintain a parallel, reconciled fully loaded technology cost per confirmed Order metric based on actual invoices and service usage. It answers a financial question that CPU-to-Order alone cannot answer.

Segment to avoid misleading comparisons

Break down the funnel by direct and indirect channel, seller, market, itinerary complexity, journey type, passenger count, cache hit or miss, and API version. A connecting itinerary can require more evaluation than a simple one-way journey. A high exploratory search ratio may reflect genuine customer comparison rather than abusive polling. Conversely, a retry storm can produce an LTB spike without any increase in shopper demand.

Compare matched cohorts and preserve sample sizes. Use daily anomaly detection alongside seven-day and 28-day trends. Annotate changes in campaign traffic, schedule, inventory, seller integration and pricing configuration. A denominator that shifts because one seller changes its batching behaviour should not be described as a conversion improvement. Separate technical failures, zero availability and customer abandonment instead of grouping every unsuccessful search under one generic error code.

Caching, throttling and fairness guardrails

Traffic governance should protect host capacity without accidentally suppressing valuable checkout journeys. Distinguish idempotent retries from new searches, reserve appropriate capacity for price confirmation and ambiguous OrderCreate recovery, and apply documented seller budgets where contracts permit. A cached Offer is not proof of current bookability. Honour the applicable Offer validity, price and inventory guarantee semantics before checkout rather than assuming a cached response is safe to purchase.

Test changes in controlled cohorts. Observe p95 and p99 latency, OfferPrice rejection, stale-Offer errors, confirmed Orders, CPU-to-Order and the share of customers who receive a valid alternative after repricing. A reduced request count is not a release criterion by itself. Escalate changes that lower technical cost while increasing customer-facing failure or materially reducing completed Orders.

Alerts and ownership

Calibrate alerts against historical segment baselines rather than borrowing a generic threshold. Give each alert a named engineering and commercial owner, plus a playbook that identifies the safe rollback path. Avoid automatically blocking a seller merely because a ratio moves: legitimate demand, failed inventory and retry behaviour require different remedies. Track the completeness of the measurement system itself so missing events cannot masquerade as lower CPU consumption.

A four-week implementation sequence

Week one: agree counting rules and exclusions with product, engineering and finance. Map the existing shopping, pricing and order interactions. Week two: propagate trace IDs and reconcile confirmed Orders, including timeouts and late results. Week three: attribute CPU usage with a coverage indicator and build seller and itinerary segmentation. Week four: run a guarded cache or traffic-policy experiment and compare all three ratios with absolute Orders, customer errors and cost.

Version the counting contract whenever a schema mapping, Offer counting rule or attribution window changes. Display incomplete coverage prominently. A metric without its denominator, date window and cohort definition is not suitable for a release decision. The best north star is not the lowest search volume: it is useful, bookable Offers and reliable Orders at a sustainable marginal cost.

Original references and related reading

1. IATA, Look-to-Book: managing search volumes while creating customer-centric Offers, 7 October 2025. Source for the named metric families and ecosystem propositions.
2. IATA, Distribution with Offers & Orders (NDC). Source for NDC's role in exchanging Offers and Orders.
3. IATA Developer Portal, AIDM. Source for common industry vocabulary and logical data relationships.
4. IATA, Dynamic Offers. Context for offer creation and shopping relevance.

Continue with Offer observability, offer-funnel data quality and the Look-to-Book compute and cache calculator.

Editorial note: Independent educational analysis. Hypothetical examples, formulas, telemetry contracts and suggested controls are practitioner recommendations, not mandatory IATA standards or observed production benchmarks.