R Shiny ile İnteraktif Veri Analizi Uygulaması Geliştirme

Statik bir raporda okuyucu hazır çıktıyı inceler. Shiny uygulamasında ise kullanıcı kendi sorusunu filtreler üzerinden sorar: bir bölge seçer, tarih aralığını daraltır, kategori değiştirir — ve buna bağlı bütün hesaplamalar ile görseller yenilenir.

R Shiny, R diliyle etkileşimli web uygulamaları geliştirmeyi sağlayan bir çerçeve. Analist veri hazırlama ve hesaplama mantığını R'da tutarken kullanıcıya filtreler, seçim kutuları, tarih aralıkları, tablolar ve grafikler içeren bir arayüz sunabiliyor. Bu yazıda UI/server ayrımından reaktif programlamaya, çalışan bir örnek uygulamadan yayına almaya kadar bütün akışı ele alıyorum.

“İyi tasarlanmış bir Shiny uygulaması, bir R analizinin üstüne konmuş birkaç kontrol öğesi değildir; veri mantığıyla kullanıcı deneyimini birleştiren küçük bir analitik üründür.”

1. Ne Zaman Shiny Geliştirmek Mantıklı?

Shiny özellikle kullanıcıların analiz parametrelerini değiştirebildiği, ancak hesaplama mantığının kontrollü kalması gereken durumlarda değerli. Uygulamaya başlamadan önce iki soruya cevap vermek gerekiyor: kullanıcılar hangi soruya cevap arıyor ve hangi veriye erişme yetkileri var?

2. UI ve Server: İki Temel Parça

Tipik bir Shiny uygulamasında UI kullanıcıya ne gösterileceğini tanımlar; server ise girdilere göre hangi işlemlerin yapılacağını ve çıktıların nasıl üretileceğini belirler. Küçük bir uygulama bu iki bölümü tek bir app.R dosyasında tutabilir.

library(shiny)

ui <- fluidPage(
  titlePanel("Örnek Analiz"),
  selectInput("segment", "Segment", choices = c("A", "B")),
  textOutput("result")
)

server <- function(input, output, session) {
  output$result <- renderText({
    paste("Seçilen segment:", input$segment)
  })
}

shinyApp(ui = ui, server = server)

Buradaki "segment" ve "result" kimlikleri UI ile server arasındaki bağın ta kendisi. Kimlikleri tutarlı yazmak ve tekrar kullanmamak, hata ayıklamayı belirgin biçimde kolaylaştırıyor.

3. Reaktif Programlama Nasıl Çalışır?

Reaktif programlama bir hesabı, onu etkileyen girdilerle ilişkilendirir. Girdi değiştiğinde Shiny yalnızca bağımlı çıktıları yeniden hesaplar; her etkileşimde uygulamanın bütün kodu baştan çalışmaz.

4. Çalışan Örnek: Filtrelenebilir Satış Dashboard'u

Aşağıdaki uygulama kendi demo verisini üretiyor, yani dış dosyaya ihtiyaç duymadan çalıştırılabiliyor. Kullanıcı tarih aralığını, bölgeyi ve kategoriyi seçiyor; seçimler KPI metnini, aylık trend grafiğini, kategori grafiğini ve özet tabloyu birlikte güncelliyor.

library(shiny)
library(dplyr)
library(ggplot2)

# Tekrar calistirildiginda ayni demo verisini uret
set.seed(42)
n <- 1200

sales <- data.frame(
  date = sample(
    seq(as.Date("2025-01-01"), as.Date("2026-12-31"), by = "day"),
    n, replace = TRUE
  ),
  region = sample(c("Marmara", "İç Anadolu", "Ege", "Akdeniz"), n, TRUE),
  category = sample(c("Elektronik", "Ev", "Giyim", "Spor"), n, TRUE),
  units = sample(1:8, n, TRUE),
  unit_price = sample(c(250, 400, 650, 900, 1400, 2200), n, TRUE)
) |>
  mutate(
    revenue = units * unit_price,
    cost = revenue * runif(n, min = 0.48, max = 0.78)
  )

ui <- fluidPage(
  titlePanel("Satış Performansı | İnteraktif Analiz"),
  sidebarLayout(
    sidebarPanel(
      dateRangeInput(
        "dates", "Tarih aralığı",
        start = min(sales$date), end = max(sales$date),
        min = min(sales$date), max = max(sales$date),
        format = "dd/mm/yyyy"
      ),
      selectInput(
        "region", "Bölge",
        choices = c("Tümü", sort(unique(sales$region))),
        selected = "Tümü"
      ),
      selectInput(
        "category", "Kategori",
        choices = c("Tümü", sort(unique(sales$category))),
        selected = "Tümü"
      )
    ),
    mainPanel(
      h3(textOutput("kpi")),
      p("Filtrelere göre aylık gelir eğilimi"),
      plotOutput("trend", height = "280px"),
      p("Kategori bazında gelir"),
      plotOutput("category_plot", height = "260px"),
      h4("Filtrelenmiş kayıtlar"),
      tableOutput("summary_table")
    )
  )
)

