Entendendo a Demanda Não Atendida
A demanda não atendida é um dos vazamentos silenciosos de receita na mobilidade compartilhada: um passageiro abre o app, procura um veículo e não há nenhum por perto. Ele fecha o app e não faz a corrida. Você nunca vê a transação perdida na sua tabela de corridas porque a corrida nunca aconteceu — mas a demanda foi real, e o AI Ops agora a captura.
O que conta como evento de demanda não atendida
Toda vez que um passageiro abre o app Levy e a lista de veículos da zona retorna zero veículos disponíveis em até 500 metros do local da busca, o AI Ops registra um evento na tabela unmet_demand_events. O evento contém:
| Campo | Descrição |
|---|---|
h3_index | O hex H3 em que a busca ocorreu |
occurred_at | Carimbo de tempo da busca |
available_vehicles_500m | Contagem de veículos em 500 m (sempre 0 para eventos não atendidos) |
search_lat / search_lng | Onde o passageiro estava pesquisando |
customer_uuid | O passageiro, quando autenticado |
A instrumentação vive em POST /api/mobile/app-session-search — o app móvel do passageiro chama esse endpoint a cada abertura de mapa e a cada consulta da lista de veículos.
Por que capturamos
Duas razões:
- Quantificar a receita perdida. Se você sabe que um hex tem 30 eventos não atendidos por dia e sua tarifa média é de R$ 4, são cerca de R$ 120 de receita potencial diária somente daquele hex. O recomendador de rebalanceamento usa isso para dolarizar suas sugestões.
- Corrigir a previsão para censura. As corridas históricas são um sinal censurado de demanda — você só vê as corridas que ocorreram, não as que ocorreriam se houvesse veículo. O modelo de previsão usa eventos de demanda não atendida para reconstruir a demanda real, evitando subestimar hexes cronicamente subabastecidos.
A camada de heatmap de demanda não atendida
Em Dashboard > Analytics > Heat Maps, ative a camada Unmet demand. Os hexes são coloridos pela contagem de eventos não atendidos na janela visível (padrão: últimas 24 horas).
Hexes em vermelho intenso são onde você está perdendo mais receita. São os destinos de maior prioridade para o recomendador de rebalanceamento — mover veículos para lá tem o maior ganho projetado.
Clique em qualquer hex para ver:
- Contagem de eventos não atendidos na janela
- Distribuição por hora do dia (quando os passageiros pesquisam)
- Previsão para as próximas 4 horas (demanda prevista no mesmo hex)
Comparando demanda não atendida com a previsão
Demanda não atendida é histórico observado. Previsão é predição. Elas são complementares:
- Alto não atendido, alta previsão — subabastecimento crônico. O recomendador prioriza isso primeiro.
- Alto não atendido, baixa previsão — pico curto (ex.: evento pontual). O recomendador trata isso com cautela porque o horizonte de previsão não a prevê.
- Baixo não atendido, alta previsão — você tem acompanhado o ritmo. A previsão diz para continuar assim.
- Baixo não atendido, baixa previsão — hex tranquilo, deixe quieto.
Retenção
Os eventos de demanda não atendida ficam em uma hypertable do TimescaleDB com política de retenção de 30 dias. Linhas mais antigas são descartadas automaticamente. Os agregados são incorporados ao pipeline de features de previsão antes do descarte, então o modelo retém o sinal mesmo após os eventos individuais serem apagados.
Privacidade
As coordenadas de busca (search_lat / search_lng) são dados pessoais. Estão cobertas pelos Termos de Uso vigentes do passageiro e armazenadas somente pela janela de retenção de 30 dias. Nunca são incluídas em feeds MDS ou em qualquer exportação para terceiros.
Relacionado
- Mapa de previsão de demanda — guia completo da página de heat maps.
- Recomendações de rebalanceamento — como a demanda não atendida vira um movimento sugerido.