Cómo unir publicaciones, comentarios y perfiles de LinkedIn sin coincidencias incorrectas

Elige primero la granularidad de la fila

La granularidad de la fila indica qué representa una fila. Elige la granularidad antes de recoger filas.

La granularidad de la evidencia es una observación de comentario seleccionada. Una observación de comentario es un comentario de nivel superior guardado de una instantánea. La granularidad del conteo es una publicación seleccionada. Un conteo de comentarios y un conteo de publicaciones son medidas distintas. Escribe ambos significados en el archivo antes de sumarlos.

Escribe las URL de origen conocidas. Escribe el período del informe. El corte del informe es el último momento de observación que incluyes. Una fila posterior al corte permanece en el dataset original. No entra en este informe.

Usa este método solo para URL públicas de publicaciones conocidas, sus comentarios públicos de nivel superior y perfiles de persona comprobados. No lo uses para la búsqueda de cuentas, todas las publicaciones de una cuenta, listas de reacciones, respuestas, envío de mensajes, etiquetas de empleo ni puntajes de texto.

Términos

Una URN es un identificador de texto tipado. En `urn:li:activity:1001`, el tipo de URN es `activity`. El tipo forma parte de la clave. `ugcPost` es un tipo de publicación distinto. `member` es un tipo de cuenta de persona en estos Actors. `organization` no es un tipo de cuenta de persona.

La guía de URN de LinkedIn explica los tipos de URN de la API oficial de LinkedIn. Esa API usa una URN `person`. La clave de perfil del Actor usa `member`. Esos dos esquemas no son el mismo. No copies un identificador de una API de LinkedIn a la otra y lo trates como igual.

JSON es un formato de datos de texto. Vas a usar JSON, o columnas de texto, para que los identificadores largos no pierdan dígitos.

Un campo booleano vale true o false. Predeterminado significa el valor que se usa cuando dejas el campo sin cambios. El esquema de entrada es la lista publicada de campos que acepta un Actor. Una clave padre es la clave de la publicación guardada en una fila de comentario. Respaldo significa que pruebas la clave siguiente solo cuando falta la clave anterior. Canónica significa la única URL de origen que confirmaste, no una segunda forma de esa URL.

Las claves compatibles tienen el mismo tipo de URN y el mismo valor. Un conflicto significa que una clave apunta a dos destinos, o que dos claves apuntan a dos destinos distintos. Los tipos de URN distintos, por sí solos, no son un conflicto cuando las claves del mismo tipo nombran una sola publicación.

Qué devuelven los tres Actors

Tres Actors públicos aportan las filas de origen. La unión la construyes tú.

El LinkedIn Post Scraper es la compilación 1.0.60. El LinkedIn Comments Scraper es la compilación 1.0.47. El LinkedIn Profile Scraper es la compilación 1.0.28. Lee la página de cada Actor antes de una ejecución. Una compilación posterior puede cambiar un campo.

Cada Actor lee páginas públicas. Ninguno usa tu inicio de sesión de LinkedIn. Ninguno devuelve todas las publicaciones de una cuenta.

La entrada de comentarios también tiene `maxComments`, `includeAuthorDetails` y `collectAllAvailable`. `maxComments` es un número entero de 1 a 1000. Su valor predeterminado es 100. `maxComments` es el máximo de comentarios guardados por publicación o entrada. No es un tope para toda una ejecución con varias entradas. `includeAuthorDetails` es un booleano. Su valor predeterminado es false. `collectAllAvailable` es un booleano. Su valor predeterminado es false. `collectAllAvailable` quita solo el tope numérico de guardado. No quita una restricción pública. No recoge respuestas.

Los conteos de comentarios y el estado de la entrada están en `OUTPUT`. `OUTPUT` es el resumen de la ejecución. No es una fila de comentario. Dentro de él, `inputResults` lleva `status`, `statusReason`, `pageCommentCount`, `publicRowsOnPage`, `savedRows`, `isPublicPageComplete`, `isComplete` y `stopReason`.

`pageCommentCount` es el conteo informado para la página. `publicRowsOnPage` es la cantidad de filas públicas vistas en esa página. `savedRows` es la cantidad almacenada. Esos tres números pueden diferir. `isPublicPageComplete` indica si el Actor marcó la página pública como completa. `isComplete` indica si la colección guardada está completa. `stopReason` indica por qué se detuvo el guardado. Un resultado parcial puede venir del tope de guardado, de una vista previa pública o de un límite de facturación. Un conteo desconocido permanece null. No escribas cero en su lugar.

