Veri Katmanı (DataLayer) Nedir? Dikkat Edilmesi Gerekenler

• İş gereksinimlerinin ve hedeflerinin, teknik özelliklere kolayca aktarılabilecek bir biçimde hizalanmış açıklaması.
• Dijital bağlamda saklanan, semantik bilgi için ayrı bir katman kavramı.

Değişken adını dataLayer, dijital bağlam ve etiket yönetimi çözümü arasında veri depolamak, işlemek ve aktarmak için Google Etiket Yöneticisi tarafından kullanılan veri yapısını belirtmek için kullanılır. Örneğin, Veri Katmanı yalnızca halka açık bir web ortamında değil, çeşitli bağlamlarda kullanılabileceğinden, dijital bağlam terimini web sitesine tercih ederim.

Veri Katmanı, DMZ’ye geliştiriciler ve pazarlamacılar arasında kök salmış olan Katman’dır. Bu çok teknik bir kavramdır, çünkü varlığı, belirli web teknolojilerinin (örneğin JavaScript) tarayıcıların uygulamalarla nasıl etkileşime girdiğine (örneğin Google Etiket Yöneticisi) getirdiği sınırlamalarla haklıdır. Aynı zamanda, Veri Katmanı, en azından kısmen veri toplama yöntemlerinden memnun olan iş gereksinimlerini ve hedeflerini hazırlayan pazarlamacılar, analistler, yöneticiler, tasarımcılar ve iletişim profesyonelleri tarafından kullanılmalıdır.

Başka bir deyişle, Veri Katmanı’nın bir şirket içindeki “veri organizasyonu” nun farklı paydaşları arasında sıcak bir şekilde tartışılması çok yaygındır. Öğreneceğimiz gibi, dijital verilerinizle arayüz oluşturan tüm uygulamalar tarafından kullanılabilen genel bir veri modeli olduğundan, tüm tarafları tatmin edecek bir yönetişim modeli hazırlamak çok zordur. Bu da bu yazıda keşfedeceğiz.

Veri Katmanı Nedir?

Kısacası, Veri Katmanı, web sitenizden (veya başka bir dijital bağlamdan) işlemek ve bağlanmak istediğiniz diğer uygulamalara aktarmak istediğiniz tüm verileri ideal bir şekilde tutan bir veri yapısıdır.

Veri Katmanı kullanmamızın nedeni, bazen anlamsal bilgilerin dijital bağlamda saklanan diğer bilgilerden ayrıştırılması gerektiğidir. Bunun nedeni, zaten mevcut olan bilgileri yeniden kullanırsak, orijinal kaynakta değişiklikler yapıldıktan sonra verilerin bütünlüğünün tehlikeye girme riski olmasıdır.

Çok yaygın bir örnek, web analizi izlemesidir. Ziyaretçi hakkındaki analiz aracınıza veri besleyen bir Veri Katmanınız olabilir. Genellikle, bu veriler sunum katmanında veya işaretlemede yoktur. Bu veriler, örneğin ziyaretçi (giriş durumu, kullanıcı kimliği, coğrafi konum), sayfayla ilgili meta veriler (optimum çözünürlük, resim telif hakları) veya hatta zaten işaretlemede bulunan, ancak erişmek istediğiniz bilgiler olabilir.

Bu çoğaltma genellikle e-Ticaret verilerinde görülür. Sayfanın üstbilgisinden veya içeriğinden işlem ayrıntılarını “kazımak” yerine, bu bilgiyi taşımak için Veri Katmanı‘nı kullanmak daha güvenilirdir. Çünkü yalnızca bu şekilde web sitesinden ayrılan veriler uygun olur, yani ne zaman hatalara daha az maruz kalır.

Örneğin, teşekkür sayfasındaki HTML işaretlemesinin H2 başlığında depolanan verileri kullanmaya eğilimliyseniz, işaretlemede veya bu HTML öğesindeki bilgilerin biçiminde yapılan tek bir değişiklik siteden izleme aracınız. Bununla birlikte, veriler sunum katmanına bağlantısı olmayan bir Veri Katmanı’nda depolandıysa, beklenmedik değişiklikler meydana gelme riski çok daha düşüktür (kesinlikle imkansız değildir). Kısacası, Veri Katmanı, içinde bulunduğu bağlam hakkında bilgi depolamak, işlemek ve aktarmak için bir veri yapısıdır .

