Cómo configurar Google Tag Manager en un sitio DeFi (sin comprometer la privacidad)

Por qué GTM específicamente para DeFi

Podrías hardcodear llamadas de analytics en tu frontend. Muchos equipos DeFi lo hacen. El problema: cambiar lo que trackeas requiere un deploy de frontend. Con GTM, la data layer pasa a través de un event bus y los tags son configurados server-side en el contenedor GTM. Los equipos de marketing y analytics pueden ajustar tracking sin deploys de engineering.

Para DeFi específicamente, el valor más grande es tracking wallet-event. Wallet connect, transacción firmada, transacción confirmada, transacción fallida. Estos eventos firean desde el SDK del wallet, no de la página. Rutearlos a través de GTM significa que puedes fan out a múltiples destinos de analytics (GA4, Mixpanel, warehouse custom) sin 4 llamadas separadas de SDK.

El catch: DeFi tiene requerimientos serios de privacidad que el e-commerce mainstream no tiene. Las direcciones de wallet son pseudo-PII. Los hashes de transacción pueden ser correlacionados contra data on-chain. El comportamiento default de GTM a menudo leakea ambos. Seteado correctamente o nada.

Los 6 eventos que cada protocolo DeFi debería trackear

Trackea estos seis eventos. Todo lo demás es ruido.

1. wallet_connect_attempted. El usuario hizo clic en el botón Connect Wallet. Se dispara antes de que se abra el diálogo de la wallet. Este evento captura la intención.

2. wallet_connect_succeeded. El usuario completó la conexión de la wallet. Está bien capturar el nombre del proveedor de la wallet (MetaMask, Phantom, etc.). La dirección de la wallet NO.

3. wallet_connect_failed. El usuario canceló o la wallet rechazó. Captura el motivo del rechazo si el SDK de la wallet lo expone.

4. transaction_submitted. El usuario firmó y envió una transacción. Captura el tipo de transacción (swap, stake, mint, etc.) y el contrato del protocolo involucrado (no la wallet del usuario).

5. transaction_confirmed. Transacción confirmada on-chain. No hagas polling para esto: escucha el evento de confirmación del SDK de la wallet.

6. transaction_failed. La transacción se revirtió on-chain. Captura el motivo del revert si está disponible. Este es el evento más útil para diagnosticar y corregir problemas de UX.

Ese es el plan completo de tracking. Resiste el urge de añadir page_view, click, scroll. GA4 captura esos por default. Añadir más eventos custom diluye la señal de los 6 eventos que realmente importan para decisiones de producto.

Configuración del evento de conexión de wallet

Envía al data layer desde tu handler de conexión de wallet:

// On user clicks Connect Wallet
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'wallet_connect_attempted',
  wallet_provider: 'metamask', // detected from wallet SDK
});

// On wallet connection success
window.dataLayer.push({
  event: 'wallet_connect_succeeded',
  wallet_provider: 'metamask',
  chain_id: 1, // human-readable chain, not wallet address
  // DO NOT push wallet_address here
});

En GTM, crea tres triggers (uno por evento) y tres tags (uno por destino). Cada tag firea cuando su trigger ve el evento dataLayer matching.

Para GA4, el nombre del evento mapea 1:1. Para Mixpanel, envía el mismo nombre de evento más el wallet_provider y chain_id como propiedades. Evita enviar el mismo evento 4 veces a 4 destinos desde la página directamente, fan out a través de GTM en su lugar.

Seguimiento del evento de transacción

Los eventos de transacción firean después de que el usuario firma. El push del data layer necesita capturar contexto protocol-side, no user-side.

// On transaction submission (after wallet signs)
window.dataLayer.push({
  event: 'transaction_submitted',
  transaction_type: 'swap', // swap, stake, claim, mint, etc.
  protocol_contract: '0xA0b8...', // your contract
  amount_usd_bucket: '100-1000', // bucket, not exact amount
  chain_id: 1,
  // NEVER push: from_address, transaction_hash, exact USD amount
});

El patrón amount_usd_bucket es crítico. Los valores exactos de transacción son pseudo-PII cuando se combinan con timestamp, pueden identificar usuarios. Bucketea el valor: under-100, 100-1000, 1000-10000, over-10000. Esta es resolución suficiente para decisiones de producto y remueve la preocupación de privacidad.

Mismo enfoque para transaction_confirmed y transaction_failed. Trackea que sucedió, qué tipo, qué bucket, y en qué cadena. Sáltate el resto.

Reglas de privacidad: nunca envíes esto a GTM

Seis cosas que nunca pushear al data layer o enviar a través de GTM. Si estás enviando cualquiera de estos, tu analytics DeFi es una liability de privacidad.

1. Wallet addresses. Pseudo-PII. Se pueden correlacionar con identidades reales mediante servicios de análisis on-chain.

2. Hashes de transacción. Son públicos on-chain, pero combinarlos con el user-agent y el timestamp en tu base de datos de analytics crea un vector de reidentificación.

3. Valores exactos de transacción en USD. Usa rangos en su lugar.

4. ENS names. Algunos usuarios usan su nombre real como ENS. Trátalos como PII.

5. Códigos de referido definidos por el usuario. Suelen contener nombres de usuario identificables.

6. Direcciones de email de suscripciones opcionales al newsletter. Envíalas directamente a tu herramienta de email, no a través de GTM, donde los tags de redes publicitarias pueden extraerlas.

Integración de Consent Mode

Google Consent Mode v2 es requerido para sitios sirviendo usuarios EU. GTM tiene soporte nativo. Configuras cada tag con requerimientos de consent, y el tag espera firing hasta que el usuario otorgue el tipo de consent requerido.

Para los 6 eventos DeFi: consent analytics_storage para el destino GA4, consent ad_storage si estás enviando a plataformas de advertising (la mayoría de los protocolos DeFi no), y personalization_storage para cualquier tagging de user-segmentation.

El banner de consent se integra con GTM pusheando estado de consent al data layer cuando el usuario hace una elección. Usa un CMP que soporte Consent Mode v2 nativamente (Cookiebot, OneTrust, Iubenda). No rolees tu propio banner, hacer Consent Mode correcto a mano es más difícil que escoger un vendor.

GTM server-side es el siguiente upgrade para sitios DeFi privacy-serious. Mueve la ejecución de tag a un contenedor Google Cloud que tú controlas, lo cual significa que la data cruda va a tu servidor primero y tú decides qué forwardear. Vale el tiempo de setup si estás manejando usuarios EU a escala o tienes una función CISO real.

Preguntas comunes