Comment étudier les rôles publics des auteurs de commentaires LinkedIn

Gardez les commentaires et les comptes séparés

Une ligne enregistrée est un commentaire de premier niveau disponible. Ce n'est pas une personne. Ce n'est pas une réaction. Ce n'est pas un profil complet. Ce n'est pas un fil complet.

Voici les champs de la ligne :

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

`authorUrn` et `postUrn` sont des valeurs URN. Un URN est un identifiant textuel typé, issu de la source publique. Un `authorId` est aussi un identifiant de la source publique. Ces identifiants sont publics. Ce ne sont pas des clés secrètes.

`authorType` a trois valeurs vérifiées : `person`, `organization` ou `null`. `null` signifie que le type n'a pas été donné. Ne lisez pas `null` comme person.

`observedAt` est le moment où vous avez observé la ligne. Ce n'est pas le moment où la publication a été publiée. Écrivez les deux moments dans vos notes si vous avez les deux. Ne les échangez pas.

`authorCurrentOrganizations` peut contenir plus d'une entrée publique. Gardez chaque entrée. N'inventez pas un seul employeur. Si le champ est null ou vide, la preuve d'organisation est inconnue. Inconnu n'est pas zéro. Inconnu ne signifie pas sans emploi. Inconnu ne signifie pas aucune entreprise.

Les détails d'auteur peuvent manquer. Une requête peut renvoyer une ligne avec un titre vide ou des organisations vides. Laissez ces cellules inconnues. Ne les remplissez pas à partir du texte du commentaire.

Utilisez une seule table de commentaires. Vous n'avez pas besoin d'un second jeu de données pour coder les rôles.

Configurez une collecte limitée

1. Choisissez des publications publiques connues. Écrivez la question d'étude avant de collecter. Indiquez le moment de la collecte. Indiquez un plafond pour chaque publication. Marquez les commentaires de promotion, les commentaires de l'auteur de la publication et les comptes d'organisation lorsque ces lignes changeraient l'étude. Un commentaire de promotion promeut surtout un produit ou un service. Gardez les lignes marquées. Ne les supprimez pas. Si vous laissez un compte d'auteur de publication hors de la part, dites-le et changez le total.
2. Collectez un petit échantillon avec les détails d'auteur activés. La tâche enregistrée, vérifiée le 13 octobre 2026, est LinkedIn Comment Authors with Public Profile Details. Son entrée enregistrée est :

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

Remplacez cette publication d'exemple par la publication publique que vous voulez étudier. Pour la première exécution, réglez `maxComments` sur 3. Gardez `collectAllAvailable` à false. La valeur false garde actif le nombre maximal de commentaires. Gardez `includeAuthorDetails` à true.

Les détails d'auteur font l'objet d'une requête séparée de la ligne de commentaire. Si cette récupération supplémentaire réussit, elle peut causer un événement de facturation distinct. Un événement de facturation est un enregistrement de frais. Toutes les requêtes ne causent pas de frais. Les champs de détail peuvent quand même revenir vides. Cet article n'indique aucun prix.

1. Enregistrez les lignes de commentaires et la sortie OUTPUT de l'exécution. Lisez OUTPUT pour chaque publication avant de coder un rôle.

La sortie OUTPUT au niveau de l'exécution inclut `savedRows`, `authorProfileRequests`, `authorDetailEvents` et `rowsWithAuthorDetails`. Lisez-les pour voir combien de lignes et de requêtes de détail ont été enregistrées. `rowsWithAuthorDetails` peut être inférieur au nombre de commentaires lorsque des détails manquent. N'utilisez pas ces nombres comme le total des rôles. Ne les lisez pas comme une facture.

Chaque publication a une entrée `inputResults`. Lisez ces champs à cet endroit :

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

Utilisez le `stopReason` à l'intérieur de l'`inputResults` de cette publication. Un `stopReason` à la racine de OUTPUT n'est pas l'état du plafond pour la publication.

`isPublicPageComplete` à true signifie que la page publique exposée a été extraite. Cela ne signifie pas que toute la discussion a été enregistrée. `isComplete` à false signifie que la collecte enregistrée est incomplète. Un plafond, une restriction d'aperçu public, une restriction de la source ou une limite de frais peut causer ce résultat. Lisez le statut, la raison et le stopReason pour chaque entrée. Un statut d'exécution réussi ne rend pas la table complète. `pageCommentCount` et `publicRowsOnPage` sont des effectifs de commentaires ou de lignes au niveau de la page. Ces effectifs de page ne sont pas des effectifs de comptes-personnes observés.

Le 13 octobre 2026, une vérification à portée limitée a enregistré 3 commentaires provenant de 1 publication. Elle a fait 3 requêtes de détail d'auteur. Le plafond a arrêté l'exécution alors que l'effectif de commentaires ou de lignes sur la page exposée était 4. Pour cette publication, `isPublicPageComplete` était true, `isComplete` était false, et `stopReason` était `max_comments_reached`. Les 3 lignes enregistrées n'étaient pas toute la discussion. Elles montrent seulement que des détails publics d'auteur peuvent être renvoyés. Ce n'est pas un rapport de rôles. Ne les utilisez pas comme l'exemple résolu.