Veri Katmanı: Teknik Olmayan Perspektif

Pazarlamacı, analist, yönetici, iletişim görevlisi veya diğer geliştirici olmayanlar için Veri Katmanı aslında dijital bağlamın her bir alt kümesi için iş gereksinimlerinin ve hedeflerinin bir listesidir. Örneğin, bir web mağazası için ticari gereksinimler ve hedefler arasında işlem bilgileri (satın alınanlar), kullanıcı verileri (satın alma işlemini yapan kişi), mekansal ve geçici ayrıntılar (satın alma nerede yapıldı ve hangi zamanda yapıldı) ve bilgiler olabilir. Olası mikro dönüşümler hakkında (kullanıcı ürün güncellemelerine abone oldu mu) gibi.

Aynı web sitesinin başka bir kısmı için, işletme gereksinimleri ve hedefleri, kullanıcıyı hangi sosyal medya kanalının kullanıcıyı web sitesinin getirdiğini veya kullanıcının hangi sayfaları birden fazla görüntülediğine ilişkin ayrıntıları içerebilir. Bunlar teknik özellikler değil, web sitesinin her bir iş alanı veya diğer dijital bağlamlar için belirlenen iş hedeflerini karşılamak için toplanması gereken öğelerin açıkça tanımlanmış listeleridir.

İdeal olarak, Veri Katmanı olabildiğince çok farklı araç / kullanıcı / paydaş tarafından kullanılabilen bilgiler taşır, ancak kendine özgü ifadelerin ortaya çıkması çok yaygındır. Bu nedenle Veri Katmanına, durgun, yekpare, tekil bir varlık olarak değil yaşayan, çevik bir model olarak davranmak son derece önemlidir.

Dijital analitiklerin herhangi bir yönüne benzer şekilde, bir Veri Katmanı da sürekli değişken olan bir şey olarak ele alınmalıdır. O saklayan veri, optimize edilmelidir.

Google Etiket Yöneticisi’nin DataLayer’ı

Araştırılan veri modeli için mevcut bir standart olmadığından ( çaba devam etmektedir ), Veri Katmanı’nın birçok teknik aksaklığı olabilir. Seçtiğim teknik bakış açısı, Google Etiket Yöneticisi aracılığıyla gelişen bakış açısıdır. Bunun nedeni, dataLayer, web ortamında yapılandırılmış bir veri modelinin daha zarif uygulamalarından biridir.

dataLayer verileri anahtar / değer çiftleri halinde tutan bir JavaScript Dizisidir. Anahtar, String biçiminde bir değişken adıdır ve değerler, izin verilen herhangi bir JavaScript türü olabilir. Bu, dataLayerfarklı veri türlerine bir örnektir :

dataLayer = [{ 
    'products': [{ 
            'name': 'kırmızı tshirt',
            'tuning': 'High-G',
            'price': 449.75
        },{
            'name': 'kırmızı ayakkabı',
            'tuning': 'Drop-C',
            'price': 1699
    }],
    'stores': ['istanbul', 'Ankara'],
    'date': Sat Sep 13 2020 17:05:32 GMT+0200 (CEST),
    'employee': {'name': 'burak'}
}];

Burada bir nesne dizisi (ürünler), sayısal değerler (fiyat), bir dizi dizisi (mağazalar), bir tarih nesnesi ve iç içe geçmiş bir nesne (çalışan adı) gibi değerlerimiz var.

Buradaki nokta dataLayer, jenerik ve araç agnostik olmasıdır. Tipik JavaScript Diziniz gibi davrandığı sürece, yalnızca bir araçla sınırlı kalmaz. dataLayerYukarıdaki nesnede yer alan bilgiler, bu sayfanın genel ad alanına erişimi olan herhangi bir uygulama tarafından kullanılabilir .

