Deep links numa aplicação: abrir o ecrã certo sem perder o caminho

O bilhete está no email; a aplicação abre noutra página

Uma pessoa chega a uma oficina de cerâmica e procura o email de confirmação. Toca na ligação para o bilhete. A aplicação pede que inicie sessão e, a seguir, mostra o ecrã inicial. À porta, com outras pessoas à espera, tem agora de procurar a reserva que o email prometia abrir.

Não faltou vontade de usar a aplicação. Faltou continuidade. O início de sessão pode ser necessário, mas não devia apagar a intenção de consultar aquele bilhete.

Este cenário é um exemplo de planeamento, não um relato de um projeto da Appfyl. Serve para perceber o que deve ficar escrito antes de desenvolver ligações diretas. O importante não é ter uma tecnologia com um nome conhecido: é garantir que o convite, a mensagem e o ecrã contam a mesma história.

Descrever o percurso a partir daquilo que a pessoa precisa

Comece pelos pontos de entrada que já fazem parte do serviço. Um email com um bilhete, uma mensagem com uma aula, um convite para um grupo ou um aviso sobre uma reserva. Para cada um, identifique o conteúdo e a ação esperada.

No caso da oficina, a ligação pode abrir a informação pública do evento ou o bilhete pessoal. Não são destinos equivalentes. A descrição do evento pode ser visível sem conta; o bilhete pode exigir confirmação de acesso. Esta diferença deve ser decidida pelo produto, não improvisada quando a ligação começa a funcionar.

Também convém distinguir uma sessão de uma série de oficinas. Se alguém recebeu um bilhete para sábado, não deve acabar silenciosamente na página de domingo só porque ainda existem vagas. Uma alternativa pode ser útil, mas tem de ser apresentada como alternativa.

Use uma referência estável para o destino. Alterar o título da oficina não deveria inutilizar os convites já enviados. Para uma primeira versão, prefira poucas ligações importantes bem definidas a uma lista extensa de ecrãs sem regras para os casos difíceis.

O que está por trás de uma ligação direta

Os Universal Links da Apple e os App Links do Android permitem associar endereços web a uma aplicação. A documentação da Apple apresenta essa relação; o guia de verificação do Android ajuda a confirmar a associação do domínio.

Depois de receber a ligação, a aplicação ainda tem de reconhecer o destino, obter o conteúdo e verificar se o pode mostrar àquela pessoa. São responsabilidades diferentes. Abrir a aplicação com sucesso não prova que o bilhete certo foi encontrado.

Uma ligação com esquema próprio, como exampleapp://ticket/123, também pode apontar para um conteúdo interno. No entanto, sem a aplicação instalada, não oferece por si só uma página web utilizável. Para convites que circulam livremente, um endereço HTTPS num domínio controlado pela empresa costuma ser uma base mais prática.

Não confunda estas ligações com a continuação após uma instalação. A associação entre site e aplicação pode resolver o caso de quem já tem a aplicação. Quem ainda vai descarregá-la passa por outra etapa, e a recuperação do destino original precisa de ser prevista à parte.

Guardar a intenção durante o início de sessão

Se a sessão tiver terminado, a aplicação pode pedir nova autenticação. Antes disso, deve conservar a referência do bilhete solicitado. Depois de entrar, verifica novamente o acesso e continua para esse bilhete, em vez de aplicar sempre o encaminhamento habitual para o início.

Este comportamento deve existir também na criação de conta. As perguntas de boas-vindas e os pedidos de configuração podem ser úteis, mas não justificam esquecer o motivo da visita. Inclua a situação no planeamento da primeira utilização e percorra todas as etapas como alguém que nunca utilizou a aplicação.

Imagine agora que ficou aberta a conta de outra pessoa da família. A ligação não deve mostrar um bilhete privado nem aceitar automaticamente um convite em nome dessa conta. Uma mensagem clara pode indicar que o acesso não está disponível e permitir a troca de conta, mantendo a referência necessária para continuar.

Conservar o destino não significa aceitar qualquer endereço sem o validar. Defina os tipos de ligação admitidos e rejeite parâmetros inesperados. O servidor deve verificar o direito de acesso a conteúdos privados. Ter uma URL não equivale, por si só, a ser titular de uma reserva.

Se houver convites de utilização única, decida o que acontece quando expiram ou são abertos novamente. A pessoa pode fechar a aplicação a meio e regressar mais tarde. Uma regra clara de continuação evita que esse pequeno acidente se transforme num pedido desnecessário ao apoio ao cliente.

O destino continua a ser o bilhete ou convite original. O início de sessão e a instalação interrompem o percurso de maneiras diferentes.

Não obrigar a instalar sem explicar o que vem a seguir

Quando a aplicação não está presente, a página web pode confirmar a oficina, a data e o próximo passo, desde que sejam informações públicas. Se o bilhete for privado, mostre apenas o necessário e ofereça um acesso seguro. Uma página vazia com um botão para instalar a aplicação deixa demasiadas perguntas por responder.

