How to Separate X Original Posts, Replies, and Quotes in a Content Report

1. Define the accounts, sample, and counting unit

Write the account list before you classify posts. Record the account identifiers you will accept. An identifier, or ID, is a value used to distinguish one account or post from another.

Define the sample as the exact known posts you intend to check. If you also apply publication dates, record those dates. A supplied address list is a selected sample. It is not proof of a complete account history.

Use one distinct authored post as the counting unit. The unit is the thing each count represents. Keep these units separate:

• Requested addresses: the addresses you submit for collection.
• Distinct posts: the checked post IDs found through those requests.
• Authored posts: distinct posts whose authors match your account list.
• Classified posts: authored posts with a checked primary type.
• Metric observations: counter readings saved at stated times.

One post can have several requested addresses or several metric observations. Neither case creates more authored posts.

If you need to find posts before you can check them, treat that as a separate collection task. The guide to searching X posts by keyword and date explains that boundary. Search results still need identity and type checks before they enter this report.

Do not use received activity to establish authored activity. A post’s public reply counter concerns replies received by that post. It does not count how many reply posts its author wrote. Apply the same distinction to received quote and repost counters.

2. Check known addresses and preserve the returned identity

An Actor is a hosted data collection program. The X Post Metrics Actor has a documented fit here: it accepts known public X or Twitter post addresses and returns attempted metric snapshot rows. A snapshot is one reading at one observation time.

The frozen public contract, checked on October 25, 2026, describes build 1.0.4. It accepts one to 1,000 addresses through `startUrls`. It does not search for posts or return an account archive. These are documented capabilities, not results from a run made for this guide. See the checked public build contract.

Use this small input shape for a proposed first check:

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

Replace the sample address with one known public post from your declared sample. The supplied input is valid in shape. No run was made with it for this guide. Inspect the first returned row before you add more known addresses.

A Task is a saved input preset for an Actor. The public X Campaign Post Metrics Task page was present when checked. Its saved settings were not read through an authenticated account, and the Task was not run. Check its input before use.

Keep `inputUrl`, the requested address, separate from `postUrl`, the returned post address. Keep `postId`, the returned post ID, and `profileId`, the returned author account ID.

This distinction matters for repost addresses. The current public README says that a repost input row describes the visible original post. The returned identity, author, text, and metrics concern that original. Preserve the request-to-post connection. Do not count that request as another original authored by the account that reposted it. This behavior is documented in the public build and README evidence.

3. Save the mapping, post register, and metric observations

Use separate tables for separate units. A ledger is a saved table that records decisions and supporting evidence. The field names below describe a proposed reader ledger unless they appear as exact Actor fields in backticks.

First, save one request-mapping row for each attempted input.

Next, make one post-register row for each checked distinct post ID.

A cue is evidence that helps a decision. Treat native `postType` as a documented cue. Check the public context when your class decision needs a distinction that the row alone does not establish.

Parent and quoted source links in this ledger are reader-added evidence. The Actor contract does not export parent or quoted post IDs. Do not present your manual fields as native Actor output.

Finally, save metric observations separately. Keep the post ID, metric name, value, `observedAt`, publication time, metric status, precision, and source. Precision describes how exact the value is. Keep repeated readings as observations of the same post.

These fields are documented output fields. Their documentation does not prove that every attempted row will contain usable values. The checked output contract controls that distinction.

4. Apply one primary-class rule

Write the rule before you total the classes. Use the following order for this report:

1. Confirm that the post ID and author are checked.
2. Confirm that the author matches the declared account list.
3. If the post is a checked reply, assign reply as its primary class.
4. Otherwise, if it is a checked quote, assign quote.
5. Otherwise, assign original only when the public context supports that decision.
6. Leave an uncertain type unresolved.

This rule makes the classes mutually exclusive. That means an eligible post can enter only one primary class.

For a reply that contains a quote, assign reply and retain quote presence as yes. Save both reference links if your analysis needs them. Do not count the post again in the quote class.

Keep reference accounting separate from authored-post accounting. A quoted source helps explain what the author shared. It does not become another post authored by that account. If the source is independently part of your declared sample, give it its own checked record and apply the normal authorship rule.

A missing relationship field does not establish that no relationship exists. In particular, the absence of native parent or quoted IDs is a limit of this output contract. It is not evidence that the post has no parent or quoted source.

