Migre do Firebase Dynamic Links para o Elido

O Firebase Dynamic Links foi encerrado em 25 de agosto de 2025. Todos os links FDL agora retornam 404. Se o seu app estava usando-os para atribuição de instalações, deferred deep linking ou roteamento pós-instalação para uma tela específica, esses fluxos estão quebrados em produção agora mesmo. O Branch.io começa em $199/mês para o nível que substitui o que o FDL fazia de graça. O roteamento de deep links do Elido cobre os mesmos padrões por uma fração do custo, com residência de dados na UE integrada.

Este é o caminho mais curto de links FDL quebrados para Universal Links e Android App Links funcionando.

Resumo

• O Firebase Dynamic Links foi encerrado em 25 de agosto de 2025; todas as URLs *.page.link retornam HTTP 404 a partir dessa data, conforme as perguntas frequentes sobre descontinuação do Firebase Dynamic Links
• A atribuição de instalações, o roteamento pós-instalação e os deferred deep links do seu app estão quebrados se você ainda não migrou
• A migração é uma mudança de DNS, dois arquivos JSON (um da Apple, um do Google) e uma reescrita de links - não uma reescrita de código
• O nível básico do Branch.io para este caso de uso é $199/mês; o Elido Pro cobre o mesmo roteamento a um custo substancialmente menor sem medição por link
• Você não precisa tocar no código de tratamento de deep links existente em Swift ou Kotlin - o handoff de Universal Link / App Link em nível de SO funciona da mesma forma independentemente de qual serviço hospeda o roteamento

O que o Firebase Dynamic Links realmente fazia

O FDL era a resposta do Google a três problemas que links HTTPS simples não conseguem resolver por conta própria.

Deferred deep linking. Um usuário em um dispositivo sem o seu app clica em um link. O SO abre a App Store ou a Play Store. O usuário instala o app. O app abre em uma tela inicial genérica e não tem ideia de que o usuário estava tentando acessar um conteúdo específico. O FDL armazenava o destino pretendido e o passava através da lacuna de instalação - o app podia consultar o SDK do FDL no primeiro lançamento e rotear o usuário para a tela certa.

Atribuição de instalações. Os links FDL carregavam parâmetros de campanha (utm_source, utm_medium, parâmetros personalizados via ?st= e ?si=) que sobreviviam à instalação. Esse é o mecanismo que permitia atribuir uma instalação a uma campanha de e-mail específica, um criativo de social pago ou um link de influenciador sem um MMP de terceiros.

Roteamento com reconhecimento de plataforma. Um link, três destinos: usuários iOS iam para a App Store (ou direto para dentro do app se instalado), usuários Android iam para a Play Store (ou para o app) e navegadores de desktop recebiam uma URL de fallback configurável. O roteamento acontecia no lado do servidor na borda do Google, não no código do seu app.

Quando o FDL saiu do ar, todas as três capacidades foram para 404 simultaneamente. Se você estava usando o SDK do FDL no seu app, ele está chamando um endpoint que não existe mais.

O equivalente no Elido

O Elido replica os mesmos três comportamentos por meio de detecção de plataforma na borda de redirecionamento e mecanismos de deep link nativos do SO.

Detecção de plataforma na borda. Um link curto do Elido inspeciona o cabeçalho User-Agent no momento do redirecionamento e roteia para destinos diferentes com base na plataforma: iOS para URL da App Store (ou universal link do app), Android para URL da Play Store (ou app link intent), desktop para o seu fallback web. Isso acontece em menos de 5ms no plano de redirecionamento. Sem chamada de SDK, sem round-trip para um serviço de atribuição separado.

iOS Universal Links. Quando o app está instalado no dispositivo, o iOS intercepta o link HTTPS antes que o navegador abra. Isso requer servir um arquivo Apple App Site Association (apple-app-site-association) a partir do caminho well-known do seu domínio personalizado. O Elido hospeda esse arquivo em seu nome quando você configura um domínio personalizado com roteamento de deep links habilitado. O resultado é idêntico ao que o FDL entregava: o app abre diretamente na tela vinculada.

Android App Links. Mesmo mecanismo no Android, formato de arquivo diferente. O arquivo assetlinks.json do Google fica em /.well-known/assetlinks.json no seu domínio. O Elido gera e serve esse arquivo quando você fornece o nome do pacote do seu app e a impressão digital SHA-256 do certificado. Os Android App Links abrem seu app diretamente sem um intersticial do navegador.

Passagem de deferred deep link. Para o caso da lacuna de instalação (o usuário ainda não tem o app), o Elido armazena o destino de deep link pretendido contra a URL curta e o expõe via um endpoint de consulta leve. Seu app chama esse endpoint no primeiro lançamento com a URL curta a partir da qual foi instalado - recuperável do install referrer no Android (INSTALL_REFERRER) e da API de atribuição da App Store no iOS - e recebe de volta o caminho de deep link original. Sem SDK do FDL, sem handshake proprietário. O guia de deep links cobre o contrato do endpoint de consulta.

