# Cómo automatizar la recolección de comentarios de Facebook con n8n

Programe enlaces de publicaciones públicas para que se ejecuten de forma automática en intervalos definidos. Espere a que termine el trabajo de recolección y, después, obtenga los datos de comentarios resultantes. Guarde cada comentario con su identificador único para que las comprobaciones repetidas de recolección no creen registros duplicados.

Esta guía ofrece un método de referencia para que usted lo construya y lo pruebe en forma local. Establece un flujo de trabajo de ingesta repetible, no una importación ya armada ni un despliegue completo verificado. Un punto de control es un registro guardado del avance de su ejecución. Un upsert es una operación de base de datos que inserta una fila nueva o actualiza un registro existente si hay coincidencia con una clave única duplicada.

## Alcance técnico y límites operativos

Antes de configurar su flujo de trabajo de n8n, debe entender qué maneja esta canalización de extracción y dónde están sus límites. Este sistema se centra solo en la extracción automática de datos y en el almacenamiento persistente. No hace filtrado de spam, análisis de sentimiento, puntuación de intención del cliente, respuestas automáticas ni moderación de contenido. Si necesita agrupar comentarios en categorías personalizadas, lea nuestra guía sobre [Análisis de comentarios de Facebook como opinión de clientes](/es/articles/exportar-comentarios-de-facebook-y-analizar-la-opini%C3%B3n-de-clientes/). Si necesita derivar preguntas de soporte a una mesa de ayuda activa, consulte nuestro tutorial sobre la [Cola de preguntas sin respuesta en comentarios de Facebook](/es/articles/preguntas-sin-respuesta-en-comentarios-de-facebook/).

