# Investigação Purchase fantasma - Pixel Meta Borrello

**Data:** 2026-08-27
**Pixel:** 464623303880507 (Pixel de Campanhas Real - Francisco Borrello Matriz)
**BM:** Francisco Borrello (ID 194633344835973)
**Conta de ads:** act_517468148842987
**Investigador:** paulo-dev
**Tempo total:** ~35 min

---

## TL;DR

Causa CONFIRMADA. Não é o pixel injetado pelo Hotmart no checkout (como a memória anterior sugeria) — esse já foi desativado. A causa atual é um **bug de código na landing `passoapasso2.franciscoborrello.com.br`**: os 2 CTAs finais de compra têm `fbq('track','Purchase')` disparando no `onclick`, **antes de sair para o checkout**. Toda vez que alguém clica em "Comprar acesso de 1 ano" ou "Garantir acesso vitalício", o Meta conta um Purchase - mesmo que o cara nunca pague.

Impacto medido nos últimos 7 dias: **45 Purchases fantasmas** no pixel vs **1 venda APPROVED** real na Hotmart nesse produto. Delta = **44 fantasmas em 7 dias** (~6/dia).

---

## 1. Causa confirmada - com evidência técnica

### 1.1 O bug no HTML da LP

Arquivo ao vivo: `https://passoapasso2.franciscoborrello.com.br/`

Os 2 CTAs de checkout têm `fbq('track','Purchase')` embutido no atributo `onclick`, junto com `InitiateCheckout`. Trecho literal (capturado via DOM ao vivo com Playwright):

```html
<a href="https://pay.hotmart.com/H52956404P?off=2xffyzey&checkoutMode=10"
   onclick="fbq('track','InitiateCheckout');fbq('track','Purchase',{value:97.00,currency:'BRL'});gtag('event','begin_checkout');"
   class="cta mt-auto text-center bg-ink text-cream font-semibold px-6 py-3.5 rounded-xl">
   Comprar acesso de 1 ano
</a>

<a href="https://pay.hotmart.com/H52956404P?off=d64ejplo&checkoutMode=10"
   onclick="fbq('track','InitiateCheckout');fbq('track','Purchase',{value:147.00,currency:'BRL'});gtag('event','begin_checkout');"
   class="cta mt-auto text-center bg-golddeep text-cream font-semibold px-6 py-3.5 rounded-xl">
   Garantir acesso vitalício →
</a>
```

Consequência: **Purchase dispara na intenção de compra, não na compra em si**. É como reportar uma venda toda vez que alguém tira o cartão do bolso.

Screenshot da LP com os CTAs visíveis: `/tmp/pixel_capture/lp_passoapasso2_ctas.png`

Grep confirmatório em todas as LPs do Borrello (nenhuma outra tem o problema, só a `passoapasso2`):

| LP | fbq('track','Purchase') no HTML |
|---|---|
| passoapasso.franciscoborrello.com.br | 0 |
| **passoapasso2.franciscoborrello.com.br** | **2 (bug)** |
| mesasradionicas.franciscoborrello.com.br | 0 |
| franciscoborrello.com.br | 0 (sem pixel) |
| loja.franciscoborrello.com.br | 0 (sem pixel) |

### 1.2 A hipótese antiga (pixel Hotmart no checkout) já NÃO se sustenta

Testei via Playwright os 2 URLs de checkout Hotmart do produto (`H52956404P` + off `d64ejplo` e `2xffyzey`):

- HTML do checkout: **não contém** o pixel `464623303880507`
- Requests para domínios FB (facebook.com/tr, connect.facebook.net, fbevents): **0 requests**
- Nenhum `fbq(` no DOM renderizado
- Nenhum `<noscript>` fallback para pixel

Isso significa que **o Hotmart NÃO está mais injetando o pixel Meta no checkout deste produto**. Alguém desativou entre a investigação de 20/08 e agora — ou nunca estava ativo pra essa oferta específica. A memória `borrello_capi_hotmart_infra.md` está desatualizada nesse ponto e precisa ser revisada.

### 1.3 Cross-check com stats do pixel

`GET graph.facebook.com/v21.0/464623303880507/stats?aggregation=url&event=Purchase` retorna, últimos ~25h:

```
2026-08-26T14:00: passoapasso2.franciscoborrello.com.br: 2
2026-08-26T23:00: passoapasso2.franciscoborrello.com.br: 2
2026-08-27T01:00: passoapasso2.franciscoborrello.com.br: 2
2026-08-27T09:00: passoapasso2.franciscoborrello.com.br: 2
```

**100% dos Purchase eventos apontam pra URL da LP `passoapasso2`**, nenhum aponta pra domínio Hotmart. Confirma que a origem é o pixel client-side na LP.

### 1.4 Nuance: split BROWSER 50% / SERVER 50%

