What does the Meta Pixel send after a shopper clicks Reject?

Short answer

In these three stores, Reject stopped the Pixel in the browser. Store V's Pixel sent a PageView about 8 seconds after the page loaded, before anyone clicked. After Decline it sent nothing to Meta for the rest of the session. Store W downloaded fbevents.js on every page but never sent an event. Store X made no request to a Meta domain at all.

A quiet Pixel tells you about the browser half only. Server-side sending, including CAPI, does not show up in a browser log.

How we tested

Each run used a new Chrome profile with no cookies, a US connection from Virginia, and the browser clock set to Los Angeles time. In a Fresh run we opened the homepage and clicked nothing for 20 seconds. In a Reject run we closed any marketing popup, clicked the banner's Reject button, opened a product page, and added one item to the cart. We did not check out.

After each click we confirmed that the banner closed and that Shopify's consent API reported marketing as "no". On one early run a popup covered the banner, the click missed, and the Pixel fired again on the next page. We threw that run out.

1. Fresh: no click, 20 seconds.
2. Reject: close the popup, click Reject, open a product page, add to cart.
3. Confirm the banner closed and marketing is "no".
4. Throw the run out if the click misses the banner.

Before the click

Two of the three stores contacted Meta before the shopper chose anything. Store V loaded the Pixel, fetched its config, and sent a PageView with an fbp field. It also wrote an _fbp cookie. Store W downloaded fbevents.js and did nothing else. Store X sent nothing.

We tested US visitors only. US banners are often set to allow tags by default and stop them after Reject. Store V's consent default had ad_storage set to true, so its requests before the click may come from how the store set up its banner. We don't draw a conclusion from them.

For the before-Accept question, see what Meta receives before Accept.

After Reject: Meta requests by store

After Reject, the count of events sent to facebook.com/tr was zero on all three stores, across the product page and add to cart. No PageView, ViewContent, or AddToCart reached Meta from the browser.

Store W kept downloading fbevents.js after Decline. A script download is still a request to a Meta domain, with the usual browser headers. It carried no event.

Reject did not delete Store V's _fbp cookie. The value set before the click was the same at the end of the session.

None of the /tr requests we saw carried Meta's Limited Data Use parameters (dpo).

On 2026-10-29 UTC, Store V's Reject navigation started at 01:46:30, Decline at 01:46:52.7, the product page at 01:47:10, and add to cart at 01:47:26. Store W's Decline was at 01:48:17.4. Store X's REJECT ALL was at 01:44:37.9.

For other tags that keep running after Reject, see the Reject All hub.

Meta fields that still left the browser

After Decline, Store V's first-party collector, on the store's own domain, received three posts: a user-data event and a product view on the product page, then the add to cart. Each body had an _fbp field and an ad_storage value of update false.

Before the click, Store V also posted a PageView to an endpoint hosted on AWS, outside Meta's and the store's domains. Its field names included fb.fbp and fb.pixel_id. After Decline that endpoint received nothing.

Store X's first-party collector received the same three events with no _fbp or _fbc field.

For the server side of Reject, see Meta CAPI after Reject All.

What a browser test can't show

We did not see CAPI, because CAPI runs from the merchant's server to Meta. We can't tell what Store V's collector or the AWS endpoint did with the data they received. We tested US visitors only, and we did not run an Accept session this time.

A CMP in the EU, the UK, or California can show a different banner and default. We did not test those visitors.

Meta's on-device conversion setting

Meta's Business Help Center says "Measure conversions on customer devices is turned on by default." It says the feature "works alongside your existing Pixel and Conversions API setup and doesn't replace it," needs the Pixel installed directly on the page, and applies only to sites where people log in with an email or phone number. It is "not active for people located in the EU and UK."

Advertisers report that Events Manager shows a November 12, 2026 start date. That date comes from a secondary report by PPC Land, not from Meta. Meta's help pages do not give a date.

Our captures predate that date. We saw no request we could tie to this setting. If you want to know whether anything changes after Reject, rerun the same Fresh and Reject sessions on your store after November 12. Not legal advice.

Run the same check on your store

Run Fresh and Reject on your storefront URL with a free US-baseline scan. For EU or California sessions, see pricing. A free US-baseline scan is not an EU or California legal conclusion. ConsentProbe does not install a CMP.

1. Open a new Chrome profile and DevTools before loading the store. Turn on Preserve log.
2. Load the homepage. Filter Network by facebook and note fbevents.js, signals/config, and facebook.com/tr.
3. Close any popup, click Reject, and confirm the banner is gone. In the Console, run Shopify.customerPrivacy.currentVisitorConsent() and check that marketing is "no".
4. Open a product page and add to cart. Filter facebook again, then search request bodies for _fbp and fbp.
5. Check Application > Cookies for _fbp before and after the click.

FAQ

Limits of this test

Three stores, one Fresh and one or two Reject sessions each, US visitors only, on 2026-10-29 UTC. Two stores used Pandectes and one used OneTrust. These sessions do not describe Shopify stores in general. The browser cannot see CAPI. Not legal advice.