# Data points

A data point is one extra fact about a source, a person or a post. Subscriber counts, chart positions, how often a publication posts, engagement on an issue.

They sit apart from the main fields because they are observations rather than properties. A value can change over time, and it is not always there.

```json
{
  "key": "inbound_corpus_links",
  "value": 11649,
  "source": "derived:corpus",
  "fetched_at": "2026-08-19T04:11:02Z"
}
```

| Field | What it holds |
| --- | --- |
| `key` | What this fact is. |
| `value` | The value. A number, a string, or a small object, depending on the key. |
| `source` | Where we got it. See below. |
| `fetched_at` | When we last observed it. |

## Where a value came from

Every data point says where it came from. Use it to judge a number: a subscriber count a platform publishes is a different kind of fact from one we worked out ourselves.

> This section is only shown to signed-in users. Sign in at https://sputnikintelligence.com/login to read it.

## Where they appear

Data points come back on the detail response for a source, a person or a post. They are not on list rows, because loading them costs a query per item.

```bash
/api/v1/sources/<slug>
/api/v1/people/<slug>
/api/v1/posts/<slug>
```

## What to expect

**They are sparse.** A key exists for a publication only if we could observe it. Most sources have some data points and no source has all of them. Always check whether the key is there before reading it.

**Keys are not a fixed schema.** We add keys as we learn to observe new things, and stop refreshing ones that stop being available. Read the keys you recognise and ignore the rest. You may see a `source` not listed above, from a collector we have retired.

**Values are point-in-time.** `fetched_at` tells you how fresh a number is. A subscriber count from three months ago is still a useful order of magnitude and is not today's number.

**Some counts are bucketed.** Where a platform reports a range rather than an exact figure, the value is the bottom of the bucket. A `paid_subscriber_bucket` of `1000` means at least a thousand, not exactly a thousand.

## Audience and reach, on a source

The ones most people want. These tell you how big a publication is and how active it is.

| Key | What it holds |
| --- | --- |
| `subscriber_count_free` | Free subscribers, where the platform publishes it. |
| `paid_subscriber_bucket` | Paid subscribers, as the bottom of a bucket. |
| `leaderboard_rank` | Its rank in its category, where it appears in one. |
| `leaderboard_category` | The category that rank is in. |
| `apple_chart_ranks` | Podcast chart positions, by country and category. |
| `episode_count` | Episodes published, for a podcast. |
| `total_post_count` | Posts we hold for it. |

## Activity and standing, on a source

| Key | What it holds |
| --- | --- |
| `posting_cadence_per_week` | Posts per week, averaged. |
| `posting_consistency` | How regular that cadence is, from 0 to 1. A weekly show that never misses scores high. |
| `feed_age_days` | How long it has been publishing. |
| `inbound_corpus_links` | How many times other publications we index have linked to it. A rough measure of standing among its peers. |
| `has_custom_domain` | Whether it publishes on its own domain. |
| `feed_hosts` | Who writes or hosts it, with each person's share of its posts and their person slug. |

## Identity, on a source

| Key | What it holds |
| --- | --- |
| `author_name`, `owner_name` | Names the feed declares. |
| `owner_email` | The contact address in the feed. Publishers put this there deliberately. |
| `feed_language` | The language the feed declares. |
| `genres` | Podcast genres. |
| `explicit` | Whether the feed marks itself explicit. |
| `artwork_url`, `itunes_id` | Cover art and the Apple id, for a podcast. |
| `twitter_handle` | Where the publication declares one. |

## On a person

| Key | What it holds |
| --- | --- |
| `follower_count` | Followers on the platform they publish through. |
| `subscriber_count_bucket` | Subscribers to their own publication, as the bottom of a bucket. |
| `bestseller_tier` | A platform badge for paid-subscriber milestones. The number is the tier, not a count. |
| `author_publications` | Publications they write for. |
| `author_socials` | Links they list on their profile. |
| `publication_email`, `email` | Contact addresses declared in a feed. |

## On a post

Engagement, where the publishing platform reports it.

| Key | What it holds |
| --- | --- |
| `reaction_count` | Likes on the issue. |
| `comment_count`, `child_comment_count` | Comments, and replies to comments. |
| `restack_count` | Times it was reshared on the platform. |
| `word_count` | Length. |
| `paywall_status` | Whether the issue was paywalled. |
| `post_type` | What kind of item it is. |
| `is_audio` | Whether it carries audio. |
| `section_name` | The publication's own section, where it uses them. |

## Using them

Ranking coverage by audience size is the common one. Search for mentions, fetch each publication, and sort by `subscriber_count_free` or `apple_chart_ranks`.

Fetching one source per result costs a call each, so scope the search first and fetch only the publications you are going to report on. See [API intro](/docs/api).