Obter Endereço e Número do Pedido de um Cliente
a Partir de uma Captura de Tela do iMessage

Por que o iMessage é um cenário de extração diferente do WhatsApp

Se você leu o guia do WhatsApp Business para extrair endereços de capturas de tela de conversas, já conhece o problema básico: uma mensagem de chat não é um formulário, e os dados necessários estão embutidos no texto da conversa. O iMessage compartilha esse desafio central — o endereço e o número do pedido estão nas mensagens, não em campos estruturados — mas adiciona três complicações que o WhatsApp não tem.

Primeiro, o iMessage é exclusivo do iOS, o que significa que as capturas de tela vêm de um único sistema operacional com estilo consistente de balões de chat — azul para iMessage, verde para SMS — mas também com elementos visuais específicos da plataforma que o WhatsApp não possui. As confirmações de leitura aparecem como rótulos "Lido" abaixo das mensagens. Os indicadores de digitação mostram uma elipse animada. As reações (Tapbacks) flutuam inline acima das mensagens como ícones de selo. Nenhum deles carrega os dados de que você precisa, mas ocupam espaço visual que um mecanismo de OCR tradicional precisaria desambiguar.

Segundo, o iMessage suporta o Apple Pay Cash — o sistema de pagamento peer-to-peer integrado da Apple. Quando alguém paga via Apple Pay Cash, a confirmação aparece no chat como um cartão escuro estilizado, não como um balão de texto comum. O valor, o nome do destinatário e o status da transação são renderizados dentro de um cartão preto compacto com texto branco grande e um selo de status colorido. Visualmente, esse cartão não compartilha nada com os balões de chat ao redor. Uma captura de tela que capture tanto um endereço em um balão azul comum quanto um cartão de pagamento na mesma visualização contém dois formatos visuais completamente diferentes em uma única imagem.

Terceiro, o iMessage gera prévias de links ricas — quando alguém cola uma URL, o chat cria um cartão com título da página, descrição e miniatura. Se um cliente colar um link para a página do pedido, essa prévia se torna outro elemento visual que parece conter dados de endereço, mas geralmente não contém.

O resultado é uma imagem onde os dados necessários estão espalhados em uma mistura de elementos de UI com estilos diferentes, todos parecendo que podem conter informações úteis. O método de extração precisa diferenciar entre o balão que contém o endereço, o cartão que mostra o valor do pagamento e a prévia que contém apenas um link.

Três Cenários Comuns de Pedidos no iMessage

Nem toda captura de tela de pedido no iMessage tem a mesma aparência. O layout visual muda dependendo de como o cliente enviou as informações e se houve um pagamento envolvido.

Cenário 1: Endereço e Número do Pedido em Bolhas de Texto

O cliente digita o endereço e os detalhes do pedido como mensagens de texto comuns na conversa. O endereço aparece em uma bolha azul padrão do iMessage:

"Você pode enviar para 3421 Maple Street, Apt 4B, Portland, OR 97202? Pedido #A45-8921"

O endereço e o número do pedido podem estar na mesma mensagem ou divididos em duas mensagens consecutivas. O texto da bolha é simples — sem formatação, sem rótulos. O endereço segue um padrão comum (rua, cidade, estado, CEP) que o mecanismo de extração consegue reconhecer pela estrutura, e o número do pedido é identificável pelo formato alfanumérico e pela proximidade com o contexto do pedido. Este cenário é o mais direto: apenas as bolhas de bate-papo com o nome do remetente e os horários como únicos elementos ao redor.

Cenário 2: Cartão de Pagamento Apple Pay Cash no Bate-Papo

Quando um cliente também paga via Apple Pay Cash na mesma conversa, o tópico contém um cartão escuro visualmente distinto de todas as bolhas ao redor. O cartão tem fundo preto e exibe o valor em dólar em texto branco grande e centralizado, o nome do destinatário ou remetente, um selo de status ("Enviado", "Entregue", "Pendente") e uma nota opcional na parte inferior.

O importante é entender o que o cartão Apple Pay Cash não contém. Ele mostra o valor do pagamento e a pessoa envolvida, mas não inclui o endereço de entrega nem o número do pedido. Esses itens permanecem nas bolhas de texto acima ou abaixo do cartão. Se você estiver extraindo dados de uma captura de tela que inclui ambos, precisará de colunas separadas para o endereço (das bolhas de texto), o número do pedido (também das bolhas de texto) e o valor do pagamento (do cartão).

