Signals, Records, Devices: How to Read a Data Feed's Headline Number

One feed can truthfully report billions of signals a day and tens of millions of IDs a day. The two numbers count different things. The first counts rows as they land in storage. The second counts unique identifiers after those rows are collapsed. A third number, identifiers that meet an observation rule, can be no larger than the second. Trouble starts when a buyer compares one supplier's top layer with another's bottom layer. It gets worse when any of the three is read as people. This guide is for data buyers and data-science leads judging location data volume and web-behavior feeds.

What a data feed's headline number counts

A data feed's headline number sits on one of three layers. Supplier labels vary, so ask for the definition rather than trusting the word on the spec sheet.

• Stored records, often called signals or observations. Each stored row adds to the count, even when several rows describe the same underlying event. A phone that reports its position many times an hour produces many rows.
• Distinct identifiers. The number of unique keys that appear at least once, after deduplication across a stated file set and time window. The key might be a mobile advertising ID (MAID), a cookie ID or another identifier. Our glossary entry on the mobile advertising ID covers the main types.
• Threshold IDs. Distinct IDs that meet a stated rule, such as a minimum number of observations in a day. Suppliers often call this layer active or qualified devices. The count alone does not prove how many physical devices sit behind the IDs.

None of the three layers is a count of people. The Interactive Advertising Bureau (IAB) and the Media Rating Council (MRC) draw that line for web measurement. Their Audience Reach Measurement Guidelines, updated in August 2013, classify unique cookies, browsers and devices as machine-based measures. Unique users are the people-based measure. The guidelines say a measurer must not present machine-based counts as people-based counts. They also require the basis of a unique measure to be disclosed on the report or through a prominent link from it.

The MRC applies the same idea to location. Its Location-Based Advertising Measurement Guidelines, issued in March 2017, state that a measure labeled unique requires de-duplication. They limit the word "unique" to records de-duplicated within the entire reporting period. They also ask vendors to disclose whether a location is a point-in-time observation or a derived home location. The MRC standards list shows both documents still on its measurement shelf.

Why gross record counts repeat events

Gross record counts are large because collection is repetitive. A phone on a desk can report the same coordinates again and again. An app can retry a failed upload, so one event can land twice. A single page view can generate more than one request. Repeated observations can be expected. Retries and duplicate deliveries still need checking against the feed's counting rules.

A row count still has real uses. It sizes storage and estimates ingest cost. It also lets you compare a delivered total with an expected total.

Here is what that looks like on real feeds. The table below sets out the headline figures for two GSDSI feeds. The data operations team has confirmed twice that the location feed carries about eight billion signals on a typical US day. These are records as stored, not people and not unique devices.

The web behavior rows show the gap between layers inside one delivery. The team's definition sheet says "records are counted as stored, including repeated events." Distinct counts are deduplicated across all files. The record counts and the distinct count describe the same day of the same feed. They sit far apart because they count different things.

These are two separate feeds with different identifiers and collection methods. Never add or average them. Never compare a location signal count with a web record count as if they measured the same thing.

A worked example of signal, ID and device counts

A worked example makes the layers concrete. The toy sample below has two people and three physical devices over one day. One phone resets its advertising ID at midday. One upload is retried, so a single event is stored twice. The observation rule is at least three observations in the day.

The same toy sample supports five honest headlines: the signal count, the unique event count, the ID count, the active device count and the people count. The threshold count matches the device count only by coincidence. ID 3 drops out, and IDs 1 and 2 are the same phone. Change the rule to two observations and the threshold count rises above the real device count. That is why the rule belongs in writing.

Why monthly ID counts can exceed the population

Monthly ID counts above a country's population look like inflation, and sometimes they are. A large count does not prove it on its own. Identifiers are not people, and several mechanisms raise the number of IDs tied to one person.

