TL;DR: what the Phia allegations mean for merchants
- The gap: Bloomberg reported that Phia's browser extension allegedly opened a background tab during checkout and fired its own affiliate link, overriding whoever actually referred the shopper. None of that appears in a merchant's server logs. The order arrives looking entirely normal, with a valid affiliate cookie attached.
- The evidence: reporters tested the extension across more than 50 sites, and Ben Edelman, the researcher whose work led to the eBay cookie-stuffing prosecutions, reviewed the source code and corroborated three separate features. Phia's average daily revenue reportedly fell from about $80,000 to between $10,000 and $28,000 after they were switched off.
- The decision: you do not need a vendor to check this. Six tests on order and click data you already own will tell you whether a partner is claiming demand it did not create.
Short on time? See cside's real-session third-party script monitoring. It covers the affiliate and coupon tags you load yourself, which is the part of this problem a website can actually control.
Cookie stuffing is affiliate tracking that fires without the shopper doing anything. A legitimate referral requires a deliberate act: someone clicks a partner's link, or applies a coupon it offered, and that action writes a tracking cookie proving the partner introduced the sale. Stuffing skips the person. Software loads the tracking URL by itself, the cookie lands anyway, and the commission follows.
One disclosure before anything else: cside has no telemetry on Phia's extension, and no website can inspect a visitor's add-ons. Everything below comes from published reporting. What we can offer is the part we do know something about, which is how this class of behaviour hides from the people paying for it, and what you can measure without anyone's cooperation.
What Bloomberg reported about Phia's extension
Phia is a shopping assistant founded in 2025 by Phoebe Gates and Sophia Kianni. It compares prices, surfaces discount codes, and earns affiliate commissions on purchases made through it. It raised a $35 million Series A in January 2026.
On 2026-07-09, Bloomberg News reporters Olivia Solon, Priyanjana Bengani and Jeff Kao reported that Phia's mobile browser extension was taking credit for sales it did not drive. They tested it across more than 50 websites. A follow-up on 2026-08-11, drawing on internal Slack messages and a screenshot of an internal dashboard reviewed by Bloomberg, reported that this was not incidental: the behaviour came from features that could be toggled remotely, and the co-founders were aware of them from December 2025.
Three mechanisms were described, plus a fourth that was proposed internally.
| Alleged mechanism | What triggered it | What it overrode | Active window (per Bloomberg) |
|---|---|---|---|
| "enable coupon auto drop" | A background tab opened during checkout, firing Phia's affiliate link | Whichever publisher had actually referred the shopper | 2025-12-10 to 2026-07-07 |
| "passive trigger" | A two-hour timer, on any top-1000 site where the shopper had previously interacted with Phia | Any attribution already present at that moment | 2025-10 to 2026-07 |
| Click-anywhere after the pop-up | Any click on the checkout page once Phia's pop-up had appeared, including clicking to close it | Whatever attribution the session already carried | Not specified in the reporting |
| Drop on dismiss | Clicking the X to close a pop-up | — (proposed internally; Phia says it never launched) | Never launched, per Phia |
The dates matter more than the mechanisms. The "enable coupon auto drop" flag was reportedly live from 2025-12-10 until 2026-07-07, the day Bloomberg first contacted the company. On 2025-12-18, Gates raised a question in Slack about whether Phia was automatically setting cookies across all retail partners even when shoppers had not interacted with the coupon pop-up. On 2026-07-08, Phia said publicly that it had become aware of the situation "within the last 24 hours."
Phia's position, given to TechCrunch: "Any features causing misattributions were immediately removed over a month ago on July 7. We are reviewing every transaction, we are fully committed to and have already begun issuing all transaction reversals to brand partners as a result of any misattribution, and we are hiring a head of compliance to make sure something like this never happens again." As of 2026-08-15 no lawsuit has been filed against Phia and no regulator has taken public action.
Why this costs merchants more than the Honey case did
The obvious comparison is Honey, the PayPal-owned coupon extension accused in late 2024 of replacing creators' affiliate cookies with its own. But as Michael McNerney argued in Adweek, treating the two as the same story misses what makes this one worse for the people paying the bills.
Honey, on the allegations, redistributed a commission that already existed. A shopper arrived through an affiliate, the sale generated one commission, and the argument was over which publisher banked it. Merchants paid the same total either way. Publishers were furious; finance was indifferent.
Forced clicks are different in kind. If tracking fires on a session no affiliate ever touched, the commission did not exist until the software created it. Any shopping session with the extension running can become an affiliate transaction. Affiliate marketing is normally a slice of a merchant's online sales; forced clicks reach across everything the extension can see. That is why Edelman's summary is blunt: "merchants are the victims of forced clicks."
The scale, and what is actually disputed
An internal revenue chart reviewed by Bloomberg shows average daily revenue falling from roughly $80,000 to between $10,000 and $28,000 after the features were disabled in early July 2026. A Phia data scientist estimated in a Slack message on 2026-07-07 that cookie stuffing accounted for about 51% of the merchandise value the company claimed credit for in June 2026, a preliminary figure Phia disputes as based on incorrect methodology that overstated the impact. Phia also says part of the revenue decline came from disabling most monetisation at the same time, not only these features. Adweek and Bloomberg have reported an estimate that Phia may have taken more than $10 million from merchants.
Impact.com, the affiliate network that distributes commissions to publishers, suspended Phia from its marketplace after the first Bloomberg report and has been reallocating commissions attributed to Phia but not yet paid out since 2026-06-20. Phia has begun repaying some commissions to retailers.
What a merchant can see, and what no website can see
Here is the uncomfortable part, and it is worth stating without hedging, because hedging it would be a soft sales pitch.
A website cannot inspect, block, or remove a visitor's browser extensions. Extensions run in the visitor's own browser, outside the page's control. That is a property of how browsers work, not a gap in anyone's product, and it applies to cside exactly as it applies to everyone else. We say so in our own glossary entry on browser plugins and extensions.
So be clear about what could not have been caught. A background tab firing an affiliate URL loads nothing on the merchant's page. A cookie written by extension code leaves no script for page-level monitoring to observe. If the reporting is accurate, no script-monitoring tool on the merchant's site — cside included — would have seen those two mechanisms, and any vendor telling you otherwise this week is selling you something.
What the merchant does have is the outcome. Every forced click leaves a trace in first-party data: a click timestamp, a landing hit, an attribution flip, an order. The mechanism was invisible. The residue is not.
Four layers touched every one of these transactions, and each one saw a different slice of it. Nobody outside the vendor saw the whole thing, which is the structural reason this ran for seven months rather than seven days.
| Stage | Touchpoint | Catches | Misses | Summary |
|---|---|---|---|---|
| Server logs | Your backend | The order; the affiliate cookie attached to it; the order value | Whether a human ever clicked; the background tab; the overwrite | Records the outcome, never the cause |
| Network | Partner side | Reported clicks; commission claims; partner-side totals | Whether the click was human-initiated; the session it landed in | A forced click and a real one look identical |
| Script monitor | Tags you load | Payload changes; new endpoints; cookie writes; redirect chains | Extension code; background tabs; anything your page never loads | Covers your tags, not the visitor's add-ons |
| Session data | Your analytics | Click-to-order latency; attribution flips; dead landings; device-mix steps | The mechanism itself; proof of intent | The residue, which is what you can actually test |

