Como separar posts originais, respostas e citações no X em um relatório de conteúdo

1. Defina as contas, a amostra e a unidade de contagem

Escreva a lista de contas antes de classificar os posts. Registre os identificadores de conta que você aceitará. Um identificador, ou ID, é um valor usado para distinguir uma conta ou um post de outro.

Defina a amostra como os posts conhecidos exatos que você pretende verificar. Se também aplicar datas de publicação, registre essas datas. Uma lista de endereços fornecida é uma amostra selecionada. Ela não comprova um histórico completo da conta.

Use um post distinto de autoria da conta como unidade de contagem. A unidade é aquilo que cada contagem representa. Mantenha estas unidades separadas:

• Endereços solicitados: os endereços que você envia para coleta.
• Posts distintos: os IDs de posts verificados encontrados por meio dessas solicitações.
• Posts de autoria das contas: posts distintos cujos autores correspondem à sua lista de contas.
• Posts classificados: posts de autoria das contas com um tipo principal verificado.
• Observações de métricas: leituras de contadores salvas com os respectivos horários.

Um post pode ter vários endereços solicitados ou várias observações de métricas. Nenhum desses casos cria mais posts de autoria das contas.

Se precisar encontrar posts antes de verificá-los, trate isso como uma tarefa de coleta separada. O guia de busca de posts no X por palavra-chave e data explica esse limite. Os resultados de busca ainda precisam passar por verificações de identidade e tipo antes de entrar neste relatório.

Não use a atividade recebida para determinar a atividade de autoria da conta. O contador público de respostas de um post se refere às respostas recebidas por esse post. Ele não conta quantos posts de resposta o autor escreveu. Aplique a mesma distinção aos contadores de citações e reposts recebidos.

2. Verifique endereços conhecidos e preserve a identidade retornada

Um Actor é um programa de coleta de dados hospedado. O X Post Metrics Actor tem uma adequação documentada a este uso: aceita endereços conhecidos de posts públicos do X ou Twitter e retorna linhas das tentativas de captura de métricas. Uma captura é uma leitura em um momento de observação.

O contrato público congelado, verificado em 25 de outubro de 2026, descreve a versão de compilação 1.0.4. Ele aceita de um a 1.000 endereços por meio de `startUrls`. Não busca posts nem retorna um arquivo histórico da conta. Essas são capacidades documentadas, não resultados de uma execução feita para este guia. Consulte o contrato público verificado da versão de compilação.

Use esta estrutura pequena de entrada para uma primeira verificação proposta:

{
  "startUrls": [
    "https://x.com/OpenAI/status/2077446718728425686"
  ]
}

Substitua o endereço de exemplo pelo de um post público conhecido da sua amostra declarada. A entrada fornecida tem uma estrutura válida. Nenhuma execução foi feita com ela para este guia. Inspecione a primeira linha retornada antes de adicionar mais endereços conhecidos.

Uma Task é uma configuração de entrada salva para um Actor. A página pública da X Campaign Post Metrics Task estava disponível quando foi verificada. Suas configurações salvas não foram lidas por meio de uma conta autenticada, e a Task não foi executada. Verifique a entrada antes de usá-la.

Mantenha `inputUrl`, o endereço solicitado, separado de `postUrl`, o endereço do post retornado. Guarde `postId`, o ID do post retornado, e `profileId`, o ID da conta do autor retornado.

Essa distinção é importante para endereços de reposts. O README público atual informa que uma linha de entrada de repost descreve o post original visível. A identidade, o autor, o texto e as métricas retornados se referem a esse original. Preserve a ligação entre a solicitação e o post. Não conte essa solicitação como outro original de autoria da conta que o repostou. Esse comportamento está documentado nas evidências públicas da versão de compilação e do README.

3. Salve o mapeamento, o cadastro de posts e as observações de métricas

Use tabelas separadas para unidades diferentes. Uma tabela de controle é uma tabela salva que registra decisões e evidências de apoio. Os nomes dos campos abaixo descrevem uma tabela de controle proposta para o leitor, exceto quando aparecem entre crases como campos exatos do Actor.

Primeiro, salve uma linha de mapeamento de solicitação para cada entrada tentada.

Em seguida, crie uma linha no cadastro de posts para cada ID distinto de post verificado.

Um indício é uma evidência que ajuda a tomar uma decisão. Trate o campo nativo `postType` como um indício documentado. Verifique o contexto público quando sua decisão de classe exigir uma distinção que a linha sozinha não permite estabelecer.

