Best known for technology news web sites, CNET also provides comparison shopping tools—its namesake “CNET Shopping” as well as a similar tool called PriceBlink. Both tools say they save customers money by finding coupons, rebates, and lower prices. But both tools also violate rules about what user interface elements can be affiliate links. And both tools monetize through multiple affiliate accounts, including sometimes bouncing traffic through multiple unrelated sites (“traffic laundering”), undermining accountability and oversight.
Affiliated “Close” button
When CNET Shopping sees a user at a product detail page, it checks several sources of alternative sellers of the same product. If it finds no lower price, it declares “You’ve found the best price!”
If a user clicks the “Close” button, CNET Shopping opens a small new tab, loads the merchant in an affiliate link, and then immediately closes the tab. Video. Example merchant in the video is Belk, which CNet Shopping promotes via CJ.
CNET might seek shelter in the disclosure “When you buy after clicking on CNET Shopping, we may earn a commission.” Three problems with that argument. First, and most fundamentally, disclosure to users cannot cure violation of a rule that protects merchants. Tellingly, affiliate network policies disallow affiliate links on Close buttons, offering no exception based on user disclosure. 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 [shopping assistant] 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.” Awin’s COC also incorporates the IAB UK’s downloadable software code of conduct, which says “a consumer must be made aware if an action taken … will cause that consumer to be redirected to a website.” When the only way to close a popup is itself an affiliate link, that’s a “force[d] click” (CJ), it’s not “knowing” (Rakuten), it’s neither “voluntary” nor an “interact[ion] with the Ad Media” (Awin), and the consumer is not “made aware” of the consequences of the click (IAB UK).
Similarly, Google requires “related user action … before the inclusion of each affiliate code, link, or cookie.” Google specifically criticizes invoking affiliate links “when no discount, cashback, or donation is provided”—precisely the situation at issue.
Second, the disclosure appears only when the user’s mouse enters the window. See video at 0:13 (no such message when the window appears) and 0:17 (message appears only upon mouseover). CSS source code confirms the on-hover visibility (setting #pb-popup.disclosure-text to display:none), and making it visible (display:block) only upon :hover. This matters because a user receives the popup with no disclosure visible—then decides to click it, and begins mousing to the Close button, before the disclosure appears.
Third, the disclosure is in tiny type: 10 point, with grey type (RGB #5e5e62) on a grey background (CSS hsla(0,0%,77.3%,.1)). This format and color are easily overlooked.
Combine these factors, and users are particularly unlikely to notice. I genuinely did not notice the disclosure the first few times I saw CNET’s “found the best price” window. I read the full window when it appeared, and I did not consider rereading it after moving my mouse into the window. Small grey-on-grey text did not alert me to the possible need to reread.
For a merchant, the harm is acute. This user was already on the product page, considering a specific product. CNET Shopping did nothing to encourage the user to buy—did not offer a lower price, did not even offer a coupon. The traffic is particularly unlikely to be incremental.
Code review
To confirm my observations, I reviewed CNET Shopping source code. First, the CNET Shopping extension asks a server whether it should affiliate the Close button. The server’s optional response affiliate_close_click_url (yellow) is what activates this functionality:
https://shopping.cnet.com/api/v1/final-prices.php?n=910&browser=chrome&partnerid=1
[{… "affiliate_close_click_url":"https:\/\/shopping.cnet.com\/api\/v1\/rdr.php?d=1&f=7417&t=7417&sp=18&id=…&uid=...&partnerid=1&afsrc=1&origin=aff_close&url=https%3A%2F%2Fcnet-shopping.digidip.net%2Fvisit%3Furl%3Dhttps%253A%252F%252Fbelk.com%26ref%3DPQRST"… }]
When the user clicks the Close button, the extension checks affiliateCloseClickUrl (yellow), and if it’s present, invokes function openCloseAffiliateUrl() (red). Then openCloseAffiliateUrl() compares the last click time plus 60 minutes, versus the current time, and invokes the affiliate link only if enough time has elapsed (blue).
if (popupData?.affiliateCloseClickUrl) { openCloseAffiliateUrl(popupData?.affiliateCloseClickUrl) } async function openCloseAffiliateUrl(affiliateUrl) { const nowTime = (new Date).getTime(); const offsetTime = 60 * 60 * 1e3; // 60 minutes const affiliatePCClicked = `affiliatePCClicked${window.cnetShopping?.retailer?.id}`; const isAffiliatePCClicked = await storageGetPromise(affiliatePCClicked); if (affiliateUrl && (!isAffiliatePCClicked || isAffiliatePCClicked && Number(isAffiliatePCClicked) + offsetTime < nowTime)) { popup_browser.runtime.sendMessage({ action: "openCloseAffiliateUrl", url: affiliateUrl }); allStorageSet({ [affiliatePCClicked]: (new Date).getTime() }); } }
Two aspects of this code hinder testers trying to figure out what is occurring. One, the affiliated Close button is gated behind a server setting, allowing the server to disable the behavior per user, session, or merchant. Two, the affiliated Close button happens only once every 60 minutes per merchant.
Affiliated “X” from PriceBlink
I observed substantially the same behavior from PriceBlink, a shopping extension CNET acquired in 2022. For PriceBlink, the button to close a window is an “X” rather than the word “Close”, but otherwise network transmissions and client logic are much the same.
A representative transmission from the PriceBlink server:
https://tb.priceblink.com/final-prices.php?n=307&browser=chrome&partnerid=0
… "affiliate_close_click_url":"https:\/\/tb.priceblink.com\/rdr.php?d=1&f=7417&t=7417&sp=89&id=…&uid=…&partnerid=0&afsrc=1&origin=aff_close&url=https%3A%2F%2Fcnet-shopping.digidip.net%2Fvisit%3Furl%3Dhttps%253A%252F%252Fbelk.com%26ref%3DPQRST" …
Multiple monetization paths
Testing CNET Shopping, I was struck by its multiple monetization paths. CNET Shopping uses different affiliate IDs for coupons (sometimes via its own accounts, sometimes via lengthy chains as discussed in the next section) versus cashback (whitelabeled from Wildfire). Thus a merchant that wants to study its payments from CNET Shopping needs to look, at best, in two different places. A merchant that sees a direct relationship with CNET Shopping would logically (but incorrectly) conclude that line-item is the entirety of its spending with CNET Shopping.
The same issue arose with Phia, which had both direct and indirect relationships with merchants. Merchants that saw low traffic on the direct relationship risked concluding, incorrectly, that they had low spend with Phia.
Traffic laundering from CNET Shopping
CNET Shopping’s indirect monetization includes long and complex chains to merchants. This is fairly characterized as “traffic laundering” in that merchants cannot know, and do not know, what traffic they are paying for.
As of October 2026, I found 12,656 coupons available through CNET Shopping. 3,506 (28%) have five or more redirect steps in the redirect chain from CNET Shopping through to the merchant. A representative long chain: From CNET Shopping to Digidip to Rapidlinks.info to Shoptastic to Rewardsany (nominally a cashback site) to Linksprf.com to Coontx to Revoffers to Impact to apparel merchant Tillys.com. When traffic reached Tillys, a tag labeled the source as utm_content=Katalys_2258022. (Katalys is the rebrand of Revoffers.) Nothing in the traffic chain disclosed the long chain of intermediaries.
In a second representative chain, CNET Shopping sent traffic to Digidip to VigLink (Sovrn Commerce) (with loc= parameter disclosing origin of getinvisiblehand.com, the prior branding of the extension now known as CNET Shopping), which redirected to Rtbcl, Shopping123, Linksprf (Srvtrck powered by Yieldkit), Salegains.com, Fatcoupon, Rakuten, and finally Sixt rental car. Again nothing in the traffic chain disclosed the long chain of intermediaries.
These long chains of intermediaries make it easy for each participant to blame the others. But consider VigLink/Sovrn, appearing in 5,600/12,656=44% of CNET Shopping’s coupon redirect chains. (Compare Skimlinks in “just” 1,507 or 12% of the redirect chains.) VigLink/Sovrn holds itself out as optimizing traffic to find the most valuable way to monetize. but it’s doubtful that proper optimization includes a redirect chain bouncing through six further intermediaries en route to a merchant. With each intermediary taking a cut, such a long path yields correspondingly less value to the source. From the source’s perspective, the main benefit of a long chain is that it conceals and monetizes traffic the merchant was not willing to pay for—but for a merchant, that’s nothing to celebrate.
Other oft-observed redirect paths include companies widely viewed as traffic origins not brokers. I observed 497 CNET Shopping coupons (4%) that monetize through Savings.com, and 280 (2%) through Bravodeal. Merchants who pay for traffic from Savings.com and Bravodeal probably intend to reach users who are genuinely browsing those sites, but in fact they’re also getting users who have a CNET Shopping extension redirecting through those domains.
Does traffic laundering break affiliate network rules? It’s hard to point to a relevant rule for most networks. But Awin’s rules incorporate IAB UK rules that instruct “An Affiliate making use of downloadable software must use all
reasonable endeavours to provide Advertisers with reasonable advance
notice of its intention to use downloadable software.” An affiliate violates this requirement when it (1) pays others to put its links into downloadable software, and also (2) does not tell the merchant that it is using downloadable software. An affiliate that pays others to put its link somewhere, not knowing whether the ultimate placement is downloadable software versus something else, is probably not using “all reasonable endeavours” to alert merchants to its practice.
Traffic laundering from PriceBlink
Preliminary review of PriceBlink coupons indicates overlapping inventory with CNET Shopping. Indeed, where CNET Shopping gets coupons from a server endpoint https://shopping.cnet.com/api/v1/coupons?rid=1749&uid=…&browser=chrome&ver=14.33&partnerid=1&code=1&ab=webravoTest (substituting rid= with each merchant’s ID), PriceBlink uses https://tb.priceblink.com/coupons?rid=1749&uid=…&browser=chrome&ver=9.18&partnerid=0&code=1&ab=webravoTest – not just an identical URL pattern, but also, in my testing, one-for-one identical results, which would mean identical redirect chains.
Recommendations
The narrow version of remediation is straightforward. Close and X should do what they say, and are no basis to invoke affiliate links. CNET Shopping should monetize via simple direct relationships. Networks should redouble their efforts to check more carefully and more often.
Fixing unaccountable redirect chains is more difficult. I’m reminded of the mess that adware companies created when they monetized through traffic marketplaces and long chains of directs. (20 examples I published en masse in 2012, among scores of others.) I’m working on further automation to explore shopping extensions improperly bouncing traffic through redirect chains. For now, affiliate program managers need to be wary: Shopping extensions monetize not just through affiliate accounts with names merchants recognize, but also through concealed redirect chains that launder the extension traffic to make it look like something else entirely. Even a diligent manager, who rejects applications from extensions applying in their own names, may nonetheless end up buying unwanted extension traffic masquerading as something else.
In my view, networks are overdue to stop traffic laundering. This summer James Little and I proposed that extensions “must use direct links that are associated with an affiliate account operated by the same legal entity marketing the software”—ruling out one level of subnetworks, and certainly ruling out nested subnetworks and redirect chains. Reasonable people might question our recommendation. I see a case for allowing extensions to use one level of subnetwork for their smaller relationships (perhaps those earning less than some threshold amount in the past 12 months). But there is no place for traffic bouncing through half a dozen relationships—a tactic that serves only to reduce accountability.
I wrote last week about aspects of affiliate marketing I value and applaud. High on my list is a merchant’s ability to easily exclude any publisher it doesn’t want to work with—for any reason or no reason; by simply clicking a button, without needing lawyers or a cease-and-desist letter. These are big advantages over goliath ad platforms, and they are the core of accountability in affiliate marketing. Merchants should reject CNET’s indirect relationships and complex traffic chains as undermining accountability.