Links diretos

Deep linking é a prática de usar uma única URL para enviar um usuário diretamente a uma tela, produto ou conteúdo específico dentro de um app mobile, em vez da tela inicial do app’s ou de uma página web mobile. Um deep link carrega um destino e, geralmente, um payload como um ID de produto, um código promocional, um token de referência ou um ID de atribuição, que o app lê ao abrir e usa para renderizar a experiência certa.

Tudo o resto nesta página é uma variação dessa ideia. O deep linking complica-se porque um link tem de sobreviver a três ambientes separados no caminho até à sua app: a página web ou anúncio que o aloja, a plataforma onde o utilizador tocou, e o sistema operativo que decide qual app abre. Cada camada pode quebrar o link silenciosamente, e cada uma fá-lo de forma diferente.

Resumindo:

• Um deep link é uma URL que abre um destino específico no app e envia dados para o app ao abrir.
• Há 3 camadas para acertar: deep links web (a URL e seus arquivos de associação), deep links de plataforma (como Instagram, Meta, Reddit, TikTok, e-mail e SMS lidam com seu link), e deep links de app (o mecanismo do SO: Universal Links no iOS, App Links no Android, esquemas de URI como fallback legado).
• Deep linking adiado cobre usuários que ainda não têm o app: clique, instale e caia na tela certa. Exige um SDK de atribuição. Nenhum sistema operacional oferece isso nativamente.
• Navegadores in-app em plataformas sociais são o motivo mais comum para um deep link configurado corretamente ainda não abrir o app.
• As plataformas de anúncios se dividem em 2 grupos, e o grupo decide onde você configura deep links.
• Singular é um dos 5 parceiros de atribuição de apps que o Google suporta para deep linking adiado no Google Ads, e um dos apenas 2 que não precisam de configuração adicional para ativá-lo.
• Deep links só valem a pena se você puder medi-los. Os links de rastreamento da Singular são criados para suportar deep links e deep links adiados assim que seu app estiver configurado.

Antes da implementação, ajuda saber qual camada você está depurando. A maioria dos tickets de “deep link quebrado” é um problema em uma camada específica.

Camada 1: Deep links da web

Um deep link web é uma URL HTTPS comum, por exemplo https://example.com/product/123, que foi reivindicada pelo seu app. Quando o SO a vê, ele verifica se o seu app é dono daquele domínio. Se sim, abre o app. Se não, carrega a página web.

Tanto o iOS quanto o Android exigem que você publique um arquivo de associação legível por máquina, comprovando que o app e o domínio pertencem ao mesmo proprietário.

No iOS, esse arquivo é o apple-app-site-association, servido sem extensão de arquivo via HTTPS a partir da raiz do seu domínio ou de /.well-known/, com preferência para /.well-known/ , emparelhado com uma permissão de Associated Domains no app usando o prefixo applinks: . A Apple re-rastreia o arquivo periodicamente, então as mudanças não são instantâneas. Consulte a documentação da Apple sobre domínios associados para a especificação atual.

No Android, o equivalente é assetlinks.json em /.well-known/assetlinks.json, listando o nome do pacote e a impressão digital do certificado de assinatura, emparelhado com android:autoVerify=”true” no filtro de intent relevante. O guia do Google para verificar App Links cobre as regras de hospedagem, que são mais rígidas do que a maioria das equipes espera.

Regras de hospedagem que pegam as equipes de surpresa

Elas se aplicam a ambas as plataformas e respondem por uma grande parcela das falhas de verificação:

• Apenas HTTPS. Nenhum sistema operacional buscará o arquivo via HTTP simples.
• Sem redirecionamentos. Se /.well-known/assetlinks.json retornar 301 em qualquer lugar, até para outra URL HTTPS no mesmo domínio, o Android não vai segui-lo.
• Content-Type correto. application/json para assetlinks.json. O arquivo da Apple deve ser servido como JSON sem a extensão .json no nome do arquivo.
• Sem autenticação. O arquivo deve ser publicamente legível, sem cookies, tokens ou cabeçalhos.
• Não bloqueie os crawlers. Se o seu robots.txt bloquear AdsBot-Google ou AdsBot-Google-Mobile de /.well-known/assetlinks.json ou /.well-known/apple-app-site-association, o Google Ads não consegue validar seus arquivos de associação, o que falha na validação de deep links para campanhas de anúncios.

