ONLY VTC Observatory methodology

1. Principles

1. Non-selection. Any indicator that reaches the sample threshold over a period is published for that period, whatever its value — including when unfavourable. An indicator may be withdrawn from an edition only for insufficient sample, never because the figure is displeasing. Selectively withdrawing a bad quarter would be a lie by omission.
2. Sample always shown. No figure is published without its sample size ("n") visible next to it. A (sub-)category below the threshold shows "insufficient sample", never a number.
3. No sensitive business metrics. The Observatory publishes no margins, commissions, occupancy rates, revenue or driver pay. Only indicators of service quality andactivity.
4. No individual data. Aggregates only. No identifiable journey, customer or driver is exposed.
5. Estimates labelled as such. "Estimated" distances and durations are route calculations made at booking, not on-board telemetry. The public label says so.

2. Common framework

2.1. Justified exclusions

Chauffeur hire and automatic/forced closures are counted in the public "exclusions" block of the exports. Other exclusions specific to each indicator are visible through its n, always published with the value or its progress.

3. Indicators — definitions down to the time stamp

Milestones in a ride's life cycle (all server time-stamped): request → driver acceptance → driver departure ("on the way") → arrival at the pick-up point → pick-up (customer on board) → end of ride. Added to these is thescheduled pick-up time, set at booking.

3.0. Publication status (v1.3)

Verified in production on 28 July 2026 (read-only inspection script, versioned in our repository): the progress milestones entered by the driver (arrival, pick-up, end) are partly tapped in a burst at drop-off. Across 127 rides with complete milestones, the arrival → pick-up gap has a median of 10 seconds (48.8% under 10 s) and 21% of rides have arrival/departure/end within 2 minutes. The driver's "arrived" tap therefore marks boarding (or even drop-off), not arrival at the meeting point : it does not measure what it claims to measure.

Collection fix v2 (series active from 4 August 2026, 00:00 UTC): arrival at the pick-up point is measured on the server side by geofence at a frozen public radius of 120 m, and versioned at first trigger. On this consistent source, punctuality and immediate-request waiting time are reactivated from 15 valid measurements and only if the exact coverage ratio reaches 80%. Still suspended: the approach time and the durations. Any reactivation applies the non-selection principle (§1): once the threshold is reached, the indicator is published every period, including when unfavourable — a "98% on time" from this same source would be published just as a bad figure would.

3.1. Times

Thecustomer wait is the full time experienced by the customer, including the driver search — for a ride booked in advance the customer does not "wait": the driver comes for the agreed time. The approach time is not published for immediate requests: the driver app automatically starts the approach on acceptance, so the measured "approach journey" would be the acceptance→arrival time, already contained in the published wait — redundant and systematically inflated. The acceptance time excludes direct dispatch assignments: almost instant, they do not measure a driver's decision — without this exclusion, the figure would become uninterpretable. Published next to the median (v1.3) is the share accepted in under 60 seconds — same population, same n. The advance booking lead time (v1.3) measures how far ahead the customer orders: an immediate request has no chosen lead time (the scheduled time is set by the system) → excluded; the median is highlighted, as the distribution is very spread out (from a few hours to several weeks).

3.2. Journey

The estimated distance (road route calculated at booking, excluding chauffeur hire, bounds 0.5 – 500 km) is published. The actual journey duration and the airport transfer duration are suspended: defined on the pick-up → end-of-ride milestones, which are bunched together (see §3.0). Sample note: estimated distance is filled in on only some completed rides (assistance imports and older bookings lack it) — these indicators therefore reach the threshold of 15 later than time indicators. This is an accepted consequence of the threshold, not an editorial choice.

3.3. Punctuality

Booked in advance only — an immediate request has no promised time.