El Actor de comentarios puede aceptar una URL tipada de actualización del feed. El Actor de publicaciones exige una URL `/posts/`. Si solo conoces la URL del feed, conserva las claves padre del comentario. Obtén una URL `/posts/` coincidente y verificada antes de recoger la instantánea de la publicación. No inventes un slug de `/posts/`.

Usa estas Tasks y después cambia la entrada de ejemplo. Una muestra sin cambios no se puede unir. La muestra de la Task de publicaciones es una publicación distinta de la muestra de la Task de comentarios.

No juntes las dos Tasks de comentarios como si fueran dos conjuntos de comentarios. Elige una Task de comentarios para esa publicación. La Task de detalles todavía puede devolver un comentario sin ID de autor. Una solicitud de detalles útil puede causar un evento de facturación aparte. La solicitud no garantiza un ID. No garantiza un cargo.

Los detalles del autor están desactivados de forma predeterminada. En esa salida predeterminada, las claves estables del autor del comentario suelen ser null. Los identificadores públicos y las URL públicas pueden cambiar después. Una instantánea de perfil muestra el perfil en su propio momento. No demuestra un empleo en el momento anterior del comentario. Este método no asigna roles de empleo.

La documentación de la ejecución describe los topes y el tiempo de espera de la ejecución. Léela antes de una ejecución grande. No pongas tokens de acceso en la hoja.

Cómo hacer coincidir un comentario con una publicación

Haz la coincidencia en el orden indicado. Conserva las reglas del mismo tipo. La clave de coincidencia nombra una publicación. Primero revisa todas las claves compatibles disponibles para detectar conflictos. No omitas una clave inferior que contradice. Solo después de esa revisión, elige la primera base de coincidencia admitida en el orden indicado. Registra esa base. La columna de la base la crea quien lee. Los Actors no la devuelven.

1. Igualdad de `postUrn` tipado.
2. Igualdad de `activityId`, solo dentro del tipo activity.
3. Igualdad de `ugcPostId`, solo dentro del tipo ugcPost.
4. Una URL de origen canónica comprobada.

Los campos del comentario son `postUrn`, `activityId`, `ugcPostId` y `postUrl`. Los campos de la publicación son `postUrn`, `activityId`, `ugcPostId` y `url`. Cualquiera de ellos puede ser null.

Usa una URN tipada antes que un ID aislado. Un valor de activity y un valor de ugcPost pueden existir juntos en una publicación y, aun así, ser distintos. Eso es normal. No compares un valor de activity con un valor de ugcPost. Los dígitos iguales entre tipos distintos no son evidencia.

La publicación A del ejemplo ficticio tiene activity `1001` y ugcPost `2001`. Esas son dos claves de una publicación, no un conflicto. Hay un conflicto cuando una clave apunta a dos publicaciones, o cuando las claves disponibles apuntan a dos publicaciones distintas. El orden de respaldo no permite que una clave más débil anule ese conflicto. Deja el comentario sin resolver.

Usa la URL solo cuando faltan las claves tipadas. Las dos URL deben ser la misma URL de origen canónica que comprobaste. Si no puedes comprobarlo, deja la fila sin resolver. Una base de URL es más débil que una clave tipada. Escribe la base y los dos momentos de observación.

Reduce las instantáneas de publicación duplicadas a una fila de referencia seleccionada antes de esta unión. Si la tabla de referencia todavía tiene dos filas exitosas para una publicación, la unión va a copiar comentarios. Corrige la tabla de referencia. No borres las filas de comentario copiadas y dejes la tabla de referencia sin cambios.

Una instantánea de publicación ausente es una coincidencia ausente. No es una publicación vacía. Una publicación exitosa sin comentarios guardados es un resultado distinto. Un intento de publicación fallido es un resultado distinto. Una entrada que no ejecutaste es un resultado distinto.

Cómo hacer coincidir un perfil de persona

