Reklam Doğrulamada Datacenter Proxy

Reklam doğrulama tek bir iş değildir; birbirinden çok farklı soruların ortak adıdır. “Kampanyanın Almanya’daki landing page’i açılıyor mu?” sorusu ile “Reklamımız bir yayıncı sitesinde gerçek bir kullanıcıya hangi sıklıkla gösteriliyor?” sorusu aynı araçla yanıtlanmaz. İlki, reklamın tıklandıktan sonraki yolunu, yani reklamverenin kendi kontrolündeki altyapıyı ilgilendirir. İkincisi reklam ağının müzayede, hedefleme ve geçersiz trafik filtreleriyle ilgilidir. Datacenter proxy birinci grupta güçlü, ikinci grupta sınırlıdır.

Bu ayrımı baştan yapmak, pazarlama operasyonu ekiplerinin en sık düştüğü tuzağı önler: datacenter IP’siyle bir reklam ağına bakıp reklamı göremeyince kampanyanın bozuk olduğu sonucuna varmak. Oysa reklam ağı o trafiğe zaten reklam göstermemeyi seçmiş olabilir. Doğru soruyu doğru araçla sormak, hem yanlış alarmları hem de gereksiz harcamayı azaltır.

Bu sayfanın odağı, datacenter çıkışlarıyla güvenilir biçimde yapılabilen kontroller ve bunların otomasyonudur: kampanya URL’lerinin farklı ülkelerden erişilebilirliği, sayfanın ne kadar sürede yanıt verdiği, izleme yönlendirmelerinin parametreleri koruyup korumadığı, sayfanın doğru dilde ve doğru bölgesel içerikle açılıp açılmadığı, kreatif dosyalarının ve sayfa kaynaklarının sorunsuz yüklenip yüklenmediği. DatacenterProxy yalnız datacenter ürünleri sunar; bu yüzden datacenter’ın yetmediği durumları da açıkça yazıyoruz.

Bir doğrulama programı kurmadan önce yapılacak kontrolleri envanter olarak yazmak işe yarar. Her kontrolün neyi ölçtüğünü, hangi verinin kanıt olarak saklanacağını ve datacenter çıkışıyla ne kadar güvenilir yapılabildiğini tek tabloda görmek, araç seçimini ve bütçeyi netleştirir. Aşağıdaki tabloda “güvenilir” ifadesi, sonucun ağ türünden bağımsız olduğu anlamına gelir: aynı sayfa bir veri merkezinden de bir evden de aynı içerikle sunuluyorsa datacenter ölçümü temsil gücüne sahiptir.

Tablodaki son satır bilinçli olarak eklendi. Reklamın yayıncı sitelerinde gerçek kullanıcılara nasıl gösterildiğini ölçmek, reklam ağının kendi raporlarının ve bu iş için akredite edilmiş ölçüm hizmetlerinin alanıdır. Datacenter proxy bu ölçümün yerini tutmaz; ilk dört kontrol ailesinde ise hızlı, tekrarlanabilir ve ucuz bir altyapı sağlar.

En temel ve en değerli kontrol, kampanyanın nihai landing page adresinin her hedef pazardan açılıp açılmadığıdır. Bir sayfanın yalnız bir ülkede 404 döndürmesi, bir bölgesel CDN kuralının yanlışlıkla bir pazarı engellemesi ya da bir ülke yönlendirmesinin sayfayı ana sayfaya atması, ödenen her tıklamanın boşa gitmesi demektir. Bu tür sorunlar genellikle reklamverenin kendi ofisinden fark edilmez; çünkü ekip sayfayı kendi ülkesinden görür.

Yanıt süresi de aynı turda kaydedilmelidir. Burada amaç mutlak bir hız iddiası değil, zaman içindeki değişimdir: aynı pazardan, aynı saatte, aynı yöntemle ölçülen süre bir gün belirgin biçimde artıyorsa bir şeyler değişmiştir. Datacenter çıkışının avantajı tam olarak bu tekrarlanabilirliktir; ev bağlantısındaki dalgalanma ölçüme karışmaz, böylece süredeki değişim büyük olasılıkla sayfanın veya altyapının kendisinden kaynaklanır.

