TikTok Events API en WordPress: lo que hace falta y lo que no

TikTok pide Automatic Advanced Matching, cookies first-party y enhanced postback por defecto en el onboarding. Nada de eso hace falta para trackear conversiones. Todo conlleva riesgo RGPD. La config mínima real en dos pantallas, más lo que tiene que hacer el banner de consentimiento para que funcione.

Lo que el onboarding de TikTok intenta dejar activado por defecto

Cuando creas una fuente de datos Web Events en TikTok Ads Manager, un asistente te lleva por una serie de pantallas. Tres de esas pantallas tienen toggles etiquetados como "Recommended" preconfigurados como activados. Cada uno por separado parece inofensivo. Juntos suponen una exposición RGPD no trivial que en realidad no necesitas para que el tracking de conversiones funcione.

Los tres:

1. Automatic Advanced Matching.
2. Allow first-party cookies.
3. Allow enhanced data postback.

El default es "on" para los tres. La config mínima requerida es "off" para los tres.

Automatic Advanced Matching

Lo que TikTok dice que hace: mejora el match-rate capturando automáticamente información del cliente desde los campos del formulario y enviándola a TikTok hasheada.

Lo que en realidad hace: escanea cada campo de formulario en cada página que carga el visitante. Cuando el visitante escribe en un campo de email o teléfono, incluso si nunca envía el formulario, el pixel de TikTok lee el valor, lo hashea en cliente y lo envía a TikTok junto con eventos posteriores.

Por qué es riesgo RGPD: es recogida de PII (email, teléfono) sin consentimiento por campo. El visitante quizá consintió "cookies de marketing", pero no consintió que TikTok viera cada campo de formulario con el que ha interactuado en tu sitio. El hasheo no ayuda, la PII hasheada sigue siendo PII bajo RGPD.

Por qué no lo necesitas: Beaconry hashea los mismos campos en servidor, con caminos de código controlados, solo para los formularios que el visitante envía realmente. Mismo boost de match-rate, superficie de ataque drásticamente menor.

Pon a: OFF.

Allow first-party cookies

Lo que TikTok dice que hace: permite que el pixel de TikTok establezca cookies bajo tu dominio de cliente en vez del dominio de TikTok, "mejorando el tracking entre navegadores".

Lo que en realidad hace: permite a TikTok escribir _ttp y cookies relacionadas en tu dominio. Desde la perspectiva del navegador del visitante, esas cookies son ahora first-party hacia ti, lo que significa que sobreviven al bloqueo de cookies de terceros del visitante, ITP y similares.

Por qué es un problema: salta tu consent gate. El nl-data-gate de Beaconry no ve _ttp como cookie gestionada por Beaconry, así que cuando el visitante revoca el consentimiento, la cookie no se limpia. Han consentido al tracking de Beaconry, no a que las cookies del pixel de TikTok persistan en tu dominio.

Por qué no lo necesitas: el modo híbrido logra el mismo resultado de cookies first-party de forma explícita, gated a través de tu banner de consentimiento, eliminable al revocar. Las cookies first-party autoasignadas son el mismo resultado con peor higiene.

Pon a: OFF.

Allow enhanced data postback

Lo que TikTok dice que hace: envía "contexto adicional" desde la página para mejorar la precisión de atribución.

Lo que en realidad hace: envía meta tags de la página, datos estructurados (JSON-LD), clics recientes en botones, profundidad de scroll, métricas de rendimiento de página y algunas otras señales del lado navegador a TikTok junto con cada evento. Nada de lo cual configuraste explícitamente para trackear.

Por qué es un problema: no tienes rastro de auditoría de qué se envía. El pixel de TikTok decide en runtime qué cuenta como "contexto adicional", y puede cambiar entre versiones del pixel sin que te enteres. Es el más opaco de los tres toggles.

Por qué no lo necesitas: los eventos que Beaconry envía son explícitos y auditables. Cada campo del payload es trazable a un evento configurado o a un default explícito de Beaconry. El enhanced postback añade ruido, no señal, y lo hace sin tu visibilidad.

