Analityka witryn wielojęzycznych: Śledzenie zachowania między językami

Witryna wielojęzyczna to rzadko po prostu jedna witryna w wielu językach. To portfel zlokalizowanych doświadczeń, każde z własnym popytem wyszukiwawczym, własną podróżą kupującego, własnym tarciem konwersji i własną velocity contentu. Warstwa analityczna, która działała dla angielskiej witryny, rzadko produkuje używalny widok tego, jak wersje niemiecka, japońska i brazylijska faktycznie sobie radzą. Traktowanie witryny wielojęzycznej jako pojedynczej property w GA4 z dymensją języka doczepioną z boku to najczęstszy powód wielorynkowych programów wyglądających zdrowo w globalnym rollupie i zawodzących, gdy zarząd prosi o detal na poziomie języka.

Operujemy programy analityki wielojęzycznej z biur w Szwajcarii, Danii, Polsce, Hongkongu, Holandii i Wielkiej Brytanii, wspierając klientów, których witryny obejmują 20+ języków i dialektów. Wzorzec konsekwentnie produkujący używalny widok: wychwytywanie zdarzeń świadomych języka, monitoring zdrowia hreflang, metryki velocity contentu segmentowane per lokalizacja i modelowanie na poziomie warehouse traktujące każdy język jako pierwszorzędną encję. Wynikiem jest warstwa raportowania wydobywająca luki wydajności napędzające kolejną decyzję priorytetyzacyjną, zamiast ukrywać je w globalnej średniej.

Dlaczego "po prostu dodaj dymensję języka" nie wystarcza

Domyślną odpowiedzią na pomiar wielojęzyczny jest dodanie language jako custom dimension w GA4 i uznanie pracy za zrobioną. Dymensja produkuje filtrowany widok standardowych raportów, który wydaje się użyteczny, dopóki pytania nie staną się interesujące. Dlaczego niemiecki bounce rate jest o 14 punktów wyższy niż francuski na równoważnych stronach? Czy to problem jakości contentu, jakości tłumaczenia, niedopasowania intencji wyszukiwawczej, czy technicznej błędnej konfiguracji hreflang wysyłającej niewłaściwe audytorium? Pojedyncza dymensja języka nie potrafi na to odpowiedzieć.

"Cross-domain and multi-property measurement requires careful identifier and taxonomy alignment to produce comparable analytics across language and country versions of a site." — Google Analytics 4 documentation, 2024

Działający stos wielojęzyczny rozszerza się poza dymensję języka w cztery powiązane widoki: język jako oś podstawowa, locale (język plus kraj) tam, gdzie się rozchodzą, klaster contentowy i etap podróży użytkownika. Każda oś wydobywa inną klasę problemu, a kombinacje to miejsce, gdzie pojawiają się najciekawsze wyniki. Nasza praktyka SEO zwykle zaczyna audyt wielojęzyczny od zmapowania tych czterech osi wobec obecnego setupu pomiarowego klienta; luki zwykle przewyższają liczebnie mocne strony.

Wychwytywanie zdarzeń świadomych języka

Fundamentem analityki wielojęzycznej jest wychwytywanie zdarzeń zawierające kontekst języka i locale w każdym payloadzie zdarzenia — a nie jako dymensja wnioskowana z parsowania URL w raportowaniu, ale jako jawny parametr na samym zdarzeniu. Wnioskowane dymensje łamią się, gdy struktury URL się zmieniają; jawne parametry zdarzeń przeżywają przebudowy witryn.

Parametr hreflangmatch to diagnostyka wychwytująca najwięcej problemów. Użytkownik, którego przeglądarka preferuje niemiecki, ale który ląduje na angielskiej stronie — ponieważ konfiguracja hreflang go tam wysłała — reprezentuje mierzalną stratę potencjału konwersji, a payload zdarzenia to wydobywa. W typowym audycie wielojęzycznym widzimy wskaźniki hreflangmatch=mismatch w wysokości 8-15% między głównymi rynkami; wpływ na konwersję jest znaczący.

Zdrowie hreflang jako metryka operacyjna

Hreflang jest traktowany jako techniczna konfiguracja SEO przez większość zespołów. W dojrzałym programie analityki wielojęzycznej zdrowie hreflang jest także metryką operacyjną śledzoną cotygodniowo w warstwie raportowania. Trzy wskaźniki wychwytują większość wartości diagnostycznej:

Pierwszym jest kompletność tagów zwrotnych. Każda adnotacja hreflang na stronie A wskazująca na stronę B wymaga wzajemnej adnotacji na stronie B wskazującej z powrotem na stronę A. Wskaźnik kompletności tagów zwrotnych poniżej 95% oznacza, że wyszukiwarki odrzucają adnotacje, a zlokalizowane wersje nie są właściwie klastrowane.

