Checklist
Tracking pixel vs cookie: what still ran after Reject All?
A pixel is a request; a cookie is stored data. On one Shopify store after Reject All, Clarity still sent a collect call without writing _clck or _clsk.
In brief
A tracking pixel is a request the page sends to a vendor. A cookie is a value the browser stores and sends back later. After Reject All on Store J, a Shopify store with a OneTrust banner, those two things came apart. Microsoft Clarity loaded its tag and sent one /collect request in each Reject run, and none of Clarity's cookies appeared. TikTok's Shopify app pixel kept sending events that carried the _ttp cookie it had set before the click. Meta and Google sent no requests and set no cookies. A cookie list taken after Reject would show TikTok, and would show nothing at all for Clarity. We ran one Accept run and two Reject runs on October 15, 2026, from a US connection. It is the same capture as our Rebuy after Reject page, impact.com after Reject page and Searchspring after Reject page. This page sorts those requests by whether a cookie was involved.
What we ran
- Store J: Shopify with a OneTrust banner (Accept All, Reject All and Cookie Settings on the first layer). Store letters are per-page labels; the same letter on another page can be a different store.
- Chrome Guest window, recorded with
chrome://net-exportin raw-bytes mode from before the first page load. The first page request in each run had no cookies. - Path after the click: home page, product page, collection page. Reject run 2 also reloaded the home page after the click and loaded more pages, so compare which hosts appear, not totals.
- Before any click, OneTrust stored
C0001:1, C0002:0, C0003:0, C0004:0. Reject All kept C0002 to C0004 at 0.
Requests and cookies after the click
| Vendor | Accept | Reject run 1 | Reject run 2 | Vendor cookies after Reject |
|---|---|---|---|---|
| Microsoft Clarity | 31 | 3 | 4 | none (_clck, _clsk only after Accept) |
| TikTok | 8 | 8 | 11 | _ttp, ttcsid set before the click, still sent |
| Klaviyo | 88 | 4 | 8 | none (__kla_id only after Accept) |
| Meta | 9 | 0 | 0 | none (_fbp only after Accept) |
| 49 | 0 | 0 | none (_ga, _gcl_au only after Accept) | |
| Meta + Google + Klaviyo + Clarity total | 177 | 7 | 12 |
Requests with no cookie: Microsoft Clarity
After Accept, Clarity sent 21 /collect POSTs to y.clarity.ms and set _clck and _clsk, plus its own third-party cookies such as MUID. After Reject, the Clarity tag loaded 2 times in run 1 and 3 times in run 2, and each run sent one /collect POST, to g.clarity.ms and m.clarity.ms. No Clarity cookie appeared in either Reject run. We did not decode what the /collect request carried.
This capture does not show why Clarity skipped its cookies here. Shopify's consent fields still read true after Reject on these visits. Our Microsoft Clarity after Reject All page found the same split at a larger scale on a different store (Store C on that page): _clck and _clsk were gone, and one product page sent 23 /collect POSTs.
Requests that carried a cookie set before the click: TikTok
TikTok's app pixel set _ttp on the home page before any choice. While OneTrust's C0004 was still 0, it sent Pageview, LandingPageView and EnrichIpv6. After Reject, it sent the same events it sent after Accept: Pageview and ViewContent on the product page, Pageview and collection_viewed on the collection page. Run 2 added a Pageview from the reloaded home page. That came to 8 requests in run 1 and 11 in run 2.
In both Reject runs, context.user.anonymous_id equaled the _ttp cookie and did not change across the click. external_id equaled Shopify's shopify_client_id cookie. Rebuy and impact.com did the same thing with other cookies on the same visits. Rebuy's rsid equaled _rsession, and impact.com's CustomProfileId equaled shopify_client_id. That last case is a cookie from one party (Shopify) sent inside another party's (impact.com) request body.
A script download with no event: Klaviyo
After Reject, klaviyo.js loaded 4 times in run 1 and 8 times in run 2. No request went to a.klaviyo.com/onsite/track-analytics, which received 7 after Accept, and __kla_id never appeared. A host list would still show Klaviyo after Reject. The endpoints show only the script download.
Neither request nor cookie: Meta and Google
Meta's hosts received 9 requests after Accept and 0 in both Reject runs. Google Tag Manager, GA4, Google Ads, DoubleClick and Merchant Center received 49 after Accept and 0 in both Reject runs. _fbp, _ga, _ga_* and _gcl_au appeared only after Accept. Server-side paths such as Meta's Conversions API do not show in the browser; our Meta CAPI after Reject All page covers that split.
Together, Meta, Google, Klaviyo and Clarity went from 177 requests after Accept to 7 and 12 after Reject.
A cookie written after Reject: Searchspring
Searchspring wrote ssUserId, ssSessionId and ssViewedProducts on the first product page after the click, and its product-view request carried the ssUserId value. It did the same after Accept. Details are on the Searchspring after Reject page.
What a cookie-only check would have shown
After Reject on Store J, the cookie jar held _ttp, ttcsid, _rsession, shopify_client_id and the Shopify cookies set before the click. It held no Clarity, Meta, Google or Klaviyo cookie, and we saw no request that deleted a cookie. The Network panel showed Clarity, TikTok, the Klaviyo script, Rebuy, impact.com and Searchspring still sending. A cookie list would have caught TikTok and Rebuy through their cookies, and would have shown no trace of Clarity's /collect requests. Does a cookie audit catch tracking pixels? explains which surfaces an audit has to record to see both.
Why this can happen
Store J's Shopify analytics requests after Reject reported "analytics_allowed": true and "marketing_allowed": true in every payload that carried the fields (8 in run 1, 11 in run 2). No _tracking_consent cookie appeared. The log does not show the OneTrust choice reaching Shopify, so tools that read Shopify's consent, such as TikTok's app pixel, kept running. Meta and Google stopped. Shopify Customer Events vs the Customer Privacy API covers how Shopify passes consent to app pixels.
Check your own store (5 minutes)
- Open a Guest or Incognito window, open DevTools, tick Preserve log, then load the store's home page.
- In Application > Cookies, note which tracking cookies exist before you click anything.
- Click Reject All, then open a product page.
- In Network, filter for
clarity,tiktok,klaviyo,facebookandgoogle. For each request, open Headers and Payload: does it send a cookie, or an ID that matches a cookie value? - Compare the two lists. A host in Network with no cookie, and a cookie in Application that rides along in a request body, are separate findings.
If a Google request after Reject carries a denied consent state and no _ga, read Consent Mode ping vs real tracking before you call it a tracking event. Our Reject All still tracking check shows what an after-Reject record holds, and the Shopify Reject All guide collects results from other stores.
FAQ
What is the difference between a tracking pixel and a cookie?
A pixel is a request from the page to a vendor. A cookie is a value the browser stores and sends back. On Store J after Reject All, Clarity sent requests without cookies, and TikTok sent requests that carried a cookie set before the click.
Can a tracking pixel send data without a cookie?
Yes. On Store J, Clarity sent one /collect POST in each Reject run while none of its cookies existed.
If no tracking cookies appear after Reject All, has tracking stopped?
Not on Store J. Clarity's cookies were absent and Clarity still sent /collect. impact.com sent page loads keyed to Shopify's own cookie.
Does Reject All delete cookies that were already set?
On Store J we saw no request that deleted a cookie. _ttp stayed and TikTok kept sending its value.
Did Meta and Google stop after Reject All?
On Store J, yes in the browser: 0 requests in both Reject runs and no _fbp, _ga or _gcl_au.
Limits
One store on one day: one Accept run and two Reject runs, from a US connection where OneTrust started with C0002 to C0004 off. Page paths differ between runs. We did not decode Clarity's /collect body, log in, add to cart, or call the Shopify consent API in the console. We see what left the browser; we cannot see what Clarity, TikTok, Meta, Google or Shopify stored on their servers. Not legal advice.
Sources
These links cover the platform and regulatory context used in this guide. Applicability still depends on the organization and jurisdiction.
Save a US-baseline technical record
After a DIY check, run a free US-baseline audit: one browser visit outside California, with cookies, requests, and screenshots stored as evidence. That visit does not run EU reject/accept or California GPC. EU, California, and Global 2 audits can be purchased from Billing after sign-in.