Pon a: OFF.

El selector de business funnel template

TikTok te pide elegir un "Business Funnel Template" en el mismo flujo del wizard. Las opciones son E-commerce, Lead generation, Travel, Other. Este es inofensivo. El template solo prefigura qué objetivos de conversión sugiere TikTok en su UI; no impacta lo que fluye o qué eventos se reconocen. Elige el que más o menos encaje con tu negocio o "Other" si no encaja ninguno. Si TikTok no te deja saltar, elige E-commerce como default seguro.

La config mínima real

Dos valores son obligatorios, ni más ni menos:

• Pixel ID (alfanumérico, ~20 caracteres). Visible arriba en la página del Pixel tras la creación.
• Access Token (cadena larga y opaca). Generado en Pixel-Settings → Events API → Set up manually → Generate Access Token. Se muestra una vez, copiar de inmediato.

Ambos van en Beaconry → Tracking → TikTok. Guardar. Clic en "Enviar evento de prueba de TikTok". HTTP 200 con code: 0 significa que funciona.

Cómo se ve el flujo de eventos con la config mínima

En una compra de WooCommerce, con los tres toggles default de TikTok apagados y la config mínima de Beaconry activa:

1. El visitante aterriza desde un anuncio de TikTok con ?ttclid=... en la URL.
2. Beaconry captura ttclid, lo persiste en la cookie first-party nl_ext (gestionada por Beaconry, gated por consentimiento).
3. El visitante navega, añade al carrito, completa el checkout.
4. El evento de purchase de Beaconry dispara server-side vía TikTok Events API: ttclid desde nl_ext, email/teléfono/nombre hasheados desde el pedido WooCommerce, event_id estable, valor, divisa, line items.
5. TikTok atribuye la conversión al clic original del anuncio. Fin.

Sin pixel de navegador. Sin Automatic Advanced Matching. Sin cookies first-party de TikTok en tu dominio. Sin enhanced postback. El match-rate es bueno porque ttclid es la señal de atribución más fuerte que tiene TikTok, y Beaconry la envía en cada evento.

Lo que tiene que hacer el banner de consentimiento

El nl-data-gate de Beaconry es lo que envías por defecto; hace lo correcto. Si usas un CMP distinto (CookieYes, Complianz), asegúrate de dos cosas:

• El CMP establece una cookie o un flag de local-storage que Beaconry lee como analytics-accepted. Beaconry no dispara ningún evento antes de eso.
• Al revocar, el CMP dispara una limpieza que elimina nl_pref, nl_ext y cualquier cookie gestionada por Beaconry. Beaconry tiene un event-hook para esto; el CMP solo tiene que dispararlo.

Si además tienes el modo híbrido activado para TikTok, el script del pixel de navegador también queda gated por el mismo flag, Beaconry solo carga el script tras el consentimiento.

Errores de configuración comunes

• Dejar "Allow first-party cookies" activado. El más común. Hace que las cookies _ttp sobrevivan a la revocación del consentimiento. Una auditoría RGPD lo señalará.
• Pegar el Pixel ID sin el access token. Beaconry omite silenciosamente el dispatch a TikTok. La pestaña Logs muestra "credentials incomplete".
• Poner Test Event Code y olvidarse de quitarlo. Los eventos en vivo van a la pestaña Test Events, Campaign Manager no los ve. Fácil de pasar por alto durante semanas.
• Elegir el método de conexión "Events API only". Bloquea el modo híbrido para después. Elige siempre "TikTok Pixel + Events API (Recommended)", la opción combinada, aunque empieces solo server-side.

Para llevar

El onboarding por defecto de TikTok les da más datos de los que necesitan para atribuir tus conversiones. Ninguno de los toggles "Recommended" hace falta para que la Events API funcione; todos suponen exposición RGPD no trivial. La config mínima real son dos strings (Pixel ID + access token), un parámetro de URL (ttclid) y un consent gate que controla cuándo los eventos salen del navegador. Todo lo demás que ofrece TikTok en el wizard es opcional y, en nuestra lectura, no está en el interés del cliente activarlo.