Haz coincidir un perfil con el autor de un comentario solo después de comprobar que ese autor representa una cuenta de persona. El campo del comentario es `authorType`. Puede ser `person`, `organization` o null. El Actor de publicaciones puede escribir el tipo de autor de la publicación como `Person`. Conserva cada valor de origen exactamente como llegó. Para esta comprobación de significado, `person` y `Person` significan una cuenta de persona. No exijas las mismas mayúsculas. No edites el texto almacenado para que las letras coincidan.

Un autor de organización queda fuera de la unión con el perfil de persona. Una URL de organización no puede convertirse en una fila de perfil `/in/`. `urn:li:member:11` y `urn:li:organization:11` son claves distintas. No quites el tipo de URN para forzar una coincidencia.

Después de la comprobación de persona, haz la coincidencia en este orden:

1. ID de member igual: `profileId` del perfil con `authorId` del comentario.
2. URN de member igual: `profileUrn` del perfil con `authorUrn` del comentario.
3. Un respaldo más débil: `publicIdentifier` con `authorPublicIdentifier`, o la URL canónica `/in/` de `url` del perfil y `authorUrl` del comentario.

No hagas coincidir null. No hagas coincidir una celda en blanco. Si el ID de member apunta al perfil X y la URL apunta al perfil Y, la fila es un conflicto. No uses la URL más débil para elegir un ganador.

Una URL o un identificador público puede cambiar entre instantáneas. Si usas esa base más débil, escribe los dos valores de `observedAt` y la base. Una URL null queda sin resolver. Los nombres, las fotos y los titulares no son claves. No busques por nombre para completar un enlace ausente.

Los mismos campos de perfil se pueden comparar con los campos del autor de la publicación `authorId`, `authorUrn`, `authorPublicIdentifier`, `authorUrl` y `authorType`. Esa comparación revisa solo el rol de autor de la publicación. Es opcional. No es el autor del comentario. Nunca reemplaces al autor de un comentario por el autor de la publicación. Nunca unas todas las publicaciones de una cuenta con todos los comentarios de esa cuenta.

one post snapshot
    -> many comment observations

one person profile
    -> many comments by that person

optional post-author match
    -> the post row only
    -> not the comment author

Una persona puede escribir muchos comentarios. Una publicación puede tener muchos comentarios. Esas dos flechas son independientes.

La identidad del comentario usa `commentId`, `commentUrl`, la clave padre y `observedAt`. Un ID o un enlace puede ser null. Conserva esa observación. No inventes un ID estable. No trates un texto igual como el mismo comentario. No trates el número de fila de la hoja como un ID. Entre ejecuciones, selecciona una sola observación solo cuando la clave padre y `commentId` son estables e iguales. Las filas sin un `commentId` estable siguen siendo observaciones separadas.

El estado del perfil y de la publicación usa `status`, `statusReason` y `observedAt`. Conserva una fila de perfil fallida en el archivo de origen. No la trates como una coincidencia exitosa de perfil.

Selecciona una instantánea antes de la unión

Una fila de búsqueda es la única instantánea que permites usar en la unión. Selecciona como máximo una fila de publicación exitosa por cada publicación comprobada. Selecciona como máximo una fila de perfil exitosa por cada persona comprobada. Hazlo antes de la unión.

Conserva los datasets originales. No mezcles dos instantáneas en una fila nueva. Escribe la regla de selección en el archivo. Una regla clara es la última instantánea exitosa anterior al corte del informe.

Si una persona tiene dos instantáneas de perfil exitosas, elige una. Si las dos permanecen en la tabla de referencia, cada comentario de esa persona se copia una vez por cada instantánea. Las filas unidas de más son un error de la tabla de referencia. Corrige la tabla de referencia. No borres las copias y declares que la hoja es correcta.

Después construye un left join desde las observaciones de comentario seleccionadas. Primero une cada comentario con una publicación de origen. Después une a su autor persona con, como máximo, un perfil. Un comentario sin coincidencia de publicación permanece. Un comentario sin coincidencia de perfil permanece.

La tabla de evidencia unida debe tener la misma cantidad de filas que las observaciones de comentario seleccionadas. Más filas significan que una clave de búsqueda todavía apunta a más de una fila.

Estos campos creados por quien lee pertenecen a la fila de evidencia: base de la coincidencia, resultado de la coincidencia, regla de la instantánea seleccionada y los momentos de origen que comparaste. Márcalos como creados por quien lee. No los presentes como campos del Actor.

