¿Apify o scrapers propios?

El pedido original mezclaba la pregunta de fondo (comprar o construir) con decisiones de diseño. Se reescribió para que tenga criterios de decisión medibles y supuestos explícitos. Sobre esta versión trabajó toda la investigación.

• Interpretaciones: «Archify» es Archify, la herramienta de diagramas con la que están hechos los diagramas de flujo de este informe. Una primera lectura lo tomó como Apify, que de todos modos es una de las opciones evaluadas. La «Y» de la lista de redes se leyó como TikTok. El cliente se asumió en Colombia, con contenido en español.
• Restricción dominante: el mantenimiento a largo plazo pesa más que el costo unitario (35 % frente a 25 % en la matriz de decisión).
• Hipótesis a validar: YouTube casi gratis, Meta y X caros, proxies móviles comprados en Cloudflare y autorreparación con LLM.

Cuánto le cuesta al cliente mantener el sistema funcionando cada mes: lo que cobran los proveedores de datos, el NLP, Cloudflare y el almacenamiento en R2. No incluye el desarrollo ni las horas de soporte en dólares. Las horas se muestran aparte, como referencia, para que las valores tú.

Cada escenario asigna una fuente a cada red. El precio de cada proveedor varía dentro de su rango de incertidumbre, simulado con 1.500 iteraciones en el navegador. El almacenamiento crece mes a mes porque el lago acumula datos.

• Para un presupuesto de unos USD 2.400 al año (USD 200 al mes) con 100.000 registros caben «YouTube oficial + Apify» (USD 150), «Bright Data» (USD 128) y «APIs por request» (USD 33). Se recomienda la primera: es la que mejor equilibra estabilidad, cobertura y precio. Agregar la API oficial de X (USD 234 en total) la pasa del presupuesto por unos USD 400 al año.
• La API oficial de X es la pieza más cara. Cuesta unos USD 84 al mes con 15.000 registros de X. Pasar X al actor de Apify ahorra unos USD 1.000 al año, a cambio de perder las respuestas y de depender de un actor de un socio.
• Los comentarios son lo que más consume. Bajar el tope de comentarios por publicación, o la proporción de comentarios en la mezcla, es la palanca más directa para ajustar el consumo al presupuesto.
• Construir no ahorra en consumo. Proxies móviles, cuentas, cómputo y CAPTCHAs cuestan más que Apify con 100.000 registros, y además exigen 60 horas o más de soporte al mes.

La regla es simple: la recolección queda fuera de Cloudflare y todo lo demás vive dentro de la cuenta del cliente. Los proveedores entregan JSON y el cliente es dueño del pipeline, del lago y de la aplicación. Cinco decisiones mantienen el soporte cerca de cero:

1. Un adaptador por fuente. Cada proveedor tiene un módulo que traduce su JSON al esquema silver común. Cambiar un actor de Apify por otro, o Apify por Bright Data, es reescribir un adaptador y una línea de configuración. Esta es la autorreparación que sí vale la pena.
2. Contratos de datos en la ingesta. Que una corrida termine en SUCCEEDED no garantiza datos buenos: hay corridas exitosas vacías, actores que insertan filas simuladas y campos que desaparecen (Instagram dejó de enviar reshareCount el 1 de octubre de 2026). Se valida el conteo esperado, la tasa de nulos por campo y el esquema. Si algo falla, se alerta y se pasa al proveedor de respaldo.
3. Idempotencia y tope de gasto. Cada corrida lleva un tope de cobro, y el runId evita ingerir dos veces el mismo dataset. El planificador se detiene si se agota el presupuesto del mes.
4. El crudo siempre se guarda. Bronze conserva el JSON original, la versión del actor y la fecha. Si un adaptador tenía un error, silver se reconstruye sin volver a pagar por los datos.
5. Solo servicios administrados. Sin servidores, sin Spark y sin contenedores de larga vida que parchear. Desde el 1 de octubre de 2026 la plataforma de datos de Cloudflare se llama Basin, y conviene construir con esos nombres desde el inicio porque los anteriores (R2 Data Catalog, R2 SQL, Pipelines) serán retirados.

El termómetro mide la conversación en línea, no la opinión de la población. Los datos casi nunca traen la ciudad, así que hay que construirla y mostrar con qué confianza se asignó.

• X: solo entre el 0,5 % y el 2 % de las publicaciones trae un lugar etiquetado. El campo de ubicación del perfil es texto libre y está vacío o no es geográfico en un tercio de los casos.
• Instagram es la red con más etiquetas de lugar: el 19 % de las fotos en el único estudio grande (2014). Pero la recolección por URL de ubicación está rota en el actor oficial de Apify desde julio de 2026, con la incidencia todavía abierta.
• TikTok da la ciudad solo en los videos geoetiquetados (campo locationMeta); en el resto, solo el país. Las páginas de lugares (POI) se pueden recolectar con un actor de un socio de Apify por USD 0,30 por 1.000.
• YouTube solo da el país del canal, que el propio creador declara.
• Facebook solo da la dirección de las páginas.

La regla de backend es resolver una vez, guardar el identificador nativo y refrescar por identificador. Buscar por nombre en cada corrida es caro (las búsquedas de YouTube tienen una bolsa de 100 al día y en Instagram son las más frágiles: el 90,8 % de corridas exitosas, frente al 99 % de los demás actores) y produce falsos positivos con nombres comunes.

