Smart Redirect Routing: geo, urządzenie, testy A/B i warunki reguł
Jeden link kampanii może wymagać innych celów według kraju, urządzenia, języka, UTM, wagi testu i fallbacku. Tak projektuje się tę logikę bez ukrywania jej w kodzie aplikacji.
Przekierowanie jest proste tylko wtedy, gdy każdy klik ma trafić w to samo miejsce. W kampaniach, ecommerce i aplikacjach mobilnych to rzadko prawda.
Użytkownik z Polski może potrzebować polskiej oferty, użytkownik z Niemiec innego sklepu, a ruch spoza obsługiwanych krajów jasnego fallbacku. iPhone powinien dostać App Store albo Universal Link, Android Google Play albo Android App Link, desktop landing page lub formularz. Kampanie performance muszą zachować UTM, click ID, kupony i identyfikatory afiliacyjne. Test A/B powinien trzymać użytkownika w tej samej wariancie.
Smart Redirect Routing to publiczny link sterowany polityką routingu, a nie pojedynczym polem destination.
UrlEdge publikuje taką politykę na edge. Możesz łączyć kraj, urządzenie, język, query, header, cookie, kampanię, wagi A/B i fallback, z analityką oraz rollbackiem. To szczególnie ważne, gdy marketing, ecommerce, agencja i development dotykają tych samych linków.
Jeden link, kilka decyzji
Logika często jest rozrzucona:
- geo redirect w CDN
- mobile redirect w sklepie lub CMS
- test A/B w skrypcie przeglądarkowym
- UTM-y w landing page
- fallback w arkuszu
- wyjątki w middleware
Przy zmianie kampanii lub migracji sklepu nikt nie wie, która warstwa zdecydowała.
| Pytanie | Dlaczego ma znaczenie |
|---|---|
| Co matchuje? | Domena, ścieżka, wildcard, regex, slug, QR |
| Jaki kontekst liczy się? | Kraj, urządzenie, język, OS, browser, query, header, cookie |
| Co ma priorytet? | Safety, kampania, urządzenie, kraj, A/B, fallback |
| Dokąd kierować? | Sklep, app store, landing, support, blokada, fallback |
| Jak dzielić ruch? | Wagi A/B, rollout, wariant kampanii, canary |
| Co zachować? | Path, query, UTM, ID afiliacji, kupon |
| Jak wrócić? | Snapshot, fallback, pauza kampanii, owner |
Geo routing ma sens, gdy cel naprawdę się różni
| Scenariusz | Lepsze zachowanie |
|---|---|
| Ecommerce regionalny | Właściwy katalog, waluta, dostawa i dostępność |
| Kampanie płatne | Polska, Niemcy, Czechy lub global trafiają na właściwą ofertę |
| Brak produktu | Waitlist, lokalny partner albo jasny komunikat |
| Compliance | Jawna polityka allowed, blocked, fallback |
| Pomoc i dokumentacja | Lokalny język tylko przy utrzymanej treści |
Cloudflare Workers udostępnia metadane request.cf, w tym kraj. To pomaga, ale nie zastępuje decyzji SEO i biznesowej. Unikaj cloakingu, trzymaj canonical intent i stabilny fallback.
Routing według urządzenia: mobile commerce i aplikacje
W Polsce dużo ruchu kampanijnego przechodzi przez mobile, social, QR, marketplace i aplikacje.
| Kontekst | Cel |
|---|---|
| iOS | Universal Link, App Store albo web mobile |
| Android | Android App Link, Google Play albo web mobile |
| Desktop | Landing, signup, dashboard albo QR handoff |
| Tablet | Często desktop web |
| Webview social | Bridge page, gdy deep link nie działa |
| Nieznane urządzenie | Stabilny web fallback |
Po Firebase Dynamic Links zespoły aplikacyjne muszą posiadać tę warstwę. UrlEdge obsługuje device routing i fallback; natywne otwieranie appki nadal wymaga Universal Links i Android App Links.
A/B przez redirect, gdy zmienia się destination
To działa dla:
- landing A vs landing B
- lokalna oferta vs globalna oferta
- nowy checkout dla małego procentu ruchu
- canary release storefrontu
- rotacja stron partnerów lub afiliantów
Nie jest to pełna platforma experimentation.
| Decyzja | Domyślnie |
|---|---|
| Kod | 302 lub 307 dla testu |
| Spójność | Ten sam wariant dla powracającego użytkownika |
| SEO | Bez innego doświadczenia dla crawlerów |
| Canonical | Jasny, jeśli warianty mają osobne URL |
| Czas | Zamknąć test po decyzji |
| Rollout | Zwiększać wagi etapami |
Google zaleca unikanie cloakingu i używanie tymczasowych redirectów podczas kierowania na wariant testowy.
Warunki potrzebują kolejności
| Priorytet | Warunek | Przykład |
|---|---|---|
| 1 | Safety/legal | Kraj bez obsługi na jasną stronę |
| 2 | Kampania | ?campaign=partner wygrywa |
| 3 | Urządzenie/OS | iOS, Android, desktop mają różne cele |
| 4 | Kraj/język | Polska, UE lub global |
| 5 | Waga A/B | Tylko kwalifikowany ruch |
| 6 | Fallback | Reszta trafia stabilnie |
Zła kolejność psuje atrybucję, wykluczenia i testy.
UTM-y są częścią trasy
| Polityka | Kiedy |
|---|---|
| Zachowaj wszystko | Zaufane źródło |
| Allowlist | UTM, click ID, afiliacja |
| Dodaj defaults | Standaryzacja kampanii |
| Usuń wszystko | Wrażliwy cel |
| Przepisz | Parametr wybiera ścieżkę lub cel |
QA przed ruchem
Sprawdź kraje, urządzenia, UTM-y, paid/organic/affiliate/QR, powracających użytkowników w A/B, statusy, hop count, priorytety, fallback, analytics i rollback.
Gdzie pasuje UrlEdge
- Smart Redirect Routing
- Geo Redirects
- Device Targeting
- A/B Testing
- Advanced Redirect Rules
- UTM Builder
- Redirect Checker
- Broken Link Monitor
FAQ
Czym jest Smart Redirect Routing?
To kierowanie jednej URL do różnych miejsc według kraju, urządzenia, języka, parametrów, kampanii, wag A/B i fallbacku.
Czy to geo redirect?
Geo to jeden warunek. Smart routing łączy wiele warunków i priorytetów.
A/B redirect: 301 czy 302?
Zwykle 302, bo test jest tymczasowy.
Źródła
Twórz reguły smart routingu na edge
Kieruj ruch według kraju, urządzenia, języka, parametrów, wag A/B i fallbacku bez ukrywania logiki w aplikacji.
Zobacz smart routingPowiązane artykuły
Zobacz wszystko
Redirect API i reguły jako kod: CI/CD dla bezpieczniejszych zmian URL
Reguły przekierowań to konfiguracja ruchu produkcyjnego. Powinny przechodzić review, walidację, staging, publikację, monitoring i rollback.
Geo redirects dla ecommerce: sklepy krajowe, waluta, język i fallback bez szkody dla SEO
Geo redirects mogą prowadzić kupujących do właściwego sklepu regionalnego, ale zbyt agresywne reguły mogą ukryć strony lokalne.