ROAS do SKU vs receita do carrinho

A tua loja pode estar a ler o ROAS do produto no Shopping e a concluir que o SKU «não paga», enquanto o mesmo clique abre um cabaz cuja receita o painel nunca cola naquela linha.

No relatório de produto vês custo, conversões e valor atribuídos ao item clicado. Calculas o ROAS dessa linha e, se está abaixo do alvo, pausas. O que essa conta não responde: quanto valeu o pedido quando esse SKU foi o produto de entrada. São duas contas. O painel mede o SKU. A loja mede o cabaz.

Este spoke aprofunda o pilar Antes de pausares o produto, vê a venda cruzada. Distinto do ROAS a mentir (loja vs painel na mesma venda) e do Shopping a pagar cliques mortos (feed partido). Aqui o corte é ROAS do SKU vs receita do cabaz no pedido.

Porque o ROAS do produto e a receita do cabaz divergem?

Porque a atribuição por produto cola o resultado no item do clique. O pedido pode trazer mais itens; a linha do SKU não é o mapa do cabaz.

No Google Ads Shopping (e nas vistas de produto do Merchant Center), o desempenho por SKU responde a impressões, cliques, custo, conversões e valor nessa linha. O ROAS que daí tiras é ROAS do produto. Não é, sozinho, a receita média do pedido quando esse produto abriu o carrinho, nem a margem do conjunto.

Num exemplo ilustrativo — não é média de Portugal nem lei do mercado — um SKU de entrada pode mostrar ROAS fraco na linha e, no mesmo período, aparecer em pedidos com variantes, acessórios ou um pack cujo valor total aguenta o CPC. Os números de uma sessão não são regra; servem para ver o desencontro: conta do painel vs conta do cabaz. Sem a segunda, qualquer pausa pelo ROAS do SKU é compatível com cortar o produto de entrada.

Facto: no Google Shopping o ROAS por produto é o valor e o custo que o painel atribui ao SKU clicado naquela linha. Não é a receita total do pedido quando esse clique abre um cabaz com outros itens. Market basket (composição do pedido) e ROAS do produto são duas contas. A primeira vive na loja: itens por encomenda, receita do cabaz, margem do conjunto, frequência com que o SKU entra sozinho ou acompanha. A segunda vive no relatório de produto: custo, conversões e valor colados no item. Pausar porque o ROAS do SKU está abaixo do alvo trata a linha como se o pedido fosse só aquele produto. Em catálogos com venda cruzada, o produto de entrada pode falhar essa linha e mesmo assim puxar receita que só a loja vê no cabaz. Enquanto só olhares o ROAS do SKU, a pausa no Shopping não prova que o produto «não paga». Prova que mediste o item sem a receita atribuída ao carrinho que ele abriu.

Opinião: decidir pausa no Shopping só com o ROAS do SKU, sem a receita do cabaz quando esse produto é entrada, é fechar o veredicto com metade da conta.

O que o painel cola no SKU (e o que a loja vê no pedido)?

O painel cola desempenho no produto clicado. A loja vê o pedido completo.

Mostra (conforme colunas e janela de atribuição): custo do produto, cliques, conversões e valor naquela linha, e o ROAS que daí resulta. Se a linha está vermelha, o reflexo é pausar, baixar lance ou tirar do feed.

Não mostra sozinho: receita média do pedido quando esse SKU foi o primeiro item; quantas vezes o cabaz fechou com mais peças; se o valor colado no produto é só a primeira unidade enquanto o resto do pack paga a margem. Também não absolve o SKU automaticamente. ROAS fraco no produto e cabaz vazio no mesmo período — aí a pausa ganha peso. O spoke que fecha este cluster formaliza quando pausar Shopping faz sentido (e quando não).

Se o feed mente preço, stock ou título, o clique pode ser morto antes de haver cabaz: isso é o Shopping a pagar cliques mortos. Aqui assumimos clique que chega à ficha; a pergunta é se a linha «fraca» esconde um cabaz saudável.

Como confrontas as duas contas antes de pausar?

Escolhe o SKU que queres pausar porque o ROAS do produto «não paga».

Nos últimos 14 ou 28 dias, anota no Shopping: custo, cliques, conversões e valor atribuídos a esse produto. Na loja (ou no analytics do pedido): quantas encomendas o tiveram no cabaz, receita média desses pedidos, itens médios, e se costuma entrar sozinho ou com outros SKUs. Não pauses ainda.

Se o ROAS do SKU está abaixo do alvo, mas os pedidos que passam por ele trazem cabaz com mais itens e margem no conjunto, não declares falha do produto sozinho. Ou tratas o SKU como produto de entrada (com a conta do cabaz), ou aceitas que o período no painel não conta como prova sem a segunda conta.

Se o produto quase nunca aparece com outros itens, o cabaz é só ele, e a margem não aguenta o CPC, a pausa ganha peso. Se o que falha é a ficha (variantes, prova, portes), a conversão na URL vem antes de mais leilão: isso é o cluster da página de produto, não deste.

Não scales o lance do produto de entrada se o checkout ainda fura. Compra de clique com funil partido não valida o cabaz. Valida o pedido primeiro — o checkout a comer o que os ads trazem é a ponte curta quando a medição do funil é o ponto.

FAQ

O ROAS do SKU no Shopping é a receita do carrinho?

Não. É o valor e o custo que o painel cola no produto clicado. A receita do cabaz vive no pedido: o que o cliente levou além desse SKU. São duas contas.

Pausar pelo ROAS do produto prova que o SKU falhou?

Não sozinho. Pode ser produto de entrada com linha fraca e cabaz saudável. Cruza ROAS do SKU com receita e composição do pedido antes de pausar.

Qual keyword interessa aqui?

A âncora do cluster (pausar produto Google Shopping / venda cruzada) fica no pilar. A query deste post é ROAS do SKU vs receita do cabaz. O que decides é se o ROAS da linha do produto esconde a receita do pedido. Sem essa segunda conta, o ROAS do SKU é só metade do quadro.

Como distingo isto do pilar da venda cruzada?

O pilar pergunta se estás a pausar sem olhar o cabaz. Este spoke separa as duas contas com nomes claros: ROAS do SKU vs receita do carrinho. Mesmo cluster, zoom no desencontro de medição.

A Aero Agency faz performance para lojas online em Portugal. Se estás a pausar SKUs no Shopping só com o ROAS da linha, o sítio para começar é a comunidade.