AULA 28 / 30 · Parceiros e operação
Instalação → compra: reconciliação opcional no warehouse
Use transaction_id sem duplicar purchase.
Guia baseado em documentação e PRs consultados. SDKs/API citados ainda têm alterações em draft; confirmar release e homologação.
Ver implementação e critérios de aceite →Escopo separado
Installs resolve origem de aquisição; commerce intelligence é opcional. O laboratório contém SQL de identidade e join instalação-compra, mas não um conector recorrente universal para VTEX, Wake ou Shopify.
Chaves e fonte canônica
O contrato propõe bridgee_install_id consentido para contexto no Firebase. transaction_id liga purchase ao pedido do comércio/ERP. Pagamento pode ter outro ID; não force que o ID financeiro seja a chave de marketing.
Defina receita
Escolha status de pedido, moeda, desconto, frete, impostos, cancelamento e devolução. Deduplicate purchase e pedido; compare janela e timezone. Divergência requer reconciliação antes de concluir ROAS.
Cuidado com receita ajustada
O lab possui trusted ROAS com ajuste de qualidade/risco e fórmula conservadora. Isso é experimento sintético que requer calibração; não apresente multiplicar receita por Trust Score como procedimento contábil ou resultado incremental.
SUA VEZ
Leve a aula para a prática
Prepare três pedidos sintéticos: correspondência correta, purchase duplicado e pedido cancelado. Documente a ação de reconciliação.
Baixar checklist de homologação ↓Confira o aprendizado
Documentação e evidências
Consultadas em 03/10/2026. Os exercícios e números desta aula são fictícios.