Construisez les deux tables

Gardez une table de commentaires. Donnez à chaque ligne son propre `commentId`.

Si `commentId` manque, gardez cette ligne comme sa propre observation de source. Donnez-lui une étiquette que vous créez, par exemple `missing-comment-1`. Ne fusionnez jamais deux identifiants de commentaire vides. Ne fusionnez jamais deux lignes parce que le texte du commentaire correspond. Un texte identique n'est pas le même commentaire.

Construisez une table de comptes-personnes seulement après avoir confirmé le type.

1. Lisez `authorType`.
2. Ne regroupez un identifiant que lorsque `authorType` est `person`.
3. Préférez `authorUrn` ou `authorId` comme clé sûre.
4. Si ces identifiants sont absents, une URL de profil public vérifiée peut servir d'étiquette provisoire. Dites que l'étiquette d'URL est plus faible qu'un identifiant stable. Une étiquette d'URL n'est pas non résolue.
5. Non résolu signifie qu'il n'y a pas de clé sûre. Pas d'`authorUrn`, pas d'`authorId`, et pas d'URL de profil vérifiée. N'appelez pas une ligne non résolue seulement parce que l'identifiant stable manque lorsqu'une URL vérifiée existe.
6. Ne fusionnez jamais des lignes par `authorName`.
7. Ne fusionnez jamais des identifiants vides entre eux.

Les comptes `organization` restent dans un groupe séparé. Gardez leurs identifiants à part des identifiants person. Ils n'entrent pas dans le total des comptes-personnes. Indiquez leur nombre à côté de ce total.

Si `authorType` est `null`, ne traitez pas la ligne comme un compte-personne. Si cette ligne n'a pas non plus de clé de personne sûre, elle reste non résolue. Ne l'attribuez pas à un nom voisin.

Un rôle inconnu et une identité non résolue sont différents. Un rôle inconnu signifie que vous avez trouvé le compte-personne, mais que le titre n'indique pas de rôle. Ce compte reste dans le total des comptes-personnes. L'identité non résolue reste dehors.

Codez le titre que vous pouvez voir

Écrivez un guide de codage avant de compter. Un guide de codage est une courte liste de catégories et du texte du titre qui appuie chacune d'elles.

Utilisez cette règle.

• `operations` : le titre indique un travail d'opérations.
• `technical` : le titre indique un travail logiciel ou d'ingénierie.
• `marketing` : le titre indique un travail de marketing.
• `mixed` : le titre indique plus d'une de ces fonctions, et la règle ne peut pas en choisir une.
• `unknown` : le titre manque, ou il n'indique aucune fonction. Un slogan est unknown.

Enregistrez le texte exact du titre à côté de la catégorie. Utilisez toute la fonction indiquée. N'inférez pas un emploi à partir d'un slogan. N'inférez pas un rôle à partir de l'humeur du commentaire. Le texte du commentaire n'est pas une preuve de rôle.

Utilisez une seule catégorie principale pour chaque identité de compte-personne. Chaque identité entre alors une seule fois dans les parts. Vous pouvez garder des étiquettes supplémentaires dans un second champ. N'ajoutez pas ces étiquettes comme des comptes supplémentaires.

Gardez les deux instantanés datés du titre lorsque le même compte a des textes en conflit. Gardez le texte exact de la preuve pour chaque instantané. Ne choisissez pas le titre qui rend le graphique plus net. Pour le rapport, déclarez une règle qui choisit l'observation dont le titre fournit la preuve. Si vous ne pouvez pas utiliser cette règle, le rôle principal reste `unknown`. Utilisez `conflict pending review` seulement pour un état séparé de relecture par le lecteur. Ne codez pas des rôles de moments différents comme `mixed`. Codez `mixed` seulement lorsque le titre sélectionné indique plusieurs rôles et que le guide de codage ne peut pas choisir un seul rôle. Codez `unknown` lorsque le titre sélectionné ne montre pas une fonction claire.

Une catégorie de rôle est votre étiquette pour une fonction indiquée. Ce n'est pas une qualification vérifiée.

Comptez une fois, puis divisez

Comptez les commentaires répétés dans une table d'activité. Comptez chaque identité de compte-personne observée une fois dans la table des rôles.

Un dénominateur est le total par lequel vous divisez. Un numérateur est le nombre que vous divisez. Une part est le numérateur divisé par le dénominateur indiqué.

Pour le rapport de rôles, le dénominateur est le nombre d'identités de compte-personne observées. Les lignes d'organisation sont hors de ce dénominateur. Les lignes non résolues sont hors de ce dénominateur. Les comptes à rôle inconnu restent dans ce dénominateur.

