Aura LogoAura

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 ID

Seeing 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 momentMeta eventWhen Aura sends it
Contact capturedLeadThe booking form is submitted successfully
Application completedSubmitApplicationThe qualifying form is completed, whether the lead qualifies or not
Unique bookingAuraBooked plus configurable companionThe first confirmed booking for that lead and booking link; the companion defaults to CompleteRegistration and can instead be Schedule or none
Qualified callAuraSalesQualified plus optional ScheduleThe 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 attendedCallAttendedAura confirms attendance from the notetaker or a manual attendance update
No-showNoShowAura confirms a no-show and the event is enabled
PaymentPurchaseA payment is recorded through the supported payment lifecycle
SubscriptionSubscribeA 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 + CompleteRegistration

or:

AuraBooked + Schedule

They 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:

  • Lead means the form was submitted successfully.
  • CompleteRegistration means 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:

ProtectionPrevents
Aura's database claimSeveral bookings for the same lead and offer inflating the conversion count
Meta's shared event IDBrowser 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, and fbclid)
  • 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:

  1. Attribution already stored with the lead.
  2. Attribution submitted with the booking request.
  3. 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.

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.

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

  1. Open the exact landing or booking URL and confirm the expected utm_* parameters are present.
  2. Follow every redirect and confirm the parameters still exist when Aura loads.
  3. For an embed, confirm the official Aura embed passes host-page attribution and consent context.
  4. Confirm the visitor did not decline advertising storage or send a Global Privacy Control signal.
  5. 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.

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.

On this page