Decide whether your site needs a page reload after each answer

Most sites need no reload, because TermsFeed Free Cookie Consent runs the scripts of an accepted category on the same page, the moment the visitor accepts. Turn on page_refresh_confirmation_buttons only when a declined or withdrawn category must stop at once, or when a script or your server reads the answer only while the page loads. Every reload interrupts the visitor, so check your site against the cases where a reload helps before you turn it on.

What happens after an answer without a reload

Accepting runs the tagged scripts of each accepted category at once, while refusing or withdrawing does not stop tagged scripts that already run on the current page. After a click on the "I decline" button or a category turned off and saved in the Preferences Center, the scripts that already run stop on the next page load. Google tags still receive denied at once from a Consent Mode update in your user_consent_saved callback, and stop storing new cookies for that category.

Cookie Consent does not delete cookies set by scripts that already ran. Delete the cookies of a refused vendor when its category is off with Consent Storage and Duration.

What page_refresh_confirmation_buttons does

With page_refresh_confirmation_buttons: true, a click on the "I agree", "I decline", or "Save my preferences" button reloads the page at once, and the reloaded page runs only the accepted categories. The "OK" button of implied consent reloads the page too. Opening the Preferences Center, switching its language, or closing it without saving reloads nothing.

Add the option to the object you pass to cookieconsent.run().

<script type="text/javascript" charset="UTF-8">
document.addEventListener('DOMContentLoaded', function () {
cookieconsent.run({
  "notice_banner_type": "headline",
  "consent_type": "express",
  "language": "en",
  "page_refresh_confirmation_buttons": true
});
});
</script>

The reload follows every answer, even a save that does not change any switch. Cookie Consent writes the 3 cookies before it reloads, so the reloaded page reads the new answer. Once an answer starts the reload, no tagged script runs on the page being left. Consent signals granted from scripts_specific_loaded therefore arrive on the reloaded page.

Cookie Consent calls user_consent_saved and i_decline_button_clicked before it starts the reload, and i_agree_button_clicked right after it starts the reload. In Chrome, i_agree_button_clicked usually still runs before the page unloads, but no browser guarantees it. The page does not wait for responses to the requests your callbacks send, so a consent record that your user_consent_saved callback sends to your server has no guarantee of finishing. Send such a request with navigator.sendBeacon() or fetch() with keepalive: true, or send it again on the reloaded page. Read why a beacon survives the reload on the MDN page for sendBeacon.

When a page reload after consent helps

A reload helps only where the current page keeps doing something the answer no longer allows, or misses something the answer now allows. A session recording tool or a chat widget on the current page keeps collecting data after the visitor turns its category off. The reload stops the tool or the widget at once.

A script or widget that reads the answer only once, at startup, misses a new answer and shows the old state until the next page load.

A server that reads cookie_consent_level to decide whether to print an embed or a tracking tag sees a new answer only on the next request, which the reload sends at once. Read the cookie on the server with Read the Consent State.

What a reload clears: form input, scroll position, app state, and the referrer

A reload throws away what the visitor did on the page before answering: text typed into a form, the scroll position, and the state of a single-page app. A visitor who answers halfway through a long form starts again. Leave the reload off on pages where visitors type before they answer, such as a checkout, by printing false for page_refresh_confirmation_buttons in the template of those pages.

The reloaded page keeps its address, so campaign parameters such as utm_source survive. The referrer does not survive in Chrome, which sets the referrer of the reloaded page to its own address. A tagged analytics tool runs for the first time on the reloaded page, so it never sees the search engine or the site the visitor came from. Check how your analytics reports the traffic source before you keep the reload on.

How to turn on the page reload after consent and check it

The checks assume express consent with page_load_consent_levels left out or at the generator value ["strictly-necessary"]. Turning on the reload takes 4 steps and about 15 minutes, and reopening the Preferences Center after the answer needs a cookie settings link on the page. Add one with Add a Cookie Settings Link.

  1. Add "page_refresh_confirmation_buttons": true to the configuration object, and deploy it.
  2. Close every private window and open a new one. Open Chrome DevTools on the Network tab and turn on the "Preserve log" checkbox. Type the host of an optional tagged script in the filter box, such as googletagmanager.com for a tagged Google tag, then load your site.
  3. Click the "I agree" button, confirm the page reloads, and confirm the requests to that host start only after the reload. Then open the Preferences Center with your cookie settings link, select the category tab of that script, and set its switch to Inactive. Click the "Save my preferences" button, and confirm no request to that host follows the second reload.
  4. With a tagged Google Analytics 4 tag on the page, close every private window and open a new one. Open DevTools on the Network tab with collect in the filter box, add ?utm_source=test to the address of your site, and load it. Click the "I agree" button, and select the first collect request after the reload. Confirm its dl parameter, the page address, still holds utm_source=test, and read its dr parameter, the referrer, which Chrome sets to the page itself.