Troubleshooting

Pixel que no dispara, conversiones que faltan, errores de OAuth, conflictos entre plugins. Las cosas que más fallan, en el orden en el que típicamente aparecen.

Los eventos de Beaconry no llegan a ninguna plataforma

Empieza aquí si nada funciona.

1. Abre tu sitio en un navegador limpio, acepta el banner de consentimiento.
2. Abre DevTools, pestaña Network. Recarga la página.
3. Busca un POST a /wp-json/beaconry/v1/event. Status 202 significa "encolado para despacho".
4. Si no ves la petición: el consentimiento fue rechazado, o el banner está mal configurado. Comprueba Beaconry, Tracking, Dashboard, pill "Consent state".
5. Si ves HTTP 4xx: la REST de WordPress está rota (otro plugin filtra /wp-json/). Desactiva otros plugins uno por uno.
6. Si ves 202 pero ninguna conversión en plataforma: abre Beaconry, Logs. La respuesta de cada plataforma se loggea con request y response payload completos.

Meta, los eventos llegan a CAPI pero el Match Quality es "Poor"

Beaconry envía los campos PII hasheados correctamente. Meta necesita tres señales de confianza para usarlos de verdad:

• Domain Verification en Business Settings, Brand Safety, Domains.
• Trusted domains list en Pixel, Settings, Traffic Permissions.
• Aggregated Event Measurement con orden de prioridad configurado en cada dominio.

Sin esto, Meta sigue grabando el evento pero lo marca como Match "Poor". Configurar las tres cosas dentro de Meta lleva unos 10 minutos y es independiente de Beaconry.

TikTok, "code: 40005, content_id required"

La TikTok Events API rechaza eventos sin un content_id en el array contents[]. Beaconry lo configura automáticamente para eventos WooCommerce (el SKU del producto). Para eventos JS custom, incluye content_id en contents[], no en el top level (TikTok ignora el top-level content_id).

Google Ads, "PERMISSION_DENIED"

La cuenta de Google que ejecutó el handshake OAuth no tiene permiso de edición sobre el Customer ID. Dos arreglos:

• Abre Google Ads, Tools, Access and security. Verifica que la cuenta conectada tiene al menos rol "Standard" en este Customer ID.
• Si usaste una cuenta manager (MCC): conéctate con la cuenta manager, luego especifica el Customer ID de la sub-cuenta en Beaconry. El scope OAuth debe cubrir al manager.

Tras arreglar, pulsa Conectar con Google de nuevo para reautenticar.

Google Ads, conversión subida pero no visible en Campaign Manager

Los datos de conversión de Google Ads tienen hasta 3 horas de latencia. No hay vista de prueba en tiempo real para la API. Espera, después comprueba Campaign Manager, Tools, Conversions, columna Status.

Si tras 6 horas no aparece nada: abre Beaconry, Logs, busca el upload, comprueba la respuesta. partialFailureError con detalles significa que Google rechazó la fila. Razón más común: la Conversion Action está pausada (re-actívala en Campaign Manager).

LinkedIn, "403 Forbidden"

La cuenta de LinkedIn que ejecutó OAuth no tiene permisos sobre la Ad Account. Se requiere rol Account-Manager, Campaign-Manager o Account-Billing-Admin. Viewer-only es rechazado por la API.

Reautentica con una cuenta que tenga al menos rol Campaign-Manager.

LinkedIn, aviso de token caducado

Los access-tokens de LinkedIn caducan tras 60 días. La pestaña Logs de Beaconry recibe un heartbeat diario más un aviso cuando quedan 7 días. Pulsa Conectar con LinkedIn para renovar. Los Conversion-Rule-IDs y el Ad-Account-ID se quedan configurados, solo se repite el handshake OAuth.

GA4, eventos en Tiempo real pero faltan en informes estándar

Los informes estándar de GA4 tienen 24 a 48 horas de retraso de procesamiento. Tiempo real es la fuente de verdad para "¿llegó el evento?". Si Tiempo real muestra el evento, aparecerá en los informes estándar mañana.

El tracking se para en una pestaña abierta durante horas, o en páginas cacheadas

Cada despacho está protegido por un nonce beaconry_event, y los nonces de WordPress caducan (típicamente tras 12 a 24 horas). En una pestaña dejada abierta toda la noche, o en HTML servido desde un page cache, ese nonce normalmente estaría caducado para cuando un visitante convierte. Beaconry renueva el nonce beaconry_event en el lado cliente, así que las pestañas abiertas mucho tiempo y el HTML page-cacheado siguen despachando eventos válidos sin recargar. Si aún ves despachos fallando solo tras periodos largos de inactividad, confirma que la propia petición de refresco no está siendo bloqueada (una regla de caché demasiado agresiva o un firewall delante de /wp-json/).

