A multipoint is a collection of point observations that are counted or aggregated together but do not describe one coherent shape the way a polygon does — an hour of bid requests, a week of store visits, a month of conversions. Each observation is a member of the points family individually; what makes this a distinct geometry family is the aggregate: the questions asked of a multipoint (how many observations per cell, how many distinct entities, what's the density) are different from the questions asked of any single point, and answering them correctly depends on getting deduplication and suppression right before the count is ever reported.
- Cardinality
- A variable-size set of observations over a window, not one shape
- Governed by
- The aggregation window and deduplication logic applied, not an external authority
- Not a geometry
- A device or cookie id — the audience is the aggregate of resolved points
- Converts via
- Per-observation point-to-cell, then dedup, count, and suppress at the cell level
Members
| Member | What each observation represents | Typical volume |
|---|---|---|
| Audience observations | A device or cookie's recorded presence | Millions per market per period |
| Bid requests | An ad-exchange auction event's location field | Very high volume, high duplication risk |
| Store visits | A resolved visit-to-POI event | Moderate volume, tied to a dwell/visit model |
| Conversions | A purchase or app-event location | Lower volume, often the measurement target |
| Event observations | Any other logged occurrence with a coordinate | Varies by source |
Required metadata
| Field | Why it's required |
|---|---|
| CRS | Standard normalization requirement shared with all point-based geometries |
| Per-observation timestamp | Needed to define the aggregation window and detect staleness within it |
| Deduplication key | Without one, the same impression or visit can be counted more than once per cell |
| Entity identifier (where privacy-permitted) | Distinguishes "10 observations from 1 device" from "10 observations from 10 devices" — a materially different audience signal |
Common risks
Duplicate observations are the dominant risk: the same impression, visit, or conversion logged more than once — from retries, multi-source ingestion, or an upstream join fanning out — inflates the count or audience size attributed to a cell, and the effect compounds with volume, since high-volume feeds like bidstream data are also the ones most prone to duplicate delivery. A dedup key plus a time window is the standard defense; without one, "volume per cell" silently becomes "volume per cell times an unknown, non-uniform duplication factor," which corrupts any comparison across cells with different duplication rates. Sparse-cell suppression follows once the multipoint is aggregated: a cell with very few distinct observations risks re-identifying the individuals behind them, and must be suppressed or rolled up to a coarser resolution rather than reported as-is — this is the same minimum-aggregation requirement that governs device pings and trajectories, applied at the aggregate rather than the individual level. Entity-vs-observation conflation is a related but separate error: reporting raw observation counts as if they were unique-entity counts overstates audience size whenever any entity contributes more than one observation in the window, which is the common case, not the exception.
There is no boundary to this family the way there is for a polygon — "the geometry" of a multipoint is entirely a function of which observations were included, over what time window, after what deduplication. Two multipoints built from the identical underlying event stream but different windows or dedup logic are not comparable cell-for-cell, even though both are legitimately "the same audience."
How it converts to H3
Each observation converts individually with the same latLngToCell
mechanics as point to H3; what differs at the
multipoint level is what happens after conversion — grouping by cell,
deduplicating within the window, counting distinct entities rather than raw
rows, and applying sparse-cell suppression before the aggregate is
reported. See privacy and minimum aggregation
for the suppression thresholds, and
conversion quality metrics for how
duplication and suppression should be surfaced alongside the resulting
per-cell counts rather than left implicit.