For 3 Years, a Game Sent Your "Number" Out: How Identifiers Leak From App Tracking Tags, and How to Prevent It

A smartphone game you'd played for over three years had been quietly sending a "number" that identifies you to an outside advertising system — and it took three years and ten months for anyone to notice.

On July 13, 2026, LY Corporation (LINE Yahoo) announced and apologized that, across three games including "LINE Pokopoko," information identifying users had been mistakenly transmitted to an external advertising tool — about 7.1 million records. Many people are puzzled here: "What leaked wasn't a name or a phone number, but a string called an 'internal identifier.'" So why is this a problem? And with no attack involved, how does one company's misconfiguration keep users' information flowing outward for over three years?

Using that case as an entry point, this article works through two more universal questions — "why does user-identifying information leak from an app's 'tracking tags'?" and "how do you prevent this 'unintended data transmission' in development?" — from a hands-on app and analytics-infrastructure perspective. So it reaches both ordinary players and the developers who build apps, every technical term comes with a one-line plain explanation.

What happened — identifying data flowed from three games for 3 years 10 months

First, the disclosed facts in order. All of the following is based on LY Corporation's official announcement, with no speculation added.

The sequence is simple. Transmission to the external advertising tool began on May 25, 2022; LY Corporation discovered the problem and began investigating on April 1, 2026, and completed a fix to stop the transmission on April 3. In other words, for about three years and ten months, identifying information that should not have been sent was automatically transmitted from users' devices. The total was about 7.1 million records; the actual number of users, excluding duplicates, was about 6.1 million (of which about 5.74 million were in Japan).

Crucially, this was not an external attack (unauthorized access). LY Corporation explains the cause as follows: when the settings of the external advertising-measurement tool were changed, an "internal identifier" that should not be sent was automatically transmitted from users' devices, and this happened because setting verification was insufficient at both the company and its partner. It wasn't stolen by an attacker — they had, by their own hand, put it into a "send" configuration. That is the essence of this case, and the point we dig into from the next section. Note that the external tool provider has already deleted the information, and no unauthorized use or secondary damage has been confirmed (all per the official announcement).

What is an "internal identifier" — why is it a problem without names or phone numbers?

This is where many get stuck. What leaked was not a name, address, phone number, or credit card number, but a random string called an "internal identifier." And yet it's news, and the company apologizes. Why? Resolving this apparent contradiction is the heart of this article.

An internal identifier is a "jersey number" assigned to a user

An internal identifier is a jersey-number-like string a service assigns to tell users apart within its system. LY Corporation explains it as "a random string for identifying an individual user within the system, distinct from the LINE ID used for adding friends." By itself it's an inert symbol like "12345…," and looking at the string alone tells you nothing about who the person is. That's why LY Corporation says it is "highly anonymous, and this data alone cannot be connected to a specific individual by an external third party" (official statement).

The problem arises not from "alone" but from "cross-matching"

So why is it a problem? The danger of a jersey number appears not alone, but the moment it is cross-matched with other information. If the same identifier is reused across multiple services and apps, it enables "linking" (bundling separate data as belonging to the same person) — tracing "who did what, when, in which app" across services. In advertising especially, a "number that follows a person across apps" has value. When an identifier passes to an advertising system as it did here, it creates the groundwork for unintentionally tying a user's behavior together. Each string looks harmless, yet gather and cross-match them and a person's outline emerges — which is why identifiers are handled carefully in privacy protection.

To be clear, LY Corporation states that no actual harm has been confirmed in this case, and the recipient has deleted the data. So it would be inaccurate to fan fears that "damage occurred." But "no confirmed harm" and "data that should never have been sent flowed for over three years" are two different things. What this article puts center stage is the latter — why it happened, and how to prevent it.

Why information leaks from "tracking tags" — how app analytics works

Now to the first universal theme: why does identifying information leak from an app's tracking tags? Modern apps and web services almost all measure usage. Doing that measurement are tracking tags / SDKs (small components embedded in an app that collect behavioral data and send it to external analytics and advertising tools; "tag" is the web term, "SDK" the app term).

A tracking tag decides "what to send" by configuration

A tracking tag decides, by configuration, "which fields to send" from the user's device to the advertising/analytics tool. Even if you only mean to send screen views and clicks, changing one setting can cause fields that need not be sent — such as the internal identifier — to be sent along too. LY Corporation's explanation of "insufficient verification when settings were changed" is exactly this. Because transmission happens automatically on the device, once it's in a "send" state, it keeps sending quietly until someone notices and stops it. There's no dramatic trace like an attack leaves.

A "distributed senders" design makes the accident hard to see

Another structural weakness is that transmission flies directly from each user's device to the external tool. This method (client-side measurement) is convenient but makes it hard for the provider to grasp "what is actually going out." By contrast, routing through your own server first and selecting what to send there before passing it outward (server-side measurement) lets you control and audit transmission centrally. As covered in our guide to server-side tag management (server-side GTM), "holding in your own hands what goes out" is an effective design move for preventing this kind of unintended transmission.