Se o serviço exigir instalação, explique como o bilhete será recuperado na primeira abertura. O chamado deferred deep linking trata precisamente dessa continuação. A explicação da Airbridge ajuda a visualizar a passagem de contexto, embora seja escrita por um fornecedor interessado na adoção do seu serviço.

Não conclua daí que todas as aplicações precisam de uma plataforma adicional. Para participantes habituais, ligações verificadas e uma boa alternativa web podem chegar numa fase inicial. Para convites dirigidos sobretudo a novos utilizadores, o percurso pela loja pode justificar uma solução mais completa.

Peça uma demonstração nas lojas e nos dispositivos que vai suportar. Inclua situações em que certos dados não estão disponíveis ou a sua recolha não foi autorizada. A correspondência entre clique e instalação não deve ser tratada como uma certeza universal, nem obtida através de recolha oculta de dados.

Vale a pena preparar uma saída simples: voltar ao email depois de instalar, por exemplo. Um código de convite também pode ajudar se a aplicação o suportar. É um passo adicional, mas permite recuperar o objetivo sem obrigar a pessoa a procurar uma oficina entre dezenas de resultados.

Algumas funções específicas das lojas podem influenciar determinados percursos. O nosso guia sobre páginas de produto personalizadas aborda essa camada. Uma opção disponível para uma campanha não deve ser prometida como comportamento geral de qualquer ligação.

Quando a informação mudou entretanto

Uma oficina pode ter sido cancelada, uma reserva anulada ou um bilhete substituído. O endereço antigo não deve fingir que nada aconteceu. Mostre o estado atual adequado e uma ação que faça sentido, sem revelar informação privada a quem não tem acesso.

Se a sessão terminou, pode ser útil encaminhar para novas datas, mas explique primeiro o que aconteceu à original. A página inicial, sem qualquer aviso, transfere para o utilizador o trabalho de descobrir por que razão a ligação já não cumpre a promessa.

Uma falha de rede é outro caso. Não a apresente como falta de autorização. Quando possível, conserve o pedido e permita repeti-lo. Para ações como confirmar presença, garanta ainda que repetir uma tentativa não cria duas confirmações diferentes.

Pense também no caminho de regresso. Quem abre diretamente um bilhete precisa de uma forma razoável de voltar às reservas ou ao evento. O ecrã correto não é suficiente se deixa a pessoa presa numa parte isolada da aplicação.

Uma grelha de aceitação para usar numa demonstração

Prepare dados fictícios e peça à equipa que mostre os resultados no telemóvel. O objetivo é observar estados diferentes, não repetir várias vezes o único cenário em que tudo já está configurado.

Acrescente uma versão antiga ainda suportada e uma tentativa sem rede. Registe versão, dispositivo, origem da ligação e resultado. Esta grelha pode integrar o plano de testes antes do lançamento.

O guia de testes da Adjust distingue quem já utiliza a aplicação de quem vai instalá-la. É uma separação útil para investigar problemas: se a aplicação instalada já abre o ecrã errado, comece por corrigir esse encaminhamento. As instruções específicas do fornecedor para preparar o dispositivo não são requisitos universais de todas as plataformas.

Teste a mensagem que será realmente enviada. Um serviço de email pode acrescentar uma ligação intermédia para contar cliques. Essa alteração pode tornar o percurso diferente do teste feito com a URL original. O mesmo cuidado se aplica a códigos QR e a navegadores integrados em aplicações de mensagens.

Manter as ligações úteis depois da publicação

Nem todos os toques têm de forçar a abertura da aplicação. O contexto do navegador e as preferências do utilizador contam. A Apple descreve, por exemplo, situações de navegação no mesmo domínio em Safari que permanecem no navegador. Por isso, o resultado web deve ser previsto e utilizável.

Mantenha um registo dos domínios, das ligações importantes e de quem pode alterar os respetivos destinos. Um convite impresso pode circular durante muito tempo. Se mudar de fornecedor, precisa de saber que endereços continuam sob o seu controlo e que materiais terão de ser substituídos.

O Firebase Dynamic Links deixou de funcionar em 25 de agosto de 2025. Revise modelos antigos e campanhas automáticas que ainda usem esse serviço. Isto não significa que todos os produtos Firebase tenham sido encerrados. Também não é possível recuperar uma ligação num domínio alheio apenas alterando o seu próprio domínio.

Na analítica da aplicação, separe a receção da ligação, a apresentação do bilhete e a ação concluída. Estes são passos sugeridos para medir o percurso, não nomes obrigatórios de eventos. Evite incluir dados pessoais ou códigos secretos nos parâmetros recolhidos.

Se existir um programa de recomendação, a atribuição de uma recompensa precisa de uma verificação própria. Abrir uma ligação não prova que as condições foram cumpridas. Esta distinção protege tanto as regras do programa como a interpretação dos resultados.

Ao preparar o trabalho com a Appfyl, reúna exemplos dos emails, convites e destinos previstos. É uma forma concreta de escolher os percursos prioritários. Uma ligação bem feita quase passa despercebida: a pessoa chega, reconhece o que procurava e continua.

Perguntas frequentes