Comment joindre des profils, des publications et des commentaires LinkedIn sans mauvais appariements

Choisissez d'abord le grain de ligne

Le grain de ligne indique ce qu'une ligne représente. Choisissez le grain avant de collecter les lignes.

Le grain de preuve est une observation de commentaire sélectionnée. Une observation de commentaire est un commentaire de premier niveau enregistré, issu d'un instantané. Le grain de compte est une publication sélectionnée. Un compte de commentaires et un compte de publications sont des mesures différentes. Écrivez les deux sens dans le fichier avant de les additionner.

Écrivez les URL source connues. Écrivez la période du rapport. La limite du rapport est le dernier moment d'observation que vous incluez. Une ligne postérieure à la limite reste dans le jeu de données d'origine. Elle n'entre pas dans ce rapport.

Utilisez cette méthode seulement pour des URL publiques connues de publications, leurs commentaires publics de premier niveau et des profils de personne contrôlés. Ne l'utilisez pas pour une recherche de comptes, toutes les publications d'un compte, des listes de réactions, des réponses, l'envoi de messages, des libellés de poste ou des scores de texte.

Termes

Un URN est un identifiant textuel typé. Dans `urn:li:activity:1001`, le type d'URN est `activity`. Le type fait partie de la clé. `ugcPost` est un autre type de publication. `member` est un type de compte personne dans ces Actors. `organization` n'est pas un type de compte personne.

Le guide des URN LinkedIn explique les types d'URN pour l'API LinkedIn officielle. Cette API utilise un URN `person`. La clé de profil de l'Actor utilise `member`. Ces deux schémas ne sont pas les mêmes. Ne copiez pas un identifiant d'une API LinkedIn dans l'autre en le déclarant égal.

JSON est un format de données textuel. Vous utiliserez JSON, ou des colonnes texte, pour que les longs identifiants ne perdent pas de chiffres.

Un champ booléen vaut true ou false. La valeur par défaut est la valeur utilisée lorsque vous laissez le champ inchangé. Le schéma d'entrée est la liste publiée des champs qu'un Actor accepte. Une clé parente est la clé de publication stockée sur une ligne de commentaire. Le repli signifie que vous essayez la clé suivante seulement lorsque la clé précédente est absente. Canonique signifie l'unique URL source que vous avez confirmée, pas une seconde forme de cette URL.

Des clés compatibles ont le même type d'URN et la même valeur. Un conflit signifie qu'une clé désigne deux cibles, ou que deux clés désignent deux cibles différentes. Des types d'URN différents ne forment pas à eux seuls un conflit lorsque les clés de même type nomment une seule publication.

Ce que les trois Actors renvoient

Trois Actors publics fournissent les lignes source. Vous construisez quand même la jointure.

Le LinkedIn Post Scraper est le build 1.0.60. Le LinkedIn Comments Scraper est le build 1.0.47. Le LinkedIn Profile Scraper est le build 1.0.28. Lisez la page de chaque Actor avant une exécution. Un build ultérieur peut modifier un champ.

Chaque Actor lit des pages publiques. Aucun n'utilise votre connexion LinkedIn. Aucun ne renvoie toutes les publications d'un compte.

L'entrée des commentaires a aussi `maxComments`, `includeAuthorDetails` et `collectAllAvailable`. `maxComments` est un nombre entier de 1 à 1000. Sa valeur par défaut est 100. `maxComments` est le nombre maximal de commentaires enregistrés par publication ou par entrée. Ce n'est pas un plafond pour l'ensemble d'une exécution à plusieurs entrées. `includeAuthorDetails` est un booléen. Sa valeur par défaut est false. `collectAllAvailable` est un booléen. Sa valeur par défaut est false. `collectAllAvailable` retire seulement le plafond numérique d'enregistrement. Il ne retire pas une restriction publique. Il ne collecte pas les réponses.

