Jak Digital Vantage przeniosło tagowanie z przeglądarki na własny serwer — first-party, odporne na adblocki i sterowane z jednego miejsca dla wszystkich domen
Wewnętrzna infrastruktura DV: własny server-side kontener Google Tag Manager, który taguje ruch dla sześciu domen w trzech krajach z jednego miejsca. Nie ma klienta ani interfejsu — case sprzedaje kompetencję DevOps i analityczną: tracking odporny na adblocki, z Consent Mode i własnym monitoringiem, który wykrywa awarię w pięć minut zamiast po dobie. Reference build, żywy na produkcji.

Klasyczny tracking (gtag.js + fbevents.js) ma trzy znane słabości: adblocki wycinają zewnętrzne skrypty, Safari ITP kasuje third-party cookies po siedmiu dniach, a każdy kolejny skrypt kosztuje Core Web Vitals. Dlatego DV przeniosło tagowanie na własny serwer — jeden lekki skrypt z first-party domeny i jeden punkt kontroli nad tagami dla sześciu domen naraz.
Prawdziwe wyzwanie przyszło po wdrożeniu. 7 maja 2026 tracking padł na wszystkich sześciu domenach: Google zrotował tag obrazu kontenera, a wraz z nim wymóg konfiguracji, której kontenery nie miały, i /gtag/destination zaczął zwracać 400. Awaria trwała ponad dobę i nikt jej nie zauważył — monitoring istniał, ale sprawdzał, czy kontener żyje (zawsze 200), a nie czy tag realnie przyjmuje event; przy okazji nigdy nie działał, bo czytał listę hostów z pliku, w którym jej nie było. Awarię znalazł człowiek, ręcznie, w konsoli DevTools.
Każda decyzja to odpowiedź na to, co zawiodło. Health-check uderza teraz w dwa endpointy per host — „kontener żyje” ORAZ „GA4 realnie przyjmuje event” — bo to ta druga klasa awarii przeszła niezauważona. Konfiguracja (hosty, measurement IDs) jest czytana wprost z jednego README, żeby nie mogła się rozjechać jak poprzednio.
Obraz jest pinnięty do konkretnego SHA zamiast ruchomego tagu, który Google rotuje bez ostrzeżenia — a że pin to dług, pilnuje go cotygodniowy cron wykrywający rotację, zanim trafi na produkcję. Alerty mają lifecycle na GitHub Issues: pierwsza awaria zakłada issue i pinguje Discord, kolejne tylko dopisują komentarz, recovery zamyka — bo dwanaście identycznych pingów w godzinę uczy zespół je ignorować. Cały monitoring stoi na ~1027 liniach basha z 84 testami i CI, bo niesprawdzony skrypt monitoringu to ten sam problem od nowa.
Wykrycie awarii spadło z ponad doby do poniżej pięciu minut: synthetic robi 10 probe’ów co 5 minut i pinguje Discord na pierwszą awarię. Pomiar 16.07.2026 — 10 na 10 probe’ów zdrowych, wszystkie 200. Sześć domen w trzech krajach obsługuje jeden kontener na 512 MB i pół rdzenia, na istniejącym VPS-ie, bez dodatkowego kosztu wobec Cloud Run.
Czytamy to jako wynik inżynierski i tak go stawiamy. Nie twierdzimy, że mamy „99,9% uptime” — nie ma tu historii runów, żeby to policzyć. MTTD poniżej pięciu minut jest poprawny konstrukcyjnie, ale poparty jedną awarią sprzed wdrożenia, nie serią wykryć po nim. To dokładnie ta uczciwość — mierzyć to, co się zmierzyło — którą ten projekt ma pokazywać.
Własny server-side GTM dla 6 domen z monitoringiem, który skrócił wykrycie awarii trackingu z ponad doby do 5 minut.
Przeniosę tracking na własny serwer — first-party, odporny na adblocki, sterowany z jednego miejsca.