• Perfil: diario en Instagram, TikTok, YouTube y X; semanal en Facebook, donde cada página cuesta USD 8,20 por 1.000. El perfil de Instagram ya trae las últimas 12 publicaciones con sus métricas, así que las publicaciones recientes se actualizan sin costo extra.
• Publicaciones nuevas: cada día, con filtro de fecha desde la última corrida y un día de traslape.
• Métricas de cada publicación: cada 12 horas durante las primeras 48, a diario hasta el día 7 y semanal hasta el día 30. Después la publicación se congela. En YouTube se usa videos.batchGetStats, que tiene bolsa propia.
• Comentarios: solo de publicaciones con menos de 7 días, del más nuevo al más viejo, deteniéndose en el último ya guardado y con un tope por publicación (10 a 30). Son el 77 % del costo: un creador activo en cinco redes cuesta unos USD 1,20 al mes sin comentarios y USD 5,20 con 30 por publicación. El tope debe ser un ajuste visible para el cliente.
• Cambios de significado: YouTube cuenta vistas de Shorts en cada repetición desde marzo de 2025 y desde el primer cuadro desde agosto de 2026. Instagram suma vistas de Facebook en publicaciones cruzadas desde abril de 2026. El modelo guarda una versión de la semántica de cada métrica para no mezclar series.

Detalles de Basin que conviene conocer desde el inicio:

• Basin SQL es de solo lectura. Admite joins, CTE y funciones de ventana, pero no INSERT ni DDL. Por eso deduplicar y agregar lo hace un Workflow nocturno que consulta Basin SQL y escribe en D1, usando QUALIFY ROW_NUMBER() para quedarse con el último snapshot.
• Basin Pipelines no migra esquemas. Además descarta en silencio los eventos inválidos de los streams estructurados. Hay que guardar siempre el JSON crudo y la columna schema_version, y vigilar sus métricas de calidad.
• Mantenimiento automático. Activar desde el día uno la compactación (archivos de 128 a 256 MB) y la expiración de snapshots. Un DELETE en Iceberg solo borra físicamente cuando expira el snapshot, lo que importa para atender solicitudes de habeas data.
• D1 tiene un límite de 10 GB por base. Solo guarda agregados y metadatos de la aplicación, nunca comentarios.

• Acceso: la app se sirve como archivos estáticos de Workers (solicitudes gratis) detrás de Cloudflare Access, gratis hasta 50 usuarios, con código de un solo uso por correo o con el proveedor de identidad del cliente.
• Explorador sin SQL libre: el Worker solo ejecuta plantillas parametrizadas, porque Basin SQL no admite OFFSET (la paginación se hace por clave), devuelve 500 filas por defecto, cobra un mínimo de 10 MB por consulta y rechaza consultas que escanean demasiado. El token nunca llega al navegador.
• Usuarios técnicos: pueden conectar DuckDB 1.4 o posterior, PyIceberg o Snowflake al catálogo con un token de solo lectura. Leer el catálogo con DuckDB-WASM desde el navegador no está verificado con R2 y expondría credenciales.

La ley que decide es la colombiana, y es más estricta de lo que suele pensarse. La jurisprudencia de EE. UU. sobre scraping ayuda a entender el riesgo frente a las plataformas, pero no autoriza a tratar datos personales en Colombia.

Comprar traslada las roturas al proveedor, pero no elimina el riesgo. Ninguna opción es de mantenimiento cero: la recomendada necesita unas 10 horas al mes, que caben en un retén pequeño. Sin ese retén el sistema sigue funcionando, pero las alertas se quedarían sin atender.

Cómo se hizo. 21 agentes investigaron en paralelo un frente cada uno: plataforma Apify, actores de Instagram y Facebook, actores de TikTok, X y YouTube, APIs por request, proveedores enterprise, APIs oficiales de YouTube y TikTok, APIs oficiales de Meta y X, scraping desde Cloudflare, proxies móviles, evidencia de roturas, autorreparación con LLM, marco legal, geolocalización, sentimiento en español, lakehouse en Cloudflare, resolución de creadores, SaaS de social listening, APIs de influencers, experiencias de usuarios y dos equipos rojos (a favor de construir y en contra de depender de proveedores). Otros 10 agentes verificaron de forma adversarial los precios que alimentan el simulador contra las páginas oficiales. Confirmaron casi todo y corrigieron sobre todo la asignación de precios por plan de algunos actores de Apify (el precio «desde» suele ser el del plan Business). También dejaron como no verificables los precios heredados de los planes Basic y Pro de X.

Límites. No se hicieron corridas de prueba de los actores. Las horas de mantenimiento y las roturas por año son estimaciones construidas desde la evidencia pública, no mediciones. Varias páginas (Reddit, G2, algunas de la SIC) bloquearon el acceso, y parte de los agentes agotó su presupuesto de búsqueda y trabajó con lectura directa de páginas oficiales. El análisis legal no reemplaza a un abogado colombiano.

Archivos del proyecto. docs/PROMPT_MEJORADO.md, simulador/simulador_costos.py, simulador/parametros.json (todos los precios con su URL), simulador/generar_datos_sinteticos.py y informe/, desde donde se genera esta página.