İki MCP Sunucusuyla Tek Sohbet: Reklam Metriklerini Form Sonuçlarıyla Birleştirmek

Reklam bütçenizi harcadığınız ekranla, form yanıtlarınızı topladığınız ekran farklıysa, bu iki sistem arasındaki ilişkiyi anlamak için verileri elle birleştirmek zorunda kalırsınız. Reklam platformunda tıklama sayısını görürsünüz, form yöneticisinde ise yanıtları. Peki bu iki veriyi bir araya getirerek, reklam harcamasının gerçekten kayıt olup olmadığını nasıl anlarsınız? Bu sorunun cevabı, Model Context Protocol (MCP) adı verilen yeni bir protokolle karşınızda durabilir.

Son sekiz gündür gerçekleştirdiğim bir deneyde, insan müdahalesi olmadan reklam metriklerini form sonuçlarıyla otomatik olarak birleştiren bir sistem oluşturdum. Bu sistem, iki farklı MCP sunucusunu aynı yapay zeka sohbetinde bir araya getirerek, verilerin tek bir yerde bütünleşmesini sağlıyor. İşte bu deneyin arkasındaki tasarım ilkeleri ve ortaya çıkan ilginç bulgular.

İki sistem arasındaki bağlantıyı kimin kurması gerekiyor?

Geleneksel yöntemde, iki farklı yazılım hizmetini birbirine bağlamak istediğinizde, genellikle birinin diğerinin API’sine doğrudan bağlanması gerekir. Örneğin, form hizmetinizin reklam platformuna bağlanması ve verileri birleştirmesi gerekebilir. Bu yaklaşımın en büyük handikapı, bağlantının kalıcı bir bakım yükü oluşturmasıdır. Bağlantıyı her kurduğunuzda, API değişikliklerine uyum sağlamak, kimlik doğrulama bilgilerini yönetmek ve bu yapıyı her yeni platform için yeniden oluşturmak zorundasınız.

MCP protokolü ise bu sorunu tamamen farklı bir şekilde ele alıyor. Her iki hizmetin de birer MCP sunucusu olarak çalışması durumunda, bir yapay zeka istemcisi her iki sunucuya da aynı anda bağlanabilir. Yapay zeka istemcisi, verileri birleştirme görevini üstlenir ve kullanıcının sorusunu yanıtlamak için gerekli tüm verileri anında toplar. Bu sayede, hizmetlerden biri diğerinin verilerini çekmek zorunda kalmaz. Her hizmet sadece kendi verisini doğru ve anlaşılır bir şekilde sunar; birleştirme işlemi ise istemcinin sorumluluğunda olur.

Örneğin, FORMLOVA adlı form hizmetinin belgesinde de açıkça belirtilmiş olan yaklaşımda, hizmetin görevi sadece kendi verisini sağlamak ve araçlarının giriş/çıkış şekillerini net bir şekilde tanımlamaktır. Yapay zeka istemcisi ise birden fazla MCP sunucusuyla etkileşime geçerek verileri birleştirir ve kullanıcıya sunar. Bu modelde, her yeni harici hizmet için FORMLOVA içinde yeni bir bağlantı kodu yazılmaz; bunun yerine, doğru bir şekilde tanımlanmış araçlar ve protokoller kullanılır.

Tek bir kaynağa odaklanan bir araç: Reklam atıf aracı

FORMLOVA’nın sunduğu reklam atıf aracı, bu yaklaşımın somut bir örneğidir. Bu aracın görevi oldukça dar ve net bir şekilde tanımlanmıştır: form yanıtlarını reklam kimliği, UTM kaynağı ve kampanya adı gibi alanlara göre gruplandırarak, her reklam için görüntüleme sayısını, yanıt sayısını ve dönüşüm oranını sunmaktır. Bu araç, reklam platformuna doğrudan bağlanmaz ve harcama, gösterim sayısı veya tıklama sayısı gibi verileri sağlamaz. Bunun yerine, sadece FORMLOVA’nın kendi verilerini sunar ve bu verileri, başka bir kaynaktan gelen verilerle karşılaştırmaya hazır bir şekilde sunar.

Aşağıdaki yapı, bu aracın nasıl çalıştığını göstermektedir:

// FORMLOVA’nın reklam atıf aracı: tek bir kaynağa odaklanan yapı
type AdAttributionRow = {
  adId: string;          // Reklam platformuyla eşleştirme için anahtar
  utmSource: string;     // UTM kaynağı
  campaign: string;      // Kampanya adı
  views: number;         // Formdaki görüntüleme sayısı
  responses: number;     // Formdaki yanıt sayısı
  cvr: number;           // Yanıt / Görüntüleme oranı (sadece form tarafındaki verilerle)
};

async function getFormAdAttribution(userId: string, formId: string): Promise<AdAttributionRow[]> {
  // Önce erişim kontrolü yapılır; araç sadece ilgili kullanıcının verilerini görür
  const access = await checkFormAccess(formId, userId, { requiredRole: "viewer" });
  if (!access.ok) return [];
  
  // Formun yanıt verileri, reklam kimliği bazında gruplandırılır
  // Bu fonksiyon içinde reklam platformuna yapılan herhangi bir HTTP çağrısı YOKTUR
  return aggregateResponsesByAdId(formId, userId);
}

Bu yapının en dikkat çekici yanı, eksikliği. Fonksiyon içinde reklam platformuna yapılan herhangi bir çağrı bulunmaz. Araç, sadece kendi verilerini sunmayı amaçlar ve diğer yarısını başka bir MCP sunucusundan almayı bekler. Bu yaklaşım, ilk bakışta kullanıcının sorusuna tam bir yanıt veremiyor gibi görünse de, gerçekte çok daha esnek ve sürdürülebilir bir yapı sunar.

Sekiz günlük uygulamada verilerin nasıl birleştiği

Bu sistemin nasıl çalıştığını anlamak için, sekiz günlük bir uygulama sürecini incelemek faydalı olacaktır. Aynı sohbet içinde, sırasıyla reklam platformundan ve FORMLOVA’dan veri çeken iki MCP sunucusu kullanıldı.

İlk olarak, reklam platformundan alınan veriler:

• Toplam harcama: 6.597 Japon Yeni (JPY)
• Toplam gösterim sayısı: 5.578
• Erişim sayısı: 3.065
• Frekans: 1,82
• Tıklama sayısı: 704
• Tıklama oranı (CTR): %12,62
• Bin gösterim başına maliyet (CPM): 1.183 JPY
• Tıklama başına maliyet (CPC): yaklaşık 9,4 JPY (harcama / tıklama)
• Günlük harcama aralığı: yaklaşık 570 ila 1.080 JPY

Bu veriler tek başına bakıldığında oldukça iyi görünüyor. Yüksek bir tıklama oranı ve düşük bir maliyet, reklam kampanyasının başarılı olduğunu gösteriyor. Ancak, bu veriler reklam tıklamalarının kayıt olup olmadığını göstermiyor. İşte tam da bu noktada, sistemin ikinci kısmı devreye giriyor.

FORMLOVA’nın MCP sunucusu aracılığıyla, aynı sohbette form yanıtları reklam kimliklerine göre gruplandırıldı. Artık her iki veri kaynağı da aynı yerde bulunuyordu. Reklam platformundan alınan harcama verileriyle, FORMLOVA’dan alınan yanıt verileri birleştirildiğinde, doğrudan dönüşüm maliyeti hesaplanabiliyordu. Ne reklam platformu ne de FORMLOVA tek başına bu hesaplamayı yapabilirdi; çünkü sadece yapay zeka istemcisi her iki kaynağa da aynı anda erişebiliyordu.

Bu yaklaşımın en büyük avantajı, her iki hizmetin de birbirinden bağımsız olarak çalışmaya devam edebilmesi ve herhangi bir kalıcı bağlantıya ihtiyaç duymamasıdır. Yapay zeka istemcisi, sadece gerektiğinde verileri birleştirir ve kullanıcıya sunar. Bu sayede, sistem daha esnek, daha güvenilir ve daha kolay bakım yapılabilir hale gelir.

Gelecekte neler değişebilir?

Bu deney, reklam metrikleri ve form sonuçları gibi farklı veri kaynaklarını birleştirmenin yeni bir yolunu gösteriyor. Model Context Protocol’un sunduğu esneklik sayesinde, artık insan müdahalesi olmadan otomatik olarak veri bütünleştirmesi yapılabilir. Bu yaklaşımın yaygınlaşmasıyla birlikte, farklı hizmetler arasındaki veri bütünleştirmesi daha kolay, daha güvenilir ve daha verimli hale gelebilir. Gelecekte, bu tür sistemlerin daha da yaygınlaşması ve kullanıcıların verilerini daha etkili bir şekilde yönetmelerine yardımcı olması bekleniyor.