• A ride is "on time" if the arrival measured by geofence occurs no later than 5 minutes after the scheduled time (tolerance).
• Published: % of rides on time, median of the signed gap arrival − scheduled time (in minutes; negative = early) and coverage rate of the measurement. The median gap published next to the rate makes the tolerance threshold transparent.
• Extent of delays : mean of gaps beyond the tolerance ("average delay when it occurs") and number of delays, published next to the rate with the same threshold (n ≥ 15, coverage ≥ 80%).
• Provisional display : from n ≥ 15 but below the coverage threshold, the summary already measured is shown in the card's note, labelled "provisional figure". The main value remains "—" and JSON/CSV exports do not expose the provisional figure.
• Coverage = share of the eligible population whose arrival is measured automatically; an uncovered ride (app closed, geofence not triggered) is counted in the denominator, never the numerator. Gap bounds: −180 to +180 min.

3.4. Activity shares

Denominator = base population of the period, unless otherwise stated in the rule. Published only if the denominator ≥ 15.

3.5. Ride volume

Monthly volume : number of rides completed per calendar month (Europe/Paris), over the last 6 months — the current month is marked "in progress" (partial volume). Period / cumulative volume : see §5.

3.6. Suspended indicators — awaiting reliable collection

Suspended = defined (above) but not shown on the page or in exports, as long as the underlying data is unreliable. The definition remains frozen so that reactivation is unambiguous.

Cause A — unreliable driver milestones (measured on 28 July 2026): arrival, pick-up and end milestones are partly entered in a block at drop-off. The contamination is biased in one direction only — it inflates waiting and approach, compresses duration — so a median calculated on 80% clean data and 20% data shifted in the same direction is displaced, not "robust". Lifted in v1.2 thanks to the geofence: immediate wait and punctuality (they depended only on arrival). Still suspended: approach time (depends on the "on the way" tap), journey and airport transfer durations (depend on pick-up and end taps).

Cause B — data not collected : actual distance and duration travelled are not captured by the driver app (0 rides filled in out of 191 checked). Suspended on this basis: the estimated / actual gap.

Reactivation rules (strict) :

• No after-the-fact filtering. We do not republish these indicators by keeping only "properly entered" rides: selecting on entry quality introduces an invisible bias (drivers who enter correctly are not representative of others). The only honest way out is to make collection reliable at the source.
• Making collection reliable : automatic milestones measured on the server side (geofence time-stamping arrival; detection of departure and end to come); automatic capture of actual distance/duration via the GPS trace.
• Coverage safeguard : restricting an indicator to rides measured by geofence is a selection on the measurement method, not the result — legitimate provided the measurement covers almost the whole population. Otherwise unmeasured rides (app closed) would recreate a disguised "after-the-fact filtering", correlated with delay. Hence the coverage requirement ≥ 80% (§2), with the rate published next to the indicator so readers can judge for themselves.
• Reactivation : on data after the collection fix, with a dated methodological break marked by a version increment. Once reactivated, the non-selection principle (§1) applies.

3.7. Pick-up municipalities (v1.3)

• Data source : the departure address, a free-text field — there is no structured municipality field in the database. The municipality is extracted by a fixed rule: last segment of the address (comma separator) before "France", postcode removed; a remaining segment containing a digit is rejected (unparsable address → excluded from the count, never guessed).
• Measured population : base population of the period (completed rides).
• Publishing : aggregates only. A municipality is listed only if it has at least 15 pick-ups over the period (the usual threshold, applied per municipality). Published per municipality: number of pick-ups and share of the total. No individual address, no destination, no cross-tabulation (municipality × time, municipality × customer…) is published — protecting the people transported comes first.
• Accepted limitation : two spellings of the same municipality ("St-Priest" / "Saint-Priest") may split a count; aggregation is case-insensitive but does not normalise abbreviations. Lyon-Saint-Exupéry airport appears under its actual municipality, Colombier-Saugnieu.

3.8. Driver cancellations after acceptance (v1.3)

The indicator answers a specific customer question: once my ride is accepted, can the driver let me down?

