Pular para o conteúdo principal

Clicked-IDs

Clicked-ID é o identificador único que cada plataforma de ads gera quando o usuário clica num anúncio. Permite à plataforma reconciliar a conversão com o clique original (independente do user ter ou não cookie de terceiro). É o sinal mais valioso de atribuição — mais robusto que UTMs.

IDs suportados​

O front captura 10 clicked-IDs distintos da URL:

Param URLPlataformaQuando aparece
gclidGoogle Ads (Search/Display tradicional)Maioria dos cliques no Google
gbraidGoogle iOS 14+Quando gclid não pode ser setado (ITP)
wbraidGoogle web-to-appCliques que vão de web pra app store
fbclidMeta (Facebook + Instagram)Todo clique em ad da Meta
ttclidTikTokTodo clique em ad do TikTok
msclkidMicrosoft Bing AdsCliques no Bing/Microsoft Ads
mgclidMGIDNative ads MGID
tclidTaboolaNative ads Taboola
kwclidKwaiCliques no Kwai
obclidOutbrainNative ads Outbrain

Persistência: dois formatos paralelos​

Cada clicked-ID é persistido de dois jeitos ao mesmo tempo, pra suportar dois schemas que coexistem em produção no BFF:

Formato 1 — campo individual​

Cada clicked-ID vira sua própria chave no cookie e no payload:

{
  "gclid": "Cj0KCQjw...",
  "fbclid": "IwAR3...",
  "ttclid": "abc123"
}

Esse é o formato esperado pelos handlers BFF do 7k e vera-new (o "schema novo"). Cada clicked-ID vira top-level key.

Formato 2 — par derivado (media_source, media_clid)​

O primeiro clicked-ID encontrado também alimenta dois campos derivados:

{
  "media_source": "google",
  "media_clid": "Cj0KCQjw..."
}

Esse é o formato esperado pelos handlers BFF do bullsbet, jogao e mcgames (o "schema antigo"). Apenas 1 par é populado por request.

Por que ambos?​

O BFF tem os dois handlers em produção dependendo da brand. Enviar nos dois formatos garante atribuição independente de qual handler está ativo. Cookie continua confortavelmente abaixo do limite de 4KB do browser mesmo com todos os 10 IDs populados (worst case ~1.5KB).

Ordem de prioridade pra media_source​

Quando múltiplos clicked-IDs coexistem na mesma URL (raro, mas acontece em redirects de tracking complexos), o primeiro match na lista abaixo vence o media_source derivado:

OrdemURL keymedia_source derivado
1gclidgoogle
2gbraidgoogle
3wbraidgoogle
4fbclidmeta
5ttclidtiktok
6msclkidbingads
7mgclidmgid
8tclidtaboola
9kwclidkwai
10obclidoutbrain

Note que todos os IDs presentes são persistidos individualmente (Formato 1) — só o media_source derivado segue prioridade.

Exemplo combinado​

URL:

https://vera.bet.br/?utm_source=facebook&gclid=ABC&fbclid=XYZ

Cookie cookie_tracking resultante:

{
  "utm_source": "facebook",
  "gclid": "ABC",        // ← Formato 1
  "fbclid": "XYZ",       // ← Formato 1
  "media_source": "google",  // ← Formato 2 derivado (gclid wins)
  "media_clid": "ABC"        // ← Formato 2 derivado
}

Tanto Meta quanto Google podem reconciliar essa conversão usando seus próprios IDs.

Política last-touch​

Última URL com clicked-ID sobrescreve o anterior, mesmo padrão dos UTMs. Se user clica em ad do Google (gclid=ABC) e dias depois em ad da Meta (fbclid=XYZ), o cookie fica:

{
  "gclid": "ABC",        // ← preservado (não veio na URL nova)
  "fbclid": "XYZ",       // ← novo
  "media_source": "meta",  // ← agora deriva do fbclid
  "media_clid": "XYZ"
}

:::warning Implicação importante Se a campanha A (Google) e B (Meta) competirem em janelas curtas, o user que clicou nos dois conta como conversão da Meta no cookie do front (last-touch). Os dois gclid e fbclid estão lá pra reconciliação, mas media_source derivado segue last-touch. :::

Sanitização​

Cada valor passa pelas mesmas regras de UTMs:

  • HTML entities, scripts, tags strippados
  • Placeholders não-substituídos descartados ({fbclid}, __CLICKID__ ← ad mal-configurada)
  • Truncated em 500 chars
  • PII bloqueada

Importante: placeholder não-substituído é descartado completamente. Se a Meta enviar ?fbclid={fbclid_unresolved} (caso de ad bug), nada vai pro cookie. Dashboard fica limpo de {fbclid} como literal.

Onde aparecem no payload​

Signup​

{
  "gclid": "Cj0KCQjw...",
  "fbclid": "IwAR3...",
  "ttclid": "abc123",
  "media_source": "google",
  "media_clid": "Cj0KCQjw..."
}

Todos os clicked-IDs presentes vão pro payload de signup.

Deposit​

Mesma coisa — clicked-IDs viajam no POST /wallet/add-credit. Permite atribuição em conversões de re-deposit também.

Captura por brand​

Independe de brand — todos os clicked-IDs são capturados em todas as brands automaticamente. Não há config por brand — é comportamento padrão do front.

Como testar​

  1. Cole no browser: http://localhost:5173/?gclid=test_g_123&fbclid=test_f_456&ttclid=test_t_789
  2. DevTools → Application → Cookies → cookie_tracking deve ter: 
    {
      "gclid": "test_g_123",
      "fbclid": "test_f_456",
      "ttclid": "test_t_789",
      "media_source": "google",
      "media_clid": "test_g_123"
    }
  3. Submete signup → Network → confirma que todos os clicked-IDs estão no body do POST /api/auth/register

Anti-patterns​

  1. Tentar setar media_source/media_clid na URL diretamente. Esses são derivados — você só tem controle dos clicked-IDs nativos.
  2. Pedir suporte a clicked-ID novo sem confirmar com BFF. O BFF precisa aceitar a key no payload. Adicionar só no front é tracking morto.
  3. Confiar só em media_source ignorando os IDs individuais. Brands diferentes usam handlers diferentes — mande os dois formatos.
  4. Achar que clicked-ID substitui UTM. Não substitui — clicked-ID é pra plataforma de ads reconciliar conversão; UTM é pra você segmentar relatórios. Use os dois.

Referência cruzada​