Fish Eat Fish

How to Actually Implement Fish Eat Fish Privacy Signals at Scale

Fish Eat Fish is a recursive privacy framework for consumer data. When a user opts out, that signal should travel through every downstream processor, reseller, and data broker in the chain. The concept is straightforward. Making it work in production is another thing entirely. The California Consumer Privacy Act (CCPA) and its amendments have pushed this from theoretical to mandatory. Global Privacy Control (GPC) signals, browser-based opt-out preferences, and the "do not sell or share" flags all feed into the same problem: your data ends up in places you never directly shared it with. Fish Eat Fish addresses the propagation layer.

The Fish Eat Fish Problem

Here is the core mechanic. A user triggers an opt-out on your property. Your data goes to a CRM vendor, a marketing automation platform, a third-party analytics provider, and a handful of data brokers. Each of those entities resells or processes your users' data further down the line. The Fish Eat Fish model requires that the original opt-out signal be recursively enforced at every node. If the first downstream processor sells that data to a second processor, the opt-out must follow. Like a fish eating another fish, the privacy signal consumes whatever version of the data it touches as it moves through the pipeline. In theory this is clean. In practice, the signal propagation breaks down constantly. I spent about eight months building a propagation system for a mid-size e-commerce company that was hitting compliance audits. The system needed to take a GPC signal or a direct opt-out request, normalize it, and push it to roughly forty-five downstream vendors. The straightforward approach would be to maintain a registry and batch-send updates on a schedule. We tried that first. It failed within six weeks because several vendors had their own update cycles and some didn't support batch processing at all.

The workaround was to implement a two-tier propagation model with individual API-level callbacks where supported and periodic reconciliation sweeps where APIs were unavailable. The reconciliation sweep runs daily against a maintained list of known downstream recipients. You query each vendor's privacy center or support channel to confirm the opt-out is active, and flag any discrepancies for manual review. This added about three hours of engineering work per week but caught the drift that batch-only approaches miss.

Setting Up the Signal Normalization Layer

Before any propagation happens, you need a normalization layer. Different signals come in different formats. A GPC header is a single bit. A CCPA opt-out form submission contains structured fields. A "Do Not Sell" checkbox on a partner site might be unstructured text in a support ticket. If you feed these raw into your propagation logic, things get messy fast. Build a schema that maps every incoming signal to a canonical representation. At minimum you need these fields: user identifier (hashed or pseudonymized, never plain PII at this stage), signal type, timestamp, source jurisdiction, and the specific rights being asserted. The timestamp is critical because some jurisdictions have different expiration rules for opt-outs. A California opt-out may need renewal periodically while a Brazilian LGPD request, once granted, does not expire until the user revokes it. One thing beginners consistently miss is that the user identifier needs to be consistent across your entire downstream chain. If you hash with different salts per vendor, the downstream processor cannot match the opt-out to the right user records. Use a stable, salted hash that all vendors can reproduce independently. A simple HMAC with a shared secret works fine here. I learned this the hard way when a vendor complained that fifty percent of our opt-outs were applying to the wrong user accounts. The salts had drifted between our staging and production environments.

Propagation Strategies

There are three main ways to propagate opt-out signals downstream. Each has tradeoffs. The first is synchronous API calls. This is the fastest approach but only works with vendors that expose a privacy API. Most data brokers do not. The ones that do often have rate limits that make bulk operations impractical. We ran into this with a major identity resolution provider. Their API allowed one hundred requests per minute. Our daily opt-out volume during peak periods hit roughly eight hundred distinct requests. We had to implement queue-based throttling with exponential backoff and a retry window of four hours. This meant opt-outs took up to four hours to fully propagate through that vendor alone. The second approach is periodic file-based submission. Many data brokers accept CSV or JSON files via SFTP or secure upload portals. This is slower to set up but more reliable for high-volume propagation. You generate the normalized signal file, encrypt it, and upload on a schedule. The tradeoff is latency. If you run the upload daily, an opt-out submitted at 11 PM won't reach the broker until the next day's batch. That window is where compliance gaps appear.

The third approach is the reconciliation sweep I mentioned earlier. This is not a propagation method per se but a verification method. You use it to catch signals that failed to propagate through the first two methods. Run it at least weekly. Document every check. Auditors will ask for proof that you actively verify propagation, not just that you attempt it. For most organizations, a combination of all three is necessary. Synchronous where possible, file-based for brokers without APIs, and reconciliation sweeps as the safety net.

Tracking the Data Supply Chain

This is the hardest part and the part most companies get wrong. You cannot propagate opt-out signals to vendors you do not know about. Building and maintaining a data supply chain map is not a one-time task. It is a continuous operational requirement. Start with what you can see. List every vendor that receives personal data directly from your systems. This includes CRM platforms, email service providers, ad networks, analytics tools, payment processors, and customer support platforms. Then go a layer deeper. Which of those vendors share data with sub-processors? Those sub-processors may themselves share data further. You need visibility into at least two to three tiers of downstream processing to have meaningful coverage. I recommend maintaining a living document or database with the following fields per vendor relationship: vendor name, category of data shared, purpose of processing, contractual basis (standard contractual clauses, CCPA addendum, etc.), method of opt-out propagation, and last verification date. Update this whenever a new vendor relationship is created or an existing one changes.

