Forced Clicks and Stand-Down Violations by Shopping Plugin Phia

I’ve recently been looking at multiple forms of misconduct by Phia, a fast-growing shopping plugin.  I’m troubled by what I found, and even more troubled by Phia’s misleading public statements about these practices.  Based on my hands-on testing, code review, and other investigative methods, Phia appears to be materially out of compliance with network and merchant agreements.  Networks, merchants, and rule-following affiliates should be concerned, and in my view, all three groups have strong claims against Phia.

Forced clicks

The basic bargain of affiliate marketing is simple: an affiliate earns a commission only if it presents an offer, the user clicks, and the user purchases.  Network rules make clear that shopping plugins, like all other affiliates, are only allowed to invoke affiliate links—setting the cookies and other tracking codes that claim commission—if a user actually clicks an affiliate link.

See the CJ Publisher Service Agreement: “Software may not be used to force clicks [or] perform redirects without an affirmative click by a user”.  Rakuten Affiliate Network Policies: “The DSA must not force clicks or ‘cookie stuff’. The DSA must not insert a cookie onto the user’s computer without the user knowingly taking an action.”  Awin Code of Conduct: “Publishers only initiate tracking via a tracking link used for click tracking if the user voluntarily and intentionally interacted with the Ad Media or Tracking link.”

This is arguably the most fundamental rule of affiliate marketing.  Almost two decades ago, I caught Shawn Hogan and Brian Dunning invoking affiliate links, and thereby claiming commission, without users clicking.  I reported this to eBay, which told the FBI, leading to criminal charges for wire fraud, breach of contract, RICO, and more.  Both men ultimately served jail time.  Details.

Phia appears to be doing much the same thing.  Phia’s iOS app and Chrome plugin both include a setting called enable_coupon_auto_drop that, when active, automatically invokes affiliate links without user action, most often when a user is at a merchant’s shopping cart or check-out page.  See this iOS test video, showing the affiliate link invisibly loaded into a second tab.  (In the video, at 0:05, the tab switcher window screen is opened so viewers can see the second tab loading, but normal users would have no reason to do this.)

Notably, Phia activates the “auto_drop” setting via a “feature flag” that allows server-side control of which devices receive forced clicks (yellow).  In my testing, this feature is always turned off for Chrome users.  But if a user-agent header references iOS (green), the feature flag server replies in the affirmative (blue).  Change the user-agent to a different value, while keeping everything else the same, and the feature flag becomes false.

