Understanding Your Metrics

Every number in your Noise dashboard and in the Reporting API comes from the same definitions, explained here. All metrics are grouped by UTC day.

The core metrics

• Posts: approved posts, counted on the day the post was created. Posts that have not passed content review (or were rejected) are never counted.
• Creators: unique creators behind those approved posts. Uniqueness is computed over whatever period you are looking at, so creators for a month is not the sum of the daily values: a creator who posts every day counts once for the month.
• Views: new views recorded that day across your approved posts, regardless of when the posts were created. This is a daily incremental measure: a post created last week that gained 10,000 views today contributes 10,000 to today, not to last week.
• Spend: your cost in USD, counted on the day it was billed. You are billed as views land, so spend follows views, not post creation.

One post therefore shows up on three different time axes: it is counted in posts on the day it was created, accrues views for days or weeks afterward, and generates spend as those views land. This is deliberate, and it is why the three numbers for a single day are not describing the same set of posts.

CPM

CPM is your cost per 1,000 views:

cpm = spend / views × 1000

It is always computed from the totals of the range you are looking at, never stored or averaged. Two consequences:

• A range CPM is not the average of its daily CPMs. The range CPM is total spend divided by total views, which weights busy days more.
• Daily CPM is noisier than range CPM. Spend and views are dated independently, so on any single day the billed spend does not line up exactly with the views recorded that day. Over a week or a month the two converge. If a single day's CPM looks off, check the range CPM before concluding anything.

Installs

If your brand has an installs source, your dashboard and reports include daily app installs:

• First-party store data: if you have connected App Store Connect or Google Play under App Store Integrations, installs come straight from the store for that platform.
• Estimated: otherwise, installs are a third-party SensorTower estimate for your linked apps.

The two are merged per platform and per day: first-party data wins for every day it covers, and the estimate fills any remaining days (including history from before you connected the store). The installs_source field (and the tile hover in the dashboard) tells you which contributed: store, estimated, or mixed (both did, across platforms or days).

Install numbers are org-wide per day. They cannot be split by campaign or playbook, because a store does not know which campaign drove an install.

Freshness and restatement

• Views, spend, posts, creators: data lags real time by roughly 5 minutes.
• Installs: store reports are produced daily, and stores revise recent days as their reporting finalizes (Apple documents completeness within about five days). Noise re-pulls the trailing window every day, so install figures for the last several days can shift slightly before settling. Estimated installs are similarly restated as SensorTower refines recent estimates.

If today is part of your selected range, expect today's numbers to be partial: the day is still accumulating. The v2 dashboard marks the in-progress day with a dashed line for exactly this reason.