MAID-to-HEM Linkage Counts: Why Unique MAIDs and Unique HEMs Differ by Country

Most confusion about linkage data starts with one question: how many people is that? The file does not say. A linkage delivery counts identifiers and the joins between them. Before you compare two countries or budget against a row, you need the unit and the window behind each number. This guide is for data and identity teams receiving an international feed. It uses GSDSI's own October 2026 delivery as the worked example.

Three units in a linkage file, and none of them is a person

A linkage file holds three units, and each answers a different question. A MAID is a mobile advertising identifier. The iOS developer documentation describes the advertising identifier as a string unique to each device and notes it can return all zeros. A HEM is a hash derived from an email address. Whether two HEMs match depends on the normalization and hashing rules used. A linkage pair records an association between one MAID and one HEM. Whether a pair was directly observed or inferred is something the delivery documentation has to tell you.

Those definitions already explain why the counts drift apart. A person using a phone and a tablet with one email can contribute two MAIDs and one HEM. A shared family tablet with three signed-in accounts can contribute one MAID and three HEMs. The identity graphs primer covers how these joins feed household resolution. Here the point is narrower. The figure shows how the three units relate.

How advertising ID resets and permissions change MAID counts

Advertising ID behavior on the device decides how many MAIDs a month of data can contain. The Play Console help describes the Android advertising ID as a unique, user-resettable and user-deletable ID for advertising. The Android developer guide adds a detail that matters for counting. On devices that support several users, including guests, an app can obtain different advertising IDs on the same device. The same guide tells apps not to cache the value, because the user can reset it at any time.

The iOS model starts from permission. On iOS 14.5 and later, an app needs tracking authorization before it can read the advertising identifier. The App Tracking Transparency framework provides that request. The advertising identifier documentation says the value is either a unique UUID or all zeros. Exclude all-zero values when counting valid MAIDs, instead of counting them as one giant device. Ask how the delivery handles resets and opt-outs. Those choices can change the unique MAID count when the relevant records are present.

• A reset inside the window can turn one device into two MAIDs.
• A multi-user Android device can expose one MAID per user profile.
• Withdrawn tracking authorization can affect later identifier availability. Whether earlier records remain depends on the delivery's deletion and retention rules.
• Zeroed IDs should be filtered, not deduplicated into a single value.

How HEM normalization changes hashed email counts

HEM normalization is the cleanup applied to an email address before it is hashed. The email guide in the IAB (Interactive Advertising Bureau) Tech Lab documentation repository lists the steps. It removes leading and trailing spaces, converts uppercase to lowercase, and then applies SHA-256. For one named webmail domain, the guide also removes dots from the part before the @ sign, and removes a plus sign and the characters after it up to the @ sign. Those rules belong to that specification, so use the one the delivery names. Its own example shows a mixed-case address producing a different hash before and after lowercasing.

That behavior follows from what a hash is for. The federal Secure Hash Standard describes digests that are used to detect whether a message has changed. The standard notes that any change to a message will, with a very high probability, produce a different digest. Even one capital letter counts as a change. Sources that normalize differently can therefore produce different hashes for the same address. That can raise a distinct HEM count and lower matches against your own file. Applying the same normalization again leaves an already normalized address unchanged. Matching hashes also require the same hash algorithm, encoding and any salt. The glossary entry on SHA-256 normalization covers the common steps in one place.

Why one country shows more HEMs and another more MAIDs

The country table below is the October 2026 monthly delivery, as counted by GSDSI's data operations team on the delivered files. It reports unique MAIDs and unique HEMs for the twelve countries shown, each counted on a dated monthly partition. It does not report pair counts.

Several forces can push a row one way or the other. A count alone cannot tell you which one is at work. Several devices per person and advertising ID resets can raise distinct MAID counts when those observations are collected. Shared devices and several email accounts per person can raise distinct HEM counts when those associations are collected. Collection matters as much as behavior. Email capture that is strong in one market and device coverage that is strong in another can tilt a country's ratio. Treat the direction of a row as a question for the provider about that delivery, not a finding about the market.

Why you cannot add or compare country rows blindly

