Bir marketing ekibi, managed bir OpenSearch cluster'ı ve görünüşte basit bir istek: "email_open / email_sent oranını, kampanya offer'ı bazında, seçtiğim herhangi bir zaman aralığı için yüzde olarak göster." Sayıları göstermek kolaydı. Oranı göstermek değildi.
musth.io email marketing event'lerini—sent, open, hlo, link redirect—günlük analytics indekslerine yazıyor. Veri akıyordu; dashboard'lar soruyu cevaplamıyordu. Aşağıda OpenSearch Dashboards'tan dinamik ratio tablolarını nasıl çıkardığımızı, mapping'in yolda bize ne anlattığını ve Kibana Lens'in nerede devreye girdiğini anlatıyorum. Her zamanki gibi: sadece evidence pack'teki sayılar.
Kısa cevap: OpenSearch Dashboards standart bir tabloda iki event sayısı arasında dinamik yüzde hesaplayamıyor—oran önceden hesaplanmak zorunda, bu da dinamik zaman aralığını öldürüyor. İki çözüm kurduk: Filter Ratio aggregation'lı bir TSVB tablosu (event.name: "email open" bölü event.name: "email sent", offer bazında group by) ve formula transform, ratio'ya göre azalan sıralama ve pagination içeren custom bir Vega tablosu. Göç yolunu da not ettik: Kibana Lens aynı oranı native hesaplıyor. Yol üstünde mapping'de 19 campOfferName alanı bulduk (sadece 3'ü aktif) ve open sayısı kayıtlı sent sayısını aşan offer'lar gördük—matematik hatası değil, tracking boşluğu.
Sorun
Kurulum küçük ve dürüsttü: SaaS-managed OpenSearch, tüm rolleri taşıyan 3 node, node başına 4 GB memory / 2 GB JVM heap, toplam 20 GB disk (~%25 dolu). Veri create-only—update yok—günlük indekse yazılıyor (musth-analytics-%{YYYY-MM-DD}), retention 30 günde delete. Burada ölçek dramı yok; bu bir modelleme ve görselleştirme problemi.
İlk milestone, müşterinin kendi cümlesiyle: campOfferName başına email_open/email_sent yüzdesi gösteren bir tablo (POC için geçici olarak email_open/email_hlo), artı offer başına click+redirect/email_sent. Notlardaki örnek offer'lar: "Number One Coin", "EFIR Neuralink".
Engel şuydu: OpenSearch Dashboards email open ve email sent sayılarını yan yana rahatça gösteriyor ama dinamik bölemiyor. Yüzdeyi ingest'te önceden hesaplarsanız time picker süse dönüşüyor—artık "son 24 saat" ile "son 30 gün"ü canlı oranla karşılaştıramıyorsunuz.
Teşhis
Bir mantıksal alan, on dokuz mapped alan
Bir şey kurmadan önce campOfferName'in indekste gerçekte ne anlama geldiğine baktım. Mapping ("dynamic": "strict", neredeyse her şey keyword) 19 ayrı campOfferName alanı içeriyordu. Sadece 3'ünde veri vardı: event.campOfferName, context.event.campOfferName ve visible.campOfferName (nested). Kalan 16'sı—clicked.*, submitted.*, ref.*, endpointStart.*, sessionStart.*, userStart.* varyantları—boştu.
İki aktif üst seviye alan büyük ölçüde örtüşüyordu: musth-analytics-2024-* içindeki 75.471 dokümanın 70.463'ünde event.campOfferName, 70.985'inde context.event.campOfferName vardı ve değerler neredeyse aynıydı. Görselleştirmelerin hangi alanda group by yapacağına bu karşılaştırma karar verdi—burada yanlış tahmin, her orandan binlerce dokümanı sessizce düşürmek demek.
Open sayısı sent'ten büyük
Offer başına terms aggregation ve event.name sub-bucket'ları, her grafikten daha değerli bir veri kalitesi gerçeğini ortaya çıkardı: bazı offer'larda email sent kayıtlıydı (bir offer: 28.904 sent / 798 open), bazılarında ise binlerce open vardı ama hiç sent bucket'ı yoktu (bir offer: 6.241 open, sıfır sent event'i). Dashboard'da bu, "EFIR Neuralink" için %235,8'lik bir Email Ratio olarak göründü (500 sent, 1.179 open). Oran matematiği doğruydu; email sent instrumentation'ı her offer'ı kapsamıyordu. Marketing ekibi bir yüzde kolonuna güvenmeden önce bilmek isteyeceğiniz bulgu tam olarak bu.
Çözüm
TSVB Filter Ratio: native cevap
OpenSearch Dashboards TSVB'yi miras alıyor ve TSVB'de bu problemin tam karşılığı var: Filter Ratio. Table görselleştirmesi şöyle kuruldu:
- Group by field:
event.campOfferName, 1000 satıra kadar - Metric: Filter Ratio — pay
event.name: "email open", paydaevent.name: "email sent", metric aggregation Count - Ham Email Sent ve Email Open kolonları da eklendi; oran her an tek bakışta doğrulanabilir
Bu tamamen dinamik bir oran veriyor: time picker'ı değiştirin, yüzde yeniden hesaplanıyor. Tek kısıt panelin adına kadar işledi—"Email Ratio (Sorting Disabled)". TSVB tabloları hesaplanan ratio kolonuna göre sıralayamıyor.
Vega: pagination'lı, sıralanabilir oranlar
Sıralanabilir versiyon için musth-analytics* üzerine, time field olarak context.event.timestamp kullanan bir Vega spec yazdım. Spec'in içindeki veri hattı:
"aggs": {
"by_offername": {
"terms": { "field": "context.event.campOfferName", "size": 1000 },
"aggs": {
"hlo_count": { "filter": { "term": { "event.name": "email hlo" } } },
"open_count": { "filter": { "term": { "event.name": "email open" } } }
}
}
}
Formula transform bucket başına hlo_count / open_count hesaplıyor, collect transform ratio'ya göre azalan sıralıyor, window/filter ikilisi de client-side pagination yapıyor (sayfa başına 20 satır, prev/next okları Vega mark'ı olarak çizildi). %context% ve %timefield% sayesinde dashboard'un zaman aralığına ve filtrelerine uyuyor—yani TSVB panelleriyle aynı dashboard'da, tek offer'a filtreliyken %2,036 gösterirken TSVB'nin hlo/open varyantı kendi kolon düzeninde %1,442 gösteriyordu.
Lens çıkış kapısı
Notlar dürüst alternatifi de belgeliyor: Kibana'da Lens, email_open/email_sent oranını kutudan çıktığı gibi dinamik hesaplıyor—son 24 saat, son 30 gün, picker ne derse. Ratio tipi KPI'lar çoğalırsa bu workload'u Elasticsearch'e taşımak workaround'u tamamen ortadan kaldırıyor. OpenSearch'te kalan ekipler için TSVB + Vega işi görüyor; bedeli elle yazılmış bir spec'in bakımı. (TSVB tarafı için OpenSearch dashboards dokümantasyonu mevcut görselleştirme tiplerini anlatıyor.)
Deliverable olarak mapping hijyeni
19'a karşı 3 alan bulgusu kendi başına bir öneriye dönüştü: dynamic: strict zaten devredeyken 16 ölü campOfferName alanı saf template borcu—her biri, gelecekte bir görselleştirmenin boş alanda aggregate etmesi için bir fırsat. En iyi kapsama sahip alan olan context.event.campOfferName üzerinde birleşmek, her grafiği tek doğruluk kaynağında tutuyor.
Sonuçlar
Sadece evidence'ın desteklediği kadarı:
| Sonuç | Kanıt |
|---|---|
| Offer başına dinamik open/sent oranı, native | TSVB Filter Ratio tablosu, event.campOfferName group by, 1000 satır |
| Sıralanabilir + pagination'lı ratio tablosu | Vega spec: formula transform, azalan sıralama, pageSize 20 |
| Sayılarla desteklenen alan seçimi | 75.471 dokümanda iki aday alan: 70.985'e karşı 70.463 |
| Mapping borcu tespit edildi | 19 campOfferName alanı, 3 aktif, 16 boş |
| Tracking boşluğu ortaya çıkarıldı | Open'ı olup email sent event'i olmayan offer'lar; %235,8 açıklandı |
| Cluster zarfı belgelendi | 3 node, 4 GB/2 GB heap, 20 GB disk ~%25 dolu, 30 gün retention |
Uydurma KPI yok: kaynak pakette open-rate iyileşmesi, maliyet veya latency rakamı bulunmuyor; burada da yok.
Öğrendiklerimiz
- "Bana yüzde göster" bir modelleme sorusudur. Sayılar aggregate olur; oranlar Filter Ratio (TSVB), Vega formula veya Lens ister—dashboard sözü vermeden önce karar verin.
- Duplicate alanlardan hangisinin gerçekten kapsama sahip olduğunu doğrulayın.
event.*ilecontext.event.*arasındaki doc-count karşılaştırması group-by alanımızı seçti; tahmin, dokümanı sessizce kaybettirir. - %100'ün üstündeki oranlar instrumentation bulgusudur. Sent kaydı olmayan open'lar payda eksik demek—grafiği değil, tracking'i düzeltin.
dynamic: stricteski template'i temizlemez. 19campOfferNamealanının 16'sı boştu; sadece gelen dokümanı değil, template'i de budayın.- Vega, TSVB'nin yapamadığı sıralama ve pagination'ı satın alır—bedeli birinin bakmak zorunda olduğu bir spec. Ekip birini seçene kadar iki paneli de tutun.
- Çıkış kapınızı bilin. Kibana Lens dinamik oranı native yapıyor; ürününüz KPI dashboard'ıysa platform seçiminde bunu hesaba katın.
Marketing veya ürün analitiğiniz OpenSearch'te yaşıyor ve dashboard'lar oran sorularına cevap veremiyorsa bu çözülmüş bir problem—cluster ve dashboard tarafına nasıl yaklaştığımı searchali.com/tr/monitoring adresinde görebilirsiniz.
Ekibinizin gerçekten güveneceği dashboard'lar mı lazım? → searchali.com