Bu Dizi içindeki verilerin işlenmesi böylece araca bırakılır. Örneğin, Google Etiket Yöneticisi’nde verileri işlemek için bir ara yardımcı nesne kullanılır dataLayer; bu daha sonra aracın kendisinde dahili, soyut bir veri modelinde saklanır. Bu dataLayer, genel ve araçtan bağımsız kalabilmenizi sağlar, ancak içindeki veriler Google Etiket Yöneticisi’nin kendine özgü özelliklerine uyacak şekilde işlenir. Google Etiket Yöneticisi tarafından kullanılan yardımcı nesnenin aşağıdakiler gibi bir dizi ilginç özelliği vardır:

• Dinleyenleri dinleyen bir dinleyici dataLayer. Bir itme meydana gelirse, itmedeki değişkenler değerlendirilir.
• dataLayerBir kuyruk (ilk giren ilk çıkar) olarak işleyen / işleyen yöntemleri alıp ayarlayın ve veri modelindeki özel değerlerin (nesneler, Diziler) doğru bir şekilde güncellenip eklenebildiğinden emin olun.
• Saklanan nesnelerin komutlarına ve yöntemlerine erişebilme ve dataLayerveri modeli bağlamında özel fonksiyonlar çalıştırma imkanı.

Bunların hepsi elbette Google Etiket Yöneticisi’nin kullanıcıları için şeffaftır, ancak örneğin Veri Katmanı Değişken noktalı değişken adlarına (gtm.element) ve özelliklere (gtm.element.id) neden eşit olarak erişebildiğini ve neden aynı tuşla birden fazla değeri içeri itebilirsiniz, dataLayerancak itme işleminden sonra tetiklenen etiketler için yalnızca en son itilen değer kullanılabilir.

Google Etiket Yöneticisi’ndeki özet veri modeli, herhangi bir değişken adının yalnızca en son değerine saygı duyduğundan, kuruluşun bir iş bileşeni olarak Veri Katmanının dataLayerDizi yapısı haline geleceği yeri ve zamanı belirlemesi gerekir . Bu bir sonraki bölümün konusudur.

İş Hedeflerinden Teknik Uygulamaya

En yaygın yaklaşım, inanıyorum ki, iş gereksinimleri ve hedefleri, sunucu tarafı kodu tarafından oluşturulması / dağıtılması gereken bir dizi anahtar / değer çiftine dönüştürülür, böylece GTM’dendataLayer önce gerekli tüm verilerle doldurulur.

Doğal olarak, bunu istemci tarafı koduyla yapabilirsiniz ve önceden doldurulmuş olması gerekmez , ancak iş açısından kritik veriler, dataLayersayfa yüklemesinde mümkün olan en kısa zamanda işlenirse en iyi şekilde güvence altına alınır, böylece veri kaybı kullanıcı sayfa oluşturulmadan önce sayfadan ayrılmaya karar verirse simge durumuna küçültülür dataLayer.

İşte bir örnek. İşletme hedefleri olarak izlemek istediğimiz aşağıdaki işletme gereksinimlerine sahip bir sayfamız var:

1. Kullanıcı Kimliği – yalnızca oturumdan veya cihazdan aygıta değil , tüm kullanıcı yolculuğunu izlemek istediğimizden
2. Dahili kullanıcı – çünkü kendi çalışanlarımızın trafiğini verilerden filtrelemek istiyoruz
3. Ziyaret sırasında hava durumu – çünkü havanın ziyaret davranışını nasıl etkilediğini görmek istiyoruz

Bu, web sitesinin bu bölümünün hedeflerini nasıl izlediğimiz üzerinde doğrudan etkisi olan basit, saçma da olsa iş gereksinimleri listesidir. Bu listeye, bu değişkenler için örnek değerlerin neler olduğu, kapsamları (isabet, oturum, kullanıcı, ürün) gibi devam etmeleri (sayfadan sayfaya devam etmeleri) gibi daha fazla bilgi eklenmelidir.

Her neyse, dataLayerkapsayıcı snippet’inden önce oluşturulan bir örnek şöyle görünebilir:

<script>
    window.dataLayer = window.dataLayer || [];
    dataLayer.push({
        'userId' : 'abf5-3245-ffd1-23ed',
        'internalUser' : true,
        'weather' : 'bulutlu'
    });
</script>
<!-- GTM Container Snippet Code Here -->

