# How to Compare Topics in a Fixed Sample of X Posts

Compare topics by reading and labeling a fixed list of known posts before you view their response counts. Keep accounts, post types, and post ages separate. Then show each topic’s post count, median response, range, and missing cases. Use the result to choose a subject to explain next. Raw engagement counts cannot establish that a topic caused the response or will produce future follower growth.

Start with a manual review of meaning. The [public question collected on August 11, 2026](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/) asks “what topics get the most engagement.” Make that question narrower: which topics received which recorded responses within these selected posts? Engagement means recorded actions or counters, such as likes or replies. Choose one counter before you compare topics.

Your result will have three parts: written topic rules, a list that links each topic label to its source, and a response table with clear limits. You create these parts. The collection tool supplies documented source fields, not the complete analysis.

## 1. Write the decision and fix the sample

A sample is the set of posts you will examine. A fixed sample has a saved membership list that you do not change to improve the result.

Write one decision before you collect counts. For example, you might want to choose a subject for your next product explanation. That is a proposed decision, not evidence that the chosen subject will perform better.

Save these choices:

1. The supplied accounts and known post URLs.
2. The publication dates you intend to include.
3. The rule used to select those posts.
4. The post types allowed in each comparison.
5. The response counter you will use.
6. The post age required for that counter.
7. The decision the comparison will support.

A selection rule might use all supplied original posts within stated dates. Describe it accurately. If someone supplied only posts they considered successful, keep that qualification with the result.

Do not add a high-response post after you see the first table. Save it for a later sample, or record a new sample version and repeat the analysis.

A known-post list does not describe every post from an account. It also does not measure platform demand. Keep account results separate so a topic posted mainly by one account does not become an unexplained comparison with another account’s topics.

## 2. Check the source and post type first

Use a checked post-type record before you assign topics. A record is a saved row of facts and review decisions for one post.

Original posts, replies, and quote posts can have different purposes. A reply may answer an earlier question. A quote post may discuss another author’s statement. Keep these types separate where those differences affect the comparison. Leave an uncertain type unresolved until you can check it.

Distinguish the author’s words from quoted source content. A quoted pricing announcement does not, by itself, show that the author explains pricing. Read the author’s contribution and the context needed to understand it.

The [public Actor contract checked on October 25, 2026](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default) documents `postType`, but it does not export parent or quoted post IDs. Save required relationship checks in your own record. Do not treat a missing relationship field as proof that no relationship exists.

The same contract says a repost input row describes the visible original post. `inputUrl` preserves the requested address. The returned identity, text, and metrics describe that original. Do not count this row as another original work by the account that reposted it.

This guide starts after that source accounting. It does not replace the post-type review.

## 3. Define topics before viewing metrics

A topic is the reader question or subject that a post addresses. A codebook is a short set of written rules for assigning topic labels.

Create the codebook before you view metrics. A metric is a recorded numerical measure, such as a like count. Keep those columns hidden while you define and apply the topic rules. This is a blinded review: the reviewer assigns labels without seeing the response values.

Write these fields for each topic:

| Codebook field | What to save |
| --- | --- |
| Topic name | A short, stable label |
| Reader question | The question this topic answers |
| Include | The meaning required for this label |
| Exclude | Similar content that belongs elsewhere |
| Inclusion example | A short example of a matching subject |
| Exclusion example | A short example that does not match |
| Mixed rule | How to choose when two topics appear |
| Unclear rule | When meaning must remain unresolved |
| Version | The rule version used for the review |

These proposed codebook examples are original fiction:

| Topic | Reader question | Include | Exclude |
| --- | --- | --- | --- |
| Setup | How do I start using the product? | An explanation of first-use steps | A price announcement with no setup explanation |
| Pricing | What does the product cost or include? | An explanation of prices or plan contents | A setup guide that only mentions a paid plan |

Use one primary topic, meaning the main subject under your written rule. If two subjects have equal weight and the rule cannot resolve them, use a mixed label or leave the primary topic unresolved. Record that choice before you view the counts.

A keyword match alone cannot establish topic meaning. For a separate word-count task, use the [guide to keyword co-occurrence](/en/articles/x-post-keyword-cooccurrence/). Co-occurrence means two selected terms appear in the same post. It does not replace this reading step.

## 4. Read, label, and preserve unresolved meaning

Read each post and the context needed to understand its main point. Review images, quoted material, or linked content separately when the topic depends on them. The documented `text` field does not prove that all required meaning is available.

