Histórico e solução de problemas
Consulte o histórico de e-mails e solicitações HTTP no Shopify Flow, reenvie ações e exporte eventos em CSV para solucionar falhas.
Todas as ações executadas por este aplicativo são registradas. O histórico é o primeiro lugar onde se deve verificar quando um e-mail não chegou ou chegou com algum problema.
A lista
Colunas: ID, Nome, Tipo, Status, Duração e Data de execução.
Filtrar por:
- Tipo de ação - Solicitação HTTP ou e-mail
- Status - Sucesso, Falha, Pendente ou Ignorado (cancelado)
A pesquisa corresponde ao nome do layout ou da solicitação. Ao acessar esta página a partir do botão “Histórico de solicitações” de uma solicitação HTTP, a exibição é pré-filtrada para essa solicitação específica, com um botão “Mostrar todos os eventos” para limpar o filtro.
Exportar como CSV
A opção “Exportar CSV”, localizada na parte superior da página “Histórico”, baixa a lista exatamente como está filtrada no momento: a pesquisa e todos os filtros que você definir também se aplicam à exportação. O arquivo é denominado history-<date>.csv e contém, no máximo**,** os 50.000 eventos mais recentes. Caso seus filtros correspondam a um número maior de eventos, o aplicativo informará isso após o download; refine os filtros (por exemplo, para um layout ou um status) para acessar eventos mais antigos.
Colunas: Data (UTC), ID, Tipo, Status, Layout ou solicitação, Destinatários, CC, CCO, Assunto, Erro e Duração (ms). Os nomes das colunas e os rótulos de status estão no idioma definido na sua conta de administrador. Os campos Destinatários, CC, CCO e Assunto são preenchidos apenas para e-mails. A exportação contém o que é exibido na lista de Histórico: variáveis de Shopify Flow, corpos de solicitação e respostas não são incluídos.
As três coisas a serem observadas
Um emblema vermelho com a indicação “Falha” significa que o envio ou a solicitação não ocorreu. Abra-o para verificar o erro do provedor.
Um selo âmbar de “Variáveis vazias” significa que o e-mail foi entregue, mas um ou mais marcadores de lugar {{ variables.x }} não foram preenchidos - portanto, o destinatário recebeu uma mensagem com uma lacuna. Essa é a falha que costumava passar despercebida: a linha aparece em verde, o provedor aceitou a mensagem e apenas o destinatário percebe o problema.
Um ícone cinza com a indicação “Skipped” significa que um e-mail de marketing não foi enviado porque todos os destinatários do campo “Para” haviam cancelado a assinatura de seus e-mails de marketing. Isso não constitui uma falha, não é contabilizado no seu plano e não é incluído na taxa de sucesso. Consulte E-mails de marketing e cancelamentos de inscrição.
A visualização detalhada
Ao abrir um registro, é exibido o seguinte:
| Cartão | Índice |
|---|---|
| Aviso sobre variáveis vazias | Quais placeholders não geraram nenhum resultado e se o Shopify Flow os enviou vazios ou simplesmente não os enviou |
| Não enviado: o destinatário cancelou a inscrição | Exibido em um evento “Ignorado” em vez de um erro, com um link para “Cancelar inscrição” |
| Detalhes do evento | ID do evento, tipo de ação, status, duração, hora de execução e o ID da execução do Shopify Flow |
| Mensagem de erro | O erro efetivo do provedor ou da API, quando a ação falhou |
| Solicitar dados | O que foi enviado - destinatários, remetente, assunto finalizado, variáveis ou a solicitação HTTP finalizada. No caso de um e-mail de marketing, to é a lista de destinatários após a remoção dos endereços que cancelaram a assinatura, e suppressed indica quantos foram removidos. No caso de um e-mail com um anexo proveniente de um metacampo, orderId ou customerId registram qual pedido ou cliente foi visualizado |
| Dados de resposta | O que foi retornado - o ID da mensagem do provedor ou o status HTTP e o corpo da mensagem. No caso de um e-mail de marketing, recipients lista todos os destinatários do campo “Para” com endereços do tipo sent, failed ou skipped, juntamente com o respectivo ID da mensagem ou mensagem de erro |
O título indica qual remetente foi utilizado, por exemplo, Order email via support@acme.com (MICROSOFT).
Um e-mail de marketing é enviado como uma mensagem por destinatário no campo “Para”, mas constitui um único evento no Histórico. O evento é considerado “Sucesso” quando todos os destinatários receberam suas mensagens. É considerado “Falha” assim que uma mensagem falhar após o envio de outra; a mensagem de erro indica, então, quem não foi contemplado, e o campo recipients nos Dados de Resposta mostra quem recebeu a mensagem.
Reenvio de uma ação
A página de detalhes possui um botão “Reenviar”. Ele atualiza o layout com as variáveis originais e reenvia aos destinatários originais por meio do mesmo remetente, ou reexecuta a solicitação HTTP exatamente como foi enviada.
Ela é executada imediatamente e conta como uma ação em seu plano. O reenvio não está disponível para ações que passaram pelo remetente padrão de fallback.
Um evento ignorado não possui o botão “Reenviar”: nada foi enviado, portanto não há nada a ser reenviado. Execute o fluxo de trabalho novamente assim que o cliente se inscrever novamente. O reenvio de um e-mail de marketing verifica novamente a lista de cancelamentos de inscrição e exclui todos aqueles que cancelaram a inscrição desde o envio original; caso não haja ninguém na lista, o reenvio é recusado.
Problemas comuns
O e-mail nunca chegou e não há nenhum registro no Histórico. A ação nunca foi executada. O problema está em Shopify Flow, e não aqui: verifique se o fluxo de trabalho está ativado, se o gatilho foi acionado e se alguma condição foi realmente atendida. As condições de tag correspondem exatamente, portanto, VIP e vip são diferentes.
A entrada apresenta um ícone de “Variáveis vazias”. Seu layout solicita uma variável que a ação do Shopify Flow não forneceu ou forneceu vazia. Abra a entrada para verificar qual é. Veja o passo a passo completo em Transmissão de dados de umShopify Flow.
A entrada foi ignorada. O modelo é um modelo de marketing e todos os destinatários do campo “Para” constam na sua lista de cancelamentos de assinatura; por isso, o aplicativo não enviou a mensagem. Isso significa que o cancelamento de assinatura está funcionando conforme o esperado. Se o e-mail for algo que o cliente precise receber, como uma atualização sobre um pedido ou envio, ele deve ser enviado por meio de um modelo transacional. Consulte E-mails de marketing e cancelamentos de inscrição.
Um e-mail de teste parecia estar correto, mas o enviado ao público está em branco. As variáveis de teste no editor de layout influenciam apenas as visualizações e os envios de teste. Um envio ao público utiliza o campo “Variáveis (JSON)” da ação do Shopify Flow, que é algo completamente distinto. Essa é a fonte mais comum de confusão.
O status é “Falha” com um erro de autenticação. Para SMTP, as credenciais ou a porta estão incorretas - abra o servidor SMTP e clique em “Testar conexão”. Para o Microsoft 365 ou o Google, talvez seja necessário reautorizar a conexão: verifique “Remetentes de e-mail” → “Contas conectadas” para verificar se há um ícone indicando “É necessário reconectar”.
O corpo de um e-mail exibe [object Object]. O(a) senhor(a) interpolou um objeto inteiro. Em e-mails, é necessário acessar o objeto ({{ variables.customer.firstName }}) ou percorrê-lo em um loop. Apenas as solicitações HTTP serializam objetos para JSON automaticamente.
A mensagem foi rejeitada devido ao tamanho. Anexos com mais de 20 MB no total são bloqueados, e o Microsoft 365 rejeita anexos incorporados com mais de 4 MB. Alterne os arquivos grandes para o modo de link. Consulte Anexos e imagens.
Uma solicitação HTTP falha com a mensagem SSRF blocked. O destino corresponde a um endereço de rede privada ou interna, o que é recusado por motivos de segurança. Utilize um endpoint acessível publicamente.
Tudo deixa de funcionar de uma só vez, acompanhado de uma mensagem indicando o limite do plano. O senhor esgotou sua cota de 30 dias. Consulte Planos e uso.
Consultando o Sidekick
Shopify O Sidekick pode consultar este aplicativo diretamente, em modo somente leitura. Muitas vezes, isso é mais rápido do que filtrar o Histórico manualmente:
- "Algum e-mail não foi entregue esta semana?"
- "Por que meu último e-mail não foi enviado?"
- "Quais remetentes de e-mail estão configurados?"
- "Tenho uma solicitação HTTP para o Airtable?"
O Sidekick nunca retornará valores secretos, senhas SMTP, tokens OAuth, valores de cabeçalho HTTP ou payloads em formato bruto - para esses dados, ele o redireciona para o aplicativo.
Ainda estou com dificuldades
Abra um relatório de bug indicando o domínio da sua loja, o nome do layout ou da solicitação e a data e hora da execução. Consulte “Relatar um bug” na Central de ajuda.