Drugim jest wskaźnik konfliktu canonical-hreflang. Strony, których tag canonical wskazuje na inną wersję językową niż ich adnotacje hreflang, tworzą mieszane sygnały tłumiące zlokalizowaną wersję. Wskaźnik konfliktu powyżej 1-2% wskazuje na poważny problem techniczny.

Trzecim jest wskaźnik dopasowania zaserwowanego języka do sygnału. Logowany przez parametr zdarzenia hreflang_match, mierzy, jak często użytkownicy faktycznie lądują na stronie, na której język przeglądarki wskazuje, że powinni wylądować. Silne programy wielojęzyczne biegną na 85-92%; słabe programy biegną na 60-75%, a luka to odzyskiwalne przychody.

Dla zestawu diagnostycznego hreflang przy skali techniczne wytyczne IAB Europe i dokumentacja hreflang Google to autorytatywne odniesienia. Połączenie dwóch produkuje obronną techniczną linię bazową; powyższe metryki operacyjne siedzą na tej linii bazowej.

Velocity contentu per locale

Witryna wielojęzyczna rzadko publikuje content równomiernie między językami. Angielska witryna może publikować trzy artykuły tygodniowo; niemiecka witryna jeden tygodniowo; brazylijska portugalska witryna jeden co dwa tygodnie. Raportowanie, które nie wydobywa tej asymetrii, ukrywa najważniejsze strategiczne pytanie w programach wielojęzycznych: gdzie velocity contentu produkuje procentujące zwroty, a gdzie produkuje malejące zwroty?

Trzy metryki velocity contentu należą do widoku raportowania per locale:

1. Artykuły opublikowane per locale per kwartał, z porównaniem rok-do-roku.

Locale, w którym publikowanie spowolniło o więcej niż 25% YoY, jest albo intencjonalnie depriorytetyzowane, albo niezamierzenie dryfuje; raportowanie powinno oflagować które.

1. Średni czas od angielskiej publikacji do dostępności tłumaczenia, w

dniach. Program wielojęzyczny, w którym tłumaczenia opóźniają się wobec angielskiego o 90+ dni, produkuje inne doświadczenie użytkownika na nieanglojęzycznych rynkach, niż zakładała strategia. Opóźnienie poniżej 30 dni wskazuje na działający pipeline; opóźnienie powyżej 60 dni wskazuje na pipeline wymagający inwestycji.

1. Procent pokrycia tłumaczeń dla oczekiwanej biblioteki contentowej każdej

locale. Locale pokazujące 40% pokrycia, gdy strategia zakładała 80%, jest albo ograniczone zasobami, albo miało zmienione wymagania bez aktualizacji warstwy pomiarowej.

Trzy metryki razem produkują widok operacji contentowych wydobywający, gdzie pipeline publikacyjny nadąża za strategią, a gdzie nie. Nasza biblioteka Insights omawia wzorce operacyjne utrzymujące velocity tłumaczeń przy skali między wieloma językami.

Segmentacja wydobywająca właściwe pytania

Domyślna segmentacja GA4 w setupie wielojęzycznym porównuje grupy językowe wobec siebie na standardowych metrykach — sesje, conversion rate, średnia wartość zamówienia. To porównanie jest użyteczne, ale rzadko wydobywa pytanie, które ma największe znaczenie: gdzie doświadczenie jest znacząco gorsze niż równoważne w innym języku i dlaczego?

Działający wzorzec segmentacji porównuje trzy rzeczy:

Pierwszym jest porównanie tego samego contentu cross-language. Weź pojedynczy klaster contentowy — na przykład "usługi data analytics" — i porównaj lejek między wszystkimi wersjami językowymi. Bounce rate, głębokość scrollowania, clickthrough wewnętrznych linków i conversion rate na równoważnej stronie w każdym języku. Język z najgorszą wydajnością lejka na równoważnym contencie to najwyższy priorytet badania, a przyczyną często jest jakość tłumaczenia lub niedopasowanie lokalnej intencji wyszukiwawczej, a nie cokolwiek widocznego na poziomie strony.

Drugim jest dopasowanie intencji wyszukiwawczej per locale. To samo zapytanie przetłumaczone dosłownie na niemiecki lub japoński często nie reprezentuje tej samej intencji użytkownika. Locale o wysokim ruchu i niskiej konwersji często wskazuje na niedopasowanie intencji w targetowaniu słów kluczowych, a nie problem optymalizacji conversion rate.

Trzecim jest mix urządzeń i kanałów per locale. Udział mobile w Brazylii i Indiach jest materialnie różny od Szwajcarii i Wielkiej Brytanii. Model raportowania nie wydobywający mixu urządzeń per locale produkuje benchmarki conversion rate wyglądające porównywalnie, ale faktycznie mierzące różne audytoria.