If two observations disagree about type, retain both pieces of evidence. Resolve the conflict through a public-context check, or leave the type unresolved. Do not pick the class that gives the preferred result.

5. Define the response comparison before calculating it

Choose one metric and a stated observation rule. A metric is a measured quantity, such as public views or likes. Do not add different counters together without a separate definition.

Keep authored type separate from received response. A quote-class post can receive replies, reposts, and quotes. Those received counters describe response to that one post. They do not change its authored class or create more posts in the register.

Record post age when you compare observations. Post age is the time between publication and the metric reading. A counter read soon after publication and one read much later have different time scopes. If publication time is missing, age is unknown. Do not substitute `observedAt` for `publishedAt`.

The Actor documents `postMetricStatus` entries with metric, status, precision, and source. Status can be `present`, `unavailable`, or `not_attempted`. Precision can be `exact`, `unavailable`, or `unknown`. Preserve these values with each metric you use. Do not treat one usable metric as proof that all six metrics are usable.

Write the quality rule in advance. For example, a report may require a present value with exact precision and a stated source. This is a proposed reader rule. It is not a claim that a run met that rule.

A missing value stays missing. A returned zero is a measured number. Do not replace a missing counter with zero to make a table complete. A post can have a checked class while remaining outside the eligible metric rows.

For each class, show the classified post count and the eligible metric count. Show the total only for eligible observations. If you show a mean, divide by the eligible post count for that metric. A mean is the total divided by the number of included posts. When that count is zero, the mean is undefined.

Public readings and owner-only report values can have different definitions and time scopes. If you already hold an authorized export, preserve it as a separate source. Use the public counter and owner-export comparison guide before treating the two values as equivalent.

6. Work through one example marked as original fiction

Original fiction. All labels and counts in this example are invented. These are not Actor results, Task results, or real post IDs.

Six supplied addresses resolve to five distinct posts. Two addresses resolve to P1. The other four resolve to P2, P3, P4, and U1.

The checked classification example is:

“Not specified” does not mean checked no. A real ledger must retain the evidence behind each decision. U1 has no usable view value in this example. Its missing value is not zero.

The post arithmetic is:

• 6 requested addresses resolve to 5 distinct posts.
• 5 distinct posts comprise 4 eligible classified posts plus 1 unresolved post.
• 4 eligible classified posts comprise 1 original plus 2 replies plus 1 quote.

P1 enters the post count once, despite its two requests. P4 enters the reply count once. Its quote flag remains visible, but it does not add a second class entry.

The fictional response panel uses matched view observations by the example’s stated premise. It supplies no actual publication or observation timestamps. In a real report, save those times and verify the match.

The complete eligible total is 100 + 40 + 200 + 60 = 400 fictional view events across four posts. The class totals also give 100 + 100 + 200 = 400 view events.

Those are source counter events, not unique people. The quote class has the largest total and mean in this invented sample. That does not show that quoting caused more response. It does not establish a general class ranking. The class sizes are one, two, and one posts.

Do not include U1 in a class mean. Do not assign it zero views. Keep it visible beside the table as one unresolved post with a missing metric.

7. Check the counts and keep failure states visible

Complete these acceptance checks before you share the report:

1. Trace every requested address to a saved outcome. Keep requests with unresolved identity visible.
2. Check distinct posts by stable post ID. Do not count repeated observations as additional posts.
3. Match authors to the declared account list. Keep unknown authors outside an exact authored-post count.
4. Check that each eligible classified post enters exactly one primary class.
5. Confirm that a reply with a quote appears once in the primary-class totals.
6. Trace every included metric value to its observation time, status, precision, and source.
7. Recalculate each class total from the included post rows.
8. State the unresolved and excluded counts beside the results.

Keep different problems in different states. A missing post ID prevents an exact identity count. An unknown author prevents a confirmed account match. A known author outside the account list is an exclusion, not an unknown author. An unresolved type can block class inclusion while leaving identity known.

A missing metric is another state. It does not erase a checked post or turn it into a failed classification. Unequal post ages limit the response comparison even when all identities and types are known.

Deliver the request mapping, checked post register, metric observations, written class rule, and bounded performance table. State what each count includes. Say whether the sample came from public checks, authorized owner records, or both.

Later questions need separate methods. Counting daily authored replies needs publication dates and a reporting time zone. Comparing topics needs content labels. Neither task follows automatically from these class totals. Likewise, keyword co-occurrence analysis counts terms within posts; it does not establish reply or quote relationships.