Ketergantungan Data Tersembunyi yang Terungkap Saat Migrasi Peta

#Apa yang pertama kali rusak saat sebuah peta diganti?

Bukan petanya. Saat Indonesia pindah ke GrabMaps pada 2022, sebagai negara terakhir Grab yang beralih, banyak keluhan awal bukan soal jalan yang salah atau mal yang hilang. Keluhannya soal tempat yang sudah disimpan user: rumah, kantor, alamat pelanggan tetap. Peta baru sudah aktif, dan sebagian tempat tersimpan itu tidak lagi menunjuk ke mana pun.

Itulah pelajaran artikel ini. Peta bukan satu dataset yang bisa ditukar begitu saja. Semua yang merujuk ke peta itu ikut harus dipindahkan, dan sebagian rujukan itu milik user.

#Bagaimana migrasinya dijalankan?

Peralihan dilakukan per kota, tidak sekaligus. Kota tier 3 pindah lebih dulu, baru kemudian kota besar: Jakarta, Bandung, Medan, dan kota tier 1 lainnya. Kota yang lebih kecil berarti lebih sedikit user yang terdampak kalau ada masalah, dan setiap gelombang menghasilkan feedback nyata sebelum giliran kota dengan pemesanan terbanyak.

Buka ukuran penuh

Bagian saya ada di siklus feedback itu. Saya menangani tiket peta yang masuk dari setiap gelombang, dan tim saya memantau guardrail metrics bersama tim city operations: kalau pemakaian peta di sebuah kota turun di bawah batas yang sudah disepakati, atau pembatalan naik, kami menyelidikinya bersama tim kota sebelum gelombang berikutnya berjalan. Routing adalah langkah terpisah yang menyusul belakangan, setelah aplikasi navigasi untuk driver siap. Jadi fase ini soal tempat, bukan rute.

#Kenapa tempat tersimpan berhenti berfungsi?

Tempat tersimpan disimpan sebagai rujukan ke tempat milik provider sebelumnya. Dugaan pertama kami sederhana: cari padanannya di data POI kami sendiri, lalu arahkan tempat tersimpan ke sana. Cara itu berhasil untuk tempat populer. Cara itu gagal untuk banyak tempat yang paling penting bagi masing-masing user.

Kasus paling jelas datang dari GrabExpress. Para seller menyimpan titik antar pelanggan tetap mereka di aplikasi, dan justru tempat-tempat seperti itulah yang tidak pernah dilihat metrik cakupan: rumah di gang perumahan, toko kecil, pintu samping. Tempat populer sudah ada di peta kami. Tempat personal sering kali belum.

Jadi ini bukan masalah cakupan yang bisa diselesaikan dengan memetakan lebih banyak mal. Ini masalah ketergantungan: data user dibangun di atas ID milik provider lain, dan tidak ada inventarisnya sebelum cutover.

Buka ukuran penuh

#Bagaimana memigrasikan tempat yang disimpan user sendiri?

Engineer menarik data tempat tersimpan yang terdampak. Datanya minim: hanya latitude dan longitude untuk setiap titik, tanpa nama dan tanpa alamat. Saya berkoordinasi dengan tim bisnis GrabExpress untuk mengeskalasi dampaknya ke engineering dan product, lalu mencocokkan titik-titik itu dengan POI internal kami dan menambahkan yang belum ada.

Mencocokkan hanya dengan koordinat lebih sulit daripada kedengarannya. Diagram di bawah menunjukkan keputusan untuk setiap tempat tersimpan.

Buka ukuran penuh

1. Ada satu POI internal di dekatnya: anggap cocok dan arahkan ulang tempat tersimpan ke POI itu.
2. Ada beberapa POI di dekatnya: misalnya mal, menara apartemen, atau deretan ruko. Koordinat saja tidak bisa menunjukkan tempat mana yang dimaksud user, jadi perlu dicek manual.
3. Tidak ada POI di dekatnya: tempat itu belum ada di peta kami. Tambahkan dulu, lalu arahkan ulang.

-- Simplified illustration of the matching logic (not production code)
with nearby as (
  select s.saved_place_id,
         p.poi_id
  from saved_places s
  left join internal_pois p
    on st_dwithin(s.geom::geography, p.geom::geography, 30)  -- small radius, in metres
)
select saved_place_id,
       count(poi_id) as candidates,
       case
         when count(poi_id) = 0 then 'missing: add to map'
         when count(poi_id) = 1 then 'match: repoint'
         else 'ambiguous: human check'
       end as action
from nearby
group by saved_place_id;

Trade-off-nya adalah presisi melawan kecepatan. Mengarahkan setiap tempat tersimpan ke POI terdekat akan terlihat selesai lebih cepat, tetapi tempat tersimpan yang diam-diam menunjuk ke gedung yang salah lebih buruk daripada tempat yang hilang. User akan sadar kalau tempatnya hilang dan menyimpannya lagi. Tempat yang salah justru mengirim kurir ke pintu yang salah. Yang jelas cocok bisa langsung dipindahkan; sisanya perlu dicek.

