Hangi sinyalin birinci tarafa taşınacağı, altyapı kurulmadan önce sinyal sinyal tartışılan bir mimari karardır.

Server-side'a geçiş tek başına bir teknoloji seçimi değildir. Hangi sinyallerin kendi domain'inizden geçeceği, ne kadar saklanacağı ve hangi bağımlılıkların üçüncü tarafta kalacağı birlikte değerlendirilmelidir.

Birinci tarafa taşınacak ve taşınmayacak sinyalleri gerekçeleriyle ayıran, uygulamaya hazır bir mimari karar.

Zeo mühendisinin takip akışlarını üçüncü taraf sistemlerden birinci taraf mimariye göre yeniden çizdiği sahne

Birlikte çalıştığımız 500'den fazla markadan birkaçı

Tüm referansları gör
  • Findeks
  • Defacto
  • Mynet
  • İstanbul Gedik Üniversitesi
  • Doremusic
  • DYO
  • Jollytur

Birinci taraf mimariyi tek bir reçete gibi uygulamak yerine browser, platform ve ekip kapasitesi sınırları içinde tasarlarız. Envanteri toplar, seçenekleri değerlendirir, onaylı privacy kurallarıyla hedef yapıyı tasarlar ve uygulama ekibine aktarırız.

Çalışma ilkelerimiz

  • Birinci taraf endpoint'ten yararlanacak sinyalleri seçeriz — Hangi sinyallerin birinci taraf endpoint üzerinden ilerlemesinin anlamlı fayda sağlayacağını, hangilerinin mevcut yapıda kalabileceğini belirleriz. Böylece kapsam gereksiz altyapıyla büyümez.
  • CNAME, tam container ve hibrit seçenekleri karşılaştırırız — ITP, CNAME cloaking'i tespit ettiği çerezlerde süre sınırı uygular. Tam server container bu belirli sınıra tabi değildir, ancak işletim maliyeti daha yüksektir. Seçenekleri trafik, bütçe ve ekip kapasitesine göre değerlendiririz.
  • Saklama ve consent kurallarını tasarıma dahil ederiz — Birinci taraf verinin saklama süresini ve onaylanan consent tercihinin downstream hedeflere nasıl aktarılacağını altyapı kurulmadan önce tanımlarız.
  • Üçüncü taraf bağımlılıklarını görünür tutarız — Bazı sinyaller, Storage Access API gibi cross-site mekanizmalara bağlı kalabilir. Birinci taraf mimarinin bu bağımlılıkları veya tüm browser ve platform sınırlarını ortadan kaldırdığını varsaymayız.
  1. Sinyal envanterini çıkarma

    Toplanan verileri, hedeflerini ve üçüncü taraf domain ya da depolama bağımlılıklarını kayıt altına alırız.

    Sinyal envanteri

    Yapay zeka desteği
    Mevcut tag'leri veri hedeflerine göre gruplandırır.
    İnsan onayı
    Envanterin doğruluğunu siz onaylarsınız.
    Sorumlular
    Ölçümleme Mimarı, Reklam Platformundan Sorumlu Kişi
    Büyük bir büyüteçle arama sonucu satırını inceleyen çizim karakter
  2. Mimari seçenekleri değerlendirme

    Uygulanabilir yaklaşımları trafik hacmi, ekip kapasitesi ve bütçe çerçevesinde karşılaştırırız.

    Seçenek karşılaştırması

    Yapay zeka desteği
    Her yaklaşımı sağlanan trafik ve bütçe bilgilerine göre karşılaştırmalı olarak taslaklar.
    İnsan onayı
    Kabul edilecek operasyonel ve teknik ödünleri siz seçersiniz.
    Sorumlular
    Ölçümleme Mimarı, Reklam Platformundan Sorumlu Kişi
    Devasa bir ölçüm kadranını okuyan çizim karakter
  3. Hedef mimariyi tasarlama

    Sinyallerin routing planını, saklama kurallarını ve consent durumunun downstream hedeflere aktarımını tanımlarız.

    Mimari plan

    Yapay zeka desteği
    Onaylanmış consent politikasındaki saklama kurallarını mimari taslağa aktarır.
    İnsan onayı
    Gizlilik sorumlunuz saklama ve consent kurallarını onaylar.
    Sorumlular
    Ölçümleme Mimarı, Gizlilik Sorumlusu
    Çizim masasında plan çizen karakter
  4. Uygulama ekibine aktarma

    Mimariyi, kurulumu üstlenecek ekibin kullanabileceği açık ve test edilebilir bir spesifikasyona dönüştürürüz.

    Uygulama özeti

    Yapay zeka desteği
    Onaylanan planı test maddeleri içeren uygulama özetine dönüştürür.
    İnsan onayı
    Mühendislik lideri özetin uygulanabilir olduğunu onaylar.
    Sorumlular
    Ölçümleme Mimarı, Mühendislik Lideri
    Bayrağı diğerine devreden çizim karakter