Co łamie się najczęściej

Trzy tryby porażki powtarzają się w programach analityki wielojęzycznej, które audytujemy.

Pierwszym jest język wnioskowany z URL, ale struktura URL różni się per rynek. Niektóre rynki używają podkatalogów /de/, niektóre subdomeny de.brand.com, a niektóre ccTLD brand.de. Raporty wnioskujące język ze wzorca URL łamią się, gdy zasady wnioskowania nie pokrywają wszystkich trzech struktur. Naprawą jest wychwytywanie języka jako parametru zdarzenia z samej strony, a nie z URL.

Drugim jest cele konwersji zdefiniowane globalnie, ale zlokalizowane inaczej. Cel "request consultation" zdefiniowany jako wysłanie formularza po angielsku mógł zostać wdrożony jako rozmowa telefoniczna w Japonii, e-mail w Holandii i wiadomość WhatsApp w Brazylii. Raporty porównujące conversion rates między tymi rynkami porównują różne zdarzenia z tą samą etykietą. Naprawą jest locale-specyficzna taksonomia konwersji agregująca do globalnego celu.

Trzecim jest sampling GA4 na poziomie segmentu języka. Wysokoruchowe języki nie są samplowane; niskoruchowe są, czasem ciężko. Segment językowy z 2 000 sesji dziennie wyprodukuje inaczej dotknięte samplingiem raporty niż jeden z 200 000. Raportowanie na poziomie warehouse (eksport BigQuery, ClickHouse lub odpowiednik) eliminuje problem samplingu i jest coraz częściej właściwą odpowiedzią dla programów wielojęzycznych przy skali.

Frequently Asked Questions

Czy każdy język powinien mieć własną property GA4 czy dzielić jedną? Dziel jedną property dla większości programów. Osobne property czynią analizę cross-language drogą i łamią śledzenie podróży użytkownika, gdy użytkownicy zmieniają język w trakcie sesji. Używaj pojedynczej property z językiem jako podstawowym parametrem zdarzenia i locale jako parametrem drugorzędnym. Wiele property ma sens tylko wtedy, gdy powody prawne lub organizacyjne wymagają sztywnej separacji danych.

Jak przypisać konwersje dla użytkowników przeglądających w wielu językach? Ustaw pierwsze zdarzenie każdej sesji jako kanoniczny język dla tej sesji, ale śledź wszystkie przejścia językowe w sesji jako osobne zdarzenia z nazwą language_change. Sesja jest przypisana do języka wyzwalającego konwersję; podróż jest widoczna w historii zdarzeń zmian języka. Większość użytkowników zmieniających język robi to raz, wcześnie w sesji.

Czy GA4 obsługuje języki right-to-left poprawnie? GA4 obsługuje dane poprawnie niezależnie od kierunku pisma; problem zwykle leży na warstwie wdrożeniowej, gdzie tekst arabski lub hebrajski w parametrach zdarzeń może łamać URL encoding, jeśli nie jest właściwie obsługiwany. Naprawą jest zapewnienie, że wartości parametrów zdarzeń są właściwie URL-zakodowane na warstwie tag managera.

Jak benchmarkować wielojęzyczne conversion rates? Unikaj benchmarkingu cross-language wobec średnich zewnętrznych — wariancja per język, rynek, mix urządzeń i branża jest zbyt wysoka, by zewnętrzne benchmarki były użyteczne. Benchmarkuj każdy język wobec samego siebie w czasie i wobec wydajności równoważnego contentu w innych językach w obrębie tej samej witryny. Benchmarkowanie wewnętrzne jest niemal zawsze bardziej informacyjne niż benchmarkowanie zewnętrzne w kontekstach wielojęzycznych.

Jaka jest właściwa kadencja raportowania dla analityki wielojęzycznej? Operacyjny review cotygodniowo dla każdego języka z lokalnymi zespołami marketingowymi. Porównawczy review cross-language miesięcznie z centralnym zespołem. Strategiczny review kwartalnie z zarządem, skupiony na lukach wydajności na poziomie języka i priorytetyzacji, która z nich płynie. Codzienne raportowanie na poziomie języka dodaje szumu bez dodawania sygnału dla większości programów.

Obronny widok analityki wielojęzycznej wydobywa luki między językami, które globalny rollup ukrywa, a te luki to zwykle miejsce, gdzie budżet contentu i optymalizacji następnego kwartału powinien się skupić. By zobaczyć, jak to wygląda zastosowane do waszego konkretnego portfela językowego, poznaj nasze usługi analytics lub umów konsultację z naszym zespołem.