Esta é uma diferença notável em relação ao WhatsApp Business, onde as informações de pagamento geralmente são compartilhadas como texto simples — "Enviei $85 para o seu número" — em vez de um cartão renderizado. O formato do cartão torna a confirmação do pagamento mais proeminente visualmente, mas também a isola das outras informações de uma forma que facilita a extração separada, desde que o mecanismo de extração consiga reconhecer o cartão como um componente visual distinto.

Cenário 3: Link de Pedido com Cartão de Visualização

Alguns clientes compartilham o pedido colando uma URL do site da loja. O iMessage gera uma visualização rica do link que aparece como um cartão no chat — uma miniatura, título da página e descrição em um contêiner arredondado. O endereço real e o número do pedido podem aparecer no balão de texto que acompanha o link, ou podem estar acessíveis apenas seguindo o link. O cartão de visualização em si normalmente não mostra o endereço de entrega completo ou um número de pedido completo. Se o cliente enviou o link sem digitar o endereço separadamente, os dados simplesmente não ficam visíveis na captura de tela. Essa é uma limitação que se aplica a qualquer método de extração: se a informação não for renderizada na tela, ela não pode ser extraída.

Lendo Através do Ruído Visual do iMessage

Uma captura de tela do iMessage pode incluir confirmações de leitura, indicadores de digitação, Tapbacks (reações com emoji), efeitos de mensagem, carimbos de data/hora e avatares de contato. Esses elementos são ruído visual se seu objetivo for o endereço e o número do pedido. Mecanismos de OCR tradicionais que processam a imagem da esquerda para a direita leem "Read" como texto, o indicador de digitação como pontos e reações com emoji como caracteres Unicode — tudo misturado no mesmo fluxo de saída que o endereço. O resultado é um bloco de texto onde "Rua das Flores, 123" e "Read" e "..." aparecem em sequência, exigindo limpeza manual.

Modelos de linguagem visual processam a captura de tela de forma diferente. Eles interpretam a imagem como uma cena visual completa e reconhecem o papel semântico de cada elemento — "isso é um rótulo de confirmação de leitura" versus "isso é um balão de chat contendo um endereço" — antes de ler o texto dentro de cada região. O texto da confirmação de leitura não contamina a extração do endereço, e o indicador de digitação não aparece como caracteres embaralhados na saída. Cada componente da interface é classificado por sua função visual, não apenas pelo texto que contém.

O mesmo princípio — de que uma captura de tela não é uma tabela, mas os dados ainda podem ser extraídos entendendo o que cada parte da imagem representa — se aplica à interface do iMessage tanto quanto se aplica a capturas de tela de pagamento. A diferença específica aqui é que o ruído visual do iMessage consiste em elementos interativos da interface, não em conteúdo de documento, e o método de extração deve distinguir entre os dois.

O que você pode extrair e o que não pode

Definir os nomes corretos das colunas é a única etapa necessária para especificar o que sai da captura de tela. Para uma captura de tela de pedido do iMessage, as colunas relevantes são endereço de entrega, número do pedido, valor do pagamento (de um cartão Apple Pay Cash) e nome do cliente (do cabeçalho da conversa). O mecanismo de extração lê cada definição de coluna, localiza o valor correspondente entendendo o papel semântico de cada elemento visual e gera uma linha por captura de tela. Um lote de 15 capturas de tela do iMessage de clientes diferentes, cada uma com formatos de mensagem e cartões Apple Pay Cash distintos, produz uma única tabela com 15 linhas.

Existem limites a serem considerados. Os dados do cartão Apple Pay Cash incluem apenas o valor da transação — não o endereço de entrega ou o número do pedido. Estes estão nas bolhas de texto e devem ser extraídos separadamente. Se a captura de tela mostrar uma prévia de link em vez de um endereço digitado, o endereço simplesmente não está visível na imagem. Em conversas com várias mensagens, onde o endereço está espalhado por várias bolhas, a captura de tela precisa abranger parte suficiente da conversa para incluir todas as partes. E as confirmações de leitura e os indicadores de digitação — embora não interfiram na extração semântica — dificultam a definição da região visual de interesse se a captura foi feita antes do cliente terminar de digitar.

Para o processamento em lote, o fluxo de trabalho é o mesmo que com qualquer outra categoria de captura de tela. Faça upload das imagens, defina as colunas uma vez e processe tudo junto. Um lote contendo capturas de tela do iMessage misturadas com confirmações de pedido por SMS — onde os dados são puramente texto simples — segue a mesma estrutura de colunas, e o método de extração se adapta ao formato visual de cada imagem de entrada individualmente.

Perguntas Frequentes