Dashboard Nasıl Kurulur: Veri Kaynakları, KPI’lar, Grafikler ve Erişim

Dashboard kurmak için, neyi yanıtlaması gerektiğinden ve onu kimlerin okuyacağından yola çıkın, az sayıda metriği kesin olarak tanımlayın, bu metriklerin geldiği verileri bağlayın ve her biri için basit bir grafik seçin. Sonra hangi sayıları kimin görebileceğine karar verin. Yapay zekâ uygulama oluşturucu dakikalar içinde cilalı bir dashboard üretebilir; ama asıl zor kısım, kimsenin ona güvenip güvenmeyeceğini belirleyen şey, verinin ve tanımların doğru olmasıdır.

Grafiklerle değil, sorularla başlayın

Her şeyi göstermeye çalışan bir dashboard bir kez açılır ve unutulur. Grafikleri düşünmeden önce şunları yanıtlayın:

• Kimin için? Kurucu, bir satış ekibi, operasyon, yatırımcılar, müşterileriniz?
• Hangi kararları destekliyor? “Bir destek elemanı daha almamız gerekiyor mu?” bir dashboard’un yanıtlayabileceği bir sorudur. “Verilerimi göster” değildir.
• Ne sıklıkla bakacaklar? Günlük operasyon dashboard’ları taze veri ve uyarılar gerektirir; aylık bir yönetim görünümü gerektirmez.

Üç ila beş soru yazın. Her biri bir ya da iki metriğe dönüşür.

Her metriği kesin olarak tanımlayın

Dashboard tartışmalarının çoğu aslında tanım tartışmalarıdır. Her sayı için kısa bir tanım yazın:

Bu tanımları prompt’unuza yapıştırın. Aksi halde yapay zekâ, işletmenizin sayım şekline uymayan ama makul görünen bir hesaplama seçebilir.

Veri nereden gelir

Her yerde geçerli iki ilke vardır:

1. Anahtarları sunucuda tutun. API anahtarları ve veritabanı şifreleri uygulamanın ortam değişkenlerinde olmalı, asla tarayıcı kodunda olmamalıdır.
2. Tazelik konusunda karar verin. Her sayfa yüklenişinde birden fazla API’den veri çekmek yavaştır ve hız sınırlarına takılabilir. Çoğu iş dashboard’u için, saatte bir ya da gece bir kez kendi veritabanınıza senkronize edilen ve sayfada bir “son güncelleme” zamanı gösteren veri daha basit ve daha güvenilirdir.

API’ler size yeniyse, API nedir ve veritabanı nedir temel bilgileri açıklar.

Doğru grafiği seçin

• Değişimle birlikte tek bir sayı (“42 bin $, geçen aya göre yüzde 8 artış”) — bir KPI kartı. Çoğu dashboard’daki en yararlı öğedir.
• Zaman içinde eğilim — bir çizgi grafiği. Çubukları yalnızca az sayıda dönem için kullanın.
• Kategorileri karşılaştırmak — değere göre sıralanmış yatay bir çubuk grafiği.
• Bütünün parçası — yığılmış bir çubuk. Pasta grafikler yalnızca iki ya da üç dilim için işe yarar.
• Ayrıntı ve istisnalar — sıralama, arama ve filtreleri olan bir tablo. Çoğu zaman herhangi bir grafikten daha yararlıdır.

Renkleri tutarlı tutun: “bu dönem” için bir renk, “karşılaştırma” için sönük bir renk, yalnızca dikkat gerektiren şeyler için kırmızı.

Kimin neyi gördüğü

Erişimi inşa etmeden önce belirleyin:

• Dahili, herkes her şeyi görür — en basit olanı. İş verisi tutuyorsa yine de giriş gerekir.
• Role dayalı — satış satış sayılarını görür, finans marjları görür, yöneticiler kendi ekiplerini görür.
• Müşteriye dönük — her müşteri yalnızca kendi verisini görür. Her sorgu sunucuda müşterinin hesabına göre filtrelenmelidir. İki farklı müşteri olarak giriş yaparak test edin.

Gelir ya da müşteri verisi içeren, girişsiz herkese açık bir URL’deki bir dashboard, bulunmayı bekleyen bir veri sızıntısıdır.

İşe yarayan bir ilk prompt

10 kişilik bir B2B yazılım şirketi için bir satış dashboard’u yap. Hedef kitle: kurucular ve satış lideri, her Pazartesi kontrol ediyor. Genel bakış sayfası: bu ay yeni MRR, toplam MRR, bu ay yeni müşteriler, bu ay kayıp müşteriler ve satış hattı değeri için KPI kartları; her biri geçen aya göre değişimle. Son 12 ayın MRR’ını gösteren bir çizgi grafiği; yeni anlaşmaların kaynağa göre bir çubuk grafiği. Ekip (kurucu), değer, aşama ve kapanış tarihi sütunlu, aranabilir ve sıralanabilir bir tablo olan bir Anlaşmalar sayfası; sahibe ve aşamaya göre filtreler. Metrik tanımları: MRR, aktif aylık abonelik tutarlarının toplamıdır; yıllık planlar 12’ye bölünür. Kayıp, bu ay aboneliği sona eren müşterileri sayar. Şimdilik bir veritabanında gerçekçi örnek veri kullan; Stripe’ı daha sonra bağlayacağız. Bir “son güncelleme” zamanı göster. Giriş gerekli olsun. Temiz bir kenar çubuğu düzeni olsun.

