Cómo estudiar los roles públicos de autores de comentarios en LinkedIn

Separe comentarios y cuentas

Una fila guardada es un comentario de primer nivel disponible. No es una persona. No es una reacción. No es un perfil completo. No es un hilo completo.

Estos son los campos de la fila:

• `commentId`
• `commentUrl`
• `postUrl`
• `postUrn`
• `authorType`
• `authorUrl`
• `authorId`
• `authorUrn`
• `authorPublicIdentifier`
• `authorName`
• `authorHeadline`
• `authorLocation`
• `authorCurrentOrganizations`
• `text`
• `observedAt`

`authorUrn` y `postUrn` son valores URN. Un URN es un identificador de texto con tipo, tomado de la fuente pública. Un `authorId` también es un identificador de la fuente pública. Estos identificadores son públicos. No son claves secretas.

`authorType` tiene tres valores comprobados: `person`, `organization` o `null`. `null` significa que el tipo no fue dado. No lea `null` como person.

`observedAt` es el momento en que usted observó la fila. No es el momento en que se publicó la publicación. Escriba ambos momentos en sus notas si tiene los dos. No los intercambie.

`authorCurrentOrganizations` puede contener más de una entrada pública. Conserve cada entrada. No invente un empleador. Si el campo es null o está vacío, la evidencia de organización es desconocida. Desconocido no es cero. Desconocido no significa desempleado. Desconocido no significa que no hay empresa.

Los datos del autor pueden faltar. Una solicitud puede devolver una fila con el titular vacío o con las organizaciones vacías. Deje esas celdas como desconocidas. No las complete con el texto del comentario.

Use solo una tabla de comentarios. No necesita un segundo conjunto de datos para codificar roles.

Defina una ejecución pequeña

1. Elija publicaciones públicas conocidas. Escriba la pregunta del estudio antes de recolectar. Indique el momento de la recolección. Indique un tope para cada publicación. Marque los comentarios de promoción, los comentarios del autor de la publicación y las cuentas de organización cuando esas filas cambiarían el estudio. Un comentario de promoción promueve sobre todo un producto o un servicio. Conserve las filas marcadas. No las borre. Si deja una cuenta del autor de la publicación fuera de la proporción, dígalo y cambie el total.
2. Recolecte una muestra pequeña con los datos de autor activados. La tarea guardada, comprobada el 13 de octubre de 2026, es LinkedIn Comment Authors with Public Profile Details. Su entrada guardada es:

{"startUrls": ["https://www.linkedin.com/posts/timferriss_how-to-become-dramatically-more-productive-activity-7386884213343428608-wrF3"], "maxComments": 100, "collectAllAvailable": false, "includeAuthorDetails": true}

Reemplace esa publicación de muestra por la publicación pública que quiere estudiar. Para la primera ejecución, ponga `maxComments` en 3. Deje `collectAllAvailable` en false. False mantiene activo el tope numérico. Deje `includeAuthorDetails` en true.

Los datos de autor son una solicitud distinta de la fila del comentario. Un detalle extra obtenido con éxito puede causar un evento de facturación aparte. Un evento de facturación es un registro de un cargo. No toda solicitud causa un cargo. Los campos de detalle igual pueden volver vacíos. Este artículo no indica un precio.

1. Guarde las filas de comentarios y el OUTPUT de la ejecución. Lea el OUTPUT de cada publicación antes de codificar un rol.

El OUTPUT a nivel de ejecución incluye `savedRows`, `authorProfileRequests`, `authorDetailEvents` y `rowsWithAuthorDetails`. Léalos para ver cuántas filas y cuántas solicitudes de detalle quedaron registradas. `rowsWithAuthorDetails` puede ser menor que la cantidad de comentarios cuando faltan detalles. No use estos conteos como el total de roles. No los lea como una factura.

Cada publicación tiene una entrada de `inputResults`. Lea allí estos campos:

• `status`
• `statusReason`
• `pageCommentCount`
• `publicRowsOnPage`
• `savedRows`
• `isPublicPageComplete`
• `isComplete`
• `stopReason`

Use el `stopReason` dentro de los `inputResults` de esa publicación. Un `stopReason` en la raíz del OUTPUT no es el estado del tope de la publicación.

`isPublicPageComplete` en true significa que se extrajo la página pública expuesta. No significa que se guardó toda la conversación. `isComplete` en false significa que la recolección guardada está incompleta. Un tope, una restricción de vista previa pública, una restricción de la fuente o un límite de cargo pueden causar este resultado. Lea el estado, el motivo y el stopReason de cada entrada. Un estado de ejecución correcto no hace que la tabla esté completa. `pageCommentCount` y `publicRowsOnPage` son conteos de página. Esos conteos de página no son conteos de cuentas de persona observadas.