Gördüğünüz gibi, veriler GTM kapsayıcı snippet’inden önce oluşturulur, böylece GTM yüklenir yüklenmez tetiklenen tüm etiketler bu verileri kullanabilir.

dataLayerEtiketleriniz veya diğer sayfa içi kitaplıklar, bu önyükleme işleminden sonra verileri yapıya aktarabileceğinden, Google Etiket Yöneticisi sınırları içinde de kullanabileceğinizi ve kullanacağınızı unutmayın . Bu dinamik itmelerin veya veri alışverişlerinin dikkatli bir şekilde belgelenmesi gerektiğini düşünmüyorum, çünkü yalnızca itme yapan aracın etki alanında gerçekleşiyorlar. Böylece, dokümantasyon ve sürüm kontrolü aracın kendisinin karmaşıklığına bırakılmıştır.

Önceden işlenenlerin arkasına çok fazla düşünmeniz gerekmesinin nedeni dataLayer, her yeni paydaşın yönetim sorununu biraz daha karmaşık hale getirmesidir.

Veri Katmanının Yönetişimi

İyi bir yönetişim modeli oluşturmak zordur. Farklı seviyelerde uzmanlığa (ve genel ilgiye) sahip bir dizi farklı partinin insafına dayanan bir veri yapısı için bir tane bulmak daha da zordur. Bununla birlikte, iyi tanımlanmış, yapılandırılmış ve resmileştirilmiş bir yönetişim modeli, büyük olasılıkla, analitik kuruluşunuzun bir Veri Katmanı ile çalışırken yanlış adımlar nedeniyle patlamasını önleyecek tek şeydir.

Bu bağlamda bir yönetişim modeli, Veri Katmanı’nı, bölümlerini, içinde bulunduğu iş alanlarını, çeşitli sahiplerini, sürüm geçmişini, değişkenlerini, risk yönetiminin nasıl olduğunu açık bir şekilde tanımlayan bir belgedir (veya belgeler). Bu çok akıcı bir kavram ve organizasyona kendilerini bu proje etrafında nasıl organize etmek istediklerine bağlı, ama ideal olarak çalışmaktan memnuniyet duyacağım türden bir yönetim modeli:

1. I.Giriş
   1. Belgenin amacı
   2. Bu belge kimler içindir
   3. İçindekiler
2. Sürüm Geçmişi
   1. Revize edilenler
   2. Revize edildiğinde
   3. Kim tarafından revize edildi
3. Mülkiyet
   1. 1. Sahiplik ne demektir
      2. Sürecin sahibi
      3. Sahibinin hakları ve ayrıcalıkları nelerdir
   2. Paydaşlar
      1. Veri Katmanı’nda pay sahibi olanlar (araçlar, platformlar, departmanlar, ajanslar, üçüncü taraflar)
      2. Rolleri nedir
      3. Hakları ve ayrıcalıkları nelerdir
   3. Teknik Verileri
      1. Teknik Veri Katmanının sahibi kimdir (BT, çoğunlukla veya çok aydınlanmış bir pazarlamacı)
      2. Rolleri nedir
      3. Hakları ve ayrıcalıkları nelerdir
   4. Yönetimi
      1. İşletme gereksinimlerinin sahibi kimdir (pazarlama müdürü veya müşteri kuruluşunda benzer bir rol)
      2. Rolleri nedir
      3. Hakları ve ayrıcalıkları nelerdir
4. Proses Dağıtımı
   1. Taraflar Veri Katmanı’nı kullanır
   2. Özel gereksinimleri nelerdir
   3. Farklı paydaşlar arasındaki anlaşmazlıklar nasıl önlenir?
5. Risk Yönetimi
   1. Riskler nelerdir
   2. Onların şiddeti nedir
   3. Olasılıkları nedir
   4. Risklerin sahibi kim (ve bunları hafifletmek için alınan önlemler)
6. Veri Katmanı Yönetim Modeli
   1. Güncellemeler nasıl planlanır?
   2. Güncellemeler nasıl uygulanır?
   3. Güncellemeleri kim dağıtır
   4. Güncellemeleri kim test ediyor
   5. Kimler bilgilendirilmeli
   6. Belgeyi kim günceller
   7. Çatışmalardan kaçınma