curl -X POST \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" \
  -H "STATSIG-API-KEY: client-..." \
  -H "STATSIG-SDK-TYPE: javascript-client" \
  -H "STATSIG-SDK-VERSION: 3.31.0" \
  -H "Content-Type: application/json" \
  -d '{"user":{"userID":"...","platform":"IOS_SAFARI_EXTENSION",
              "appVersion":"1.10.26","platformVersion":"1.10.26"},
       "hash":"djb2","statsigMetadata":{"sdkType":"javascript-client","sdkVersion":"3.31.0"}}' \
  'https://featureassets.org/v1/initialize?k=client-...&st=javascript-client&sv=3.31.0&...'

  → HTTP 200, hash_used: djb2
  → derived_fields.browserName = "Mobile Safari"
  → derived_fields.osName      = "iOS"

  → feature_gates["3845139938"]   // decodeable to "enable_coupon_auto_drop"
    {
      "name": "3845139938",
      "value": true,

Thus, a user who tests only on desktop would never see these forced clicks. In my experience, many affiliate fraud testers test desktop only. That explains why this wasn’t promptly noticed.

Phia first shipped this feature in version 1.9.33 of its app, published on December 13, 2025.  Nonetheless, Phia told Bloomberg “a recent release our codebase was causing misattributions from a subset of users.”  I disagree that the problem was limited to “a recent release” of Phia.  There have been numerous intervening releases, making it difficult to characterize this as a problem confined to a single recent release (as Phia’s “a release” claims).  The feature appears to have persisted for roughly seven months, including the 2025 holiday shopping season—a significant period with real economic consequences

In remarks to industry bloggers Kris and Sarah, Phia downplays the forced clicks as a “bug.”  That characterization is difficult to reconcile with the evidence.  Phia intentionally built and shipped a feature which they themselves call “auto_drop” and which does what it says.  In no context in affiliate marketing is it ever permitted to “auto drop” an affiliate link and automatically set affiliate cookies.  Deliberately building and deploying a feature called “auto_drop” that automatically sets affiliate tracking — this cannot be dismissed as a mere bug.  It’s intentional, and it violates both trust and contract.

Consequences of forced clicks

It’s well-known within affiliate marketing that many users don’t click on affiliate links.  Suppose the click-through rate, when users are asked or encouraged to click, is 20%.  A publisher that fakes clicks gets a 5x increase in monetizable traffic, with no change to cost, yielding a disproportionate increase in profit.

Merchants are the main victims of forced clicks, which compel merchants to pay affiliate commissions on traffic they should have gotten at no charge (thanks to their reputation or SEO) or no additional charge (having already paid for SEM or other marketing).  When I advised merchants about fraud detection and remediation, my standard recommendation was to require rule-breaking affiliates—especially those who forced clicks—to pay back every penny they had taken, plus the costs of investigation (lawyers, experts, and more).  Multiple recoveries reached seven figures.

Stand-down violations

A second set of affiliate network rules pertains to who gets the marketing commission when multiple affiliates were involved (or claimed to be involved).  Let’s be specific.  Suppose a user clicks a NYT Wirecutter link recommending (say) Polaroid.com.  But on a computer with Phia installed, there’s an obvious risk: After a user puts a new camera in her cart, Phia can pop open, present its affiliate link, and claim it should get the commission.  But NYT incurred real costs (journalist salaries, health insurance, and office space), while Phia’s costs are minimal.  Furthermore, NYT was the genuine cause of the purchase, the actual first step in the user’s decision-making.  From a merchant’s perspective, a substantive product recommendation from NYT is far more valuable than a last-minute shopping-plugin intervention.  If Polaroid doesn’t protect NYT’s interest, NYT—and other high-quality publishers like it—will instead review, test, and recommend products from sellers that give them reasonable confidence in getting paid.

Fortunately there’s no need to resort to some amorphous sense of fairness to protect publishers from shopping plugins taking credit at the last minute.  To the contrary, networks and merchants for years have embodied these ideas in governing contracts.  CJ: “non-interference with competing advertiser/ publisher referrals”.  Rakuten: “Software Publishers must recognize and Stand-down on publisher-driven traffic.”  Details in my January 2025 write-up about Honey at heading “The contracts that bind Honey.”

I found it surprisingly easy to uncover examples of Phia not standing down.  In my first test session, I clicked a Savings.com link to Polaroid, added an item to my cart, and immediately got a Phia offer that, when clicked, invoked Phia’s affiliate link.  Video.

A particularly surprising aspect of my Savings.com-Polaroid-Phia test scenario is that Phia not only tracked the link I had clicked (yellow), but also watched the redirect chain (green), and explicitly recognized that I had clicked an affiliate link (blue).  From Phia’s /events telemetry immediately after the Savings.com link:

POST https://p.phia.com/events HTTP/1.1
Host: p.phia.com
...
{"eventName":168,"eventProperties":{"finalUrl":"https://www.polaroid.com/en_us/film?irclickid=QsFVXMyFfxyZR9d1lV0pGwW6UkuQ%3A9QPPWguSM0&sharedid=&irpid=10851&utm_medium=affiliate&utm_source=Savings.com%20.&irgwc=1&afsrc=1","matchedUrl":"https://polaroid.pxf.io/c/10851/2112974/24813?subId1=809258334-46-678567891459&u=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Ffilm","network_id":"unknown","domain":"www.polaroid.com",
"chain":["https://www.savings.com/m/offer?offerid=14626284","https://polaroid.pxf.io/c/10851/2112974/24813?subId1=809258334-46-678567891459&u=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Ffilm","https://www.ojrq.net/p/?return=https%3A%2F%2Fpolaroid.pxf.io%2Fc%2F10851%2F2112974%2F24813%3FsubId1%3D809258334-46-678567891459%26u%3Dhttps%253A%252F%252Fwww.polaroid.com%252Fen_us%252Ffilm%26level%3D1&cid=24813&tpsync=yes&auth=5ab2153b89b0c662","https://polaroid.pxf.io/c/10851/2112974/24813?subId1=809258334-46-678567891459&u=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Ffilm&level=1&brwsr=c81dd3a8-7776-11f1-9f75-554d085a42bf&brwsrsig=X%3A5TVmU4gVwtT4JQk70%3AXxo2y6UQlY","https://www.polaroid.com/en_us/film?irclickid=QsFVXMyFfxyZR9d1lV0pGwW6UkuQ%3A9QPPWguSM0&sharedid=&irpid=10851&utm_medium=affiliate&utm_source=Savings.com%20.&irgwc=1&afsrc=1"],
"os":"WINDOWS","phiaId":"...","osVersion":"10","platformVersion":"1.10.26","timestamp":"2026-07-04T07:05:49.491Z","deviceType":"PC","platform":"CHROME_EXTENSION"}}

HTTP/1.1 202 Accepted
{"status":"success","message":"Event EVENT_TYPE_AFFILIATE_COOKIE_COMPETITOR_DETECTED queued successfully"}

Despite recognizing “competitor” savings.com having invoked an affiliate link and set an “affiliate cookie” (blue), Phia nonetheless set its shouldStandDown status to false (yellow):

GET https://api.phia.com/whitelist/validate?url=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Fcameras&phiaId=1474393b-f7e7-4c25-9bff-affcfcbf10e2 HTTP/1.1
Host: api.phia.com
…

HTTP/1.1 200 OK …

{"isWhitelistedPage":true,"isProductPage":false,"shouldFirePageView":true,"shouldShowTopOfPage":false,"numImagesToScrape":1,"topOfPage":{"shouldShow":false,"ctaMessage":""},"showExtensionOnStandDown":true,"standDown":{"shouldStandDown":false,"shouldTakeover":false,"affiliateType":0,"decisionTtlSec":0,"featureSurfaces":[{"feature":1,"canShowSurface":true},{"feature":2,"canShowSurface":true},{"feature":3,"canShowSurface":true},{"feature":4,"canShowSurface":true}],"cookieSources":[{"source":1,"canPlaceAffiliateCookie":true},{"source":2,"canPlaceAffiliateCookie":true},{"source":3,"canPlaceAffiliateCookie":true},{"source":4,"canPlaceAffiliateCookie":true},{"source":5,"canPlaceAffiliateCookie":true},{"source":6,"canPlaceAffiliateCookie":true},{"source":7,"canPlaceAffiliateCookie":true},{"source":8,"canPlaceAffiliateCookie":true},{"source":9,"canPlaceAffiliateCookie":true},{"source":10,"canPlaceAffiliateCookie":true},{"source":11,"canPlaceAffiliateCookie":true}]}}

Then Phia did not stand down, as the video shows.

Consequences of stand-down violations

Stand-down violations are the core of ongoing litigation against Honey and others.  The same concern applies to Phia: Every dollar Phia takes through stand-down violation is a dollar that would otherwise flow to another publisher.  No wonder publishers are furious.

Reflections

There’s more to be found in Phia’s codebase, and more to be found in hands-on testing.  But I’ll stop here, for now, as to the substance of Phia’s misconduct.

Phia’s statements to Bloomberg and industry bloggers Kris and Sarah raise additional concerns.  “Phia has been reviewed and verified as compliant across the affiliate networks we work with,” they told Kris and Sarah.  I’ve never seen a network offer any kind of certification of compliance — at most they can say they didn’t find problems, but they can’t know what they didn’t find.  At most, affiliate-network review can fail to detect violations; it cannot certify their absence, and failure to catch a violation does not mean no violation occurred. Did affiliate network staff test the right scenario in the right way?  Did they test on iOS, not just desktop?  Did they test stand-down scenarios?  How many staff, with what experience, tested for how long?

Meanwhile, just as Honey conceals its practices to prevent network staff from uncovering its misconduct, Phia’s violations sit behind servers that can condition behavior on a user’s shopping history, browsing history, IP address, device type, and more.  When I recently drafted a model COC, I disallowed that tactic, instead requiring that key shopping-plugin decisions be made within the browser extension without consulting a server, a rule designed to make behavior more predictable.  See proposed rule 9.3 paragraph 3.  It is particularly unconvincing for Phia to claim networks did not uncover violations when Phia’s architecture makes violations difficult to detect.

A related concern is that Phia often participates in affiliate marketing as a subaffiliate, rather than establishing relationships directly with merchants.  When Phia’s traffic is merged with other subaffiliates, patterns of misconduct—like traffic spikes, implausible conversion rates, and implausible timing—become more difficult for a merchant or even a network to uncover.  Hence my recommendation that shopping plugins operate only through direct merchant relationships—see my model COC, proposed rule 5.2.

So many recent problems in affiliate marketing generally, and in shopping plugins specifically!  Much remains to be done to restore integrity to affiliate marketing, ensure that rule-following publishers are paid for the value they create, and give merchants confidence that they are paying only for genuine incremental value.