Les comptes de commentaires et le statut d'entrée sont dans `OUTPUT`. `OUTPUT` est le résumé de l'exécution. Ce n'est pas une ligne de commentaire. À l'intérieur, `inputResults` porte `status`, `statusReason`, `pageCommentCount`, `publicRowsOnPage`, `savedRows`, `isPublicPageComplete`, `isComplete` et `stopReason`.

`pageCommentCount` est le compte indiqué pour la page. `publicRowsOnPage` est le nombre de lignes publiques vues sur cette page. `savedRows` est le nombre stocké. Ces trois nombres peuvent différer. `isPublicPageComplete` indique si l'Actor a marqué la page publique comme complète. `isComplete` indique si la collection enregistrée est complète. `stopReason` indique pourquoi l'enregistrement s'est arrêté. Un résultat partiel peut venir du plafond d'enregistrement, d'un aperçu public ou d'une limite de facturation. Un compte inconnu reste null. N'écrivez pas zéro à sa place.

L'Actor des commentaires peut accepter une URL typée de mise à jour du fil. L'Actor des publications exige une URL `/posts/`. Si vous ne connaissez que l'URL du fil, conservez les clés parentes des commentaires. Obtenez une URL `/posts/` correspondante et vérifiée avant de collecter l'instantané de la publication. N'inventez pas un slug `/posts/`.

Utilisez ces Tasks, puis modifiez l'entrée d'exemple. Un exemple inchangé ne peut pas être joint. L'exemple de la Task de publication est une publication différente de l'exemple de la Task de commentaires.

N'ajoutez pas les deux Tasks de commentaires comme deux ensembles de commentaires. Choisissez une seule Task de commentaires pour cette publication. La Task de détails peut encore renvoyer un commentaire sans ID d'auteur. Une demande de détails utile peut provoquer un événement de facturation distinct. La demande ne garantit pas un ID. Elle ne garantit pas des frais.

Les détails d'auteur sont désactivés par défaut. Dans cette sortie par défaut, les clés stables d'auteur de commentaire sont souvent null. Les identifiants publics et les URL publiques peuvent changer plus tard. Un instantané de profil montre le profil à son propre moment. Il ne prouve pas un emploi au moment antérieur du commentaire. Cette méthode n'attribue pas de rôles professionnels.

La documentation d'exécution décrit les plafonds d'exécution et le délai d'expiration. Lisez-la avant une grande exécution. Ne placez pas de jetons d'accès dans la feuille.

Comment apparier un commentaire à une publication

Appariez dans l'ordre indiqué. Conservez les règles de même type. La clé d'appariement nomme une publication. Vérifiez d'abord toutes les clés compatibles disponibles pour détecter les conflits. Ne sautez pas une clé inférieure contradictoire. Seulement après cette vérification, choisissez la première base d'appariement prise en charge, dans l'ordre indiqué. Enregistrez cette base. La colonne de base est créée par le lecteur. Les Actors ne la renvoient pas.

1. Un `postUrn` typé égal.
2. Un `activityId` égal, seulement à l'intérieur du type activity.
3. Un `ugcPostId` égal, seulement à l'intérieur du type ugcPost.
4. Une URL source canonique contrôlée.

Les champs du commentaire sont `postUrn`, `activityId`, `ugcPostId` et `postUrl`. Les champs de la publication sont `postUrn`, `activityId`, `ugcPostId` et `url`. Chacun d'eux peut être null.

Utilisez un URN typé avant un ID nu. Une valeur activity et une valeur ugcPost peuvent toutes les deux exister sur une publication et rester différentes. C'est normal. Ne comparez pas une valeur activity avec une valeur ugcPost. Des chiffres égaux entre des types ne sont pas une preuve.

Dans l'exemple fictif, la publication A a l'activity `1001` et l'ugcPost `2001`. Ce sont deux clés pour une publication, pas un conflit. Un conflit existe lorsqu'une clé désigne deux publications, ou lorsque les clés disponibles désignent deux publications différentes. L'ordre de repli ne permet pas à une clé plus faible d'annuler ce conflit. Laissez le commentaire non résolu.

