Como medir pedidos assistidos pela prova sem achismo

Um pedido assistido pela prova é aquele em que o comprador viu uma notificação de prova social antes de comprar. A Provedly conta esses pedidos cruzando o ID do visitante que viu a notificação com o ID do visitante que fez um pedido verificado dentro de 30 dias. É uma contagem simples, nunca uma estimativa ou uma projeção modelada, e saber exatamente o que ela mede é o que a torna útil.

Por que números de "receita influenciada" costumam ser inflados

Muitos painéis desta categoria mostram um número grande de receita rotulado como "influenciada" ou "gerada". Vale perguntar como esse número é produzido. Abordagens comuns incluem:

• Contar todos os pedidos de um site em que o widget está instalado, quer o comprador tenha visto algo ou não.
• Aplicar um percentual de ganho presumido sobre a receita total.
• Modelar uma contribuição a partir de uma mistura de sinais e apresentar o resultado como medição.

Cada uma delas produz um número fácil de mostrar e difícil de defender. Se a ferramenta do próprio fornecedor decide quanto crédito a ferramenta do fornecedor merece, o número tende a ser generoso. Lojistas que depois o comparam com as próprias análises geralmente descobrem que os dois não batem, e o painel perde credibilidade junto com o widget.

Como a Provedly conta

O método é deliberadamente estreito.

1. Quando uma notificação é exibida, o widget registra uma impressão associada ao ID de visitante daquele navegador.
2. Quando um pedido verificado chega por um webhook do Stripe ou da Shopify, a Provedly confere se o mesmo ID de visitante viu pelo menos uma notificação nos 30 dias anteriores.
3. Se sim, o pedido é contado como assistido pela prova. Se não, não é.

O painel mostra a contagem resultante e a fatia dos pedidos verificados que ela representa. Não há multiplicador, nem ganho presumido, nem extrapolação para visitantes que não foram cruzados. Registros de amostra ficam de fora, porque um pedido que a Provedly não consegue verificar não pode ser atribuído.

O que o número diz, e o que não diz

Ele diz quantos compradores verificados viram prova antes de comprar. Isso é um teto para a influência possível do widget: o widget não pode ter ajudado um pedido para o qual ele nunca foi exibido.

Ele não diz que a notificação causou a compra. Alguns desses compradores teriam comprado de qualquer forma. "Assistido" é a palavra certa, e a usamos porque "gerado" seria uma afirmação que os dados não sustentam.

É a mesma distinção que separa um relatório de último clique de um experimento controlado. A contagem é uma estatística descritiva. Causalidade exige um grupo de comparação.

Chegando mais perto da causalidade

Se você quer saber o que o widget acrescenta, e não só o que ele tocou, precisa de um período ou de um segmento sem ele.

Nenhum deles é perfeito, e o conselho honesto é tratar a contagem de pedidos assistidos como o seu sinal do dia a dia e rodar um grupo de controle de vez em quando para calibrá-la. Se a contagem é alta mas um grupo de controle não mostra diferença, o widget está sendo visto mas não está ajudando, e isso é útil saber.

Lendo a tendência, e não o nível

O número absoluto depende do tráfego, do volume de pedidos e de quantas notificações você mostra. As leituras mais úteis são relativas:

• Fatia assistida ao longo do tempo. Se a fatia de pedidos verificados assistidos pela prova sobe depois que você muda a segmentação, a mudança colocou a prova diante de mais compradores.
• Fatia versus frequência. Se você corta as notificações por sessão de cinco para três e a fatia assistida se mantém, você não perdeu nada mostrando menos. As escolhas de frequência são discutidas em /blog/notifications-per-visit-frequency.
• Fatia por posicionamento. Restringir o widget às páginas de produto e de preços e observar se a fatia muda mostra onde a prova é realmente vista antes da compra. As opções de segmentação estão em /blog/where-to-show-social-proof-page-targeting.

Limites conhecidos do cruzamento por ID de visitante

Qualquer método baseado num identificador de navegador tem lacunas, e é melhor nomeá-las do que escondê-las.

• Um visitante que limpa o armazenamento, usa uma janela anônima ou troca de dispositivo entre ver a notificação e comprar não vai ser cruzado. O pedido é real; ele simplesmente é contado como não assistido.
• A janela de 30 dias é uma escolha. Janelas mais longas cruzam mais pedidos, mas enfraquecem a ligação; janelas mais curtas fazem o contrário. Trinta dias é um meio-termo razoável para a maioria dos ciclos de compra.
• O cruzamento exige um pedido verificado, então lojas que não conectaram o Stripe ou a Shopify não têm contagem de pedidos assistidos.

O efeito prático desses limites é que a contagem tende a subestimar, e não a superestimar. Se é para errar, essa é a direção certa.

Resumindo numa linha.

Quando alguém perguntar o que o widget está fazendo, a frase honesta é: "Dos nossos pedidos verificados no período, esta quantidade veio de visitantes que tinham visto uma notificação nos 30 dias anteriores." É menos dramática do que um número de receita com cifrão. Também é verdadeira, bate com as suas próprias análises e é estável o bastante para embasar decisões. O painel está descrito junto com o resto do produto em /features.

Perguntas frequentes

Um pedido assistido pela prova significa que a notificação causou a venda?

Não. Significa que o comprador viu uma notificação antes de comprar. Causalidade exige um grupo de controle ou um teste A/B; a contagem é um teto de influência, não uma medida dela.

Por que não mostrar um número de receita?

Porque o único número de receita honesto seria a soma dos pedidos assistidos, e apresentá-lo como "gerado" exageraria o papel do widget. Mostramos contagens e fatias para que o número signifique o que diz.

Os registros de amostra entram na conta?

Não. Só pedidos verificados podem ser cruzados, então samples nunca aparecem na contagem de pedidos assistidos pela prova.

Veja os pedidos assistidos pela prova no seu próprio painel no plano grátis: /register.