Answer first: size from event-level rentals and returns grouped into local 15-minute intervals, then test the station against the most demanding borrow and return windows. Record ready inventory, working empty slots, failed attempts, device faults, and response time alongside completed orders. Daily averages and total venue traffic are context only; they cannot reveal the short interval in which a station becomes empty or full.
Peak-hour demand is often discussed too loosely. A buyer may hear that a venue serves 2,000 visitors per day or that a station averages eight rentals. Neither figure shows whether six users arrive at once, whether returns cluster after closing, or whether an unavailable bay turns a manageable interval into a support incident. Capacity is consumed in time, so the dataset must preserve time.
Use consistent timestamps. RFC 3339 defines an unambiguous Internet date-time representation with UTC offsets [1]. For a multi-country SaaS, store the source event time, UTC representation, station time zone, and ingestion time. This prevents a lunch peak in Singapore from appearing in the same reporting bucket as a lunch peak in London and makes daylight-saving changes auditable.
Build an event-level source table
The source table should include more than paid orders. Capture:
- scan or rental-page start;
- payment initiated, succeeded, failed, or abandoned;
- dispense command and device acknowledgement;
- power bank identity and slot identity;
- return insertion, lock, recognition, and order closure;
- station online/offline and slot-health changes;
- ready-to-rent count and working empty-slot count;
- alert, acknowledgement, dispatch, arrival, and recovery;
- venue, station, local timestamp, UTC offset, and software version.
Use pseudonymous or minimized identifiers in analytics and apply the target market's privacy requirements. The purpose is operational measurement, not collecting unnecessary personal data.
GBFS is designed to provide the current status of shared-mobility systems and distinguishes station availability states [2]. It does not specify shared-power-bank analytics, but it demonstrates the value of machine-readable station status. For sizing, retain historical snapshots or reconstruct state from events so the team can see exactly when ready inventory or return capacity reached a threshold.
Why 15-minute intervals are useful
A 15-minute interval is short enough to expose many meal, class, train, checkout, and event waves while remaining understandable to operations teams. It is not a mandatory universal window. A stadium exit may require five-minute analysis; a small hotel may be stable at thirty minutes. Start with fifteen, then inspect whether the pattern is being hidden or fragmented.
For each interval calculate:
- completed rentals and completed returns;
- net flow: returns minus rentals;
- minimum ready-to-rent units;
- minimum working empty slots;
- scans or payment attempts when no unit was available;
- return attempts when no working slot was available;
- downtime and disabled-slot minutes;
- minutes below warning and critical thresholds.
Keep borrow and return peaks separate. The highest rental interval may occur at 19:00, while the strongest return interval occurs at 22:30. Sizing only for the first wave can create a full station later.
Use percentiles without hiding extremes
The single busiest interval may be a data error or a once-a-year event, while the average may be too forgiving. Review a distribution: median, 90th or 95th percentile, maximum, and the number of intervals that breach the proposed buffer. Mark special events, holidays, promotions, weather disruptions, and outages instead of silently mixing them into normal operations.
Transit-capacity guidance distinguishes actual demand from several forms of capacity [3]. The practical implication is to compare the measured interval with usable station capacity, not nominal slots. Discount disabled bays, charging units, protected return positions, and inventory that the software cannot safely rent.
Estimate unmet demand
Completed transactions are censored by availability. If no power bank is ready, the absence of a rental does not prove the absence of demand. Bike-sharing research notes that realized actions may not reveal users' primary choices when a station cannot serve them [4]. For shared power banks, use page starts, scans, failed dispenses, empty-station views, support contacts, and nearby-station redirections as indicators. Do not turn these signals into exact lost revenue without a validated attribution model.
Similarly, a full station can hide return demand. Record rejected insertions, repeated lock attempts, customers opening a nearby-station map, and manual order corrections. Distinguish full capacity from a faulty slot or stale status.
Convert the peak into a capacity test
Replay the busiest representative sequence against candidate station sizes. Begin with the planned number of ready units and protected empty slots. Apply rentals, returns, charging eligibility, faults, and the realistic service response. The candidate fails when ready units or working empty slots reach the unacceptable level before recovery.
Then compare alternatives: a larger station, a second station on another path, a different initial load, an earlier restocking visit, or faster alerts. Capacity is one control among several. An extra cabinet may be unnecessary if a route change can rebalance inventory before the peak; a route change may be impossible if event access is restricted.
Define a publishable decision record
For each venue, retain the observation period, excluded data, time zone, interval size, candidate models, initial inventory mix, peak sequence, alert thresholds, response assumption, and decision date. State when the model will be reviewed. This turns “the venue felt busy” into an auditable choice and helps prevent a pilot result from being copied into a different venue without context.
A reliable sizing process is deliberately modest. It does not claim perfect forecasting. It uses consistent timestamps, captures both successful and failed journeys, separates borrow and return capacity, and tests a candidate against observed peaks. That is enough to make a better first decision and a clearer upgrade rule.
Evidence date and limits
Evidence reviewed through 2026-08-09. The following limits are part of this buyer guide:
- Fifteen minutes is an analytical recommendation, not a standard mandated by the sources.
- Transit and bike-sharing evidence supports measurement concepts but does not forecast shared-power-bank demand.
- Analytics must follow target-market privacy, retention, payment, and consumer rules. Verify target-country requirements before publication and deployment.
- No demand, conversion, revenue, or required sample-size guarantee is claimed.
Related CoreCharge guides
- power bank rental software features
- shared power bank rental software integration checklist
- choose shared power bank stations from china
- products 12 slot.html
- Previous guide in this capacity cluster
- Next guide in this capacity cluster
Sources
1. IETF / RFC Editor - RFC 3339: Date and Time on the Internet: Timestamps (accessed 2026-08-09). an unambiguous Internet timestamp format with UTC offsets for interoperable event records. 2. MobilityData - General Bikeshare Feed Specification (GBFS) (accessed 2026-08-09). current shared-mobility status can be represented in uniform machine-readable feeds with distinct availability states. 3. U.S. Federal Transit Administration - Characteristics of Bus Rapid Transit for Decision-Making (accessed 2026-08-09). actual demand is distinct from maximum, design, and operated capacity; used as a planning analogy. 4. Benjamin Legros - Dynamic Repositioning Strategy in a Bike-Sharing System: How to Prioritize and How to Rebalance a Bike Station (accessed 2026-08-09). observed actions may not reveal first choices when stations are unavailable, and stochastic flow creates empty/full risks.