Utilisez l'URL seulement lorsque les clés typées sont absentes. Les deux URL doivent être la même URL source canonique que vous avez contrôlée. Si vous ne pouvez pas le contrôler, laissez la ligne non résolue. Une base d'URL est plus faible qu'une clé typée. Écrivez la base et les deux moments d'observation.

Réduisez les instantanés de publication en double à une seule ligne de référence sélectionnée avant cette jointure. Si la table de référence a encore deux lignes réussies pour une publication, la jointure copiera les commentaires. Corrigez la table de référence. Ne supprimez pas les lignes de commentaire copiées en laissant la table de référence inchangée.

Un instantané de publication absent est un appariement absent. Ce n'est pas une publication vide. Une collecte de publication réussie, sans commentaire enregistré, est un résultat différent. Une tentative de collecte en échec sur une publication existante est un résultat différent. Une entrée que vous n'avez pas exécutée est un résultat différent.

Comment apparier un profil de personne

Appariez un profil à un auteur de commentaire seulement après avoir établi que l'auteur est un compte personne. Le champ du commentaire est `authorType`. Il peut valoir `person`, `organization` ou null. L'Actor de publication peut écrire le type d'auteur de la publication comme `Person`. Conservez chaque valeur source exactement comme elle est arrivée. Pour ce contrôle de sens, `person` et `Person` signifient tous les deux un compte personne. N'exigez pas les mêmes majuscules. Ne modifiez pas le texte stocké pour faire coïncider les lettres.

Un auteur organisation reste hors de la jointure des profils de personne. Une URL d'organisation ne peut pas devenir une ligne de profil `/in/`. `urn:li:member:11` et `urn:li:organization:11` sont des clés différentes. Ne retirez pas le type d'URN pour forcer un appariement.

Après le contrôle de personne, appariez dans cet ordre :

1. ID member égal : `profileId` du profil avec `authorId` du commentaire.
2. URN member égal : `profileUrn` du profil avec `authorUrn` du commentaire.
3. Un repli plus faible : `publicIdentifier` avec `authorPublicIdentifier`, ou l'URL canonique `/in/` issue de `url` du profil et de `authorUrl` du commentaire.

N'appariez pas null. N'appariez pas une cellule vide. Si l'ID member désigne le profil X et que l'URL désigne le profil Y, la ligne est un conflit. N'utilisez pas l'URL plus faible pour choisir un gagnant.

Une URL ou un identifiant public peut changer entre des instantanés. Si vous utilisez cette base plus faible, écrivez les deux valeurs `observedAt` et la base. Une URL null reste non résolue. Les noms, les photos et les intitulés de profil ne sont pas des clés. Ne recherchez pas par nom pour remplir un lien absent.

Les mêmes champs de profil peuvent être comparés aux champs d'auteur de la publication `authorId`, `authorUrn`, `authorPublicIdentifier`, `authorUrl` et `authorType`. Cette comparaison contrôle seulement le rôle d'auteur de la publication. Elle est facultative. Ce n'est pas l'auteur du commentaire. Ne remplacez jamais un auteur de commentaire par l'auteur de la publication. Ne joignez jamais toutes les publications d'un compte à tous les commentaires de ce compte.

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

Une personne peut écrire de nombreux commentaires. Une publication peut avoir de nombreux commentaires. Ces deux flèches sont séparées.

L'identité du commentaire utilise `commentId`, `commentUrl`, la clé parente et `observedAt`. Un ID ou un lien peut être null. Conservez cette observation. N'inventez pas un ID stable. Ne traitez pas un texte égal comme le même commentaire. Ne traitez pas un numéro de ligne de feuille comme un ID. D'une exécution à l'autre, sélectionnez une seule observation seulement lorsque la clé parente et `commentId` sont tous les deux stables et égaux. Les lignes sans `commentId` stable restent des observations séparées.

