Building a Rental Listing Recommender for Shared Fleets

Does a standard e-commerce recommender work when you are renting out e-bikes and cargo scooters? Not really.

Standard retail engines assume infinite inventory and ignore physical geography. If a rider in Seattle looks for a weekend gravel bike, showing them an amazing rig sitting in Miami is useless. Worse, recommending an e-bike that is already reserved for Saturday morning ruins trust immediately.

Marketplace listing recommenders for mobility rentals must resolve three hard constraints simultaneously: physical availability, geographic proximity, and rider compatibility. When platforms like Airbnb or peer-to-peer mobility hubs recommend a listing, they do not just predict whether a user likes the photo. They calculate whether that listing can fulfill the trip.

Why Mobility Rentals Break Collaborative Filtering

Traditional matrix factorization decomposes a sparse user-item interaction matrix into latent vectors. It works well for streaming movies.

For peer-to-peer bike and vehicle rentals, pure collaborative filtering falls apart. First, listing turn-around is fast, and inventory is strictly local. A host might list a custom cargo bike for two months and then pull it. Second, interaction data is hyper-sparse. Most users rent a specialized commuter or road bike only a few times each year.

Turns out, building a production engine requires a multi-stage funnel rather than a single standalone model.

Hard filters remove non-starters before any neural network runs. If a host requires a two-day minimum booking and the rider needs an afternoon rental, discard it. If an e-bike battery sits at fifteen percent and cannot charge before pickup, drop it.

Candidate Retrieval with a Two-Tower PyTorch Architecture

Once hard constraints clear, candidate generation reduces thousands of neighborhood listings to the top hundred.

Two-tower architectures, popularized in large production environments and supported by libraries like TorchRec, handle this retrieval step efficiently. One tower encodes user context. The other tower encodes listing properties.

Because the listing embeddings can be precomputed and stored in a vector index, online inference only requires running the user tower and executing an approximate nearest neighbor search.

import torch
import torch.nn as nn
import torch.nn.functional as F

class MobilityListingTwoTower(nn.Module):
    def __init__(self, num_rider_types, num_categories, embedding_dim=64):
        super().__init__()
        self.rider_type_embed = nn.Embedding(num_rider_types, embedding_dim)
        self.user_dense = nn.Sequential(
            nn.Linear(embedding_dim + 2, 64),
            nn.ReLU(),
            nn.Linear(64, embedding_dim)
        )
        self.category_embed = nn.Embedding(num_categories, embedding_dim)
        self.listing_dense = nn.Sequential(
            nn.Linear(embedding_dim + 3, 64),
            nn.ReLU(),
            nn.Linear(64, embedding_dim)
        )

    def forward(self, rider_cat_id, rider_scalars, item_cat_id, item_scalars):
        u_emb = self.rider_type_embed(rider_cat_id)
        u_vec = torch.cat([u_emb, rider_scalars], dim=-1)
        user_repr = F.normalize(self.user_dense(u_vec), p=2, dim=-1)
        i_emb = self.category_embed(item_cat_id)
        i_vec = torch.cat([i_emb, item_scalars], dim=-1)
        item_repr = F.normalize(self.listing_dense(i_vec), p=2, dim=-1)
        scores = (user_repr * item_repr).sum(dim=-1)
        return scores

Train this model using in-batch negatives with cross-entropy loss. Every listing booked by another rider in the same training batch serves as an implicit negative example for the current user.

Enriching Listings with Text and Hardware Specs

Listing titles and descriptions contain nuances that structured drop-down menus miss.

Hosts frequently describe specific component upgrades, child seat mounts, suspension setups, or included accessories like high-security locks. Running text descriptions through a compact transformer produces a dense vector that captures qualitative listing strengths. Concatenate that vector with mechanical attributes like frame size, wheel dimensions, and rider weight limits.

For electric models, hardware telemetry dictates whether a recommendation is physically viable. Standardized data schemas, such as the current_range_meters field found in GBFS definitions, allow engines to pair vehicle range directly with user route queries.

Thing is, riders lose patience when an application suggests an e-bike showing ten miles of remaining charge for a fifteen-mile commute. Telemetry cannot sit isolated in an operations dashboard; it belongs directly inside your ranking feature pipeline.

Building the query pipeline is rarely elegant because vehicle telemetry comes in messy, with dropped GPS pings and stale battery readings that force you to fall back on sensible defaults. You need fallback logic that downgrades stale vehicles rather than crashing the scoring pass.

Solving the Cold-Start Dilemma for New Listings

New hosts listing their equipment have zero historical bookings, no reviews, and no click-through history. Without special handling, pure machine learning recommenders leave these listings buried at the bottom of search results.

1. Attribute clustering: Assign newly published listings the prior conversion baseline of nearby vehicles with matching frame types and price points.
2. Exploration slate allocation: Reserve five to ten percent of slots on search result pages for unproven inventory to collect click signals quickly.
3. Onboarding responsiveness scoring: Use host response times on initial messages to bootstrap trust metrics before guest reviews accumulate.
4. Price deviation guardrails: Automatically notify hosts if their daily rate sits twenty percent above comparable local listings, preventing wasted discovery impressions.

Location Privacy and Geohash Boundaries

Marketplace recommenders need location data to function, yet handling raw rider and host coordinates introduces serious legal exposure. Regulatory enforcement has targeted services that collect and expose precise location traces without explicit boundaries.

Do not feed exact latitude and longitude floats into your user embedding tables. Instead, index coordinates into spatial hexagons or bounding boxes with a radius between 500 meters and one kilometer.

Spatial quantization prevents bad actors from pinpointing where an expensive custom e-bike is stored overnight. It also keeps embedding dimensions manageable across your candidate database.

Evaluating Offline and Online Performance

Offline metrics determine whether a new model architecture deserves live traffic.

Candidate generation relies heavily on Recall@K to verify that actual booked listings appear within the top 50 or 100 retrieved items. Ranking stages, by contrast, depend on NDCG@K to assess whether the best matches sit at the top of the screen. As established in offline ranking evaluation principles, offline gains do not guarantee business success if model complexity causes p99 latency to spike.

To be honest, a model that lifts offline NDCG by four percent is a liability if inference times jump from 35 milliseconds to 200 milliseconds on a cellular connection.

Monitor these operational signals during live testing:

• Search-to-inquiry conversion rate across specific vehicle categories.
• Host decline rates caused by mismatched rider expectations.
• Trip completion rate without mid-ride battery or maintenance complaints.

Deployment Steps for Fleet and Rental Platforms

Begin by establishing an event stream that logs vehicle page views, inquiries, booking requests, and calendar cancellations.

Next, deploy your vector retrieval index using tools like Milvus or Qdrant. Store listing embeddings alongside basic metadata filters so geographic boundaries and dates resolve directly inside the index query.

Run shadow deployments alongside your existing rule-based search. Compare model predictions against actual user selections for two weeks before directing live user traffic to the neural ranking service. Track response times continuously under peak weekend morning booking loads.