• IDs get reset. Android developer documentation describes the advertising ID as unique, user-resettable and user-deletable. A handset that resets its ID mid-month can appear as two distinct IDs that month.
• Cookies churn. The cookie standard, RFC 6265, notes that user agents often evict cookies because of memory pressure or privacy concerns. It also says browsers should let users delete cookies. A deleted cookie returns as a new ID.
• People carry more than one device. One person can use a phone, a tablet and a work laptop. Each can contribute its own identifiers.
• The window is longer. A monthly distinct count accumulates every ID seen on any day of the month. Daily distinct counts cannot be summed into it, and dividing it by the number of days does not recover a daily count.

So a monthly count above population is a prompt to ask about the unit, not proof of fraud. For audience planning, distinct IDs over the campaign window usually fit. For visit analysis, a threshold can help screen histories, since a single observation is rarely enough to establish a visit.

How to ask for a count definition and partition date

A count definition turns a marketing figure into something you can audit. Get it in the supplier's own words. Check that it names the identifier type, the files included and the deduplication window. A data dictionary that lists each field and its fill rate makes this easier.

Ask for the partition date as well, and the time zone that partition uses. A partition cut at midnight UTC covers different hours from one cut at midnight Eastern. Align the boundaries before comparing counts. A single partition is a snapshot. Ask whether the number describes a typical day or one chosen day, and request consecutive partitions if stability matters.

Ask what type of identifier sits in each ID field, too. The IAB Tech Lab's OpenRTB 2.6 specification defines the device field "ifa" as an ID sanctioned for advertiser use in the clear, normally from an operating-system advertising API. A separate flag carries the platform's limit-ad-tracking signal. A feed built from bid requests should say which of those fields it counted and how it treated limited devices.

Percentages need the same care. In the web behavior partition dated 2026-10-12, about half of cookie records carry a MAID. That is a share of records, not a share of distinct cookie IDs. It is also not a match rate against your file. A cookie ID that appears many times in a day is counted many times in that share. If linkage matters, ask for the share of distinct IDs that carry the second identifier. Our note on why vendor match rates are not comparable explains the denominator problem in detail.

Why counting identifiers does not make data anonymous

Identifier counts can sound anonymous, and regulators reject that reading. FTC technology staff wrote in July 2024 that a hashed identifier still creates a unique signature that can track a person or device over time. The same post says data is only anonymous when it can never be associated back to a person. A persistent advertising ID behaves the same way.

Enforcement on location data has turned on where records came from, how they were collected and what was kept. Those are the questions a careful buyer asks about a headline count anyway. Our sensitive-location guide for data buyers covers the regulator sources and diligence questions. None of this is legal advice for your situation.

Five count questions for a data feed statement of work

A statement of work (SOW) is where count definitions should live, so they survive staff changes on both sides. Put these five questions in it and keep the answers.

1. Which layer does each headline number count: stored records, distinct identifiers of a named type, or identifiers that meet a stated observation threshold?
2. Across which files and over what window is deduplication done, and which partition date and time zone does each number come from?
3. Are repeated events, retries and duplicate deliveries kept in the record count, and is there a field that identifies them?
4. For any device or active count, what is the threshold (minimum observations, minimum days seen), and can we rerun it on our sample?
5. For every percentage, what is the denominator (records or distinct IDs), and will it be recomputed for each delivery period?

Then test the answers against counts the supplier reports for the same sample files and window. Count stored rows, deduplicate the stated ID field and apply the agreed rule. A sample tests the method. Reproducing a full-feed total needs the full counted dataset.

The same habit applies to coverage by country, which our international coverage matrix turns into tests. It also applies to panel-based web data, where clickstream panels have their own scale and bias trade-offs. Teams using these counts in cross-channel measurement should carry the definitions into the study documentation before reporting any reach figure.

How to read a feed's headline number before you compare

A feed's headline number is only comparable once you know its layer. A big signal count says the feed is busy. A distinct ID count says how many keys it touches over a window. A threshold ID count says how many keys meet a stated rule. None of them is a head count, so name the layer before comparing it with anything else.

If you are evaluating a location or web behavior feed, bring your use case and the window you care about. Talk to GSDSI's team about a sample with its count definitions attached, so your analysts can reproduce the counts reported for that sample.