O aggregation `event_source` mostra que os Purchases estão distribuídos 50/50 entre BROWSER e SERVER. O CAPI server-side do Borrello (endpoint `hotmart-webhook.agentesclimb.us/borrello`) ainda está em STUB_MODE (aguardando token Meta + HOTTOK). Então esse SERVER 50% NÃO é o nosso CAPI. É a Meta fazendo "Automatic Event Matching" ou reprocessamento server-side interno a partir do evento browser que chegou - as bibliotecas do Meta hoje frequentemente clonam eventos client como server pra melhorar match. Isso NÃO é uma segunda venda, é o mesmo evento contado uma vez só (o pixel deduplica via cookie/fbp). Não muda o veredito: **o gatilho original é o onclick do CTA na LP**.

---

## 2. Impacto quantificado (últimos 7 dias)

### 2.1 Meta (insights API - conta act_517468148842987)

Campanha ativa única: `RADIESTESIA PRÁTICA [VENDA] 08.2026`

| Data | Spend | InitiateCheckout | Purchase-pixel | CPA-pixel |
|---|---|---|---|---|
| 2026-08-20 | R$ 121,30 | 45 | 11 | R$ 11,03 |
| 2026-08-21 | R$ 69,10 | 24 | 4 | R$ 17,27 |
| 2026-08-22 | R$ 39,23 | 24 | 4 | R$ 9,81 |
| 2026-08-23 | R$ 110,78 | 36 | 4 | R$ 27,70 |
| 2026-08-24 | R$ 89,81 | 33 | 6 | R$ 14,97 |
| 2026-08-25 | R$ 97,24 | 42 | 9 | R$ 10,80 |
| 2026-08-26 | R$ 130,12 | 38 | 7 | R$ 18,59 |
| **TOTAL 7d** | **R$ 657,58** | **242** | **45** | **R$ 14,61 (fake)** |

### 2.2 Hotmart real (Sales History API - product_id 1437935 "O Passo a Passo da Radiestesia na Prática")

Últimos 7 dias, TODOS status:

- APPROVED: **1**
- CANCELLED: 1
- COMPLETE / STARTED / WAITING_PAYMENT / EXPIRED / REFUNDED / CHARGEBACK: **0**

Considerando TODOS os produtos Borrello (não só o do curso Passo a Passo), últimos 7 dias:

| Produto | APPROVED | EXPIRED | CANCELLED |
|---|---|---|---|
| 957426 - Radiestesia, Radiônica Individual, Geobiologia e Geoacupuntura | 2 | 1 | 0 |
| 1437935 - O Passo a Passo da Radiestesia na Prática | 1 | 0 | 1 |
| 2422576 - Promoção Cromoterapia e Radiestesia | 1 | 0 | 0 |
| 4821543 - Combo Feng Shui 4 Cursos | 1 | 0 | 0 |
| **TOTAL APPROVED** | **5** | | |

### 2.3 Delta

- Meta Purchases: **45**
- Hotmart APPROVED (produto do curso): **1**
- Hotmart APPROVED (todos produtos, teto máximo): **5**
- **Fantasmas: entre 40 e 44 em 7 dias** (~6/dia)
- **CPA real (todos produtos): R$ 131,52** — vs CPA-pixel R$ 14,61 (**9x pior que o Meta mostra**)
- **CPA real (só produto Passo a Passo): R$ 657,58** — vs CPA-pixel R$ 14,61 (**45x pior**)

Isso replica o mesmo padrão que estourou na campanha de 05-20/08 (56 pixel vs 9 reais). A campanha continua rodando às cegas.

---

## 3. Fixes possíveis

### Fix A — Remover o `Purchase` do onclick (RECOMENDADO)

**O que fazer:** editar `passoapasso2.franciscoborrello.com.br/index.html` no cPanel HostGator (credenciais em `/opt/mia/config/hostgator/borrello_cpanel.env`, user `fran1799`), removendo `fbq('track','Purchase',{...})` dos 2 CTAs de compra. Manter só o `InitiateCheckout`.

**Trade-off:**
- Prós: fix cirúrgico, 5 minutos, resolve 100% do fantasma sem quebrar nada.
- Contras: Meta fica sem sinal de Purchase até o CAPI server-side entrar em produção (~48h de aprendizado da campanha zerando temporariamente). Aceitável — melhor ficar sem sinal do que otimizar pra métrica falsa.

**Ação imediata pós-fix:** rodar `backfill_capi.py` do endpoint CAPI (quando os tokens forem preenchidos) pra jogar as vendas APPROVED reais dos últimos 15-30d — recompõe o sinal Meta na base correta.

### Fix B — Ativar CAPI server-side + manter pixel client (com dedupe)

**O que fazer:**
1. Preencher os 2 tokens pendentes em `/opt/mia/config/meta_capi_borrello.env` e `/opt/mia/config/hotmart_borrello.env` → restart `hotmart-capi-borrello.service`.
2. **Ao mesmo tempo remover o Purchase do onclick** (fix A).
3. Adicionar Purchase client-side APENAS numa página de "Obrigado" pós-checkout (se o produtor tem essa URL configurada no Hotmart), com `eventID` gerado pelo Hotmart transaction_id — deduplicado com o server-side do CAPI.