Le statut du profil et de la publication utilise `status`, `statusReason` et `observedAt`. Conservez une ligne de profil en échec dans le fichier source. Ne la traitez pas comme un appariement de profil réussi.

Sélectionnez un instantané avant la jointure

Une ligne de référence est l'unique instantané que vous autorisez la jointure à utiliser. Sélectionnez au plus une ligne de publication réussie pour chaque publication contrôlée. Sélectionnez au plus une ligne de profil réussie pour chaque personne contrôlée. Faites-le avant la jointure.

Conservez les jeux de données d'origine. Ne mélangez pas deux instantanés dans une nouvelle ligne. Écrivez la règle de sélection dans le fichier. Une règle claire est le dernier instantané réussi avant la limite du rapport.

Si une personne a deux instantanés de profil réussis, choisissez-en un. Si les deux restent dans la table de référence, chaque commentaire de cette personne est copié une fois pour chaque instantané. Les lignes jointes en trop sont une erreur de la table de référence. Corrigez la table de référence. Ne supprimez pas les copies en déclarant la feuille correcte.

Construisez ensuite une jointure gauche à partir des observations de commentaire sélectionnées. Joignez d'abord chaque commentaire à une publication source. Joignez ensuite son auteur personne à au plus un profil. Un commentaire sans appariement de publication reste. Un commentaire sans appariement de profil reste.

Le tableau de preuves joint doit avoir le même nombre de lignes que les observations de commentaire sélectionnées. Plus de lignes signifient qu'une clé de recherche désigne encore plus d'une ligne.

Ces champs créés par le lecteur appartiennent à la ligne de preuve : base d'appariement, résultat d'appariement, règle d'instantané sélectionné et moments source que vous avez comparés. Étiquetez-les comme créés par le lecteur. Ne les présentez pas comme des champs d'Actor.

Conservez les longs ID comme texte. Un tableur peut modifier un long nombre et supprimer des chiffres. Exportez en JSON, ou réglez chaque colonne d'ID en texte avant l'import. JSON est défini plus haut. La documentation des jeux de données donne le chemin d'export : sélectionnez le jeu de données, choisissez Export, choisissez le format, puis choisissez Download. Enregistrez `OUTPUT` à part. Un export de jeu de données ne contient pas `OUTPUT`.

Étapes