Os links dos posts aos quais há respostas e das fontes citadas nesta tabela de controle são evidências adicionadas pelo leitor. O contrato do Actor não exporta IDs de posts aos quais há respostas nem de posts citados. Não apresente seus campos manuais como saída nativa do Actor.

Por fim, salve as observações de métricas separadamente. Guarde o ID do post, o nome da métrica, o valor, `observedAt`, o horário de publicação, o status da métrica, a precisão e a fonte. A precisão descreve o grau de exatidão do valor. Mantenha leituras repetidas como observações do mesmo post.

Esses são campos de saída documentados. Sua documentação não comprova que toda linha tentada conterá valores utilizáveis. O contrato de saída verificado rege essa distinção.

4. Aplique uma única regra de classe principal

Escreva a regra antes de somar as classes. Use a seguinte ordem neste relatório:

1. Confirme que o ID do post e o autor foram verificados.
2. Confirme que o autor corresponde à lista de contas declarada.
3. Se o post for uma resposta verificada, atribua resposta como classe principal.
4. Caso contrário, se for uma citação verificada, atribua citação.
5. Caso contrário, atribua original somente quando o contexto público sustentar essa decisão.
6. Deixe um tipo incerto como não resolvido.

Essa regra torna as classes mutuamente exclusivas. Isso significa que um post elegível só pode entrar em uma classe principal.

Para uma resposta que contenha uma citação, atribua resposta e mantenha a presença de citação como sim. Salve os dois links de referência se sua análise precisar deles. Não conte o post novamente na classe de citações.

Mantenha a contagem de referências separada da contagem de posts de autoria das contas. Uma fonte citada ajuda a explicar o que o autor compartilhou. Ela não se torna outro post de autoria dessa conta. Se a fonte fizer parte da sua amostra declarada de forma independente, crie um registro verificado próprio para ela e aplique a regra normal de autoria.

A ausência de um campo de relação não comprova que nenhuma relação existe. Em particular, a ausência de IDs nativos de posts aos quais há respostas ou de posts citados é um limite deste contrato de saída. Ela não é evidência de que o post não responde a outro post ou não tem uma fonte citada.

Se duas observações discordarem sobre o tipo, mantenha ambas as evidências. Resolva o conflito por meio de uma verificação do contexto público ou deixe o tipo como não resolvido. Não escolha a classe que produz o resultado desejado.

5. Defina a comparação da reação do público antes de calculá-la

Escolha uma métrica e uma regra de observação explícita. Uma métrica é uma quantidade medida, como visualizações ou curtidas públicas. Não some contadores diferentes sem uma definição separada.

Mantenha o tipo do post de autoria da conta separado da reação recebida. Um post da classe de citações pode receber respostas, reposts e citações. Esses contadores recebidos descrevem a reação àquele único post. Eles não alteram sua classe de autoria nem criam mais posts no cadastro.

Registre a idade do post ao comparar observações. A idade do post é o tempo entre a publicação e a leitura da métrica. Um contador lido logo após a publicação e outro lido muito depois abrangem períodos diferentes. Se o horário de publicação estiver ausente, a idade será desconhecida. Não use `observedAt` no lugar de `publishedAt`.

O Actor documenta entradas de `postMetricStatus` com métrica, status, precisão e fonte. O status pode ser `present`, `unavailable` ou `not_attempted`. A precisão pode ser `exact`, `unavailable` ou `unknown`. Preserve esses valores com cada métrica que usar. Não trate uma métrica utilizável como prova de que todas as seis métricas são utilizáveis.

Escreva a regra de qualidade com antecedência. Por exemplo, um relatório pode exigir um valor presente, com precisão exata e uma fonte informada. Essa é uma regra proposta para o leitor. Não é uma afirmação de que uma execução cumpriu essa regra.

Um valor ausente continua ausente. Um zero retornado é um número medido. Não substitua um contador ausente por zero para completar uma tabela. Um post pode ter uma classe verificada e ainda ficar fora das linhas de métricas elegíveis.

Para cada classe, mostre a contagem de posts classificados e a contagem de métricas elegíveis. Mostre o total apenas das observações elegíveis. Se mostrar uma média, divida pela contagem de posts elegíveis para aquela métrica. Uma média é o total dividido pelo número de posts incluídos. Quando essa contagem é zero, a média é indefinida.