Country rows look additive, but their sum is a different kind of number. For the October 2026 monthly delivery, as counted by GSDSI's data operations team on the delivered files, adding the per-country counts for unique MAIDs and unique HEMs gives a sum of rows, and GSDSI does not publish that sum as a total. The sum counts identifiers within each country and may count the same identifier in more than one country. Unless the delivery states its dedup scope, assume a device seen in two countries during the month can appear in both rows. A traveler's phone counted in Singapore and Malaysia is one device and two row entries.

Windows break comparisons too. When one period contains another and the same records, filters and dedup rules apply, the longer period cannot hold fewer distinct identifiers. Identifier churn can make counts differ from one window to the next. The device graph decay post covers how that churn plays out. Comparing a monthly row from one delivery with a longer-window row from another mixes window effects with any real difference between countries. The same logic sits behind why vendor match rates are not comparable. Different denominators produce different numbers from the same reality.

How to recount a MAID-to-HEM delivery yourself

A recount checks reported counts against the delivered files. Choose a first partition by file size and record volume. In the October 2026 monthly delivery, as counted by GSDSI's data operations team on the delivered files, pick the smallest row you can find in the table. Its counts do not establish file size or pair volume. After the first partition, check others for cases it does not contain.

1. Load only the files listed for that country and partition date, and record the file paths you used.
2. Drop empty and all-zero advertising IDs, then count distinct MAID values.
3. Check that every HEM has the expected length and encoding, then count distinct HEM values.
4. Count distinct MAID and HEM pairs using the documented validity filters. Report that count separately from the two identifier counts.
5. Group by MAID and by HEM to see how many links each identifier carries. A long tail of heavily linked identifiers deserves a question.
6. Compare your distinct counts with the stated row. Ask about any gap before the feed reaches production.

Totals need one extra check. The rows in the October table are rounded to one decimal place, and the rounded rows do not add exactly to any total built from them. Ask for unrounded per-country counts before you reconcile a total or build a forecast on one. A recount does not establish whether links were observed or inferred. Request pair-basis metadata and documentation of the evidence used to create the links.

A worked example: reading a MAID-to-HEM ratio

Take any single row in a delivery and divide its unique MAIDs by its unique HEMs. A result above 1 means more MAIDs than HEMs in that window, and a result below 1 means more HEMs than MAIDs. Treat the result as a property of that row's counting rules, not as a ranking of countries, because each row can reflect a different mix of resets, shared devices and hashing rules.

A MAID-to-HEM ratio compares distinct identifiers within the stated window. It does not describe the distribution of links. Ask for links-per-identifier distributions before you plan onboarding in either market. The ratio cannot tell you how a particular seed list will expand or shrink after a join. It also cannot tell you how many devices an email-keyed campaign can reach.

The ratio also leaves people coverage, link accuracy and your own match rate unanswered. The figure shows why: 3 MAIDs over 2 HEMs is 1.5, while 4 pairs over 2 HEMs is 2, and neither number counts devices in anyone's hand. A ratio near 1.0 does not mean one-to-one links. Pair counts and links-per-identifier distributions describe the structure of a device graph. A test against your own records measures matching under stated conditions. Estimating people or link accuracy needs separate methods and validation.

What a MAID-to-HEM delivery should state

A delivery contract should name every field that decides how a count was made. The table below is the checklist we use when reviewing a linkage feed. Treat each row as a question to settle before the first file lands.

Recount at least one country from the delivered files against that list. The MAID-to-HEM identity graph page describes the product this guide applies to. Teams using linkage for cross-channel measurement should carry the counting unit into their study documentation. The match rate glossary entry explains why a join result needs its denominator stated too.

Why a hashed email is still an identifier

A hashed email is still an identifier, and regulators describe it that way. The FTC's Office of Technology explained in July 2024 that hashing still doesn't make your data anonymous. Its reasoning is that hashes can still identify users and support tracking over time. California's privacy statute, in the CPPA's posted text of the Act (August 2024), lists mobile ad identifiers among its examples of a unique identifier. The same section defines pseudonymization separately from deidentification.

None of that is legal advice, and permitted use depends on your contracts and jurisdiction. The practical point is simpler. Handle linkage files under the same access, purpose and retention controls you apply to other identifiers. Take questions about permitted use to your own counsel.

Read every count with its unit, window and scope attached. If you want to test country rows against your own records, send your target markets and window to GSDSI's team to scope a per-country linkage sample.