Why it went unnoticed for 3 years 10 months — a data-governance problem

The heaviest part here is the duration. Not days or weeks, but three years and ten months. Why was it overlooked so long? Here you can see a structural problem common to many organizations: "the flow of data is not fully managed."

LY Corporation also explains that the fact of this transmission was not recorded in its own privacy center (the official description that explains data handling to users). In other words, "data that shouldn't have been sent was being sent, without even being recorded." This is not a mere setting error; it means the overall picture of "which data we send, where, and why" (data mapping) was not being kept up to date. Without an inventory of destinations, you can't notice when an extra field creeps in. Without a mechanism to check "the diff of transmitted data" on each setting change, the change slips through silently.

Preventing the same accident in development — a practical checklist

This is the practical core worth rereading months from now. To prevent "unintended data transmission," here's a list ordered by impact and feasibility. You can't do everything at once — start from the top, with what you can.

• 1.Build a "destination × field" inventory (data mapping). List which tracking tags/SDKs send which fields to which external tools. Without it, accidents stay invisible forever. It's the foundation to build first.
• 2.Review the "diff of transmitted data" before applying setting changes. When you change a tag's settings, always verify before release whether the data actually going out has changed. This is the one point that slipped through here.
• 3.Don't send "unnecessary fields" like identifiers by default (minimization). Send only the fields genuinely needed for measurement via an allowlist, and block sensitive fields like internal identifiers by default. "Let only what's needed through" fails safe.
• 4.Create a "checkpoint before it goes out" with server-side measurement. Instead of sending directly from the device to the outside, route through your own server and control and log what's sent there. Server-side tag management is effective for centralizing transmission.
• 5.Audit the actual traffic regularly. Beyond "what the settings say," measure the traffic leaving a device in a test environment and periodically check for unexpected fields. Gaps between config and reality only show up if you go look.
• 6.Keep your privacy descriptions consistent with reality. Always reflect the data you send in the official description, and eliminate any "sending it though it's not in the description" state. Cross-checking against the description is the last net for catching inventory gaps.

The idea at the root is privacy by design (building data protection into the design from the very first stage of a service). Rather than "inspect later," make the structure such that "nothing extra goes out in the first place." Measurement is essential to business, but the data you may collect and the data you may pass outward are different — holding that line as a design principle is the conclusion of someone who has watched data flows in practice.

What should users do — what you can do, and what to worry about

Finally, for ordinary players. For this case, there is no particular action users need to take (official). What leaked was a random internal identifier, with no names, passwords, or payment information; the recipient has deleted the data, and no misuse has been confirmed. There's no need to rush to change passwords.

That said, as a more general mindset, it's worth knowing that free apps and services almost all measure user behavior to some degree and send it to external analytics and advertising tools. This time an "accident" got mixed into that transmission, but even normal measurement sends a certain amount of data outward. If it concerns you, use your phone's advertising-identifier reset and tracking limits (iPhone's "Ask App Not to Track", Android's advertising-ID settings) to curb cross-app tracking somewhat. Rather than blaming one specific app, it's more realistic to "assume your behavioral data is being sent somewhere, and hold on to the parts you can control."

Conclusion — the incident is the "entrance," the lesson is the asset

The LINE Pokopoko case will fade as an individual news item. But the two questions it posed don't go stale: "why does identifying information leak from an app's tracking tags?" and "how do you prevent that unintended transmission?" The former is answered by understanding the mechanism that "settings decide what gets sent"; the latter by the unglamorous operations of data mapping, diff review, minimization, server-side measurement, and regular audits — all of which you can start today.

With no attack at all, identifying information flowed for over three years. Whether these quiet, undramatic accidents can be prevented comes down to whether, in peacetime, you know "which data you're sending, and where." Collecting, and passing outward. Building that line into your design is the surest first move to stop the next "quiet accident."

FAQ

Update log

• 2026-07-14First published. Using LY Corporation's mis-transmission of identifying data across three games (~7.1M records) as an entry point, we explain how information leaks from tracking tags and how to prevent it in development.
• PlannedWe'll add follow-ups on any report to the Personal Information Protection Commission, regulatory response, and further explanations from LY Corporation as they emerge.

References

• ▸LY Corporation notice and apology (official announcement, JP)
• ▸LY Corp: 7.1M game customer identifiers leaked via mis-sent identifiers (Nikkei, JP)
• ▸LY Corp mis-sent 7.1M identifiers, affecting LINE Pokopoko and other game users (ITmedia NEWS, JP)
• ▸LINE sent identifiers for ~6.1M users externally over 3y10m (Sumaho!!, JP)
• ▸Guide to server-side tag management (server-side GTM) — this site