Only the last of those four layers gives you something you can act on, and it is the one nobody sells you, because it is already yours.
Six tests to run on your own affiliate data
None of these need cooperation from the partner or the network. The first five run on data you already hold. The sixth is a test you have to run yourself, and it needs more setup than the others, so treat it as the follow-up once the data tests give you a reason to look.
| Test | What you compute | What implicates forced clicks |
|---|---|---|
| 1. Attribution flip rate | Share of a partner's attributed orders where on-site activity preceded the affiliate click by over 60 seconds | Above 10-15%, and rising |
| 2. Click-to-conversion latency | Distribution of order time minus click time, per partner | A large share under 60 seconds; a p50 under ~5 minutes |
| 3. Clicks without sessions | Network-reported clicks versus matched landing sessions, and engagement inside those sessions | 15-20% unmatched, or a spike in zero-scroll single-pageview landings |
| 4. Implausible ratios | Attributed conversion rate over sitewide; revenue over exposed users; device mix versus baseline | Over 2x sitewide is a question; over 4x at volume is an investigation |
| 5. Commission changepoints | Rolling median and changepoint detection on each partner's attributed revenue | A step change with no matching change in click volume |
| 6. Profile-matrix testing | The same compliance test from clean, aged, logged-in and mobile profiles | Any behavioural difference between profile classes |
1. Was the shopper already on your site?
For every order credited to a partner, compare the affiliate click timestamp against the first on-site event for that session. Count the orders where the shopper was already active more than sixty seconds before the click landed, and where a different attribution already existed.
A genuine referral starts a session. That is what "referral" means. A click that lands in the middle of a session the partner did not start is a flip, not an introduction. Above 10-15% is worth a conversation with your network; a majority means the partner is claiming demand it did not create.
2. How long between click and order?
Per partner, plot the full distribution of order time minus affiliate click time. Report the median and the share under sixty seconds.
Real coupon journeys have a long right tail. People click, browse, abandon, come back the next day. A cookie written at checkout produces a click that is seconds old when the order confirms. Then run a sub-check: for shoppers with three or more clicks from one partner, histogram the intervals between clicks. A spike at a fixed interval is a timer, not a person. The reported passive trigger fired every two hours.
3. Did the clicks become sessions?
Reconcile the click volume your network reports against landing sessions you can actually match. Then, inside the matched ones, count sessions with a single pageview, no scroll, no interaction events, and no foreground signal.
A background-tab fire does reach your landing page, because that is how the cookie gets set. What it never does is become a session a human was looking at. The artifact is not a missing hit. It is a hit nobody saw.
4. Do the ratios make sense?
Three numbers per partner: attributed conversion rate divided by sitewide conversion rate; attributed revenue divided by unique users exposed to that partner; and device mix compared against that partner's own trailing mix.
This is Edelman's stated tell, made computable. As he put it, "with forced clicks, both click-through rate and revenue per user will be implausibly high." Forced clicks convert sessions that were already going to convert, so the numerator grows while the number of genuinely referred shoppers does not. Watch the device split too. The reported behaviour was concentrated on mobile, and extension features ship and toggle per platform, so a twenty-point shift in device mix inside a quarter with no campaign change is a deployment artifact, not a change in how people shop.
5. Does the revenue curve ramp or step?
Run a rolling median and a changepoint detector over each partner's attributed revenue and its share of your attributed orders. Annotate the series with your own promotions and placement changes.
Human affiliate performance ramps. A feature flag steps. A toggle switched on in December and off on 2026-07-07, with daily revenue moving from about $80,000 to $10,000-$28,000, is the shape of a configuration change, and that shape is visible from the merchant side without any inside knowledge. Pay particular attention to a revenue step with no matching change in click volume.
6. Test from profiles that look like your customers
Run compliance testing as a matrix, not a single pass: a clean profile, an aged profile with real purchase history, logged in and logged out, desktop and mobile, residential and corporate network. Never test from an email address or domain associated with your affiliate programme.
Any difference in behaviour between profile classes is itself the finding. You are not looking for a violation. You are looking for a discrepancy — and the next section explains why that is the right thing to look for.
These tests produce questions for your affiliate network's compliance team. They do not produce conclusions about any partner's intent, and you should not present them as though they do.
Why "we installed it and it behaved" is not evidence
Affiliate networks require extensions to stand down: if another affiliate was earlier in the clickstream, don't fire. Compliance teams verify this by installing the extension and watching.
In the ongoing case Wendover Productions v. PayPal, which survived a motion to dismiss on 2026-06-22, plaintiffs allege Honey ran a selective version of that rule. On their account, the extension profiled for compliance testers — checking whether the user was logged into affiliate network sites, looking for particular cookies, for email addresses containing "test", for account age and cashback balance — and behaved correctly for anyone who looked like an auditor, while ignoring stand-down for users who passed its engagement thresholds. Honey's co-founder Ryan Hudson has publicly defended the extension, and these remain allegations.
But look at the shape of the claim, because we have seen it before. In March 2026 cside analysed a typosquatted ad-fraud script injected by a browser extension, impersonating Microsoft Clarity. It checked whether DevTools were open and exited if so, overwrote all seven console methods, and self-destructed its cookie-stuffing iframe after twenty seconds; the server behind it returned 403 to datacenter IPs and AI research tools. Different actor, different target, identical logic: go quiet for whoever looks like an auditor, fire for everyone else.
One distinction is essential and we should not blur it. cside detected that script because the extension injected a <script src> into the page, which put it in front of page-level telemetry. The mechanisms described in the Phia reporting do not load anything on the merchant's page, so the same detection would not apply. What carries across is not coverage. It is the methodology: the reason cside observes script payloads in real browser sessions rather than scanning them from a lab is the same reason a clean-room extension test tells you nothing about what runs for your actual customers. Conditional execution defeats synthetic auditing by design.
That is also why Google rewrote the Chrome Web Store rules in March 2025, after the Honey story. The affiliate ads policy now states plainly: "It is not permitted to inject affiliate links without related user action and without providing a tangible benefit to users," and names as a violation "an extension that continuously injects affiliate links in the background without related user action." The rule was explicit and public before the window described in Bloomberg's reporting opened.
Where script monitoring does apply
The extension layer is outside your control. The tag layer is not, and it fails in the same way.
Affiliate network tags, coupon widgets, and attribution pixels that you load on your own pages are third-party scripts. They update without asking you, and a partner tag that starts writing cookies it did not write last month, or calling an endpoint that was not in last month's payload, is a change you can see. We have written up what happens when an affiliate script is compromised and how traffic hijacking rewrites attribution mid-session.

