SODAR od Google to nazwa dwóch różnych rzeczy: po pierwsze eksperymentalnego narzędzia AR do mierzenia dystansu społecznego, a po drugie – wewnętrznego komponentu ekosystemu reklamowego, odpowiedzialnego m.in. za pomiary widoczności reklam i bezpieczeństwo ich osadzania.
To właśnie ten drugi SODAR widzisz najczęściej w DevTools i to on ma znaczenie dla wydajności, dostępności oraz stabilności serwisów.
Poniżej znajdziesz rozbudowane, techniczne omówienie z perspektywy front-endu, analityki i dostępności.
Skąd zamieszanie? Dwa „SODAR-y” od Google
SODAR jako narzędzie AR
W 2020 r. Google opublikowało eksperymentalne narzędzie Sodar, które w przeglądarce mobilnej za pomocą AR tworzyło okrąg o promieniu 2 m, by pomóc użytkownikom zachować dystans społeczny w pandemii COVID‑19.
Narzędzie działało w Chrome na Androidzie z wykorzystaniem WebXR i nie wymagało instalacji aplikacji – funkcjonowało po wejściu na stronę WWW.
To jednak osobny projekt „Experiments with Google” i nie ma nic wspólnego z reklamami.
SODAR, który widzisz w reklamach
Jeśli zajmujesz się tworzeniem stron, prawdopodobnie trafiłeś na następujące elementy powiązane z SODAR-em:
- dodatkowe iframe’y lub skrypty o nazwach zawierających „sodar”,
- elementy DOM o klasach lub atrybutach z tym fragmentem nazwy,
- dodatkowe zasoby z domen reklamowych Google.
W praktyce ten komponent pełni kilka ról w infrastrukturze reklamowej Google:
- Komponent infrastruktury reklamowej – część ekosystemu Google Ads / AdSense / Ad Manager uruchamiana automatycznie z tagami reklamowymi;
- Pomiar widoczności reklam (viewability) – monitoruje, czy reklama była realnie widoczna na ekranie i jak długo;
- Bezpieczne osadzanie w iframe’ach – izoluje reklamy oraz umożliwia kontrolowaną komunikację międzydomenową;
- Anty‑fraud i integracja z analityką – pomaga wykrywać nienaturalny ruch i zasila systemy raportowania.
Dla twórcy strony SODAR to po prostu kolejny, automatycznie osadzany fragment kodu, który pojawia się, gdy ładujesz reklamy z ekosystemu Google.
Jak w ogóle działa Google Ads – kontekst dla SODAR
Model biznesowy i aukcja
Google Ads to system reklamowy wyświetlający reklamy w wyszukiwarce, w sieci reklamowej (strony partnerskie), w YouTube i aplikacjach.
Podstawowy model rozliczeń to PPC (Pay‑Per‑Click) – reklamodawca płaci za kliknięcie, nie za samo wyświetlenie.
Wyświetlenie reklamy poprzedza aukcja, w której:
- reklamodawcy licytują stawkę za konkretne słowa kluczowe lub grupy odbiorców,
- system oblicza Ad Rank, łącząc m.in. stawkę i jakość reklamy,
- na tej podstawie decyduje, które reklamy pokaże i w jakiej kolejności.
Aby rozliczać i optymalizować kampanie, Google musi wiedzieć:
- czy reklama została faktycznie wyświetlona,
- czy była widoczna w polu widzenia użytkownika,
- czy użytkownik w nią kliknął,
- jakie późniejsze działania podjął (konwersje).
Bez rzetelnego pomiaru nie da się ani uczciwie rozliczać reklam, ani skutecznie używać uczenia maszynowego do ich optymalizacji.
Jak wygląda to technicznie na stronie
Z punktu widzenia front-endu przepływ działań jest prosty:
- w kodzie strony umieszczasz tag reklamowy (np. gtag, Google Ads, AdSense lub tag w Google Tag Managerze),
- skrypt tworzy dodatkowe iframe’y z reklamami (często z domeny
googlesyndication.com), - ładuje kolejne podskrypty odpowiedzialne za pomiar, bezpieczeństwo i personalizację,
- komunikuje się z serwerami Google, wysyłając dane o wyświetleniach, widoczności, kliknięciach i konwersjach.
SODAR jest jednym z takich dodatkowych komponentów – nie generujesz go samodzielnie; pojawia się „w tle”, gdy korzystasz z usług reklamowych Google.
Co dokładnie robi SODAR w reklamach (z perspektywy dewelopera)
Google nie publikuje pełnej specyfikacji SODAR. Na podstawie obserwacji:
- zachowania skryptów,
- struktury DOM z reklamami,
- komunikacji z serwerami.
Można dość jasno wskazać jego główne role.
Pomiar widoczności reklamy (viewability)
W ekosystemie reklamowym kluczowe jest nie tylko, czy reklama została załadowana, ale czy była realnie widoczna na ekranie przez określony czas.
Widoczność (viewability) wpływa na kilka obszarów:
- sposób rozliczania (np. CPM za widoczne odsłony),
- optymalizację kampanii (algorytmy unikają miejsc, gdzie reklamy są technicznie wyświetlane, ale niewidoczne),
- jakość sieci reklamowej (eliminowanie spamu i nadużyć).
SODAR działa tutaj mniej więcej tak:
- monitoruje położenie iframe’ów z reklamą względem okna przeglądarki,
- używa API pokroju IntersectionObserver (gdy jest dostępne) i/lub nasłuchuje zdarzeń scroll oraz resize,
- gdy reklama wchodzi w próg widoczności (np. 50% pikseli przez 1 s), wysyła do serwerów sygnał „reklama widoczna / niewidoczna”,
- sygnały te trafiają do systemów raportujących Google Ads / AdSense / Ad Manager.
Z punktu widzenia twórcy strony SODAR zazwyczaj:
- tworzy niewielkie elementy pomiarowe w DOM (czasem transparentne overlaye),
- nasłuchuje zdarzeń przewijania i zmiany rozmiaru,
- raportuje Google, co dzieje się z reklamą na ekranie.
Bezpieczne osadzanie reklam i komunikacja cross‑domain
Reklamy są często serwowane z innych domen (np. pagead2.googlesyndication.com), dlatego trafiają do iframe’ów, a bezpośredni dostęp JS ogranicza Same Origin Policy. W tym miejscu SODAR pełni rolę pośrednika i m.in.:
- wstawia ramki pośrednie, by lepiej kontrolować zachowanie reklamy,
- umożliwia bezpieczną komunikację między stroną a iframem z reklamą (np. przez
postMessage), - ogranicza potencjalnie niebezpieczne działania reklam,
- pilnuje, by reklama nie wykraczała poza swój kontener,
- współpracuje z mechanizmami prywatności i zgód (np. Consent Mode).
Dzięki temu reklamy pozostają odizolowane, a jednocześnie można je mierzyć i kontrolować bez narażania strony na ryzyko.
Dodatkowe metryki i anty‑fraud
SODAR oraz pokrewne skrypty reklamowe zbierają dane, które pomagają:
- wykrywać nienaturalny ruch (boty, farmy kliknięć),
- ograniczać nieuczciwe praktyki (np. auto‑refresh, ukryte reklamy),
- budować dokładniejsze metryki skuteczności (np. interakcje z formatami rich‑media).
Nie chodzi tu o „śledzenie użytkownika” w sensie personalizacji; rolą jest przede wszystkim ochrona jakości ruchu reklamowego i rzetelny pomiar.
SODAR a prywatność i personalizacja reklam
Czego SODAR nie robi
Warto rozróżnić dwie warstwy działania reklamy:
- warstwę pomiarowo‑techniczną (SODAR i pokrewne skrypty),
- warstwę personalizacji – czyli „komu jaką reklamę pokazać”.
Za personalizację odpowiadają m.in. następujące mechanizmy:
- ustawienia reklam spersonalizowanych w koncie Google,
- identyfikatory reklamowe urządzeń i ustawienia systemowe (np. reset ID, rezygnacja z personalizacji na Androidzie).
Użytkownik może samodzielnie zarządzać personalizacją:
- włączać lub wyłączać reklamy spersonalizowane w usługach Google,
- zresetować identyfikator reklamowy lub ograniczyć personalizację na urządzeniu.
SODAR nie decyduje o doborze reklam; pełni funkcję „czujnika”, który mierzy, jak reklamy były wyświetlane i widziane.
Co widzi użytkownik w ustawieniach
Zmiana ustawień reklam spersonalizowanych wpływa na:
- dobór treści reklam,
- zakres danych wykorzystywanych do profilowania.
SODAR nadal może działać – mierzy wtedy widoczność reklam kontekstowych lub ogólnych.
Wpływ SODAR na wydajność, UX i dostępność
Wydajność
Reklamy Google (w tym komponenty takie jak SODAR) wnoszą dodatkowe obciążenie:
- ładują dodatkowe skrypty i iframe’y,
- zwiększają liczbę żądań HTTP,
- dodają nasłuchiwaczy scroll oraz resize.
Może to wpływać na metryki i odczucia użytkownika:
- czas ładowania (LCP),
- responsywność podczas przewijania,
- zużycie CPU i baterii na słabszych urządzeniach.
Aby ograniczyć negatywny wpływ, zastosuj sprawdzone praktyki:
- stosuj lazy‑loading reklam (ładowanie dopiero w pobliżu viewportu),
- rezerwuj z góry miejsce pod reklamy (wysokość kontenerów), by uniknąć CLS,
- ograniczaj liczbę jednocześnie widocznych slotów reklamowych,
- testuj wydajność z włączonymi reklamami w Lighthouse i WebPageTest.
SODAR jest relatywnie lekki, ale jego wpływ sumuje się z pozostałymi elementami ekosystemu reklamowego.
Dostępność – potencjalne problemy
SODAR dodaje do DOM elementy techniczne, które:
- są zwykle niewidoczne wizualnie (przezroczyste, poza ekranem),
- czasem stanowią overlay nakładany na stronę,
- bywają umieszczone w strukturze w sposób zaskakujący dla czytników ekranu lub nawigacji klawiaturą.
Możliwe skutki uboczne to:
- zaburzona kolejność fokusu – jeśli iframe’y reklamowe lub elementy pomiarowe nie mają
tabindex="-1"lub są błędnie oznaczone, - zagubienie kontekstu – gdy reklamy wpychają się między logicznie powiązane elementy (np. między nagłówek a treść),
- nakładanie się warstw – overlay reklamowy (także techniczny) może czasowo przykrywać interaktywne elementy przy źle ustawionych
z-index.
Google stara się minimalizować te problemy, m.in. przez:
- używanie
aria-hidden="true"dla elementów technicznych, - ustawianie
tabindex="-1"tam, gdzie interakcja nie jest potrzebna.
Efekt końcowy zależy jednak od uwarunkowań po twojej stronie:
- konkretnej konfiguracji reklam,
- struktury strony i miejsca wstrzyknięcia slotów,
- dodatkowych styli CSS (zwłaszcza globalnych reguł dla iframe’ów i overlayów).
Dostępność – dobre praktyki po stronie twórcy strony
Aby SODAR i inne komponenty reklamowe nie pogorszyły dostępności, zastosuj poniższe zalecenia:
- Wyraźne oznaczenie stref reklamowych – dodaj nagłówki typu „Reklama” oraz właściwe role/landmarki (np.
role="complementary",aria-label="Reklama") wokół kontenerów; - Brak globalnego stylowania elementów z Google – nie stosuj reguł typu
iframe { position: relative; z-index: 9999; }, które mogą zaburzyć układ i warstwy pomiarowe; - Testy z czytnikami ekranu – sprawdź NVDA/JAWS/VoiceOver z włączonymi reklamami i bez nich, bo to dwa różne scenariusze dostępności;
- Przemyślana kolejność w DOM – nie wstawiaj reklam między logicznie powiązane elementy (np. pola formularza i etykiety); lepiej grupować je w wydzielone obszary;
- Kontrola fokusa klawiatury – upewnij się, że użytkownik nie trafia do technicznych iframe’ów bez widocznej treści; w razie problemów skonsultuj konfigurację z supportem Google Ads / AdSense.
Co możesz, a czego nie powinieneś robić z SODAR
Czego nie robić
Nie usuwaj ręcznie elementów SODAR (np. przez display: none !important na konkretne identyfikatory lub klasy). Możesz w ten sposób zaburzyć pomiar widoczności, naruszyć regulamin Google Ads / AdSense i dostarczyć reklamodawcom nieprawidłowe dane o skuteczności.
Nie zasłaniaj reklam technicznymi overlayami (np. stałymi nagłówkami z bardzo wysokim z-index). Reklamy mogą wówczas nigdy nie osiągać statusu „widocznych” w standardach pomiaru, co obniży przychody i zafałszuje wyniki.
Co możesz zrobić sensownie
Te działania realnie poprawią stabilność, wydajność i jakość pomiaru:
- Ogranicz liczbę slotów reklamowych – mniej slotów to mniej iframe’ów i mniej pracy dla komponentów pomiarowych,
- Zadbaj o „czyste” środowisko CSS – traktuj reklamy jak „czarną skrzynkę” i nie nadpisuj ich styli poza niezbędnymi (np. marginesy kontenera),
- Wykorzystaj atrybuty i API Google Ads – w miarę możliwości włączaj/wyłączaj wybrane funkcje pomiarowe, stosuj lazy‑loading i kontroluj formaty reklam,
- Pracuj z Consent Mode – w UE poprawne wdrożenie zgód (np. IAB TCF) i Consent Mode pomaga zachować zgodność z RODO, a jednocześnie utrzymać część funkcji pomiarowych w trybie ograniczonym.
