Dlaczego warto pobierać dane z sieci i automatycznie je odświeżać
Cel jest prosty: raz zbudować proces, który bez zbędnego klikania pobiera z internetu dane do Excela lub Power BI i dba o ich aktualność. Zamiast co tydzień czy codziennie logować się do serwisu, eksportować plik i wklejać go ręcznie, wystarczy odświeżenie zapytania lub dobrze ustawiony harmonogram.
Najczęstsze scenariusze użycia danych z sieci
Najwięcej czasu uciekają drobne, powtarzalne zadania. Do tych zadań Power Query nadaje się szczególnie dobrze. Typowe przypadki:
Raporty kursów walut – pobieranie tabel z NBP, EBC lub innych serwisów finansowych, codzienna aktualizacja przeliczeń.
Ceny produktów z e‑sklepów – monitorowanie własnych cenników publikowanych w WWW lub cen konkurencji tam, gdzie jest to możliwe technicznie i prawnie.
Statystyki z paneli www – sprzedaż dzienna z systemu SaaS, liczba zgłoszeń w systemie ticketowym, dane z narzędzi marketingowych.
Dane z systemów online – CRM, systemy rezerwacji, systemy flotowe, aplikacje branżowe, które udostępniają eksport przez link lub proste API.
W każdym z tych scenariuszy ręczny eksport oznacza kilka do kilkunastu minut klikania przy każdym odświeżeniu. Jeśli raport jest potrzebny często, rośnie to w godziny w skali miesiąca.
Ręczny eksport vs Power Query: poziomy automatyzacji
Można wyróżnić trzy praktyczne poziomy pracy z danymi z sieci:
Ręczny eksport – logujesz się, klikasz „Eksportuj do Excel/CSV”, zapisujesz plik, wklejasz dane do raportu. Zero przygotowań, ale pełna zależność od człowieka.
Power Query z przyciskiem „Odśwież” – raz konfigurujesz zapytanie z sieci, czyścisz dane, budujesz raport. Później wymaga to wyłącznie kliku „Odśwież wszystko” w Excelu lub odświeżenia w Power BI Desktop.
Pełna automatyzacja odświeżania – w Power BI Service (chmura) ustawiasz harmonogram odświeżania; w Excelu używasz odświeżania przy otwarciu pliku lub dodatkowych mechanizmów (np. zadania systemowe, VBA, Power Automate). Efekt: raport sam się aktualizuje, często bez udziału użytkownika.
Najlepszy zwrot z czasu przygotowania daje często poziom drugi: ręczne odświeżanie jednym przyciskiem. Jest łatwiejszy w konfiguracji i nie wymaga dodatkowych usług. Dopiero przy raportach używanych przez wiele osób lub takich, które muszą być stale aktualne, uzasadnia się pełny harmonogram odświeżania.
Kiedy automatyzacja ma sens, a kiedy nie ma co przesadzać
Nie każde źródło danych z internetu opłaca się podpinać pod Power Query. Opłacalność da się wstępnie ocenić kilkoma prostymi pytaniami:
Jak często korzystasz z danych? Jeśli raz na kwartał – prosty ręczny eksport może wystarczyć.
Ile czasu zajmuje ręczne pobranie? Jeśli kilka sekund i jedno kliknięcie – automatyzacja da mały zwrot.
Czy struktura danych jest stabilna? Przy serwisach, które ciągle zmieniają wygląd, integracja może się psuć i wymagać częstych poprawek.
Czy źródło ma plik lub API? Jeśli trzeba „skrobać” złożone strony z dynamicznym JavaScriptem, nakład pracy bywa nieadekwatny.
Praktyczna reguła: jeśli na pobieranie i obróbkę tych samych danych z sieci schodzi co najmniej kilkanaście minut tygodniowo, a struktura źródła jest w miarę stabilna – inwestycja w porządne zapytanie Power Query i automatyzację zwykle szybko się zwraca.
Podstawy wczytywania danych z sieci w Power Query (Excel, Power BI)
Aby wykorzystać Power Query z sieci, najpierw trzeba wiedzieć, gdzie szukać odpowiednich opcji oraz z jakimi typami adresów URL da się pracować najtaniej „czasowo”.
Gdzie szukać opcji „Z sieci” / „From Web”
W Excelu i Power BI Desktop punkt startowy jest podobny, choć menu wygląda nieco inaczej.
Excel (nowe Power Query / Pobieranie i przekształcanie danych)
W Excelu (wersje z Power Query na karcie Dane) podstawowa ścieżka jest następująca:
Karta Dane.
Grupa Pobieranie i przekształcanie danych.
Przycisk Pobierz dane > Z innych źródeł > Z sieci.
W starszych wersjach Excela z dodatkiem Power Query (osobna karta „Power Query”) nazwy przycisków mogą się minimalnie różnić, ale mechanizm pozostaje taki sam: wybierasz połączenie From Web / Z sieci, wklejasz adres URL i przechodzisz do kreatora.
Power BI Desktop
W Power BI Desktop ścieżka jest uproszczona:
Karta Home / Strona główna.
Przycisk Get data / Pobierz dane.
Wybór kategorii Other lub Inne i źródła Web / Sieć.
Następnie pojawia się okno, w którym wklejasz adres URL oraz ewentualnie określasz tryb autoryzacji (anonimowy, podstawowy, OAuth i inne).
Typy adresów URL obsługiwanych przez Power Query
Power Query nie ma „magii” – pobiera to, co udostępni serwer pod wskazanym adresem. Najczęściej spotykane typy URL:
Zwykła strona HTML – klasyczna strona WWW z nagłówkiem, menu, tabelami, tekstem. Power Query stara się rozpoznać tabele i elementy strukturalne.
Bezpośredni link do pliku – adres prowadzący do pliku CSV, XLSX, JSON, XML lub innego formatu (np. .txt). To zwykle najbardziej stabilny scenariusz.
Adres API – URL zwracający dane w formacie JSON lub XML, często z parametrami w zapytaniu (np. ?date=2024-01-01&id=123).
Im bliżej jesteś „gołego” pliku lub API, tym mniej problemów z layoutem strony, zmianami wyglądu i zbędnymi elementami. W praktyce, jeśli serwis oferuje zarówno tabelę na stronie HTML, jak i link „Pobierz CSV”, zawsze lepiej podpiąć się bezpośrednio do CSV.
Prosty proces wczytywania danych z adresu URL
Wersja „na start” jest bardzo podobna niezależnie od rodzaju źródła:
Skopiuj adres URL z przeglądarki lub z panelu.
W Excelu / Power BI wybierz Z sieci / Web.
Wklej adres URL do pola Adres.
Wybierz rodzaj uwierzytelnienia (anonimowe lub inne, jeśli źródło jest zabezpieczone).
Po połączeniu wyświetli się Nawigator – lista wykrytych tabel (HTML) lub struktura pliku (CSV, JSON itd.).
Zaznacz interesującą tabelę lub dokument główny.
Wybierz Przekształć dane, aby otworzyć Edytor Power Query i wyczyścić dane.
Po zakończeniu wybierz Zamknij i załaduj, by przesłać dane do Excela lub modelu w Power BI.
Ten prosty schemat wystarcza do większości podstawowych integracji i już na tym etapie pozwala na odświeżanie danych jednym kliknięciem.
Praktyczne różnice między Power Query w Excelu a Power BI
Silnik M i interfejs Edytora zapytań w obu narzędziach są bardzo podobne, ale różnice wpływają na decyzję, gdzie budować automatyzację:
Aspekt
Power Query w Excelu
Power Query w Power BI Desktop
Docelowe miejsce danych
Arkusz Excela lub model danych w skoroszycie
Model danych raportu Power BI
Udostępnianie
Wysyłka pliku, OneDrive, SharePoint
Publikacja do Power BI Service, raport online
Automatyczne odświeżanie
Przy otwieraniu, makra, narzędzia zewnętrzne
Harmonogram w Power BI Service, bez makr
Skalowalność
Dobra dla mniejszych zestawów, zależna od Excela
Lepsza przy dużych modelach i wielu użytkownikach
Jeśli raport ma służyć jednej osobie lub małemu zespołowi, a dane są raczej małe – Excel będzie prostszym i tańszym rozwiązaniem. Gdy jednak wymagana jest dystrybucja do wielu odbiorców, wygodne dostępy online i centralne odświeżanie – sensownie jest przejść do Power BI.
Źródło: Pexels | Autor: Negative Space
Rodzaje źródeł internetowych i co z nich „da się wycisnąć”
Nie każde źródło internetowe da się bezboleśnie zasilić do Power Query. Dobrze jest szybko ocenić, z czym ma się do czynienia i co będzie wymagane, aby dane nadawały się do automatycznego odświeżania.
Strony HTML z tabelami
Najbardziej klasyczny przypadek to strona WWW z tabelą z danymi: kursami walut, listą produktów, zestawieniem rankingowym. Power Query potrafi:
automatycznie wykryć tabele w kodzie HTML,
odróżnić je od innych elementów jak nawigacja czy stopka,
zbudować zapytanie bez ręcznego pisania kodu M.
Jeśli tabela jest prosta, bez zagnieżdżonych struktur i wielopoziomowych nagłówków, zwykle wystarczy wybrać odpowiednią pozycję (Table 0, Table 1 itd.) w Nawigatorze. Przy bardziej rozbudowanych stronach trzeba czasem trochę poszukać właściwego elementu i odfiltrować śmieci.
Pliki w chmurze z publicznym lub półpublicznym linkiem
Często wygodniej jest pobierać dane nie ze strony HTML, ale z pliku umieszczonego w chmurze:
CSV z systemu sprzedażowego, udostępniony poprzez link „pobierz raport”,
plik Excel z serwisu branżowego, aktualizowany raz dziennie,
JSON z serwisu statystycznego, dostępny po podaniu adresu z parametrami.
Takie pliki mogą być:
publiczne – dostępne bez logowania, każdy z linkiem może pobrać,
półpubliczne – dostępne po zalogowaniu się w przeglądarce, ale z linkiem, który nie wymaga sesji,
chronione – wymagające uwierzytelnienia, np. podstawowego HTTP, tokenu lub OAuth.
Im bardziej „techniczny” link (bez przekierowań, prosty adres do pliku), tym prostsza integracja i mniejsza szansa, że coś się po drodze zepsuje.
Proste API z parametrami
Coraz więcej systemów oferuje lekkie API HTTP, w którym dane można pobrać, podając parametry w adresie URL. Najczęstszy przypadek to:
adres bazowy (np. https://api.serwis.pl/dane),
parametry zapytania (np. ?date=2024-04-01&product=ABC),
autoryzacja przez klucz API w nagłówku lub parametrze.
Power Query bardzo dobrze radzi sobie z JSON i XML zwracanym z API, pod warunkiem że znamy:
strukturę zwracanych danych (jakie pola są w odpowiedzi),
limit zapytań (często API ma ograniczenia na liczbę wywołań w czasie),
zasady uwierzytelniania (gdzie podać klucz, jak odświeżać token).
API to najstabilniejsze źródło, jeśli jest udokumentowane i wspierane – layout strony się nie zmienia, nazwy pól są bardziej przewidywalne niż struktura tabel HTML.
Portale z wymogiem logowania i dynamiczny JavaScript
Tu zaczynają się kłopoty. Wiele nowoczesnych serwisów działa tak, że:
strona ładuje się jako „pusta ramka” HTML,
dane dociągane są dopiero przez JavaScript po stronie przeglądarki,
wymagana jest aktywna sesja logowania.
Power Query nie uruchamia JavaScript – widzi tylko surowy HTML zwrócony przez serwer. Jeśli dane są ładowane dopiero poprzez skrypty w przeglądarce, w oknie Nawigatora nie pojawią się sensowne tabele.
W praktyce można próbować:
poszukać w narzędziach deweloperskich (F12 w przeglądarce) zapytań sieciowych, które zwracają JSON/CSV – często to właśnie te adresy da się wykorzystać w Power Query,
upewnić się, czy system nie oferuje dedykowanego API raportowego,
Gdy Power Query „nie widzi” danych na stronie
Zdarza się, że na ekranie w przeglądarce widzisz piękną tabelę, a w Nawigatorze Power Query – pustka albo kilka dziwnych fragmentów HTML bez danych. Najczęściej przyczyną jest właśnie JavaScript lub nietypowa struktura strony.
Praktyczny test: skopiuj adres URL, wklej do Power Query i sprawdź, co pokazuje się w Nawigatorze. Jeśli zamiast tabel widzisz tylko pojedynczą pozycję typu „Document” lub kilka losowych „Table 0 / Table 1” bez zawartości, trzeba zejść poziom niżej – do ruchu sieciowego.
Najprostsza ścieżka diagnostyczna w przeglądarce:
Otwórz stronę z danymi.
Wciśnij F12, przejdź do zakładki Network / Sieć.
Przefiltruj listę żądań po typach XHR, Fetch lub po rozszerzeniach .json, .csv.
Odśwież stronę i obserwuj, jakie adresy zwracają dane w czytelnym formacie.
Często okaże się, że ta tabelka w przeglądarce to tak naprawdę wynik wywołania jednego lub kilku URL-i zwracających JSON. Wtedy cała integracja z Power Query polega na wykorzystaniu tych adresów zamiast „głównej” strony HTML – dużo stabilniejsze i mniej podatne na zmiany wyglądu.
Jeśli serwis wymaga logowania, dochodzi jeszcze kwestia uwierzytelniania. Przy prostych mechanizmach (Basic, token w nagłówku) Power Query sobie poradzi. Gdy serwis używa złożonej sesji przeglądarkowej, logowania wieloskładnikowego czy SSO, może się okazać, że taniej i szybciej będzie:
skorzystać z wbudowanych eksportów do plików i pobierać CSV/XLSX,
zlecić administratorowi wystawienie prostego API raportowego,
albo przerzucić integrację do systemu pośredniego (np. skrypt w chmurze, który zapisuje codzienny plik na SharePoint).
Wczytywanie tabel z klasycznych stron WWW (HTML)
Gdy strona jest „starej daty”, bez SPA i ciężkiego JavaScriptu, Power Query radzi sobie z nią bardzo sprawnie. To dobry punkt startowy przy raportach kursów walut, wskaźników rynkowych czy prostych rankingów.
Identyfikacja właściwej tabeli w Nawigatorze
Po podaniu adresu HTML Power Query skanuje dokument i wyciąga wszystkie znalezione tabele. W Nawigatorze zwykle pojawia się lista typu Table 0, Table 1, ale też czasem elementy nazwane po ID lub klasie z kodu HTML.
Szybki sposób na wybranie właściwej:
zaznacz pierwszą tabelę i spójrz na podgląd – jeśli kolumny lub nagłówki wyglądają znajomo, jesteś w domu,
jeśli widzisz menu, stopkę lub fragmenty layoutu, przejdź do kolejnej pozycji,
gdy struktur jest dużo, łatwiej wybrać jedną, załadować do Edytora i tam usuwać zbędne wiersze (nawigacja, reklamy) niż próbować zgadywać w Nawigatorze.
Na tym etapie celem nie jest idealnie „czysta” tabela, tylko złapanie najbogatszej struktury z interesującymi danymi. Oczyszczanie przychodzi chwilę później.
Czyszczenie tabeli HTML po wczytaniu
Średnio dopracowana strona dorzuca w tabeli różne śmieci: scalone komórki, dodatkowe wiersze tytułowe, puste rekordy. Kilka prostych kroków w Edytorze Power Query rozwiązuje większość przypadków:
Promuj pierwszy wiersz do nagłówków – przycisk Użyj pierwszego wiersza jako nagłówków.
Usuń puste kolumny i wiersze – filtr na wartość null lub polecenia Usuń puste.
Zmień typy danych – daty na Date, liczby na Decimal/Whole Number.
Jeśli tabela ma wielopoziomowe nagłówki (np. dwa pierwsze wiersze to grupy kolumn), opłaca się czasem ręcznie zbudować nagłówki:
Skopiować właściwe nazwy do jednego wiersza (funkcje łączenia tekstu, Merge Columns).
Potem dopiero użyć opcji Użyj pierwszego wiersza jako nagłówków.
Tego typu „razowe” dopieszczenie tabeli kosztuje kilka minut, a potem działa przy każdym odświeżeniu bez udziału użytkownika, więc bilans czasu jest na plus.
Stałe vs zmienne fragmenty strony
Niektóre serwisy lubią drobne modyfikacje layoutu – przesuną baner, dołożą wiersz z reklamą w środku tabeli. Dla człowieka to kosmetyka, dla Power Query czasem zmiana struktury.
Przy delikatnych stronach można się podeprzeć prostymi „bezpiecznikami” w zapytaniu:
filtrować tylko wiersze z numerem w pierwszej kolumnie,
wybierać kolumny po nazwie, nie po pozycji,
sprawdzać, czy kluczowa kolumna nie jest pusta, i odrzucać takie wiersze.
Chodzi o to, żeby pojedyncza zmiana dekoracyjna na stronie nie rozwalała całego odświeżania. Kilka dodatkowych kroków filtrowania w Power Query jest zwykle tańsze niż ręczne poprawki po każdym liftingu portalu.
Źródło: Pexels | Autor: ThisIsEngineering
Pobieranie plików z internetu: CSV, Excel, JSON i inne formaty
Bezpośredni link do pliku to najbardziej „budżetowy” sposób integracji: mało kroków, mało ryzyk, a odświeżanie zwykle działa bezboleśnie przez długie miesiące.
Łączenie się z plikami CSV
CSV to najczęstszy format eksportów z systemów online. W Power Query obsługa jest bardzo prosta:
Źródło Web / Z sieci.
Adres URL prowadzący bezpośrednio do pliku .csv.
Power Query sam wybiera konektor tekstowy i od razu proponuje podgląd.
Czasem trzeba jeszcze ręcznie ustawić:
separator (przecinek, średnik, tabulator),
kodowanie (rzadziej, ale przy polskich znakach potrafi się przydać),
czy pierwszy wiersz zawiera nagłówki.
Jeśli pod tym samym adresem serwis codziennie nadpisuje nowy plik, wystarczy jedno zapytanie – po odświeżeniu zawsze pobierana jest aktualna wersja. To idealny układ z perspektywy utrzymania: raz ustawiasz, a potem tylko korzystasz.
Pliki Excel z sieci
Gdy serwis udostępnia gotowy skoroszyt XLSX, Power Query po połączeniu pokaże w Nawigatorze:
zakresy nazwane,
arkusze,
tabele Excela (jeśli są zdefiniowane).
Najwygodniej korzystać z tabel zdefiniowanych w pliku – są stabilniejsze niż „gołe” arkusze pełne formatowań. Jeśli jednak plik jest obcy i nie masz wpływu na jego strukturę, w praktyce:
wybierz odpowiedni arkusz,
usuń w Power Query wiersze tytułowe, logotypy, stopki,
ustaw nagłówki i typy danych.
Przy plikach Excel dochodzi tylko jedno ryzyko: ktoś w serwisie zmieni nazwę arkusza albo układ kolumn. Na to nie ma złotego środka, ale znów – kilka inteligentnych filtrów w zapytaniu potrafi wyłapać większość takich subtelnych zmian.
JSON i XML – gdy plik jest „pół-API”
Część serwisów nie mówi wprost „to jest API”, tylko po prostu udostępnia adres zwracający JSON lub XML. Dla Power Query to bez różnicy – źródło jest obsługiwane tak samo jak oficjalne API.
Po wczytaniu JSON możesz:
rozwinąć rekord główny do kolumn,
rozwinąć listy do wierszy (ikona z dwiema strzałkami obok nagłówka),
stopniowo „spłaszczać” strukturę, aż uzyskasz normalną tabelę.
Jeden raz trzeba przejść tę ścieżkę ręcznie, klikając rozwijanie kolejnych poziomów. Każdy krok jest zapamiętywany jako transformacja, więc przy odświeżeniu cała „wycieczka” po strukturze JSON powtarza się automatycznie.
Foldery i „wersjonowane” pliki na serwerze
Niektóre serwisy udostępniają katalog z plikami, np. raporty dzienne nazwane wg daty. Wtedy zamiast jednego adresu do pliku mamy stały adres do katalogu i zmieniające się nazwy plików.
Power Query radzi sobie z tym scenariuszem, jeśli serwer pozwala na listowanie zawartości (typowe w prostych serwerach HTTP lub na SharePoint/OneDrive). Krok po kroku:
Połącz się ze ścieżką katalogu.
W Power Query otrzymasz tabelę z listą plików (nazwy, daty modyfikacji, rozmiary).
Przefiltruj pliki, które chcesz pobierać (np. po prefiksie w nazwie).
Rozwiń kolumnę Content i zdefiniuj transformację zawartości jednego pliku.
Efekt: przy odświeżaniu Power Query pobierze wszystkie nowe pliki spełniające kryteria, połączy je w jedną tabelę i od razu przetworzy. Jeden raz konfigurujesz transformacje, a potem możesz sobie pozwolić na długie urlopy bez ręcznego kopiowania raportów.
Dynamiczne adresy URL, parametry i funkcje w Power Query
Statyczny adres URL wystarczy przy jednym raporcie dziennym lub miesięcznym. Gdy jednak trzeba pobrać dane dla wielu dat, regionów czy produktów, opłaca się zautomatyzować budowanie adresu i wywołania.
Parametry – najprostszy poziom dynamiki
Parametr w Power Query to pojedyncza wartość (data, tekst, liczba), którą można wstrzyknąć do zapytania. Przydaje się choćby do sterowania zakresem dat w adresie API.
Przykład: masz adres API:
https://api.serwis.pl/dane?date=2024-04-01
Zamiast na sztywno wpisywać datę w URL, tworzysz parametr DataRaportu i budujesz adres w M:
let
DataRaportu = #date(2024, 4, 1),
Url = "https://api.serwis.pl/dane?date=" & Date.ToText(DataRaportu, "yyyy-MM-dd"),
Źródło = Web.Contents(Url)
in
Źródło
W praktyce parametr ustawiasz z poziomu interfejsu, bez pisania M, a do kodu zaglądasz tylko, jeśli chcesz mieć większą kontrolę nad formatem daty czy składnią zapytania.
Budowanie adresów URL z wielu fragmentów
Nieraz adres składa się nie tylko z daty, ale i innych filtrów: typu raportu, identyfikatora klienta, waluty. Łączenie tekstów w M działa podobnie jak w Excelu – operator &:
let
BazowyUrl = "https://api.serwis.pl/raport",
DataOd = Date.ToText(#date(2024, 1, 1), "yyyy-MM-dd"),
DataDo = Date.ToText(#date(2024, 1, 31), "yyyy-MM-dd"),
Waluta = "PLN",
Url = BazowyUrl & "?dateFrom=" & DataOd & "&dateTo=" & DataDo & "¤cy=" & Waluta,
Źródło = Web.Contents(Url)
in
Źródło
Takie podejście jest szczególnie przydatne, gdy adresy zmieniają się wg powtarzalnego wzorca – zamiast kopiować i przerabiać 10 zapytań, trzymasz jedną logikę i sterujesz ją parametrami.
Funkcje w M – gdy potrzebujesz wielu wywołań
Przy wielu kombinacjach parametrów (np. 12 miesięcy, 5 oddziałów) wygodniej jest zdefiniować funkcję pobierającą dane dla jednego zestawu i potem zawołać ją hurtowo.
Minimalistyczny schemat:
Tworzysz zapytanie, które pobiera dane dla jednej daty na sztywno.
W Edytorze modyfikujesz jego kod, zamieniając datę na parametr funkcji.
Przykładowa funkcja:
(DataRaportu as date) as table =>
let
Url = "https://api.serwis.pl/dane?date="
& Date.ToText(DataRaportu, "yyyy-MM-dd"),
Źródło = Web.Contents(Url),
Json = Json.Document(Źródło),
Tabela = ... // transformacje JSON do tabeli
in
Tabela
Następnie w osobnym zapytaniu tworzysz listę dat, zamieniasz ją na tabelę i wywołujesz funkcję dla każdego wiersza (kolumna niestandardowa). Efekt: z jednego wzorca funkcji budujesz komplet danych np. dla całego roku, a koszt utrzymania rośnie minimalnie.
Web.Contents z konfiguracją – kontrola nad cache i nagłówkami
Przy API lub serwisach z tajemniczą infrastrukturą czasem trzeba sięgnąć po bardziej szczegółowe wywołanie Web.Contents z rekordem opcji:
Przekazywanie nagłówków i parametrów zapytania
Większość prostych źródeł zadziała na samym adresie URL. Przy poważniejszych API pojawiają się jednak wymagania: token w nagłówku, dodatkowe parametry w ścieżce, timeouty. Wtedy przydaje się pełniejsza wersja Web.Contents:
parametry zapytania (Query) są uporządkowane – nie bawisz się w ręczne sklejanie długiego łańcucha URL,
nagłówki (Headers) można łatwo podmieniać; zmiana tokena autoryzacyjnego to jedna linijka,
timeout zabezpiecza przed wiecznym „mieleniem” w razie problemów po stronie serwera.
Do prostych zadań spokojnie wystarczy zbudowanie adresu jako tekst. Web.Contents z rekordem opcji opłaca się w momencie, gdy API staje się kluczowym elementem raportu i trzeba mieć nad nim lepszą kontrolę.
Cache, Retry i inne niuanse wydajności
Power Query lubi keszować wyniki zapytań internetowych. Zwykle to pomaga (mniej ruchu po sieci), ale przy testowaniu zmian potrafi mylić obraz. Do sterowania tym zachowaniem służy m.in. opcja IsRetry i parametry buforowania.
Przykładowy szkielet z wyłączaniem domyślnego cache na jedno wywołanie:
let
Źródło = Web.Contents(
"https://api.serwis.pl/dane",
[
Query = [date = "2024-01-01"],
IsRetry = true
]
)
in
Źródło
W praktyce do codziennej pracy rzadko trzeba to dotykać. Wystarczy wiedzieć, że gdy „coś nie gra” przy testach, a API na pewno już zwraca nowe dane, problem może leżeć po stronie cache. Wtedy pomaga:
zapisanie i ponowne otwarcie pliku,
zmiana drobnego fragmentu zapytania (np. dodanie parametru w URL),
chwilowe użycie IsRetry = true przy trudniejszych diagnozach.
Bezpieczeństwo: klucze, tokeny i poziomy prywatności
Klucze API i tokeny autoryzacyjne to newralgiczne elementy konfiguracji. Najgorszy scenariusz to wpisanie klucza na sztywno w kodzie M w udostępnianym skoroszycie. Tanie i bezpieczniejsze warianty:
trzymanie klucza w Parametrach (Power Query → Parametry) – nie ląduje w każdej funkcji, łatwiej go podmienić,
korzystanie z poświadczeń wbudowanych w Power BI Service / Excel (konektor Web przechowuje token po stronie usługi, nie w kodzie),
przy plikach w sieci firmowej – ograniczenie dostępu do samego pliku z raportem.
Poziomy prywatności (Publiczny, Organizacyjny, Prywatny) mają wpływ na to, jak Power Query miesza dane z różnych źródeł. Domyślnie warto trzymać dane firmowe w kategorii „Organizacyjny”, a prywatne foldery czy dyski – jako „Prywatne”. Zmniejsza to ryzyko przypadkowego wypłynięcia danych np. do obcego API przez nieprzemyślane „złączenie” zapytań.
Automatyczne odświeżanie w Excelu – możliwości i ograniczenia
Wczytanie danych z sieci to dopiero połowa historii. Realne oszczędności pojawiają się dopiero wtedy, gdy odświeżanie dzieje się samo, a człowiek tylko otwiera gotowy raport.
Ręczne odświeżanie vs odświeżanie przy otwarciu pliku
Excel oferuje trzy podstawowe tryby:
ręczne odświeżanie (prawy przycisk na tabeli → Odśwież),
odświeżanie wszystkich zapytań (Dane → Odśwież wszystko),
odświeżanie przy otwarciu skoroszytu.
Przy mniejszych raportach ręczne kliknięcie raz dziennie nie jest problemem. Schody zaczynają się, gdy:
plik ma kilkanaście zapytań i każde ciągnie dane z innego systemu,
odświeżanie trwa kilka minut,
raport ogląda kilka osób, które oczekują aktualnych danych od rana.
Wtedy najprostszy upgrade to włączenie opcji „Odśwież dane przy otwarciu pliku” dla kluczowych tabel lub w oknie „Właściwości połączenia”. Excel po prostu po starcie skoroszytu wykona wszystkie niezbędne zapytania, a użytkownik widzi świeże dane bez dodatkowych kliknięć.
Harmonogram odświeżania – lokalnie, bez Power BI
Pełnoprawny harmonogram to domena Power BI Service, ale w środowisku „tylko Excel” można złożyć działający kompromis. Dwa podstawowe warianty:
Skoroszyt otwierany przez użytkownika – odświeżanie przy otwarciu plus ewentualnie prosty makro-przycisk „Odśwież teraz”, jeśli ktoś chce zaktualizować dane w ciągu dnia.
Maszyna serwerowa lub dedykowany komputer – harmonogram systemowy (Harmonogram zadań w Windows), który o określonej godzinie otwiera skoroszyt, czeka na odświeżenie i zapisuje plik.
Drugi wariant to klasyczne, „budżetowe” obejście braku prawdziwego serwera analitycznego. Wymaga:
komputera, który jest włączony o zadanej godzinie,
skryptu (np. prosty plik .vbs lub .bat), który otworzy Excela, załaduje skoroszyt, poczeka na koniec odświeżania i go zapisze,
ustawienia zadania w Harmonogramie zadań.
Nie jest to rozwiązanie „enterprise”, ale często wystarczy, żeby co rano w folderze współdzielonym leżał świeży raport, gotowy do odczytu przez kilkanaście osób.
Ograniczenia odświeżania w Excelu
Przy danych z sieci Excel ma kilka praktycznych barier, o których dobrze wiedzieć zawczasu:
czas odświeżania – bardzo długie zapytania potrafią zawiesić Excela na kilka minut, zwłaszcza gdy zapytań jest wiele i pracują sekwencyjnie,
sesja użytkownika – jeśli korzystasz z prostych haseł logowania (np. Basic Auth do serwisu), odświeżanie może wymagać interakcji użytkownika przy wygaśnięciu sesji lub zmianie hasła,
limity API – niektóre serwisy pozwalają na ograniczoną liczbę wywołań na godzinę/dzień; kilka osób odświeżających duży raport może szybko „wyklikać” limit.
Gdy te ograniczenia zaczynają boleć, zwykle sygnałem jest rosnący czas oczekiwania przy otwieraniu skoroszytu lub komunikaty błędów z API. Wtedy opłaca się rozważyć przeniesienie ciężaru na Power BI Service albo uproszczenie zapytań (np. mniejszy zakres dat, mniej częste odświeżanie pełnego historii).
Częstotliwość odświeżania – kiedy „za dużo” szkodzi
Kuszące jest ustawienie odświeżania przy każdym otwarciu i każdej zmianie, ale ekonomicznie to rzadko ma sens. Dobrą praktyką jest rozbicie logiki na dwa poziomy:
pełne odświeżenie (z długą historią) – np. raz dziennie, w godzinach nocnych lub rano na dedykowanej maszynie,
lekki update bieżącego dnia – krótkie zapytanie po nowe rekordy, dostępne z przycisku „Odśwież dziś”.
W Power Query można to osiągnąć przez dwa zestawy zapytań:
zapytanie Historia – niewielki, rzadko aktualizowany plik (np. lokalny CSV lub Excel) z danymi dziennymi do wczoraj,
zapytanie Dzisiaj – zapytanie do API tylko po aktualny dzień,
zapytanie Wynik – łączy Historia i Dzisiaj w jedną tabelę.
Przy takim układzie pełne odświeżenie historii może dziać się rzadko i w trybie „technicznym”, a użytkownik na co dzień odświeża jedynie lekką część online.
Połączenia tła i blokowanie Excela
Domyślnie Excel potrafi odświeżać niektóre połączenia w tle. Przy zwykłych plikach z sieci często jest to wygodne – użytkownik może w tym czasie pracować w innych arkuszach. Natomiast przy API lub cięższych transformacjach Power Query praca w tle bywa iluzją: Excel i tak zwalnia, a użytkownik nie wie, czy proces jeszcze trwa.
Dla kluczowych zapytań sieciowych praktyczniejsze bywa wyłączenie odświeżania w tle w ustawieniach połączenia. Użytkownik widzi wtedy czytelny pasek postępu, a ryzyko błędów typu „dwa odświeżenia naraz” jest mniejsze.
Udostępnianie skoroszytów z zapytaniami Web
Raport z danymi online rzadko jest dziełem jednej osoby. Gdy plik idzie „w lud”, pojawiają się pytania:
czy każdy ma mieć prawo do odświeżania danych,
czy poświadczenia mają być współdzielone,
co się stanie po zmianie hasła w serwisie źródłowym.
Prostszy i bezpieczniejszy model to rozdzielenie ról:
jedna osoba (lub mały zespół) odpowiada za skoroszyt źródłowy z zapytaniami Web i określoną strukturą tabel wynikowych,
użytkownicy końcowi pracują na skoroszytach konsumenckich, które łączą się do źródłowego pliku (np. przez Power Query z folderu sieciowego) i nie dotykają bezpośrednio internetu.
To tani sposób na centralizację połączeń sieciowych bez stawiania serwerów raportowych. Po zmianie hasła do API wystarczy zaktualizować poświadczenia w jednym pliku, zamiast biegać po kilkunastu kopiach rozsianych po działach.
Najczęściej zadawane pytania (FAQ)
Jak w prosty sposób pobrać dane z internetu do Excela za pomocą Power Query?
Najprostsza ścieżka wygląda tak: kopiujesz adres URL z przeglądarki, w Excelu przechodzisz do karty Dane → Pobierz dane → Z innych źródeł → Z sieci, wklejasz adres i zatwierdzasz. Jeśli źródło jest publiczne, zwykle wystarczy tryb „Anonimowe”.
Po połączeniu Excel pokaże Nawigator z listą wykrytych tabel lub struktur danych. Wybierasz to, co cię interesuje, klikasz „Przekształć dane”, robisz podstawowe czyszczenie (typy kolumn, usunięcie śmieci), a na końcu „Zamknij i załaduj”. Od tego momentu odświeżasz wszystko jednym przyciskiem zamiast co tydzień pobierać pliki ręcznie.
Kiedy opłaca się automatyzować pobieranie danych z sieci, a kiedy lepiej zostać przy ręcznym eksporcie?
Automatyzacja ma sens, gdy na te same czynności tracisz co najmniej kilkanaście minut tygodniowo, a struktura danych w źródle jest względnie stabilna. Jeśli raport robisz codziennie, a każdorazowe logowanie, eksport i wklejanie zajmuje 5–10 minut, to jedno dobrze zrobione zapytanie Power Query szybko się „spłaci”.
Jeżeli natomiast korzystasz z danych raz na kwartał albo cały proces to jedno kliknięcie „Eksportuj do CSV” i wklejenie jednej tabeli – tu oszczędność czasu będzie znikoma. W takich przypadkach nie ma sensu budować rozbudowanych zapytań ani harmonogramów odświeżania, wystarczy prosty ręczny eksport.
Czym się różni odświeżanie danych w Excelu od odświeżania w Power BI?
W Excelu korzystasz głównie z ręcznego „Odśwież wszystko” i ew. opcji odświeżania przy otwieraniu pliku. Możesz dorzucić makra VBA lub zadania systemu Windows, ale to już dodatkowa konfiguracja i utrzymanie. Dobrze się sprawdza przy pojedynczych użytkownikach i mniejszych plikach.
W Power BI po publikacji do Power BI Service ustawiasz harmonogram odświeżania (np. kilka razy dziennie) i raport aktualizuje się w tle, bez udziału użytkowników. To wygodniejsze przy większych zespołach i raportach oglądanych przez wiele osób. Kosztowo – Excel jest tańszy na start, Power BI opłaca się, gdy faktycznie wykorzystujesz centralne odświeżanie i udostępnianie online.
Jakie typy adresów URL najlepiej działać z Power Query: strona HTML, API, CSV?
Najmniej problemów sprawiają bezpośrednie linki do plików (CSV, XLSX, JSON, XML) oraz proste API zwracające JSON lub XML. W takim scenariuszu dostajesz „gołe” dane, bez layoutu strony, reklam i innych dodatków, które potrafią się często zmieniać. To oszczędza czas na sprzątanie i zmniejsza ryzyko, że po zmianie wyglądu strony wszystko się rozsypie.
Klasyczne strony HTML z tabelami też da się wczytać, ale tu jesteś bardziej zależny od struktury i zmian w serwisie. Jeżeli masz wybór między tabelą HTML a przyciskiem „Pobierz CSV” – podpinaj Power Query pod CSV. Zwykle oznacza to mniej pracy przy budowie zapytania i mniej poprawek w przyszłości.
Jak ustawić automatyczne odświeżanie danych z sieci w Excelu bez dodatkowych płatnych narzędzi?
Najprostsza i darmowa opcja to włączenie odświeżania przy otwieraniu pliku. W oknie „Właściwości” połączenia (Prawy przycisk myszy na tabeli → Właściwości danych) możesz zaznaczyć „Odśwież dane przy otwieraniu pliku” i ewentualnie „Odśwież co X minut”. To wystarcza, jeśli raport otwierasz regularnie.
Jeśli potrzebujesz czegoś ciut bardziej automatycznego, da się wykorzystać proste makro VBA, które otwiera plik, odświeża wszystkie zapytania i zapisuje skoroszyt, uruchamiane z Harmonogramu zadań Windows. To nadal rozwiązanie „budżetowe”, ale pozwala mieć świeże dane np. co rano, bez ręcznego klikania.
Kiedy lepiej budować pobieranie danych w Power BI zamiast w Excelu?
Power BI ma sens, gdy te same dane mają oglądać różne osoby, raportów jest więcej, a wszyscy oczekują, że wszystko będzie dostępne online i aktualne bez kombinowania z wysyłką plików. Przykład: raport sprzedaży, do którego zagląda kilkunastu handlowców i zarząd – tutaj centralne odświeżanie w Power BI Service zwykle wychodzi taniej organizacyjnie niż żonglowanie plikami Excela.
Jeżeli jednak raport jest „dla siebie” albo dla małej grupy, a dane mieszczą się spokojnie w jednym skoroszycie, Excel z Power Query będzie prostszy, tańszy w utrzymaniu i szybszy do wdrożenia. Migrację do Power BI warto rozważać dopiero wtedy, gdy Excel zaczyna być wąskim gardłem.
Co zrobić, jeśli serwis często zmienia wygląd strony i wczytywanie tabel przez Power Query się sypie?
Najpierw sprawdź, czy serwis nie oferuje alternatyw: linku do CSV, pliku XLSX, prostego API albo jakiejkolwiek stałej ścieżki eksportu. Nawet „ukryty” przycisk „Eksportuj CSV” daje szansę na dużo stabilniejsze połączenie niż parsowanie skomplikowanej strony HTML z dynamicznym JavaScriptem.
Jeśli musisz zostać przy stronie HTML, staraj się w zapytaniu odwoływać do możliwie stabilnych elementów (np. konkretnej tabeli, a nie całej strony) i licz się z tym, że od czasu do czasu potrzebna będzie ręczna poprawka. Gdy poprawki zaczynają zajmować więcej czasu niż ręczny eksport – tam, gdzie to możliwe, lepiej uprościć proces, nawet kosztem częściowej rezygnacji z automatyzacji.
Najważniejsze wnioski
Największy zysk daje zastąpienie ręcznego eksportu prostym odświeżeniem zapytania Power Query – z kilkunastu minut klikania robi się jedno kliknięcie „Odśwież”, bez budowania pełnej „rakiety” automatyzacji.
Power Query szczególnie opłaca się przy powtarzalnych raportach z sieci (kursy walut, ceny produktów, statystyki z paneli www, dane z CRM/SaaS), gdzie te same kroki powielasz codziennie lub co tydzień.
Pełny harmonogram odświeżania (Power BI Service, zadania systemowe, Power Automate) ma sens głównie wtedy, gdy raporty są współdzielone i muszą być aktualne bez udziału użytkownika; w pozostałych przypadkach wystarczy ręczne odświeżenie jednym przyciskiem.
Automatyzacja ma ekonomiczny sens, gdy na ręczne pobieranie i obróbkę tych samych danych z sieci schodzi co najmniej kilkanaście minut tygodniowo i gdy struktura źródła jest w miarę stabilna.
Najtańsze „czasowo” źródła to bezpośrednie linki do plików (CSV, XLSX, JSON, XML) lub proste API; skomplikowane strony HTML z dynamicznym JavaScriptem zwykle generują więcej problemów niż oszczędności.
Jeśli serwis udostępnia zarówno tabelę na stronie, jak i link „Pobierz CSV”, rozsądniej jest podpiąć Power Query pod plik – mniej ryzykujesz, że zmiana wyglądu strony zepsuje cały proces.
W Excelu i Power BI punkt wejścia jest prosty: opcja „Z sieci / From Web”, wklejenie adresu URL i ustawienie uwierzytelnienia – to najtańsza czasowo ścieżka, żeby zacząć bez inwestowania w dodatkowe narzędzia czy usługi.
Bibliografia
Power Query documentation. Microsoft – Oficjalna dokumentacja Power Query: źródła danych, transformacje, odświeżanie
Power BI documentation. Microsoft Learn – Opis źródeł sieciowych, harmonogramów odświeżania i ograniczeń Power BI Service
Refresh data in Power BI. Microsoft Support – Zasady i konfiguracja odświeżania danych, w tym z sieci i plików
Power Query M formula language specification. Microsoft Open Specifications – Opis języka M używanego w Power Query do zapytań i automatyzacji
Power BI governance and deployment approaches. Microsoft Azure Architecture Center – Rekomendacje dot. architektury, skalowalności i automatyzacji raportów Power BI
Excel 365: Business Intelligence Features. Pearson (2021) – Omówienie Power Query w Excelu, modeli danych i scenariuszy raportowych
