Success Booking Redirect Does Not Preserve URL Parameters

[Dinhu]

The forward paramenters button does NOT solve this. it just forwards informaiton user typed on the form, not UTM parameters.

When a user completes a booking flow, the redirect to the success-booking page does not preserve URL parameters from the original landing page (e.g., utm_source, utm_campaign, etc.).

Steps to Reproduce:

1. Land on the origin website with URL parameters (e.g., https://mysite.com/booking?utm_source=google).
2. Complete a booking through the embedded Cal.com component.
3. Get redirected to the success page (/success-booking).

The redirect should preserve the original URL parameters so tracking and attribution data (such as ad campaign UTMs) can be passed through to the success page.

Why This Matters:

• Ad campaign tracking depends on retaining UTM parameters across the entire funnel.

• Without preserved parameters, analytics platforms (Google Ads, Meta Ads, etc.) cannot properly attribute conversions.

• This reduces the ability to measure ROI from ad spend.

• Add support for automatically appending existing URL parameters from the origin site to the success redirect.

• Or, provide configuration options to define which parameters should be persisted through the redirect.

[jenilsavani9]

For more context on previous work:

The issue described in the provided question, where URL parameters like utm_source and utm_campaign are not preserved during the redirect to the success page, is related to how the booking success redirect handles query parameters.

Specifically, [CAL-3429] highlights a problem where the code incorrectly adds an extra ? when appending new query parameters to a redirect URL that already contains them, leading to malformed URLs.

[CAL-5388] addresses a related but distinct issue where the embed query parameter was being forwarded to a WordPress page, causing it to break. The fix implemented in the associated pull request filters out the embed parameter to resolve this.

While the embed parameter issue is resolved, the core problem of preserving existing URL parameters (like UTMs) to the success page, as described in your question, appears to be a separate, unaddressed concern. The current system might be stripping or not correctly handling these parameters during the redirect.