Conserva los ID largos como texto. Una hoja de cálculo puede cambiar un número largo y perder dígitos. Exporta JSON, o establece cada columna de ID como texto antes de importar. JSON está definido arriba. La documentación del dataset indica la ruta de exportación: selecciona el dataset, elige Export, elige el formato y elige Download. Guarda `OUTPUT` por separado. Una exportación de dataset no contiene `OUTPUT`.

Pasos

1. Escribe la granularidad, las URL conocidas, el corte del informe y el significado de cada conteo. El archivo de evidencia tendrá una fila por cada observación de comentario seleccionada. El archivo de conteo tendrá una fila por cada publicación seleccionada. Un total de comentarios y un conteo de publicaciones mostrado permanecen separados hasta que termines esa escritura.
2. Abre IDs de publicaciones y comentarios de LinkedIn para uniones de datos seguras. Reemplaza la URL de ejemplo con una URL pública de publicación conocida. Establece `maxComments` en 3. Mantén `collectAllAvailable` en false. Deja desactivados los detalles del autor. Inicia la ejecución. Abre `OUTPUT` antes de explicar un conjunto pequeño o un conjunto vacío. Pocas filas pueden significar el tope de guardado, una entrada fallida, una restricción pública o un conjunto público de comentarios corto. El conteo de filas por sí solo no dice cuál es.
3. Si necesitas claves de autor que las filas predeterminadas de comentarios no contienen, usa Autores de comentarios de LinkedIn con detalles públicos del perfil en lugar de la primera Task de comentarios. Reemplaza la publicación de ejemplo. Usa tres comentarios. Mantén desactivada la opción sin límite. Establece `includeAuthorDetails` en true. No pegues las dos salidas juntas. Los detalles todavía pueden faltar. La solicitud adicional de detalles se puede facturar por separado y, aun así, puede no devolver un ID.
4. Abre IDs de publicaciones de LinkedIn y claves de autor para uniones de datos. Reemplaza su muestra con la misma URL `/posts/`. No pases un ID de publicación. No pases una URL de actualización del feed. Si solo tienes una URL de actualización del feed, conserva las claves padre del comentario y detén la recolección de la publicación hasta tener una URL `/posts/` verificada. No inventes el slug. Mantén separadas las filas `ok`, `failed` e `invalid_url`. Conserva `observedAt`. Una instantánea de publicación ausente sigue siendo una coincidencia ausente.
5. Lee las claves de autor del comentario. Si las filas de comentarios ya tienen cada dato de autor que este informe necesita, omite el Actor de perfiles. Si no los tienen, recoge las URL públicas `/in/` distintas con IDs y URN de perfiles de LinkedIn para uniones de datos. Quita las URL repetidas. Excluye las URL de organización. No busques por nombre, foto ni titular. Conserva los intentos de perfil fallidos en el archivo de origen. Un intento fallido no es una persona con coincidencia.
6. Selecciona la tabla de referencia. Conserva una instantánea de publicación exitosa por cada publicación comprobada. Conserva una instantánea de perfil exitosa por cada persona comprobada. Para ejecuciones de comentarios repetidas, conserva una observación por cada clave padre estable más `commentId`. Conserva las filas sin `commentId` como observaciones separadas, aunque el texto sea igual. Conserva cada dataset original. Escribe la regla de corte. Resuelve las claves duplicadas y los conflictos en la tabla de referencia antes de unir.
7. Haz un left join de cada comentario seleccionado con una publicación. Usa un `postUrn` tipado igual, después un ID de activity igual, después un ID de ugcPost igual y después una URL canónica comprobada. No cruces tipos de URN. Después une al autor persona con, como máximo, un perfil. Usa el ID de member, después la URN de member y después un identificador público con fecha o una URL canónica `/in/`. Escribe la base creada por quien lee, el resultado y los dos momentos de origen. No completes al autor de un comentario con el autor de la publicación. No unas todas las publicaciones de una cuenta con todos los comentarios de esa cuenta.
8. Cuenta las filas de evidencia. El número debe ser igual a las observaciones de comentario seleccionadas. Si es mayor, la tabla de referencia todavía tiene muchas filas para una clave. Corrige esa tabla de referencia y vuelve a unir. No borres las filas de evidencia repetidas como única reparación. Por separado, cuenta los padres sin coincidencia, las claves de persona ausentes, los perfiles fallidos, los autores de organización y los conflictos.
9. Agrupa las observaciones de comentario por la clave de publicación resuelta. Pon `commentsCount` solo en una fila de publicación seleccionada. Pon la cobertura de `OUTPUT` de esa ejecución junto a la publicación. Conserva una publicación que no tiene comentarios guardados. Conserva como hechos distintos una recolección vacía exitosa, un intento fallido y una entrada que no ejecutaste. Cuenta las claves de autor como cuentas observadas. No las llames personas distintas con cada persona contada una sola vez. No las llames el conjunto completo de quienes comentan ni de quienes ven.
10. Exporta la tabla de evidencia, la tabla sin resolver, la tabla de conteo por publicación y un resumen de origen. Usa la ruta de exportación del dataset indicada arriba. Guarda `OUTPUT` junto a ella. Conserva los ID como texto. En cada fila de resultado, muestra las claves de origen, la base creada por quien lee y la evidencia ausente. Completa un hueco solo cuando tienes una URL de origen admitida para ese hueco exacto. Si no, déjalo como desconocido.