Deep linking, SEO e a correspondência de conteúdo app-para-web

O deep linking não altera como suas páginas web são indexadas. Os mecanismos de busca indexam conteúdo web, não conteúdo de app. Mas há uma regra de UX que importa tanto para o score de qualidade quanto para a confiança do usuário: a tela do app que um link abre deve corresponder à página web que substituiu. Se um snippet de busca promete uma página de produto e o app abre em um feed inicial, você criou uma incompatibilidade que os usuários notam.

Para equipes que executam mobile web e app em paralelo, isso conecta diretamente a atribuição web, onde você precisa de uma visão única de uma jornada que começa no navegador e termina no app.

Camada 2: Deep links de plataforma

É aqui que a maioria dos deep links do mundo real falha, e é a camada que os profissionais de marketing controlam mais diretamente.

O problema é o navegador in-app. A maioria das grandes plataformas sociais abre links tocados dentro do app em uma webview incorporada, em vez de entregar a URL ao sistema operacional. Universal Links e App Links dependem dessa transferência no nível do SO. Dentro de uma webview incorporada, a transferência geralmente é suprimida, então um usuário que tem seu app instalado ainda cai no seu site mobile.

As plataformas fazem isso por motivos que não têm nada a ver com você: manter o usuário a um toque do feed e reter a capacidade de observar o comportamento na página de destino.

Comportamento documentado de links por canal

O comportamento varia por canal e por sistema operacional, e não é simétrico. A tabela abaixo reflete o comportamento de redirecionamento documentado da Singularpara links em canais próprios e orgânicos.

Três pontos importantes.

E-mail e mensagens nativas são a zona segura

Gmail, Apple Mail, iMessage e WhatsApp lidam com deep links e fallbacks de loja em ambas as plataformas. Se você quer um comportamento previsível, comece por aí.

Feeds sociais precisam de um intermediário

Facebook, YouTube, Slack e X renderizam links em navegadores in-app que suprimem a transferência do SO. Uma landing page no meio que re-dispara o link como ação do usuário é a solução.

Instagram e Reddit precisam de planejamento, não de correção

O Instagram não faz deep link no Android e não recorre à App Store no iOS. O Reddit não faz nenhum dos dois em nenhuma plataforma. Se algum deles for um canal relevante para você, projete a experiência de destino deliberadamente, em vez de assumir que o link resolve.

Controlando como seus links são visualizados

Separadamente do roteamento, o cartão de pré-visualização que um link renderiza quando compartilhado é controlado pelas tags Open Graph. Singular suporta Título OG, Descrição OG e URL de imagem OG opcionais em links de Origem Personalizada, definidos em Gerenciar Links ou substituídos dinamicamente no momento do clique. A personalização da pré-visualização é suportada em Facebook, Instagram, Google, Gmail, LinkedIn, X, Reddit, Discord, Pinterest, Slack, Telegram, WhatsApp, Snap, TikTok, Viber, LINE, KakaoTalk, Tumblr, Quora, QQ, WeChat e iMessage.

Soluções alternativas para navegador no aplicativo

Nenhuma dessas é elegante. Todas são melhores do que perder a sessão.

