{"id":13100,"date":"2026-09-19T07:35:00","date_gmt":"2026-09-19T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13100"},"modified":"2026-09-09T13:24:13","modified_gmt":"2026-09-09T11:24:13","slug":"tutorial-reading-a-ga4-collect-request-parameter-by-parameter","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-analytics\/tutorials\/tutorial-reading-a-ga4-collect-request-parameter-by-parameter\/","title":{"rendered":"Tutorial: Reading a GA4 Collect Request Parameter by Parameter"},"content":{"rendered":"

A GA4 hit is one HTTP request, and everything the property will ever know about that moment is in its query string. Sixty parameters, all abbreviated to two or three characters, none of them documented in the interface.<\/p>\n

Reading them is worth learning for one reason: it is the only place where what the browser actually sent can be seen. Every report, every debug view and every consent indicator is downstream of this request, and a value that is not here was never sent.<\/p>\n

\n\"A
Four groups cover almost every parameter. The fifth block, the e-commerce item, is a format of its own inside one field.<\/figcaption><\/figure>\n

Finding the Request<\/h2>\n

The request goes to \/g\/collect<\/code>, either at Google directly or at the server container if one is in use. In the browser’s network panel, a filter on collect<\/code> reduces the list to exactly these hits.<\/p>\n

https:\/\/www.google-analytics.com\/g\/collect\n  ?v=2&tid=G-AB12CD34&gtm=45je55h0v9182736&_p=1737041234567\n  &cid=1234567890.1737041234&ul=de-de&sr=2560x1440&_s=2\n  &sid=1737041234&sct=4&seg=1&dl=https%3A%2F%2Fshop.example%2Fkasse\n  &dt=Kasse&dr=https%3A%2F%2Fwww.google.com%2F&en=purchase\n  &ep.payment_type=card&epn.value=129.9&cu=EUR&_et=4312\n  &pr1=idSKU-42~nmStuhl~caMoebel~pr64.95~qt2&gcs=G111<\/code><\/pre>\n
Two practical notes about where it hides. Small hits travel as a GET and the parameters are in the address; larger ones switch to a POST, and then the address carries only part of them while the rest sits in the request body. And several events can be batched into one POST, one per line – a body with three lines is three hits, not one.<\/p>\n
A request that never appears is a finding in itself, and it has three usual causes: consent is denied and the tag is holding back, an ad blocker removed the script, or the tag never fired. The three are told apart in the tag debugger, not here.<\/p>\n
The Parameters That Identify<\/h2>\n
The first group answers who is sending and to which property. These parameters are on every hit and change rarely.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Parameter<\/th>\nMeaning<\/th>\n<\/tr>\n<\/thead>\n
v=2<\/td>\nProtocol version – 2 is GA4, 1 was Universal Analytics<\/td>\n<\/tr>\n
tid<\/td>\nMeasurement ID of the target property<\/td>\n<\/tr>\n
cid<\/td>\nClient ID, the value from the _ga cookie without its prefix<\/td>\n<\/tr>\n
sid<\/td>\nSession ID – the epoch second at which the session started<\/td>\n<\/tr>\n
sct<\/td>\nSession count for this client<\/td>\n<\/tr>\n
seg<\/td>\n1 once the session counts as engaged, 0 before that<\/td>\n<\/tr>\n
_p<\/td>\nRandom number per page load, groups the hits of one page<\/td>\n<\/tr>\n
_s<\/td>\nCounter within the page load – the first hit is 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Two of these are more useful than they look. The session ID is a timestamp, so it says exactly when the session began – a session that keeps restarting is visible here before any report shows it. And _s<\/code> makes gaps obvious: a page whose hits jump from 1 to 3 lost one on the way.<\/p>\n
The Parameters That Describe the Page<\/h2>\n
The second group is the context, and it is where most wrong values originate, because these are the parameters a tag can overwrite.<\/p>\n
dl<\/code> is the page location and arrives percent-encoded; it is the source of the page path and of every query parameter GA4 later reports. dr<\/code> is the referrer and empty on a direct entry. dt<\/code> is the document title, taken at the moment the hit fires – which is why a single-page application that fires before the title changes reports the previous page’s title.<\/p>\n
ul<\/code> is the browser language and sr<\/code> the screen resolution. Both come from the browser and are the two fields that most often reveal an automated visitor: a resolution of 800×600 paired with an English locale on a German shop is a pattern rather than a person.<\/p>\n
Worth checking here rather than in a report: whether dl<\/code> carries parameters that should not be in analytics at all. Everything after the question mark ends up in the page dimension, and a form that puts an email address in the URL sends it here first.<\/p>\n
The Event and Its Parameters<\/h2>\n
The third group is what actually happened, and it follows a simple naming rule.<\/p>\n
en=purchase              the event name\nep.payment_type=card     event parameter, text\nepn.value=129.9          event parameter, number\nup.plan=premium          user property, text\nupn.credits=40           user property, number\n_et=4312                 engagement time in milliseconds since the last hit\ncu=EUR                   currency<\/code><\/pre>\n
The distinction between ep.<\/code> and epn.<\/code> is the one that costs the most time when it is wrong. A number sent as text lands in a text dimension, cannot be summed, and cannot be turned into a metric afterwards – and nothing reports an error, because a text parameter with the content 129.9<\/code> is perfectly valid.<\/p>\n
The engagement time is cumulative per hit, not per session: each request carries the milliseconds since the previous one. A page that sends 0 here throughout is not being looked at, or the timer is being reset by something.<\/p>\n
The E-Commerce Payload in One Field<\/h2>\n
Items do not each get their own parameter. They are packed into pr1<\/code>, pr2<\/code> and so on, one field per item, with two-letter codes and a tilde as separator.<\/p>\n
pr1=idSKU-42~nmStuhl~caMoebel~pr64.95~qt2~brNordholz~vaEiche<\/code><\/pre>\n\n\n\n\n\n\n\n\n\n\n
Code<\/th>\nGA4 field<\/th>\nCode<\/th>\nGA4 field<\/th>\n<\/tr>\n<\/thead>\n
id<\/td>\nitem_id<\/td>\npr<\/td>\nprice<\/td>\n<\/tr>\n
nm<\/td>\nitem_name<\/td>\nqt<\/td>\nquantity<\/td>\n<\/tr>\n
br<\/td>\nitem_brand<\/td>\nds<\/td>\ndiscount<\/td>\n<\/tr>\n
ca<\/td>\nitem_category<\/td>\ncp<\/td>\ncoupon<\/td>\n<\/tr>\n
c2 \u2026 c5<\/td>\nitem_category2 \u2026 5<\/td>\nln<\/td>\nitem_list_name<\/td>\n<\/tr>\n
va<\/td>\nitem_variant<\/td>\nlp<\/td>\nindex<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Three things become checkable once this is readable. Whether every item carries an id<\/code> – an item without one is dropped silently. Whether pr<\/code> is a plain number: a price arriving as 64,95<\/code> with a comma, or with a currency symbol, is not a number and the revenue stays empty. And whether the sum of price times quantity matches epn.value<\/code>, because the two are sent independently and a mismatch between them is invisible in every report.<\/p>\n
The number of items has a ceiling that is easy to hit. A request has a length limit, and a cart with two hundred lines exceeds it – GA4 then switches to a POST, and beyond that it truncates. A purchase whose item list is shorter in the reports than in the shop is almost always this.<\/p>\n
The Consent Fields<\/h2>\n
The last group is short and decides more than the rest together.<\/p>\n
gcs=G111    ad_storage granted, analytics_storage granted\ngcs=G100    both denied\ngcs=G101    ad_storage denied, analytics_storage granted\ngcd=13t3t3t3t5   the defaults that were set before the choice<\/code><\/pre>\n
The two digits after G1<\/code> are ad storage and analytics storage in that order, 1 for granted and 0 for denied. A hit with G100<\/code> is a cookieless ping: it counts towards modelling but writes no identifier, and the client ID in it is generated per request rather than persisted.<\/p>\n
The field to compare it against is gcd<\/code>, which records what the defaults were. A container whose defaults arrive as granted while the banner has not been answered yet is a misconfiguration that only shows here – the reports look normal, because the data is being collected.<\/p>\n
One last check that takes ten seconds and settles a whole class of arguments: reload the page with consent denied and look for the request. If a hit with gcs=G100<\/code> goes out, consent mode is working as designed. If nothing goes out at all, the tag is being blocked entirely – which is a different setup with different reports, and worth knowing which one is in place.<\/p>\n
\n
Sources<\/h2>\n