El 13 de octubre de 2026, una comprobación acotada guardó 3 comentarios de 1 publicación. Hizo 3 solicitudes de detalle de autor. El tope detuvo la ejecución cuando el conteo de la página expuesta era 4. Para esa publicación, `isPublicPageComplete` era true, `isComplete` era false y `stopReason` era `max_comments_reached`. Las 3 filas guardadas no eran toda la conversación. Solo muestran que los datos públicos de autor pueden devolverse. No son un informe de roles. No las use como el ejemplo resuelto.

Arme las dos tablas

Mantenga una tabla de comentarios. Dé a cada fila su propio `commentId`.

Si falta `commentId`, conserve esa fila como su propia observación de fuente. Dele una etiqueta que usted cree, como `missing-comment-1`. Nunca fusione dos identificadores de comentario en blanco. Nunca fusione dos filas porque el texto del comentario coincide. Un texto igual no es el mismo comentario.

Arme una tabla de cuentas-persona solo después de confirmar el tipo.

1. Lea `authorType`.
2. Agrupe un identificador solo cuando `authorType` es `person`.
3. Prefiera `authorUrn` o `authorId` como clave segura.
4. Si esos identificadores no están, una URL de perfil público comprobada puede ser una etiqueta provisoria. Diga que la etiqueta de URL es más débil que un identificador estable. Una etiqueta de URL no es una fila sin resolver.
5. Sin resolver significa que no hay clave segura. No hay `authorUrn`, no hay `authorId` y no hay URL de perfil comprobada. No llame sin resolver a una fila solo porque falta el identificador estable cuando existe una URL comprobada.
6. Nunca fusione filas por `authorName`.
7. Nunca fusione identificadores en blanco entre sí.

Las cuentas `organization` quedan en un grupo aparte. Mantenga sus identificadores separados de los identificadores de person. No entran en el total de cuentas-persona. Indique su conteo al lado.

Si `authorType` es `null`, no trate la fila como una cuenta de persona. Si esa fila tampoco tiene una clave segura de persona, queda sin resolver. No la asigne a un nombre cercano.

El rol desconocido y la identidad sin resolver son distintos. Rol desconocido significa que usted encontró la cuenta de persona, pero el titular no declara un rol. Esa cuenta permanece en el total de cuentas-persona. La identidad sin resolver queda afuera.

Codifique el titular que puede ver

Escriba un libro de códigos antes de contar. Un libro de códigos es una lista corta de categorías y de la evidencia del titular que cada una necesita.

Use esta regla.

• `operations`: el titular declara trabajo de operaciones.
• `technical`: el titular declara trabajo de software o de ingeniería.
• `marketing`: el titular declara trabajo de marketing.
• `mixed`: el titular declara más de una de esas funciones, y la regla no puede elegir una.
• `unknown`: falta el titular, o no declara ninguna función. Un eslogan es unknown.

Guarde el texto exacto del titular junto a la categoría. Use toda la función declarada. No infiera un puesto a partir de un eslogan. No infiera un rol a partir del tono del comentario. El texto del comentario no es evidencia de rol.

Use una categoría principal para cada identidad de cuenta-persona. Así las proporciones suman una sola vez. Puede guardar etiquetas extra en un segundo campo. No sume esas etiquetas como más cuentas.

Conserve las dos capturas del titular con fecha cuando la misma cuenta tiene textos en conflicto. Conserve el texto exacto de evidencia de cada captura. No elija el título que deja el gráfico más prolijo. Use una regla declarada de observación seleccionada para el informe. Si no puede usar esa regla, el rol principal sigue siendo `unknown`. Use `conflict pending review` solo para un estado aparte de revisión del lector. No codifique roles de momentos distintos como `mixed`. Codifique `mixed` solo cuando el titular seleccionado declara varios roles y el libro de códigos no puede elegir un rol. Codifique `unknown` cuando el titular seleccionado no muestra una función clara.

Una categoría de rol es su etiqueta para una función declarada. No es una credencial comprobada.

Cuente una vez y después divida

Cuente los comentarios repetidos en una tabla de actividad. Cuente cada identidad de cuenta-persona observada una sola vez en la tabla de roles.

Un denominador es el total por el que usted divide. Un numerador es el conteo que usted divide. Una proporción es el numerador dividido por el denominador indicado.

Para el informe de roles, el denominador es la cantidad de identidades de cuenta-persona observadas. Las filas de organización quedan afuera. Las filas sin resolver quedan afuera. Las cuentas con rol desconocido permanecen adentro.