For each post:

1. Confirm the source identity and checked post type.
2. Read the author’s text and required context.
3. Apply the saved codebook without viewing metrics.
4. Assign one primary topic when the evidence supports it.
5. Save a short passage or reason for that decision.
6. Record missing context and unresolved meaning.

A secondary flag is an extra label that records another subject. Keep these flags separate from the primary topic table. Otherwise, one post can enter several topic totals without a clear explanation.

If the issue is whether a word names your product, use the [product-reference review guide](/en/articles/x-product-mention-review/). Confirming a product reference and identifying the post’s main topic are separate decisions.

Keep incomplete meaning outside the resolved-topic comparison. Do not assign a likely topic from one visible word. Also, do not call unresolved meaning a zero-response post.

If you change a topic rule, save the reason and apply the revised rule to the full sample. Check labels before you reveal the metrics. If you already knew some response values, record that limit rather than describing the review as fully blinded.

## 5. Collect compatible public observations

An observation is a recorded reading taken at a stated time. Post age is the time between publication and that reading. A seven-day-old post and a one-day-old post have different observation ages.

For a small sample, you can inspect public posts manually and save the source, time, counter, and availability. If you need owner-only records for your own account, keep them separate. Public observations do not provide another account’s private analytics.

The [X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics) fits the collection step when you already have public post URLs. An Actor is a hosted collection program. Its checked public input accepts one to 1,000 known X or Twitter post URLs in `startUrls`. It does not search for posts or return a complete account archive.

This supplied input has a valid documented shape:

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

5. Collect compatible public observations

Replace the sample address with one known public post URL from your fixed list. Use that one URL for a first check before submitting the rest. This is a proposed collection step. No run was made for this guide.

The public [X Campaign Post Metrics Task](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics) was present when checked on October 25, 2026. A Task is a saved input preset for an Actor. Its saved settings were not inspected with an authenticated account, and it was not run. Check its current input yourself before use.

The checked contract documents identity, text, publication time, observation time, and public counters. It also documents `postMetricStatus`, which records each metric’s availability, precision, and source. Precision describes whether a value is exact, unavailable, or unknown. Keep that state beside the value.

A current reading cannot reconstruct a past day-seven count. Use already saved matched-age readings, meaning readings taken at the same required post age. Otherwise, plan future observations. If you use current readings of different ages, state that difference and keep them outside a table that requires matched ages.

## 6. Save the topic and observation records

Keep the raw source facts separate from your topic decisions. Preserve the original values, including missing values.

A practical post-topic record needs these fields:

| Field | Purpose |
| --- | --- |
| Account identity | Keeps account comparisons separate |
| `inputUrl`, `postUrl`, `postId` | Links the request to the returned post |
| Checked post type | Defines the permitted comparison group |
| Text and context reference | Supports the meaning decision |
| Context state | Records complete, incomplete, or unresolved meaning |
| Primary topic | Holds one resolved topic or an unresolved state |
| Secondary flags | Stores additional subjects separately |
| Topic reason | Explains why the primary label applies |
| Codebook version and reviewer | Shows which rules were applied and by whom |
| `publishedAt`, `observedAt` | Supports the post-age check |
| Metric name and value | Identifies the counter and its reading |
| Metric status, precision, and source | Preserves the state from `postMetricStatus` |
| `status`, `statusReason` | Preserves the returned row state |
| Eligibility and reason | States whether the post enters this comparison |

Eligibility means that a post meets every rule for the stated comparison. A readable post can have an unavailable metric. A post with an exact metric can still have unresolved meaning. Record both states.

Use `postId` to check that repeated exports do not add another post. Several observations of one post are several readings, not several authored posts. Select the reading required by your age rule.

Keep these failure states visible:

| State | Treatment |
| --- | --- |
| Missing identity | Keep the attempt unresolved until identity is checked |
| Missing required context | Keep the topic unresolved |
| Missing metric | Leave the value missing and exclude it from that metric summary |
| Unknown precision | Keep the value outside an exact-only summary |
| Wrong observation age | Keep it outside the matched-age summary |
| Confirmed zero | Include zero if all other rules pass |
| No eligible posts in a topic | Report zero eligible posts and leave response summaries undefined |

A missing value means the measurement is unavailable. Zero means an available reading recorded no units of that counter. These are different facts.

