Aplicativos móveis e deep links

Um link curto que leva a um aplicativo móvel tem três públicos ao mesmo tempo: quem já tem o aplicativo, quem não tem e quem está com um navegador que vive dentro de outro aplicativo. Esta página cobre os três, mais as duas partes da configuração que fazem diferença: os arquivos de associação no seu domínio e o contexto de clique adiado que o seu aplicativo pode ler na primeira abertura.

O que a seção Mobile faz

Abra um link, vá até a aba Mobile e ligue os destinos para mobile. Para cada plataforma você pode definir três endereços:

• Link do aplicativo — o endereço dentro do seu aplicativo: o seu próprio esquema com um caminho (myapp://product/42), um intent do Android ou um link universal https.
• Endereço na loja — a página na App Store ou no Google Play, usada quando o aplicativo não abre.
• Alternativa web — uma página para os visitantes que você prefere não mandar para a loja de jeito nenhum.

Tudo é opcional. Um link só com endereço na loja é um simples redirecionamento para a loja. Um link com link do aplicativo e endereço na loja ganha o comportamento completo: a página tenta o aplicativo primeiro e segue para a loja quando nada acontece.

Outras duas configurações decidem o que acontece fora de um navegador comum de celular:

• Tablets — tratá-los como celulares (o padrão) ou como desktops.
• Navegadores dentro de aplicativos — o que fazer quando o link abre dentro do Instagram, do TikTok, do Facebook ou de um aplicativo parecido.

Os visitantes de desktop seguem o Destino no desktop, se você definir um, e o destino principal do link caso contrário. Nada da seção Mobile muda o que os visitantes de desktop veem, a menos que você peça.

Por que navegadores dentro de aplicativos precisam de uma regra só deles

A maior parte dos cliques em links num feed social nunca chega ao Safari ou ao Chrome. Eles abrem em uma web view dentro do próprio aplicativo, e várias dessas web views guardam toda navegação para si: um link universal fica na web view, e um esquema personalizado simplesmente não faz nada. Isso não é um defeito que você conserta a partir do link — é uma decisão do aplicativo dono da web view.

Por isso a configuração te dá três opções honestas:

| Escolha | O que o visitante recebe | | --- | --- | | Tentar abrir o aplicativo | A página intermediária tenta o link do aplicativo; quando se sabe que aquela web view bloqueia isso, a página pula a espera e mostra como reabrir o link no navegador do celular. | | Ir direto para a loja | Nenhuma tentativa de abrir o aplicativo — útil em campanhas de instalação, em que a página da loja é o objetivo. | | Ir para a alternativa web | O visitante fica na web, o que muitas vezes é a melhor resposta para links de conteúdo. |

Arquivos de associação: a configuração que faz os links abrirem o aplicativo em silêncio

Para que um link abra o seu aplicativo sem uma parada no navegador, o sistema operacional precisa saber que o seu domínio e o seu aplicativo andam juntos. As duas plataformas verificam isso com um arquivo servido pelo próprio domínio:

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

Esses arquivos não são escritos por você. Em Domínios, abra o domínio e adicione seus aplicativos em Aplicativos móveis:

• no iOS: o App ID no formato TEAMID.com.company.app e os caminhos que o aplicativo deve tratar (* cobre todos os links curtos);
• no Android: o nome do pacote e as impressões digitais de assinatura SHA-256 do Play Console.

A plataforma monta e serve os dois arquivos a partir do seu domínio com a resposta exata que as duas plataformas exigem: status 200, sem redirecionamentos, application/json, sem compactação de transporte. Esse último ponto importa mais do que parece — um proxy que aplica gzip no arquivo em trânsito é um dos motivos mais comuns para os links de aplicativo pararem de funcionar sem avisar.

Conferir a configuração

O botão Verificar os arquivos busca os dois arquivos no seu domínio no ar e relata o que uma plataforma veria. Cada achado corresponde a uma correção específica:

| Achado | O que fazer | | --- | --- | | O domínio não respondeu | O domínio ainda não está servindo tráfego, ou o DNS ainda está se propagando. | | O arquivo não existe | Nenhum aplicativo está configurado para este domínio, ou a requisição nunca chega à plataforma. | | O domínio redireciona este endereço | Algo na frente do domínio reescreve /.well-known/. As plataformas não seguem redirecionamentos aqui. | | Servido com o tipo errado | A resposta é HTML, normalmente uma página 404 de outro serviço. | | A resposta chega compactada | Um proxy compacta o arquivo. As verificações das duas plataformas podem falhar por causa disso. | | Nenhum aplicativo declarado | O arquivo é válido, mas está vazio para aquela plataforma — adicione o aplicativo no painel. |

Depois que os arquivos estão no lugar, as duas plataformas os guardam em cache na CDN delas, então uma instalação nova do aplicativo pode demorar um pouco para pegar uma alteração. Reinstalar o aplicativo é a forma confiável de forçar uma releitura durante os testes.

Contexto do clique adiado depois da instalação

Um visitante sem o seu aplicativo clica em um link, cai na loja, instala o aplicativo e o abre. Nesse momento o aplicativo não sabe nada sobre de onde aquela pessoa veio — a sessão do navegador e o aplicativo são dois mundos que não se falam.

Ligue Entregar o contexto do clique depois da instalação e a plataforma guarda por umas duas horas uma impressão digital curta do dispositivo: plataforma, versão principal do sistema operacional, idioma, país, tamanho da tela, fuso horário e operadora de rede. Nela não há endereço IP, não há identificador de publicidade e não há nada que possa ser ligado de volta a uma pessoa.

Na primeira abertura, o seu aplicativo pergunta à plataforma se houve um clique:

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

Havendo correspondência, a resposta traz o link original e as tags de campanha dele:

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

Sem correspondência a resposta é {"matched": false} — e o mesmo vale para uma segunda requisição sobre o mesmo clique, porque o registro é entregue exatamente uma vez.

Os limites, ditos com clareza

• A correspondência é probabilística. Dois aparelhos do mesmo modelo, na mesma rede, no mesmo fuso horário e no mesmo idioma são idênticos para este método. É por isso que toda resposta traz um confidence e a lista de atributos que decidiram: high quer dizer que tamanho de tela e fuso horário bateram os dois em um clique recente, low quer dizer para tratar aquilo como uma pista, não como um fato.
• A janela é de horas, não de dias. A impressão digital expira duas horas depois do clique, e a confiança cai já depois dos primeiros quinze minutos.
• Envie a requisição uma vez só, na primeira abertura. O registro é consumido pela primeira correspondência bem-sucedida; uma segunda chamada não devolve nada.
• Um redirecionamento direto para a loja, sem a página intermediária, coleta menos. Tamanho de tela e fuso horário só são conhecidos pela página que roda no navegador, então um link que vai direto para a loja bate apenas por idioma e versão do sistema operacional — e diz isso, com uma confiança menor.

Checklist de testes

1. Abra o link em um celular com o aplicativo instalado: ele deve cair dentro do aplicativo.
2. Abra sem o aplicativo: a página aparece por um instante e a loja abre.
3. Abra a partir de um feed social: confira se a sua escolha para navegadores dentro de aplicativos corresponde ao que você espera.
4. Abra em um navegador de desktop: o destino de desktop ou o destino principal.
5. Rode Verificar os arquivos no domínio e confirme que os dois arquivos voltam limpos.