Como unir perfis, publicações e comentários do LinkedIn sem correspondências erradas

Escolha primeiro a granularidade da linha

Granularidade da linha significa o que uma linha representa. Escolha a granularidade antes de coletar as linhas.

A granularidade da evidência é uma observação de comentário selecionada. Uma observação de comentário é um comentário de nível superior salvo de um instantâneo. A granularidade da contagem é uma publicação selecionada. Uma contagem de comentários e uma contagem de publicações são medidas diferentes. Escreva os dois significados no arquivo antes de somá-los.

Escreva as URLs de origem conhecidas. Escreva o período do relatório. O corte do relatório é o último horário de observação que você inclui. Uma linha depois do corte permanece no conjunto de dados original. Ela não entra neste relatório.

Use este método só para URLs públicas de publicação conhecidas, os comentários públicos de nível superior delas e perfis de pessoa verificados. Não use o método para busca de conta, todas as publicações de uma conta, listas de reações, respostas, envio de mensagens, rótulos de cargo ou pontuações de texto.

Termos

Uma URN é um identificador de texto tipado. Em `urn:li:activity:1001`, o tipo da URN é `activity`. O tipo faz parte da chave. `ugcPost` é um tipo de publicação diferente. `member` é um tipo de conta de pessoa nestes Actors. `organization` não é um tipo de conta de pessoa.

O guia de URN do LinkedIn explica os tipos de URN da API oficial do LinkedIn. Essa API usa uma URN `person`. A chave de perfil do Actor usa `member`. Esses dois esquemas não são o mesmo. Não copie um identificador de uma API do LinkedIn para a outra e o trate como igual.

JSON é um formato de dados em texto. Você vai usar JSON, ou colunas de texto, para que identificadores longos não percam dígitos.

Um campo booleano é verdadeiro ou falso. Padrão significa o valor usado quando você deixa o campo sem alteração. O esquema de entrada é a lista publicada de campos que um Actor aceita. Uma chave pai é a chave da publicação gravada em uma linha de comentário. Alternativa seguinte significa que você tenta a próxima chave só quando a chave anterior está ausente. Canônica significa a única URL de origem que você confirmou, não uma segunda forma dessa URL.

Chaves compatíveis têm o mesmo tipo de URN e o mesmo valor. Um conflito significa que uma chave aponta para dois alvos, ou que duas chaves apontam para dois alvos diferentes. Tipos de URN diferentes, sozinhos, não são um conflito quando as chaves do mesmo tipo nomeiam uma publicação.

O que os três Actors devolvem

Três Actors públicos fornecem as linhas de origem. Você ainda constrói a junção.

O LinkedIn Post Scraper é o build 1.0.60. O LinkedIn Comments Scraper é o build 1.0.47. O LinkedIn Profile Scraper é o build 1.0.28. Leia a página de cada Actor antes de uma execução. Um build posterior pode mudar um campo.

Cada Actor lê páginas públicas. Nenhum deles usa o seu login do LinkedIn. Nenhum deles devolve todas as publicações de uma conta.

A entrada de comentários também tem `maxComments`, `includeAuthorDetails` e `collectAllAvailable`. `maxComments` é um número inteiro de 1 a 1000. O padrão é 100. `maxComments` é o máximo de comentários salvos por publicação/entrada. Não é um teto único compartilhado por toda a execução com várias entradas. O limite continua a valer, em separado, para cada publicação/entrada. `includeAuthorDetails` é um booleano. O padrão é false. `collectAllAvailable` é um booleano. O padrão é false. `collectAllAvailable` remove só o limite numérico de salvamento. Não remove uma restrição pública. Não coleta respostas.

Contagens de comentários e status da entrada estão em `OUTPUT`. `OUTPUT` é o resumo da execução. Não é uma linha de comentário. Dentro dele, `inputResults` traz `status`, `statusReason`, `pageCommentCount`, `publicRowsOnPage`, `savedRows`, `isPublicPageComplete`, `isComplete` e `stopReason`.

`pageCommentCount` é a contagem informada para a página. `publicRowsOnPage` é o número de linhas públicas vistas nessa página. `savedRows` é o número armazenado. Esses três números podem ser diferentes. `isPublicPageComplete` diz se o Actor marcou a página pública como completa. `isComplete` diz se a coleção salva está completa. `stopReason` diz por que o salvamento parou. Um resultado parcial pode vir do limite de salvamento, de uma prévia pública ou de um limite de cobrança. Uma contagem desconhecida permanece null. Não escreva zero no lugar dela.

