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?
- 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.
thanks @agworld - this is a very comprehensive summary. We’ll keep you all updated when there is news to share.
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.
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
You can find more here: Bug fixed: Proxy did not pass query string to target
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
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.
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
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.
No updates yet. This has been a bit more challenging than expected with more moving parts. We’ll update here as things develop!
The change for proxy type rules is now rolled out across all CDN tiers.
Redirect (3xx) rules are not updated yet.
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.
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.
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
_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.
Thanks for the clarification @robert! If you happen to know, could you possibly show me an example of how I could go about even getting one or two permutations done? I’m trying to understand the complexity. Would love to ideally be able to account for at least
utm_medium for two of my redirect rules.