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.

Tiempo de lectura: ~6 minÚltima actualización: 2026-05-02

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.

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.
  • 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.