O Actor de comentários pode aceitar uma URL tipada de atualização do feed. O Actor de publicação exige uma URL `/posts/`. Se você conhece só a URL do feed, mantenha as chaves pai do comentário. Obtenha uma URL `/posts/` correspondente e verificada antes de coletar o instantâneo da publicação. Não invente um slug de `/posts/`.

Use estas Tasks e depois altere a entrada de exemplo. Uma amostra sem alteração não pode ser unida. A amostra da Task de publicação é uma publicação diferente da amostra da Task de comentários.

Não acrescente as duas Tasks de comentários como dois conjuntos de comentários. Escolha uma Task de comentários para essa publicação. A Task de detalhes ainda pode devolver um comentário sem ID de autor. Um pedido útil de detalhes pode causar um evento de cobrança separado. O pedido não garante um ID. Ele não garante uma cobrança.

Os detalhes padrão do autor estão desligados. Chaves estáveis de autor do comentário muitas vezes são null nessa saída padrão. Identificadores públicos e URLs públicas podem mudar depois. Um instantâneo de perfil mostra o perfil no horário dele. Ele não prova um cargo no horário anterior do comentário. Este método não atribui papéis de cargo.

A documentação de execução descreve limites de execução e tempo limite. Leia a documentação antes de uma execução grande. Não coloque tokens de acesso na planilha.

Como corresponder um comentário a uma publicação

Corresponda na ordem indicada. Mantenha as regras de mesmo tipo. A chave de correspondência nomeia uma publicação. Verifique primeiro todas as chaves compatíveis disponíveis em busca de conflitos. Não ignore uma chave inferior contraditória. Só depois dessa verificação, escolha a primeira base de correspondência suportada na ordem indicada. Registre essa base. A coluna de base é feita pelo leitor. Os Actors não a devolvem.

1. `postUrn` tipada igual.
2. `activityId` igual, só dentro do tipo activity.
3. `ugcPostId` igual, só dentro do tipo ugcPost.
4. Uma URL de origem canônica verificada.

Os campos do comentário são `postUrn`, `activityId`, `ugcPostId` e `postUrl`. Os campos da publicação são `postUrn`, `activityId`, `ugcPostId` e `url`. Qualquer um deles pode ser null.

Use uma URN tipada antes de um ID simples. Um valor de activity e um valor de ugcPost podem existir os dois em uma publicação e ainda serem diferentes. Isso é normal. Não compare um valor de activity com um valor de ugcPost. Dígitos iguais entre tipos não são evidência.

A publicação A no exemplo fictício tem activity `1001` e ugcPost `2001`. Essas são duas chaves para uma publicação, não um conflito. Existe conflito quando uma chave aponta para duas publicações, ou quando as chaves disponíveis apontam para duas publicações diferentes. A ordem de alternativa seguinte não permite que uma chave mais fraca anule esse conflito. Deixe o comentário sem resolução.

Use a URL só quando as chaves tipadas estão ausentes. As duas URLs precisam ser a mesma URL de origem canônica que você verificou. Se você não puder verificar isso, deixe a linha sem resolução. Uma base de URL é mais fraca que uma chave tipada. Escreva a base e os dois horários de observação.

Reduza instantâneos duplicados de publicação a uma linha de consulta selecionada antes desta junção. Se a consulta ainda tiver duas linhas bem-sucedidas para uma publicação, a junção vai copiar comentários. Corrija a consulta. Não apague as linhas de comentário copiadas e deixe a consulta sem alteração.

Um instantâneo de publicação ausente é uma correspondência ausente. Não é uma publicação vazia. Uma publicação bem-sucedida sem comentários salvos é um resultado diferente. Uma tentativa de publicação com falha é um resultado diferente. Uma entrada que você não executou é um resultado diferente.

Como corresponder um perfil de pessoa