Aşağıdaki iskelet her pazar için ayrı bir proxy adresi kullanır, sayfayı ilgili dil tercihiyle ister ve sonucu CSV dosyasına yazar. Kaydedilen alanlar: zaman damgası, pazar, istenen ve son adres, yönlendirme adımı sayısı, durum kodu, başlıkların gelme süresi, toplam süre, aktarılan bayt, sayfanın beyan ettiği dil ve sayfa başlığı. Sayfa başlığını kaydetmek, 200 döndüren ama aslında hata sayfası olan yanıtları yakalamanın en basit yoludur.

import csv
import re
import time
from datetime import datetime, timezone

import requests

# Her pazar için ayrı çıkış (ülke seçimi panelde yapılandırılır)
PAZARLAR = {
    "DE": {"proxy": "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT", "dil": "de-DE,de;q=0.9"},
    "GB": {"proxy": "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT", "dil": "en-GB,en;q=0.9"},
    "NL": {"proxy": "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT", "dil": "nl-NL,nl;q=0.9"},
}
URLLER = ["HEDEF_URL"]
USER_AGENT = "OrnekReklamKontrol/1.0 (iletisim: [email protected])"

LANG_RE = re.compile(r'<html[^>]*lang="([^"]+)"', re.I)
TITLE_RE = re.compile(r"<title[^>]*>(.*?)</title>", re.I | re.S)


def kontrol(url, pazar, ayar):
    proxies = {"http": ayar["proxy"], "https": ayar["proxy"]}
    headers = {"User-Agent": USER_AGENT, "Accept-Language": ayar["dil"]}
    basla = time.perf_counter()
    try:
        r = requests.get(url, proxies=proxies, headers=headers,
                         timeout=(10, 30), allow_redirects=True)
        govde = r.text
        return {
            "zaman": datetime.now(timezone.utc).isoformat(),
            "pazar": pazar,
            "istenen": url,
            "son_adres": r.url,
            "adim": len(r.history),
            "kod": r.status_code,
            "baslik_suresi": round(r.elapsed.total_seconds(), 3),
            "toplam_sure": round(time.perf_counter() - basla, 3),
            "bayt": len(r.content),
            "html_lang": (LANG_RE.search(govde) or [None, ""])[1],
            "content_language": r.headers.get("Content-Language", ""),
            "title": (TITLE_RE.search(govde) or [None, ""])[1].strip()[:120],
            "hata": "",
        }
    except requests.RequestException as e:
        return {"zaman": datetime.now(timezone.utc).isoformat(), "pazar": pazar,
                "istenen": url, "hata": type(e).__name__}


ALANLAR = ["zaman", "pazar", "istenen", "son_adres", "adim", "kod",
           "baslik_suresi", "toplam_sure", "bayt", "html_lang",
           "content_language", "title", "hata"]

with open("landing_kontrol.csv", "a", newline="", encoding="utf-8") as f:
    yazici = csv.DictWriter(f, fieldnames=ALANLAR, restval="")
    if f.tell() == 0:
        yazici.writeheader()
    for url in URLLER:
        for pazar, ayar in PAZARLAR.items():
            yazici.writerow(kontrol(url, pazar, ayar))
            time.sleep(2)  # aynı siteye art arda yüklenmemek için

Kodda iki süre ayrı tutulur. Başlıkların gelme süresi, sunucunun ilk yanıtı ne kadar sürede verdiğini gösterir; toplam süre ise HTML gövdesinin indirilmesini de kapsar. Başlık süresi artıp toplam süre ile arasındaki fark sabit kalıyorsa sorun sunucu tarafındadır; fark büyüyorsa sayfa ağırlaşmış olabilir. Bu ölçüm yalnız HTML belgesini kapsar, tarayıcıdaki tam yükleme süresini değil. Tam yükleme için gerçek bir tarayıcıyla düşük sıklıkta ayrı bir tur çalıştırmak daha doğrudur.

Bir reklamın tıklanmasıyla landing page arasında çoğu zaman birkaç adım vardır: reklam ağının tıklama adresi, reklamverenin izleme şablonu, bir kampanya yönetim aracının yönlendirmesi, HTTP’den HTTPS’e geçiş, dil veya ülke yönlendirmesi ve nihayet sayfanın kendisi. Bu zincirin herhangi bir halkasındaki hata, izleme parametrelerinin kaybolmasına, kullanıcının yanlış ülke sayfasına düşmesine ya da 404’e çıkmasına yol açar. Sorun çoğu zaman yalnız belirli bir ülkede ortaya çıkar; çünkü ülke yönlendirmesi zincirin içindedir.