Mi reembolso no está en Meta ni en Google Ads

Esto es por diseño. Los eventos de reembolso van solo a GA4, porque GA4 tiene un evento de reembolso nativo que descuenta los ingresos reembolsados contra la compra original. Los canales de ads (Meta, TikTok, LinkedIn, Google Ads, Microsoft Ads, Pinterest, X Ads, Snapchat, Reddit) no tienen un evento de reembolso real, así que Beaconry los omite en lugar de falsear uno. Los totales de conversión de tus plataformas de ads se quedan como el conteo bruto de compras, y reconcilias los ingresos netos en GA4.

Números del funnel de formularios (form_start / form_abandon)

Las señales del funnel form_start (primer campo enfocado) y form_abandon (salida sin enviar) aparecen solo en GA4, nunca en los canales de ads. Son señales de analítica para medir el drop-off, no conversiones, así que no hay nada que buscar en Meta o Google Ads.

Para leer el drop-off por formulario en GA4: filtra los eventos por el identificador del formulario, después compara el conteo de form_start contra el evento de envío correspondiente para el mismo formulario. El hueco es tu abandono, y form_abandon marca exactamente qué sesiones se fueron. Si un formulario muestra form_start pero ningún envío, el hook de éxito del formulario no se está disparando (comprueba que el evento de finalización del plugin de formularios llega a Beaconry).

Conflictos entre plugins

• Plugins de caché (W3 Total Cache, WP Rocket): asegúrate de que /wp-json/ está excluido del page caching. La mayoría de cachés WP-aware lo hacen por defecto. Si el tuyo no, tanto el estado del banner de consentimiento como el despacho de eventos pueden romperse. Beaconry además excluye automáticamente su propio inline script de la optimización JS (concatenación, deferral, delay-until-interaction) en LiteSpeed Cache, WP Rocket, SiteGround Optimizer y Cloudflare, para que la lógica de nonce-refresh y despacho nunca se reordene ni se elimine.
• Otros plugins de tracking (PixelYourSite, Tracking Plus, Sky GA4): no corras dos plugins de tracking para el mismo destino. Van a duplicar los eventos. O desactiva el canal de Beaconry para esa plataforma, o desactiva el otro plugin del todo.
• Plugins de consentimiento de cookies (CookieYes, Complianz): Beaconry incluye su propio banner de consentimiento (nl-data-gate). Si ya tienes un CMP, configura el banner de Beaconry como "Hidden" en Beaconry, Banner e integra vía la API. El CMP debe configurar nl_pref = "{analytics: true}" cuando el usuario acepta la categoría analytics.

Eventos WooCommerce que no se disparan

1. Beaconry engancha en woocommerce_thankyou (Purchase), woocommerce_add_to_cart y woocommerce_before_checkout_form. Verifica en Beaconry, Logs que esos hooks se disparan.
2. Si falta un hook en los logs: un tema o plugin está interceptando el flujo de WooCommerce. Comprueba woocommerce status, Tools, Logs por errores durante el checkout.
3. Páginas thankyou personalizadas: el evento Purchase de Beaconry se dispara en la plantilla thankyou estándar de WooCommerce. Si rediriges a una página personalizada tras el pedido, tienes que disparar nlc.track('purchase', ...) manualmente en esa página.

"Mi adblocker sigue bloqueando Beaconry"

El path /wp-json/beaconry/v1/event de Beaconry es estructuralmente adblock-immune. Si lo ves bloqueado:

• Verifica la URL en DevTools. ¿Es realmente /wp-json/beaconry/v1/event en tu dominio, o apunta a un dominio distinto? Si es distinto, el modo híbrido está activo para algún canal y el pixel de ese canal está cargando desde un dominio third-party (que SÍ es bloqueable).
• Si el modo híbrido es la causa, desactívalo para ese canal. El despacho server-side reanuda cubriendo el 100% de los visitantes con consentimiento.

Cuando dudes, comprueba los Logs

Beaconry, Logs guarda los últimos 200 eventos con request y response payload completos. Filtra por canal, tipo de evento o status. La mayoría de los problemas son diagnosticables desde la respuesta de la plataforma en el log entry.

Para depuración más profunda, configura BCNR_DEBUG = true en wp-config.php. La pestaña Logs entonces incluye también los mensajes del transport-layer HTTP de WordPress.

¿Sigues atascado?

Escribe a info@beaconry.app con el nombre del canal afectado, la entrada relevante de Logs y una captura de pantalla de la respuesta de la plataforma. Solemos responder en un día laborable.