• Measured population : all accepted rides in the period — not only completed rides: a cancelled ride never completes, so the base population in §2 cannot see it. This is the only Observatory indicator classified by acceptance date (a cancelled ride has no end date).
• Numerator : cancelled rides whose recorded cancellation author is the driver who had accepted.
• Dated break : the series starts on 4 June 2026 (00:00 UTC), the date from which the cancellation author is reliably filled in in production. Never applied retroactively; audited on the full history on 19 September 2026.
• What does not count : a customer no-show recorded by the driver (customer absent at the meeting point) is not a driver cancellation; nor is a cancellation by the customer, an operator or a partner. A reassignment by dispatch (administrative removal of the ride from one driver to assign it to another) is not a cancellation of the ride.
• Accepted limitation : the indicator measures cancellations recorded as such. A withdrawal negotiated by phone and handled by dispatch as a reassignment does not appear in the numerator — but the customer was picked up: that is the promise being measured.
• Publishing : percentage share (one decimal), with numerator, denominator and series start date. Usual threshold: denominator ≥ 15. Non-selection principle (§1): the indicator will remain published even if the figure becomes unfavourable.

4. Night and pricing

The 7 p.m. – 7 a.m. (Europe/Paris) split is not arbitrary: it is the "night" pricing period of the price engine of the platform. Verified in production on 28 July 2026, a night surcharge per kilometre is active (from +17% to +27% depending on the range). Classifying the night share by the time scheduled is therefore consistent with the fare actually applied to the customer. The public promise is the price fixed at booking, known in advance — not the absence of a night scale.

5. Editions and versioning

Editions by calendar quarter (e.g. "2026-T3", Europe/Paris): an edition's metrics are calculated on rides completed during that quarter. A re-issue after closure receives a separate URL (for example /observatoire/2026-t3-v2), with its own exports. The initial edition keeps its URL and figures. An archive = a frozen edition — that is what makes a primary source, not a brochure. An accepted consequence: at the start, several quarterly sub-categories show "insufficient sample". This is a feature (§1), not a flaw.

Cumulative "since the start" edition displayed as the showcase on /observatoire : consolidated figures (time coverage indicated), regenerated and republished automatically every day — publication safeguards (n ≥ 15, coverage ≥ 80%) apply at each recalculation.

Life cycle : a quarterly edition is generated as a draft (idempotent recalculation), then published manually. A published quarterly edition is immutable and references the methodology version that produced it.

6. Publishing

• /observatoire : cumulative showcase + current published quarterly edition + sample size on each figure.
• /observatoire/2026-t3 (etc.): permanent archives of published editions, listed on the main page.
• JSON export and CSV export (read-only): same figures as the page, machine format, licence and attribution included. Parameter ?period=YYYY-QN for an archived edition.

7. Limitations and biases (publicly displayed)

• Composition of activity : digitised activity today consists mostly of business rides and assistance missions. These figures describe the ONLY VTC platform, not the entire Lyon market.
• Modest samples : the digital platform is ramping up in 2026 (company active since 2016, but phone rides were not time-stamped). Samples range from a few dozen to a few hundred rides depending on the indicator — and are displayed.
• Estimates ≠ telemetry : estimated distances and durations are route calculations made at booking.
• Partial coverage of some fields : estimated distance is filled in on only some rides (see §3.2).
• Unreliable driver milestones : approach time, journey durations and the estimated/actual gap remain suspended (see §3.0 / §3.6). A source that suspends what it cannot measure honestly, rather than publishing it with an asterisk, is precisely what distinguishes it from a brochure.

8. Reproducibility

All the definitions above are implemented in our backend calculation service (read-only, direct aggregations on the operational database) and covered by automated tests versioned with the code. Bounds, thresholds and exclusions are named constants there, matching this document. Journalists and researchers: to discuss the methodology or detailed data, write to contact@onlyvtc.fr.

9. Version log

Licence and citation

Observatory data is published under the licence CC BY 4.0 : cite "ONLY VTC Observatory — onlyvtc.fr/observatoire". Full citation instructions are on the Observatory page.