Meta CAPI and Ad Tracking
How Aura sends reliable, deduplicated funnel events to Meta and preserves the attribution behind them
Meta CAPI and Ad Tracking
Aura reports meaningful funnel events to Meta from both the browser Pixel and the Conversions API (CAPI). This gives Meta a timely browser signal and a durable server-side signal without counting the same conversion twice.
This guide explains exactly when Aura sends each event, why booking conversions do not depend on a thank-you page, how rebookings are handled, and how campaign attribution travels with a lead.
Pixel and CAPI are two delivery paths
The Meta Pixel runs in the visitor's browser. It can send an event immediately, but browser privacy controls, ad blockers, network interruptions, or a closed tab can prevent delivery.
Meta CAPI sends the corresponding event from Aura's servers. It is not a second conversion. It is a more durable delivery of the same conversion.
For events sent through both paths, Aura gives the Pixel and CAPI event the same stable event ID. Meta uses the event name and event ID to recognize the pair and count one conversion.
Confirmed Aura action
|
+--> Browser Pixel ----+
| +--> Meta counts one conversion
+--> Server CAPI -------+
same event IDSeeing a browser event and a server event in Meta Events Manager is expected. They should share an event ID so Meta can deduplicate them into one conversion.
Aura's funnel events
Aura uses different events for different funnel stages. They are not duplicate snippets for the same action.
Aura also publishes a stable lifecycle vocabulary through CAPI:
AuraInterested, AuraFormQualified, AuraFormDisqualified, AuraBooked,
AuraConfirmed, AuraAttended, AuraNoShow, AuraSalesQualified, and
AuraWon. Customers can use these for custom conversions, audiences,
reporting, or future campaign optimization. AuraConfirmed means the attendee
explicitly confirmed or accepted the calendar event. It never means only that
Aura created the booking.
For a confirmed booking, Aura also sends its canonical custom event
AuraBooked. This always means the first confirmed booking for a lead and
booking link. Your workspace chooses whether the separate Meta-standard
companion is CompleteRegistration, Schedule, or none.
| Funnel moment | Meta event | When Aura sends it |
|---|---|---|
| Contact captured | Lead | The booking form is submitted successfully |
| Application completed | SubmitApplication | The qualifying form is completed, whether the lead qualifies or not |
| Unique booking | AuraBooked plus configurable companion | The first confirmed booking for that lead and booking link; the companion defaults to CompleteRegistration and can instead be Schedule or none |
| Qualified call | AuraSalesQualified plus optional Schedule | The booked call later receives a qualified outcome such as won, lost, or follow-up; Aura avoids sending Schedule here when the workspace already uses it for booking |
| Call attended | CallAttended | Aura confirms attendance from the notetaker or a manual attendance update |
| No-show | NoShow | Aura confirms a no-show and the event is enabled |
| Payment | Purchase | A payment is recorded through the supported payment lifecycle |
| Subscription | Subscribe | A recurring subscription reaches its configured conversion point |
This separation lets you compare completed forms, unique bookings, qualified calls, attendance, and revenue instead of optimizing every campaign around one ambiguous event.
AuraBooked and the Meta booking companion
A booking can intentionally produce two event names:
AuraBooked + CompleteRegistrationor:
AuraBooked + ScheduleThey are not browser/server duplicates. AuraBooked is Aura's stable lifecycle
fact; the companion matches the terminology your campaigns use. Pixel and CAPI
deliveries of AuraBooked share one event ID, and Pixel and CAPI deliveries of
the companion share another. Meta can therefore deduplicate each event while
keeping both signals available for custom conversions, audiences, reporting,
or optimization.
Configure the workspace default under Settings → Integrations → Meta CAPI. Each booking link can inherit that choice or override it in its Tracking step.
Why Lead and CompleteRegistration can have the same count
Lead and CompleteRegistration are intentionally separate:
Leadmeans the form was submitted successfully.CompleteRegistrationmeans the calendar booking was created successfully.
Their counts will match when everyone who submits the form also completes a
booking. An abandoned booking should create a Lead without a
CompleteRegistration. Adding the two event totals together does not produce a
meaningful "number of people" metric because they represent consecutive funnel
stages.
Why Aura does not fire the booking conversion on thank-you page load
Aura fires CompleteRegistration from the confirmed booking transaction. The
browser event fires when the booking request returns success, and the server
event is dispatched from the same completed-booking lifecycle.
The thank-you screen is presentation, not proof that a booking exists. Using a page load as the conversion trigger would introduce several failure modes:
- The booking can succeed even if the visitor closes the tab before the screen renders.
- Reloading the page could send the event again.
- Back-navigation could send it again.
- A rendering or network error could hide a real booking from Meta.
- A thank-you URL could be opened without creating a new booking.
Aura therefore fires at the moment it enters the successful booking state, but does not depend on the thank-you page being viewed.
Rebookings and duplicate protection
Aura counts CompleteRegistration once for each lead and booking-link pair.
The first confirmed booking atomically claims that conversion in Aura's
database. A later cancellation, retry, or rebooking by the same lead through
the same link remains visible as a real call in Aura, but does not claim another
CompleteRegistration conversion.
The stable event ID is then shared by Pixel and CAPI. These controls solve two different duplication problems:
| Protection | Prevents |
|---|---|
| Aura's database claim | Several bookings for the same lead and offer inflating the conversion count |
| Meta's shared event ID | Browser Pixel and server CAPI deliveries of one conversion being counted twice |
A genuinely different lead, or the same lead converting through a different booking link, has a different conversion scope.
How Aura matches a server event to an ad click
When permitted, Aura captures attribution and matching signals during the visitor's booking journey. Depending on what is available, these can include:
- Meta browser and click identifiers (
_fbp,_fbc, andfbclid) - UTM source, medium, campaign, term, and content
- The event source URL
- Browser user agent and request IP address
- Normalized and hashed contact fields such as email, phone, and name
Aura normalizes contact data and hashes it before including it in a Meta CAPI request. Meta uses the combined signals to match the server event to a person and, where possible, the originating ad click. Missing click identifiers do not automatically stop delivery, but they can reduce attribution and Event Match Quality.
UTM capture and persistence
UTM capture is not a switch that must be enabled on every booking link. Aura captures supported parameters when they arrive on a hosted booking URL or are passed into an embedded scheduler.
When Aura creates the booking record, it resolves UTM values from the available journey data:
- Attribution already stored with the lead.
- Attribution submitted with the booking request.
- The linked visitor session as a recovery path.
If all three sources are empty, the booking is recorded without UTMs. Common causes include:
- The ad or shared URL did not contain UTM parameters.
- A redirect removed the query parameters before Aura loaded.
- A custom iframe did not pass its host page's parameters to Aura.
- The visitor returned through a clean or bookmarked URL in a different session.
- Advertising storage was not permitted, or Global Privacy Control blocked it.
See UTM Tracking for link and embed examples.
Consent and privacy
Aura's browser and server tracking honor the visitor's applicable consent state. In regions where consent is required, advertising tracking waits for a valid grant. An explicit denial or Global Privacy Control signal suppresses advertising tracking.
Embedded schedulers can receive a supported consent decision from the host page. Passing URL parameters into an iframe is not a substitute for passing the visitor's consent state.
For California traffic, Aura applies Meta's Limited Data Use flags where required. Contact fields sent through CAPI are normalized and hashed; Aura does not place raw email addresses or phone numbers in event logs.
Delivery and retries
Aura sends server-side conversion work through a durable background process. The visitor does not wait for Meta before seeing their confirmed booking. If Meta is temporarily unavailable, Aura can retry the delivery without creating a new conversion identity.
An accepted event still needs enough matching information for Meta to attribute it to a campaign. These are separate questions:
- Was it delivered? Check whether Meta received the event.
- Was it deduplicated? Compare the browser and server event IDs.
- Was it matched? Review Event Match Quality and available identifiers.
- Was it attributed? Check whether Meta connected it to the relevant ad and attribution window.
Per-link event routing
UTM capture is automatic, but conversion routing can be configured per booking link. A link can use the organization's default Meta destination or route supported events to selected pixels. Individual lifecycle events can also be enabled or disabled according to the available Tracking settings.
This routing controls where an event is sent. It does not determine whether
the link can read utm_* parameters.
Troubleshooting checklist
A booking has no UTMs
- Open the exact landing or booking URL and confirm the expected
utm_*parameters are present. - Follow every redirect and confirm the parameters still exist when Aura loads.
- For an embed, confirm the official Aura embed passes host-page attribution and consent context.
- Confirm the visitor did not decline advertising storage or send a Global Privacy Control signal.
- Check whether the visit and booking belong to the same tracked journey.
Pixel and CAPI both appear in Meta
That is expected. Confirm that the two deliveries have the same event name and event ID. If they do, Meta has the information it needs to deduplicate them.
A rebooking appears as another call in Aura
That is expected. Aura preserves operational booking history while suppressing
another same-link CompleteRegistration conversion for the same lead.
Lead and CompleteRegistration counts are identical
Check whether any visitors submitted the form without booking. If none did, identical counts are a valid funnel result rather than evidence of a duplicate snippet.
Frequently asked questions
Does CompleteRegistration fire on form submission, slot selection, or the thank-you page?
It fires after Aura successfully creates the calendar booking. It does not fire from form submission, merely selecting a slot, or loading the thank-you page.
Does it fire again after cancel-and-rebook?
Not for the same lead and booking link. Aura's conversion claim suppresses the additional registration while retaining the new booking in Aura.
Can reload or back-navigation double-count it?
No. The event is tied to successful booking creation, not a page-view trigger.
Are Lead and CompleteRegistration duplicate events?
No. They describe successive funnel stages and should be analyzed separately.
Does a new booking link require UTM configuration?
No. It captures supported UTMs when they reach Aura. Per-link Tracking settings control event destinations and event routing, not basic UTM parsing.
Does CAPI replace the Pixel?
No. Aura uses them together where supported. The Pixel provides the browser signal, CAPI provides the durable server signal, and the shared event ID lets Meta count the conversion once.