La couverture des rôles connus utilise un second rapport, pas un nouveau public. Son numérateur compte les identités de compte-personne dont le rôle principal n'est pas `unknown`. Son dénominateur compte toutes les identités de compte-personne observées. `mixed` n'est pas `unknown`.

Vous pouvez aussi montrer des parts seulement à l'intérieur du groupe des rôles connus. Cette vue a un dénominateur plus petit. Écrivez ce dénominateur sur la table. Gardez le nombre d'inconnus à côté. Ne comparez pas ces parts avec les parts du dénominateur plus grand. Les comptes n'ont pas changé. Le total a changé.

Demandez à un second lecteur de coder quelques titres avec le même guide de codage. Relisez les lignes que vous codez différemment. Cela vérifie la cohérence. Cela ne prouve pas que l'emploi est réel.

Exemple résolu fictif

Les publications, les étiquettes, les noms, les titres et les nombres de cette section sont fictifs. Ils ne sont pas la vérification du 13 octobre 2026. Ce ne sont pas de vraies personnes.

Une publication inventée donne 8 lignes de commentaires. Les valeurs fictives de `commentId` vont de `c1` à `c8`. Aucune de ces 8 lignes n'a un `commentId` vide. Les identifiants de personne des lignes person sont vérifiés. `c8` n'a pas de clé sûre.

Table des comptes-personnes :

`org1` a `authorType` `organization` et 1 commentaire. Il reste hors de la table des comptes-personnes. `c8` a `authorType` `null` et aucune clé sûre. C'est 1 commentaire non résolu. N'attribuez jamais `c8` à `p4`.

Les 8 commentaires contiennent 4 identités de compte-personne observées, 1 auteur organisation et 1 ligne d'auteur non résolue. Ne dites pas qu'il y avait exactement 6 personnes. La ligne non résolue peut répéter un compte-personne. `org1` est une organisation.

Les parts de rôles utilisent 4 identités de compte-personne observées comme dénominateur.

La part operations est 1 divisé par 4. Cela fait 25 %. Le même calcul donne 25 % pour technical, marketing et unknown. Ces quatre parts utilisent un seul dénominateur, donc elles font 100 %.

La couverture des rôles connus utilise 3 comme numérateur et 4 comme dénominateur. 3 divisé par 4 fait 75 %. Le compte inconnu reste visible comme 1 des 4.

Une seconde vue n'utilise que les 3 comptes à rôle connu. Chaque groupe connu est 1 divisé par 3, soit environ 33,3 %. Gardez le nombre d'inconnus à côté de cette vue. Ce compte inconnu est 1, et il est hors de ce dénominateur.

Ne comparez pas 33,3 % avec 25 %. Ces chiffres utilisent des dénominateurs différents. Ils ne sont pas un changement du public.

L'activité des commentaires est un total différent. Sa somme est 8.

`p1` et `p2` ont chacun écrit 2 commentaires. Un rapport de rôles qui utilise les 8 lignes de commentaires compterait ces deux comptes deux fois. Utilisez la table d'activité pour le volume. Utilisez les 4 identités de compte-personne pour la composition.

Note de couverture fictive : le plafond est 8. L'effectif observé de commentaires ou de lignes sur la page source est 12. Dans `inputResults`, `stopReason` est `max_comments_reached` et `isComplete` est false. Cette note fictive n'attribue ni `status` ni `statusReason`.

Décision : gardez la table de rôles à 4 comptes comme échantillon observé. Collectez davantage seulement si l'étude a besoin de plus de couverture. N'appelez jamais cet échantillon l'ensemble des 12 participants. Ne lisez pas 12 comme 12 identités de compte-personne.

Constat fictif : dans cet échantillon plafonné, chaque rôle principal représente 25 % des 4 identités de compte-personne observées. La couverture des rôles connus est 75 %. Le constat porte seulement sur cet échantillon. Il ne décrit pas tous les clients. Il ne montre pas qui peut acheter.

Ce que vous transmettez

Transmettez ces éléments.

• La table des comptes-personnes, avec un rôle principal pour chaque compte-personne.
• Le guide de codage et le texte exact du titre utilisé comme preuve.
• Le nombre d'organisations, hors du dénominateur des comptes-personnes.
• Le nombre d'identités non résolues, avec les étiquettes créées par le lecteur pour tout `commentId` manquant.
• Une note de couverture pour chaque publication, tirée de `inputResults`.
• Un constat à portée limitée qui nomme le dénominateur et le plafond.

Indiquez le moment de la collecte. Ne le remplacez pas par le moment de publication de la publication. Si un titre ou une liste d'organisations était vide, montrez inconnu. Ne transformez pas inconnu en zéro.

Si `isComplete` est false, dites que la table n'est pas toute la discussion. Si deux instantanés de titre ne concordent pas, montrez les deux. Ne cachez pas celui que vous n'avez pas codé.