How to Compare Follower Growth Across a Fixed X Profile Panel

Check one known profile first

An Actor is a hosted data collection program. A Task is a saved input preset. The Actor collects result rows. You do the comparison in this article.

Use the X Profile Metrics Actor. The public build is 1.0.4. The saved X Competitor Profile Comparison Task was checked at 2026-10-13T14:22:40Z. A public Task is only a starting input. It does not make the comparison automatic.

The Task sample input has three profiles:

{
  "profiles": [
    "https://x.com/OpenAI",
    "https://x.com/NASA",
    "https://x.com/elonmusk"
  ]
}

For the first check, replace that whole list with one known public profile URL. Use the input key `profiles`. Do not use `startUrls`. The Actor also accepts a public handle. A full URL is the clearer first check.

{
  "profiles": [
    "https://x.com/OpenAI"
  ]
}

Put your own known public URL in that list before you rely on the run. The Actor attempts one result row for each unique input.

Read these fields on each result row: `profileId`, `profileUrl`, `handle`, `followersCount`, `profileMetricStatus`, `status`, `failureCategory`, `statusReason`, and `observedAt`. `profileId` is the stable profile identity. `handle` is the public name. `observedAt` is the source time. `profileMetricStatus` is an object. Its metric keys use `exact` or `unavailable`. `unavailable` means the count is not exact.

A missing `followersCount` is null. An exact zero is a real count. Do not turn null into zero. If you do, a missing row can look like a new profile. That makes a false net change.

The run summary is separate from the result rows. Read `inputCount`, `datasetRows`, `usefulRows`, `billableRows`, `failedRows`, `statusCounts`, and `stopReason`.

A fresh one-profile run returned the correct known OpenAI `profileId`. Its follower count was exact. The run summary was `inputCount` 1, `datasetRows` 1, `usefulRows` 1, `billableRows` 1, and `failedRows` 0. `statusCounts` showed ok 1. `stopReason` was `inputs_exhausted`. That means the run finished the inputs it was given.

This run proves current collection for one known profile. It does not prove that repeated panel runs stay accurate. A later roster can use separate finite batches. Each batch can contain at most 1000 inputs. That is the current maximum. The one-profile run does not prove that a 1000-input batch will succeed.

The Actor does not return earlier counts. It does not return a growth number. It does not return follower identities. It does not return gross follows or unfollows. It does not schedule runs. It does not store roster history. It cannot fill in past dates. You must save both boundaries yourself.

Do not subtract an older X Post Metrics `profileFollowers` value from this standalone `followersCount`. Those values come from different sources. Their difference is not a tested growth result.

Follow eight comparison steps

1. State the comparison question before you collect new counts. Save the fixed roster before you see who gained followers. Keep that original list. At each boundary, report coverage. Coverage is the number of roster profiles with a usable result row. A changing list of popular accounts answers a different question. A list you pick from accounts that already grew also answers a different question. Do not swap in either list after you start.
2. Collect a current snapshot of each known profile at each saved boundary. A snapshot is the result row you save at that time. The Actor cannot fill in past dates. You must keep the earlier rows yourself. To keep old rows and check elapsed time, use the Facebook post metrics history page. Use that page only for saving rows and checking elapsed time. Use these steps to decide who stays in the paired cohort and how to combine counts.
3. Pair two rows only when `profileId` is not blank and matches. The same `profileId` can use a new handle spelling and still pair. The same handle with a different `profileId` is a conflict. Leave conflicts unpaired. A count that is rounded or `unavailable` is not exact. Leave it out of both growth summaries. Also leave out failed rows, missing rows, and profiles with no start count. Do not replace a fresh null with an older count. Do not add a newly successful profile to the paired cohort in silence.
4. Use the same start boundary and end boundary for both summaries. Use the same exact-count rule for both. The source time is `observedAt`. Elapsed time is the span from the start `observedAt` to the end `observedAt`. A label such as weekly is not a source time. If one profile covers a much longer or shorter time, put it in another group. Do not combine groups that cover different periods.
5. Write down the paired cohort and the coverage before you combine counts. For each included profile, net change = end - start. When the start count is not zero, relative growth = (end - start) / start. Relative growth is the net change divided by the start count. A start count of exact zero can still have a net change. Its relative growth has no percentage, because you cannot divide by zero. A negative net change is possible. It can be a loss or a revised count. It does not name who unfollowed. It does not tell you why the count changed.
6. Pick one cohort whose start counts are exact and not zero. Use that same cohort, the same exact counts, and the same time group for both summaries. Follower-weighted growth = (sum of net changes) / (sum of starting counts). Weight means how much one profile moves the combined number. A larger start count has more weight. The equal-account average is the average of the relative growth values in that same cohort. This average is the equal-account mean. An average adds the values and divides by the number of values. Each included profile counts once. A small profile can have a large percentage and still add little to the total. The weighted summary stays near the large profile. The equal-account average moves toward the small profile. Write the cohort name and the weight rule beside every number. Do not give the two summaries the same name.
7. Keep exact-zero start profiles outside the percentage cohort. You can still show their net change. Show missing and failed profiles outside the summaries too. If the successful set changes, the summary can change. That can happen even when each included profile did not change. Report the number of included profiles. Report each excluded state. Do not report only the combined number. Neither summary counts unique new followers. Neither summary judges audience quality. Neither summary shows that a post caused the change.
8. Give the per-profile pairs, the roster coverage, and both named summaries. For a later period, keep the same profiles and the same boundary rules. If the profiles change, show that change clearly. Do not treat this roster as growth for every X profile. Do not expect the Actor to monitor the roster for you. Do not treat this chosen list as proof about a wider population.

