Veri kalitesinden kim sorumludur? Analitik ekipleri için sorumluluk matrisi

Düşük kaliteli veriler başka eylemleri (ilişkilendirme hesaplama, reklam hizmetlerine teklif gönderme veya rapor oluşturma gibi) yararsız hale getirebileceğinden, verilerin kalitesinin güvence altına alınması dijital analitikte en büyük zorluk olmaya devam ediyor. Verilerle ilgili tüm sorunlardan analistlerin sorumlu olduğunu söylemek yaygındır. Ama bu doğru mu?

Bir şirkette veri kalitesinden kim sorumludur? Popüler inanışın aksine, sadece analistler değil. Örneğin, pazarlamacılar UTM etiketleriyle çalışır, mühendisler izleme kodları uygular, vb. Dolayısıyla, verilerle çalışırken kaosun oluşması şaşırtıcı değildir: her çalışanın birçok görevi vardır ve kimin ne yaptığı, kimin neyden sorumlu olduğu ve kimin sorumlu olduğu net değildir. sonuç kime sorulacak.

Bu yazımızda, her aşamada veri kalitesinden kimin sorumlu olduğunu ve nasıl yönetileceğini anlamaya çalışıyoruz.

Tek bir şirkette bile, veri dünyası tutarsızlıklar ve yanlış anlamalarla dolu olabilir. İş kullanıcılarını kaliteli verilerle güçlendirmek ve değerli verileri kaçırmamak için gerekli tüm pazarlama verilerinin toplanmasını planlamanız gerekir. Veri iş akışını hazırlayarak, noktaları birleştirmeyi kolaylaştırmak için verilerin tüm departmanlardaki iş arkadaşlarınız için nasıl ilişkili olduğunu gösterirsiniz. Ancak, bu sadece ilk adım. Raporlar ve gösterge tabloları için veri hazırlamada diğer adımların neler olduğunu görelim:

1. Birincil veri toplamayı ayarlayın.
2. Ham verileri veri deposuna veya bir veritabanına toplayın.
3. Ham verileri, işaretleme ile temizlenmiş ve iş için anlaşılır bir yapıda iş için hazır verilere dönüştürün.
4. Verileri görselleştirmek için veri kaynağı görevi gören düz bir yapı olan bir data mart hazırlayın.
5. Pano için verileri görselleştirin.

Ancak, tüm hazırlıklardan bağımsız olarak, karar vericiler genellikle düşük kaliteli veriler içeren bir rapor veya gösterge panosuyla karşılaşır. Ve yaptıkları ilk şey, analiste şu soruyla dönmek olur: Neden bir tutarsızlık var? veya Veriler burada alakalı mı?

Ancak gerçek şu ki, farklı uzmanlar bu süreçlere dahil oluyor: veri mühendisleri analitik sistemini kurmakla meşgul, pazarlamacılar UTM etiketleri ekliyor, kullanıcılar veri giriyor. Kullanıcılara yüksek kaliteli veriler sağlamak için hangi aşamalardan geçmeniz ve bunların nasıl uygulanması gerektiğini ayrıntılı olarak görelim.

Bu adım en kolayı gibi görünse de, birkaç gizli engel var. Her şeyden önce, tüm müşteri temas noktalarını hesaba katarak tüm kaynaklardan tüm verileri toplamayı planlamalısınız. Bazen bu planlama adımı atlanır, ancak bunu yapmak mantıksız ve risklidir. Yapılandırılmamış bir yaklaşım benimsemek, eksik veya yanlış veri elde edilmesine yol açar.

Asıl zorluk, birlikte çalıştığınız farklı reklam platformlarından ve hizmetlerden parçalanmış veriler toplamanız gerektiğidir. Büyük veri dizilerini mümkün olan en kısa sürede işlemek karmaşık ve kaynak yoğun olduğundan, olası darboğazların neler olabileceğini görelim:

• Tüm sayfalarda yüklü bir GTM kapsayıcısı yoktur ve bu nedenle veriler Google Analytics'e gönderilmez.
• Bir reklam platformunda yeni bir hesap oluşturulur, ancak analistler bilgilendirilmez ve bu hesaptan veri toplanmaz.
• API, UTM etiketlerinde dinamik parametreleri desteklemez ve bunları toplamaz veya aktarmaz.
• Google Cloud projesine bağlı kartta yeterli bakiye veya kredi yok.
• Bir kullanıcı tarafından girilen verilerin yanlış doğrulanması.