Este tutorial cubre la implementación técnica con nodos estándar de n8n y la API HTTP del [Facebook Comments Scraper](https://apify.com/chronometrica/facebook-comments-scraper). Una API (interfaz de programación de aplicaciones) es un conjunto de reglas y puntos de conexión que permite que distintos programas de software se comuniquen entre sí por la web. El scraper acepta como entradas URL públicas de publicaciones específicas y conocidas. No acepta enlaces generales de perfiles, URL de grupos ni páginas de canales de marca. Cuando se ejecuta, el scraper devuelve registros de datos planos con formato JSON (JavaScript Object Notation), que es un formato de texto estándar para compartir datos estructurados.

Cada fila de salida representa un comentario de nivel superior o una respuesta anidada directa. La carga útil devuelta incluye identificadores de cadena como commentId y contentId. Tenga en cuenta que authorId y publishedAt pueden ser null, que publishedAt y scrapedAt son marcas de tiempo y que isReply es un valor booleano, no un identificador de cadena exacto. El objeto JSON sin procesar conserva parentCommentId, rootCommentId, isReply, text y los valores null. Entre ejecuciones, su base de datos maneja la deduplicación con una restricción única compuesta sobre contentId y commentId, implementada mediante consultas parametrizadas.

Tenga presentes los siguientes parámetros operativos mientras configura su canalización:

- Enlaces de destino: debe pasar entre 1 y 100 URL públicas explícitas de publicaciones como elementos de cadena dentro de un arreglo.
- Topes de resultados: el parámetro maxResultsPerPost define la cantidad máxima de filas de comentarios y respuestas recolectadas por publicación. Si lo establece en 25, la ejecución queda limitada a un máximo de 25 filas por publicación.
- Extracción de respuestas: establecer includeReplies en true indica al scraper que recolecte respuestas anidadas junto con los comentarios principales.
- Extracción completa: establecer collectAllAvailable en true omite el tope numérico de resultados, aunque sigue sujeto a los límites de visibilidad de la plataforma y a los cargos de cómputo.
- Parámetros de orden: opciones de orden como all, newest o most_relevant determinan cómo Facebook ordena los comentarios antes de la extracción. Operan de forma independiente de los topes de resultados.

## Referencia de puntos de conexión principales de la API

La tabla siguiente resume los puntos de conexión usados en este flujo de trabajo, junto con sus estructuras de URL sin procesar y los campos de respuesta esperados:

| URL del punto de conexión | Descripción | Campos de respuesta esperados |
| --- | --- | --- |
| [https://api.apify.com/v2/acts/chronometrica~facebook-comments-scraper/runs](https://api.apify.com/v2/acts/chronometrica~facebook-comments-scraper/runs) | Inicia la ejecución del scraper | data.id, data.defaultDatasetId, data.defaultKeyValueStoreId, data.status |
| [https://api.apify.com/v2/actor-runs/RUN_ID](https://api.apify.com/v2/actor-runs/RUN_ID) | Comprueba el estado de la ejecución | data.status |
| [https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100](https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100) | Obtiene páginas de elementos del conjunto de datos | Arreglo JSON de registros de comentarios |
| [https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT](https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT) | Inspecciona el almacén de resumen de la ejecución | Registro de resumen específico de la ejecución |

Nota: reemplace los marcadores de posición como RUN_ID, DATASET_ID y STORE_ID por los valores reales de ejecución que guardó. Nunca incluya tokens de acceso directamente dentro de las cadenas de URL.

## Arquitectura paso a paso y secuencia de nodos

Para construir esta canalización en n8n, va a configurar una secuencia estructurada de nodos integrados. Necesitará n8n instalado, un token de API de Apify guardado en una credencial Header Auth de n8n (con el nombre Authorization y el valor Bearer your_token) y una credencial de base de datos relacional (como Postgres).

### 1. Configuración de disparadores y credenciales

Empiece por crear un flujo de trabajo nuevo en n8n. Abra la configuración del flujo de trabajo, seleccione su zona horaria local y deje el flujo de trabajo sin publicar mientras construye y prueba sus componentes.

Va a crear dos puntos de entrada:

- Schedule Trigger: dispara de forma automática su ejecución de recolección recurrente, diaria o por hora, según la configuración de su zona horaria.
- Disparador manual y entrada de recuperación: un punto de entrada manual separado para operadores. Como un disparador manual no puede aceptar un ID de ejecución de forma directa, coloque un nodo Edit Fields después de él, donde un operador pueda ingresar un ID de ejecución guardado existente. Esto le permite recuperar ejecuciones detenidas sin iniciar un trabajo de scraping nuevo.

### 2. Inicio del scraper

Conecte su disparador de programación a un nodo HTTP Request llamado Launch Scraper. Establezca el método en POST y apunte al punto de conexión de ejecución del Actor de Apify. Adjunte su credencial Header Auth. Configure un cuerpo de solicitud JSON plano y pequeño con cadenas de URL sin procesar:

```text
{
  "startUrls": [
    "https://www.facebook.com/story.php?story_fbid=123456789&id=987654321"
  ],
  "maxResultsPerPost": 25,
  "includeReplies": true,
  "collectAllAvailable": false,
  "commentSortMode": "all"
}
```

Arquitectura paso a paso y secuencia de nodos

Cuando esta solicitud tiene éxito, la API de Apify devuelve una envoltura que contiene metadatos de ejecución. Su flujo de trabajo debe capturar y guardar cuatro valores de inmediato: data.id, data.defaultDatasetId, data.defaultKeyValueStoreId y data.status.

Guarde estos valores en un punto de control duradero de la base de datos, con clave por el ID de ejecución. Inicialice el conteo de intentos en cero y el desplazamiento siguiente en cero. Duradero significa almacenado de forma permanente en una base de datos relacional, fuera de la memoria temporal del flujo de trabajo.

Regla de seguridad crítica: nunca reintente de forma automática una solicitud POST de inicio ambigua si ocurre un tiempo de espera de red. Si la primera solicitud llegó al servidor, un reintento a ciegas iniciará una segunda ejecución de scraping facturable. Si un inicio es ambiguo, inspeccione de forma manual la lista de ejecuciones de su cuenta de Apify antes de disparar una nueva.

### 3. La ruta de recuperación

Si una ejecución falla o se detiene, la rama de recuperación manual selecciona el registro de punto de control existente con el ID de ejecución que proporcionó el operador y omite por completo el nodo de inicio.

Su flujo de trabajo aplica una regla de una ejecución activa por ID de ejecución. Si una ejecución recuperada ya muestra en la base de datos un estado terminal guardado SUCCEEDED, el flujo de trabajo omite por completo el sondeo de estado y pasa directo a la carga de páginas. Si el estado guardado es failed, lo deriva a revisión manual. Los demás estados entran en un sondeo acotado. Las ejecuciones de recuperación nunca restablecen de forma automática los conteos de intentos.

### 4. Sondeo de estado y compuerta de contador

Antes de cada comprobación de estado, su flujo de trabajo consulta la base de datos para comprobar el conteo de intentos actual. Si el conteo de intentos llegó a 30, el sistema deriva la ejecución a una rama de revisión manual para evitar bucles infinitos.

Si el conteo es menor que 30, el flujo de trabajo incrementa el conteo de intentos en la base de datos, pausa la ejecución durante 10 segundos con un nodo Wait y, después, usa una solicitud HTTP GET para comprobar el estado de la ejecución en la API de Apify ([https://api.apify.com/v2/actor-runs/RUN_ID](https://api.apify.com/v2/actor-runs/RUN_ID)).

Los errores de solicitud de red durante el sondeo deben usar reintentos de lectura acotados (máximo 3 intentos con una espera de 10 segundos), en lugar de reintentar solicitudes POST.

El flujo de trabajo evalúa el estado devuelto:

- SUCCEEDED: el flujo de trabajo guarda el estado plano en la base de datos y continúa con la obtención del conjunto de datos.
- READY / RUNNING / ABORTING / TIMING-OUT: el flujo de trabajo devuelve la ejecución a la compuerta de contador para esperar y comprobar de nuevo.
- FAILED / ABORTED / TIMED-OUT: el flujo de trabajo registra el estado de falla y se detiene o deriva a revisión manual.
- Estado desconocido: deriva a revisión manual.

Nota: detener su bucle de sondeo no cancela el Actor remoto de Apify; solo hace que su flujo de trabajo de n8n deje de esperar. Un tiempo de espera del sondeo no significa que la publicación tuviera cero comentarios.

### 5. Paginación y carga de páginas

Cuando la ejecución tiene éxito, su flujo de trabajo entra en el bucle de paginación. Antes de obtener cada página, vuelve a cargar desde la base de datos el estado actual del punto de control para tomar el desplazamiento más reciente y el ID del conjunto de datos.

Hace una solicitud HTTP GET para obtener los elementos del conjunto de datos ([https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100](https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100), sustituyendo el desplazamiento actual y el ID de conjunto de datos guardado). Debe apuntar al ID del conjunto de datos de la ejecución específica, no a un alias genérico latest. Establezca el formato de la solicitud en JSON, use clean=false y establezca limit=100.

Configure el nodo HTTP para que devuelva el cuerpo completo de la respuesta. Registre la longitud del arreglo entrante antes de pasar datos a cualquier nodo de división. Si el arreglo de la página inicial está completamente vacío, omita la división e inspeccione el registro de salida del almacén clave-valor mediante su punto de conexión dedicado ([https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT](https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT)), con el ID de almacén guardado, para determinar si ocurrió un error. En las páginas siguientes, un arreglo vacío solo indica el fin de la recolección.

### 6. División y upsert en la base de datos

Pase el arreglo del conjunto de datos a un nodo Split Out configurado con un campo de destino explícito llamado comment.

Su nodo posterior de almacenamiento en la base de datos recibe cada elemento dividido y asigna los campos directamente desde comment. Valida que existan identificadores de cadena no vacíos y marcas de tiempo válidas. Ejecuta una operación upsert con consultas parametrizadas contra una restricción de clave única compuesta (contentId y commentId). Un upsert inserta una fila nueva o actualiza un registro existente si hay una coincidencia duplicada.

Para evitar que datos antiguos sobrescriban actualizaciones recientes, configure la condición de actualización de su base de datos de modo que el texto y los metadatos entrantes se actualicen solo si la marca de tiempo scrapedAt entrante es mayor o igual que la marca de tiempo almacenada. Esto representa el estado observado más reciente de la publicación pública, no un registro de auditoría histórica inmutable ni una prueba de eliminación.

### 7. Avance del punto de control

Después de que cada elemento de la página actual se escribe con éxito en la base de datos, su flujo de trabajo actualiza en la base de datos el desplazamiento del punto de control sumando 100.

Regla crucial: nunca avance el desplazamiento del punto de control una vez por comentario. Debe actualizar el desplazamiento del punto de control exactamente una vez por página, después de que todo el lote tenga éxito. Si una escritura en la base de datos falla a mitad de una página, el desplazamiento del punto de control permanece sin cambios. Así, su flujo de trabajo puede reproducir la página de forma segura sin duplicar registros.

Conserve por separado los metadatos de longitud de la página actual a lo largo de los pasos de división y de base de datos. La comprobación final usa la longitud de la página actual, no la longitud del primer bucle. Si la longitud de la página actual fue menor que 100 elementos, la recolección está completa y el flujo de trabajo termina. Si la longitud de la página es igual a 100, el flujo de trabajo vuelve a cargar el punto de control y obtiene el lote siguiente.

## Protocolo de prueba y validación para el lector

Antes de publicar su flujo de trabajo para que se ejecute de forma automática en producción, debe construirlo y probarlo en forma local con comprobaciones de verificación estructuradas. No dependa de plantillas sin probar.

1. Prueba de ingesta aislada: inyecte una entrada fija de caso de prueba pequeño {body: [25 comments]} directamente en un nodo Split Out dirigido a su nodo de base de datos y configurado para STOP de inmediato. Así omite todos los nodos reales de punto de control y de resumen de página. Verifique que su base de datos almacene exactamente 25 filas. Ejecutar exactamente el mismo caso de prueba una segunda vez da como resultado 0 filas nuevas insertadas y registros existentes evaluados sin regresión. Agregar un registro distinto, el número 26, inserta exactamente 1 fila nueva. Además, verifique que un caso de prueba más antiguo no pueda sobrescribir texto más reciente.
2. Prueba de caso de paginación: pruebe su bucle de desplazamiento con un punto de control simulado y 201 registros en 3 páginas de 100, 100 y 1, sin generar ninguna llamada paga al Actor.
3. Prueba de tolerancia a fallas y de sondeo: pruebe que los conteos máximos de sondeo disparen correctamente la revisión manual en la ruta de sondeo. Simule una falla de escritura en la base de datos en una página intermedia. Verifique que el desplazamiento de su punto de control permanezca sin cambios, que la recuperación no vuelva a iniciar el scraper y que los estados que no son de éxito bloqueen correctamente la obtención del conjunto de datos.
4. Verificación manual en vivo: ejecute una sola prueba manual contra un enlace real de publicación pública. Revise los límites de su plataforma, los costos de cómputo y los registros de ejecución.

Solo después de que todas las pruebas locales tengan éxito y de que la zona horaria de su programación esté configurada correctamente, debe guardar y publicar su flujo de trabajo de n8n.

## Automatice hoy la recolección de comentarios de Facebook

Construir una canalización personalizada de ingesta de comentarios da a su equipo acceso confiable a los datos de debate público, sin exportaciones manuales a hojas de cálculo. Al combinar nodos estándar de n8n con puntos de control duraderos en la base de datos y restricciones únicas compuestas, establece un flujo de trabajo de extracción resistente que maneja las interrupciones de red de forma limpia. Empiece hoy a extraer conversaciones sociales estructuradas con el [Facebook Comments Scraper](https://apify.com/chronometrica/facebook-comments-scraper).

## Fuentes y lecturas adicionales

- [Actor Facebook Comments Scraper](https://apify.com/chronometrica/facebook-comments-scraper)
- [Documentación del Schedule Trigger de n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/)
- [Documentación del nodo HTTP Request de n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/)
- [Documentación del nodo Wait de n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.wait/)
- [Documentación del nodo Postgres de n8n](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.postgres/)
- [Documentación del nodo Split Out de n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.splitout/)
- [Referencia de la API de Apify: obtener la ejecución de un Actor](https://docs.apify.com/api/v2/actor-run-get)
- [Referencia de la API de Apify: obtener elementos de un conjunto de datos](https://docs.apify.com/api/v2/dataset-items-get)
- [Guía de análisis de opinión de Chronometrica](/es/articles/exportar-comentarios-de-facebook-y-analizar-la-opini%C3%B3n-de-clientes/)
- [Guía de preguntas sin respuesta de Chronometrica](/es/articles/preguntas-sin-respuesta-en-comentarios-de-facebook/)