Understand PilotMyX Account Analytics

Which X metrics are available?

Available metrics depend on what X returns for the connected account and its API access level.

PilotMyX stores the latest post-level engagement measurements returned by X and the account's current follower count. The interface does not fabricate unavailable values, and partial responses remain marked as partial.

• Post impressions and engagement totals when available
• Likes, reposts, quotes, and other returned interactions when available
• Current follower count with its synchronization timestamp
• Posts and replies ranked by a selected supported metric
• Comparison with the preceding period

How are date ranges interpreted?

A selected period filters posts and replies by publication time, then uses the current synchronized metrics for each included item.

This makes a content cohort stable while its engagement can continue to mature. Comparing two reports therefore requires checking the publication range, selected posts/replies scope, and metrics timestamp. The analytics payload exposes a comparison-available flag. If either period contains unavailable post metrics, PilotMyX keeps the absolute current totals but returns null period deltas.

How are current metrics refreshed?

Each eligible refresh overwrites current values for at most the 100 most recent active cached posts and replies.

A post can gain impressions and interactions long after publication. PilotMyX stores only the latest synchronized value for the MVP, together with its measurement timestamp; it does not retain metric history. New posts already measured by the incremental timeline are not immediately fetched a second time.

How does the cache avoid redundant X API requests?

Dashboards and MCP tools query PostgreSQL first, while synchronization handles external reads separately.

The initial sync builds the local account dataset. Later syncs run only after an eligible Dashboard visit or an explicit Dashboard/MCP request, fetch newer posts and refresh a bounded set of current metrics, then persist them once for many cached reads. A one-hour cooldown prevents redundant X requests, and synchronization status lets a client decide whether stale data justifies a refresh.

How should an agent use freshness fields?

An agent should state the measurement timestamp when making an important analytical claim.

For routine planning, cached data may be sufficient. For a time-sensitive report, inspect synchronization status first and request a refresh when fresher data is genuinely needed. If post metrics are unavailable, the agent should qualify its conclusion instead of treating missing data as zero.