Zinciri izlemek için curl yeterlidir. Aşağıdaki ilk komut her adımın durum kodunu ve Location başlığını sırayla yazar; ikinci komut ise yalnız özeti verir: son adres, adım sayısı, son durum kodu ve toplam süre. Gövde indirilmez ama GET isteği kullanılır; bazı sunucular HEAD isteğine farklı yanıt verdiği için gerçek davranışı görmek açısından GET daha güvenilirdir.

# 1) Her adımın durum kodu ve Location başlığı
curl -sS -L --max-redirs 10 -o /dev/null -D - \
  -x "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT" \
  -H "Accept-Language: de-DE,de;q=0.9" \
  "HEDEF_URL?utm_source=test&utm_campaign=dogrulama" \
  | grep -iE "^(HTTP/|location:)"

# 2) Özet: son adres, adım sayısı, son kod, toplam süre
curl -sS -L --max-redirs 10 -o /dev/null \
  -x "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT" \
  -w "son_adres=%{url_effective} adim=%{num_redirects} kod=%{http_code} sure=%{time_total}\n" \
  "HEDEF_URL?utm_source=test&utm_campaign=dogrulama"

Çıktıda bakılacak noktalar şunlardır. Son adreste utm ve tıklama kimliği parametreleri hâlâ duruyor mu; bir ara adım parametreleri düşürüyor mu? Zincirde gereksiz bir döngü ya da beklenenden fazla adım var mı? Kalıcı yönlendirme (301, 308) ile geçici yönlendirme (302, 307) bilinçli mi seçilmiş? Ülke yönlendirmesi doğru pazara mı gidiyor; örneğin Hollanda çıkışından gelen istek Hollanda sayfasına mı, yoksa varsayılan İngilizce sayfaya mı düşüyor? Son durum kodu 200 olsa bile son adres ana sayfaysa kampanya sayfası büyük olasılıkla bulunamamış ve sessizce ana sayfaya atılmıştır.

Yönlendirme zincirini düzenli olarak kaydetmek, değişiklikleri yakalamanın da en iyi yoludur. Bir site taşıması, bir CMS güncellemesi ya da bir CDN kuralı değişikliği zinciri bir gecede bozabilir. Her turda zinciri metin olarak saklayıp bir önceki turla karşılaştıran basit bir fark kontrolü, sorunu ilk günde yakalar.

Uluslararası kampanyalarda landing page’in açılması yetmez; doğru dilde, doğru para birimiyle ve o pazara ait yasal metinlerle açılması gerekir. Birçok site dili ve bölgesel içeriği iki sinyalle belirler: isteğin geldiği IP’nin ülkesi ve tarayıcının Accept-Language başlığı. Datacenter çıkışı ülke sinyalini sağlar; dil başlığını ise siz gönderirsiniz. İkisini ayrı ayrı değiştirerek sitenin hangi sinyale öncelik verdiğini öğrenebilirsiniz.

Kontrol edilecek alanlar sayfaya göre değişir ama tipik liste şöyledir: html etiketindeki lang değeri ve Content-Language başlığı, fiyatlardaki para birimi simgesi, bölgeye özel kampanya metni, çerez bildirimi ve yasal bilgilendirme metninin dili, iletişim bilgileri ve kargo koşulları. Bu alanlar için sayfa türüne göre basit metin kuralları yazmak, ekran görüntüsünü gözle incelemekten çok daha ölçeklenebilirdir. Ekran görüntüsü ise kuralın alarm verdiği durumlarda kanıt olarak alınır.

Pazar listesi, hangi ürünün kullanılabileceğini doğrudan belirler. Katalogda static IPv4 beş ülkede (Amerika Birleşik Devletleri, Birleşik Krallık, Hollanda, Almanya, Kanada), rotating IPv4 on beş ana lokasyonda, static IPv6 on dokuz ülkede, rotating IPv6 dokuz ülkede sunulur. Aşağıdaki tablo, sık doğrulanan bazı pazarlar için katalogdaki eşleşmeyi gösterir. IPv6 ürünleri ancak landing page ve kaynakları IPv6 üzerinden erişilebilirse işe yarar.