Bu adım sırasında, diğer tüm zorlukların yanı sıra verilere erişimi kontrol etmeyi de düşünmelisiniz. Bunun için, süreçler için rolleri tanımlayan ve kimin yaptığını, kontrol ettiğini, yönettiğini ve neyden sorumlu olduğunu vurgulayan klasik RACI matrisini kullanmanızı öneririz. İşte olası roller:

• R (Sorumlu) — belirli bir süreçten sorumlu ve yürütücüsü olan kişi
• C (Danışma yapıldı) — süreci uygulamak için danışan ve gerekli verileri sağlayan kişi
• A (Sorumlu veya Onaylayıcı) — işin sonucundan sorumlu olan kişi
• I (Bilgilendirilmiş) — işin ilerleyişi hakkında bilgilendirilmesi gereken kişi

RACI matrisine göre, veri toplamanın rolleri ve sorumlulukları şu şekildedir:

Bir sonraki adım, elde edilen tüm verilerin nerede saklanacağına karar vermektir. Ham verileriniz üzerinde değişiklik yapmadan tam kontrol sahibi olmak istiyorsanız, otomatik veri içe aktarma özelliğine sahip tek bir depolama alanı kullanmanızı öneririz. Her bayt veriyi depolamak için kendi sunucularınızı kullanmak bir servete mal olacağından, kaynaklarınızı koruyan ve verilere her yerden erişim sağlayan bulut çözümlerini kullanmanızı öneririz.

Bu görev için en iyi seçenek Google BigQuery'dir, çünkü pazarlamacıların ihtiyaçlarını göz önünde bulundurur ve web sitelerinden, CRM sistemlerinden, reklam platformlarından vb. ham verileri depolamak için kullanılabilir. Bugün, tonlarca pazarlama yazılımı çözümü vardır. Farklı hizmetlerden ve web sitelerinden otomatik olarak bir veri ambarına (veya veri gölüne) veri toplayan OWOX BI'ı öneriyoruz.

Ham verileri toplarken hangi klasik hataların oluşabileceğini görelim:

• Reklam hizmetinin API'si değişti. Buna göre, veri formatı da değişti.
• Harici hizmet API'si mevcut değil. Paydaş, kişisel hesabında belirli sayıları görür, ancak aynı reklam hizmetinin API'si başka veriler verir. Bu veriler, herhangi bir dağıtılmış sistemde olduğu gibi, reklam hizmeti API'sinin veri kaynağının web portalının veri kaynağından farklı olması nedeniyle eşleşmiyor.
• Harici hizmetin web arayüzündeki ve API'sindeki veriler farklıdır. Belgeleme ve veri işleme biçimleri farklı olabilir. Örneğin, popüler reklam hizmetlerinden birindeki ilginç bir hata, giderlerin hem yokken hem de gerçekte sıfırken sıfır olmasıdır. Tüm veri mühendisleri ve analistler, sıfır ve Null'un farklı değerler olduğunu ve farklı şekilde işlendiğini bilir. Bir durumda, bu masraflar görünebilir ve tekrar talep edilmelidir ve sıfır, gerçekten orada olmadıkları ve sıfır olarak sayıldığı anlamına gelir.
• Harici bir hizmetin API'si yanlış veriler sağlar.

Matrise göre, bu süreçte pazarlamacı bir danışman ve bilgi kaynağıdır: örneğin, hangi hesaplardan veri indirmeniz gerektiği, UTM etiketlerinin ne olduğu ve reklam kampanyalarında işaretleme hakkında bilgi.

Web sitesinin indirme hızından sorumlu olduklarından, Google Etiket Yöneticisi kullanılırsa kapsayıcılarda ne gibi değişikliklerin olacağını bilmek isteyen geliştiriciler de vardır.

Bu noktada veri mühendisleri, veri boru hatlarını yapılandırdıkları için sorumlu rolü zaten üstleniyorlar. Ve analistler çalışmanın sonucundan sorumludur. Bir çalışan bu işlevleri yerine getirse bile aslında iki rol olacaktır. Bu nedenle, şirketin yalnızca bir analisti varsa, yine de matrisin rollere göre uygulanmasını öneririz. Ardından, şirketin büyümesiyle birlikte yeni bir meslektaşınız için bir iş tanımınız olacak ve belirli bir rol için sorumlulukların ne olduğu netleşecek.

Bu aşamadaki paydaş, veri toplamaya yönelik öncelikleri ve kaynakları belirlediğinden, hangi verilerin mevcut olduğunu ve kalitesiyle ilgili ne gibi sorunlar olduğunu bilmekle ilgilenir. Örneğin, OWOX BI Veri İzleme özelliği müşterilerimiz tarafından yaygın olarak kullanılmaktadır.