1. Écrivez le grain, les URL connues, la limite du rapport et le sens de chaque décompte. Le fichier de preuves aura une ligne par observation de commentaire sélectionnée. Le fichier de décomptes aura une ligne par publication sélectionnée. Un total de commentaires et un décompte affiché sur la publication restent séparés jusqu'à la fin de cette écriture.
2. Ouvrez Identifiants de publication et de commentaire LinkedIn pour des jointures de données sûres. Remplacez l'URL d'exemple par une URL publique connue d'une publication. Mettez `maxComments` à 3. Laissez `collectAllAvailable` à false. Laissez les détails d'auteur désactivés. Lancez l'exécution. Ouvrez `OUTPUT` avant d'expliquer un petit ensemble ou un ensemble vide. Peu de lignes peuvent signifier le plafond d'enregistrement, une entrée en échec, une restriction publique ou un court ensemble public de commentaires. Le seul nombre de lignes ne dit pas lequel.
3. Si vous avez besoin de clés d'auteur que les lignes de commentaires par défaut ne contiennent pas, utilisez Auteurs de commentaires LinkedIn avec des détails de profil public à la place de la première Task de commentaires. Remplacez la publication d'exemple. Utilisez trois commentaires. Laissez l'option illimitée désactivée. Mettez `includeAuthorDetails` à true. Ne collez pas les deux sorties ensemble. Des détails peuvent encore manquer. La demande de détails supplémentaire peut être facturée à part, et elle peut encore ne pas renvoyer d'ID.
4. Ouvrez Identifiants de publication LinkedIn et clés d'auteur pour les jointures de données. Remplacez son exemple par la même URL `/posts/`. Ne transmettez pas un ID de publication. Ne transmettez pas une URL de mise à jour du fil. Si vous n'avez qu'une URL de mise à jour du fil, conservez les clés parentes des commentaires et arrêtez la collecte de la publication jusqu'à avoir une URL `/posts/` vérifiée. N'inventez pas le slug. Gardez séparées les lignes `ok`, `failed` et `invalid_url`. Conservez `observedAt`. Un instantané de publication absent reste un appariement absent.
5. Lisez les clés d'auteur des commentaires. Si les lignes de commentaires ont déjà chaque fait d'auteur dont ce rapport a besoin, sautez l'Actor de profil. Sinon, collectez les URL publiques `/in/` distinctes avec Identifiants et URN de profil LinkedIn pour les jointures de données. Retirez les URL répétées. Excluez les URL d'organisation. Ne recherchez pas par nom, photo ou intitulé de profil. Conservez les tentatives de profil en échec dans le fichier source. Une tentative en échec n'est pas une personne appariée.
6. Sélectionnez la table de référence. Conservez un instantané de publication réussi par publication contrôlée. Conservez un instantané de profil réussi par personne contrôlée. Pour des exécutions de commentaires répétées, conservez une observation par clé parente stable plus `commentId`. Conservez les lignes sans `commentId` comme des observations séparées, même lorsque le texte est égal. Conservez chaque jeu de données d'origine. Écrivez la règle de limite. Résolvez les clés en double et les conflits dans la table de référence avant de joindre.
7. Faites une jointure gauche de chaque commentaire sélectionné vers une publication. Utilisez un `postUrn` typé égal, puis un ID activity égal, puis un ID ugcPost égal, puis une URL canonique contrôlée. Ne croisez pas les types d'URN. Joignez ensuite l'auteur personne à au plus un profil. Utilisez l'ID member, puis l'URN member, puis un identifiant public daté ou une URL canonique `/in/`. Écrivez la base créée par le lecteur, le résultat et les deux moments source. Ne remplissez pas un auteur de commentaire à partir de l'auteur de la publication. Ne joignez pas toutes les publications d'un compte à tous les commentaires de ce compte.
8. Comptez les lignes de preuve. Le nombre doit être égal aux observations de commentaire sélectionnées. S'il est plus grand, la table de référence a encore plusieurs lignes pour une clé. Corrigez cette table de référence et joignez de nouveau. Ne supprimez pas les lignes de preuve répétées comme seule réparation. Comptez à part les parents non appariés, les clés de personne absentes, les profils en échec, les auteurs organisation et les conflits.
9. Regroupez les observations de commentaire par la clé de publication résolue. Placez `commentsCount` sur une seule ligne de publication sélectionnée. Placez la couverture `OUTPUT` de cette exécution à côté de la publication. Conservez une publication qui n'a aucun commentaire enregistré. Conservez comme des faits différents une collecte vide réussie, une tentative en échec et une entrée que vous n'avez pas exécutée. Comptez les clés d'auteur comme des comptes observés. Ne les appelez pas des personnes distinctes comptées une fois. Ne les appelez pas l'ensemble complet des auteurs de commentaires ni des personnes qui ont vu le contenu.
10. Exportez le tableau de preuves, le tableau des non résolus, le tableau des comptes par publication et un résumé des sources. Utilisez le chemin d'export de jeu de données indiqué plus haut. Enregistrez `OUTPUT` à côté. Conservez les ID comme texte. Sur chaque ligne de résultat, montrez les clés source, la base créée par le lecteur et la preuve absente. Remplissez un manque seulement lorsque vous avez une URL source prise en charge pour ce manque exact. Sinon, laissez-le inconnu.

Le compte de preuves est l'étape 8. Le compte inscrit sur la ligne de publication est l'étape 9. N'utilisez pas ce compte de la ligne de publication comme un compte de commentaires.