Corresponda um perfil a um autor de comentário só depois que o autor significar uma conta de pessoa. O campo do comentário é `authorType`. Ele pode ser `person`, `organization` ou null. O Actor de publicação pode gravar o tipo de autor da publicação como `Person`. Mantenha cada valor de origem exatamente como chegou. Para esta verificação de significado, `person` e `Person` significam os dois uma conta de pessoa. Não exija as mesmas letras maiúsculas. Não edite o texto armazenado para fazer as letras coincidirem.

Um autor organização fica fora da junção de perfil de pessoa. Uma URL de organização não pode virar uma linha de perfil `/in/`. `urn:li:member:11` e `urn:li:organization:11` são chaves diferentes. Não retire o tipo da URN para forçar uma correspondência.

Depois da verificação de pessoa, corresponda nesta ordem:

1. ID de member igual: `profileId` do perfil com `authorId` do comentário.
2. URN de member igual: `profileUrn` do perfil com `authorUrn` do comentário.
3. Uma alternativa mais fraca: `publicIdentifier` com `authorPublicIdentifier`, ou a URL canônica `/in/` de `url` do perfil e `authorUrl` do comentário.

Não corresponda null. Não corresponda uma célula em branco. Se o ID de member aponta para o perfil X e a URL aponta para o perfil Y, a linha é um conflito. Não use a URL mais fraca para escolher um vencedor.

Uma URL ou um identificador público pode mudar entre instantâneos. Se você usar essa base mais fraca, escreva os dois valores de `observedAt` e a base. Uma URL null permanece sem resolução. Nomes, fotos e headlines não são chaves. Não busque pelo nome para preencher um link ausente.

Os mesmos campos de perfil podem ser comparados com os campos de autor da publicação `authorId`, `authorUrn`, `authorPublicIdentifier`, `authorUrl` e `authorType`. Essa comparação verifica só o papel de autor da publicação. Ela é opcional. Não é o autor do comentário. Nunca substitua um autor de comentário pelo autor da publicação. Nunca una todas as publicações de uma conta a todos os comentários dessa conta.

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

Uma pessoa pode escrever muitos comentários. Uma publicação pode ter muitos comentários. Essas duas setas são separadas.

A identidade do comentário usa `commentId`, `commentUrl`, a chave pai e `observedAt`. Um ID ou um link pode ser null. Mantenha essa observação. Não invente um ID estável. Não trate texto igual como o mesmo comentário. Não trate o número de uma linha da planilha como um ID. Entre execuções, selecione uma observação só quando a chave pai e `commentId` forem os dois estáveis e iguais. Linhas sem `commentId` estável permanecem observações separadas.

O status de perfil e de publicação usa `status`, `statusReason` e `observedAt`. Mantenha uma linha de perfil com falha no arquivo de origem. Não a trate como uma correspondência bem-sucedida de perfil.

Selecione um instantâneo antes da junção

Uma linha de consulta é o único instantâneo que você permite a junção usar. Selecione no máximo uma linha de publicação bem-sucedida para cada publicação verificada. Selecione no máximo uma linha de perfil bem-sucedida para cada pessoa verificada. Faça isso antes da junção.

Mantenha os conjuntos de dados originais. Não misture dois instantâneos em uma linha nova. Escreva a regra de seleção no arquivo. Uma regra clara é o instantâneo bem-sucedido mais recente antes do corte do relatório.

Se uma pessoa tem dois instantâneos de perfil bem-sucedidos, escolha um. Se os dois permanecem na consulta, cada comentário dessa pessoa é copiado uma vez para cada instantâneo. As linhas unidas extras são um erro de consulta. Corrija a consulta. Não apague as cópias e chame a planilha de correta.

Depois, construa uma junção à esquerda a partir das observações de comentário selecionadas. Primeiro una cada comentário a uma publicação de origem. Depois una o autor pessoa dele a no máximo um perfil. Um comentário sem correspondência de publicação permanece. Um comentário sem correspondência de perfil permanece.

A tabela de evidência unida precisa ter o mesmo número de linhas que as observações de comentário selecionadas. Mais linhas significam que uma chave de consulta ainda aponta para mais de uma linha.

Estes campos feitos pelo leitor pertencem à linha de evidência: base da correspondência, resultado da correspondência, regra do instantâneo selecionado e os horários de origem que você comparou. Rotule esses campos como feitos pelo leitor. Não os apresente como campos do Actor.