Compare one original fiction roster

All profiles, IDs, times, and counts in this section are original fiction. They are not Actor output. They are not a product result. No follower-history panel was run.

The assumed start `observedAt` for the exact paired rows is 2026-09-15T15:00:00Z. The assumed end `observedAt` for those same rows is 2026-10-13T15:00:00Z. ProfileA, ProfileB, and ProfileC use both times. Their `status` is ok at both boundaries. Their followers value in `profileMetricStatus` is `exact`. No failure is recorded on those rows.

Unknown below means the value was not observed. Unknown is not zero. Null is a missing count. Null is not zero.

ProfileC starts at exact 0. That 0 is a real count. ProfileD has no start count, so it has no baseline. Baseline means the start count. Its end count is unknown and is not filled in. ProfileE has a failed fresh count. Its end `followersCount` is null, and the followers status is `unavailable`. `failureCategory` and `statusReason` mark that failure. Their exact text is not part of this fiction, so it is not invented here. ProfileF keeps both IDs because the handle matches but the ID does not. Its counts stay unknown. Leave the conflict out. Do not pick one ID in silence.

This next note is also original fiction. It is not a seventh roster entry. The start handle AlphaNews and the end handle Alpha_News share `profileId` fic-same. Pair those rows after the ID check. A handle spelling change is not a new person. The roster still has six entries.

Usable net-change pairs are 3 of 6: ProfileA, ProfileB, and ProfileC. The nonzero-baseline percentage cohort is 2 of 6: ProfileA and ProfileB. Do not call this full coverage.

ProfileA net change = 120 - 100 = 20. ProfileA relative growth = (120 - 100) / 100 = 20 percent. ProfileB net change = 1010 - 1000 = 10. ProfileB relative growth = (1010 - 1000) / 1000 = 1 percent.

The percentage cohort is ProfileA plus ProfileB. Start sum = 100 + 1000 = 1100. End sum = 120 + 1010 = 1130. Net sum = 1130 - 1100 = 30. That equals 20 + 10. Follower-weighted growth = 30 / 1100. That is about 2.72727 percent. The equal-account average = (20 percent + 1 percent) / 2 = 10.5 percent.

These two results are different estimands. An estimand is one defined quantity. Follower-weighted growth gives ProfileB more weight because 1000 is larger than 100. The equal-account average gives 20 percent and 1 percent equal shares. One number does not replace the other.

ProfileC goes from 0 to 12. Its net change = 12 - 0 = 12. That net change is valid. Its relative growth = (12 - 0) / 0. That value is undefined. Keep ProfileC outside the two-profile percentage cohort. Do not add 12 into the 1100 start sum.

The percentage cohort has 2 profiles. The net-change set has 3 profiles. The roster has 6 profiles. Do not read the net sum of 30 as 30 unique people. The rows do not say who followed or who unfollowed. They do not show that a post caused the change. The only measured collection check is the one-profile run in the previous section.