--- name: comentarios-linkedin-a-sheets-en-vivo description: Dado un URL de publicación de LinkedIn, crea al instante una hoja de Google Sheets formateada, envía el link al chat de inmediato, y luego extrae cada comentarista y los va transmitiendo a la hoja fila por fila mientras el público observa. Diseñada para demos en escenario donde llegan 500-1000 comentarios en 2-5 minutos y el trabajo debe VERSE rápido y en vivo. Usar cuando Felipe diga "live linkedin comments to sheets", "harvest the comments live", "go get the commenters into a sheet", o cuando esté corriendo una demo en vivo del agente recolectando comentaristas. version: 6 created: 2026-07-09 last_used: 2026-07-30 category: outbound featured: yes image: chart-increasing integrations: [apify, googlesheets, apollo] --- ## Para qué sirve Esta es una habilidad usada en **demos en vivo**. En el escenario, Felipe le pide al público que comente en una de sus publicaciones de LinkedIn y luego le pide a Houston que "vaya a buscarlos todos y los meta en una hoja". Pueden llegar 500-1000 comentarios en 2-5 minutos. La demo solo funciona si el trabajo se **percibe como rápido y en vivo**: la hoja aparece al instante, el link se entrega de inmediato, y las filas se van llenando visiblemente mientras el scraper sigue corriendo. La decisión de diseño central que hace que esto funcione: **desacoplar la hoja del scrape.** Nunca esperes a que termine el scrape para mostrar resultados. Crea la hoja primero, envía el link, y luego llena la hoja con el scraper en lotes. ## LA ÚNICA REGLA IRROMPIBLE **En el instante en que se crea la hoja, envía su link al chat como mensaje propio y sigue trabajando.** No empaquetes el link con el resumen final. No esperes ni un solo comentario antes de enviarlo. Crear hoja -> publicar link -> seguir transmitiendo. Esto no es negociable; toda la demo depende de ello. ## Cuándo usar - Felipe está corriendo una demo en vivo y quiere que los comentaristas de una publicación se recolecten en una hoja - "live linkedin comments to sheets", "harvest the comments live", "get the commenters into a sheet now" - Se pega un URL de LinkedIn reciente y la velocidad/viveza son el punto ## Cuándo NO usar - Pulls de leads silenciosos/producción donde el streaming no importa -> usar `linkedin-comment-scraper` (escribe un archivo JSON, sin hoja en vivo) - Reacciones/likes en vez de comentarios -> usar `linkedin-reaction-scraper` - Un ENVÍO de cold-email -> esta habilidad termina en una hoja ordenada y enriquecida. Cargar una campaña es `instantly-campaign`; escribir el copy es `cold-email-sequence`. ## Requisitos previos (verificar que las conexiones estén ACTIVAS antes de la demo) - Apify conectado (actor: `harvestapi/linkedin-post-comments`) - Google Sheets conectado - Apollo conectado (para la columna de emails) - Ambos fueron confirmados ACTIVOS el 2026-07-09. Verificar justo antes de cualquier demo: `composio connections list --toolkit apify` y `--toolkit googlesheets`. ## Configuración bloqueada de la demo (confirmada por Felipe) | Configuración | Valor | |---|---| | Enriquecimiento | Enriquecimiento de perfil ON (`profileScraperMode: "main"`) para que Empresa sea real, MÁS enriquecimiento de email por Apollo corriendo en paralelo desde el primer lote. | | Columnas | `Name \| Headline \| Company \| LinkedIn URL \| Comment \| Reactions \| Email` — Email lo llena Apollo, nunca se scrapea ni se adivina. Dejarlo en blanco si Apollo no tiene match. | | Nombre de la hoja | `LinkedIn Comments ` — ver "Nombrar la hoja" abajo. Nunca caer silenciosamente a la fecha sin intentar deducir primero el evento. | | maxItems | 1000 | | Orden | Transmitir en orden de LLEGADA; ORDENAR A-Z por nombre UNA SOLA VEZ, al final, después de que toda fila y todo email esté. Una llamada nativa, toda la tabla se reorganiza en pantalla. | | Emails | Apollo empieza con los PRIMEROS perfiles y va llenando la columna G lote a lote, junto al scrape — nunca al final. | | Celdas en blanco | Está bien — dejar cualquier campo faltante en blanco, no eliminar la fila. | | Cadencia de lotes | Jalar 8 chunks por mensaje (15 ítems c/u), escribir cada chunk al recibirlo. | | Disparador | Una ejecución por solicitud. Si llegan más comentarios, Felipe dice "re-run" -> dedup + agregar solo los nuevos. | ## Transportes - **Apify** via las herramientas MCP de `apify` (preferido) o Composio (toolkit `apify`). - **Google Sheets** via Composio (toolkit `googlesheets`). Slugs probados y formas exactas (testeados de punta a punta el 2026-07-09 — confiar en estos, omitir el descubrimiento en vivo por velocidad de demo; recurrir a `composio search` / `--get-schema` solo si una llamada falla): - Crear hoja: `GOOGLESHEETS_CREATE_GOOGLE_SHEET1` — body `{"title": "..."}`. No es idempotente, crear exactamente una vez por ejecución. - Estilizar la fila de encabezado: `GOOGLESHEETS_FORMAT_CELL` — **NO** `GOOGLESHEETS_BATCH_UPDATE` (ese slug rechaza la forma repeatCell/updateSheetProperties que se intentó; la validación falla). Parámetros en snake_case: `{"spreadsheet_id", "worksheet_id" (int sheetId, ej. 0), "range" ("A1:G1"), "red"/"green"/"blue" (floats 0-1), "text_color" (hex string "#FFFFFF"), "bold": true, "font_family": "Arial", "font_size": 10}`. - Congelar la fila de encabezado: `GOOGLESHEETS_UPDATE_SHEET_PROPERTIES` — camelCase, sobre anidado: `{"spreadsheetId", "updateSheetProperties": {"properties": {"sheetId": 0, "gridProperties": {"frozenRowCount": 1}}, "fields": "gridProperties.frozenRowCount"}}`. - Agregar filas (streaming durante la ejecución en vivo): `GOOGLESHEETS_SPREADSHEETS_VALUES_APPEND` — parámetros camelCase: `{"spreadsheetId", "range" (debe incluir nombre de la hoja, ej. "Sheet1!A:G"), "valueInputOption": "USER_ENTERED", "values": [[...]]}`. - Sobreescribir un rango existente (para corregir datos malos después del hecho, no durante el streaming normal): `GOOGLESHEETS_VALUES_UPDATE` — parámetros **snake_case**: `{"spreadsheet_id", "range", "value_input_option", "values"}`. - Leer un rango para verificar: `GOOGLESHEETS_VALUES_GET` — snake_case: `{"spreadsheet_id", "range"}`. - **Gotcha: el casing de parámetros NO es consistente entre los slugs de Sheets.** APPEND y UPDATE_SHEET_PROPERTIES usan camelCase (`spreadsheetId`, `valueInputOption`); VALUES_UPDATE, VALUES_GET y FORMAT_CELL usan snake_case (`spreadsheet_id`, `value_input_option`). No asumir — si una llamada da 400 con "Required: spreadsheetId" o similar, casi siempre es esto. - Ejecución async de Apify (fire-and-forget): Composio `APIFY_RUN_ACTOR` con parámetros `{"actorId": "harvestapi~linkedin-post-comments", "body": {"posts": [""], "maxItems": 1000, "profileScraperMode": "main"}}`. **Confirmado 2026-07-30: los parámetros son `actorId` + `body`.** Pasar `actor_id` / `run_input` / `input` se ignora silenciosamente — la ejecución arranca, termina en ~2s con `inputBodyLen: 30` y un dataset vacío. Verificar `stats.inputBodyLen` en la respuesta del run: ~30 significa que el input fue descartado. **El campo de input del actor es `posts` (array de URLs de publicación), no `urls`.** - Consultar estado del run: `APIFY_ACTOR_RUN_GET` `{"runId", "waitForFinish": 30}` (máx 60; valores más altos pueden hacer timeout a la llamada de Composio). - Jalar ítems — **usar la proyección compacta, es 5x más pequeña** (confirmado 2026-07-30): `APIFY_GET_DATASET_ITEMS` con `{"datasetId", "limit": 15, "offset": N, "unwind": "actor", "omit": ""}`. La lista pesada (copiar literalmente): `about,skills,topSkills,certifications,courses,education,interests,languages,honorsAndAwards,volunteering,services,organizations,patents,causes,featured,publications,projects,receivedRecommendations,moreProfiles,profilePicture,coverPicture,picture,photo,pictureUrl,multiLocaleHeadline,profileActions,profileLocales,profileTopEducation,replies,commentaryAttributes,linkedinUrl,id,objectUrn,registeredAt,primaryLocale,query,emails,currentPosition` - `unwind: "actor"` sube el perfil al nivel superior y MANTIENE `commentary` y `engagement`, así una llamada da toda la fila. - Hay que omitir `linkedinUrl` (la URL del comentario ensombrece a la del perfil) y reconstruir la URL del perfil como ` - `omit` es SOLO DE NIVEL SUPERIOR — `experience.companyLogo` y similares se ignoran, por eso el tope es 15 ítems por llamada, no 40. - `fields` funciona SOLO POR SÍ MISMO. Combinado con `unwind` o `flatten` retorna objetos vacíos silenciosamente, y no puede seleccionar claves anidadas. - **Las respuestas sobredimensionadas se guardan en archivo y se TRUNCAN mid-JSON.** Nunca usar `json.load`: encontrar `"items"`, luego `raw_decode` objeto por objeto hasta que falle. Rastrear cuántos ítems retornó cada chunk, hacer diff contra lo solicitado, y rellenar los gaps — un chunk que retorna 11 de 15 es normal. - Leer la publicación (para el nombre del evento): `APIFY_RUN_ACTOR_SYNC_GET_DATASET_ITEMS` `{"actorId": "pratikdani~linkedin-posts-scraper", "input": {"url": ""}, "fields": "post_text", "limit": 1}` — retorna `post_text`, un ítem, rápido. - Ordenar la tabla A-Z: `GOOGLESHEETS_SORT_RANGE` — id en snake_case, specs en camelCase: `{"spreadsheet_id", "range": {"sheet_id": 0, "start_row_index": 1, "end_row_index": <última fila>, "start_column_index": 0, "end_column_index": 7}, "sortSpecs": [{"dimensionIndex": 0, "sortOrder": "ASCENDING"}]}`. `start_row_index: 1` salta el encabezado (índices son 0-based, fin exclusivo). Mueve FILAS COMPLETAS, así lo que ya esté en la columna G viaja con su persona. - Emails: `APOLLO_BULK_PEOPLE_ENRICHMENT` `{"details": [ ...máx 10 personas... ]}`. Cada entrada: `{"first_name", "last_name", "linkedin_url", "company_name"}`. 10 es el tope duro (400/422 si se pasa). La respuesta es ~7 KB por persona, así que cada llamada aterriza en un archivo — parsear desde disco, nunca inline. ### Obtener la Empresa (confirmado 2026-07-30) El actor de comentarios SÍ puede retornar datos reales de empresa — solo hay que pedirlo: `profileScraperMode: "main"` enriquece a cada comentarista con su perfil completo. Entonces `actor.experience[]` está presente, y Empresa = `companyName` de la primera experiencia sin `endDate` (su rol actual); fallback a `experience[0]`. También disponible en modo main si alguna vez se necesita: `actor.location`, `actor.headline`, `actor.followerCount`, `actor.experience[].companyLinkedinUrl`, `actor.emails` (observado vacío — NO depender de él para email). Costo y velocidad, medido dos veces en el mismo post de 215 comentarios: - `short`: 32s, $0.43, Empresa en blanco para ~94% de filas (solo inferencia del headline). - `main`: ~104s, $0.87, Empresa llenada para **98%** de filas (208/213). Usar `main` por defecto — el scrape no es el cuello de botella (ver abajo), y el enriquecimiento corre mientras las filas ya están fluyendo a la hoja. Bajar a `short` solo si el post es enorme (500+ comentarios) y la velocidad supera los datos. El ~2% en blanco son perfiles sin sección de experiencia; dejarlos en blanco, nunca adivinar. ## Velocidad: qué realmente cuesta tiempo Medido de punta a punta en el post de 215 comentarios (2026-07-30): | Fase | Secuencial (primera versión) | Paralelo (versión actual) | |---|---|---| | Hoja creada + link en el chat | ~30s | **~10s** | | Scrape termina | 105s | 103s (sin cambio — es del lado del servidor) | | Todos los registros jalados | ~6 min (36 llamadas seriales) | **3m18s** (20 llamadas, 8 por mensaje) | | Ordenar A-Z | manual, por Felipe | una llamada al final, instantáneo | | Emails | trabajo separado, después | fluyen a columna G junto al scrape | El scrape NO es el cuello de botella — **jalar el payload enriquecido sí lo es**. Dos soluciones, ambas requeridas: la proyección compacta de arriba (15 ítems por llamada en vez de 6) y paralelizar las jaladas. ### Cómo paralelizar (sin herramienta de subagente) Concurrencia aquí significa **varias llamadas a herramientas EN UN SOLO MENSAJE** — se ejecutan al mismo tiempo. Si hay una herramienta Task/subagent disponible, un shard por subagente es incluso mejor (cada uno retorna solo las filas parseadas, manteniendo el contexto principal ligero); sin ella, las llamadas en lote dan la misma ganancia de tiempo de reloj. 1. **T0, un mensaje:** crear la hoja + lanzar el run de comentarios (async) + obtener el texto de la publicación para el nombre del evento. Tres llamadas independientes, sin esperas. 2. **Publicar el link de inmediato.** Luego, un mensaje: escribir la fila de encabezado, estilizarla, congelarla y renombrar la hoja al nombre del evento deducido — cuatro llamadas a la vez. (Crear la hoja con un título placeholder y renombrarla unos segundos después; la URL nunca cambia, así el link ya enviado sigue válido.) 3. **Loop de jalada:** disparar **8 chunk pulls por mensaje** (offsets 0, 15, 30, …). No esperar a que el run termine — los ítems aparecen desde ~30s. Parsear, anotar los gaps, disparar los próximos 8 (rellenar gaps primero). Dos o tres rondas cubren ~200 comentarios. 4. **Escrituras:** cada chunk es independiente. Ya sea APPEND de cada chunk al recibirlo, o calcular rangos explícitos disjuntos (`A2:G72`, `A73:G143`, …) y disparar las llamadas de `GOOGLESHEETS_VALUES_UPDATE` juntas — los rangos disjuntos nunca colisionan. La vieja regla de "nunca escribir en paralelo" aplica solo a APPENDs ciegos. 5. **Condición de parada:** estado del run SUCCEEDED *y* sin gaps *y* el último chunk vino corto. ### La coreografía: todo fluye, el orden es el final Dos cosas se mueven en pantalla a la vez, y el orden es lo último que sucede: 1. **Los nombres fluyen por la columna A** (orden de llegada) — primeras filas ~40s. 2. **Los emails los persiguen por la columna G**, lote a lote, mientras el scrape sigue corriendo. El público ve dos columnas llenándose al mismo tiempo. 3. **Toda la tabla se ordena A-Z** — una llamada, al final, solo cuando cada fila está escrita Y cada lote de Apollo aterrizó en la columna G. **Ordenar AL FINAL, exactamente una vez.** Esta es la regla que hace el streaming seguro: mientras llegan filas, cada fila mantiene una dirección fija, así un email puede escribirse directo en ella. Ordenar a mitad del run movería a las personas de bajo las direcciones donde aún estás escribiendo. Verificado 2026-07-30: `GOOGLESHEETS_SORT_RANGE` sobre `A2:G<última>` mueve FILAS COMPLETAS, así cada email llega al final aún junto a su persona. ### Emails: transmitirlos, alineados a bloques de filas Apollo es el palo largo (22 llamadas para ~215 personas), así que arranca tan pronto existen los primeros perfiles — nunca después del scrape. **El truco que hace los emails escribibles en una sola llamada: construir los lotes de Apollo desde FILAS CONSECUTIVAS de la hoja.** Tomar las filas que recién se escribieron (digamos filas 38-47), enviar exactamente esas 10 personas a Apollo, y la respuesta mapea de vuelta exactamente a `G38:G47` — una sola escritura contigua, sin dispersión, sin llamadas por celda. Los límites de lote y los bloques de filas se mantienen alineados de punta a punta. El loop, por chunk de scrape que llega: 1. Escribir las nuevas filas (columnas A-F) en su rango conocido. 2. Dividir esas mismas filas en grupos de 10 **en orden de fila** y disparar 6-8 llamadas de `APOLLO_BULK_PEOPLE_ENRICHMENT` en un mensaje (10 personas es el tope duro). Cada entrada: `{"first_name", "last_name", "linkedin_url", "company_name"}`, dividiendo el nombre solo en el PRIMER espacio. 3. Cuando cada respuesta llega, escribir su bloque de 10 celdas en columna G de inmediato — `{"range": "Sheet1!G38:G47"}`. Blancos para no-matches; cada bloque se escribe una vez por exactamente un lote, así nada sobreescribe un email encontrado. 4. Publicar una línea de progreso: "62 emails hasta ahora…". Parsear Apollo: `matches` está alineado posicionalmente con tu solicitud y contiene `null` para misses — así el índice i de la respuesta ES la posición i del bloque de filas, por eso la escritura en bloque es segura. Cruzar con `linkedin_url` (Apollo lo retorna como ` — normalizar antes de comparar). Tratar `email: null` y `email_status: "unavailable"` como un no-match normal, nunca reintentar. Medido en la hoja de 213 filas (2026-07-30): 22 lotes, ~130 créditos de Apollo, **92 emails (43%)**. El rango documentado de Apollo es 50-70%; SMB de LATAM y perfiles independientes lo bajan, así que cotizar 40-50% para esta audiencia, no 70%. Cada llamada factura créditos así no encuentre un email. ### La trampa del orden de filas Los chunks llegan fuera de orden y los rellenos de gaps llegan tarde, así el ordenamiento global cambia mientras transmites. Si escribes el chunk 1 en `A2:G37` y después recalculas un orden global, las filas se desplazan, obtienes duplicados, y cada email que ya escribiste ahora está junto a la persona equivocada. **La regla: la dirección de una fila queda fija el momento en que se escribe.** Hacer append de cada chunk al recibirlo, registrar `URL de perfil -> número de fila` en un mapa local, y nunca recalcular un orden global. El orden de llegada no importa — el orden al final arregla la presentación. Dedup por URL de perfil contra todo lo ya escrito. Ese mapa local es lo que permite que fluyan los emails: es lo único que debe mantenerse verdadero entre "fila escrita" y "email escrito". ## El Flujo de Trabajo ### Paso 0 — Validar el URL (instantáneo) Aceptar `/posts/...`, `/feed/update/urn:li:activity:...`, `/feed/update/urn:li:ugcPost:...`. Si es un link acortado/redirect, resolverlo primero. No frenar la demo — si parece un URL válido de publicación, continuar. ### Paso 0.5 — Nombrar la hoja (nunca caer a la fecha por defecto) La hoja se llama `LinkedIn Comments `. Seguir esta escalera: 1. **Felipe lo nombró** en el mensaje disparador ("el taller de Sandler", "LAB 10") → usar ese, sin preguntas. 2. **Deducirlo de la publicación.** Jalar `post_text` con el scraper de publicaciones (slug arriba) y leerlo para el evento: un taller/bootcamp/webinar nombrado, un nombre de comunidad o socio, una fecha. Ejemplo (run 2026-07-30): el texto de la publicación nombraba un bootcamp gratuito con la comunidad Sandler Dan Macías → un buen nombre fue "Sandler Bootcamp". Cruzar con los comentarios — los asistentes suelen nombrar el evento ellos mismos ("estuve en la sesión de LAB 10"). 3. **Preguntar, en UNA pregunta corta**, ofreciendo el nombre deducido como opción recomendada, más la fecha de hoy como fallback. Hacer esto ANTES de crear la hoja — renombrar a mitad de la demo se ve peor que una pregunta de 5 segundos. 4. Solo si no se puede preguntar (Autopilot / sin respuesta) usar el nombre deducido; la fecha de hoy es el último recurso, y decirlo claramente. ### Paso 1 — Fan-out T0: hoja + scrape + texto del post, TODO EN UN MENSAJE Enviar estas tres llamadas juntas; nada aquí depende de otra cosa: 1. Crear la hoja. Si ya se conoce el nombre del evento usarlo; de lo contrario usar un placeholder como `LinkedIn Comments — cargando` y renombrar en el Paso 2. 2. Lanzar `harvestapi/linkedin-post-comments` async (fire-and-forget) con `{ "posts": [""], "maxItems": 1000, "profileScraperMode": "main" }`. Nunca una llamada sync bloqueante — eso destruye el efecto en vivo. 3. Obtener `post_text` con el scraper de publicaciones, para el nombre del evento (Paso 0.5). **Luego PUBLICAR EL LINK AL CHAT DE INMEDIATO**, como mensaje propio y corto: > La hoja está lista — ábrela aquí: . Jalando los comentaristas ahora, observa cómo se llena. ### Paso 2 — Vestir la hoja mientras corre el scrape (un mensaje, 4 llamadas) Disparar juntas: fila de encabezado `Name | Headline | Company | LinkedIn URL | Comment | Reactions | Email`; estilizado del encabezado (fondo negro, Arial blanco negrita 10); `frozenRowCount: 1`; y el renombre al nombre real del evento. Email queda como columna solo de encabezado — es el destino del enriquecimiento posterior, nunca se scrapea aquí. NO esperar al scrape entre estos. ### Paso 3 — Loop de streaming (el llenado en vivo), 8 pulls por mensaje **Antes de hacer el loop: jalar UN ítem de muestra e imprimir su forma raw.** Seguro barato — el 2026-07-09 el parser asumió claves con puntos flat (`"actor.name"`) cuando el payload era anidado, y silenciosamente escribió celdas en blanco para cada columna excepto `commentary`. Repetir hasta que el run sea SUCCEEDED, no haya gaps, y el último chunk haya venido corto: 1. Disparar **8 chunk pulls en un mensaje** con la proyección compacta (limit 15, offsets no cubiertos aún, rellenar gaps primero). 2. Mapeo de campos — después de `unwind: "actor"` todo queda al nivel superior: - `name` -> Name - `position` (o `headline`) -> Headline, texto libre, no se divide en título/empresa - ` -> LinkedIn URL (el `linkedinUrl` raw es la URL del COMENTARIO después del unwind — nunca usarlo) - `commentary` -> Comment (`.strip()`) - Reactions: no hay un campo único de conteo de reacciones. `engagement.reactions` es un array de `{type, count}` — sumar los counts; si está vacío usar `engagement.likes`. Default 0. - Company: `experience[]` → `companyName` de la primera entrada cuyo `endDate` esté ausente o sea `{"text": "Present"}` (rol actual), si no `experience[0]`. Si `experience` está vacío (~2% de perfiles), intentar parsear `position` buscando " at X" / " @ X" (cortar en el próximo `|`/`•`/`·`/salto de línea); si falla, dejar en blanco — nunca adivinar. En titulares en español NO parsear " en X" — produce basura como "seguros de vida, retiro e inversiones". - Email: nunca lo retorna el scraper. Viene del track de Apollo, que se arranca con el primer chunk (ver "Emails" arriba). - Eliminar filas solo donde `publicIdentifier` esté ausente (cuentas eliminadas). Mantener filas con Headline/Company/Comment/Reactions en blanco. - Dedup por URL de perfil contra todo lo ya escrito en este run. 3. Escribir cada chunk al recibirlo — APPEND, o un rango explícito disjunto. Las escrituras paralelas están bien SOLO con rangos explícitos disjuntos; nunca disparar APPENDs ciegos concurrentemente. Registrar `URL de perfil -> fila` para cada fila escrita, y nunca recalcular un orden global de filas a mitad del stream (ver la trampa del orden de filas arriba). 4. Disparar de inmediato los lotes de Apollo para esas mismas filas (ver "Emails" arriba), y escribir cada bloque retornado en la columna G al recibirlo. 5. Publicar una línea corta de progreso cubriendo ambos tracks: "138 adentro, 61 emails…". 6. La latencia natural de las herramientas regula el ritmo; si realmente se necesita una pausa usar un loop Monitor hasta que se cumpla una condición, nunca un sleep en primer plano. ### Paso 4 — Ordenar A-Z (el final, UNA llamada, LA ÚLTIMA) **Barrera dura. Cada una de estas debe ser verdadera antes de ordenar:** - El estado del run de Apify es SUCCEEDED - cada gap de offset está rellenado (no faltan ítems del dataset) - cada fila está escrita en la hoja - **cada lote de Apollo volvió Y su bloque está escrito en la columna G** Luego disparar `GOOGLESHEETS_SORT_RANGE` sobre `A2:G<última>` en columna 0 ascendente. Toda la tabla se reorganiza de golpe, emails incluidos, y la demo termina en una lista alfabética limpia. Decirlo en el chat ("ordenado A-Z, es tuya"). Ordenar UNA VEZ. Nunca ordenar antes para "limpiar" a mitad del run, y nunca ordenar dos veces. Si un lote de Apollo falla o se cuelga, no ordenar alrededor de él: reintentar ese lote, y si genuinamente falla, escribir su bloque como blancos primero — luego ordenar. La barrera es "todo lote contabilizado", no "todo lote con match". La razón por la que la barrera es absoluta: en el instante en que corre el orden, tu mapa `URL de perfil -> fila` queda obsoleto, y cualquier email escrito después necesita una nueva lectura de la columna de nombres para encontrar a su persona. Esperar unos segundos siempre es más barato que recuperarse de eso. (Google también ordena insensiblemente a mayúsculas/acentos por locale, así un `sorted()` local de Python no reproducirá su orden — nunca asumir el orden post-sort, leerlo de vuelta si se necesita.) ### Paso 5 — Cerrar (el remate) Publicar estadísticas finales: comentarios raw jalados / comentaristas únicos escritos / empresas llenadas / emails encontrados + tasa de match / créditos de Apollo gastados. La tabla está ordenada y enriquecida — no queda nada que Felipe tenga que hacer a mano. ### Ruta de re-run (llegaron más comentarios) Cuando Felipe dice "re-run": jalar el dataset de nuevo desde offset 0, dedup por URL de perfil contra lo que ya está en la hoja, agregar SOLO los nuevos comentaristas, enriquecer solo esos, y re-ordenar todo el rango. Reportar cuántos nuevos se agregaron. ## Errores Comunes | Error | Solución | |---|---| | El link se envía solo al final | Enviarlo en el instante en que la hoja existe — Paso 1.4. Este es el punto central. | | Llamada sync bloqueante al scrape | Usar fire-and-forget (`waitSecs: 0` / async run) para que el streaming pueda empezar de inmediato. | | Solo se retornan 20 filas | El `maxItems` por defecto del actor es 20 — siempre poner 1000. | | Appends paralelos | Hacer append secuencialmente; los appends concurrentes colisionan y saltan filas. Los rangos explícitos disjuntos sí son seguros en paralelo. | | Ordenar antes de que todos los lotes de Apollo vuelvan | Barrera dura — ver Paso 4. Ordenar a mitad del run mueve a personas de bajo las direcciones de fila donde aún estás escribiendo emails. Un lote fallido se reintenta o blanquea, nunca se ordena alrededor de él. | | Retener emails hasta el final | Deben fluir — ese es el efecto en vivo. Las direcciones de fila son estables hasta el orden, así escribir cada bloque de Apollo en el momento en que retorna. | | Lotes de Apollo que no se alinean con bloques de filas | Construir cada lote de 10 desde FILAS CONSECUTIVAS de la hoja; entonces cada respuesta es una sola escritura contigua `G{n}:G{n+9}` en vez de 10 escrituras dispersas por celda. | | Arrancar Apollo solo después de que el scrape termina | Duplica el tiempo de reloj. Arrancar con el PRIMER chunk de perfiles — los dos tracks se traslapan completamente. | | Confiar en un `sorted()` local para que coincida con la hoja | La colación de Google ignora mayúsculas/acentos diferente. Leer la columna D de vuelta después de ordenar para conocer el orden real. | | Prometer una tasa de 70% de emails | Medido 43% en esta audiencia LATAM. Cotizar 40-50% y reportar el número real. | | Reintentar no-matches de Apollo | `email: null` es una respuesta válida y el crédito ya se gastó. Reportarlo, no reintentar. | | Eliminar filas con campos en blanco | Mantenerlas — los blancos están bien según Felipe. Solo eliminar `profileUrl` nulo. | | El re-run crea duplicados | Dedup por `linkedinUrl` contra la hoja existente antes de hacer append. | | El scrape largo se ve "atascado" | 500-1000 comentarios toman 2-5 min — las líneas de progreso del streaming cubren esto; seguir publicando conteos. | | Asumir campos con puntos flat (`item["actor.name"]`) | El payload real es anidado (`item["actor"]["name"]`). Solo campos verdaderamente de nivel superior como `commentary` se verán "bien" con un lookup flat — todo lo demás silenciosamente vuelve en blanco. Jalar un ítem de muestra e imprimir su forma raw antes de escribir el parser. | | Asumir que existe un campo `fullName` / `profileUrl` | Esos nombres de campo fueron una suposición de un borrador anterior y son incorrectos. Campos reales: `actor.name`, `actor.position`, `actor.linkedinUrl`. | | "El actor no puede retornar empresa" | Sí puede — `profileScraperMode: "main"` agrega `actor.experience[].companyName`. La habilidad antigua decía lo contrario; eso era solo verdad del modo `short`. | | Nombrar la hoja con la fecha de hoy porque no se dio un evento | Deducir el evento del texto del post primero, luego preguntar. La fecha es el último recurso — ver Paso 0.5. | | `fields` + `unwind`/`flatten` juntos | Retorna objetos vacíos. Para jaladas enriquecidas usar `unwind` + `omit` (sin `fields`). | | `json.load` en un resultado de herramienta sobredimensionado guardado | Esos archivos están truncados mid-JSON. `raw_decode` objeto por objeto y rellenar los gaps. | | Jalar ítems enriquecidos de a una llamada | 36 llamadas seriales tomaron ~6 min. Proyección compacta + 8 pulls por mensaje: 20 llamadas, ~3 min. | | Tomar `linkedinUrl` después de `unwind: "actor"` | Esa es la URL del COMENTARIO. Construir la URL del perfil desde `publicIdentifier`. | | Reescribir filas con un orden global recalculado a mitad del stream | Los rellenos de gaps cambian el orden y duplicas filas. Hacer append por chunk, o escribir una sola vez al final. | | Esperar al scrape antes de crear la hoja o leer el post | Los tres son independientes — dispararlos en el mismo mensaje en T0. | | Adivinar slugs/casing de parámetros de Google Sheets | Los slugs confirmados y el casing exacto de parámetros están listados bajo Transportes — no improvisar `GOOGLESHEETS_BATCH_UPDATE` ni mezclar camelCase/snake_case; revisar la tabla primero. | | Input del actor `{"urls": [...]}` | Clave incorrecta. El schema de input del actor usa `{"posts": [...]}`. | | Sobreescribir datos malos con APPEND | APPEND siempre agrega filas nuevas. Para corregir filas ya escritas, usar `GOOGLESHEETS_VALUES_UPDATE` apuntando al rango exacto estilo `A2:F{n}`, no append. | ## Campos de output de Apify (referencia) Confirmado 2026-07-09 contra `harvestapi/linkedin-post-comments` — objeto anidado, no flat: ``` { "commentary": "...", // -> Comment "engagement": { "likes": 0, "reactions": [ { "type": "...", "count": 1 } ] // sumar counts -> Reactions (fallback: likes) }, "actor": { "name": "...", // -> Name "position": "...", // -> Headline (texto libre; Company es un parseo best-effort, puede quedar en blanco) "linkedinUrl": " // -> LinkedIn URL, ya normalizado } } ``` En modo `main` el objeto `actor` es el perfil completo, agregando (entre muchos otros campos): ``` "actor": { "name": "...", "headline": "...", "position": "...", "linkedinUrl": " "location": { "parsed": { "country": "...", "text": "..." } }, "experience": [ { "companyName": "Belcorp", // -> Company "position": "Commercial Senior Manager", "companyLinkedinUrl": " "startDate": {...}, "endDate": null } // endDate null = rol actual ], "emails": [] // siempre vacío — no es una fuente } ``` El email nunca lo retorna este actor en ningún modo. Requiere un paso de enriquecimiento separado (Apollo/Hunter) aguas abajo de esta habilidad.

Bio

Skills · 1

Works with