Giovani Ortolani Barbosa
AuthorIf you've ever noticed mysterious /set_cookie requests appearing in your server-side Google Tag Manager (sGTM) logs, you may be wondering what they are, why they exist, and whether they indicate a problem. These requests often raise concerns about billing, data collection, and tag behavior.
The short answer is: this is expected behavior (and not documented by Google), not an error. These requests are part of a clever solution to a complex timing problem inherent in server-side tagging.
In this article, we'll break down what /set_cookie requests are and what role they play in ensuring reliable tracking and cookie collection in sGTM.
A /set_cookie request occurs when three conditions are met:
sendPixelFromBrowser API in sGTM.setCookie API after sendPixelFromBrowser API has already been called.richsstsse parameter in the end of its URL and without having any value (e.g. [...]&richsstsse).Tags like Google Ads Conversion/Remarketing, Floodlights, and GA4 (when Google Signals is enabled) rely on firing pixels from the browser to sync third-party cookies. To do this effectively, the sendPixelFromBrowser API is often called very early in the tag's execution process to give the browser maximum time to collect these cookies from the vendor's domains (like doubleclick.net).
When this API is called, sGTM immediately sends the response back to the browser to initiate the third-party pixel syncing request.
Here's the catch: once the response has been sent, the server can no longer add new Set-Cookie headers to the response. Only the tags that set cookies using the setCookie API before sendPixelFromBrowser API was called will have their cookies set through Set-Cookie headers.
| This creates a problem. What if other tags are still running and need to set a first-party cookie? They've missed their chance because the headers are already gone. |
This is where the richsstsse parameter and the /set_cookie come in.
The richsstsse parameter acts as a flag, signaling that the entity that sent the event in the browser (usually a Google tag / gtag or Stape Data tag) supports a special "command protocol." This protocol allows the server to send instructions back to the browser in the response, such as setting cookies or firing third-party pixels, even after the initial response has already been sent.
And /set_cookie is a request back to the sGTM from the browser to pick up the cookies that should have been set previously, but didn't get a chance to.
In short: to ensure third-party cookies can be collected, sGTM sends its response early. To ensure first-party cookies can still be set after that, it uses a special protocol to send instructions in the response body. This protocol is what generates the /set_cookie requests.
When the richsstsse parameter is present in the incoming request to your sGTM container, sGTM sends the response body in a series of chunks. You can observe this in the sGTM Preview Mode page under the "Outgoing HTTP Requests from Browser" section.
The response body isn't delivered all at once, but in parts, with each new chunk appearing as tags execute the setCookie or sendPixelFromBrowser commands.
For example, the gtag (GA4 tags) library uses a ReadableStream to handle this. Each chunk contains a message with instructions, such as:
send_pixel: tells the browser to fire a pixel to a specific URL, which can be for third-party cookie syncing or other purposes.response: the final message in the stream, which contains the "real" HTTP status code and body that the client was expecting.Here is an example of what these data chunks look like in the response body:
// Instruction to send a pixel to set a cookie via the sGTM endpoint
event: message
data: {"send_pixel":["${transport_url}/_/set_cookie?val=[...]&path=${encoded_path}"]}
// Instruction to send a pixel to a Google domain for third-party cookie syncing
event: message
data: {"send_pixel":["https://googleads.g.doubleclick.net/pagead/viewthroughconversion/[...]","fallback_url_method":"fetch"}}
// Instruction to send a pixel to a Google domain for third-party cookie syncing
event: message
data: {"send_pixel":["https://www.google.com.br/ads/ga-audiences?v=1&t=sr&slf_rd=1&_r=4&dma=0&[...]"],"options":{}}
// Instruction to send a pixel to a Google domain for third-party cookie syncing
event: message
data: {"send_pixel":["https://ad.doubleclick.net/activity;register_conversion=1;[...]"],"options":{"attribution_reporting":true}}
// The final response message
event: message
data: {"response":{"status_code":200,"body":""}}
And also, please take a look here:
You can see in this last video that the response body is not received once, but in parts. The chunks list keeps increasing as soon as the tags execute the setCookie and sendPixelFromBrowser instructions.
For those who want a deeper understanding, here are a few key technical points derived from tests and observations.
sendPixelFromBrowser may generate /set_cookie requests.200 status code, regardless of what your client defines. The actual status code is delivered in the final response message chunk.sendPixelFromBrowser is not called, sGTM waits until all tags finish (or timeout at the default timeout of 20 seconds) before responding.send_pixel commands include a fallback URL (seen in the fallback_url parameter) in case the primary request is blocked.setCookie or sendPixelFromBrowser APIs must be called before running data.gtmOnSuccess() or data.gtmOnFailure() in the tag's code. This ensures your commands are queued before the tag signals its completion.Set-Cookie response headers.sendPixelFromBrowser API will be gracefully ignored.You'll most commonly see /set_cookie requests when using tags that rely on third-party cookie syncing for remarketing and conversion tracking. This includes:
sendPixelFromBrowser API, such as the Microsoft UET CAPI tag and Amazon tag.Each /set_cookie request is a new incoming request that your tagging server infrastructure (like Google Cloud Platform or Stape) has to process. If you have a high volume of events that trigger this behavior, it can lead to an increase in your server costs.
They are normal and expected behavior in sGTM. They are not an error or a problem.
However, you can manage it with good tagging hygiene:
The /set_cookie requests you see from your GTM are not a cause for alarm. Instead, they are a core part of the sophisticated mechanism that allows server-side tagging to effectively handle both first-party and third-party cookie requirements.
By sending an early response to facilitate third-party GTM cookie syncing and then using a chunked response body to send follow-up instructions, sGTM navigates the technical limitations of the HTTP protocol.
As an option to ease your mind:
Comments