Veri hazırlama bir sonraki adımdır. Genellikle data mart hazırlığı olarak adlandırılır - bu, gösterge tablosunda sunulacak parametreleri ve ölçümleri içeren düz bir yapıdır. Araçlar, bütçe ve zaman açısından kısıtlı olan bir analist, genellikle iş verilerinin hazırlanması aşamasını atlar ve hemen bir veri martı hazırlar. Bir veri ambarında toplanan ham verilere benziyor. Ardından, Python ve R komut dosyalarıyla birlikte bir milyon farklı SQL sorgusu vardır - ve bu karışıklık, gösterge tablosunda bir şeye neden olur.

İş için hazır verilerin hazırlanmasını atlamaya devam ederseniz, kaynakların her birinde düzeltilmesi gereken tekrarlanan hatalara yol açacaktır. Yanlış gidebilecek diğer şeyler şunlardır:

• Birincil verilerde düzenli hatalar
• Tüm SQL sorgularında çoğaltılan iş mantığı
• Veri tutarsızlıklarının nedenlerini bulmak için çok zaman gerekiyor
• Bir isteği yeniden yazma süresiyle karşılaştırılabilir şekilde mevcut veri pazarlarını iyileştirme zamanı
• Rapor mantığının müşteri tarafından anlaşılmaması

Bir hatanın en basit ve en yaygın örneği, yeni bir kullanıcı ve geri dönen kullanıcı tanımıdır. Çoğu işletme, bu ayrımı Google Analytics ile aynı şekilde yapmaz. Bu nedenle, kullanıcı tipi tanımlarının mantığı genellikle farklı raporlarda tekrarlanır. Sık yapılan hatalar, anlaşılmaz rapor mantığını da içerir. İş müşterisinin rapora bakarken soracağı ilk şey, raporun nasıl oluşturulduğu, hangi varsayımlara dayandığı, verilerin neden kullanıldığı vb. olacaktır. Bu nedenle iş verilerinin hazırlanması kesinlikle atlamamanız gereken bir aşamadır. Ham verilerden veri marketi oluşturmak, sebze ve meyveleri yemeden önce yıkamamak gibidir.

Matrise göre sorumluluklar atarsak, veri hazırlama için şunu elde ederiz:

İş için hazır veriler, iş modeline karşılık gelen temizlenmiş bir nihai veri kümesidir. Herhangi bir veri görselleştirme servisine (Power BI, Tableau, Google Data Studio vb.) gönderilebilen hazır verilerdir.

Doğal olarak, farklı işletmeler farklı modellerle çalışır. Örneğin, “kullanıcılar”, “B2B kullanıcıları”, “işlemler, “potansiyeller” vb. tanımları farklı şirketler için farklı anlamlara gelecektir. Bu iş nesneleri, aslında bir işletmenin veri açısından iş modeli hakkında nasıl düşündüğü sorusuna yanıt verir. Bu, Google Analytics'teki olayların yapısı değil, işin özündeki bir açıklamadır.

Veri modeli, tüm çalışanların senkronize olmasına ve verilerin nasıl kullanıldığına ve bu konuda ne anlaşıldığına dair genel bir anlayışa sahip olmasına olanak tanır. Bu nedenle ham verileri iş için hazır verilere dönüştürmek, atlanamayacak kadar önemli bir aşamadır.

Bu aşamada ne yanlış gidebilir:

• Şirketin hangi veri modeline sahip olduğu/kullandığı net değil
• Simüle edilmiş verileri hazırlamak ve sürdürmek zor
• Dönüşüm mantığındaki değişiklikleri kontrol etmek zor

Burada, hangi veri modelini seçeceğinize ve veri dönüştürme mantığındaki değişiklikleri nasıl kontrol edeceğinize karar vermeniz gerekiyor. Buna göre, değişim sürecindeki katılımcıların rolleri şunlardır:

Paydaş artık sadece bilgilenmekle kalmıyor, aynı zamanda danışman oluyor. Yeni veya geri dönen bir kullanıcı olarak ne anlaşılması gerektiği gibi kararlar verirler. Bu aşamada analistin görevi, paydaşları bu kararların alınmasına mümkün olduğunca dahil etmektir. Aksi takdirde olabilecek en iyi şey, analistten raporu yeniden yapmasının istenmesidir.

Deneyimlerimize göre, bazı şirketler hala iş için hazır veriler hazırlamamakta ve ham veriler üzerinde raporlar oluşturmamaktadır. Bu yaklaşımla ilgili temel sorun, SQL sorgularının sonsuz hata ayıklaması ve yeniden yazılmasıdır. Uzun vadede, aynı şeyleri tekrar tekrar yaparak ham veriler arasında dolaşmak yerine hazırlanmış verilerle çalışmak daha ucuz ve daha kolaydır.

