Smart link: jeden link do App Store, Google Play i strony
Smart link to jeden adres, który iPhone'a wysyła do App Store, Androida do Google Play, a resztę na stronę. Jak serwer rozpoznaje telefon i kraj, jak działa test A/B i czego taki link nie zrobi.
Smart link to jeden krótki adres, który dla każdego odwiedzającego wybiera inny cel: iPhone trafia do App Store, Android do Google Play, komputer na stronę WWW, a gość z Niemiec na niemiecką wersję strony. Ten sam adres może też dzielić ruch między dwie wersje strony w teście A/B. Przydaje się wszędzie tam, gdzie link albo kod QR trafia do wielu osób naraz i nie da się go podmienić: na opakowaniu, plakacie, w opisie profilu. Poniżej pokazujemy na prawdziwych zapytaniach, co serwer widzi przy kliknięciu, w jakiej kolejności podejmuje decyzję, jak zachowuje się test A/B po 500 kliknięciach i gdzie rozpoznawanie urządzenia się myli. W DVN Links reguły według urządzenia i kraju są od planu Pro, a test A/B od planu Business.
Smart link — co to jest (i co jeszcze tak nazywają)
Smart link to krótki link z regułami: zamiast jednego adresu docelowego ma listę warunków i adres dla każdego z nich. Serwer sprawdza warunki przy każdym kliknięciu i odsyła przeglądarkę pod adres pierwszego pasującego. Kto nie pasuje do żadnego warunku, trafia na adres domyślny. Dla odbiorcy wygląda to jak zwykły link: klika albo skanuje kod i po ułamku sekundy jest na właściwej stronie.
Ta sama nazwa ma w internecie co najmniej trzy znaczenia i warto je rozróżnić, zanim zaczniesz czytać porady.
- Link do aplikacji i stron zależnie od urządzenia i kraju — o tym jest ten tekst. Narzędzia do skracania linków opisują to zwykle jako kierowanie według urządzenia i kraju — Dub nazywa funkcję „device targeting” i pisze, że pozwala dobrać adres docelowy „based on the user's device type” (Dub, Device targeting).
- Smart link w muzyce — jedna strona z przyciskami do Spotify, Apple Music czy YouTube przy premierze utworu. Na stronie Linkfire, jednego z dostawców, klientka z wytwórni Deckdisc Records podsumowuje to zdaniem „Artists can promote their releases with just one link” (Linkfire). To inny produkt: strona z listą serwisów, nie przekierowanie.
- Smartlink w marketingu afiliacyjnym — link sieci reklamowej, który sam dobiera ofertę. Trackier definiuje go jako „a tracking URL that can redirect visitors to different eligible offers according to predefined conditions” (Trackier). Mechanika podobna, cel inny: tam o celu decyduje sieć, u nas właściciel linku.
Wspólne jest jedno: odwiedzający dostaje przekierowanie dobrane do siebie. Różni się to, kto ustala reguły i co jest po drugiej stronie. W DVN Links reguły ustawiasz sam, a cel jest zawsze adresem, który wpisałeś.
Jeden kod QR do App Store i Google Play
Najczęstszy powód, dla którego ktoś szuka smart linka, to aplikacja. Masz aplikację na iOS i Androida, a na ulotce, opakowaniu albo naklejce w sklepie jest miejsce na jeden kod QR. Dwa kody obok siebie („iPhone” i „Android”) to dwa razy więcej miejsca i decyzja, którą musi podjąć klient. Jeden kod z regułami robi to za niego.
Ustawienie wygląda tak:
- Adres domyślny — strona aplikacji na Twojej stronie WWW. Trafią na nią komputery i wszystko, czego serwer nie rozpozna.
- Reguła 1: iPhone / iPad → adres aplikacji w App Store (zaczyna się od
apps.apple.com). - Reguła 2: Android → adres w Google Play. Google podaje format wprost:
https://play.google.com/store/apps/details?id=<package_name>, gdzie na końcu jest nazwa pakietu aplikacji, na przykładcom.google.android.apps.mapsdla Map Google (Android Developers, Linking to Google Play).
Kod QR koduje wtedy tylko krótki link. Reguły siedzą na serwerze, więc zmienisz je w panelu bez drukowania kodu na nowo — tak samo jak cel zwykłego krótkiego linku.
Jeden krótki link, trzy cele
ten sam adres otwarty na trzech urządzeniach
Źródło: pomiar DVN Links na lokalnej instancji (prawdziwa trasa przekierowania), 19.10.2026
Opis figury
Schemat: jeden krótki link lub kod QR prowadzi do trzech celów. iPhone dostaje przekierowanie 302 do App Store, Android przekierowanie 302 do Google Play, komputer przekierowanie 302 na stronę WWW. Wynik pomiaru na lokalnej instancji DVN Links z 19 października 2026 roku.
Sprawdziliśmy to na prawdziwej trasie przekierowania DVN Links, uruchomionej lokalnie, z linkiem testowym ustawionym jak wyżej. Zapytanie z przeglądarką iPhone'a dostało odpowiedź 302 z adresem w App Store, zapytanie z Chrome na Androidzie — 302 do Google Play, a Chrome na Windows — 302 na adres domyślny. Te same reguły działają dla przeglądarki wbudowanej w aplikacje: zapytanie z przeglądarką Instagrama na Androidzie też trafiło do Google Play, bo w jej opisie jest słowo „Android”.
Jeden kod do dwóch sklepów ma też koszt, o którym warto wiedzieć przed drukiem: kod na krótkim linku działa tylko wtedy, gdy działa serwis, który przekierowuje. Kod z adresem Google Play wpisanym bezpośrednio przetrwa wszystko, ale nie poprowadzi iPhone'a do App Store. Różnicę między kodem statycznym a kodem na krótkim linku opisujemy w przewodniku Jak zrobić kod QR.
Jak serwer rozpoznaje telefon i kraj
Smart link nie ma dostępu do telefonu. Przy kliknięciu serwer widzi tylko to, co przeglądarka wysyła w zapytaniu, a dla reguł liczą się dwie rzeczy: opis przeglądarki i kraj.
Urządzenie — z nagłówka User-Agent. Każda przeglądarka wysyła tekst, który ją opisuje, na przykład Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) …. Serwer szuka w nim nazwy systemu: iPhone, iPad i iPod to iOS, „Android” to Android, reszta to komputer. MDN, dokumentacja webowa prowadzona przez Mozillę, ostrzega przed traktowaniem tego jak pewnika: „A common misuse of UA sniffing (and client hints) is to detect if the client is a mobile device” (MDN, Browser detection using the user agent). Dla wyboru sklepu z aplikacjami to wystarcza, bo pytamy o system, nie o rozmiar ekranu — ale wyjątki są i jeden jest ważny.
iPad udaje Maca. Od Safari 13 iPad w domyślnym trybie przedstawia się tak jak komputer: „With the exception of iPad mini, Safari on iPad will now send a user-agent string that is identical to Safari on macOS” (WebKit, New WebKit Features in Safari 13). WebKit zaznacza, że dzieje się tak „most of the time”: iPad mini wysyła opis iOS, a strona otwarta lub odświeżona, gdy Safari zajmuje jedną trzecią ekranu przy wielozadaniowości, też dostaje opis iOS. W naszym pomiarze zapytanie z takim opisem trafiło więc nie do App Store, tylko na adres domyślny — serwer zobaczył Maca. Reguła „iPhone / iPad” złapie iPada tylko wtedy, gdy jego przeglądarka wyśle opis z „iPad”. Dlatego adres domyślny nie powinien być ślepą uliczką: strona z dwoma przyciskami („Pobierz z App Store”, „Pobierz z Google Play”) obsłuży i komputer, i iPada.
Kraj — z nagłówka, który dodaje CDN. Ruch do DVN Links przechodzi przez Cloudflare, a ten dokłada do zapytań nagłówek z krajem: „The CF-IPCountry header contains a two-character country code of the originating visitor's country” (Cloudflare, HTTP headers). Kod to dwie litery ISO 3166-1, na przykład PL albo DE. Cloudflare ma też kody specjalne, między innymi XX dla klientów bez danych o kraju i T1 dla sieci Tor — nasza trasa traktuje oba jak brak kraju. Bez Cloudflare po drodze nagłówka po prostu nie ma i reguły według kraju nie zadziałają. Kraj wynika z adresu IP, więc ktoś z polskim VPN-em ustawionym na Niemcy dostanie stronę niemiecką. To cecha każdej reguły według kraju, nie błąd konkretnego narzędzia.
Co widzi serwer przy kliknięciu i dokąd kieruje
osiem zapytań do linku z regułami iOS, Android i DE/AT
Źródło: pomiar DVN Links na lokalnej instancji, kraj ustawiony ręcznie w nagłówku cf-ipcountry, 19.10.2026
Opis figury
Tabela ośmiu zapytań. Safari na iPhonie z Polski i z Niemiec: reguła iOS, 302 do App Store. Chrome na Androidzie z Polski: reguła Android, 302 do Google Play. Przeglądarka Instagrama na Androidzie: reguła Android, 302 do Google Play. Safari na iPadzie, które przedstawia się jak Mac: brak reguły, 302 na adres domyślny. Chrome na Windows z Polski: adres domyślny. Chrome na Windows z Niemiec: reguła kraju DE/AT, 302 na stronę niemiecką. Chrome na Windows bez nagłówka kraju: adres domyślny.
W tej tabeli widać też drugą rzecz: iPhone z Niemiec dostał App Store, nie stronę niemiecką. Nie dlatego, że kraj nie zadziałał, tylko dlatego, że reguła iOS stoi na liście wyżej niż reguła kraju. O kolejności — w następnej sekcji.
Reguły po kolei — jak ustawić smart link
Reguły sprawdzane są od góry do dołu i wygrywa pierwsza pasująca. Reguła pasuje, gdy zgadza się wszystko, co w niej zaznaczyłeś: urządzenie (jeśli wybrałeś urządzenia) i kraj (jeśli wybrałeś kraje). Reguła z urządzeniem „Android” i krajem „DE” złapie tylko Androida z Niemiec. Reguły bez urządzenia i bez kraju nie da się zapisać — przejęłaby cały ruch.
Kolejność, w jakiej smart link wybiera cel
reguły, potem test A/B, na końcu adres domyślny
Źródło: kod DVN Links (src/utilities/smartLink/resolve.ts), stan na 19.10.2026
Opis figury
Schemat decyzji w trzech krokach. Krok pierwszy: reguły od góry — jeśli urządzenie lub kraj pasują, odwiedzający idzie do celu reguły. Jeśli nie, krok drugi: test A/B — jeśli link ma warianty (plan Business), odwiedzający dostaje wariant z cookie albo losowy według udziałów. Jeśli nie, krok trzeci: adres domyślny linku. Pod spodem: reguła bez urządzenia i kraju nie pasuje do nikogo, a po zmianie planu na niższy reguły zostają zapisane, ale krok jest pomijany.
Z kolejności wynika prosta zasada układania listy: najpierw reguły najwęższe, potem najszersze. Przykład dla sklepu internetowego z aplikacją, który sprzedaje w Polsce oraz w Niemczech i Austrii:
|
Kolejność |
Urządzenie |
Kraj |
Cel |
|---|---|---|---|
|
1 |
Android |
DE, AT |
aplikacja w Google Play (DE) |
|
2 |
iPhone |
DE, AT |
aplikacja w App Store (DE) |
|
3 |
— |
DE, AT |
strona sklepu po niemiecku |
|
4 |
Android |
— |
aplikacja w Google Play |
|
5 |
iPhone |
— |
aplikacja w App Store |
|
domyślny |
|
|
strona sklepu po polsku |
Gdyby reguła 3 („cała Austria i Niemcy → strona niemiecka”) stała na górze, niemieckie telefony nigdy nie dotarłyby do sklepu z aplikacjami. W panelu DVN Links regułę przesuwasz strzałkami „Przesuń wyżej” i „Przesuń niżej”; link może mieć do 10 reguł.
Kilka zasad, które wynikają z działania systemu:
- Reguły zmieniasz bez nowego kodu. Kod QR koduje krótki link, nie reguły.
- Każdy cel przechodzi tę samą kontrolę bezpieczeństwa co zwykły link — adres ze złośliwej listy nie zostanie zapisany.
- Linku do pliku nie zapiszesz z regułami ani z testem A/B. Link, który prowadzi do wgranego PDF-a, zawsze otwiera ten plik.
- Po zmianie planu na niższy reguły nie znikają. Zostają zapisane, ale przestają działać: wszyscy trafiają na adres domyślny, a panel pokazuje je jako nieaktywne. Po powrocie na Pro działają od razu.
Tak samo jak przy zwykłym krótkim linku, odpowiedź serwera to przekierowanie tymczasowe 302. Dlaczego przy kampaniach i testach to ma znaczenie, opisujemy w poradniku o skracaniu linków.
Test A/B linku: podział ruchu i ten sam wariant dla powracających
Test A/B w smart linku dzieli ruch między dwie do pięciu wersji strony według udziałów, które ustawisz — na przykład 50/50 albo 80/20. Udział to liczba całkowita od 1 do 99, a wszystkie razem muszą dać 100. Typowe zastosowanie: dwie wersje strony produktu, dwa warianty oferty albo stara i nowa strona docelowa kampanii. Link i kod QR zostają te same, a w statystykach widzisz, ile kliknięć poszło do każdego wariantu. Test A/B jest w planie Business i wyższych.
Ważne są dwie rzeczy: losowanie i pamięć.
Losowanie jest uczciwe tylko w dużej liczbie. Wysłaliśmy 500 zapytań do lokalnej instancji z linkiem 50/50, każde jako nowy odwiedzający (bez cookie). Po 500 kliknięciach wyszło dokładnie 250 do 250, ale po drodze udział wariantu A wahał się: około 20.–30. kliknięcia sięgał 60%, a od setnego kliknięcia odbiegał od 50% najwyżej o 5,9 punktu procentowego (nasz pomiar, 19.10.2026). Wniosek praktyczny: nie oceniaj testu po pierwszym dniu i kilkudziesięciu kliknięciach — przy takiej liczbie różnica między wariantami może być samym przypadkiem.
Test A/B 50/50 — udział wariantu A po kolejnych kliknięciach
500 kliknięć nowych odwiedzających, linia przerywana to 50%
Źródło: pomiar DVN Links na lokalnej instancji (500 zapytań przez trasę przekierowania), 19.10.2026
Opis figury
Wykres liniowy udziału wariantu A w teście 50/50 po kolejnych kliknięciach. Na początku linia skacze od 100% do około 40%, około 20.–30. kliknięcia sięga 60%, od setnego kliknięcia trzyma się między około 44 a 51%, a po 500 kliknięciach kończy na 50,0% — 250 kliknięć wariantu A i 250 wariantu B. Pod wykresem: powracający odwiedzający z cookie dostał ten sam wariant 20 razy na 20, a 30 kliknięć Googlebota zapisało się bez wariantu.
Pamięć chroni wynik przed powracającymi. Ktoś, kto zeskanował kod dwa razy, powinien zobaczyć tę samą stronę — inaczej i on się zgubi, i statystyki policzą go w obu wariantach. Dlatego po pierwszym kliknięciu serwer zapisuje w przeglądarce cookie z wybranym wariantem, ważne 30 dni. W pomiarze odwiedzający z cookie dostał ten sam wariant 20 razy na 20. Cookie działa w jednej przeglądarce: ta sama osoba na telefonie i na komputerze to dla serwera dwie osoby.
Testy a Google. Jeśli test dotyczy stron, które mają być w wynikach wyszukiwania, warto znać wytyczne Google. Po pierwsze, przekierowanie do wariantu ma być tymczasowe: „use a 302 (temporary) redirect, not a 301 (permanent) redirect” — smart link zawsze odpowiada 302. Po drugie, robot Google nie może dostawać innych adresów niż ludzie: „Don't show one set of URLs to Googlebot, and a different set to humans. This is called cloaking”. Po trzecie, Google zaznacza, że „Googlebot generally doesn't support cookies” (Google Search Central, Minimize A/B testing impact in Google Search). W teście A/B smart link traktuje robota jak każdego odwiedzającego bez cookie: losuje mu wariant według tych samych udziałów. W naszym pomiarze 30 zapytań przedstawionych jako Googlebot dostało 15 razy wariant A i 15 razy B — ani jednego adresu spoza testu.
Boty nie psują wyniku. Te same 30 kliknięć Googlebota zapisało się w bazie jako ruch bota, bez przypisanego wariantu, a serwer nie wysłał im cookie. Statystyki wariantów liczą więc tylko ludzi. Tak samo traktowane są inne automaty, które otwierają linki — na przykład podgląd linku w komunikatorach. Jedna różnica dotyczy reguł według urządzenia: robota serwer rozpoznaje jako robota, nie jako telefon, więc reguły „iPhone / iPad” i „Android” go nie łapią — trafia tam, gdzie komputer. Reguły według kraju i test A/B działają dla niego tak samo jak dla ludzi.
Jak sprawdzić smart link przed drukiem
Reguły łatwo ustawić i równie łatwo pomylić — wystarczy jedna reguła za wysoko na liście albo literówka w adresie sklepu. Kod na opakowaniu poprawisz w panelu, ale nakład z błędnym celem przez kilka dni będzie prowadził ludzi w złe miejsce. Dlatego przed wysłaniem pliku do drukarni zrób krótki test:
- Zeskanuj kod iPhone'em i telefonem z Androidem. Każdy ma trafić na stronę swojej aplikacji w sklepie, a nie na stronę główną sklepu ani na komunikat o błędzie.
- Otwórz krótki link na komputerze. Powinna się otworzyć strona z adresu domyślnego. Jeśli masz iPada, sprawdź go osobno — zobaczysz, czy trafia tam, gdzie komputer.
- Sprawdź regułę kraju przez VPN ustawiony na kraj z reguły. Bez VPN-u zobaczysz tylko swój kraj.
- Zajrzyj do statystyk linku. Każde testowe kliknięcie powinno pojawić się z regułą, która je obsłużyła. Jeśli wszystko poszło na adres domyślny, któraś reguła nie pasuje tak, jak zakładałeś.
- Przy teście A/B otwórz link w dwóch różnych przeglądarkach albo w oknie prywatnym. Jedna przeglądarka pamięta wariant przez 30 dni, więc w niej zawsze zobaczysz ten sam.
Ten sam test powtórz po każdej zmianie reguł. Zmiana działa od następnego kliknięcia, więc błąd też.
Smart link nie zawsze jest potrzebny. Jeśli link prowadzi w jedno miejsce dla wszystkich — na przykład do artykułu albo formularza — reguły tylko dokładają rzeczy, które mogą się zepsuć. Sens mają tam, gdzie odbiorcy naprawdę potrzebują różnych celów: aplikacja w dwóch sklepach, oferta w kilku krajach albo dwie wersje strony do porównania.
Czego smart link nie zrobi
Smart link wybiera adres, pod który przeglądarka ma przejść. Na tym jego rola się kończy, i warto to wiedzieć przed kampanią:
- Nie otwiera konkretnego ekranu wewnątrz aplikacji. Prowadzi do strony aplikacji w sklepie albo na stronę WWW. Co dzieje się dalej, zależy od sklepu i telefonu, nie od linku.
- Nie przenosi informacji przez instalację. Po pobraniu aplikacji ze sklepu nie wie ona, z którego kodu QR ktoś przyszedł. Skąd przyszli użytkownicy, sprawdzisz w statystykach linku i w raportach sklepu.
- Nie zgaduje języka. Reguła według kraju patrzy na adres IP, nie na język przeglądarki. Polak w Berlinie dostanie stronę niemiecką.
- Nie rozpozna urządzenia na sto procent. Opis przeglądarki można zmienić, a iPad z Safari domyślnie podaje się za Maca — dlatego adres domyślny powinien działać dla każdego.
- Nie wystawi biletu. Ten sam link dostaje każdy, kto zeskanuje kod, a zrzut kodu działa jak oryginał — czym jest bilet z kodem, piszemy w tekście o biletach z kodem QR.
- Monitoring linków sprawdza tylko adres domyślny. Jeśli masz plan z monitoringiem, alert przyjdzie, gdy przestanie działać główny adres linku. Adresy z reguł i wariantów sprawdzaj sam po każdej zmianie, choćby otwierając je raz w przeglądarce. Jak monitoring odróżnia martwą stronę od takiej, która tylko nie wpuszcza automatów, opisujemy w tekście o błędzie 404.
Smart link a statystyki i UTM
Każde kliknięcie smart linka zapisuje się z informacją, która reguła albo który wariant je obsłużyły. W statystykach linku w panelu widać więc obok łącznej liczby kliknięć osobny wiersz dla każdej reguły i każdego wariantu: ile kliknięć obsłużyła reguła App Store, ile reguła Google Play, a w teście A/B — ile dostał każdy wariant i jaki to procent wobec ustawionego udziału. Adres domyślny nie ma własnego wiersza: to reszta, czyli łączna liczba minus kliknięcia z reguł. W lokalnym pomiarze wszystkie 521 kliknięć ludzi w teście A/B zapisało się z wariantem, a kliknięcia linku z regułami — z numerem reguły tam, gdzie któraś zadziałała.
Parametry UTM ustawione na linku są doklejane do każdego celu — do adresu domyślnego, do adresów z reguł i do wariantów testu. Google Analytics przypisze do kampanii ruch, który wylądował na Twojej stronie — z adresu domyślnego, z wariantów testu i z reguł prowadzących na stronę. Wizyty w App Store i Google Play do Twojej analityki nie trafią; ich liczbę zobaczysz w statystykach linku i w raportach sklepu. Jak nazywać parametry, żeby raporty się nie rozjeżdżały, opisujemy w tekście UTM — co to jest.
Najczęstsze pytania
Nie. W DVN Links reguły według urządzenia i kraju są w planie Pro i wyższych, a test A/B w planie Business i wyższych. Zwykłe krótkie linki i kody QR działają w każdym planie. Aktualne ceny i limity są w cenniku.
Do 10 reguł i do 5 wariantów testu A/B. Reguły sprawdzane są po kolei, wygrywa pierwsza pasująca, a kto nie pasuje do żadnej, trafia na adres domyślny.
Nie. Kod QR koduje krótki link, a reguły są zapisane na serwerze. Zmiana reguły działa od następnego kliknięcia.
Tak, o ile przeglądarka wbudowana w aplikację podaje nazwę systemu (sprawdziliśmy przeglądarkę Instagrama na Androidzie). W naszym pomiarze przeglądarka Instagrama na Androidzie trafiła do Google Play tak samo jak Chrome.
Robot jest traktowany jak komputer: reguły według kraju i test A/B działają dla niego tak samo jak dla ludzi, reguły według urządzenia — nie. Jego kliknięcia nie liczą się do statystyk, a serwer nie wysyła mu cookie z wariantem.
Google podaje wytyczne dla takich testów: przekierowanie ma być tymczasowe (302), a robot nie może dostawać innych adresów niż ludzie. Test A/B w smart linku spełnia oba warunki. Na stronach wariantów Google zaleca rel="canonical" wskazujący stronę oryginalną zamiast noindex — to ustawiasz na swojej stronie, nie w linku. Google ostrzega też przed testami prowadzonymi dłużej, niż to potrzebne (Google Search Central). Czym 302 różni się od 301 dla Google i przeglądarki, opisujemy w tekście o przekierowaniu 301.
Reguły Smart link ustawisz w panelu, w ustawieniach linku — od planu Pro.