Yapım adımları

1. Örnek veriyle düzen. Veri sahteyken, değiştirmesi ucuz olduğu sırada metrikleri ve grafikleri üzerinde anlaşın.
2. Bir gerçek kaynağı bağlayın. Her sayıyı kaynak sistemle elle karşılaştırın. MRR, Stripe’ın gösterdiğinden farklıysa, daha ileri gitmeden önce nedenini bulun.
3. Diğer kaynakları birer birer ekleyin, her birini kontrol ederek.
4. Planlı yenileme ya da yüklemede sorgular, “son güncelleme” etiketiyle.
5. Filtreler: önce tarih aralığı, sonra insanların sorduğu bir ya da iki diğer filtre.
6. Giriş ve roller.
7. Boş ve hata durumları: bir kaynak çalışmadığında ya da bir filtre hiçbir sonuç döndürmediğinde sayfanın ne gösterdiği.
8. Kitleyle paylaşın, sonra bir ay sonra kimsenin bakmadığı her şeyi kaldırın.

Hızlı yapın

Yavaş bir dashboard daha az kontrol edilir. Hesaplanması pahalı toplamları önceden hesaplayın (her siparişi taramak yerine günlük bir özet tablosu), büyük tabloları sayfalara bölün ve grafikler bitmeden önce başlık kartlarını yükleyerek sayfanın grafikler gelmeden de yararlı olmasını sağlayın. Bir sayının hesaplanması uzun sürüyorsa, her ziyarette yeniden hesaplamak yerine ne zaman hesaplandığını gösterin.

Sık yapılan hatalar

• Çok fazla grafik. Her şey vurgulanırsa hiçbir şey vurgulanmaz.
• Tanımsız metrikler. Aynı dashboard’u okuyan iki kişi aynı sonuca varmalıdır.
• Sayıları kaynakla hiç karşılaştırmamak. Tek bir yanlış rakam, insanların tüm dashboard’a güvenmesini bitirir.
• Her sayfa yüklemesinde her API’yi sorgulamak. Yavaş, kırılgan ve bazen pahalı.
• Tarih bağlamının olmaması. Her zaman dönemi ve karşılaştırmayı gösterin.
• Ön yüzde gizli anahtarlar. Tarayıcıda görünen bir API anahtarı, sayfayı açan herkes tarafından kopyalanabilir.

Bir BI aracı daha iyi seçim olduğunda

Verileriniz zaten bir veritabanında ya da veri ambarında duruyorsa ve ana kullanıcılar onu keşfetmek, dilimlemek ve kendi grafiklerini oluşturmak isteyen analistlerse, Looker Studio, Power BI, Metabase ve diğerleri gibi bir BI aracı, özel bir yapıdan daha iyi hizmet verir. Birçok SaaS aracının da iyi yerleşik raporları vardır; yeniden inşa etmeden önce bunlara bakın. Özel bir dashboard ise müşteriler ya da analist olmayanlar için yapıldığında, BI aracının ifade edemediği bir mantığa ya da izinlere ihtiyaç duyduğunda, işletmenize özgü bir şekilde birden fazla kaynağı birleştirdiğinde ya da zaten çalıştırdığınız bir ürünün içinde yer aldığında kazanır.

İş, sayıları görüntülemekten çok kayıtları değiştirmekse, bunun yerine bir yönetim paneli ya da dahili araç istersiniz; bkz. dahili araç nasıl kurulur. Sayılarınız bugün bir elektronik tabloda duruyorsa, bir elektronik tabloyu uygulamaya nasıl dönüştürürsünüz iyi bir sonraki okuma olur.

Mythex ile yapmak

Mythex’te dashboard’u tarif edersiniz ve ajan sayfaları ve grafikleri canlı bir önizlemede kurar; gerçekçi örnek verilerle başlar, sayıların kalıcı olması gerektiğinde özel bir Postgres veritabanına geçer. Dokümanlardaki dashboard kullanım senaryosu bir başlangıç prompt’u içerir. Verileriniz Google Sheets gibi bir araçtaysa, hesabı Bağlayıcılar üzerinden bağlayabilir ve ajandan onu okumasını ve bir dashboard kurmasını isteyebilirsiniz.

Uygulama için yerleşik veri ambarı bağlayıcıları yoktur; BigQuery, Snowflake, Stripe ve benzerleri için uygulama, proje sırları olarak sakladığınız anahtarlarla onların API’lerini çağırır. Dashboard’u görüntüleyen insanlar için giriş ve roller, inşa ettiğiniz uygulamanın parçasıdır. Bir prompt’tan başlamak için dashboard şablonlarına göz atın, örneğin metrik dashboard’u.

Sorular