#Bagaimana membuat feedback peta bisa ditindaklanjuti dalam skala besar?

Tiket adalah hambatan berikutnya. User melaporkan masalah ke agent customer service, lalu tim map support menerima seluruh percakapannya. Membaca percakapan panjang hanya untuk menemukan tempat mana, di mana, dan apa masalahnya menghabiskan sebagian besar waktu penanganan.

Saya memperkenalkan dua template: form request di sisi agent dan template jawaban di sisi map support. Agent mengubah percakapan menjadi laporan terstruktur, dan tim peta menjawab dalam format tetap yang bisa diteruskan agent ke user.

	Sebelum	Sesudah
Yang diterima map support	Seluruh percakapan agent dengan user	Form singkat yang terstruktur
Informasi yang tercatat	Apa saja yang kebetulan disebut user	Masalah, nama POI yang dibutuhkan, latitude/longitude, alamat
Langkah pertama tiap tiket	Membaca percakapan untuk menemukan masalahnya	Langsung menuju lokasinya
Balasan ke agent	Teks bebas, ditulis dari nol	Template jawaban yang bisa dipakai ulang agent

Bersama ekstraksi tiket otomatis, template ini menaikkan throughput dari sekitar 12 menjadi 25–30 tiket terselesaikan per hari. Ada juga manfaat yang tidak terlalu terlihat: tiket terstruktur bisa dikelompokkan per jenis masalah, sehingga sekumpulan keluhan serupa terlihat sebagai pola sejak awal, sebelum sempat menjadi keluhan publik.

#Bagaimana kami tahu peta baru sudah cukup baik?

Tidak ada satu metrik yang menentukannya. Kami melihat tiga sinyal.

1. Tempat-tempat krusial sudah ter-cover. Mal, stasiun, bandara, dan rumah sakit harus lengkap, karena di situlah titik jemput yang hilang paling merugikan.
2. Jenis feedback berubah. Tiket awal berbunyi "tempat yang saya simpan hilang". Lama-kelamaan berubah menjadi "tempat ini belum ada di peta": pemeliharaan peta biasa, bukan kerusakan akibat migrasi.
3. Seluruh perjalanan berhasil. Peta tampil, tempat bisa dipilih, pemesanan berjalan, dan driver bertemu penumpang di titik yang dipilih lalu mengantarnya ke tujuan yang benar, meskipun rutenya berbeda dari sebelumnya.

Sinyal kedua adalah yang akan saya pantau lebih dulu di migrasi berikutnya. Perubahan pada apa yang dikeluhkan orang lebih banyak bercerita daripada jumlah keluhannya.

#Apa yang akan saya cek pertama di migrasi berikutnya?

Setiap migrasi data punya versinya sendiri dari masalah tempat tersimpan: data yang dibangun sistem lain, atau user, di atas ID lama. Pergantian CRM punya filter pelanggan yang tersimpan, perubahan katalog punya wishlist pelanggan, migrasi data warehouse punya dashboard yang tidak pernah didaftar.

• Inventarisasi rujukannya sebelum cutover. Tanyakan apa saja yang merujuk ke ID lama, bukan hanya apa isi sistem lama.
• Long tail biasanya bersifat personal. Tempat yang paling penting bagi user jarang termasuk tempat yang dihitung metrik cakupan.
• Lebih baik data hilang daripada data salah. Otomatiskan yang jelas cocok, dan serahkan yang ambigu ke manusia.
• Strukturkan feedback sebelum skalanya membesar. Form yang mencatat lokasi dan jenis masalah mengubah keluhan menjadi data yang bisa dikelompokkan.
• Mulai dari tempat yang paling murah kalau salah. Kota-kota kecil memberi kami pelajarannya sebelum Jakarta.

Artikel berikutnya dalam seri ini beralih dari titik ke poligon: bagaimana celah kecil di antara batas layanan berubah menjadi area tanpa layanan sama sekali.

#FAQ

#Kenapa tidak memigrasikan semua kota sekaligus?

Peluncuran bertahap membatasi berapa banyak user yang terkena sebuah masalah, dan memberi waktu agar feedback setiap gelombang membentuk gelombang berikutnya. Konsekuensinya, sistem lama dan baru berjalan berdampingan lebih lama.

#Apakah tempat bisa dicocokkan hanya dengan koordinat?

Sebagian. Satu kandidat di dekatnya biasanya aman. Beberapa kandidat dalam jarak beberapa meter, seperti tenant di satu mal, butuh nama, alamat, atau pengecekan manual.

#Apa itu guardrail metric dalam migrasi?

Metrik yang tidak boleh turun selama perubahan diluncurkan, misalnya pemakaian peta atau pembatalan di sebuah kota. Kalau turun, cari penyebabnya dulu sebelum peluncuran dilanjutkan.

#Referensi

• Grab to be fully powered by its own mapping technology by Q3 2022, siaran pers Grab, Juni 2022
• Geospatial Product Ops: Di Antara Peta dan Bisnis, artikel pertama dalam seri ini

Terakhir diperbarui: 17 November 2026.