Katalogdaki lokasyonlar ülke düzeyindedir. Kampanyanız şehir veya bölge düzeyinde farklı içerik gösteriyorsa ülke çıkışıyla bu farkı doğrulayamayabilirsiniz; bu sınırı rapora not edin. Bir de şuna dikkat edin: bazı siteler IP’nin ülkesini kendi veritabanlarına göre belirler ve bu veritabanları zaman zaman farklı sonuç verebilir. Bir pazarda beklenmedik dil görürseniz önce sitenin o çıkış IP’sini hangi ülkeye atadığını kontrol edin.

Kreatif doğrulamanın datacenter ile güvenilir yapılabilen kısmı, dosyaların kendisidir. Reklamda veya landing page’de kullanılan görsel, video, yazı tipi ve betik dosyaları genellikle herkese açık bir CDN’den sunulur. Bu dosyaların her pazardan 200 ile döndüğünü, doğru içerik türüyle geldiğini ve beklenen boyutta olduğunu kontrol etmek basit ama etkili bir kalite kapısıdır. Bölgesel bir CDN düğümünde eksik ya da eski bir dosya, yalnız o pazardaki kullanıcıların kırık görsel görmesine yol açar.

• Durum kodu: her kreatif ve kritik sayfa kaynağı her pazardan 200 dönüyor mu?
• İçerik türü: Content-Type beklenen biçimle uyumlu mu; görsel adresinden bir HTML hata sayfası dönmüyor mu?
• Boyut: Content-Length beklenen aralıkta mı; sıfır bayt ya da olağandışı küçük dosya var mı?
• Sürüm: önbellek başlıkları ve ETag değeri bütün pazarlarda aynı mı; bir düğüm eski sürümü mü sunuyor?
• Karışık içerik: HTTPS sayfasında HTTP üzerinden çağrılan bir kaynak var mı?
• Üçüncü taraf bağımlılık: sayfanın ana içeriği, erişilemeyen bir üçüncü taraf betiğe bağlı olarak boş mu kalıyor?

Büyük video dosyalarını her turda tamamen indirmek gereksiz trafik yaratır. Önce başlıkları okuyup boyut ve sürüm bilgisini almak, dosyanın tamamını yalnız sürüm değiştiğinde ya da günde bir kez indirmek yeterlidir. Kreatifin bir reklam ağının sunucusundan sunulduğu durumlarda ise erişim, ağın politikalarına bağlıdır; bu dosyaları ağın kendi önizleme araçlarıyla kontrol etmek daha doğrudur.

Reklam ağları ve ölçüm sistemleri, gösterimlerin gerçek insanlara yapıldığından emin olmak için geçersiz trafik filtreleri uygular. Sektörde yaygın kabul gören geçersiz trafik yönergeleri, veri merkezlerinden gelen trafiği genel geçersiz trafik kategorisinde ele alır. Bunun pratik sonucu şudur: bir datacenter IP’sinden yayıncı sitesine bakan bir doğrulama betiği, reklamı hiç görmeyebilir, farklı bir reklam görebilir ya da gördüğü gösterim raporlardan ayıklanabilir. Bu bir arıza değil, sistemin tasarlandığı gibi çalışmasıdır.

Dolayısıyla aşağıdaki sorular datacenter proxy ile güvenilir biçimde yanıtlanamaz: reklamın belirli bir yayıncı sitesinde gerçek kullanıcılara gösterilip gösterilmediği, sıklık sınırlarının nasıl uygulandığı, yeniden hedefleme ve kişiselleştirilmiş teklif sonuçları, reklamın sayfada görünür alanda kalıp kalmadığı. Bu soruların doğru kaynağı reklam platformunun kendi raporları, yerleşim raporları ve bu amaçla akredite edilmiş bağımsız ölçüm hizmetleridir.

Ev kullanıcısı kimliği taşıyan proxy türleri bu tabloyu kısmen değiştirir ama orada da aynı etik sınır geçerlidir: doğrulama amacıyla bile gösterim ya da tıklama üretmek, reklamverenin bütçesini harcar ve verilerini bozar. Bu sitede yalnız datacenter ürünleri sunulur. Datacenter’ın güçlü olduğu alan, reklamverenin kendi altyapısıdır: tıklamadan sonra olan her şey.