**Trade-off:**
- Prós: cobre navegador (dá match de fbp/cookie) e servidor (sinal confiável). Recomendação oficial do Meta.
- Contras: mais setup, depende de o Renato fornecer os tokens (pendência antiga). Se preferir simplicidade, faz só o Fix A.

### Fix C — Só server-side (desligar pixel client Purchase de vez)

**O que fazer:** Fix A + ativar CAPI (tokens). Pixel client dispara só PageView/ViewContent/InitiateCheckout. Purchase vem 100% do webhook Hotmart via CAPI.

**Trade-off:**
- Prós: máxima limpeza, elimina qualquer chance de fantasma futuro. Meta bate 1:1 com Hotmart APPROVED.
- Contras: perde alguns matches de cookie/browser em Purchases (fbp que só existia no client). Impacto marginal em atribuição, aceitável dado que evita a fraude atual.

**Recomendação técnica:** Fix A imediato + Fix C na sequência quando o Renato liberar os 2 tokens.

---

## 4. O que precisa do Renato

Bloqueios / decisões pendentes:

### 4.1 Autorização pra rodar Fix A (remover Purchase do onclick da LP)

Edit direto no cPanel HostGator - 5 min de trabalho, zero risco (só remove código errado). **Aguarda ok do Renato pra Leo (leo-web) ou Paulo executar.**

### 4.2 Tokens pendentes pra CAPI sair do STUB_MODE

Já pedidos há 7 dias (memória `borrello_capi_hotmart_infra.md`), continuam pendentes:

1. **System User Token Meta CAPI** — gerar em business.facebook.com → Configurações → Usuários do sistema, escopos `ads_management` + `business_management`, com acesso ao pixel 464623303880507. Colar em `META_CAPI_TOKEN=` de `/opt/mia/config/meta_capi_borrello.env`.

2. **HOTTOK do Hotmart** — Painel Hotmart → Ferramentas → Webhook → adicionar URL `https://hotmart-webhook.agentesclimb.us/borrello`, versão 2.0.0 JSON, eventos `PURCHASE_APPROVED` + `PURCHASE_REFUNDED` + `PURCHASE_CHARGEBACK`. Copiar HOTTOK gerado e colar em `HOTMART_HOTTOK=` de `/opt/mia/config/hotmart_borrello.env`.

Depois: `sudo systemctl restart hotmart-capi-borrello` (a Mia/Paulo faz).

### 4.3 Confirmação de qual é a LP oficial da campanha

Existem 2 landings quase-iguais no ar: `passoapasso.franciscoborrello.com.br` (sem bug) e `passoapasso2.franciscoborrello.com.br` (com bug). Os anúncios estão apontando pra `passoapasso2` (é a URL que aparece no `event_source_url` de todos os Purchases). **Faz sentido depreciar a `passoapasso` antiga ou manter as duas?** Se manter, sincronizar código.

### 4.4 Print da tela do pixel no Hotmart (opcional, confirmatório)

Só pra documentar: `app-vlc.hotmart.com > Ferramentas > Pixel do Facebook` do produto 1437935. Se o pixel 464623303880507 aparecer listado lá com evento Purchase ativo, remover ou trocar pra "Purchase só em APPROVED". Se não estiver listado, ótimo (bate com o que o Playwright mostrou). Já podemos partir sem essa confirmação — o teste no checkout ao vivo já provou que não está injetando.

### 4.5 Decisão estratégica sobre a campanha em curso

Enquanto o fix não é aplicado, a campanha `RADIESTESIA PRÁTICA [VENDA] 08.2026` está gastando ~R$100/dia otimizando por métrica falsa. Recomendo:
- **Curto prazo (hoje):** pausar a campanha OU aplicar Fix A imediato (preferido).
- **Se pausar:** perde momentum; use só como último recurso.
- **Se manter rodando sem fix:** o algoritmo Meta vai continuar achando ganchos que geram cliques em "Comprar" (não venda), inflando ainda mais os fantasmas.

Bruno (bruno-trafego) deve ser envolvido nessa decisão.

---

## 5. Anexos técnicos

- Screenshot LP com CTAs: `/tmp/pixel_capture/lp_passoapasso2_ctas.png`
- HTML capturado LP: `/tmp/lp_borrello.html` (38 KB)
- Fonte deste relatório: `/opt/mia/workspace/clientes/borrello/capi_investigacao_purchase_fantasma_20260827.md`
- Endpoint CAPI (STUB): `https://hotmart-webhook.agentesclimb.us/borrello` (health OK, aguardando tokens)
- APIs usadas: Meta Graph v21.0 `/pixel/stats` e `/act_/insights` (token Renato) + Hotmart `/payments/api/v1/sales/history` (BASIC do env)

Nada foi alterado em produção durante a investigação. Só leitura.