Co się dzieje z linkiem do aplikacji otwartym w Instagramie i TikToku: zmierzyliśmy 74,000 przekierowań

Te liczby pochodzą z logów przekierowań usługi inteligentnych linków: jeden adres URL, który kieruje telefon do App Store lub Google Play. Za każdym razem, gdy link zostaje otwarty w aplikacji społecznościowej, serwujemy małą stronę, która przekazuje odwiedzającego do sklepu, a ta strona raportuje, co stało się potem. Poniżej: co mówią te raporty, jak je zmierzyliśmy i gdzie pomiar się kończy.

Dane

Dwie rzeczy widać jeszcze przed jakąkolwiek analizą. Aplikacje Meta przysyłają dużo więcej ruchu niż TikTok. A na Androidzie ponad trzy czwarte wszystkich wejść przychodzi przez przeglądarkę w aplikacji, a nie przez Chrome.

Jak strona raportuje, co się stało

Gdy link zostaje otwarty w przeglądarce wbudowanej w aplikację, strona robi trzy rzeczy i dla każdej wysyła beacon:

• auto: przy ładowaniu rozpoczyna przekazanie do sklepu (iOS: location.replace na adres App Store; Android: adres intent://, który otwiera natywną aplikację Play Store).
• exit: strona zostaje ukryta (Page Visibility API). To najlepszy sygnał, jaki ma strona internetowa, że coś, najpewniej sklep, przejęło ekran.
• stuck: strona jest nadal widoczna 2.2 sekundy po przekazaniu, więc pokazuje kartę awaryjną z przyciskiem sklepu, wskazówką „otwórz w przeglądarce” i przyciskiem kopiowania linku.

Strona internetowa nie widzi App Store ani Play Store. Wszystko poniżej jest wywnioskowane z tych trzech sygnałów, a sekcja o ograniczeniach mówi, gdzie to wnioskowanie przestaje działać.

Wniosek 1: mniej więcej 1 na 11 wejść z Meta na Androidzie to preload, którego nikt nie widział

W ciągu 30 dni do 12 października wyraźna grupa sesji na Androidzie zachowywała się tak, jak nie zachowałaby się żadna wizyta człowieka: strona się ładowała, licznik przekazania nigdy nie ruszał, a strona była niszczona 29 do 31 sekund później. Brak auto, brak stuck, brak dotknięcia. Na iOS nie było niczego podobnego.

To podpis przeglądarki w aplikacji Instagrama i Facebooka, która wstępnie ładuje link z feedu, trzyma go ukrytego i wyrzuca, gdy użytkownik przewija dalej. Strona wykonała nasz JavaScript, więc wejście zostało zapisane. Nikt nigdy na nie nie spojrzał.

Sprawdziliśmy kryterium na sesjach, które były wyraźnie ludzkie: spełniało je 0 z 17,606 sesji, w których sklep otworzył się 2–3 s po przekazaniu, i 0 z 244 sesji, w których ktoś dotknął przycisku sklepu.

Udział zmienia się z tygodnia na tydzień: 6.8% w ostatnim tygodniu tego okresu, a wcześniej 8.8%, 10.6% i 10.0%. Koncentruje się też tam, gdzie działają płatne kampanie na Instagramie: 72% preloadów w tym okresie pochodziło z jednego linku za dużą kampanią na Instagramie.

Od 16 października strona sama klasyfikuje to w czasie działania: zgłasza preload zamiast wyjścia, gdy ginie po co najmniej 20 s, nie będąc nigdy pokazana. Oto co wyłapała od tamtej pory:

Ten licznik w czasie działania to dolna granica. Preload, który ginie, nie wykonując żadnego skryptu, nie zostawia beaconu, a reguła w czasie działania jest surowsza niż historyczna rekonstrukcja.

Dlaczego to ważne. Jeśli liczysz kliknięcia na przekierowaniu, mniej więcej jedno na 13 „kliknięć” z Instagrama na Androidzie nigdy nie zostało zobaczone przez człowieka. Twój stosunek kliknięć do instalacji dla tego kanału wygląda gorzej, niż jest, a panel kampanii zbudowany na surowych trafieniach przekierowania zawyża zasięg mniej więcej o tyle.

Wniosek 2: TikTok blokuje Play Store zależnie od tego, którego webview używa

W TikToku na Androidzie część odwiedzających nigdy nie opuszcza strony: przekazanie zostaje uruchomione, a TikTok pokazuje własne okno („The action cannot be completed”). Nie dzieje się to przy każdym linku i przez tygodnie wyglądało na zależne od linku. Nie jest. Zależy od przeglądarki w aplikacji, której TikTok używa dla danego odwiedzającego, a zdradza ją user-agent:

Sesja liczy się jako udana, gdy przekazanie zostało uruchomione, a strona się ukryła, i jako nieudana, gdy pojawiła się karta awaryjna. Odsetek to udane / (udane + nieudane), na urządzenie i dzień:

Porównanie, które rozstrzyga sprawę, utrzymuje stały link i dzień, bo proporcje formatów zmieniają się z tygodnia na tydzień:

Ten sam link, ten sam kod przekierowania, ten sam dzień: jeden webview pozwala otworzyć sklep, a drugi przeważnie nie. Własne domeny nie robiły różnicy w danych z 90 dni. TikTok nie dokumentuje tego okna, tego, co je wywołuje, ani tego, którzy użytkownicy dostają który webview, więc podział według user-agenta to wszystko, co mamy.

Dlaczego to ważne. Żadna postać adresu URL tego nie naprawia: wyjście przez intent:// i zwykły adres https://play.google.com dostają tę samą odmowę. Możesz natomiast nie ukrywać wyjścia: w TikToku pokaż od razu instrukcję „otwórz w przeglądarce” i przycisk kopiowania, zamiast po upływie limitu czasu.

Wniosek 3: na iOS App Store otwiera się nad przeglądarką w aplikacji

Na Androidzie po przekazaniu strona w większości sesji się ukrywa, zwykle 1 do 3 sekund później. Na iOS w Instagramie i Facebooku często tak się nie dzieje, choć przekazanie zostało uruchomione niemal w każdej sesji:

Gdyby dwie trzecie odwiedzających z iOS naprawdę utknęły przed widoczną kartą awaryjną z przyciskiem „Otwórz App Store”, spora część by go dotknęła. Tak się nie dzieje: przycisku dotyka 0.9% załadowań stron na iOS w Instagramie i 0.4% w Facebooku. Nie ma też wersji iOS, na której to „działa”:

Pasujące wyjaśnienie jest takie, że w Instagramie i Facebooku na iOS App Store pojawia się nad przeglądarką w aplikacji, nie spychając jej w tło. Strona przez cały czas pozostaje „widoczna”, więc visibilitychange i pagehide nigdy się nie uruchamiają, choć odwiedzający patrzy na App Store.

Dlaczego to ważne. Każda metryka, która wnioskuje o otwarciu sklepu z tego, że strona znika z ekranu, jest na iOS błędna. Kiedyś pokazywaliśmy klientom odsetek „zasięgu sklepu” zbudowany dokładnie w ten sposób i mówił on 10 z 12 płacących klientów, że działające linki są zepsute. Usunęliśmy go. Na iOS wiarygodny sygnał instalacji jest po stronie sklepu: raporty kampanii w App Store Connect, z tokenem dostawcy (pt) i tokenem kampanii (ct) w adresie App Store.

Mniejsze rzeczy, które zmierzyliśmy po drodze

• Play Store pojawia się na Androidzie powoli. W sesjach z Instagrama na Androidzie, w których przekazanie zostało uruchomione, strona ukryła się 0–1 s po wejściu w 1,061 sesjach, 2–3 s po nim w 2,596 i 4–8 s po nim w 1,273 (7 dni). Licznik 2 sekund sprawdzający „czy zadziałało?” odpala się, zanim sklep się pojawi, w dużej części prawdziwych sukcesów. Nasz własny lejek liczył je jako porażki, dopóki nie pozwoliliśmy, by wyjście do 8 s po przekazaniu nadal się liczyło.
• Prawdziwy odsetek porażek jest mały. W 7,357 sesjach z Instagrama na Androidzie, odtworzonych z 3 dni na początku października, wzorzec „przekazanie, a potem nic” dotyczył 1.9% sesji, a 24.3% tych odwiedzających dotknęło linku ponownie w ciągu 3 minut. Odwiedzający, którym pokazała się karta awaryjna, dotykali ponownie w 5.4% przypadków, mniej więcej jak ci, którym sklep się otworzył (4.6%): większość tych „porażek” nie była porażkami.
• Wymaganie dotknięcia kosztuje większość ruchu. Zanim strona zaczęła uruchamiać przekazanie przy ładowaniu, pokazywała kartę z przyciskiem sklepu. W ciągu 30 dni 10,523 wejść w aplikacjach dało 2,119 dotknięć: około 80% odwiedzających nigdy nie dotarło do sklepu.

Metoda

• Źródło. Każde wejście na inteligentny link i każdy beacon ze strony przekazania jest zapisywany w Cloudflare Workers Analytics Engine z platformą, przeglądarką w aplikacji (z user-agenta), rodzajem zdarzenia i znacznikiem czasu z dokładnością do sekundy. Odwiedzający, których user-agent deklaruje bota, crawlera lub pobieracz podglądu linków, są trzymani osobno i wyłączeni ze wszystkich liczb tutaj.
• Sesje. Analytics Engine nie ma identyfikatora załadowania strony, więc sesje odtwarzamy, łącząc wejście z beaconami o tym samym linku, kraju, mieście, user-agencie i przeglądarce w aplikacji w ciągu następnej godziny, aż do kolejnego wejścia z tym samym kluczem. Około 98% beaconów zostaje przypisanych do wejścia.
• Preloady (wniosek 1). Kryterium historyczne: brak przekazania, brak karty awaryjnej, brak dotknięcia i wyjście 20 s do 15 min po wejściu. Kryterium w czasie działania od 2026-10-16: strona zgłasza preload, gdy ginie po co najmniej 20 s, nie będąc nigdy pokazana, a jej licznik przekazania nigdy nie ruszył (albo załadowała się ukryta). Beacon niesie jednorazowy podpisany token, więc nie da się go odtworzyć, by wymazać prawdziwą wizytę.
• TikTok (wniosek 2). Sesje kluczowane linkiem, modelem urządzenia, wersją aplikacji TikTok i dniem. Reguła formatu: wersja musical_ly_ z kropkami → A; w przeciwnym razie JsSdk → B; w przeciwnym razie C. Odwiedzający z sieci hostingowych są liczeni osobno i pominięci w tabeli. Ponowny pomiar z 30 dni używa tego samego skryptu co pierwotna analiza z 90 dni.
• Sumy uwzględniają interwał próbkowania Analytics Engine (2–4% wierszy reprezentuje więcej niż jedno zdarzenie). Tabele sesji liczą wiersze.

Ograniczenia

• Nigdy nie widzimy sklepu. „Strona ukryta” to przybliżenie „sklep się otworzył”. Uruchamia się też, gdy odwiedzający przełącza aplikację lub blokuje telefon.
• Znaczniki czasu mają dokładność do sekundy, a sesje to rekonstrukcje. Dwa szybkie załadowania z tego samego urządzenia mogą się połączyć.
• Koncentracja. Kilka dużych linków dominuje w niektórych okresach: jedna kampania na Instagramie odpowiada za 72% preloadów z 30 dni, a dwa linki niosą większość sesji z TikToka. Właśnie dlatego istnieją tabele dla tego samego linku.
• Nic z tego nie zostało sprawdzone na fizycznym telefonie. Zachowania są wywnioskowane z tego, co raportują strony. Wyjaśnienie dla iOS we wniosku 3 to to, które pasuje do danych, a nie coś, co widzieliśmy na własne oczy.
• To nasz ruch. To odwiedzający aplikacji, które korzystają z naszych linków, z dużą przewagą kampanii na Instagramie i Facebooku w kilku krajach. Inna mieszanka da inne odsetki, choć mechanizmy powinny być te same.
• Preloady, które nigdy nie wykonują JavaScriptu, są niewidoczne. 12% załadowań stron w Instagramie na Androidzie nie wysyła żadnego beaconu i część z nich to prawdopodobnie także preloady.

Co z tym zrobić

1. Uruchamiaj przekazanie przy ładowaniu. Strona, która czeka na dotknięcie, traci większość odwiedzających z aplikacji. Zostaw ręczny przycisk jako zapas, pokazywany tylko wtedy, gdy przekazanie wyraźnie się nie udało.
2. Na Androidzie używaj `intent://` z `S.browser_fallback_url`. Adres https://play.google.com w webview otwiera stronę internetową Play Store, która bez logowania niczego nie zainstaluje.
3. Daj wolnemu sklepowi czas. Odczekaj co najmniej 3 s, zanim uznasz, że przekazanie się nie udało, i nadal licz późne wyjście.
4. W TikToku pokaż wyjście od razu: „··· → Otwórz w przeglądarce” i przycisk kopiowania linku. Żadna zmiana adresu URL nie usunie odmowy TikToka.
5. Nie licz preloadów Meta jako kliknięć. Jeśli raportujesz kliknięcia z przekierowania, licz się z tym, że 2–9% wejść z Instagrama i Facebooka na Androidzie to strony, których nikt nie widział.
6. Mierz instalacje w sklepie, linkami kampanii App Store Connect (pt + ct) na iOS i Play Install Referrer na Androidzie, a nie zdarzeniami na stronie.

Tworzymy onestore.link, który domyślnie robi wszystkie sześć rzeczy dla każdego linku, a powyższe dane pochodzą z jego logów przekierowań.

Pytania i odpowiedzi