Tek seferlik kontroller kampanya açılışında işe yarar ama asıl değer düzenli turlardan gelir. Aşağıdaki sıra, pazarlama operasyonu ekibinin teknik ekiple birlikte kurabileceği hafif bir doğrulama döngüsünü tarif eder. Her adımın çıktısı bir sonraki adımın girdisidir.

1. Kampanya envanterini çıkarın: her aktif reklam için pazar, nihai landing page adresi, izleme şablonu ve kullanılan kreatif dosyaları tek tabloda toplansın.
2. Pazarları katalogla eşleştirin: her pazar için hangi ürünün ülke listesinde yer aldığını belirleyin; sabit çıkış gereken pazarlarda static IPv4, geniş örnekleme için rotating IPv4 kullanın.
3. Kendi analitik ve güvenlik araçlarınızda doğrulama trafiğini tanımlayın: tanımlayıcı User-Agent ve, static IP kullanıyorsanız, çıkış IP’lerini analitik raporlarından hariç tutun.
4. Hafif turu planlayın: landing page durum ve süre kaydı ile yönlendirme zinciri kontrolü günde birkaç kez, hedef sunuculara yük bindirmeyecek aralıklarla çalışsın.
5. Ağır turu planlayın: kreatif dosyalarının tam indirilmesi, gerçek tarayıcıyla tam sayfa yüklemesi ve ekran görüntüsü günde bir kez ya da sürüm değiştiğinde çalışsın.
6. Kuralları yazın: durum kodu 200 değilse, son adres beklenen sayfa değilse, dil beklenen değer değilse, izleme parametresi kaybolmuşsa ya da süre önceki günlerin belirgin biçimde üstündeyse alarm üretilsin.
7. Alarmı doğru kişiye yönlendirin: landing page sorunları web ekibine, yönlendirme sorunları kampanya operasyonuna, kreatif sorunları tasarım ekibine gitsin.
8. Kanıtı saklayın: her alarm için CSV satırı, yönlendirme zinciri ve ekran görüntüsü kampanya kimliğiyle birlikte arşivlensin; platform destek ekibine başvururken bu kayıtlar kullanılsın.

Turların zamanlaması da sonuçların yorumunu etkiler. Kampanya yayın saatleri pazara göre değişiyorsa kontrolleri o pazarın yerel saatine göre planlayın; gece yarısı yapılan bir bakım çalışması, sabah reklam trafiği başladığında çoktan bitmiş olabilir ve gereksiz alarm üretir. Aynı nedenle her alarmı tek bir başarısız ölçüme dayandırmayın: kısa bir aralıkla tekrarlanan ikinci ölçüm de aynı sonucu veriyorsa alarm üretin. Bu basit kural, geçici ağ dalgalanmalarından doğan yanlış alarmların büyük kısmını eler ve ekibin alarmlara güvenini korur. Kayıtları en az kampanya süresi boyunca saklamak da önemlidir; bir platform destek ekibine ya da ajansa sorunun hangi gün başladığını gösterebilmek, çözüm süresini belirgin biçimde kısaltır.

Doğrulama işinin trafiği scraping projelerine göre küçüktür; bu yüzden maliyet hesabı çoğu zaman sürpriz biçimde düşük çıkar. Yine de hesabı yapmak gerekir, çünkü kreatif dosyalarının ve tam sayfa yüklemelerinin trafiği hafif kontrollerden kat kat büyüktür. Aşağıdaki örnekte sayılar varsayımdır; kendi kampanyanızın sayfa ve dosya boyutlarıyla yeniden hesaplayın.

Hesapta 1 GB = 1.000.000 KB ve 1 GB = 1.000 MB alındı. Rotating IPv4 ile bu ihtiyaç bir adet 20 GB (12 dolar) ve bir adet 10 GB (6 dolar) paketle karşılanır; 30 GB için toplam 18 dolar ödenir. Kontrol başına düşen maliyet 18 / 29.250 ile yaklaşık 0,0006 dolardır. Artan 6,4 GB’ın sonraki aya devri, sipariş adımında gösterilen kullanım koşullarına bağlıdır; bunu varsaymadan önce kontrol edin.