Mantenha IDs longos como texto. Uma planilha pode alterar um número longo e descartar dígitos. Exporte JSON, ou defina toda coluna de ID como texto antes da importação. JSON está definido acima. A documentação de conjunto de dados indica o caminho de exportação: selecione o conjunto de dados, escolha Export, escolha o formato e escolha Download. Salve `OUTPUT` à parte. Uma exportação de conjunto de dados não contém `OUTPUT`.

Passos

1. Escreva a granularidade, as URLs conhecidas, o corte do relatório e o significado de cada contagem. O arquivo de evidência terá uma linha por observação de comentário selecionada. O arquivo de contagem terá uma linha por publicação selecionada. Um total de comentários e uma contagem de publicação exibida permanecem separados até essa escrita terminar.
2. Abra IDs de publicação e comentário do LinkedIn para junções seguras de dados. Substitua a URL de exemplo por uma URL pública de publicação conhecida. Defina `maxComments` como 3. Mantenha `collectAllAvailable` em false. Deixe os detalhes do autor desligados. Inicie a execução. Abra `OUTPUT` antes de explicar um conjunto pequeno ou um conjunto vazio. Poucas linhas podem significar o limite de salvamento, uma entrada com falha, uma restrição pública ou um conjunto público curto de comentários. A contagem de linhas, sozinha, não diz qual é o caso.
3. Se você precisa de chaves de autor que as linhas padrão de comentários não contêm, use Autores de comentários do LinkedIn com detalhes públicos de perfil no lugar da primeira Task de comentários. Substitua a publicação de exemplo. Use três comentários. Mantenha a opção ilimitada desligada. Defina `includeAuthorDetails` como true. Não cole as duas saídas juntas. Os detalhes ainda podem estar ausentes. O pedido extra de detalhes pode ser cobrado à parte, e ainda pode não devolver um ID.
4. Abra IDs de publicação e chaves de autor do LinkedIn para junções de dados. Substitua a amostra dela pela mesma URL `/posts/`. Não passe um ID de publicação. Não passe uma URL de atualização do feed. Se você tem só uma URL de atualização do feed, mantenha as chaves pai do comentário e pare a coleta da publicação até ter uma URL `/posts/` verificada. Não invente o slug. Mantenha separadas as linhas `ok`, `failed` e `invalid_url`. Mantenha `observedAt`. Um instantâneo de publicação ausente permanece uma correspondência ausente.
5. Leia as chaves de autor do comentário. Se as linhas de comentários já têm todo fato de autor de que este relatório precisa, pule o Actor de perfil. Se não têm, colete URLs públicas `/in/` distintas com IDs de perfil e URNs do LinkedIn para junções de dados. Remova URLs repetidas. Exclua URLs de organização. Não busque por nome, foto ou headline. Mantenha tentativas de perfil com falha no arquivo de origem. Uma tentativa com falha não é uma pessoa correspondida.
6. Selecione a consulta. Mantenha um instantâneo de publicação bem-sucedido por publicação verificada. Mantenha um instantâneo de perfil bem-sucedido por pessoa verificada. Para execuções repetidas de comentários, mantenha uma observação por chave pai estável mais `commentId`. Mantenha linhas sem `commentId` como observações separadas, mesmo quando o texto é igual. Mantenha todo conjunto de dados original. Escreva a regra de corte. Resolva chaves duplicadas e conflitos na consulta antes de unir.
7. Faça a junção à esquerda de cada comentário selecionado com uma publicação. Use `postUrn` tipada igual, depois ID de activity igual, depois ID de ugcPost igual e depois uma URL canônica verificada. Não cruze tipos de URN. Depois una o autor pessoa a no máximo um perfil. Use ID de member, depois URN de member e depois um identificador público datado ou uma URL canônica `/in/`. Escreva a base feita pelo leitor, o resultado e os dois horários de origem. Não preencha um autor de comentário a partir do autor da publicação. Não una todas as publicações de uma conta a todos os comentários dessa conta.
8. Conte as linhas de evidência. O número precisa ser igual às observações de comentário selecionadas. Se for maior, a consulta ainda tem muitas linhas para uma chave. Corrija essa consulta e una de novo. Não apague linhas de evidência repetidas como o único reparo. Conte à parte publicações pai sem correspondência, chaves de pessoa ausentes, perfis com falha, autores organização e conflitos.
9. Agrupe as observações de comentário pela chave de publicação resolvida. Coloque `commentsCount` em uma única linha de publicação selecionada. Coloque a cobertura de `OUTPUT` dessa execução ao lado da publicação. Mantenha uma publicação que não tem comentários salvos. Mantenha uma coleta vazia bem-sucedida, uma tentativa com falha e uma entrada que você não executou como fatos diferentes. Conte chaves de autor como contas observadas. Não as chame de pessoas distintas, com cada pessoa contada uma vez. Não as chame do conjunto completo de autores de comentários ou de espectadores.
10. Exporte a tabela de evidência, a tabela sem resolução, a tabela de contagem por publicação e um resumo das fontes. Use o caminho de exportação do conjunto de dados acima. Salve `OUTPUT` ao lado. Mantenha os IDs como texto. Em cada linha de resultado, mostre as chaves de origem, a base feita pelo leitor e a evidência ausente. Preencha uma lacuna só quando você tiver uma URL de origem suportada para essa lacuna exata. Caso contrário, deixe a lacuna desconhecida.

