Checklist

Does Searchspring tracking stop after Reject All on Shopify?

Start a free audit

On a Shopify store with OneTrust, Searchspring's pixel sent a product view after Reject All and wrote its visitor ID cookie. Shopify's docs explain why.

In brief

On Store J, a Shopify store with a OneTrust banner, Searchspring's Shopify pixel kept working after Reject All. In every run, the first product page after the click sent one product-view event to analytics.searchspring.net and one personalization request to Searchspring's preflight endpoint, the same 2 requests we saw after Accept All. Both carried a visitor ID that the page had written into the ssUserId cookie on that product page. Store J's Shopify consent fields still read true after Reject, and Shopify's pixel manager loads an app pixel when those fields allow it.

What we ran

We ran one Accept run and two Reject runs on October 15, 2026, from a US connection. This is the same capture as our Rebuy after Reject page and impact.com after Reject page; this page covers the Searchspring and Tolstoy requests.

  • Store J: Shopify with a OneTrust banner (Accept All, Reject All and Cookie Settings on the first layer). Store letters are labels for this page only.
  • Chrome Guest window, recorded with chrome://net-export in 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 right after the click and went back to the home page before the collection page.
  • Before any click, OneTrust stored C0001:1, C0002:0, C0003:0, C0004:0. Reject All kept C0002 to C0004 at 0.
  • We did not use the store's search box, so no search or autocomplete requests appear in these runs.

What Searchspring sent after Reject All

Searchspring requests, before and after the click
Searchspring requestsAcceptReject run 1Reject run 2
Searchspring requests before the click000
product-view POSTs after the click111
preflight POSTs after the click111
userId equals ssUserIdyesyesyes
ssUserId values after it was written111

The product-view event went to analytics.searchspring.net/beacon/v2/{siteId}/product/pageview. Its body had userId, sessionId, pageLoadId, the page URL, the currency, and the product's parent ID, variant ID and SKU. Its initiator field named Searchspring's Shopify pixel. The preflight request sent the same userId with lastViewed, the SKU of the product on screen.

userId matched the ssUserId cookie and sessionId matched ssSessionId in all three runs. lastViewed matched ssViewedProducts. Each run kept one ssUserId value from the product page to the end of the log, including the collection page.

The home page and collection pages sent no Searchspring requests in any run, before or after the click. Searchspring's pixel code loaded on the home page before the click, but it sent requests only from the product page.

When the Searchspring cookies appeared

ssUserId, ssSessionId and ssViewedProducts first showed up on the product page, written by script on the page (no Set-Cookie header). That happened the same way after Accept All. In all three runs the visitor reached the product page only after clicking, so this capture has no product page from before a choice. After Reject All, the page wrote all three cookies anyway. Searchspring's cookie documentation lists ssUserId with a 1-year expiry and ssViewedProducts with 7 years. An empty ssCartProducts cookie was already present on the home page before the click.

Tolstoy on the same product page

Tolstoy's video widget loaded its scripts and settings on every page. Its analytics endpoint, analytics-v2.gotolstoy.com/event, received 2 events on the product page in each run, pageView and embedView, and none before the click. That held after Accept and after both Rejects. Each event carried an anonymousId and a sessionId generated by Tolstoy, the page URL and the product ID. The name, email and phone fields were empty.

Tolstoy's developer documentation says the widget follows Shopify's analytics consent and blocks analytics only when that state is "no". On Store J, Shopify reported analytics as allowed after Reject, so the Tolstoy events match what its docs describe for that state. The events left from Tolstoy's own frame, so we could not see where anonymousId is stored or whether it lasts beyond the visit.

Why this can happen

Store J's page configuration listed Searchspring as a Shopify app pixel that requires analytics, marketing and sale-of-data permission. Shopify's Pixel Privacy documentation says the pixel manager loads an app pixel only when the visitor has given every permission the pixel declares.

On Store J, Shopify's own 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), with gdpr_enforced and ccpa_enforced both false. No _tracking_consent cookie appeared in any run. The log does not show the OneTrust choice reaching Shopify, so Shopify kept treating the visitor as allowed and loaded the pixel. TikTok and Impact behaved the same way on these visits. Shopify Customer Events vs the Customer Privacy API covers how Shopify passes consent to app pixels.

What the docs say to configure

Steps are from Searchspring's, Tolstoy's, Shopify's and OneTrust's official documentation; we have not verified each one.

  • Searchspring's Shopify pixel is switched on and off in the Searchspring Management Console, under Data Feed, with Enable Tracking and Remove Tracking. Searchspring's documentation says its tracking feeds reporting and personalized recommendations.
  • Shopify loads an app pixel only when the visitor has granted every purpose the pixel declares, so the pixel follows whatever Shopify's Customer Privacy API reports.
  • OneTrust's Shopify documentation says its Shopify app writes the banner choice into Shopify's Customer Privacy API through the Consent Mapping step. Check that step if Shopify still reports consent after Reject.
  • Tolstoy follows Shopify's analytics consent when the Customer Privacy API is present. Its docs also describe a tolstoy_reject_cookie_policy message and a tolstoy-cookie-policy localStorage value for stores that manage consent themselves.
  • Searchspring's cookie documentation recommends setting ssUserId and ssSessionId as soon as a shopper arrives.

Check your own store (5 minutes)

  1. Open a Guest or Incognito window, open DevTools, tick Preserve log, then load the store's home page.
  2. Click Reject All, then open any product page.
  3. In the console, run Shopify.customerPrivacy.currentVisitorConsent(). Note the analytics and marketing values.
  4. Filter Network for searchspring. Open the POST to product/pageview and read userId in Payload. Then filter for gotolstoy and look for /event.
  5. In Application > Cookies, compare userId with the ssUserId cookie.

If step 3 still says analytics and marketing are allowed after Reject, the banner choice is not reaching Shopify, and every app pixel that trusts Shopify will keep sending. Our Reject All still tracking check shows what an after-Reject record holds. Results for other apps and stores are in the Shopify Reject All guide.

FAQ

Does Searchspring stop tracking after Reject All on Shopify?

On Store J it did not. The first product page after Reject sent 1 product-view event and 1 preflight request in each of two runs, the same as after Accept.

Does Searchspring set cookies after Reject All?

On Store J, ssUserId, ssSessionId and ssViewedProducts appeared on the first product page after Reject, and the product-view event carried the ssUserId value.

Why does the OneTrust choice not stop Searchspring?

On Store J, Searchspring ran as a Shopify app pixel, and Shopify still reported analytics and marketing as allowed after Reject. Shopify loads an app pixel when those permissions are granted.

Does Tolstoy send analytics after Reject All?

On Store J, Tolstoy sent pageView and embedView on the product page after Reject. Tolstoy's docs say it stops only when Shopify's analytics consent is "no".

Limits

One store on one day: one Accept run and two Reject runs, from a US connection. Every run reached a product page only after the click, so we have no product-page view from before a choice. We did not use the search box, open a Tolstoy video, add to cart, log in, check out, or call the Shopify consent API in the console. We see what left the browser; we cannot see what Searchspring, Tolstoy 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.

Does Searchspring Stop After Reject All? | ConsentProbe