7. Veri Katmanı Teknik Açıklaması
   1. Temeldeki veri yapısı nedir
   2. Bu yapı her bir aracın kendi veri modeline nasıl çevrilir?
   3. Ayrılmış değişken isimleri veya başka potansiyel çatışma kaynakları var mı
8. Veri Katmanı Değişkenleri
   1. Veri katmanı değişkenlerine çevrilmiş iş gereksinimleri
   2. İşletme alanına göre sıralandı
   3. Örnek değerler, kapsam, parametreler, beklenen türler
   4. Veriler nereden geliyor?
   5. Veriler nasıl kullanılır?
   6. Ve bunun gibi…

Biliyorum, korkunç görünüyor. Ve muhtemelen birçokları için kullanılamaz. Bununla birlikte, sürekli güncellenen böyle bir belgeye sahip olmak, sadece bazı sözleşme güvenliği sağlamakla kalmaz, aynı zamanda Veri Katmanı’nın en son yapısı ve formatı hakkında herkesi güncel tutar. Sayfadaki görüntü sayısını hesaplayan yeni bir JavaScript kod snippet’i oluştururken bu belgeye başvurulması / güncellenmesi gerekiyor mu? Muhtemelen değil.

İşlem Değeri’ni de kullanan bir dönüşüm pikseli uygularken bu belgeye başvurulması / güncellenmesi gerekiyor mu? Büyük ihtimalle.

Geliştirilmiş e-Ticaret dağıtırken bu belgeye başvurulması / güncellenmesi gerekiyor mu? Kesinlikle.

Hayattan veya büyük bir komplikasyondan daha büyük olması gerekmez. Sadece sahip bazı her zaman mevcuttur Veri Katmanı somut açıklamasını ve en azından, Veri Katmanı güncellenir nasıl ve kim tarafından yazılı olarak kabul ediyorum. Bu şekilde, uzun vadede, gereksiz değişikliklerin gerçekleşmesi gerektiğinde çok fazla sorundan tasarruf edersiniz.

Veri Katmanı’nın kavraması çok zor bir kavram olduğunu düşünüyorum. Bu sadece çoğu için teknik bir şey olduğu için değil, aynı zamanda çoğu iş gereksinimlerinin bir listesi olduğunu fark etmediği için.

İş hedeflerini iyi biçimlendirilmiş, yalın ve %100 kullanılan Veri Katmanına çevirmek gerçekten zordur. Dürüst olmak gerekirse, en büyük hatalardan birinin, projenin başlangıcında büyük bir gereksinim listesinin not edildiği, daha sonra sitedeki her bir sayfada görünen bir Veri Katmanına çevrildiği ve bundan sonra şelale modelini takip etmek olduğunu düşünüyorum. Noktaya bir daha asla dokunulmaz.

Bu işe yaramıyor.

Şelale modeli insan yanılgısı sayesinde kusurludur. Dijital bağlamımızın hemen hemen her yönünü kapsayabilecek bir anlamsal veri katmanı kadar geniş bir şeyin son şeklini tasarlayamaz veya tahmin edemeyiz. Çevik olmalı. Katmanın şeklinin zamanla daha netleştiğine dair karşılıklı bir anlayış olmalıdır.

Zamanınız varsa küçük başlayın ve ölçeklendirin. Acele ediyorsanız, yalnızca iş açısından kritik öneme sahip gereksinimlere odaklanın.

Ne yaparsanız yapın, Veri Katmanında hızlı bir şekilde değişiklik yapmanızı öneren bir işlem olduğundan emin olun. Bu çok fazla yağlama, eğitim ve bilgi aktarımı gerektirir. Bu yüzden herhangi bir veri projesindeki en önemli şeyin, tüm tarafları diğer tarafların projede neler yaptığını eğitmekle başlamak olduğunu düşünüyorum. Pazarlamacıları daha geliştirme odaklı ve geliştiricileri pazarlama çabalarınıza daha saygılı hale getirin.

Bu şekilde herkes kazanır ve kısa sürede güzel bir Veri Katmanına sahip olursunuz.