1. Uma página intersticial “abrir no app”. Uma página intermediária que re-dispara o link como uma ação do usuário. Singular cria isso automaticamente como a Social Landing Page, sem página para construir. Você a ativa por link alternando Enable Landing Page em Social Link Settings em Manage Links. Está disponível para links de Custom Source, Mobile links Web-to-App, e links de parceiros para parceiros específicos onde deep linking é bloqueado. O fluxo padrão é um botão de CTA que o usuário toca. Quando o link tem um esquema de app e um destino de deep link configurado e o sinalizador de redirecionamento forçado está definido para essa plataforma, a página pode abrir o app ao carregar sem toque. Android tem redirecionamento forçado habilitado por padrão; no iOS você o ativa anexando _force_redirect=true. Os usuários podem ver brevemente uma tela branca antes do app abrir.

Duas condições que vale a pena conhecer. Não ative em um link sem destino de deep link, pois não há para onde a página rotear. E se o app já estiver instalado, o iOS tentará abri-lo diretamente, pulando a landing page e qualquer URL de fallback. Esse comportamento não pode ser substituído.

1. Uma landing page hospedada pelo cliente. Se você quer controle total do design, hospede a sua e rastreie o clique na página ou incorpore o link de rastreamento nela. Decida a qual touchpoint você quer atribuir a instalação antes de construir.
2. Transferência via QR para desktop e out-of-home. A leitura pelo app de câmera contorna o problema completamente. Singular gera um código QR automaticamente para cada link de fonte personalizado, em PNG e SVG.
3. Smart banners na sua mobile página web. Menos toques, mas sem risco de engenharia.

A consequência de medição importa tanto quanto a de UX. Se um usuário fica preso em um webview, essa sessão é atribuída ao mobile web em vez do seu app. Seu ROAS de canal parecerá pior do que é e seus números de engajamento no app parecerão mais fracos do que a realidade.

Plataformas de anúncios: a divisão de auto-atribuição

As plataformas de anúncios se dividem em 2 grupos, e o grupo determina onde você configura os deep links.

• Redes de autoatribuição executam sua própria atribuição e não aceitam links de rastreamento MMP para campanhas de app . Meta, Google Ads, Snapchat, TikTok e X Ads funcionam assim. Você configura deep links no painel do próprio parceiro, e o comportamento adiado vem da integração MMP, não de um link. Com a Singular, o deep linking adiado é ativado automaticamente para Google Ads, Snapchat e TikTok Ads assim que a Configuração de Parceiro é ativada. Para Meta, é ativado pelo seu Singular gerente de sucesso do cliente, e a função equivalente deve ser desativada no SDK do Facebook para evitar que dois sistemas disputem o mesmo destino.

O Google publica uma lista de parceiros de atribuição de apps que ele suporta para deep linking adiado no Google Ads. Singular está nessa lista e é um dos apenas 2 parceiros que não exigem configurações adicionais para ativar postbacks de deep link adiado. Os outros precisam de alternâncias de integração, um ticket de suporte ou uma verificação de configuração.

• As campanhas web nessas mesmas plataformas são diferentes. Campanhas web da Meta com objetivos de Vendas ou Tráfego, e campanhas web do TikTok, passam por Singular links de rastreamento, que é exatamente onde a Social Landing Page importa. O navegador in-app do Facebook não suporta iOS Universal Links nem Android App Links, e o do TikTok suprime iOS Universal Links, então uma campanha web-to-app em qualquer uma das plataformas vai silenciosamente deixar os usuários na tela inicial do seu app sem uma página intermediária.

O Google Ads tem seu próprio requisito para campanhas web que direcionam para um app instalado, incluindo Search e Performance Max. A URL final precisa ser um App Link nativo ou Universal Link, porque a política do Google Ads exige que o destino do clique aponte diretamente para a página de destino final. Esquemas de URI personalizados e links baseados em redirecionamento não são aceitos lá. Esse é um requisito apenas para a URL final, então você pode manter sua configuração de links existente em outros canais e adicionar links nativos para o Google Ads junto com ela.

Tudo o resto ou aceita redirecionamentos de links de rastreamento ou integra servidor a servidor. Para parceiros que aceitam redirecionamentos, o seu link de rastreamento entrega a experiência de deep link diretamente. Para parceiros assíncronos, a notificação de clique chega depois e o deep link é configurado no painel de campanhas do parceiro.

