Ang mamamahayag na nakabase sa Maynila na si Karol Ilagan ay isang regular na customer ng GrabCar, ang ride-hailing app. Sa isa sa kanyang mga biyahe papuntang trabaho noong 2023, nagbayad siya ng surge fee na higit sa ikatlong bahagi ng buong pamasahe. Hindi iyon ang unang pagkakataon, ngunit dahil sumakay siya ng madaling araw sa mabagal na Martes, naisip niyang na-overcharge siya. Nagpadala siya ng feedback sa Grab Support at sinabihang mataas ang demand, kaya mas mataas ang pamasahe.
Hindi kayang hamunin ni Ilagan ang “high demand” na paliwanag dahil ang Grab lang ang may access sa pinagbabatayan na data. Ang kanyang karanasan, kasama ang maraming kuwento sa social media tungkol sa tila matataas na presyo ng Grab, at mga reklamo ng mga driver tungkol sa kanilang lumiliit na take-home pay, ay nagbigay inspirasyon sa pag-uulat na proyektong ito.
Sa suporta mula sa AI Accountability Network ng Pulitzer Center, nakipagtulungan siya sa data specialist na si Federico Acosta Rainis upang subukan kung ang mga claim tungkol sa mga mamahaling sakay ng Grab ay mapapatunayan sa sistematikong paraan. Sa pakikipagtulungan sa 20 mananaliksik, gumugol kami ng higit sa anim na buwang pagsusuri sa algorithm ng Grab at kung paano ito nakakaapekto sa mga consumer at driver.
Sa pamamagitan ng pagkolekta ng data mula sa Grab at sa online fare check tool nito, natuklasan namin na ang mga biyahe para sa hindi bababa sa 10 ruta ay palaging may kasamang surge charge, ang bayad na idinagdag ng Grab upang makakuha ng mas maraming sasakyan sa kalsada. Batay sa app, palaging may mas mataas na demand kaysa sa mga kotseng available halos buong araw.
Ang pag-alam kung palaging may kasamang surge fee ang mga sakay sa GrabCar ang unang bagay lang na gusto naming malaman. Nais din naming suriin kung ang modelo ng surge pricing ng kumpanya ng ride-hailing ay gumagana tulad ng na-advertise – na makakakuha ito ng mas maraming sasakyan sa kalsada. Gayunpaman, ang data na aming nakalap ay nagmungkahi na ang mga customer ay kailangan pa ring magtiis ng mahabang oras ng paghihintay kahit na mataas ang pamasahe. Ginamit namin ang mga oras ng paghihintay bilang proxy para sa kalidad ng serbisyo.
Higit pa sa data, gusto rin naming maunawaan kung paano nagawang dominahin ng Grab ang merkado; kung paano kinokontrol ang mga algorithm; ang pinagbabatayan na mga salik na nagpapahirap sa pag-navigate sa Metro Manila; at, marahil ang pinakamahalaga, kung ano ang kailangang gawin.
Sa mga darating na buwan, ang Philippine Center for Investigative Journalism, PumaPodcast, at Commoner ay maglalathala ng mga kwento tungkol sa kung ano ang aming nahanap, kasama ang aming data, at kung ano ang ibig sabihin ng spatial unfixing ng trabaho para sa mga Filipino at kung paano ito nagsalubong sa mga sistema ng kawalan. Ipapakilala namin sa iyo ang mga driver, rider, at commuter na madalas na nagdurusa sa kawalang-hiyaan ng pagdaraan sa mga lansangan ng lungsod araw-araw. Ipagpapatuloy namin ang pag-update sa pahinang ito upang magbahagi ng higit pa tungkol sa aming proseso.
Paano namin nakolekta ang data
Upang maunawaan kung paano gumagana ang modelo ng surge pricing ng Grab, nakolekta namin ang isang linggong halaga ng impormasyon sa pagpepresyo ng kumpanya para sa 10 ruta sa pamamagitan ng manu-manong pangangalap ng data mula sa app at sa pamamagitan ng online fare check tool nito.
Data ng app: Manu-manong pagkolekta
Bumuo si Ilagan ng pangkat ng 20 mananaliksik na nagtangkang mag-book ng mga sakay para sa 10 ruta sa buong Metro Manila bawat oras mula 6 am hanggang hatinggabi sa pagitan ng Pebrero 14 at Pebrero 20, 2024. Ang huling datos na nakolekta ay noong 00:00 ng Pebrero 21, 2024. shift, dalawang mananaliksik ang itinalaga para sa bawat ruta. Pinili namin ang mga lokasyon ng pick-up at drop-off sa iba’t ibang lungsod sa Metro Manila, kabilang ang mga istasyon ng tren, simbahan, ospital, mall, unibersidad, city hall, at iba pa.
Sinubukan ng mga mananaliksik na i-book ang kanilang nakatalagang ruta sa tuktok ng oras, ibig sabihin, 6 am, 7 am at iba pa, upang tumugma sa awtomatikong pagkolekta ng data na pinangungunahan ni Acosta Rainis (tingnan sa ibaba). Sa bawat pagtatangkang mag-book, kumuha sila ng mga screenshot ng pahina ng pag-book sa app na may mga detalye sa pamasahe para sa isang GrabCar na may apat na upuan, mga tinantyang oras ng pagdating sa destinasyon, at ang iminungkahing ruta.
Pagkatapos ng bawat pagtatangka sa pag-book sa app, kumuha din ang mga mananaliksik ng screenshot sa Google Maps gamit ang rutang iminungkahi ng Google nang awtomatiko. Ito ay upang irehistro ang oras at distansya na inirerekomenda ng Google dahil hindi ipinapakita ng app ang distansya.
Kung ang default na ruta ng Google Maps ay hindi katulad ng sa app, ginaya ng mga mananaliksik ang ruta ng Grab sa Google Maps at kumuha ng pangalawang screenshot. Kinailangan na gayahin muli ang ruta para makuha ang tinantyang distansya ng biyahe, na naging susi sa pagkasira ng pamasahe.
Ang isang dry-run ng prosesong ito ay isinagawa ng mga mananaliksik noong Enero 2024 bago naganap ang aktwal na pangongolekta ng data noong Pebrero 2024. Ilang round ng paglilinis ng data ang isinagawa pagkatapos ng pangongolekta ng data.
Data ng API: Awtomatikong pagkolekta
Samantala, si Acosta Rainis, na nakabase sa Spain, ay nakakuha ng data mula sa fare check application programming interface (API) ng Grab tuwing 15 minuto bawat araw para sa parehong mga ruta sa parehong panahon.
Noong Hunyo 20, 2024, nalaman namin na hindi na available ang online fare check tool sa website ng Grab. Tinanong namin ang kumpanya tungkol dito ngunit hindi pa kami nakakakuha ng tugon.
Ang API ay isang paraan para makipag-usap ang iba’t ibang software system sa isa’t isa. Ito ay isang tagapamagitan na nagtatakda ng mga panuntunan para sa iba’t ibang mga sistema upang makipagpalitan ng impormasyon. Kung susundin namin ang mga patakaran, maaari naming tanungin o “i-query” ang API para sa impormasyong kailangan namin mula sa ibang system at pupunta ito at kukunin ang impormasyon para sa amin.
Para sa aming proyekto, ginamit namin ang Grab’s Farefeed API, na nagbigay-daan sa aming suriin ang mga pamasahe para sa mga biyahe nang real time sa pamamagitan ng pagbibigay ng mga lokasyon ng pagsisimula at pagtatapos. Mayroong pribadong bersyon para sa mga kasosyo ng Grab, ngunit ginamit namin ang pampublikong bersyon na available sa kanilang website. Dahil ang kanilang API ay nagbibigay lamang ng isang pagtatantya ng pamasahe sa isang pagkakataon, nagsulat kami ng script ng Python upang i-automate ang proseso. Humiling kami ng data mula sa API nang walang tigil sa isang buong linggo, nangongolekta ng 672 data point para sa bawat isa sa 10 biyahe.
Sa pangkalahatan, nakakolekta kami ng 1,328 data point mula sa manual na proseso at 6,720 sa pamamagitan ng API. Nagpasya kaming ituloy ang parehong manual at API na pangongolekta ng data upang makadagdag sa built-in na limitasyon mula sa bawat paraan.
Ang data ng API, halimbawa, ay nagpakita lamang ng isang hanay ng mga pagtatantya ng pamasahe, habang ang data ng app ay nagpakita ng nakapirming rate na talagang babayaran ng mga mananaliksik kung sila ay gumawa ng booking. Sa kabilang banda, ang pag-query sa API tuwing 15 minuto sa halip na bawat oras ay nagbigay-daan sa amin na makakuha ng higit pang granularity ng data.
Ang paghahambing sa mga punto ng presyo na ito mula sa dalawang magkahiwalay na mapagkukunan ay nagbigay sa amin ng kumpirmasyon na ang data na aming kinokolekta ay nasa loob ng magkatulad na mga hanay at hindi off the mark. Bukod dito, ang pagkakaroon ng iba’t ibang mga variable ay nagbigay-daan sa amin na pag-aralan ang data nang mas komprehensibo.
Sa anumang kaso, alam namin na ang aming nakolekta ay kumakatawan sa isang maliit na bahagi ng data ng Grab, ngunit nag-aalok ito ng isang sulyap sa panloob na mga gawain ng algorithm nito.
Paano namin sinuri ang data
Nagsimula ang aming pagsusuri sa isang breakdown ng mga pamasahe na ibinibigay ng app gamit ang fare matrix na inaprubahan ng Land Transportation Franchising and Regulatory Board (LTFRB), ang katawan ng gobyerno na kumokontrol sa mga pampublikong transportasyon. Narito ang formula, tulad ng ipinapakita sa isang dokumento mula sa Philippine Competition Commission. Tandaan na ang base fare ngayon ay P45, P15 kada kilometro, at P2 kada minuto.
Nasa ibaba ang isang sample na resibo:
Gamit ang LTFRB fare matrix, maaari nating hatiin ang pamasahe sa itaas tulad ng sumusunod:
Kung walang surge charges, ang biyahe ay magkakaroon ng gastos: P45 plus P198.30 plus P88 = P331.30.
Kasunod ng fare matrix ng LTFRB at formula ng Grab, ang maximum surge charge ay maaari lamang umabot ng hanggang dalawang beses sa kabuuan ng P198.30 at P88 (P286.30*2) o P572.60. Sa halimbawang ito, kinakalkula namin ang surge multiplier gaya ng sumusunod:
Nakukuha namin ang kabuuan ng mga gastos sa distansya at tagal kasama ang inilapat na surge fee.
P198.30 + P88 + P223.70 = P510
Pagkatapos ay hinati namin ang halaga sa itaas (P510) sa kabuuan ng mga gastos sa distansya at tagal upang makuha ang surge multiplier.
P510/P286.30 = 1.781
Ang surge multiplier ay 1.78. Ang maximum na pinapayagang surge rate ay x2.
Ginamit namin ang parehong formula upang makuha ang mga bahagi ng pamasahe ng bawat biyahe na sinubukan naming i-book. Nang masira ang mga pamasahe, napag-isipan natin na palaging may surge rate na inilalapat, ibig sabihin, palaging may natitira pagkatapos ibawas ang P45 na base fare, P15 kada kilometro, at P2 kada minuto na itinakda ng LTFRB.
Ang pagkuha ng surge rate ay nagbigay-daan sa amin na galugarin at ihambing ang iba pang mga variable gaya ng kaugnayan nito sa mga oras ng paghihintay, araw, oras ng araw, ruta, atbp.
Bilang karagdagan sa mga mapaglarawang istatistika, nagpatakbo din kami ng mga pagsusuri sa istatistika upang higit na maunawaan ang aming data. Humingi kami ng tulong sa ilang statistician, kabilang ang mula sa School of Statistics sa Unibersidad ng Pilipinas Diliman at De La Salle University Manila. Bagama’t alam namin na hindi kami nagpapatakbo ng siyentipikong pananaliksik na nangangailangan ng mas matatag na pagsusuri sa istatistika, ginamit namin ang diskarteng ito bilang isang paraan upang masakop ang aming mga base. Ang isang karaniwang pagpuna sa pag-uulat ng mga proyekto tulad ng sa amin ay ang mga natuklasan sa data ay hindi makabuluhan ayon sa istatistika.
Ayon sa istatistikal na resulta, ang data ay hindi nagpakita ng makabuluhang ugnayan sa pagitan ng surge rate at mga oras ng paghihintay. Gayunpaman, ang ilang mga ruta ay nagpakita ng makabuluhang negatibo at positibong ugnayan sa pagitan ng dalawang variable na ito.
Sa talahanayan sa itaas, ang surge na pagpepresyo ay tila pinakamahusay na gumagana sa Ruta 6 (katamtamang negatibo) at pagkatapos ay medyo gumagana sa Mga Ruta 1, 2, 9, 10, 12, at 15 (mababang negatibo). Ang Route 6 ay nasa Valenzuela, isa sa mga hindi gaanong abalang lungsod sa Metro Manila.
Samantala, ang mas mataas na pamasahe ay hindi nauugnay sa mas maikling oras ng paghihintay sa Route 5 at 11. Route 5 pick-up ang Makati City, at Route 11, Taguig. Ito ang mga business district sa Metro Manila.
Kung paano namin iniulat ang kuwento
Para talagang maunawaan ang epekto ng mga serbisyong nakabatay sa algorithm sa mga tao, natutunan namin mula sa mga karanasan ng kahit isang dosenang commuter at 50 driver at rider. Naabot ni Ilagan ang mga indibidwal na madalas gumamit ng GrabCar. Nakapanayam din niya ang mga driver at rider mula sa ilang mga reporting trip kung saan sila madalas nagpapahinga, tulad ng Diokno Boulevard at Macapagal Avenue sa Pasay City. Ang ilan sa mga nakapanayam ay humiling na hindi magpakilala dahil sa takot sa paghihiganti.
Nagbasa kami ng maraming pag-aaral sa transportasyon tungkol sa surge pricing para makatulong na ipaalam ang proseso ng pangongolekta ng data.
Nakapanayam din ni Ilagan ang mga kinatawan mula sa mga organisasyong sumusubaybay sa mga ride-hailing company at digital labor.
Sinubukan ni Ilagan na humingi ng datos at panayam mula sa LTFRB, Consumer Protection Group ng Department of Trade and Industry, Department of Information and Communication Technology (DICT), at PCC. Tanging ang DICT at PCC lamang ang tumugon sa oras ng pag-post.
Nakatuon ang mga kahilingan sa panayam na ito sa tungkulin ng pamahalaan bilang regulator, kung ano ang sinasabi o hindi sinasabi ng batas, patakaran o mga panuntunan at regulasyon tungkol sa mga algorithm, at ang pangingibabaw sa merkado ng Grab noong nakuha nito ang mga operasyon ng Uber sa Pilipinas. – Rappler.com
Ang kwentong ito ay ginawa ng Philippine Center for Investigative Journalism katuwang ang AI Accountability Network ng Pulitzer Center.
Ang kuwento ay iniulat ng kapwa Karol Ilagan ng AI Accountability Network ng Pulitzer Center at dalubhasa sa data na si Federico Acosta Rainis.
Nag-ambag si Jabes Florian Lazaro sa pag-uulat at pananaliksik para sa artikulo.
Ang pangongolekta ng datos ay ginawa nina Angelica Alcantara, Jay-ar Alombro, Donna Clarisse Blacer, Lyjah Tiffany Bonzo, James Kenneth Calzado, Gina de Castro, Maverick de Castro, Dominique Flores, Lois Garcia, Guinevere Latoza, Aya Mance, Faith Maniquis, Karmela Melgarejo , Gabriel Muñoz, Arone Jervin Ocampo, Matthew Raralio, Arriana Santos, at Angelica Ty.
Si Felipe Salvosa II ang pangunahing editor.
Ang mga larawan ay kinuha ni Bernard Testa. Ang mga guhit ay nilikha ni Joseph Luigi Almuena.
Ang mga visualization ng data ay idinisenyo nina Karol Ilagan, Federico Acosta Rainis, at Kuang Keng Kuek Ser.
