Jak raport ginie w rzeczywistości

Zanim wybierzesz sposób zabezpieczenia, warto wiedzieć, przed czym się bronisz. Z mojego doświadczenia scenariusze są cztery i każdy wymaga innego zabezpieczenia.

• Cudza edycja. Ktoś z prawem do edycji przesuwa element, zmienia filtr albo podmienia metrykę na wykresie. Raport działa, tylko pokazuje inne liczby, i przez tydzień nikt tego nie łapie.

• Zmiana w źródle. Ktoś zmienia nazwę kolumny w arkuszu, usuwa wymiar własny w analityce albo przebudowuje tabelę. Wykresy pokazują błąd konfiguracji pola.

• Utrata dostępu. Osoba, która była właścicielem pliku, odchodzi z firmy i jej konto zostaje wyłączone.

• Usunięcie. Ktoś porządkuje Dysk i wyrzuca raport albo — częściej — plik źródłowy, o którym nikt nie pamiętał, że jest podstawą pulpitu.

Tylko pierwszy z tych scenariuszy da się odkręcić w samej usłudze. Pozostałe trzy wymagają czegoś, co zrobisz zawczasu.

Historia wersji — co obejmuje, a czego nie

Looker Studio prowadzi historię zmian raportu i pozwala wrócić do wcześniejszej wersji. Znajduje się to w menu Plik, w pozycji dotyczącej historii wersji. Można też zapisać wersję ręcznie i — to jest ważne — nadać jej nazwę.

Nazywanie wersji to jedyna rzecz, która czyni tę funkcję używalną. Lista automatycznych zapisów opisanych wyłącznie datą i godziną jest przy większym pulpicie nieczytelna. Zanim wprowadzę większą zmianę, zapisuję wersję i podpisuję ją tak, żeby dwa miesiące później dało się ją rozpoznać.

Trzeba jednak wiedzieć, gdzie ta funkcja się kończy. Historia wersji dotyczy raportu, a nie źródeł danych — te mają własną, oddzielną historię, więc przywrócenie starego układu raportu nie cofa zmian w źródle. Nie chroni też przed usunięciem samego pliku: kasując raport, kasujesz jego historię.

I rzecz najistotniejsza w praktyce: historia jest funkcją wewnątrz usługi. Jeśli tracisz dostęp do konta albo do pliku, tracisz razem z nim całą historię.

Kopia jako właściwa kopia zapasowa

Dlatego podstawą zabezpieczenia jest zwykłe, ręczne kopiowanie. Nudne i skuteczne.

Raz w miesiącu i przed każdą większą przebudową wykonuję kopię raportu przez polecenie tworzenia kopii. W nazwie umieszczam datę zapisaną od roku do dnia, żeby kopie układały się chronologicznie po zwykłym posortowaniu alfabetycznym. Kopie trzymam w osobnym folderze na Dysku, nazwanym w sposób, który zniechęca do porządków.

Przy kopiowaniu Looker Studio pyta o źródła danych i to jest moment, w którym łatwo zrobić sobie krzywdę. Jeśli w kopii wskażę te same, żywe źródła, to zmiana w źródle zepsuje jednocześnie oryginał i wszystkie kopie. Dla pulpitów krytycznych robię więc kopię z osobnymi, skopiowanymi źródłami — działa niezależnie i jest droższa w utrzymaniu, ale to jedyna wersja, która przetrwa przebudowę po stronie danych.

Kopia ma jeszcze jedno zastosowanie, z którego korzystam częściej niż z odzyskiwania: to poligon. Wszystkie eksperymenty z układem robię na kopii, a do oryginału przenoszę tylko rozwiązania gotowe.

Źródła danych to osobny byt

Najczęstszy błąd, jaki widzę w pulpitach po innych wykonawcach, dotyczy nie raportu, a właśnie źródeł.

Źródło danych w Looker Studio jest samodzielnym obiektem z własnym właścicielem, uprawnieniami i sposobem uwierzytelniania. Jeżeli zostało utworzone na czyichś prywatnych poświadczeniach, to raport przestanie działać w dniu, w którym ta osoba straci dostęp do konta analityki albo do reklam — niezależnie od tego, ile kopii raportu zrobiłeś.

Dlatego przy przejęciu pulpitu przechodzę wszystkie źródła po kolei i sprawdzam trzy rzeczy: kto jest właścicielem, w jakim trybie uwierzytelniania działa połączenie i czy nie jest to źródło osadzone wyłącznie w tym jednym raporcie. Źródła osadzone są wygodne przy tworzeniu i bardzo niewygodne później, bo nie da się ich użyć nigdzie indziej ani łatwo skopiować.

Pola wyliczane opisuję osobno. Formuła w źródle danych to kawałek logiki biznesowej, który przy odtwarzaniu raportu z pamięci odtworzy się najgorzej. Trzymam ich zestawienie w tym samym dokumencie, w którym opisuję cały pulpit.

Uprawnienia i własność pliku

To element, przy którym najłatwiej zapobiec problemowi, i najczęściej pominięty.

Właścicielem raportu i źródeł powinno być konto firmowe klienta albo konto należące do zespołu, nie osoba fizyczna. Jeżeli pulpit tworzę na koncie agencyjnym, ustalam z klientem od początku, że przy zakończeniu współpracy przekazujemy własność — i zapisuję to w notatce z ustaleń, żeby nie było później rozmowy o tym, kto co pamięta.

Prawa do edycji ograniczam do jak najmniejszej grupy. Odbiorcy raportu potrzebują podglądu, nie edycji, a ryzyko przypadkowej zmiany jest wprost proporcjonalne do liczby osób z uprawnieniem do edytowania. Osoby, które chcą własnych przekrojów, dostają swoją kopię — to lepsze rozwiązanie niż wpuszczanie ich do wersji produkcyjnej.

Warto też pamiętać, że raport usunięty trafia najpierw do kosza i przez pewien czas da się go odzyskać. To jednak okno o ograniczonej długości i nie należy na nim budować planu awaryjnego.

Dokumentacja i procedura, którą stosuję

Ostatnia warstwa to opis, bez którego kopia bywa bezużyteczna, bo nikt nie wie, co dokładnie odtwarzać.

Dla każdego utrzymywanego pulpitu prowadzę jedną stronę notatek: do czego służy i kto go czyta, lista stron raportu z opisem w jednym zdaniu, lista źródeł z właścicielem i trybem uwierzytelniania, zestawienie pól wyliczanych, znane ograniczenia i to, czego raport nie pokazuje. Ten ostatni punkt bywa najcenniejszy, bo chroni przed wnioskami wyciąganymi z danych, których w pulpicie nie ma.

Rytm pracy wygląda tak. Kopia miesięczna po zamknięciu miesiąca, razem z zapisem eksportu danych. Nazwana wersja przed każdą większą zmianą. Kwartalny przegląd uprawnień i właścicieli. I raz w roku test, którego nikt nie lubi robić: otwieram najstarszą kopię i sprawdzam, czy w ogóle się ładuje.

Ten test wykrył u mnie już dwa razy sytuację, w której kopie były, ale wszystkie wskazywały na źródło, którego już nie było. Kopia, której nikt nigdy nie odtworzył, jest wyłącznie deklaracją.