Entegrasyon hedefini netleştirin: konum → rezervasyon eşleşmesi
Arvento’dan gelen araç konumları ile şoför telefonundan gelen GPS kayıtlarını, transfer rezervasyonlarıyla aynı zaman ve kimlikle eşleştirmelisiniz. Hedef, “canlı araç haritasında doğru aracı doğru rezervasyonla” göstermek ve operasyon panelinde rota/son görülme bilgilerini tutarlı çalıştırmaktır. Bunun için önce veri türlerini ayırın: araç takip cihazı (Arvento) konumu genellikle cihaz ID veya araç plaka türevi anahtarlarla gelir; telefon GPS’i ise şoför telefonu numarası veya cihaz kimliği üzerinden ilişkilendirilir. Rezervasyon tarafında ise çoğu sistemde tripId, rezervasyonID, kalkış/varış saat pencereleri ve müşteri adresleri bulunur. Eşleşme kuralları net olmazsa panel yanlış atama gösterebilir. Bu rehberde, kimlik anahtarı ve zaman penceresi ile eşleşme yaklaşımını ele alacağız.
Veri sözleşmesi çıkarın: Arvento payload alanlarını tek tek görün
Bağlama öncesi Arvento entegrasyoninden gelen ham verinin alanlarını doğrulamak gerekir. Panel tarafında kullanacağınız alanları listeleyin: cihaz/araç kimliği (vehicleId veya deviceSerial), konum enlem-boylam, hız (km/s), yön (heading), zaman damgası (eventTime), doğruluk (accuracy/meters), batarya/gnss durumu varsa (opsiyonel). Şoför telefonundan gelen GPS için de benzer şekilde: telefon numarası (MSISDN), enlem-boylam, timeStamp, accuracy ve mümkünse hareket durumu. Bu iki kaynağı aynı modele indirgemeden canlı haritada “zıplama” ve rezervasyonla yanlış eşleşme görülür. En azından panelde tek bir normalleştirilmiş alan seti kullanın: sourceType, sourceKey, latitude, longitude, eventTime, accuracy, tripHint. Kaynak anahtarlarının türünü (string/number) ve biçimini (ör. +90’lı numara standardı) sabitleyin.
Kimlik eşleştirme stratejisi seçin: araç ID mi telefon mu?
Gerçek hayatta tek bir kimlik her zaman yeterli olmaz. Operasyon panelinizde iki aşamalı eşleştirme kullanın: önce araç cihaz kimliğiyle (Arvento vehicleId) rezervasyonu bulmayı deneyin; sonuç yoksa telefon GPS’i üzerinden şoför telefonu ile rezervasyonu bulun. Rezervasyonların şoför ataması düzenli ise telefon üzerinden eşleştirme daha stabil olabilir. Ancak şoför telefonu değişimi ya da hat geçişleri varsa, bu kez zaman penceresi ve konum yakınlığı ile doğrulama gerekir. Önerilen karar ölçütleri: (1) aynı araç/şoför kimliği, (2) eventTime ile rezervasyon startTime arasındaki sapma (ör. -15/+60 dk gibi), (3) geofence kontrolü: kalkış noktasına belirli yarıçapta (ör. 300–800 m bandı) gelmiş olma, (4) opsiyonel olarak adres hash veya son bilinen durakla tutarlılık. Bu ölçütleri “tek koşul” gibi değil, ağırlıklı doğrulama gibi kurgulayın.
Canlı araç haritası akışını kurun: son görülme, rota izi, durum
Bağlantının çalıştığını görmek için panelde canlı haritayı hedefleyin. Arvento ve telefon GPS kayıtları geldikçe her cihaz için lastSeenTime, lastKnownLatLng ve accuracy alanlarını güncelleyin. UI tarafında renk/ikon mantığı tanımlayın: eventTime rezervasyon pencersinde değilse gri, pencere içindeyse mavi, accuracy belirli değerin üstündeyse (ör. 50 m’den fazla) turuncu uyarı. Rota izi için son N nokta (ör. 50) tutun ve noktaları “zaman sırası”na göre ekleyin. Zaman damgaları farklı saat dilimlerinden geliyorsa UTC’ye çevirin. En önemli kontrol: aynı nokta tekrar tekrar geliyorsa çift sayım yapmayın; eventTime+sourceKey+latLng yuvarlama ile idempotent kayıt üretin. Böylece canlı harita görünümü operasyon anında güvenilir olur ve rezervasyon atamaları sarsılmaz.
Rezervasyonla eşleştirmeyi uygulayın: eşleşme penceresi ve öncelik
Rezervasyon eşleştirmede amaç “en doğru kaydı” seçmektir. Uygulama yaklaşımı: rezervasyon için aktif pencere oluşturun (ör. startTime-30 dk ile startTime+90 dk arası). Bu pencere içinde gelen konumlar değerlendirilsin. Ardından aynı rezervasyon için birden fazla konum gelirse seçim kuralı tanımlayın: (1) geofence içinde olanlara öncelik, (2) en düşük accuracy değerine öncelik, (3) eventTime rezervasyon startTime’a en yakın olana öncelik. Arvento geldiğinde öncelik her zaman Arvento olmalı demeyin; cihazın GNSS doğruluğu düşükse telefon kaydı daha iyi sonuç verebilir. Bu nedenle kaynak önceliğini sadece “sourceType” değil kaliteyle de birlikte belirleyin. Panelde eşleşme kararı sonrası rezervasyon kartında “eşleşen kaynak” bilgisini (Arvento/Telefon) kısa bir etiketle gösterin. Operatör böylece yanlışlık görürse hızlıca nedeni anlar.
Operasyon paneli ekranları: atama, doğrulama ve izleme kontrolleri
Panelde en az üç kontrol ekranı şarttır: (1) Canlı Araç Haritası: cihazlar, son görülme, doğruluk durumu. (2) Rezervasyon Eşleşme Akışı: rezervasyonun hangi konumdan eşleştiği, eventTime aralığı ve doğrulama sonucu. (3) Konum Kuyruğu/Senkr uç: son senkron zamanı, bekleyen olay sayısı ve hata mesajları. Operatör için somut alanlar tanımlayın: deviceId/vehicleId, şoför telefonu (normalleştirilmiş), rezervasyonID, konum doğruluğu metrikleri, en son güncelleme zamanı. Ayrıca “eşleşmedi” durumuna ayrı görünüm koyun: belirli bir süre içinde konum gelmemişse veya kimlik bulunamamışsa. Bu sayede uygulama hatası mı yoksa veri akışı kesintisi mi anlaşılır. Yanlış eşleşme gördüğünüzde önce lastSeenTime ve accuracy değerlerine bakın; çoğu hatada kök sebep hızlı anlaşılır.
Sık yapılan hatalar ve hızlı teşhis: saat, anahtar, yinelenme
En sık sorunlar üç başlıkta toplanır: zaman, kimlik anahtarı ve tekrarlı olaylar. Zaman sorunu: Arvento eventTime ile paneldeki startTime yerel saat/UTC farkından dolayı pencere dışına itilir. Teşhis için aynı noktayı tek cihazdan gelen iki kayda bakın; ikisi arasında saat kayması varsa saat dönüşümünü kontrol edin. Kimlik sorunu: telefon numarası +90 formatı yerine düz 0 ile geliyorsa eşleşme başarısız olur. Normalizasyon kuralı tanımlayın ve bunu hem ingest katmanında hem de eşleşme katmanında kullanın. Yinelenme sorunu: webhook aynı olayı iki kez gönderiyor olabilir; bu yüzden eventTime+latLng yuvarlama+sourceKey ile idempotent yazın. Bir diğer pratik kontrol: panel loglarında sourceType dağılımını izleyin; ani düşüş veri kesintisini gösterir. Hataların çoğu tek bir testle tespit edilir: aynı rezervasyon için Arvento ve telefon GPS’i aynı anda geliyorsa eşleşme kuralı doğru çalışıyor mu diye bakın.
Doğru mimari: ingest, normalize, eşleştir, göster; gecikmeyi yönetin
Doğru mimariyi katmanlara ayırın: (1) ingest: Arvento webhooks/polling ve mobil GPS alımı, olayları kuyruğa yaz. (2) normalize: tüm olayları ortak modele çevir, UTC’ye dönüştür, doğruluğu ve anahtarları standartlaştır. (3) eşleştir: pencere ve karar ölçütleriyle rezervasyon ataması yap; idempotentlik ekleyin. (4) göster: canlı harita ve rezervasyon kartlarını, son başarılı eşleşmeye göre güncelleyin. Gecikme yönetimi için iki zaman tanımı kullanın: eventTime (olayın üretim zamanı) ve receivedAt (sizin aldığınız zaman). Operatör ekranda “gecikme”yi görünür kılın: eventTime ile now arasındaki fark belirli eşiği geçerse uyarı verin. Ayrıca hata durumunda fallback kuralı ekleyin: Arvento kaydı gelmediğinde telefon GPS’i ile geçici eşleştirme yapılabilir, sonra Arvento tekrar gelince güncellenebilir. Bu yaklaşım Neptün Transfer panelinde kararların tutarlı görünmesini sağlar ve arka planda veri tutarsızlığı birikmez. Neptün Medya uygulamalarında da en kritik nokta, eşleştirmeyi UI’dan bağımsız katmanda, olay temelli ve test edilebilir biçimde yürütmektir.
Uygulama sonrası kontrol listesi
- Mobil görünüm, form ve WhatsApp yönlendirmeleri test edilir.
- Title, description, canonical ve sitemap kayıtları kontrol edilir.
- Kırık link, hatalı görsel ve boş CTA alanı bırakılmaz.
- İçerikler gerçek hizmet kapsamıyla uyumlu kalır.