O problema recorrente com parceiros não auto-atribuíveis é o embrulho de links. Quando um parceiro embrulha seu link de rastreamento em seu próprio redirecionamento, os Universal Links param de funcionar, porque a Apple exige intenção direta do usuário por trás do roteamento. É para isso que existe o fallback de redirecionamento forçado. Deep linking adiado não é afetado pelo embrulho, porque ele roda via SDK em vez da cadeia de redirecionamento.

Camada 3: Deep links de aplicativo

Quando um link chega ao sistema operacional, um dos 3 mecanismos o processa.

Esquemas de URI (legado)

Um esquema personalizado como myapp://product/123. O app registra o esquema na instalação e o SO roteia qualquer coisa que comece com myapp:// para ele.

• Funciona: quando o app está instalado, na maioria dos contextos, incluindo muitos webviews.
• Falha: quando o app não está instalado. O usuário recebe um erro ou nada.
• Diferido: não por si só. Singular ainda pode carregar um destino diferido em um link baseado em esquema via SDK usando o parâmetro _ddl .
• Segurança: qualquer app pode registrar o mesmo esquema, então os esquemas podem ser sequestrados. O Google Ads não os aceita como URL final por esse motivo.
• Ainda útil como: fallback dentro de navegadores in-app, e como deep link em uma página de produto personalizada da App Store.

Universal Links do iOS (iOS 9+)

Uma URL HTTPS reivindicada pelo seu app via entitlement de Domínios Associados e o arquivo apple-app-site-association .

• App instalado, o app abre na tela correta.
• App não instalado, sua página web carrega, o que pode direcionar para a App Store. Levar o usuário à tela correta após essa instalação é deep linking adiado, que o SDK gerencia em vez do tipo de link.
• Sem estado de erro, sem sequestro de esquema, funciona a partir do Safari, Mail, Mensagens e na maioria dos contextos não-webview.

Android App Links (Android 6.0+)

Uma URL HTTPS verificada por meio de assetlinks.json e android:autoVerify.

• Verificado: abre o app diretamente, sem diálogo de escolha, e nenhum outro app pode reivindicar a URL.
• Não verificado: no Android 12 e versões posteriores, a verificação é por filtro de intent, efetivamente por host, e um link não verificado vai silenciosamente para o navegador, sem diálogo de desambiguação. Não há erro visível ao usuário, o que torna fácil passar despercebida uma verificação quebrada.
• Android 15+ adiciona Dynamic App Links. Você declara um filtro de intent amplo no manifesto e define regras de roteamento específicas em assetlinks.json no seu servidor, incluindo exclusões de caminho e regras baseadas em parâmetros de consulta ou fragmentos de URL. Dispositivos com Google Play services buscam o arquivo novamente aproximadamente uma vez por semana, então você pode alterar o roteamento sem lançar uma nova versão do app.

Duas restrições dos Dynamic App Links são fáceis de ignorar. As regras do lado do servidor só podem restringir o escopo declarado no seu manifest, nunca expandi-lo. E dispositivos com Android 14 ou anterior ignoram totalmente as regras dinâmicas e recorrem ao manifest, o que mantém a mudança compatível com versões anteriores, mas significa que você não pode contar com isso para toda a sua base instalada.

O Google também oferece correção de deep links no Play Console, permitindo que equipes Android façam ajustes ad hoc nas configurações de App Link na versão atual do app sem precisar de um novo lançamento.

O deep linking adiado lida com o usuário que ainda não tem seu app. Ele clica em um link, chega à loja, instala, abre, e o app ainda sabe para onde ele estava indo.

Nenhum sistema operacional oferece isso. Apple e Google não oferecem mecanismo adiado. Funciona porque um SDK de atribuição fica dos dois lados da instalação: o provedor registra o clique pré-instalação e seu contexto, o SDK recupera esse contexto no primeiro acesso, e seu app lê o destino e renderiza a tela pretendida. É por isso que deep linking adiado é uma capacidade de MMP, não um recurso de plataforma.

