feat: Add meta pixel conversion events

[roy-abir05]

What does this PR do?

This PR adds the ability to configure specific Standard Conversion Events for the Meta Pixel integration.

Previously, the app only fired a generic PageView event on the booking success page. This update allows users to select a specific event type (Lead (default), Schedule, Complete Registration, or Page View) from the app settings. This ensures that the correct signal is sent to Meta for better ad optimization and reporting.

Additionally, this PR implements a robust History API hook to ensure conversion events fire correctly during client-side navigation (SPA transitions) in Next.js, while preventing duplicate events on page refreshes.

It also excludes "Cancellation" pages for firing the conversion events.

• Fixes Meta Pixel app: Add support for Lead/CompleteRegistration conversion events on booking confirmation #25449
• Fixes CAL-6828

Visual Demo

Video Demo:

2025-12-05.15-57-59.mp4

Image Demo:

Booking Form Page:

Booking Confirmed Page:

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code.
• N/A
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

• Setup: Install the Meta Pixel app and enter a dummy Pixel ID (e.g., 123456789).

• Configuration: Go to App Settings, select Schedule or any other event of your choice from the new Conversion Event dropdown, and click Save

• Booking Test: Go to a public booking page and complete a booking.

• Verification:

  • Open Chrome DevTools > Network Tab (Ensure "Preserve Log" is enabled).
  • Filter by tr
  • Verify that on the booking form, PageView and CalcomView events are fired.
  • Verify that upon reaching the success page, a request with payload ev: Schedule (or the event that you selected) is fired instantly.

• Cancellation Test: Click "Cancel Booking" on the success page. Verify that the conversion event (Schedule) does not fire on the cancellation confirmation page (only PageView and CalcomView should fire).

• SPA Test: Verify the event fires immediately upon transition to the success page without requiring a hard browser refresh.

Checklist

• I have read the contributing guide
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have checked if my changes generate no new warnings

---

[vercel]

@roy-abir05 is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

No issues found across 4 files

[dhairyashiil]

Thank you for the PR and the after video. Could you please attach the before video as well? I haven’t worked on this part before, so I’m not familiar with the current behavior.
A description with an example would also be helpful. Please add both, and I’ll review it afterward. Thanks!

[roy-abir05]

Thank you for the PR and the after video. Could you please attach the before video as well? I haven’t worked on this part before, so I’m not familiar with the current behavior. A description with an example would also be helpful. Please add both, and I’ll review it afterward. Thanks!

Thanks for the review!

The Context: Currently, the Meta Pixel app fires a generic PageView event on the Booking Success page. This prevents advertisers from distinguishing between a user simply visiting a booking page vs. actually completing a booking. Without a distinct conversion event (like Lead or Schedule), ad campaigns cannot be optimized for conversions.

The "Before" Behavior: As you can see in the recording below, the App Settings has no configuration options. When a booking is completed, the Network tab shows only a PageView event firing.

2025-12-12.12-45-15.mp4

The Fix: This PR adds a dropdown to select a specific Standard Event (e.g., Schedule) and implements a History API hook to ensure this event fires correctly on the client-side transition to the success page.

[cubic-dev-ai]

No issues found across 4 files

[roy-abir05]

Hi @dhairyashiil,

Just checking in—did the Before video and explanation above provide the context you needed?

Please let me know if any changes are required. I am happy to provide more details if needed. Thanks!

[github-actions]

This PR has been marked as stale due to inactivity. If you're still working on it or need any help, please let us know or update the PR to keep it active.

[roy-abir05]

@dhairyashiil Just bumping this to keep it open. The branch is up-to-date and I believe I've addressed the previous feedback regarding the Before video.

Let me know if there is anything else needed to get this merged.

[roy-abir05]

Hi @anikdhabal,

Thanks for updating the branch.

It looks like the CI/CD workflows are stuck on Authorization required, so the tests were skipped. Could you please authorize the deployment so we can get a green build?

Thanks!

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 4 additional findings.

[sahitya-chandra]

LGTM

[sahitya-chandra]

@roy-abir05 are you still working on this?

[roy-abir05]

@roy-abir05 are you still working on this?

Hi @sahitya-chandra ! Yes, I am still here and monitoring this.

Thanks for the review, the LGTM, and for cleaning up that file. I noticed the CI failed on the check-types step because the new trackingEvent field was throwing errors on legacy database objects. I just changed .default("Lead") to .optional() in the Zod schema (the fallback to 'Lead' is already safely handled in the app data getter).

Standing by for the E2E tests.
Thanks for helping me get this across the finish line

stale

[roy-abir05]

Hi @sahitya-chandra!

All CI checks are fixed and fully green now.

The type checks, production builds, and all E2E test suites passed successfully.
Let me know if there's anything else needed.

Thanks again for the help.