El conteo de evidencia es el paso 8. El conteo de publicaciones es el paso 9. No uses el conteo de publicaciones como conteo de comentarios.

Qué demostró una comprobación pública

Una comprobación pública guardó tres comentarios de una publicación conocida. La fuente mostró cuatro comentarios y expuso cuatro filas. El tope guardó tres. Cada una de las tres claves padre guardadas coincidió con esa misma publicación de origen. Un autor de comentario coincidió con una fila distinta de perfil de persona. Todas esas coincidencias comprobadas tuvieron éxito.

El `OUTPUT` de comentarios de esa ejecución tenía `isPublicPageComplete` true, `isComplete` false y `stopReason` `max_comments_reached`. Leídos juntos, el Actor marcó la página pública como completa, y el guardado seguía incompleto porque se alcanzó el tope de guardado.

Esa comprobación demuestra solo esas filas y ese resumen. No demuestra cada publicación posterior. No es una prueba en vivo y nueva de la coincidencia de ugcPost, de autores de organización, de claves null ni de conflictos. Esos casos usan las reglas de campos de arriba y los conteos ficticios de abajo.

Publicaciones, comentarios y conteos ficticios

Cada valor de esta sección es ficticio. C1 a C6 son etiquetas de enseñanza. Los ID cortos son ID de enseñanza. No son valores recogidos de LinkedIn. No trates ninguna URN de abajo como un perfil, una publicación o un comentario real.

El corte del informe es posterior a `time-2`. La instantánea seleccionada de member12 es la exitosa posterior. El tipo de autor de la publicación se almacena como `Person` en A y B. El tipo de autor del comentario se almacena como `person` en C1 a C4. Esos significados coinciden. Las letras almacenadas siguen siendo distintas. La publicación C se almacena como un autor de organización.

Member11 tiene una fila de perfil exitosa seleccionada. Member12 tiene dos instantáneas exitosas. Selecciona una antes de la unión. Member13 tiene un intento de perfil fallido. A y B fueron escritas por member11. C fue escrita por organization11, no por member11.

C2 no coincide por una URN de activity tipada, porque esa URN padre es una URN de ugcPost. El ID de activity `1001` coincide con la publicación A. El ID de ugcPost `2001` también coincide con la publicación A. Las dos claves del mismo tipo concuerdan, así que esto es una confirmación, no un conflicto. La base que escribes es el ID de activity.

C5 coincide con la publicación C porque los dos lados usan ugcPost `1001`. La publicación A también contiene los dígitos `1001`, pero esos dígitos son un ID de activity. Los dígitos iguales no mueven C5 a A.

La tabla de evidencia conserva seis filas. La tabla de coincidencias y la tabla sin resolver son vistas. Pueden repetir un comentario cuando un lado coincide y el otro no. No sumes esas vistas y llames a la suma un total de comentarios.

La vista de coincidencias tiene 8 líneas. C1, C2 y C3 tienen cada uno dos lados exitosos. C4 y C5 tienen solo el lado de la publicación. Ocho no es el total de comentarios. Seis es el total de comentarios.

C6 tiene dos partes sin resolver y una fila de evidencia. Cuéntalo una sola vez como comentario.

