Who sets it, and when
srsltid comes from Google Merchant Center, specifically the free product listings that show up in the Shopping tab, in regular Search results, and sometimes in Google Images. Google mints the parameter itself, at the moment it renders the link to your product, and attaches it before the shopper ever clicks. You did not add a tag. Your site did not set a cookie. This is Google's own plumbing for its free Shopping surfaces, separate from paid Search ads, which carry gclid instead, or from Ads' own newer source flag, gad_source.
What it actually is
It is an opaque token, not a readable code. There is no product ID or store ID sitting inside it that you can pull out by hand. It is long, case-sensitive, and looks random by design, built so Google's own systems can trace a click back to the specific listing instance that generated it. That is the whole job. It carries no information about the shopper as a person and is not an account identifier of any kind.
Why one product becomes many rows
Google appears to mint a fresh srsltid per listing instance it serves, not one fixed value per product. The effect shows up in two places at once. In Search Console's Pages report, a single product page can appear as several separate URL rows instead of one. In Google Analytics, the landing page report splits that same product's traffic across just as many rows. Nobody added tracking. The product only has one real URL. Google's free-listing pipeline is what generates the variants, and there is no setting on your site that turns it off.
What to strip, and what not to worry about
Whether srsltid survives a redirect depends on your redirect rules, same as any query parameter: a rule that preserves the query string carries it through, one that does not drops it. For the shopper, none of this matters. The page loads exactly the same either way. For you as the site owner, stripping srsltid from your canonical tag and excluding it in your analytics view is safe, because Merchant Center tracks listing performance on Google's side, not by reading the parameter back off your server. A clean canonical setup and a query-exclusion rule fix the reporting split. A redirect rule does not. Compare it against utm_source, which you choose and set yourself, or see the full list at the link decoder hub.