## 7. Show counts and distributions

A distribution shows how response values differ across posts. Start with the eligible post count, median, and range for each topic within the same account, post type, metric, and age rule.

The median is the middle value after you sort the values. For an even number of values, use the mean of the two middle values. The mean is their sum divided by their count. The range here is the lowest through highest observed value.

Use clear units, such as likes per post at day seven. Like counts describe recorded likes. They do not measure unique people across the sample or future followers.

Show the requested count, resolved-topic count, eligible metric count, and excluded cases. A topic with two eligible posts does not provide the same amount of evidence as a topic with many eligible posts. Always show the sample sizes beside the response summaries.

Keep the source list available for review. A summary without its contributing posts makes it hard to check whether different purposes or one unusual post explain the pattern.

## 8. Work through one fictional comparison

Original fiction. All posts, IDs, and readings in this example are invented. The example assumes exact saved day-seven like readings. It is not an Actor result or evidence about real accounts.

The fixed list contains six original posts from one supplied account. Five have complete text, a resolved primary topic, and eligible day-seven like counts. One remains meaning-unresolved.

| Fictional post | Primary topic | Saved day-seven likes | Comparison state |
| --- | --- | --- | --- |
| P1 | Setup | 10 | Eligible |
| P2 | Setup | 20 | Eligible |
| P3 | Setup | 100 | Eligible |
| P4 | Pricing | 25 | Eligible |
| P5 | Pricing | 35 | Eligible |
| P6 | Unresolved | Not specified | Outside topic comparison |

No like value is supplied for P6 in this example. Do not invent a value, call it zero, or infer a collection failure. Its stated reason for exclusion is unresolved meaning.

For Setup, sort the readings: 10, 20, 100 likes. The middle reading is 20 likes. The median is therefore 20 likes per post. The range is 10–100 likes per post.

For Pricing, sort the readings: 25, 35 likes. There are two middle values. Calculate the median as follows:

(25 likes + 35 likes) / 2 posts = 30 likes per post.

The Pricing range is 25–35 likes per post.

| Topic | Eligible posts | Median day-seven likes per post | Range of day-seven likes per post |
| --- | --- | --- | --- |
| Setup | 3 | 20 | 10–100 |
| Pricing | 2 | 30 | 25–35 |

Check the totals: 3 Setup posts + 2 Pricing posts = 5 eligible posts. The five eligible posts plus one meaning-unresolved post account for all six supplied posts.

P3 is an outlier: its response is far from the other Setup values. Keep it in the table unless a written eligibility rule excludes it. Review its source and purpose. Do not remove it merely because it makes the range wide.

The supported statement is narrow: Pricing has the higher median in these five eligible posts. Setup contains the highest individual reading. Pricing has only two eligible posts. These facts do not establish a causal topic winner or predict follower growth.

## 9. Check the result before choosing a subject

Before you use the table, complete these checks:

1. Reconcile every supplied post with an eligible or excluded record.
2. Confirm that each included post contributes once to its primary topic.
3. Confirm the same metric, age rule, account, and post-type group.
4. Check missing values separately from confirmed zeros.
5. Recalculate each median and range from the saved readings.
6. Read outliers and unresolved cases beside the topic definitions.
7. Check whether different purposes or account differences offer another explanation.
8. Write a conclusion that names the sample and its limits.

Describe the pattern as an association: a topic label and a response occurred together in this sample. The comparison does not isolate what caused the response. A higher median does not prove that repeating the topic will improve results.

## Choose the next explanation

In the fictional example, the founder reviews the two Pricing sources before choosing a further pricing explanation. That action uses a small observed pattern to guide reading and planning. It does not establish that Pricing causes more engagement or future follower growth.

Save the codebook, labeled sources, observation records, exclusions, and final table together. If compatible readings are missing, plan the next observations before making a matched-age comparison. If meaning remains unclear, improve the source review before expanding the topic claim.

Use [X Post Metrics](https://apify.com/chronometrica/x-post-metrics) when your collection step needs snapshots from known public post URLs. Keep topic judgment and the final content decision in your own review process.

## Sources

- [Public founder question — retrieved August 11, 2026; one question record, no demand estimate](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/)
- [X Post Metrics public build 1.0.4 and README — checked October 25, 2026; documented input and output, no runtime test](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)
- [X Campaign Post Metrics Task — checked October 25, 2026; public presence only, saved settings unverified, no run](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics)