Preserve query parameters on redirect

Any success getting this prioritised @fool?
Continues to be major pain for us.

thanks for continuing to ask! The more specifically you outline how this affects your business, the more useful your feedback is - are there any details you can share about how this impacts you, how many people, etc?

Sure thing.

  • Put yourself in the shoes of someone who is responsible for the marketing expenditure and demonstrating a return on investment for your spend. Let’s say you’re spending $50K a month on digital advertising and need to know which of your paid and organic channels and campaigns are performing best.
  • If you require any type of redirection, then choosing to use Netlify is a choice to compromise your ability to report on return on investment. To elaborate further:
  • UTM parameters are the bread and butter of campaign and channel tracking for most marketers. Let’s say you serve a translated or localised site based on country and language.
  • When you launch a new campaign via email, social media, mulitple paid advertising channels, you want to be able to customise the utm_source, utm_campaign and sometimes others such as utm_term.
  • Using Netlify, if you post links to those marketing channels, and you use your primary domain for the links, then when the user is redirected to their language/location subdomain, Netlify will nuke your utm parameters, eliminating the ability as marketers to measure the effectiveness of the campaign.
  • This is currently affecting our business to the tune of close to a million dollars in expenditure that we can’t track effectively and a high prospect of missed growth opportunities due to poor feedback cycles on marketing campaigns.
  • I would also argue that it is unexpected behaviour. The fact that you can put a * wildcard on your redirects and Netlify picks and chooses what included in the wildcard is a strange indeed. It has that feel about it that there is a technical concern that’s driving a poor product management position. I can’t understand otherwise why Netlify would hold a position that the current behaviour should be expected.
3 Likes

thanks @agworld - this is a very comprehensive summary. We’ll keep you all updated when there is news to share.

1 Like

Not sure how to upvote or join, but this is very problematic for us as well.
We’re thinking of migrating our sites to Netlify, and we have a lot of legacy urls pointing to our site with tons of different query params.

We can’t know in advance what would be the query params that folks use, as they are chosen by marketing folks at times, by third party at other times.

Given that we’re about to sign up for the enterprise tier, I would love to understand what is the status of this feature request as it may be blocking us from continuing, or needing to go to other unsupported solutions like putting a reverse proxy in front of Netlify (Trying to set up a nginx reverse proxy fails)
Which isn’t supported by you guys.

cc @fool

Thanks for that additional context @altryne ! I’ve seen some discussion of this situation recently so I’ll check in with the dev and product teams to see if I can give any status updates. Are you already working with anyone on the sales team so I can loop them in on this discussion?

Yeah I had a chat with Jeff Watson and @Bhavana regarding the enterprise account but this issue didn’t come up then, I only now noticed it.

We finally fixed the proxy part of this :tada:

You can find more here: Bug fixed: Proxy did not pass query string to target

4 Likes

amazing news! thank you marcus - and thank you to all of the folks who mentioned they needed this and waited patiently for us to ship it :pray:

Oh, the proxy wasn’t passing them along! great that it was fixed (as this is even more problematic for us than the redirects)
@marcus any ETA on this getting on the enterprise?

@altryne rollout for enterprise will definitely be this week, today or tomorrow.

2 Likes

we identified a regression with this change: Breaking change to redirect query parameters
therefore we are going to delay the rollout for the enterprise cdn

2 Likes

hey @marcus @fool is any update on the original post?
Being able to specify netlify to redirect 301/302 with all GET params?

Additionally, is there any update on the rewrites GET param and it’s Enterprise CDN rollout? 80% of our payed traffic will move through a rewrite so this is blocking our deployment at the moment.

1 Like

No updates yet. This has been a bit more challenging than expected with more moving parts. We’ll update here as things develop!

1 Like

The change for proxy type rules is now rolled out across all CDN tiers.

Redirect (3xx) rules are not updated yet.

2 Likes

@marcus @fool This news is fantastic. Thank you!

When you say “Redirect (3xx) rules are not updated yet,” does this mean that it’s ready to be rolled out? Will it be soon? Or is it a ways away?

I’m just trying to get a rough idea as we’re looking to do a migration from a naked domain to www. We have around 20k (that we know of) inbound links, some of which have query params that we can’t afford to lose in the redirect. This use-case and, pretty much, everything agworld laid out, to a T.

Thanks again!

1 Like

I would not bet on getting it before January. The work is not scoped out and we don’t know how it plays with our caching, so there is still stuff to figure out.

2 Likes

Thanks for the follow-up!

Loved @agworld’s use cases — totally agree. Our main use cases are UTM (e.g. ?utm_source=) and search params (?q=), directing traffic to correct locale. Something that indicates we should be preserving all query params would be amazing. Glad to see this is actively developing.

We currently use netlify.toml … could re-write to _redirects but ideally wouldn’t have to (though would prefer to rewrite if it made the solution quicker to implement).

My understanding is the issue lies somewhere above netlify.toml and _redirects. For both of these, you need to specify all combinations of query parameters. I’m assuming that a fix will allow use of either one to implement redirects that keep arbitrary query parameters intact without having to write out the params in configuration files.