A contagem de evidência é o passo 8. A contagem de publicações é o passo 9. Não use a contagem de publicações como contagem de comentários.

O que uma verificação pública provou

Uma verificação pública salvou três comentários de uma publicação conhecida. A origem mostrou quatro comentários e expôs quatro linhas. O limite salvou três. Cada uma das três chaves pai salvas correspondeu a essa mesma publicação de origem. Um autor de comentário correspondeu a uma linha separada de perfil de pessoa. Todas essas correspondências verificadas foram bem-sucedidas.

O `OUTPUT` de comentários dessa execução tinha `isPublicPageComplete` true, `isComplete` false e `stopReason` `max_comments_reached`. Lidos juntos, o Actor marcou a página pública como completa, e o salvamento ainda estava incompleto porque o limite de salvamento foi atingido.

Essa verificação prova só essas linhas e esse resumo. Ela não prova toda publicação posterior. Não é um teste ao vivo novo de correspondência de ugcPost, de autores organização, de chaves null ou de conflitos. Esses casos usam as regras de campo acima e as contagens fictícias abaixo.

Publicações, comentários e contagens fictícios

Todo valor nesta seção é fictício. C1 a C6 são rótulos de ensino. Os IDs curtos são IDs de ensino. Eles não são valores coletados do LinkedIn. Não trate nenhuma URN abaixo como um perfil, uma publicação ou um comentário real.

O corte do relatório é depois de `time-2`. O instantâneo selecionado de member12 é o bem-sucedido mais recente. O tipo de autor da publicação está armazenado como `Person` em A e B. O tipo de autor do comentário está armazenado como `person` em C1 a C4. Esses significados coincidem. As letras armazenadas permanecem diferentes. A publicação C está armazenada como autor organização.

Member11 tem uma linha de perfil selecionada e bem-sucedida. Member12 tem dois instantâneos bem-sucedidos. Selecione um antes da junção. Member13 tem uma tentativa de perfil com falha. A e B foram escritos por member11. C foi escrito por organization11, não por member11.

C2 não corresponde por uma URN tipada de activity, porque essa URN pai é uma URN de ugcPost. O ID de activity `1001` corresponde à publicação A. O ID de ugcPost `2001` também corresponde à publicação A. As duas chaves do mesmo tipo concordam, então isto é confirmação, não conflito. A base que você escreve é o ID de activity.

C5 corresponde à publicação C porque os dois lados usam ugcPost `1001`. A publicação A também contém os dígitos `1001`, mas esses dígitos são um ID de activity. Dígitos iguais não movem C5 para A.

A tabela de evidência mantém seis linhas. A tabela de correspondência e a tabela sem resolução são visões. Elas podem repetir um comentário quando um lado corresponde e o outro lado não corresponde. Não some essas visões e chame a soma de total de comentários.

A visão de correspondência tem 8 linhas. C1, C2 e C3 têm, cada um, dois lados bem-sucedidos. C4 e C5 têm só o lado da publicação. Oito não é o total de comentários. Seis é o total de comentários.

C6 tem duas partes sem resolução e uma linha de evidência. Conte C6 uma vez como comentário.

Confira cada total:

