DataLakes i DataWarehouses: Jak są wykorzystywane w SEO
Opublikowany: 2021-02-16Choć koncepcje DataWarehouses i DataLakes już dawno weszły do codziennego języka analityków danych i Data Scientists, w innych branżach słyszymy o nich dopiero od kilku lat.
Na przykład analitycy sieci Web i eksperci SEO zaczynają poważnie przyglądać się tym koncepcjom ze względu na charakter ich pracy i silny związek między tym, co robią, a manipulacją danymi. Wiele ostatnich artykułów mówi o zainteresowaniu wdrożeniem SEO DataLake lub SEO DataWarehouse, traktując te dwa terminy jako wymienne i bez rozróżniania między nimi.
W tym artykule poprowadzimy Cię przez określenie różnic między DataLakes i DataWarehouses, aby zrozumieć ich cele i przypadki użycia w SEO i analityce internetowej.
DataWarehouse: uporządkowany magazyn danych
Pierwsze użycie terminu „DataWarehouse” datuje się na rok 1988 w artykule Paula Murphy'ego i Barry'ego Delvina, Architektura dla biznesu i systemów informatycznych . Ten artykuł daje nam pierwszą definicję pojęcia jako łatwo dostępnego, relacyjnego środowiska bazy danych, łączącego wszystkie dane biznesowe przydatne w podejmowaniu strategicznych decyzji.
Co zawiera DataWarehouse?
DataWarehouse służy do gromadzenia w jednym miejscu danych biznesowych przydatnych do podejmowania strategicznych decyzji dla firmy. Mówimy o danych biznesowych, które mogą obejmować wszystko, od danych klientów, przez informacje o asortymencie, po konwersje w komercyjnej witrynie internetowej lub bezpłatne wizyty (na przykład z wyszukiwarki, takiej jak Google).
Powszechnie przyjmuje się, że dane przesyłane do DataWarehouse są ustrukturyzowanymi, wstępnie przetworzonymi danymi używanymi do odciążania operacyjnych baz danych, co ostatecznie pozwala na jak najmniejsze wykorzystywanie tych operacyjnych baz danych do celów zapytania.
Głównym celem hurtowni danych i osób nią administrujących jest kompilacja danych z różnych, heterogenicznych źródeł (zarówno wewnętrznych, jak i zewnętrznych) w celu ich standaryzacji, tak aby różne źródła mogły się ze sobą komunikować. Ostatecznym celem jest wykorzystanie tych danych do przeprowadzania analiz, raportowania, wspomagania podejmowania decyzji itp.
Kim są codzienni użytkownicy DataWarehouse?
Ze względu na charakter DataWarehouse oraz format i rodzaj danych, które zawiera, jest idealnym miejscem zabaw dla analityków danych i sieci.
Data Analysts współpracuje z administratorem DataWarehouse (lub zespołem administracyjnym). Określają potrzeby biznesowe i przypadki użycia. Identyfikują źródła danych i działania potrzebne do przetworzenia danych w górę. Dane te będą następnie wykorzystywane przez analityków danych na końcu łańcucha.
Jak użytkownicy komunikują się z hurtownią danych?
Po zidentyfikowaniu źródeł danych oraz przetworzeniu, przetworzeniu i połączeniu danych w DataWarehouse, analityk danych może wykorzystać te dane w analizach i tworzeniu nowych kombinacji danych. Proces ten może być wykorzystany do utrzymywania kokpitów raportowania, kokpitów alarmowych itp.
Najczęściej używanym językiem programowania do wykonywania zapytań w DataWarehouse jest SQL (lub języki podobne do SQL). SQL pozwala analitykom danych manipulować i przetwarzać dane w celu zaspokojenia potrzeb biznesowych: monitorowania, podejmowania strategicznych decyzji itp.
Jakie przypadki użycia i typy projektów obsługują DataWarehouses?
Nie jest możliwe sporządzenie wyczerpującej listy przypadków użycia związanych z wykorzystaniem DataWarehouse. Oto kilka przykładów projektów, nad którymi prawdopodobnie będzie pracował analityk danych:
Ulepszenie hurtowni danych:
Ten rodzaj projektu jest często spotykany podczas tworzenia DataWarehouse, ale także w przypadku zidentyfikowania nowej potrzeby lub biznesowego przypadku użycia.
Chodzi tutaj o dodanie nowych danych do DWH (znowu mogą to być dane wewnętrzne lub zewnętrzne).
W tym przypadku często mówimy o procesie ETL (Extraction-Transformation-Loading):
- Ekstrakcja:
Pierwszy krok polegający na identyfikacji i zebraniu danych z różnych źródeł potrzebnych do dalszych działań. - Transformacja:
Ten drugi krok jest bardzo ważny, ponieważ bez dostosowania, bez standaryzacji, generalnie niemożliwe jest wykorzystanie nowych danych i nakłonienie ich do komunikacji z już istniejącymi w DWH.
Jest to zatem faza niezbędnej standaryzacji, która czasami może być skomplikowana przez sztywność narzuconą przez DWH w zakresie formatowania i schematu tabeli. - Ładowanie:
Faza przyswajania danych przetwarzanych (i w ten sposób ustrukturyzowanych) w DWH.
Realizacja analiz statystycznych:
Jest to bardzo częste zastosowanie DWH. Celem może być udowodnienie X lub Y na podstawie danych, stworzenie statystyk na podstawie dostępnych danych historycznych lub ustalenie powiązań przyczynowych w celu wyjaśnienia ustalenia itp.
Raportowanie i alerty:
Po raz kolejny jest to bardzo częsty przypadek użycia. W rzeczywistości, ponieważ dane w DWH są wysoce ustrukturyzowane i sformatowane (współdzielą stały i wstępnie zdefiniowany schemat), wszystko to nadaje się do przesyłania danych do paneli raportowania lub alarmowania.
To powtarzające się żądanie kierownictwa najwyższego szczebla, które musi być w stanie monitorować zespoły operacyjne oraz stan wyników, sprzedaży itp. w najprostszy i najszybszy możliwy sposób.
Podsumowując to wszystko, mamy mniej więcej 2 rodzaje projektów: projekty pozyskiwania i integracji danych (które można również porównać do formy przechowywania i historyzacji danych) oraz projekty analizy i oceny danych (poprzez monitorowanie/dashboarding i alertowanie ).
Pojęcie DWH od dawna jest obecne w codziennym języku tych, którzy pracują z danymi. Jak to działa i jego liczne przypadki użycia już dawno zostały potwierdzone, a DWH można znaleźć w wielu firmach o różnym stopniu dojrzałości, jeśli chodzi o kwestie zarządzania danymi.
W mniejszym stopniu dotyczy to koncepcji DataLakes, która jest znacznie młodsza i znacznie mniej rozpowszechniona.
Dane dotyczące indeksowania³
DataLake: jezioro megadanych (BigData)
Pochodzenie tej koncepcji przypisuje się Jamesowi Dixonowi, CTO w Penthao, który definiuje ją jako rozwiązanie do przechowywania i wykorzystywania dużych ilości danych, bez wstępnego przetwarzania i niekoniecznie określonego przypadku użycia… W przeciwieństwie do DWH, które są bardzo zorientowane w kierunku natychmiastowej aktywacji.
DL stara się wypełnić lukę, która jest coraz ważniejsza wraz z pojawieniem się BigData, co zrobić z całą tą masą danych, którą jesteśmy dzisiaj w stanie zebrać i jak to wykorzystać.
Co zawiera DataLake?
Zacznę od zacytowania Jamesa Dixona, który używa bardzo sugestywnego porównania, służącego zarówno jako wyjaśnienie nazwy „jeziora” jego koncepcji, jak i rozróżnienie z DWH:
„Jeśli myślisz o datamarcie jako o magazynie wody butelkowanej – oczyszczonej, zapakowanej i uporządkowanej w celu łatwego spożycia – jezioro danych to duży zbiornik wodny w bardziej naturalnym stanie. Zawartość jeziora danych napływa ze źródła, aby wypełnić jezioro, a różni użytkownicy jeziora mogą przychodzić, aby zbadać, zanurkować lub pobrać próbki”.
Cytat ten doskonale ilustruje różnicę między rodzajem danych zawartych w DWH, które są ustrukturyzowane i zorganizowane w postaci tabel z precyzyjnymi, stałymi wzorcami, a rodzajem danych zawartych w DataLake, które są surowe, bez wcześniejszego przetwarzania, dostępne do pobrania próbki w razie potrzeby, czy to eksploracyjne, czy nie.
Tam, gdzie DWH jest ograniczone do przechowywania danych strukturalnych, DataLake służy do przechowywania wszystkich rodzajów danych surowych (ustrukturyzowanych lub nie). Debata pomiędzy Tamarą Dull (Amazon Web Service) i Anne Buff (Microsoft SAS) daje nam nieco bardziej konkretną wizję zawartości DataLake:
„Jezioro danych to repozytorium pamięci masowej, które przechowuje ogromną ilość surowych danych w swoim natywnym formacie, w tym dane ustrukturyzowane, częściowo ustrukturyzowane i nieustrukturyzowane. Struktura danych i wymagania nie są zdefiniowane, dopóki dane nie są potrzebne.”
Kim są codzienni użytkownicy DataLakes?
Tam, gdzie analityk danych był doskonale przystosowany do pracy z ustrukturyzowanymi danymi zawartymi w CWU, surowe dane są zamiast tego specjalnością Data Scientists, którzy często są lepiej przygotowani do manipulowania tego typu danymi.
Ta zmiana w profilu danych i głównym użytkowniku skutkuje również różnymi językami programowania i przypadkami użycia.
Jakie przypadki użycia i typy projektów służą DataLakes?
Ze względu na swoją nieustrukturyzowaną naturę i znaczną ilość danych, które może zawierać DataLake, przypadki użycia mogą się bardzo różnić od tych, które wcześniej występowały w ramach DWH, na przykład:
- Implementacja algorytmów uczenia maszynowego w celu stworzenia wartości dodanej dla BigData:
Często mówimy tu o analizie predykcyjnej, opartej na algorytmach uczenia maszynowego wykorzystujących wszelkiego rodzaju dane.
Aby wziąć bardziej konkretny przykład, wyobraźmy sobie, że firma z sektora finansowego (bankowość i ubezpieczenia) chce określić prawdopodobieństwo, że transakcja finansowa X jest oszukańcza. Może to wymagać od Data Scientists, zdolnych do tworzenia algorytmów uczenia maszynowego, które będą szkolić się na astronomicznej ilości danych zawartych w DataLake (ilość, data, częstotliwość, typowy profil transakcji przeprowadzanych przez właściciela konta itp.). Celem jest przeprowadzenie badania predykcyjnego, które posłuży do identyfikacji potencjalnie nieuczciwych transakcji, a tym samym pozwoli firmie skrócić czas reakcji w ich wykryciu i ostatecznie uniknąć dużych strat dla nich i ich klientów.
To prosty przykład, który jest regularnie używany do zilustrowania zainteresowania i wartości dodanej uczenia maszynowego, ale jest ich tak wiele, jak możesz sobie wyobrazić. - DataLakes jako źródło danych dla DataWarehouse:
Po prostu DataLake może działać jako strefa tranzytowa między różnymi wewnętrznymi i zewnętrznymi źródłami danych a DWH. Samą zasadą DataLake jest centralizacja wszystkich rodzajów danych, ustrukturyzowanych lub nieustrukturyzowanych, w celu przeprowadzenia badań predykcyjnych za pomocą ML lub ekstrakcji jako próbek do analizy. Dlatego DWH wydaje się bardzo odpowiedni dla tej drugiej kategorii projektów i korzysta z DataLake jako potencjalnego źródła (pod warunkiem, że dane DataLake są importowane w ustrukturyzowany sposób poprzez wstępne przetwarzanie, jeśli to konieczne). - Od DataLake do oprogramowania BI (Business Intelligence):
Możemy to postrzegać jako zastosowanie podobne do tego, które widzieliśmy w przypadku DataWarehouses, chociaż istnieją pewne specyficzne cechy korzystania z DataLake do tego celu. DataLake pozwoli Ci tworzyć nieco bardziej egzotyczne wizualizacje (ze względu na różnorodność zawartych w nim danych) za pomocą narzędzi takich jak Tableau, Qlikview, Google Data Studio, Microstrategy itp.
Jak użytkownicy komunikują się z DataLake?
Biorąc pod uwagę przypadki użycia i użytkowników (Data Scientists), bardzo często znajdziemy języki programowania, takie jak Python, Java, R, Scala itp…
W większości języki te są obecne w dziedzinie nauki o danych od dłuższego czasu.
DataLake jest zatem narzędziem do zarządzania BigData. Opiera się na ogromnym przechowywaniu surowych danych do celów zaawansowanej analizy i wizualizacji, umożliwiając w ten sposób ulepszenie danych, które wcześniej nie były często wykorzystywane.
Podsumowując, oto tabela elementów różnicujących ustalona od początku tego artykułu:
Magazyn danych | DataJezioro | |
---|---|---|
Rodzaj danych | Ustrukturyzowane, wstępnie przetworzone dane, zorganizowane w tabele ze zdefiniowanymi schematami | Surowe dane, przechowywane w sposób ustrukturyzowany lub nieustrukturyzowany |
Użytkownicy | Analitycy danych, analitycy sieci Web | Naukowcy zajmujący się danymi (czasami analitycy danych) |
Ilość danych | Mały – Duży (W zależności od potrzeby i przypadku użycia) | Potencjalnie bardzo duży (Wielkie dane) |
Użyty język programowania | SQL lub podobny do SQL | Python, R, Java, Scala m.in. |
Rodzaj projektu | Projekty analityczne i statystyczne, raportowanie, alarmowanie, projekty typu ELT (eksport, transformacja, ładowanie), niektóre analizy predykcyjne i oparte na danych | Analiza predykcyjna, uczenie maszynowe, strefa tranzytu między źródłami danych a DWH, zaawansowana wizualizacja – BI, analiza sterowana danymi |
Analiza predykcyjna, uczenie maszynowe, strefa tranzytu między źródłami danych a DWH, zaawansowana wizualizacja – BI, analiza sterowana danymi
To właśnie te różnice sprawiają, że te dwie koncepcje są komplementarnymi narzędziami. W wielu przypadkach, w zależności od dojrzałości zarządzania firmą i zarządzania danymi, mogą polegać na połączeniu tych dwóch narzędzi.
DWH jest używany głównie do tradycyjnego raportowania i analizy, podczas gdy DataLake służy jako źródło danych przed osiągnięciem pełnego potencjału, gdy firma zbliża się do dojrzałości osób, których dane dotyczą.
Moim zdaniem DataLakes są bardziej odpowiedzią na nowe problemy z danymi w XXI wieku, zwłaszcza wraz z pojawieniem się BigData i rosnącą zdolnością firm do gromadzenia danych, niż zastąpieniem DWH, jak niektórzy mogą sądzić.
Oba mają swoje zalety, wady, mocne i słabe strony. Najlepszym sposobem na maksymalne wykorzystanie obu jest nadal używanie ich razem, aby móc poradzić sobie z każdą ewentualnością i odpowiedzieć na szerszą gamę potrzeb.
Teraz, gdy mamy już jasno określone pojęcia, w końcu skupimy się na wykorzystaniu DataWarehouses i DataLakes do marketingu, a dokładniej do SEO (nawet jeśli w wielu przypadkach to, co dotyczy pierwszego, będzie prawdziwe dla drugiego, i vice odwrotnie).
DataWarehouse i DataLake SEO
Porozmawiamy tutaj o DataWarehouse lub DataLake (lub o obu), w których przynajmniej część obecnych danych może być wykorzystana do zastosowań SEO.
Po co łączyć DataLakes i DataWarehouses z marketingiem i SEO?
SEO (i ogólniej marketing) już w ostatnich latach dokonało bardzo wyraźnego zwrotu w kierunku danych. Coraz więcej zadań wymaga korzystania z różnych źródeł danych:
- Dane analityczne (Google Analytics, AT internet itp.)
- Dane o wydajności (Google Search Console, Analytics)
- Dane dziennika, bardzo duże „źródło” danych dla niektórych witryn, które wymaga dużej częstotliwości aktualizacji i dużej pojemności pamięci.
- Dane dotyczące sieci (Majestic, Ahrefs, Babbar)
- Dane pozycjonujące (SEMRush, Monitorank itp.)
- Dane indeksowania (OnCrawl itp.)
- Czasami również dane biznesowe/branżowe
Do tej listy należy również dodać wykorzystanie API narzędzi takich jak Search Console, Majestic, Google Analytics, co w naturalny sposób popycha nas w kierunku rozwiązań opisanych wcześniej w tym artykule.
To właśnie ten silny związek między SEO a danymi popycha coraz więcej analityków internetowych i ekspertów SEO do poznawania nowych sposobów organizowania potoku danych.
Jednak czynniki decydujące o tym przejściu to nie tylko potencjał i wzajemne powiązania SEO i danych. Wiele codziennych przypadków użycia jest zgodnych z typami projektów wymienionymi powyżej dla DWH i DL.
Przypadki użycia SEO DataWarehouse lub SEO DataLake.
Najpierw zacznę od problemów, z którymi często spotykają się eksperci SEO, zanim wyjaśnię, w jaki sposób korzystanie z DataLake lub DataWarehouse jest odpowiedzią, którą należy wziąć pod uwagę podczas rozwiązywania tych problemów.
Wśród głównych punktów bólu wyróżniają się:
- Mnożenie plików Excela (kartka na luźne kartki naszej dekady) i związane z tym kopiowanie i wklejanie:
Dla wielu SEO to wciąż norma, ale bądźmy szczerzy, jest to zarówno czasochłonne, ograniczające, jak i bardzo sprzyja błędom ludzkim. W tym celu DataWarehouse jest idealnym rozwiązaniem. Magazyny danych nie tylko pozwalają na zebranie wszystkich wskaźników KPI wymaganych do przeprowadzenia tych lub innych audytów/analiz z różnych dostępnych źródeł danych, ale także umożliwiają zautomatyzowanie przetwarzania, które jest wymagane do osiągnięcia oczekiwanego rezultatu.
W miarę budowania DataWarehouse identyfikuje się coraz więcej przypadków użycia i rozwiązywanych jest coraz więcej problemów, co z czasem prowadzi do coraz większych oszczędności czasu. - Limity pojemności (przypominamy, że Excel może otworzyć cały plik tylko wtedy, gdy nie przekracza on 1 048 576 wierszy. Wydaje się, że to dużo, ale w rzeczywistości nie jest tak dużo w dzisiejszych woluminach): Tak naprawdę nie ma tu żadnego szczególnego przypadku użycia, ponieważ w ogólnie rzecz biorąc, zarówno DataLakes, jak i DataWarehouses nie cierpią z powodu tego rodzaju limitu. Oba oferują środki do żądania dużych ilości danych dla każdego rodzaju potrzeb. W tym konkretnym przypadku ważne jest, aby pamiętać, że w zależności od potrzeb, jedno lub drugie pozwoli ci uwolnić się od ograniczeń pojemności i ostatecznie łatwiej rozwiązać te sytuacje.
- Odpowiedz na potrzebę historii danych
Spoiler: jednym z przypadków użycia może być na przykład zapisanie historii danych z Google Search Console w SEO DataWarehouse, zamiast kopiowania i stronicowania ich danych w Arkuszach Google co tydzień w celu utrzymania dashboardu Data Studio. moim zdaniem mamy tutaj jeden z najczęstszych przypadków użycia wśród ekspertów SEO, zarówno w agencjach, jak i w firmie: historyzacja danych. Rzeczywiście, wielu analityków SEO patrzy na dane historyczne i wyciąga z nich wnioski.
Przykładem, który mógł bezpośrednio przyjść Ci do głowy, jest przypadek Google Search Console. Zapewnia dostęp tylko do 16-miesięcznej historii dzisiaj (nawet przez API). A jeśli ręczne zaległości nadal są możliwe dzięki eksportom, które należy wklejać do Arkuszy Google co tydzień (lub innymi niejasnymi metodami), jest to znaczna strata czasu, oprócz tego, że jest bolesna i nudna.
To dobrze, ponieważ jest to stosunkowo prosty problem do rozwiązania w DataWarehouse. Wszystko, co musisz zrobić, to skonfigurować automatyczne połączenie z interfejsem API Google Search Console, zdefiniować różne możliwe kombinacje przetwarzania wstępnego i danych potrzebne do uzyskania danych o rzeczywistej wartości dodanej, a na koniec zautomatyzować wywołania interfejsu API. - Chęć kontynuowania analiz, łączenia lub „analizy krzyżowej” danych indeksowania, danych odbiorców, dzienników itp. w sposób uprzemysłowiony.
Ponieważ niewielka przewaga konkurencyjna nigdy nie zaszkodzi. Podane przez nas opisy DataWarehouse i DataLake mówią same za siebie. Jednym z głównych celów obu narzędzi jest otwarcie nowych możliwości analizy poprzez zbieranie danych i analizę krzyżową i/lub uczenie maszynowe.
Przytoczę tylko jeden bardzo reprezentatywny przykład; wykorzystanie algorytmów uczenia maszynowego, takich jak Random Forest lub XG-Boost, do prognozowania rankingu w Google.
Mówiąc najprościej, chodzi o wytrenowanie algorytmu na dużej liczbie Google SERP (stron wyników) i wszystkich danych SEO możliwych do zebrania dla tych SERP, aby określić, na podstawie tych samych wskaźników, potencjał rankingowy danego adresu URL (i w związku z tym, jeszcze bardziej szczegółowo, w celu określenia najważniejszych wskaźników do sklasyfikowania w określonym sektorze/temacie).
→ Pełną metodologię znajdziesz w artykule Vincenta Terrasiego, dyrektora produktu w Oncrawl, „Successfully predicting Google rankings at the edge of data science” , 2018. - Chęć jak największej automatyzacji raportowania, aby skoncentrować się na zadaniach o wysokiej wartości dodanej. Ponownie wpisuje się to dosłownie w klasyczne przypadki użycia DataWarehouse. Oferuje możliwość zautomatyzowania całego odzyskiwania i przetwarzania różnych źródeł danych i doskonale rozwiązuje ten problem. Po skonfigurowaniu tabela zostanie automatycznie pobrana do DWH i może być używana jako połączenie z oprogramowaniem BI do tworzenia pulpitów nawigacyjnych, monitorowania, alarmowania itp. Oczywiście automatyzacja nie kończy się na samym raportowaniu projektów. Zarówno DWH, jak i DL mogą być używane do wielu automatycznych optymalizacji SEO. Na przykład dynamiczne aktualizacje wewnętrznych bloków linków według pozycji, budżetu indeksowania, odbiorców SEO itp. (wszystkie dane zawarte w DWH).
- Chęć położenia kresu raz na zawsze obawom o bezpieczeństwo (wiemy, kto co zrobił i gdzie je znaleźć) i unikanie spędzania czasu na konserwacji. Kończymy tutaj bardziej zorientowany na proces aspekt niż przypadek użycia, ściśle mówiąc.
Zarówno DataLakes, jak i DataWarehouses zakładają realizację poszczególnych procesów, które można przedstawić w następujący uproszczony sposób:- Punktem wyjścia jest obserwacja rozbita na zestawienie potrzeb (zespół biznesowy / SEO – Data Analyst).
- Następnie jest to przekształcane w bardziej techniczną specyfikację, która pozwoli zespołowi administrującemu narzędziem zrozumieć, co należy zrobić i jak to zrobić.
- Ten sam zespół administracyjny realizuje żądanie.
- Zespół biznesowy i analitycy danych opracowują proceduralny przypadek użycia dla wykonanej pracy.
- Trwa proces, w którym dwa końce łańcucha (zespół biznesowy i zespół administracyjny DataWarehouse lub DataLake) upewniają się, że nic się nie zmienia pod względem wejścia i wyjścia.
Dotyczy to szczególnie przypadku DWH, który odrzuca wszelkie dane, które nie są częścią struktury (predefiniowany schemat).
Ponownie, jest to niewyczerpująca lista problemów i możliwych przypadków użycia DataWarehouse – DataLake SEO. Ograniczenia napotykamy bardziej w braku wyobraźni tych, którzy z nich korzystają, niż w samych narzędziach.
Wybór DataWarehouse lub DataLake do zastosowań SEO
Podsumowując, w przeciwieństwie do tego, co często słyszysz lub czytasz, DataWarehouses i DataLakes są oddzielnymi strukturami przechowywania i gromadzenia danych i nie są niezgodne. Nie ma potrzeby wybierania jednego nad drugim, wręcz przeciwnie. Oba mają różne przypadki użycia, a nawet są pewne zrosty.
Przypadek SEO jest wymownym przykładem i wzmacnia ogólne zapotrzebowanie na magazyny danych i jeziora danych. Dane są wszechobecne w SEO: musimy manipulować ogromnymi ilościami danych z różnych źródeł. Nic więc dziwnego, że w tym kontekście mówimy o magazynach danych i jeziorach danych. Możemy sobie wyobrazić wiele przypadków użycia DataWarehouse lub DataLakes w SEO, niezależnie od tego, czy jest to automatyzacja, przeprowadzanie „rozszerzonej” analizy na podstawie danych, czy po prostu rozwiązywanie powtarzających się problemów (bolesnych punktów).