As leituras públicas e os valores de relatórios exclusivos do titular da conta podem ter definições e períodos de abrangência diferentes. Se você já tiver uma exportação autorizada, preserve-a como fonte separada. Use o guia de comparação entre contadores públicos e exportações do titular da conta antes de tratar os dois valores como equivalentes.

6. Percorra um exemplo identificado como ficção original

Ficção original. Todos os rótulos e contagens deste exemplo são inventados. Não são resultados do Actor, resultados de Task nem IDs de posts reais.

Seis endereços fornecidos levam a cinco posts distintos. Dois endereços levam a P1. Os outros quatro levam a P2, P3, P4 e U1.

O exemplo de classificação verificada é:

“Não especificada” não significa que a ausência foi verificada. Uma tabela de controle real deve manter as evidências por trás de cada decisão. U1 não tem um valor utilizável de visualizações neste exemplo. Seu valor ausente não é zero.

O cálculo dos posts é:

• 6 endereços solicitados levam a 5 posts distintos.
• 5 posts distintos compreendem 4 posts classificados elegíveis mais 1 post não resolvido.
• 4 posts classificados elegíveis compreendem 1 original mais 2 respostas mais 1 citação.

P1 entra na contagem de posts uma vez, apesar de suas duas solicitações. P4 entra na contagem de respostas uma vez. Seu indicador de citação permanece visível, mas não adiciona uma segunda entrada de classe.

O painel fictício de reação do público usa observações de visualizações comparáveis, conforme a premissa declarada do exemplo. Ele não fornece datas e horários reais de publicação ou observação. Em um relatório real, salve esses horários e verifique a comparabilidade.

O total elegível completo é 100 + 40 + 200 + 60 = 400 eventos fictícios de visualização em quatro posts. Os totais das classes também resultam em 100 + 100 + 200 = 400 eventos de visualização.

Esses são eventos do contador da fonte, não pessoas únicas. A classe de citações tem o maior total e a maior média nesta amostra inventada. Isso não demonstra que citar causou mais reação do público. Não estabelece uma classificação geral das classes por desempenho. As classes têm um, dois e um posts.

Não inclua U1 na média de uma classe. Não atribua zero visualizações a ele. Mantenha-o visível ao lado da tabela como um post não resolvido com uma métrica ausente.

7. Verifique as contagens e mantenha os estados de falha visíveis

Conclua estas verificações de aceitação antes de compartilhar o relatório:

1. Vincule cada endereço solicitado a um resultado salvo. Mantenha visíveis as solicitações com identidade não resolvida.
2. Verifique os posts distintos pelo ID estável do post. Não conte observações repetidas como posts adicionais.
3. Confira a correspondência dos autores com a lista de contas declarada. Mantenha autores desconhecidos fora de uma contagem exata de posts de autoria das contas.
4. Verifique se cada post classificado elegível entra em exatamente uma classe principal.
5. Confirme que uma resposta com citação aparece uma vez nos totais por classe principal.
6. Vincule cada valor de métrica incluído ao horário de observação, ao status, à precisão e à fonte.
7. Recalcule o total de cada classe a partir das linhas dos posts incluídos.
8. Informe as contagens de não resolvidos e excluídos ao lado dos resultados.

Mantenha problemas diferentes em estados diferentes. Um ID de post ausente impede uma contagem exata por identidade. Um autor desconhecido impede a confirmação da correspondência com uma conta. Um autor conhecido fora da lista de contas é uma exclusão, não um autor desconhecido. Um tipo não resolvido pode impedir a inclusão em uma classe, mesmo que a identidade seja conhecida.

Uma métrica ausente é outro estado. Ela não apaga um post verificado nem significa que sua classificação falhou. Idades diferentes dos posts limitam a comparação da reação do público, mesmo quando todas as identidades e tipos são conhecidos.

Entregue o mapeamento de solicitações, o cadastro de posts verificados, as observações de métricas, a regra de classe por escrito e a tabela de desempenho com limites explícitos. Informe o que cada contagem inclui. Diga se a amostra veio de verificações públicas, de registros autorizados do titular da conta ou de ambos.

Perguntas posteriores exigem métodos separados. Contar respostas de autoria das contas por dia exige datas de publicação e um fuso horário para o relatório. Comparar temas exige rótulos de conteúdo. Nenhuma dessas tarefas decorre automaticamente dos totais por classe. Da mesma forma, a análise de coocorrência de palavras-chave conta termos dentro dos posts; ela não estabelece relações de resposta ou citação.