Ce qu'un contrôle public a prouvé

Un contrôle public a enregistré trois commentaires d'une publication connue. La source montrait quatre commentaires et exposait quatre lignes. Le plafond en a enregistré trois. Chacune des trois clés parentes enregistrées correspondait à cette même publication source. Un auteur de commentaire correspondait à une ligne distincte de profil de personne. Tous ces appariements contrôlés ont réussi.

L'`OUTPUT` des commentaires pour cette exécution avait `isPublicPageComplete` à true, `isComplete` à false et `stopReason` à `max_comments_reached`. Interprétées ensemble, ces trois valeurs indiquent que l'Actor a marqué la page publique comme complète, et que l'enregistrement restait incomplet parce que le plafond d'enregistrement était atteint.

Ce contrôle prouve seulement ces lignes et ce résumé. Il ne prouve pas chaque publication ultérieure. Ce n'est pas un test en direct récent de l'appariement ugcPost, des auteurs organisation, des clés null ou des conflits. Ces cas utilisent les règles de champs ci-dessus et les décomptes fictifs ci-dessous.

Publications, commentaires et décomptes fictifs

Chaque valeur de cette section est fictive. C1 à C6 sont des étiquettes d'enseignement. Les ID courts sont des ID d'enseignement. Ce ne sont pas des valeurs LinkedIn collectées. Ne traitez aucun URN ci-dessous comme un profil, une publication ou un commentaire réel.

La limite du rapport est après `time-2`. L'instantané member12 sélectionné est le plus tardif parmi ceux qui ont réussi. Le type d'auteur de publication est stocké comme `Person` sur A et B. Le type d'auteur de commentaire est stocké comme `person` sur C1 à C4. Ces sens correspondent. Les lettres stockées restent différentes. La publication C est stockée comme un auteur organisation.

Member11 a une ligne de profil réussie et sélectionnée. Member12 a deux instantanés réussis. Sélectionnez-en un avant la jointure. Member13 a une tentative de profil en échec. A et B ont été écrits par member11. C a été écrit par organization11, pas par member11.

C2 ne s'apparie pas sur un URN activity typé, parce que cet URN parent est un URN ugcPost. L'ID activity `1001` correspond à la publication A. L'ID ugcPost `2001` correspond aussi à la publication A. Les deux clés de même type sont d'accord, donc il s'agit d'une confirmation, pas d'un conflit. La base que vous écrivez est l'ID activity.

C5 correspond à la publication C parce que les deux côtés utilisent l'ugcPost `1001`. La publication A contient aussi les chiffres `1001`, mais ces chiffres sont un ID activity. Des chiffres égaux ne déplacent pas C5 vers A.

Le tableau de preuves conserve six lignes. Le tableau des appariements et le tableau des non résolus sont des vues. Ils peuvent répéter un commentaire lorsqu'un côté correspond et que l'autre ne correspond pas. N'additionnez pas ces vues pour appeler la somme un total de commentaires.

La vue des appariements a 8 lignes. C1, C2 et C3 ont chacun deux côtés réussis. C4 et C5 n'ont que le côté publication. Huit n'est pas le total de commentaires. Six est le total de commentaires.

C6 a deux parties non résolues et une ligne de preuve. Comptez-le une seule fois comme un commentaire.

Contrôlez chaque total :

• Observations de commentaire sélectionnées : 6.
• Lignes de preuve après la jointure gauche : 6.
• Appariements au parent publication : 5, qui sont C1, C2, C3, C4 et C5.
• Parent non apparié : 1, qui est C6.
• Lignes de commentaire appariées à un profil de personne réussi : 3, qui sont C1, C2 et C3.
• Profils de personne réussis utilisés : 2, qui sont member11 et member12.
• Résultats de personne non résolus : 2, qui sont le profil en échec sur C4 et la clé d'auteur absente sur C6.
• Auteur organisation hors du périmètre des profils de personne : 1, qui est C5.
• Clés member identifiées : 3, qui sont member11, member12 et member13.
• Ces 3 clés member ne sont pas 2 profils, et elles ne prouvent pas qu'il y a 3 personnes.
• Lignes collectées par parent : A en a 2, B en a 2, C en a 1, et le parent non apparié en a 1.
• 2 plus 2 plus 1 plus 1 égale 6.