• Observações de comentário selecionadas: 6.
• Linhas de evidência depois da junção à esquerda: 6.
• Correspondências de publicação pai: 5, que são C1, C2, C3, C4 e C5.
• Publicação pai sem correspondência: 1, que é C6.
• Linhas de comentário correspondidas a um perfil de pessoa bem-sucedido: 3, que são C1, C2 e C3.
• Perfis de pessoa bem-sucedidos usados: 2, que são member11 e member12.
• Resultados de pessoa sem resolução: 2, que são o perfil com falha em C4 e a chave de autor ausente em C6.
• Autor organização fora do escopo de perfil de pessoa: 1, que é C5.
• Chaves de member identificadas: 3, que são member11, member12 e member13.
• Essas 3 chaves de member não são 2 perfis, e não são 3 pessoas comprovadas.
• Linhas coletadas por publicação pai: A tem 2, B tem 2, C tem 1, e a publicação pai sem correspondência tem 1.
• 2 mais 2 mais 1 mais 1 é igual a 6.

`commentsCount` permanece na linha da publicação. Se você copiar esse valor para cada comentário coletado e depois somar as cópias, A contribui com 10 duas vezes e B contribui com 20 duas vezes. Isso é 20 mais 40, que é 60. A soma exibida conhecida e correta usa cada publicação selecionada uma vez: 10 mais 20 é igual a 30. A publicação C é null. Não mude null para 0. Não chame 30 de completo. A medida de observação coletada é diferente: 5 observações de comentário com correspondência de publicação pai mais 1 observação de comentário sem correspondência de publicação pai é igual a 6.

Esta planilha fictícia não tem `OUTPUT`. A cobertura real ainda precisa de `pageCommentCount`, `publicRowsOnPage`, `savedRows`, `isPublicPageComplete`, `isComplete`, `stopReason`, `status` e `statusReason` dessa execução. Uma contagem exibida de 10 com 2 linhas coletadas não é, sozinha, uma taxa de cobertura.

Se os dois instantâneos de member12 permanecem na consulta, C2 é copiado e C3 é copiado. A tabela de evidência cresce de 6 linhas para 8 linhas. Selecione primeiro o instantâneo `time-2`. A tabela de evidência volta a 6 linhas. Apagar as duas linhas extras de evidência, enquanto os dois instantâneos permanecem na consulta, não repara a próxima junção.

Member11 escreveu duas publicações selecionadas, A e B, e um comentário selecionado, C1. Se você unir diretamente essas duas publicações de autoria ao comentário que member11 escreveu, C1 aparece duas vezes. Conte cada ramo antes de falar dos dois. O ramo de autor da publicação tem 2 publicações. O ramo de autor do comentário tem 1 comentário. A correspondência da publicação pai deixa C1 só na publicação A. C1 corresponde a member11 porque a chave de autor do comentário é member11, não porque member11 escreveu a publicação A.

Member12 mostra a direção permitida. Um perfil selecionado corresponde a dois comentários. C2 permanece em A. C3 permanece em B. O perfil compartilhado não move nenhum dos comentários para a outra publicação.

Um instantâneo de publicação bem-sucedido, sozinho, não prova uma coleção vazia de comentários. Só uma entrada de comentários bem-sucedida e verificada, com zero linhas salvas, é um resultado vazio observado. Um limite ainda restringe esse resultado. Uma restrição da origem ainda restringe esse resultado. Uma entrada com falha permanece desconhecida. Uma entrada não tentada permanece desconhecida. Um resultado vazio observado não é um `commentsCount` exibido null. Os totais do exemplo de seis linhas não mudam. C6 é uma chave de publicação pai sem correspondência. Não é uma tentativa de publicação com falha.

Mais três regras fictícias ficam fora das seis linhas. Não as some aos totais acima.

Uma pessoa com chaves de member null pode corresponder a um perfil verificado quando a URL `/in/` atual é exatamente a mesma. Escreva a base de URL mais fraca e os dois horários de observação. Uma URL null permanece sem resolução. Se o ID de member aponta para X e a URL aponta para Y, mantenha um conflito e não use a URL. Um comentário com `commentId` null permanece a própria observação. Texto igual não repara o ID ausente. O número de uma linha da planilha não repara o ID.

O arquivo final mostra o que correspondeu, por que correspondeu e o que permanece desconhecido. Ele não classifica pessoas. Ele não julga o sucesso de uma publicação.