Introdução
As limitações dos cookies de terceiros obrigam as redes de afiliados a repensar o rastreamento. Para comerciantes e parceiros vale: quem perde visibilidade de conversões perde receita e confiança. A Affilentra oferece, nas suas edições self‑hosted, um caminho pragmático para fechar lacunas de rastreamento: Identity‑Stitching baseado em identificadores first‑party combinados com reconciliação do lado do servidor. Este artigo explica como configurar e operar a Affilentra de modo que cliques, leads e vendas sejam atribuídos de forma fiável mesmo sem cookies de terceiros.
Princípios: O que o Identity‑Stitching deve realizar
- Identificadores First‑Party: recolha de dados controlados pelo próprio comerciante (p. ex. e‑mail hasheado, IDs de link persistentes no lado do servidor).
- Reconciliação Server‑Side: unificar eventos (clique, lead, venda) ao nível do servidor em vez de depender apenas de cookies no cliente.
- Separação de funções e transparência: o comerciante mantém o controlo sobre produtos, condições e dados brutos; os parceiros veem as suas link‑IDs e histórico de pagamentos.
Preparativos na Affilentra (self‑hosted)
Antes de iniciar a implementação, verifique a sua instalação Affilentra quanto aos seguintes pontos:
- Edição: PRO ou NETWORK instalada e ativada.
- Funções: operador do software, comerciante e parceiro criados e com direitos claramente separados.
- Configuração de Webhook: acesso do sistema a endpoints de webhook disponível (HTTPS, certificado válido).
- Avisos de proteção de dados: mecanismos de consentimento para dados first‑party existem e estão documentados.
Configuração passo a passo
1) Geração e persistência de link‑IDs no lado do servidor
Fluxo de trabalho:
- Links de parceiros apontam para uma URL de redirecionamento da Affilentra. Ao clicar, a Affilentra gera uma link_id única, armazenada de forma persistente (UUID ou similar), e anexa‑a como parâmetro de query para a URL do comerciante.
- A Affilentra armazena link_id, ID do parceiro, URL de destino, timestamp e metadados opcionais do contexto do cliente (p. ex. campanha).
Nota de configuração: assegure na Affilentra que a link_id é armazenada a longo prazo e não está vinculada a cookies de sessão do navegador. A link_id é o identificador primário para a posterior reconsolidação.
2) Recolha de e‑mails hasheados como Identificador First‑Party
Quando utilizadores introduzem um e‑mail no site do comerciante (p. ex. lead, registo, compra), o comerciante deve normalizar o endereço antes de o enviar à Affilentra (trim, lowercase), aplicar salt e hashear (p. ex. HMAC‑SHA256). A Affilentra armazena o hash como first_party_email_hash.
Vantagem: nenhum transporte em texto claro, preservação de um identificador estável que pode ser utilizado entre dispositivos assim que o utilizador fornece o seu e‑mail.
3) Postback Server‑Side para conversões
O comerciante envia conversões server‑side para a Affilentra (em vez de apenas pixel do cliente). O payload mínimo contém:
- link_id (se disponível)
- first_party_email_hash (se disponível)
- order_id / transaction_id
- amount, currency
- timestamp
- signature (HMAC, para proteção)
Na Affilentra, deve configurar um endpoint de postback e armazenar um HMAC‑shared‑secret em Definições → Integrações.
Exemplos de Webhook e Fluxo para Re‑Consolidação
A seguir um exemplo simplificado de como o servidor do comerciante envia uma conversão para a Affilentra e como a Affilentra efetua a correspondência.
Payload de Exemplo (POST)
- partner_id: 12345
- link_id: abcd‑ef01‑... (opcional)
- first_party_email_hash: 9f86d081884c7... (opcional)
- order_id: ORD‑2026‑0001
- amount: 99.90
- currency: EUR
- timestamp: 2026‑10‑24T12:34:56Z
- signature: HMAC_SHA256(payload, shared_secret)
Lógica de Reconciliação (lado da Affilentra)
- 1. Verificar a assinatura; em caso de falha: 401 e registo.
- 2. Procurar por link_id → atribuição direta ao parceiro/clique → marcar a conversão como atribuída.
- 3. Se não houver link_id: procurar por first_party_email_hash → se corresponder a um lead/mapeamento existente, efetuar a atribuição.
- 4. Se ainda nenhum match: matching de fallback com base em order_id/transaction_id contra dados de encomendas ou revisão manual.
- 5. Guardar o resultado na BD da Affilentra; notificar o parceiro via webhook ou callback.
Comportamento de Webhook Recomendado no Sistema do Comerciante
- Implemente mecanismos de retry (backoff exponencial) em erros temporários.
- Registe todos os payloads enviados com Order‑ID e estado para auditorias.
- Proteja as chamadas de webhook com HMAC; defina uma estratégia de rotação para os secrets.
Identificadores de Fallback: Priorização e Recomendações
Em ambientes sem cookies, precisa de uma priorização clara dos identificadores. Ordem recomendada:
- link_id persistente server‑side (melhor fiabilidade para mapear clique→venda).
- Email first‑party hasheado (estável entre dispositivos, quando o utilizador fornece email).
- Order‑ID ou Transaction‑ID (referência única, fiável para atribuição de receita, menos para atribuição direta).
- Fingerprints server‑side (IP + User‑Agent + Timestamp hasheados) apenas como última opção e sujeito a avaliação de privacidade.
Importante: documente a priorização no seu Partner‑Agreement e nas definições da Affilentra, para que comerciantes e parceiros tenham rastreabilidade.
Exemplos de Perguntas Frequentes sobre Implementação
Como procedo com utilizadores que regressam sem e‑mail?
Confie na link_id gerada no servidor quando o clique ocorre e armazenada no seu backend. Quando o utilizador mais tarde converte, o backend do comerciante compara os valores link_id referenciados na encomenda e envia estes dados à Affilentra.
O que fazer em caso de atribuição múltipla (p. ex. vários cliques)?
Defina na Affilentra uma estratégia de atribuição clara (Last‑Click server‑side, ou Time‑Decay) e implemente essa lógica na pipeline de reconciliação. Documente como a prioridade da link_id atua em relação às correspondências por e‑mail.
Segurança e proteção de dados
- Hashing: Utilize procedimentos HMAC seguros com um salt do lado do comerciante, que não seja armazenado em texto claro na Affilentra.
- Minimização de dados: Transmita apenas o hash, não o e‑mail em texto claro.
- Consentimento: Assegure que o processamento dos identificadores first‑party está legalmente coberto (Consent Management).
Exemplo prático: Processo em 6 passos
- Link do parceiro clicado → Affilentra gera link_id e redireciona para o comerciante com a link_id na URL.
- O comerciante armazena a link_id server‑side na sessão/encomenda.
- O utilizador compra / regista‑se → o comerciante normaliza e hash do e‑mail, cria order_id.
- O comerciante envia um POST server‑side à Affilentra com link_id, first_party_email_hash, order_id e HMAC.
- A Affilentra verifica, reconciliia (link_id → E‑Mail → order_id) e marca a conversão; o parceiro é notificado.
- Faturação e pagamento são realizados de forma transparente com base nos dados de conversão verificados e armazenados na Affilentra.
Conclusão e próximo passo
O rastreamento cookieless exige uma mentalidade server‑side: gere Link‑IDs persistentes, utilize e‑mails first‑party hasheados como identificador estável e construa uma pipeline de reconciliação robusta com webhooks seguros. A Affilentra, como plataforma self‑hosted, suporta estes padrões através de papéis separados, armazenamento persistente de Link‑ID, integrações via webhook e faturação de comissões transparente.
Atue agora: Escolha o seu ponto de entrada na Affilentra e configure Link‑IDs server‑side bem como postbacks de e‑mail hasheados para reduzir imediatamente as lacunas de rastreamento. Escolher entrada: https://affilentra.de
Próximo passo
Experimentar a Affilentra
Plataforma unificada que reúne de forma transparente disponibilização de produto, rastreamento, validação de conversões, cálculo de comissões e pagamentos com papéis claramente separados; opção de instalação self‑hosted com licença perpétua sem participação sobre receita; os comerciantes mantêm controlo sobre produtos, condições e criativos; os parceiros recebem links de rastreio pessoais e histórico de pagamentos rastreável.