La cobertura de roles conocidos usa un segundo informe, no un público nuevo. Su numerador son las identidades de cuenta-persona cuyo rol principal no es `unknown`. Su denominador son todas las identidades de cuenta-persona observadas. `mixed` no es `unknown`.

También puede mostrar proporciones solo dentro del grupo de roles conocidos. Esa vista tiene un denominador más pequeño. Escriba ese denominador en la tabla. Conserve el conteo de desconocidos al lado. No compare esas proporciones con las proporciones del denominador más grande. Las cuentas no cambiaron. Cambió el total.

Pida a un segundo lector que codifique algunos titulares con el mismo libro de códigos. Revise las filas que codifican distinto. Esto comprueba la consistencia. No prueba que el puesto sea real.

Ejemplo resuelto ficticio

Las publicaciones, las etiquetas, los nombres, los titulares y los conteos de esta sección son ficticios. No son la comprobación del 13 de octubre de 2026. No son personas reales.

Una publicación inventada produce 8 filas de comentarios. Los valores ficticios de `commentId` van de `c1` a `c8`. Ninguna de estas 8 filas tiene un `commentId` en blanco. Los identificadores de persona de las filas person están comprobados. `c8` no tiene clave segura.

Tabla de cuentas-persona:

`org1` tiene `authorType` `organization` y 1 comentario. Queda fuera de la tabla de cuentas-persona. `c8` tiene `authorType` `null` y no tiene clave segura. Es 1 comentario sin resolver. Nunca asigne `c8` a `p4`.

Los 8 comentarios contienen 4 identidades de cuenta-persona observadas, 1 autor de organización y 1 fila de autor sin resolver. No diga que había exactamente 6 personas. La fila sin resolver puede repetir una cuenta de persona. `org1` es una organización.

Las proporciones de roles usan 4 identidades de cuenta-persona observadas como denominador.

La proporción de operations es 1 dividido por 4. Eso es 25%. La misma cuenta da 25% para technical, marketing y unknown. Estas cuatro proporciones usan un denominador, así que suman 100%.

La cobertura de roles conocidos usa 3 como numerador y 4 como denominador. 3 dividido por 4 es 75%. La cuenta unknown sigue visible como 1 de las 4.

Una segunda vista usa solo las 3 cuentas de rol conocido. Cada grupo conocido es 1 dividido por 3, es decir cerca del 33.3%. Conserve el conteo de unknown junto a esta vista. Esa cuenta unknown es 1, y está fuera de este denominador.

No compare 33.3% con 25%. Esas cifras usan denominadores distintos. No son un cambio en el público.

La actividad de comentarios es un total distinto. Suma 8.

`p1` y `p2` escribieron 2 comentarios cada uno. Un informe de roles que usa las 8 filas de comentarios contaría esas dos cuentas dos veces. Use la tabla de actividad para el volumen. Use las 4 identidades de cuenta-persona para la composición.

Nota ficticia de cobertura: el tope es 8. El conteo observado de la página de origen es 12. En `inputResults`, `stopReason` es `max_comments_reached` e `isComplete` es false. Esta nota ficticia no asigna `status` ni `statusReason`.

Decisión: conserve la tabla de roles de 4 cuentas como una muestra observada. Recolecte más solo si el estudio necesita más cobertura. Nunca llame a esta muestra los 12 participantes. No lea 12 como 12 identidades de cuenta-persona.

Hallazgo ficticio: en esta muestra con tope, cada rol principal es el 25% de 4 identidades de cuenta-persona observadas. La cobertura de roles conocidos es 75%. El hallazgo es solo sobre esa muestra. No describe a todos los clientes. No muestra quién puede comprar.

Qué entrega

Entregue estos elementos.

• La tabla de cuentas-persona, con un rol principal cada una.
• El libro de códigos y el texto exacto del titular usado como evidencia.
• El conteo de organizaciones, fuera del denominador de cuentas-persona.
• El conteo de identidades sin resolver, con etiquetas hechas por el lector para cualquier `commentId` faltante.
• Una nota de cobertura de cada publicación, tomada de `inputResults`.
• Un hallazgo acotado que nombre el denominador y el tope.

Indique el momento de la recolección. No lo reemplace por la hora de publicación de la publicación. Si un titular o una lista de organizaciones estaba vacío, muestre desconocido. No convierta desconocido en cero.

Si `isComplete` es false, diga que la tabla no es toda la conversación. Si dos capturas del titular no coinciden, muestre las dos. No oculte la que no codificó.