`commentsCount` reste sur la ligne de publication. Si vous le copiez sur chaque commentaire collecté puis additionnez les copies, A contribue 10 deux fois et B contribue 20 deux fois. Cela fait 20 plus 40, soit 60. La somme affichée connue et correcte utilise chaque publication sélectionnée une fois : 10 plus 20 égale 30. La publication C est null. Ne changez pas null en 0. N'appelez pas 30 complet. La mesure des observations collectées est différente : 5 parents appariés plus 1 parent non apparié égale 6.

Cette feuille fictive n'a pas d'`OUTPUT`. Une couverture réelle a encore besoin de `pageCommentCount`, `publicRowsOnPage`, `savedRows`, `isPublicPageComplete`, `isComplete`, `stopReason`, `status` et `statusReason` de cette exécution. Un compte affiché de 10 avec 2 lignes collectées n'est pas à lui seul un taux de couverture.

Si les deux instantanés member12 restent dans la table de référence, C2 est copié et C3 est copié. Le tableau de preuves passe de 6 lignes à 8 lignes. Sélectionnez d'abord l'instantané `time-2`. Le tableau de preuves revient à 6 lignes. Supprimer les deux lignes de preuve en trop, alors que les deux instantanés restent dans la table de référence, ne répare pas la jointure suivante.

Member11 a écrit deux publications sélectionnées, A et B, et un commentaire sélectionné, C1. Si vous joignez directement ces deux publications écrites au commentaire que member11 a écrit, C1 apparaît deux fois. Comptez chaque branche avant de parler des deux. La branche auteur de publication a 2 publications. La branche auteur de commentaire a 1 commentaire. L'appariement au parent laisse C1 seulement sur la publication A. C1 correspond à member11 parce que la clé d'auteur du commentaire est member11, pas parce que member11 a écrit la publication A.

Member12 montre la direction autorisée. Un profil sélectionné correspond à deux commentaires. C2 reste sur A. C3 reste sur B. Le profil partagé ne déplace aucun des deux commentaires vers l'autre publication.

Un instantané de publication réussi, à lui seul, ne prouve pas une collection de commentaires vide. Seule une entrée de commentaires réussie et contrôlée, avec zéro ligne enregistrée, est un résultat vide observé. Un plafond borne encore ce résultat. Une restriction de la source borne encore ce résultat. Une entrée en échec reste inconnue. Une entrée non tentée reste inconnue. Un résultat vide observé n'est pas un `commentsCount` affiché null. Les totaux de l'exemple à six lignes ne changent pas. C6 est une clé parente non appariée. Ce n'est pas une tentative de collecte en échec sur une publication existante.

Trois autres règles fictives se trouvent hors des six lignes. Ne les ajoutez pas aux totaux ci-dessus.

Une personne dont les clés member sont null peut correspondre à un profil contrôlé lorsque l'URL `/in/` actuelle est exactement la même. Écrivez la base d'URL plus faible et les deux moments d'observation. Une URL null reste non résolue. Si l'ID member désigne X et que l'URL désigne Y, conservez un conflit et n'utilisez pas l'URL. Un commentaire dont `commentId` est null reste sa propre observation. Un texte égal ne répare pas l'ID absent. Un numéro de ligne de feuille ne le répare pas.

Le fichier terminé montre ce qui a été apparié, pourquoi cela a été apparié et ce qui reste inconnu. Il ne classe pas les personnes. Il ne juge pas la réussite d'une publication.