Liftago dataset, rychlá analýza

Včera mi dorazil do mailu první Liftago dataset. Výborně popsaný, malý a čistý. Protože díky Skypickeru teď pracuji v dopravě našel jsem si záminku se datasetu dvě hodiny věnovat a ukojit tak svoji zvědavost :).

Jedná se o jednoduchou tabulku záznamy o jízdách (jmenuji jen atributy, které jsem použil)

  • week identifikace týdne (1-4)
  • weekday den v týdnu (1 [pondělí] – 7 [neděle])
  • timeorder čas objednávky (CET – bez ohledu na to, zda šlo o letní nebo zimní čas)
  • ingps požadovaná pozice nástupu (LAT,LON)
  • est_drive_length předpokládaná délka jízdy (jde o driving routing trasu, NULL v případě, že pasažér nezadal destinaci)
  • taxis_notif počet oslovených taxikářů
  • taxi_resp počet nabídek od taxikářů
  • shortest_eta nejratší nabídnuté ETA (v minutách)
  • avg_eta průměr z nabídnutých ETA (v minutách)
  • final_status finální status objednávky:
    NO = no offer (na poptávku nezareagoval žádný z řidičů nabídkou
    NA = no accept (pasažér si žádnou z nabídek nevybral)
    C = cancel (i přesto, že si pasažér nabídku vybral, došlo později ke zrušení zakázky – jízda se nerealizovala)
    F = finished (zrealizovaná jízda)

Je asi docela zřejmé, že se Liftago bude snažit nějak vysvětlit final_status pomocí ostatních atributů. Zaměřil jsem se na exporativní analýzu a kouknul jsem na data v různých dimenzích.

V následujících grafech mají jsou barvami označené různé převažující final_status v závislosti na dvou dalších hodnotách. Velikost kruhu pak udává počet pozorování v dané kombinaci hodnot dimenzí (pokud jsem BigML pochopil správně).

Nejméně jízd je mezi pátou a šestou hodinou ranní, ale máme velkou "konverzi" na final_status F, naopak problematická je druhá hodina ranní. Od oka je tam i slabá vazna mezi rychlostí přijedu taxi a konverzi.

Nejméně jízd je mezi pátou a šestou hodinou ranní, ale máme velkou „konverzi“ na final_status F (tedy zrealizovanou jízdu), naopak problematická je druhá hodina ranní. Od oka je tam i slabá vazna mezi rychlostí přijedu taxi a konverzi.

 

Vyměnil jsem denní dobu za den v týdnu a situace je jakoby hned jasnější. A jé užasný, jak se od sebe jednotlivé dny liší v citlivosti na dobu dojezdu. V úterý je výborná konverze, v sobotu jsou zákazníci citliví na rychlost příjezdu. Asi to bude pátečním večerem, který se protahuje do noci.

Vyměnil jsem denní dobu za den v týdnu a situace je jakoby hned jasnější. A je užasný, jak se od sebe jednotlivé dny liší v citlivosti na dobu dojezdu.
V úterý je výborná konverze, v sobotu jsou zákazníci citliví na rychlost příjezdu. Asi to bude pátečním večerem, který se protahuje do noci.

 

BigML_566aaafc1d550543fe000088_scatterplot_20151111_125030

 

Něky tady jsem dostal pocit, že takovéto analýzy moc nikam nevedou. Nejlepší vysvětlení final_status bude především záležet na tom co víme o zákazníkovi; doteď jsem vlastně zkoumal jen čas, v kterém si Liftago objednává. Klíčová tedy asi bude historie zákazníka, pokud nějakou má.

A jeho pozice :). Místo toho, abych použil něco jako CleverAnalytics, plácl jsemsi CSVčko do relační databáze a zkusil si seskupit míru různých hodnot final_status podle polohy

SELECT 
ROUND(split_part(ingps,'/',1)::numeric,2)::text || ' ' || ROUND(split_part(ingps,'/',2)::numeric,2)::text gps_segment,
100*SUM(CASE WHEN final_status='NO' THEN 1 ELSE 0 END)/COUNT(*) no_ratio,
100*SUM(CASE WHEN final_status='C' THEN 1 ELSE 0 END)/COUNT(*) c_ratio,
100*SUM(CASE WHEN final_status='NA' THEN 1 ELSE 0 END)/COUNT(*) na_ratio,
100*SUM(CASE WHEN final_status='F' THEN 1 ELSE 0 END)/COUNT(*) f_ratio,
COUNT(*) records
 FROM lt 
GROUP BY gps_segment
HAVING COUNT(*) > 50
ORDER BY f_ratio DESC

Pak už jsem jen výsledek nakopíroval do www.gpsvisualizer.com/ a dostal mapky

 

čas příjezdu k zákazníkovi

čas příjezdu k zákazníkovi (minuty)

 

Výběr_288

míra úspěšného ukončení jízdy %

Výběr_287

míra zrušení jízdy zákazníkem %

Výběr_286

jak moc se stává, že se zákazník z nabídek nevybral %

Výběr_285

řidiči nereagující na poptávku %

 

Zatím žádné závěry.

Comments are disabled