Her sinyal için faydayı, bağımlılığı ve işletim yükünü ayrı değerlendiririz

Otomasyon mevcut tag'leri gittikleri yere göre kümeler, her seçeneği trafiğiniz ve bütçenizle puanlar, onaylı consent policy'sinden saklama kurallarını çıkarır ve sonucu test edilebilir bir spesifikasyona dönüştürür. Kararlar size ve onaylayanlara aittir: hangi ödünlerin kabul edilebilir olduğu, saklama ve consent kurallarının ne olacağı ve spesifikasyonun gerçekten kurulabilir olup olmadığı.

Teslim, mimari şemayla sınırlı kalmaz. Seçenekleri, sınırları ve uygulama gereksinimlerini de içerir.

  • Mimari dokümanı

    Mimari plan

    Birinci tarafa taşınacak ve mevcut yapıda kalacak sinyalleri, routing kararlarını, saklama sürelerini ve consent kurallarını gösterir.

    Kabul koşulu

    Envanterdeki her sinyal birinci tarafa taşınır, olduğu gibi kalır ya da bırakılır; her biri gerekçesiyle yerine konur.

    Ritim: Sinyaller değiştiğinde yeniden ele alınır

  • Karar notu

    Seçenek karşılaştırması

    Değerlendirilen yaklaşımları, teknik ve operasyonel ödünleri ve önerinin gerekçesini kaydeder.

    Kabul koşulu

    Elenen her seçenek, kendisini eleyen somut kısıtı belirtir.

    Ritim: Build kararı verilmeden önce bir kez

  • Teknik özet

    Uygulama özeti

    Altyapıyı kuracak ekibin doğrudan kullanabileceği gereksinimleri ve doğrulama maddelerini içerir.

    Kabul koşulu

    Kurulumu yapacak ekip, ikinci bir keşif turuna gerek kalmadan özetten başlayabilir.

    Ritim: Build ekibine bir kez teslim edilir

Şu olduğunda tamam sayarız: önerilen mimari gerçekten kullandığınız platformlara karşı kontrol edildiğinde, işletim maliyeti tahmin edildiğinde ve mühendislik lideri spesifikasyonu kurulabilir bulduğunda.

Birinci taraf mimariye yatırım yapmadan önce hangi sinyallerin taşınacağını, bağımlılıkları ve işletim sorumluluğunu netleştiririz.

Şu durumlarda iyi bir seçim

  • Server-side tracking'in operasyonel maliyeti belli, ama hangi birinci taraf sinyallerin bu yatırımı haklı çıkaracağını henüz bilmiyorsunuz.
  • Altyapı seçimine hazırlanıyorsunuz, ama araçlarınızın veri saklama süresi, routing kuralı ve consent aktarımı üzerinde anlaşılmadığı için ekip hangi yapıya yatırım yapacağını bilmiyor.
  • CNAME cloaking, tam server container ve hibrit seçenekleri karşılaştırıyorsunuz, ama hangi teknik ödünü kabul edeceğiniz henüz belli değil.

Şu durumlarda başka bir çalışma daha doğru

  • Server container gereksinimi kesinleştiyse ve yalnız kurulum yapılacaksa doğru kapsam GTM Server-Side Container ve Cloud Kurulumu'dur.
  • Sinyallerin toplama rotası netleşmişken kalan iş veri ambarındaki dönüşümse, bu ihtiyaç Veri Zenginleştirme ve Dönüşüm kapsamına giriyor.

Bunlardan biri sizin durumunuza daha yakınsa, buradan başlayın: Server-Side Tracking ve Birinci Taraf Ölçümleme çalışmalarının tümü

Şu olduğunda tamam sayarız: mevcut tag envanterinin doğruluğu teyit edildiğinde ve kabul edeceğiniz teknik ödünleri açıkça belirlediğinizde.

  • Notion

    sinyal envanterini ve tarihli öneriyi baştan sona tek belgede tutuyor

  • Stape

    sayfanın hedef mimari adımının alternatiflerle kıyasladığı server container seçeneği

  • Google Tag Manager

    hedef mimarinin belirlediği server container varyantı, standart web container'ı değil

Mevcut tracking yapınızı paylaşın. Taşınması anlamlı sinyalleri, sürdürülecek bağımlılıkları ve operasyonel gereksinimleri birlikte belirleyelim.
Birinci taraf mimarisini planla

Hayır. Bazı kurulumlarda daha sınırlı bir CNAME yaklaşımı yeterli fayda sağlayabilir. Bazılarında ise tam server container gerekebilir. Öneriyi sinyal ihtiyaçları, sınırlar ve operasyonel kapasiteye göre belirleriz.