Static IPv4 alternatifinde katalogdaki en küçük paket 100 IP için 30 günlük dönemde 15 dolardır. Üç pazar için 100 IP fazlasıyla yeterlidir ve sabit IP’nin iki somut getirisi vardır: doğrulama trafiğini analitik raporlarından IP ile ayırmak ve kendi hazırlık ortamınıza yalnız bu IP’lere izin veren bir erişim kuralı yazmak. Katalog static paketler için trafik kotası belirtmez ve paket içindeki IP’lerin ülkelere nasıl dağıtılacağını da göstermez; üç pazarın tek pakette karşılanıp karşılanamayacağını sipariş adımında doğrulayın.

Pratikte sık görülen kurgu ikisinin birleşimidir: kendi landing page’leriniz için sabit ve raporlardan ayrılabilir çıkışlar sağlayan bir static IPv4 paketi, daha geniş pazar örneklemesi ve Türkiye, Fransa, İspanya gibi static IPv4 listesinde bulunmayan ülkeler için rotating IPv4. Örnekteki üç pazara Türkiye ve Fransa eklenirse hafif kontrol, tam yükleme ve kreatif kalemleri beşte üçten beşte beşe çıkar; trafik yaklaşık 23,6 × 5 / 3 ile 39,3 GB’a yükselir ve rotating IPv4’te 50 GB’lık paket (30 dolar) bu ihtiyacı karşılar.

Bu rakamların asıl mesajı şudur: doğrulama işinde proxy maliyeti nadiren karar belirleyicidir. Belirleyici olan, kontrollerin doğru kurgulanması, alarmların doğru kişiye gitmesi ve tek bir bozuk landing page’in kaç günlük reklam bütçesini boşa harcattığıdır. Bozuk bir sayfa ne kadar erken yakalanırsa o kadar az tıklama boşa gider.

Doğrulama betiğinin ürettiği bir hatanın kaynağı üç yerden biri olabilir: sizin proxy yapılandırmanız, hedef sayfanın altyapısı ya da hedefin otomatik trafiğe karşı politikası. Doğru teşhis, gereksiz alarmları ve yanlış ekibe giden biletleri azaltır. Tablodaki çözümlerin hiçbiri bir korumayı aşmayı içermez.

Aşağıdaki liste yeni bir kampanya yayına girmeden önce ve her büyük değişiklikten sonra kullanılabilir. Maddelerin çoğu otomatik turla karşılanır; bir kısmı ise ekip içi süreçle ilgilidir.

• Her pazar için nihai landing page adresi envanterde var ve o pazardan 200 dönüyor.
• Yönlendirme zinciri test parametreleriyle izlendi; izleme parametreleri son adrese kadar korunuyor, son adres beklenen sayfa.
• Ücretli tıklama adresleri otomasyonla çağrılmıyor; zincir kendi şablonla ve platform önizleme araçlarıyla doğrulanıyor.
• Sayfa her pazarda doğru dil, para birimi ve yasal metinle açılıyor; kural ve ekran görüntüsü kaydı var.
• Kreatif dosyaları ve kritik sayfa kaynakları her pazardan doğru içerik türü ve boyutla yükleniyor.
• Doğrulama trafiği analitik raporlarından ayrılıyor; kendi koruma kuralların bu trafiği tanıyor.
• Tur aralıkları hedef sunuculara yük bindirmeyecek biçimde ayarlı; üçüncü taraf sitelerde kullanım koşullarına uyuluyor.
• Toplanan verilerde kişisel veri yok; ekran görüntülerinde kişisel bilgi görünmüyor.
• Alarmlar sahipleriyle eşleşmiş; her alarm kampanya kimliği ve kanıtla arşivleniyor.
• Proxy kimlik bilgileri betik içinde değil, gizli değişken yönetiminde tutuluyor.
• Reklam gösterimi ve geçerlilik soruları için platform raporları ve akredite ölçüm kaynağı belirlenmiş; datacenter sonuçlarıyla karıştırılmıyor.

Bu listeyi uygulayan bir ekip, reklam doğrulamada datacenter proxy’den beklentisini doğru konumlandırmış olur: tıklamadan sonraki yolculuğun her pazarda sağlam olduğunu hızlı, tekrarlanabilir ve düşük maliyetle kanıtlamak. Gösterimin kendisini ölçmek ise başka araçların işidir ve iki alan birbirine karıştırılmadığı sürece her biri kendi işini iyi yapar.