OWOX BI, farklı kaynaklardan ham verileri otomatik olarak toplar ve bunları rapor dostu bir formata dönüştürür. Sonuç olarak, pazarlamacılar için önemli olan nüanslar dikkate alınarak otomatik olarak istenen yapıya dönüştürülen hazır veri kümeleri alırsınız. Karmaşık dönüşümleri geliştirmek ve desteklemek için zaman harcamak, veri yapısını araştırmak ve tutarsızlıkların nedenlerini aramak için saatler harcamak zorunda kalmayacaksınız.

OWOX BI'nin iş verilerinin hazırlanmasına nasıl yardımcı olduğunu ve tam otomatik veri yönetiminden bugün nasıl yararlanabileceğinizi görmek için ücretsiz bir demo rezervasyonu yapın.

Bir sonraki aşama veri martının hazırlanmasıdır. Basitçe söylemek gerekirse, bu, belirli bir departmanın belirli kullanıcılarının ihtiyaç duyduğu kesin verileri içeren ve uygulamayı çok daha kolay hale getiren hazırlanmış bir tablodur.

Analistler neden bir data mart'a ihtiyaç duyar ve neden bu aşamayı atlamamalısınız? Analitik becerilere sahip olmayan pazarlamacılar ve diğer çalışanlar, ham verilerle çalışmayı zor buluyor. Analistin görevi, tüm çalışanların verilere en uygun biçimde erişimini sağlamaktır, böylece her seferinde karmaşık SQL sorguları yazmak zorunda kalmazlar.

Bir veri marketi bu sorunun çözülmesine yardımcı olur. Gerçekten de yetkin bir dolgu ile tam olarak belirli bir departmanın çalışması için gerekli olan veri dilimini içerecektir. Ve meslektaşlar böyle bir veritabanının nasıl kullanılacağını tam olarak bilecek ve içinde sunulan parametrelerin ve ölçümlerin bağlamını anlayacaklardır.

Data mart hazırlanırken bir şeylerin ters gidebileceği başlıca durumlar şunlardır:

• Veri birleştirme mantığı anlaşılmaz. Örneğin, bir mobil uygulamadan ve web sitesinden veriler olabilir ve bunları nasıl ve hangi tuşlarla birleştireceğinize veya bir mobil uygulamadaki etkinliklerle reklam kampanyalarını nasıl birleştireceğinize karar vermeniz gerekir. Bir sürü soru var. İş verilerini hazırlarken bu kararları alarak, onları bir kez alırız ve değerleri, burada ve şimdi belirli bir rapor için geçici olarak verilen kararlardan daha büyüktür. Bu tür geçici kararlar tekrar tekrar alınmalıdır.
• Veri ambarı teknik sınırlamaları nedeniyle bir SQL sorgusu çalışmıyor. İş verilerini hazırlamak, verileri temizlemenin ve sorguları işlemeyi ve hızlandırmayı daha ucuz hale getirecek simülasyonlu bir yapıya getirmenin bir yoludur.
• Veri kalitesinin nasıl kontrol edileceği açık değil .

Bakalım bu aşamada matrise göre kim nelerden sorumlu:

Verilerin hazırlanmasının, süreçte danışman olan paydaşlar ve veri mühendisleri ile birlikte veri analistlerinin sorumluluğunda olduğu açıktır. OWOX BI analistlerinin bu görevi sizin için halledebileceğini unutmayın. Verileri toplayabilir ve birleştirebilir, iş modeliniz için modelleyebilir ve gerekirse kendi tarafınızda değişiklik yapmanıza (örneğin yeni alanlar ekleme) olanak tanıyan, yapı mantığının açıklamasını içeren ayrıntılı talimatlar eşliğinde bir veri martı hazırlayabiliriz.

Raporlarda ve panolarda verilerin görsel olarak sunulması, her şeyin fiilen başlatıldığı son aşamadır. Açıkçası, veriler hem bilgilendirici hem de kullanıcı dostu bir şekilde sunulmalıdır. Otomatikleştirilmiş ve uygun şekilde yapılandırılmış görselleştirmelerin, risk bölgelerini, sorunları ve büyüme olanaklarını bulma süresini önemli ölçüde azalttığından bahsetmiyorum bile.

İşe hazır data ve data mart hazırladıysanız görselleştirmelerde zorluk çekmezsiniz. Bununla birlikte, aşağıdaki gibi hatalar da görünebilir:

• Veri pazarında alakasız veriler. Bir işletme veri kalitesinden emin değilse, veriler yüksek kalitede olsa bile, ticari müşteri için ilk adım, analistten her şeyi iki kez kontrol etmesini istemesidir. Bu verimsiz. İşletmenin hatalardan korunmak ve sonuca varmak için acele etmemek istediği açıktır. Bu nedenle, yüksek kaliteli veri, birisinin daha sonra kullanacağının garantisidir.
• Yanlış bir veri görselleştirme yöntemi seçme.
• Metrik ve parametre hesaplamalarının mantığını müşteriye doğru açıklamamak. Genellikle, SQL ve metriklerde yaşamayan bir iş müşterisinin verileri doğru bir şekilde yorumlaması için, her bir metriğin rapor bağlamında ne anlama geldiğini, nasıl hesaplandığını ve nedenini görmeleri gerekir. Analistler, raporu kullanan herkesin raporun arkasında ne olduğuna, raporun merkezinde hangi varsayımların yer aldığına vb. ilişkin bir açıklamaya erişmesi gerektiğini unutmamalıdır.

RACI matrisine göre, analist zaten ikili bir role sahiptir - onaylayıcı ve sorumlu . Paydaş burada bir danışmandır ve büyük olasılıkla hangi kararları almayı planladıkları ve hangi hipotezleri test etmek istedikleri sorusuna önceden cevap vermişlerdir. Bu hipotezler, analistin çalıştığı görselleştirmenin tasarımının temelini oluşturur.

RACI matrisi, verilerle çalışmakla ilgili olası tüm soruların cevabı değildir, ancak şirketinizde veri akışının uygulanmasını ve uygulanmasını kesinlikle kolaylaştırabilir.

Farklı rollerdeki kişiler veri akışının farklı aşamalarında yer aldığından, veri kalitesinden yalnızca analistin sorumlu olduğunu varsaymak yanlış olur. Veri kalitesi aynı zamanda veri işaretleme, dağıtım, hazırlama veya yönetim kararlarına dahil olan tüm meslektaşların sorumluluğundadır.

Tüm veriler her zaman kalitesizdir ve veri tutarsızlıklarından kalıcı olarak kurtulmak, verileri tutarlı hale getirmek ve gürültü ve tekrarlardan kurtulmak imkansızdır. Bu, özellikle pazarlama gibi hızlı ve dinamik olarak değişen bir veri gerçekliğinde her zaman olur. Ancak, bu sorunları proaktif olarak tespit edebilir ve veri kalitenizin bilinmesi için bir hedef belirleyebilirsiniz. Örneğin, şu soruların yanıtlarını alabilirsiniz: Veriler ne zaman güncellendi? Veriler hangi ayrıntı düzeyinde mevcut? Verilerdeki hangi hataları biliyoruz? ve Hangi metriklerle çalışabiliriz?

Şirketlerinin veri kalitesini iyileştirmeye katkıda bulunmak isteyenler için üç basit adım öneriyoruz:

1. Bir veri akışı şeması oluşturun. Örneğin, Miro'yu kullanın ve şirketinizin verileri nasıl kullandığını çizin. Bir şirkette bu şema hakkında kaç farklı görüş olduğuna şaşıracaksınız.
2. Bir sorumluluk matrisi oluşturun ve en azından kağıt üzerinde kimin neyden sorumlu olduğu konusunda anlaşın.
3. İş verisi modelini açıklayın.

Uzun yıllara dayanan uzmanlığa sahip olan OWOX BI ekibi, sorumlulukların nasıl dağıtılması gerektiğini ve analistlerin neye ihtiyaç duyduğunu bilir. Bu bilgilere dayanarak, analist ekipleri için bir sorumluluk tahsis matrisi şablonu hazırladık.

matrisi al

Ayrıca OWOX BI ekibi, bu makalede açıklanan tüm veri adımlarını yapılandırma ve otomatikleştirme konusunda size yardımcı olabilir. Bu görevlerden herhangi birinde yardıma ihtiyacınız varsa veya analitik ve veri kalitesi sisteminizi denetlemek istiyorsanız bir demo rezervasyonu yapın.

1. Karanlık Veri: Bilmediğiniz Şey Neden Önemlidir, David J. Hand
2. Sinyal ve Gürültü: Neden Pek Çok Tahmin Başarısız – Ama Bazıları Başarısız, Nate Silver
3. Dan Ariely tarafından Tahmin Edilebilir Bir Şekilde Mantıksız
4. Mantıksız Maymun: Neden Dezenformasyona, Komplo Teorisine ve Propagandaya Kanıyoruz David Robert Grimes
5. Antriksh Goel'den bir “Veri Ekosistemi” deneyimi