Hightouch Events after Reject All: what a Shopify store still sent

Not legal advice

This page records three browser passes on Store I, a Shopify store with a OneTrust banner, on 2026-10-13. Times below are UTC+8. It is not legal advice, not a ruling on any store or on Hightouch, and not a statement that a request broke a law. Observation is not counsel permission.

Short answer

Reject All on Store I did not stop Hightouch Events. It changed what Hightouch received. The store's own consent_updated event flipped to false, and view_item was gone. Page events kept going with the visitor ID, the full page URL, and the Google Analytics client ID.

What we ran

Same store and same day as the Yotpo reviews capture.

• Store I: Shopify, OneTrust banner with Reject All on the first layer.
• Three passes in Chrome, each recorded with chrome://net-export from before the first page load. Times are UTC+8.
• Accept session, 09:36:35 to 09:37:37. Its Hightouch events came from the home page and one product page. Bodies logged.
• Reject run 1: clicked Reject All at 09:39:31. The home page reloaded, then a product page opened. URLs, methods, timing, and status codes only. No bodies.
• Reject run 2: clicked Reject All, then the same steps. Bodies logged.
• Visitor region was not recorded. No Global Privacy Control, no login.

Hightouch requests, Accept vs Reject

Before the click on Reject run 2, the home page sent 1 page event and 1 consent_updated event. Analytics, marketing, and personalization were true, and consent_received was true. The banner had not been clicked. The Accept session started the same way.

After Reject All, the reloaded home page sent consent_updated and page at 10:00:01. The product page sent page and consent_updated at 10:00:14. Both consent_updated events read analytics false, marketing false, personalization false, and consent_received false. In the Accept session the product page also sent view_item. After Reject it did not. Reject run 1 had the same count and timing pattern: two requests at 09:39:33 and two at 09:39:50. That run reloaded the home page at 09:39:32 and opened a product page at 09:39:49.

What the events still carried after Reject

Values are left out. These are the field names in each post-Reject request in run 2.

We can't see what Hightouch or the store's warehouse does with these events after they arrive. A destination may filter on consent_state server-side. The browser log doesn't show that either way.

• anonymousId, the same value as before the click. It matches the htjs_anonymous_id cookie, which Hightouch's browser SDK docs list as its anonymous visitor ID.
• properties.anonymous_id, which matched the client ID in the _ga cookie. That cookie was already set before Reject All. GA4 itself sent no /g/collect hit on the new pages.
• context.page.url with the query string, plus referrer, userAgent, userAgentData, timezone, and locale.
• The same sessionId as the pre-click events.

Same click, other hosts

On the new pages, Meta, TikTok, DoubleClick, Google Ads conversion, GA4 collect, Bing, Clarity, StackAdapt, and Simon Data (simonsignal.com) sent 0 requests in both runs. Google Tag Manager loaded its scripts. Attentive kept running, as in the Attentive after Reject All captures. Yotpo's review requests stayed at 0, which the Yotpo post covers.

After each click, and before the new page's Tag Manager script, TikTok sent 3/2, Meta 1/1, Bing 2/2, Clarity 1/2, Heap 1/1, Quantcast 1/1, and AfterShip 1/1. Run 1 is 09:39:31 to 09:39:32. Run 2 is 10:00:00.0 to 10:00:01.33, before gtm.js at 10:00:01.39. We read those as the old page unloading.

Why Hightouch can keep sending

Steps below come from official docs. We did not verify each one.

Hightouch documents a OneTrust integration. You wrap the browser SDK load with withOneTrust and load the OneTrust Banner SDK before the Hightouch snippet. The wrapper reads active group IDs from window.OneTrustActiveGroups. The documented load call takes the project's key.

Store I's events don't match what that wrapper's source code produces. The wrapper stamps context.consent.categoryPreferences on each event and sends a track event named Consent Updated. Store I's events had a store-defined consent_updated event with properties.consent_state, and no context.consent field. From the browser we can't tell how the store loads Hightouch. The log did not show the wrapper's UMD file loading from unpkg.

Our reading of the wrapper source, not tested on any store: it waits until OneTrust reports at least one consented group and the banner is closed, then loads the SDK. If the OneTrust setup keeps a strictly necessary group active after Reject All, that check passes. After that, the categories decide which device-mode destinations run and get stamped onto each event. The events still go to Hightouch.

Options if you want Hightouch quiet after Reject

Steps below come from official docs. We did not verify each one.

Whether a store should send any of these events after Reject All depends on its jurisdiction and its policy. That decision is for the store and its counsel.

1. Gate the load. Hightouch's browser SDK can be created buffered, and nothing goes over the network until you call load once. Call it only after the categories you mapped to Hightouch are granted.
2. Use the OneTrust wrapper (withOneTrust) and set up OneTrust categories first. The wrapper also takes integrationCategoryMappings. Then check in Network what still goes to hightouch-events.com after Reject.
3. Or use Hightouch Consent Manager. Its README says it delays loading the SDK until consent and does not load it at all if the visitor opts out of everything.
4. Check storage after Reject: cookies htjs_anonymous_id, htjs_user_id, htjs_group_id, and htjs_sesh, and localStorage htjs_user_traits and htjs_group_properties. If the ParamBuilder plugin is on, Hightouch's docs say it writes _fbc, _fbp, and _fbi when the SDK loads, and suggest turning it on only after consent.

Check your own store (5 minutes)

This is a browser check. It is not an official Hightouch step.

1. New Incognito or Guest window. Open DevTools first, tick Preserve log, then load the store.
2. Filter Network for hightouch-events. Open a /v1/page or /v1/track request, then Payload.
3. Note the event names, any consent fields, and anonymousId. Compare anonymousId with the htjs_anonymous_id cookie in Application, Cookies.
4. Click Reject All. Open one product page. Repeat the payload check.
5. Compare with an Accept run on the same URL. The Reject All pixel check has the full method. To keep a labeled Fresh / Reject / Accept record, start an audit.

Check the browser half

ConsentProbe records cookies and request hosts from a fresh visit and from the Reject control the banner shows. It does not replace Hightouch admin, and it does not install a CMP. A free US-baseline scan is not an EU or California legal conclusion.

FAQ

Limits of this page

One store, three passes, one day. Visitor region was not recorded. Reject run 1 has no bodies. We did not check Hightouch cookie writes after the click, and we did not test the wrapper or Consent Manager. We see what leaves the browser, not what Hightouch, its destinations, or the store's warehouse keep. Configuration steps come from the official docs and were not checked one by one here. These notes do not describe Shopify stores in general. It is not legal advice. Observation is not counsel permission. ConsentProbe does not install a CMP.

Related guides

The Yotpo capture is the same store and the same day. The Reject All pixel check is the method page.

• Yotpo reviews after Reject
• Attentive after Reject All
• Does Reject All stop marketing pixels?
• Shopify Reject All still tracking
• Klaviyo after Reject All
• Cookie audit
• Shopify Customer Events vs the Customer Privacy API