server <- function(input, output, session) {
  filtered_data <- reactive({
    req(input$dates)

    df <- sales |>
      filter(date >= input$dates[1], date <= input$dates[2])

    if (input$region != "Tümü") {
      df <- df |> filter(region == input$region)
    }
    if (input$category != "Tümü") {
      df <- df |> filter(category == input$category)
    }

    validate(need(nrow(df) > 0, "Bu seçimlerde kayıt bulunamadı."))
    df
  })

  output$kpi <- renderText({
    df <- filtered_data()
    paste0(
      "Toplam gelir: ",
      format(round(sum(df$revenue), 0), big.mark = ".", scientific = FALSE),
      " TL  |  Adet: ", sum(df$units),
      "  |  Kayıt: ", nrow(df)
    )
  })

  output$trend <- renderPlot({
    monthly <- filtered_data() |>
      mutate(month = as.Date(format(date, "%Y-%m-01"))) |>
      group_by(month) |>
      summarise(revenue = sum(revenue), .groups = "drop")

    ggplot(monthly, aes(x = month, y = revenue)) +
      geom_line(color = "#8B7CFF", linewidth = 1.1) +
      geom_point(color = "#62DFF2", size = 2) +
      labs(x = NULL, y = "Gelir (TL)") +
      theme_minimal(base_size = 12)
  })

  output$category_plot <- renderPlot({
    category_data <- filtered_data() |>
      group_by(category) |>
      summarise(revenue = sum(revenue), .groups = "drop")

    ggplot(category_data, aes(x = reorder(category, revenue), y = revenue)) +
      geom_col(fill = "#62DFF2", width = 0.68) +
      coord_flip() +
      labs(x = NULL, y = "Gelir (TL)") +
      theme_minimal(base_size = 12)
  })

  output$summary_table <- renderTable({
    filtered_data() |>
      group_by(region, category) |>
      summarise(
        revenue = sum(revenue),
        units = sum(units),
        transaction_rows = n(),
        .groups = "drop"
      ) |>
      arrange(desc(revenue))
  })
}

shinyApp(ui = ui, server = server)

5. Örnek Uygulama Nasıl Çalışıyor?

Tek bir reaktif kaynak kullanmanın görünmeyen bir faydası daha var: filtre mantığı dört ayrı yerde tekrarlanmadığı için bir kuralı değiştirmek istediğinizde tek bir yeri düzenlemeniz yeterli oluyor.

6. Prototipten Sürdürülebilir Uygulamaya

Uygulama büyüdükçe her bileşeni tek dosyada tutmak bakım maliyetini yükseltir. Shiny'nin modüler yapısı, tekrar kullanılan arayüz ve sunucu mantığını ayrı bileşenlere bölmeye yardımcı olur.

Veri seti çok büyükse tüm dosyayı uygulama başlangıcında belleğe almak uygun olmayabilir. Sorguyu kaynağa göndermek, yalnızca gerekli kolonları seçmek veya ön hesaplanmış özetler kullanmak gerekebilir.

7. İyi Bir Uygulama Yalnızca Çalışmaz, Anlaşılır da Olur

8. Performans, Güvenlik ve Hata Yönetimi

Yerel bilgisayarda sorunsuz çalışan bir uygulama, birden fazla kullanıcı aynı anda bağlandığında yavaşlayabilir. Üretim öncesinde yalnızca ekranın görünüşü değil; eş zamanlı kullanıcı sayısı, veri hacmi ve arka plandaki hesaplamalar da değerlendirilmeli.

9. Shiny Uygulaması Nasıl Yayınlanır?

Geliştirme için yerel çalışma idealdir. Ekiplerin veya son kullanıcıların uygulamaya tarayıcıdan erişmesi gerekiyorsa uygulamanın bir barındırma ortamında çalışması gerekir.

install.packages(c("shiny", "dplyr", "ggplot2"))
shiny::runApp(".")

Dosyayı app.R adıyla kaydettikten sonra RStudio'daki Run App düğmesi de aynı işi görür. Barındırma seçimi yapılırken kullanıcı sayısı, veri hassasiyeti, işletim sorumluluğu, erişim yönetimi ve bütçe birlikte değerlendirilmeli.

10. Kontrol Listesi

11. Sık Sorulan Sorular

Sonuç

R Shiny, hesaplama mantığını R ekosisteminde tutarken etkileşimli bir web arayüzü sunma imkânı veriyor. UI ve server ayrımı uygulamanın sorumluluklarını netleştiriyor; reaktif programlama ise kullanıcı seçimlerini ilgili analiz ve çıktılara bağlıyor.

İyi bir Shiny uygulaması yalnızca grafik göstermekle yetinmiyor. Doğru metrikleri, anlaşılır filtreleri, boş durum ve hata yönetimini, güvenliği ve performansı birlikte ele alıyor. Böyle tasarlandığında analiz çıktısı, kullanıcıların kendi sorularını keşfedebildiği bir karar destek aracına dönüşüyor.

“Statik rapor cevabı verir; iyi bir Shiny uygulaması kullanıcının soruyu kendisinin sormasına izin verir.”