A realidade de 2026 nas taxas de correspondência

Com a App Tracking Transparency limitando a disponibilidade do IDFA, a correspondência determinística no iOS não está disponível para a maioria dos usuários, e o deep linking adiado recorre à correspondência probabilística com base em sinais como IP, user agent, dimensões de tela, localidade e fuso horário. A precisão varia muito e degrada em redes compartilhadas, NAT de operadora e quando o iCloud Private Relay está ativo. Duas regras práticas seguem:

• Quanto menor a janela de clique para instalação, maior a taxa de correspondência. Otimize o carregamento da página da loja e o fluxo de instalação, não apenas o link.
• Projete para a falha. A experiência de primeira execução do seu app deve degradar-se graciosamente para uma tela padrão sensata em vez de um estado em branco, porque uma parcela significativa de links adiados não será resolvida.

No Android, o GAID continua disponível sujeito à exclusão do usuário, então a correspondência determinística adiada ainda é viável. O Android Privacy Sandbox do Google foi descontinuado em 17 de outubro de 2025, com a Attribution Reporting API entre as tecnologias aposentadas tanto no Chrome quanto no Android. A consequência prática para o planejamento de medição no Android é que o GAID é o modelo operacional, e não um modelo transitório.

Páginas de produto personalizadas da App Store podem conter um deep link

No iOS 18 e iPadOS 18 ou versões posteriores, você pode anexar um deep link de app a uma página de produto personalizada da App Store. Quando um usuário que já tem o app toca em Abrir nessa página, ele chega ao destino no app especificado em vez da tela inicial. O deep link pode ser um Universal Link ou um esquema de URL personalizado, e deve ser enviado para revisão junto com a página de produto personalizada.

A Apple recomenda Universal Links aqui e desaconselha encurtadores de URL ou serviços que adicionam redirecionamentos. Teste ambos em um dispositivo com iOS 18 ou posterior antes de se comprometer, pois o arquivo apple-app-site-association é buscado de forma assíncrona e pode não ser resolvido imediatamente após a instalação.

Tipos de deep link comparados

Nota sobre a coluna de adiamento. Nenhum tipo de link fornece deep linking adiado por conta própria. Em cada linha acima, o comportamento adiado vem de um SDK de atribuição que mantém o destino durante a instalação.

O Google desativou o Firebase Dynamic Links em 25 de agosto de 2025. O console ficou somente leitura em maio de 2024, e os links existentes em domínios personalizados e page.link subdomínios agora retornam erros 404. O Google não lançou uma substituição direta e apontou as equipes para provedores terceirizados.

A lição duradoura é operacional, não técnica. Muitas equipes descobriram que não tinham um inventário de onde seus links viviam: fluxos de integração, programas de indicação, e-mails de redefinição de senha, QR codes impressos, posicionamentos de parceiros. A quebra apareceu como quedas inexplicáveis na ativação, em vez de um erro que alguém pudesse rastrear. Mantenha um inventário de links ativos, os canais em que operam, quais são links curtos que você pode redirecionar e quem é dono de cada superfície.

Esse último merece destaque. Se o seu app exige autenticação, o fluxo de login deve preservar o destino do deep link e encaminhar o usuário para lá após o login. Deixar o usuário na tela inicial após o login é um assassino silencioso de conversão e uma das lacunas mais comuns entre um deep link que funciona tecnicamente e um que converte.