Comprueba cada total:

• Observaciones de comentario seleccionadas: 6.
• Filas de evidencia después del left join: 6.
• Coincidencias con la publicación padre: 5, que son C1, C2, C3, C4 y C5.
• Padre sin coincidencia: 1, que es C6.
• Filas de comentario coincidentes con un perfil de persona exitoso: 3, que son C1, C2 y C3.
• Perfiles de persona exitosos usados: 2, que son member11 y member12.
• Resultados de persona sin resolver: 2, que son el perfil fallido en C4 y la clave de autor ausente en C6.
• Autor de organización fuera del alcance del perfil de persona: 1, que es C5.
• Claves de member identificadas: 3, que son member11, member12 y member13.
• Esas 3 claves de member no son 2 perfiles, y no establecen 3 personas verificadas.
• Filas recogidas por padre: A tiene 2, B tiene 2, C tiene 1 y el padre sin coincidencia tiene 1.
• 2 más 2 más 1 más 1 es igual a 6.

`commentsCount` permanece en la fila de la publicación. Si lo copias en cada comentario recogido y después sumas las copias, A aporta 10 dos veces y B aporta 20 dos veces. Eso es 20 más 40, que es 60. La suma mostrada conocida y correcta usa cada publicación seleccionada una sola vez: 10 más 20 es igual a 30. La publicación C es null. No cambies null por 0. No llames a 30 completo. La medida de observaciones recogidas es distinta: 5 padres con coincidencia más 1 padre sin coincidencia es igual a 6.

Esta hoja ficticia no tiene `OUTPUT`. La cobertura real todavía necesita `pageCommentCount`, `publicRowsOnPage`, `savedRows`, `isPublicPageComplete`, `isComplete`, `stopReason`, `status` y `statusReason` de esa ejecución. Un conteo mostrado de 10 con 2 filas recogidas no es, por sí solo, una tasa de cobertura.

Si las dos instantáneas de member12 permanecen en la tabla de referencia, C2 se copia y C3 se copia. La tabla de evidencia crece de 6 filas a 8 filas. Selecciona primero la instantánea `time-2`. La tabla de evidencia vuelve a 6 filas. Borrar las dos filas de evidencia de más, mientras las dos instantáneas permanecen en la tabla de referencia, no repara la unión siguiente.

Member11 escribió dos publicaciones seleccionadas, A y B, y un comentario seleccionado, C1. Si unes directamente esas dos publicaciones de su autoría con el comentario que escribió member11, C1 aparece dos veces. Cuenta cada rama antes de hablar de las dos. La rama del autor de la publicación tiene 2 publicaciones. La rama del autor del comentario tiene 1 comentario. La coincidencia del padre deja C1 solo en la publicación A. C1 coincide con member11 porque la clave de autor del comentario es member11, no porque member11 haya escrito la publicación A.

Member12 muestra la dirección permitida. Un perfil seleccionado coincide con dos comentarios. C2 permanece en A. C3 permanece en B. El perfil compartido no mueve ningún comentario a la otra publicación.

Una instantánea de publicación exitosa, por sí sola, no demuestra una colección de comentarios vacía. Solo una entrada de comentarios exitosa y comprobada con cero filas guardadas es un resultado vacío observado. Un tope todavía limita ese resultado. Una restricción de la fuente todavía limita ese resultado. Una entrada fallida permanece desconocida. Una entrada no intentada permanece desconocida. Un resultado vacío observado no es un `commentsCount` mostrado null. Los totales del ejemplo de seis filas no cambian. C6 es una clave padre sin coincidencia. No es un intento de publicación fallido.

Tres reglas ficticias más quedan fuera de las seis filas. No las sumes a los totales de arriba.

Una persona con claves de member null puede coincidir con un perfil comprobado cuando la URL `/in/` actual es exactamente la misma. Escribe la base de URL más débil y los dos momentos de observación. Una URL null queda sin resolver. Si el ID de member apunta a X y la URL apunta a Y, conserva un conflicto y no uses la URL. Un comentario con `commentId` null sigue siendo su propia observación. Un texto igual no repara el ID ausente. Un número de fila de la hoja no lo repara.

El archivo terminado muestra qué coincidió, por qué coincidió y qué sigue desconocido. No ordena a las personas. No juzga el éxito de una publicación.