A página de recursos completa está em /features/deep-links.

Migração passo a passo

Isso pressupõe que você tem uma conta Elido no Pro ou superior e um domínio personalizado que você controla. Preveja 30 minutos para uma migração direta; adicione uma margem se o volume de links FDL for grande o suficiente para exigir um script de reescrita em massa.

Etapa 1: adicione seu domínio personalizado ao Elido

No painel do Elido, vá para Workspace → Domínios personalizados → Adicionar domínio. Digite o domínio de marca pretendido (ex.: links.seuapp.com). O Elido mostrará um registro CNAME para criar.

No seu registrador de DNS, adicione o CNAME:

links.seuapp.com.  CNAME  cname.elido.me.

Recomendação de TTL: reduza para 300 segundos algumas horas antes de fazer isso se atualmente estiver em 3600+. O provisionamento de TLS é automático sob demanda e é concluído em poucos minutos após a propagação do DNS.

Etapa 2: configure iOS Universal Links (arquivo AASA)

Nas configurações de domínio, habilite Roteamento de deep links e forneça:

• Seu identificador de bundle iOS (ex.: com.suaempresa.seuapp)
• Os padrões de caminho de URL que devem abrir o app (ex.: /l/* para todos os links curtos, ou caminhos específicos)

O Elido gera e serve o arquivo AASA em https://links.seuapp.com/.well-known/apple-app-site-association. Verifique se ele resolve corretamente antes de continuar:

curl -s https://links.seuapp.com/.well-known/apple-app-site-association | python3 -m json.tool

A resposta deve incluir seu bundle ID no array applinks.details. A CDN do iOS armazena em cache o arquivo AASA e o atualiza em um cronograma; force uma atualização nos testes redefinindo o cache AASA do dispositivo via Desenvolvedor → Redefinir nas Configurações do iOS, ou instalando o app recentemente.

O Info.plist do seu app deve declarar o domínio associado. Se já o faz para seu domínio FDL, adicione o novo domínio ao lado dele durante o período de sobreposição:

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.seuapp.com</string>
  <!-- manter o domínio FDL durante a sobreposição se necessário -->
</array>

Etapa 3: configure Android App Links (assetlinks.json)

No mesmo painel de configurações de deep links, forneça:

• O nome do pacote do seu app (ex.: com.suaempresa.seuapp)
• A impressão digital SHA-256 do seu certificado de assinatura de release

Recupere a impressão digital se não a tiver em cache:

keytool -list -v -keystore release.keystore -alias seu-alias | grep SHA256

O Elido gera e serve o arquivo em https://links.seuapp.com/.well-known/assetlinks.json. Verifique:

curl -s https://links.seuapp.com/.well-known/assetlinks.json | python3 -m json.tool

O filtro de intent do seu AndroidManifest.xml já deve estar configurado para App Links se você estava usando FDL com o recurso de auto-verificação do SDK Android. Se não estiver, adicione o atributo android:autoVerify="true" ao seu filtro de intent de deep link e aponte-o para o novo domínio.

Etapa 4: reescreva seus links FDL existentes

Os links FDL têm a forma https://seuapp.page.link/SLUG ou https://seuapp.page.link/?link=https%3A%2F%2F...&.... Nenhum dos dois padrões continuará funcionando - o domínio page.link está morto.

Se você criou um pequeno número de links FDL (abaixo de algumas centenas), reescreva-os manualmente no painel do Elido. Se você criou milhares - comum para campanhas de e-mail ou tiragens de impressão de QR codes - use a API de importação em massa do Elido:

curl -X POST https://api.elido.app/v1/links/bulk \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "links": [
      {
        "slug": "boas-vindas",
        "destination": "https://seuapp.com/boas-vindas",
        "routing": {
          "ios": "https://apps.apple.com/app/id12345678",
          "android": "https://play.google.com/store/apps/details?id=com.suaempresa.seuapp",
          "fallback": "https://seuapp.com/boas-vindas"
        }
      }
    ]
  }'

Para links já impressos em materiais físicos (embalagens, pôsteres, cartões de visita), você não pode atualizar a URL em si - mas se a URL impressa era um link FDL de domínio personalizado apontando para um domínio que você controla, você pode reapontar o CNAME desse domínio para o Elido e o link impresso começará a funcionar novamente com sua nova configuração de roteamento.

Etapa 5: atualize a consulta de deferred deep link no primeiro lançamento do app

Os apps FDL chamam FirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url) ou o método de SDK equivalente no primeiro lançamento. Remova isso. Substitua por uma chamada ao endpoint de deferred deep link do Elido:

// iOS - no primeiro lançamento após a instalação
let installURL = "https://links.seuapp.com/boas-vindas" // recuperado da atribuição do StoreKit
let endpoint = URL(string: "https://api.elido.app/v1/deferred?url=\(installURL.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)!)")!
URLSession.shared.dataTask(with: endpoint) { data, _, _ in
    guard let data, let result = try? JSONDecoder().decode(DeferredLink.self, from: data) else { return }
    DispatchQueue.main.async { self.navigate(to: result.deepLink) }
}.resume()

O equivalente para Android usa a API Play Install Referrer para recuperar a URL curta e depois chama o mesmo endpoint. O guia de deep links tem amostras de código completas para ambas as plataformas.

Etapa 6: teste de ponta a ponta

Antes de fazer a transição, teste os três casos:

1. App instalado, link clicado no dispositivo - toque no link curto no Safari/Chrome, confirme que o app abre diretamente na tela certa sem um intersticial do navegador.
2. App não instalado, link clicado - toque no link, confirme que ele roteia para a página correta da App Store / Play Store.
3. App instalado da loja após clicar no link - instale o app recentemente, confirme que ele abre na tela pretendida no primeiro lançamento (caminho de deferred deep link).

Teste em um dispositivo físico para Universal Links. Os simuladores do iOS não executam de forma confiável o handoff AASA.

Casos extremos

Parâmetros FDL que você estava lendo no app. Se o seu app chamava DynamicLink.dynamicLink().url para ler parâmetros de um link FDL após abrir, esses parâmetros agora desapareceram. Você precisa codificar as mesmas informações na URL de destino do seu link curto do Elido como parâmetros de consulta e lê-los a partir da URL de deep link que o iOS ou Android entrega ao seu app. A codificação dos parâmetros é a mesma - ?screen=onboarding&ref=email_april - apenas movida do wrapper proprietário link= do FDL para a própria URL de destino.

Perda de atribuição. A atribuição do FDL era autocontida: o Google armazenava os parâmetros de campanha e os retornava ao SDK. O Elido armazena dados de eventos de clique (timestamp, plataforma, país, referenciador) no nosso armazenamento de análise e os expõe via API de análise, mas não é um MMP (mobile measurement partner). Se você precisar de atribuição probabilística ou determinística de instalações em escala - análise de coorte, LTV por fonte de aquisição, costura SKAdNetwork - você precisa de um MMP (Adjust, AppsFlyer) ou instrumentar o webhook de cliques do Elido em seu próprio pipeline de análise. Para a maioria dos apps independentes e equipes em estágio inicial que usavam o FDL puramente para "rotear o usuário para a tela certa", as análises do Elido são suficientes. Para equipes de aquisição paga executando atribuição multicanal, consulte a próxima seção.

URLs curtas page.link existentes já incorporadas no binário do app. Se você codificou URLs curtas FDL no código do seu app (payloads de notificações push gerados do lado do cliente, links de referência criados a partir do app), essas strings referenciam um domínio morto. Você precisa de uma atualização forçada do app ou de um endpoint do lado do servidor que gere a nova URL curta sob demanda. Não há como redirecionar page.link - o Google encerrou o domínio completamente.

URLs FDL longas com parâmetros codificados. O FDL suportava URLs de formato longo como https://seuapp.page.link/?link=https%3A%2F%2F...&ibi=com.seuapp&ifl=...&afl=.... Esses parâmetros (ibi, ifl, afl, isi) são específicos do FDL. Mapeie-os para os campos de roteamento do Elido: ifl (fallback iOS) para routing.ios, afl (fallback Android) para routing.android, ibi (bundle ID iOS) já está configurado no nível do domínio no Elido. O parâmetro link se torna sua URL de destino.

Residência de dados na UE. Se o seu app opera na UE e você processa dados de usuários da UE, os eventos de redirecionamento - incluindo endereços IP e strings User-Agent - são dados pessoais sob o GDPR. O FDL estava hospedado na infraestrutura global do Google com processamento nos EUA. O Elido está hospedado na região da UE por padrão; os eventos de clique da UE ficam na UE. A página de confiança e a visão geral de conformidade cobrem os detalhes contratuais.

Quando você realmente precisa do Branch.io

O Elido é a escolha certa para a maioria dos apps que usavam o FDL para roteamento de tela e atribuição básica de instalações. Não é a escolha certa se você depende de:

Atribuição probabilística para UA pago. O Branch integra-se com redes de anúncios (Meta, Google, TikTok, Snap) via postbacks e pode atribuir instalações probabilisticamente quando a impressão digital determinística não está disponível - ex.: no iOS 14.5+ com ATT não consentido. O Elido não faz atribuição probabilística. Se sua equipe de crescimento está executando UA pago e precisa reconciliar instalações com gastos de anúncios no nível de coorte, o Branch ou um MMP (Adjust, AppsFlyer) é a ferramenta certa para esse problema específico.

Fingerprinting e correspondência de dispositivo em nível de SDK. O SDK do Branch coleta sinais de dispositivo (resolução de tela, IP, idioma, fuso horário) para identificar um dispositivo através da lacuna de instalação sem depender de um install referrer. A correspondência somente por referenciador degrada em ambientes onde o referenciador é removido - se a taxa de acerto do seu deferred deep link precisar exceder ~80%, a abordagem em nível de SDK tem desempenho melhor.

Integração profunda com redes de anúncios específicas. O Branch tem integrações dedicadas com o CAPI da Meta, o rastreamento de conversões do Google e a API de eventos do TikTok que vão além do que o encaminhamento de conversões do lado do servidor do Elido cobre. Se sua pilha de atribuição estiver estreitamente acoplada a uma dessas redes, avalie a documentação de integração específica do Branch antes de mudar.

O teste prático: se você estava usando o FDL principalmente para rotear usuários para a tela certa após a instalação, e suas necessidades de atribuição são cobertas por parâmetros UTM na sua ferramenta de análise, o Elido substitui o FDL a um custo menor. Se você está executando marketing de performance em escala e a precisão de atribuição impulsiona decisões de orçamento, essa é a proposta de valor real do Branch e $199/mês compra infraestrutura real para isso.

Perguntas frequentes

Meu app tem links curtos FDL em payloads de notificações push - o que acontece quando os usuários os tocam?

Os links apontam para page.link, que retorna 404. O tratamento de links do SO passa o 404 de volta para o navegador ou para o manipulador de universal link do seu app, que vai falhar. Você precisa atualizar seu serviço de notificações push para gerar links curtos do Elido. Se você está gerando payloads push do lado do servidor (a abordagem correta), isso é uma mudança de uma linha para chamar a API do Elido em vez da API FDL. Se os payloads são gerados do lado do cliente a partir de templates codificados, você precisa de uma atualização do app.

Preciso lançar uma atualização do app para concluir a migração?

Para a consulta de deferred deep link (roteamento na lacuna de instalação), sim - você precisa substituir a chamada ao SDK do FDL pela chamada ao endpoint do Elido, o que requer uma atualização do app. Para Universal Links e Android App Links para o app já instalado, nenhuma atualização do app é necessária depois que o DNS e os arquivos AASA/assetlinks.json estiverem no lugar - o SO consulta esses arquivos do servidor, não do binário do app. A exceção: se seu Info.plist / AndroidManifest.xml ainda não declara seu novo domínio como um domínio associado, isso requer uma atualização do app.

O que acontece com os cliques nos links FDL antigos depois que eu concluir a migração?

Se o link antigo estava em um domínio page.link: nada - esse domínio está morto e esses links são irrecuperáveis. Se você estava usando um domínio personalizado para o FDL (menos comum, mas suportado), reaponte o CNAME do domínio para o Elido e configure regras de roteamento equivalentes; as URLs antigas vão começar a resolver novamente.

O Elido tem um SDK?

O Elido não requer um SDK para Universal Links ou App Links - esses são mecanismos nativos do SO. Para o endpoint de consulta de deferred deep link, você faz uma chamada HTTPS padrão; nenhuma dependência de SDK é necessária. Se você quiser um cliente tipado, o SDK Go do Elido, o SDK TypeScript e o SDK Python envolvem a API de deep links, mas não há SDK para iOS/Android e você não precisa de um. Isso é por design - quanto menos SDKs de terceiros em um app de produção, melhor.

Quanto tempo leva a propagação do AASA / assetlinks.json?

Depois que o DNS propagar (alguns minutos a uma hora dependendo do TTL), os arquivos AASA e assetlinks.json ficam imediatamente disponíveis na borda do Elido. O iOS atualiza sua cópia em cache do arquivo AASA na instalação do app e periodicamente depois; o atraso que você notará nos testes é a desatualização do cache do iOS, não a latência de serviço do Elido. Para um teste limpo, instale o app recentemente depois que a mudança de DNS tiver propagado.

---

Se você está avaliando o conjunto completo de recursos de deep links, a página /features/deep-links cobre a matriz de suporte a plataformas e a profundidade das regras de roteamento. Para detalhes específicos de residência de dados na UE relevantes para apps móveis que coletam dados de usuários da UE, a visão geral de conformidade tem o DPA e a lista de subprocessadores que sua equipe de privacidade solicitará.

Relacionados no blog

• Deep links sem SDK: como Universal Links e App Links realmente funcionam
• Residência de dados na UE para ferramentas de marketing: o que seu DPO realmente pergunta
• Smart links explicados: roteamento por dispositivo, geo, horário do dia e referenciador
• Migre do Bitly sem quebrar links: um manual de modos de falha