We mask every IP address before it reaches the database

An IP address is one of the most useful signals in mobile attribution and one of the most sensitive pieces of data you can hold. It narrows a device to a network, often a household. Under the Nigeria Data Protection Act and under GDPR it is personal data.

The usual approach is to store it in full, use it freely for matching and fraud detection, and rely on retention policy to eventually delete it. We do something different: every IP address is truncated before it is written, and the full address is never persisted anywhere.

What actually happens

Three entry points receive a client IP address: event ingestion, the deep link redirector, and the historical data importer. All three call the same masking function before any database write.

IPv4 addresses lose their final octet. An address in 203.0.113.0/24 is stored as exactly that network, and every device behind it is indistinguishable in our records.

IPv6 addresses are truncated to their first three groups, a /48 block.

An address we cannot parse, or a request that arrives without one, is stored as a placeholder network rather than null, so downstream code does not need a special case for missing data.

The masked value is what gets written. The full address exists only in memory, for the duration of a single request, and is never logged.

What it costs

This is not free, and it would be dishonest to present it as a pure win.

Fingerprint matching gets weaker. The IP address is one component of the device fingerprint we compute server side. Truncating to a /24 means every device on the same network block contributes an identical component. In a shared office or a campus, fingerprints collide more often than they would with full addresses.

We handle that by penalising rather than pretending. When a fingerprint match connects a click and an install that share the same masked block, the confidence score drops by ten points. The match is still reported, but it is reported as weaker, because it is weaker.

Fraud detection gets coarser. Our IP velocity rule counts clicks per network block per minute. With full addresses it would count clicks per device. A busy corporate network can trip the rule through ordinary use, and a fraudster with addresses spread across several blocks is harder to catch on this signal alone.

That is why velocity is one signal among several rather than a blocking rule on its own. Every flag records the values that triggered it, and nothing is blocked automatically without a human decision.

Why we took the trade

Three reasons, in order of how much they mattered.

A /24 is enough for the job. The matching value of an IP address in attribution comes almost entirely from network level correlation: did this install come from the same network as this click. The final octet adds precision we rarely need and risk we always carry.

Data you do not hold cannot leak. The strongest guarantee about a piece of personal data is that it was never written down. Retention policies fail, backups outlive their schedules, exports go to the wrong place. Truncation at the point of ingestion removes all of that.

It makes the privacy documentation honest. We can state plainly that no raw end user IP address exists in the platform, and that statement is checkable by reading three call sites. A policy that says "we retain IP addresses for ninety days" requires you to trust an operational process. This one requires you to read a function.

What masking does not solve

Truncating IP addresses does not make us not a data processor, and we do not claim otherwise. We still hold advertising identifiers, device fingerprints, device models and operating system versions. Under GDPR and the NDPA, an advertising identifier is personal data regardless of what we do with IP addresses.

Masking is one control among several. It is worth doing precisely because it is cheap, permanent and verifiable, not because it changes our regulatory position.