This is a narrower claim than the headline, deliberately. Monitoring covers the affiliate and coupon tags you load. Extension-side behaviour sits outside it, for cside and for everyone else.
What to do this week
- Run tests 1 and 2 against your top five affiliate partners by attributed revenue. They are the cheapest and the most decisive.
- Pull a twelve-month per-partner revenue series and look for steps rather than ramps.
- Re-run any compliance test you have done in the last year from an aged profile on mobile, and compare it to the original result.
- Inventory the affiliate and coupon tags you load yourself, and check whether any of them changed payload without a release on your side.
- Take anything you find to your affiliate network's compliance team. Route it as a question about attribution, not as a public accusation.
Cookie stuffing is not a new technique, and the precedent is instructive rather than predictive. Edelman is the through-line: nearly two decades ago he documented near-identical conduct by eBay's two largest affiliates. Shawn Hogan took $28 million in commissions and was sentenced to five months in prison, a $25,000 fine and three years of supervised release; Brian Dunning took $5.2 million and was sentenced to fifteen months. Both pleaded guilty to wire fraud. That was a different company, a different decade, and a criminal referral Phia has not received.
What has changed since then is where the code runs. In the eBay case the stuffing happened on a web page an investigator could load. Today it happens inside an extension, on mobile, at checkout, for a subset of users chosen by a remote flag. The residue still lands in your data. You just have to go looking for it.
Related reading
- "Microsoft Clairty" isn't Microsoft Clarity: deobfuscating a typosquatted ad fraud script
- Affiliate hijacking and traffic hijacking: how fraud scripts reroute users
- How compromised affiliate scripts steal online casino revenue
- How web extensions can hurt your site
- Client-side security: how to monitor every browser script








