Adı belli bir kişiye ulaşan bir alarm, kimsenin bakmadığı bir dashboard'dan iyidir.

Server container çalışıyor görünürken bir reklam platformuna dönüşüm göndermeyi ya da beklenen alanları taşımayı bırakabilir. Bu yüzden yalnız uptime'a bakmıyor, kararları etkileyen veri akışlarını ve kendini belli etmeyen hataları da izliyoruz. Elinizde kapsamı ve sınırları yazılı olan, kontrollü hata provasında sınanmış ve adı belirlenmiş sorumlu kişilere ulaşan alarmlar kalıyor.

İzleme kurulumunu planla Server-Side Tracking ve Birinci Taraf Ölçümleme çalışmalarının tümü

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

Tüm referansları gör

İzlenebilen her metriği toplamıyoruz. Arızası kararları etkileyebilecek hedefleri, sinyalleri ve consent kontrollerini öne alıyoruz. Kritik sinyalleri belirliyor, eşikleri geçmiş veriye göre tanımlıyor, alarmları kuruyor ve kontrollü bir hata senaryosuyla sınamadan bırakmıyoruz.

Çalışma ilkelerimiz

Kontrol listesini iş kararlarından başlatırız — Monitoring aracında hazır gelen metrikleri sıralamak yerine, kritik hedefleri ve bu hedeflerin beslediği kararları temel alıyoruz.
Verinin hedef sistemlere gerçekten vardığını kontrol ederiz — GA4, reklam platformları ve veri ambarı için hedef teslimatını izliyoruz. Endpoint'in ping isteğine yanıt vermesi tek başına yeterli sayılmaz.
Sessiz veri sorunları için ayrı kontroller kurarız — Yanlış consent durumu ya da eksik event alanı her zaman teknik hata vermez. dataLayer'dan beklenen alanların gelmemesi gibi sessiz bozulmaları ayrı kurallarla izliyoruz.
Alarmları müdahale edebilecek kişilere yönlendiririz — Eşikleri ve alert routing yapısını, alarm gerekli bağlamla birlikte müdahale edebilecek adı belirlenmiş bir sorumluya gidecek biçimde kuruyoruz.

Kritik sinyalleri belirliyoruz
Başarısız olduğunda iş kararlarını etkileyecek hedefleri, veri akışlarını ve consent kontrollerini birlikte önceliklendiriyoruz. Hangi hedeflerin kritik olduğunu siz onaylıyorsunuz.
İzleme öncelik listesi
Eşikleri tanımlıyoruz
Her sinyal için arıza ya da sapma koşulunu gerçek trafik geçmişine göre belirliyoruz. Rastgele bir sınır kullanmıyoruz. Her eşik production'a alınmadan önce siz onaylıyorsunuz.
Eşik tanımları
Monitoring ve alert yapılandırmasını kuruyoruz
Kontrolleri bağlıyor, alert mesajına ilk müdahale için gereken bağlamı ekliyor ve routing'i sorumlu kişilere yönlendiriyoruz. Alert'in adı belirlenmiş bir operasyon sorumlusuna ulaştığını siz onaylıyorsunuz.
Alarm yapılandırması
Kontrollü hata provası yapıyoruz
Güvenli bir hata simüle ediyor, alert'in tetiklenmesini, doğru kişiye ulaşmasını ve runbook adımlarının işe yarayıp yaramadığını kontrol ediyoruz. Nöbetçi sorumlu, runbook adımlarının uygulanabilir olduğunu onaylıyor.
Prova kaydı

Önce kararları etkileyen veri akışlarını seçeriz

Otomasyon hedefleri bir arızanın maliyetine göre sıralar, geçmiş trafiğinizden eşik önerir, alarm kurallarını ve yönlendirmesini hazırlar ve prova edilen arızanın gerçekten yakalanıp yakalanmadığını kaydeder. Onaylar sizindir: hangi hedeflerin önemli olduğu, bir eşiğin yayına girmeden önce doğru olup olmadığı ve alarmın gerçekten izleyen bir kişiye ulaştığının teyidi.

Ekip, alert geldiğinde neyin izlendiğini, bunun neden önemli olduğunu ve ilk olarak nereye bakacağını bilir.

Yapılandırma kaydı
İzleme yapılandırması
İzlenen hedefleri, kullanılan eşikleri, kontrol sıklığını ve her sinyalin kararlar açısından neden önemli olduğunu açıklar.
Kullanım kılavuzu
Alarm kullanım kılavuzu
Alert tetiklendiğinde bakılacak ilk noktaları, müdahale sırasını ve sürece dahil olacak sorumlu kişileri tanımlar.
Test notları
Prova kanıtı
Kontrollü testte alert'in tetiklendiğini, routing'in çalıştığını ve runbook adımlarının uygulandığını kayda alır.