Here is a practical tip that most people skip: include the vendor's legal entity name, not just their brand name. "Google" is not a sufficient identifier. It could be Google LLC, Google Ireland Limited, or one of several other entities depending on the service and jurisdiction. Your legal team needs the correct entity to enforce contractual opt-out provisions.

When Fish Eat Fish Does Not Work

There are scenarios where this framework simply cannot solve the problem, and you need to know those limits upfront. The first is data that has already been aggregated or anonymized to the point where individual opt-out signals cannot be applied. If a data broker has sold you a segment report based on fifty thousand users and you try to opt out three of them, the broker cannot remove those three individuals from an already-published aggregate dataset. The signal is moot at that point. This is why prevention matters more than correction. Getting opt-outs propagated before aggregation occurs is the only real solution. The second is data shared through informal or undocumented channels. I encountered this with a company that had a partnership agreement allowing mutual data sharing. The agreement specified that both parties would honor opt-out requests, but there was no technical integration between their systems. When we tried to enforce opt-outs through that partnership, we discovered the partner was passing raw user lists to their own vendors without any opt-out filtering. The contractual promise existed but the operational reality did not. This is common. Contracts alone do not propagate privacy signals. You need technical enforcement mechanisms in place.

The third limitation is cross-border data flows. An opt-out signal propagated within a jurisdiction may not be recognized by processors in other jurisdictions. The EU's GDPR and China's PIPL have different requirements for how opt-out signals must be handled. A CCPA-style opt-out may not satisfy a GDPR erasure request. Build your system to understand which jurisdiction applies to each user and route the signal accordingly. A single canonical signal format will not cover all legal requirements. Finally, there is the issue of data that has already been sold and resold multiple times before your opt-out signal arrives. Fish Eat Fish handles propagation forward from your point of contact. It does not retroactively clean data that has already moved through the chain. If your user's data was sold to a broker six months ago and that broker sold it three more times since then, your opt-out signal will only reach the first broker in the chain. The subsequent buyers may or may not honor it. This is the fundamental limitation of any reactive privacy framework. Prevention through upfront consent management and data minimization is the only way to fully address it.

A Real Implementation Detail

One specific edge case that cost us two weeks to resolve: a major marketing platform was accepting our opt-out signals but applying them to a hashed user identifier that used a different hashing algorithm than our reconciliation system. The reconciliation sweep kept reporting the opt-out as not received, even though the vendor confirmed they had processed it. The mismatch was in the hash function itself. We were using SHA-256 in our normalization layer but the vendor expected MD5 with a specific salt prefix. Once we aligned the hashing configuration, the discrepancy vanished. This is the kind of detail that only shows up during an audit preparation cycle, not during initial implementation. The lesson is to validate the exact technical format every vendor expects before you build your propagation system around assumptions. Get the format specifications in writing. Test with a small sample before committing to full integration.

What to Do Instead When This Fails

If your organization does not have the engineering resources to build and maintain a Fish Eat Fish propagation system, there are alternatives worth considering. Third-party privacy compliance platforms exist that handle signal normalization and propagation for a subscription fee. They maintain vendor relationship databases and handle the reconciliation sweeps internally. The tradeoff is cost and dependency. You are trusting another company to enforce your users' privacy rights. This may be acceptable for smaller organizations that cannot justify the engineering investment, but larger companies typically build in-house to maintain direct control over the process. Another alternative is to reduce the number of downstream vendors entirely. Data minimization is the most effective privacy strategy because it eliminates the propagation problem at the source. If you do not share user data with third-party brokers in the first place, you do not need a Fish Eat Fish system. This is often the hardest recommendation to accept because marketing and revenue teams will push back. But from a compliance standpoint, it is the single most impactful decision you can make. The practical middle ground is to combine targeted data minimization with a focused Fish Eat Fish implementation. Identify the top twenty vendors that receive the most personal data and build full propagation coverage for those. For the remaining longer tail, rely on contractual obligations and periodic manual checks. This approach reduced our maintenance overhead by roughly sixty percent while covering the vendors that mattered most for compliance purposes.

Final Notes on Maintenance

A Fish Eat Fish system is not a set-and-forget deployment. Vendor relationships change. Companies get acquired. APIs get deprecated. Privacy policies get updated. The system needs regular review. I recommend a quarterly audit of your data supply chain map and propagation logs. Flag any vendors where opt-out confirmation has not been received within the expected timeframe. Investigate API failures immediately rather than letting them accumulate. Document every incident and remediation step for audit trail purposes. The goal is not perfection. The goal is demonstrable good faith effort. Regulators and auditors are looking for evidence that you understand where your users' data goes and that you are actively working to enforce their privacy preferences at every stage. A well-maintained Fish Eat Fish system, even with occasional gaps, provides that evidence. A system that was built once and never touched since provides none.