• Reengajamento e retargeting. Um usuário viu um produto e não comprou. Um anúncio de retargeting com deep link o leva de volta àquele produto exato, ou ao carrinho com um cupom aplicado, em vez de um feed inicial onde ele teria que procurar novamente.
• Web para app. Usuários de app geralmente convertem a uma taxa maior do que usuários mobile web, ajudados por credenciais de pagamento salvas, permissão de push e personalização. O deep linking é o mecanismo que torna essa transição valiosa.
• Canais próprios. E-mail, SMS, push e mensagens no app se beneficiam, e o e-mail em particular tem bom desempenho porque os clientes de e-mail geralmente fazem a transição limpa para o sistema operacional.
• Indicações e compartilhamento. Um link compartilhado que carrega o ID do indicador desde a instalação até a primeira abertura é inteiramente um problema de deep linking adiado.
• Continuidade de integração. Um usuário que se cadastrou no seu site não deveria reiniciar a integração no app.
• Não digital. Links curtos e códigos QR em mídia externa, impressos, embalagens e eventos.

O fio condutor é a retenção. Cada toque extra entre a intenção e o destino é uma chance de desistir.

Medição: a parte que torna os deep links um ativo de marketing

Um deep link que não é medido é uma melhoria de UX. Um deep link que é medido é uma superfície de atribuição.

Há uma falha sutil que vale a pena entender aqui. Quando um usuário toca em um Universal Link com rastreamento habilitado e o app já está instalado, o dispositivo pode abrir o app sem fazer uma requisição HTTP, então alguns rastreadores nunca registram um clique. O roteamento funciona e a medição falha silenciosamente.

Quando um deep link carrega parâmetros de atribuição, você pode responder perguntas que de outra forma seriam impossíveis: qual criativo impulsionou a abertura do app, se uma jornada web-to-app converteu melhor que a web mobile, qual foi o valor incremental do gasto em reengajamento e quanto do seu tráfego “orgânico” no app é, na verdade, tráfego de canal próprio que perdeu sua atribuição em uma webview.

É por isso que o deep linking pertence à sua mobile de atribuição em vez de ficar ao lado dela. Na Singular, os links de rastreamento são criados para suportar deep links e deep links adiados assim que o seu app estiver configurado, em Apple Universal Links, Android App Links e intents do Android, incluindo jornadas que começam na web e terminam no app, onde a atribuição entre dispositivos se torna relevante.

Camada web

☐  apple-app-site-association servido de /.well-known/, HTTPS, tipo de conteúdo JSON, sem extensão, sem redirecionamento

☐  assetlinks.json servido de /.well-known/, HTTPS, application/json, sem redirecionamento, sem autenticação

☐ Nome do pacote e impressões digitais de assinatura SHA-256 corretos para cada variante de build, incluindo chaves de release

☐ robots.txt não bloqueia AdsBot-Google ou AdsBot-Google-Mobile

☐ Verificado via endpoint da API Digital Asset Links do Google e o Google Ads Deep Link Validator

Camada do aplicativo

☐ Direito de Domínios Associados com applinks: para cada domínio, incluindo domínios de link curto

☐  android:autoVerify=”true” em cada filtro de intenção relevante

☐ Manipuladores de rota para cada caminho com deep link, com um padrão sensato para caminhos não reconhecidos

☐ Payload de deep link adiado resolvido antes da primeira tela renderizar

☐ O fluxo de login preserva e encaminha o destino do deep link

☐ Esquema de URI registrado como fallback de webview

Camada de plataforma

☐ Navegador no app em funcionamento, seja a Página de Destino Social da Singular’s ou a sua própria

☐ Deep links configurados no painel do parceiro para redes de autoatribuição, não no seu construtor de links

☐ Nenhuma configuração duplicada de deep link adiado ativada em um SDK de parceiro junto com seu MMP

☐ Domínio de link curto registrado para Universal Links e App Links

☐ Cada canal testado individualmente. Não presuma que uma bio do Instagram se comporta como um anúncio do Instagram

Camada de medição

☐ Parâmetros de atribuição em cada link

☐ Taxa de correspondência de deep link adiado monitorada como KPI, não presumida

☐ Jornadas da web para o app reconciliadas com as sessões web móveis de mobile

☐ Domínios de substituição restritos em qualquer link exposto publicamente

Singular Links roteia usuários entre iOS, Android e web, com atribuição embutida em cada clique.