Şu olduğunda tamam sayarız: kontrollü bir hata alarmı beklenen süre içinde tetiklediğinde, gerçek bir nöbetçi sorumluya ulaştığında ve izlediği kılavuz adımı işe yaradığında.

Çalışan altyapının ötesinde veri teslimatını izlemek ve alarmlardan kimin sorumlu olacağını netleştirmek gerekiyorsa bu çalışma uygundur.

Şu durumlarda iyi bir seçim

Server-side container ya da kritik ölçümleme hattı yayında, ama temel uptime kontrolü dışında hedef teslimatını izleyen bir kural yok.
Tracking hatası ancak rakamlar günler ya da haftalar boyunca tutarsız kaldıktan sonra fark ediliyor, bu yüzden ekip hangi hedefin ne zaman bozulduğunu göremiyor.
Alarm yalnızca hata bilgisini veriyor, ama etkilenen hedefi ve runbook'taki ilk kontrol adımını ekibe söylemiyor.

Uzmanın alarm zili ve veri akışlarıyla birlikte monitoring kontrollerini yönettiği sahne

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

Server-side altyapı henüz kurulmamıştır, bu yüzden monitoring başlamadan önce GTM Server-Side Container ve Cloud Kurulumu container'ı devreye almalıdır.
Sorun veri ambarına indikten sonraki dönüşümlerde veya veri modellerinde görülüyor, bu yüzden hedef teslimatından daha geniş bir analytics engineering kapsamı gerekiyor.

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: Kritik hedefler ve kararları etkileyen sinyaller adlandırılmıştır, bu yüzden monitoring her endpoint'i izlemek yerine bu önceliklerle sınırlı kalır.

Zeo, bir iş kararını kurallara bağlı veri toplamaya ve sizin kontrol edebileceğiniz raporlamaya bağlayan ölçümleme sistemleri kuruyor. Burada gördüğünüz kişiler, bu sistemin sayfanın kapsadığı bölümünde çalışıyor.

Google Tag Manager
Yalnız uptime'ını değil, hedef bazındaki loglarını izlediğimiz server container
Google Tag Assistant
Prova edilen arızada gerçekte ne olduğunu göstererek kontrolü doğruluyor
Datadog
İlk adımdaki öncelik haritasını birinin aldığı gerçek alert'lere dönüştürüyor

Kritik hedefleri ve mevcut alert akışını paylaşın. Monitoring kontrollerini, sorumluluk dağılımını ve runbook adımlarını birlikte tasarlayıp prova edelim.

İzleme kurulumunu planla

Uptime monitoring varsa ek kontroller neden gerekir?

Uptime, server'ın yanıt verdiğini gösterir. Verinin doğru alanlarla GA4'e, reklam platformlarına ya da veri ambarına ulaştığını göstermez. Bu çalışma endpoint erişilebilirliğine ek olarak hedef teslimatını ve seçilen veri kalitesi kontrollerini izler.

Yeni alarmlar gürültü oluşturur mu?

Bu riski azaltmak için eşikleri gerçek trafik geçmişine göre belirliyor, normal kampanya ve mevsimsellik değişimlerini test ediyoruz. Yine de alert kalitesi düzenli gözden geçirme ister. Trafik deseni değişirse eşikleri yeniden ayarlamak gerekebilir.

Bir alert tetiklendiğinde ekip ne yapar?

Alert mesajı etkilenen hedefi ve ilk kontrol bağlamını taşır. Runbook, nöbetçi sorumlunun gece saat 2'de sıfırdan başlamadan önce hangi loga, metriğe ya da routing adımına bakacağını ve hangi teknik sorumluyu sürece katacağını gösterir.

Monitoring kurulumu için hangi girdiler gerekir?

Server container log ve metriklerine erişim, geçmiş trafik verisi, kritik hedeflerin listesi ve alert'lerin e-posta, Slack ya da çağrı aracı üzerinden hangi operasyon sorumlularına ulaşacağına dair karar gerekir.

Ekibe göre

Sektöre göre

Araca göre

Server-Side İzleme ve Güvenilirlik

Öncelik listesinden prova edilmiş alert akışına geçeriz

Kritik sinyalleri belirliyoruz

Eşikleri tanımlıyoruz

Monitoring ve alert yapılandırmasını kuruyoruz

Kontrollü hata provası yapıyoruz

Monitoring kurallarını, sorumlularını ve müdahale adımlarını teslim ederiz

İzleme yapılandırması

Alarm kullanım kılavuzu

Prova kanıtı