Agende uma demo  ·  Obtenha um teste gratuito

Qual é a diferença entre um deep link e um deep link adiado?

Um deep link abre uma tela específica em um app que o usuário já tem instalado. Um deep link adiado funciona quando o app não está instalado: o destino é mantido enquanto o usuário vai à loja de apps, instala e abre o app pela primeira vez, momento em que é direcionado ao destino original. Deep linking adiado requer um SDK de atribuição. Nenhum sistema operacional oferece isso nativamente.

Os deep links funcionam se o usuário não tiver o app?

Universal Links e App Links fazem isso. Eles recorrem à sua página web mobile, que pode direcionar o usuário para a app store. Esquemas de URI personalizados não fazem; eles chegam a um beco sem saída. Essa é a principal razão pela qual os esquemas não são mais recomendados como mecanismo principal.

Por que meu deep link abre o navegador em vez do aplicativo?

Na maioria das vezes, porque o toque aconteceu dentro do navegador no aplicativo da plataforma social, que suprime a transferência no nível do sistema operacional na qual os Universal Links e App Links dependem. A segunda causa mais comum é a falha na verificação de domínio, e no Android 12 e versões posteriores essa falha é silenciosa, sem diálogo de desambiguação para sinalizá-la.

Universal Links e App Links são a mesma coisa?

São equivalentes, não a mesma coisa. Universal Links são o mecanismo da Apple, verificado via apple-app-site-association. Android App Links são do Google, verificados via assetlinks.json. Ambos usam URLs HTTPS padrão e ambos exigem um arquivo de associação domínio-app, mas são configurados separadamente e podem falhar de forma independente.

Ainda preciso de esquemas de URI em 2026?

Como mecanismo principal, não. Como fallback em navegadores in-app e como deep link em uma página de produto personalizada da App Store, sim.

Como funcionam os deep links com o Google Ads e o Meta?

Para campanhas de app, ambas são redes de auto-atribuição que não aceitam links de rastreamento MMP, então deep links são configurados no próprio painel de cada plataforma. Deep linking adiado passa pelo seu parceiro de atribuição: Singular é um dos 5 Parceiros de Atribuição de Apps que o Google suporta para isso, e não precisa de configurações adicionais para ativá-lo. Para campanhas web que direcionam para um app instalado, o Google Ads exige um App Link nativo ou Universal Link como URL final, que você pode implementar junto com sua configuração de links existente em outros canais.

Quão preciso é o deep linking adiado no iOS?

Depende do método de correspondência disponível. Onde o consentimento ATT concede acesso ao IDFA, a correspondência é determinística. Onde não concede, a correspondência é probabilística e a precisão varia com as condições de rede. IPs compartilhados, NAT da operadora e iCloud Private Relay reduzem isso. Trate como uma faixa medida, monitore-a e projete sua experiência de primeira execução para degradar com elegância.

O deep linking afeta o SEO?

Não diretamente. Os mecanismos de busca indexam seu conteúdo web, não o conteúdo do app, e implementar deep links não muda rankings. Alinhar o destino do app à página web correspondente é uma boa prática de UX que afeta a qualidade pós-clique.

O que substituiu o Firebase Dynamic Links?

Os Firebase Dynamic Links foram desativados em 25 de agosto de 2025 e o Google não lançou uma substituição direta, apontando as equipes para provedores terceirizados. URLs FDL existentes agora retornam erros 404. Equipes em migração geralmente passam para um provedor que lida com roteamento e atribuição juntos.

O que mudou no Android recentemente?

Duas coisas. O Android 15 introduziu os Dynamic App Links, que permitem atualizar as regras de roteamento de deep links no servidor sem um novo lançamento do app. E o Android Privacy Sandbox do Google foi descontinuado em 17 de outubro de 2025, incluindo a Attribution Reporting API, o que significa que a medição baseada em GAID sujeita à exclusão do usuário continua sendo o modelo operacional.