Conversion feedback

Ad platforms optimise towards whatever you can report back to them. Left alone, that's a form submission; with conversion feedback, Smileline reports the moments that actually matter — the enquiry, the booked consultation, and the patient going ahead with treatment — so Google, Meta, TikTok and ChatGPT steer spend towards clicks that become patients.

Conversion feedback is part of Smileline Core and is on by default for Google Ads, Meta and TikTok: when an owner or manager switches on the platform's ad account, Smileline turns on conversion tracking and value sharing and sets up the platform resources automatically. ChatGPT Ads stays a manual choice. Each platform page (Ads → Google Ads, Meta Ads, TikTok Ads or ChatGPT Ads) carries a Conversion tracking tab under Settings — the button at the top right once the platform is connected: the on/off toggle, the Conversion values for Lead and Booked, the setup checklist and the last 30 days of sent, skipped, held and failed events. The Share conversion values switch sits under Advanced on the same tab: turn it off and platforms still learn which leads booked and went ahead, just not what they were worth.

Turning tracking or value sharing off is permanent until someone turns it back on: reconnecting, switching accounts off and on, and the automatic setup never switch an existing choice back on.

What each platform receives

Each journey reports each moment once per platform, ever — rebooking an appointment or re-entering a stage never double-counts.

Conversion values

With value sharing on, every event carries a value in your practice's accounting currency, so platforms can optimise for value rather than volume:

Change the two fixed amounts on each platform's Conversion tracking tab, under Conversion values; each platform keeps its own. The new amount applies to every event not yet sent. Leave a field empty to send that moment without a value, or enter 0 to send a value of zero.

Which platform hears about a lead

Each platform hears only about the leads that came from it. A lead belongs to a platform when its first visit carried that platform's ad click — Google's gclid, gbraid or wbraid, Meta's fbclid (or the _fbc cookie it leaves behind), TikTok's ttclid or ChatGPT's oppref — or when it came through that platform's own instant form. A call to a tracking number belongs to the platform whose ad brought the caller to your website, and a Google click whose ID Google later rejects still counts as Google's.

A visit that carries two platforms' clicks — someone who clicked a Meta ad and then a Google ad — counts for both. Walk-ins, calls to your main number, organic visitors and leads entered by hand don't belong to any platform, so no platform receives them.

Instant forms from a campaign template

When you build a Meta instant-form campaign from a template, Smileline knows which treatment the form advertises, so every lead from it opens a journey for that treatment — on its board, with the treatment's default price as the estimated value. That is the value a Going ahead event reports until someone enters the agreed figure. A template advertising two treatments, such as bonding and veneers, uses the first.

Smileline sets this up on the form the first time it meets it, from the first lead on, and the form still shows Automatic. If you change the form's Settings yourself, your changes are kept and Smileline never sets them back; Reset to automatic brings back the template's treatment. For practices in the UK and the US, where templates are available.

Calls from Google Ads

Every Google Ads setup also has a [Smileline] Calls From Ads action. Google counts a call from a Search ad's call button as a conversion once it lasts 60 seconds or longer, and measures those calls itself — nothing about the caller is uploaded, so this works in the US too.

The action is created as a secondary one, so your other Google campaigns keep bidding on the goals they had. Only a Google Search campaign built from a template bids on it: together with [Smileline] Submitted Lead Form and [Smileline] Appointment Booked in the UK, and on its own in the US. Building one waits until the action exists.

Setups from before this action existed get it within about an hour. Events that arrive while Smileline adds it wait and are sent within about 15 minutes. If Google refuses the action, your Lead, Booking and Going ahead tracking carries on unchanged and Smileline tries again the next day. An action already named [Smileline] Calls From Ads is reused only when it is an enabled calls-from-ads action; Smileline never repurposes another of your goals.

Setup and provider requirements

1. Connect the platform under Settings. Connected means access was granted.
2. Switch on the ad account, on the Lead forms tab for Google Ads and TikTok or the Ad accounts tab for Meta and ChatGPT (for Meta, the ad account, not only the Page). The switch saves straight away. If no account appears, select Sync now; the page updates when discovery finishes. Switching on the first eligible account also turns on Conversion tracking and value sharing, bound to that account. Accounts that were already switched on before this default arrived are picked up within the hour.
3. Smileline chooses the conversion resources itself (see below) and only asks when the choice is genuinely ambiguous — for example, several CRM datasets or Pixels. Then the checklist asks you to choose, and turning tracking on opens Choose conversion resources first. The button stands out until the platform's resources are chosen. If a prerequisite is missing, the checklist explains it and Review account setup opens the tab with the account's switch.
4. The open page updates when background setup finishes. Select Refresh status to check setup and delivery again if needed. Delivery not verified yet means setup has finished but the platform has not confirmed an eligible event. Healthy appears only with tracking enabled, setup complete and delivery verified. The Sent · 30 days count records accepted events.

If the connection is missing the permissions conversion events need, Smileline keeps the setup waiting instead of dropping it: the checklist asks you to reconnect, and setup resumes as soon as the reconnection grants them — with your tracking and value-sharing choices unchanged.

Automatic setup follows the same rules as a manual choice:

• Google Ads: it uses three goals named [Smileline] Submitted Lead Form, [Smileline] Appointment Booked and [Smileline] Treatment Started. It reuses one that is already there only if it is still an enabled upload goal of the right category that counts every conversion; otherwise it creates it. If that name is taken by a goal it can't reuse — for example one you removed or changed — the new goal gets a short code after its name, such as [Smileline] Appointment Booked (1bdb243c). It never takes over one of your other goals. Renaming a goal in Google Ads is safe: Smileline keeps track of it by its ID. It also sets up the calls action — in the US, only that.
• Meta: it uses the one available, business-owned CRM dataset linked to the ad account. With none, the checklist shows the Events Manager steps below; with several, it asks you to choose. It never creates a dataset on its own.
• TikTok: the website Pixel and the CRM Event Set are resolved separately, each only when its permissions are available. One existing resource is reused, none means one is created — named [Smileline] Website or [Smileline] CRM — and several ask you to choose.
• Google Ads, Meta and TikTok: setup runs only while the ad account is switched on in Smileline. If it is switched off, the checklist asks you to switch it on first, and nothing is set up on that account meanwhile.
• A failed or incomplete inventory read is a setup failure, never an empty account.
• Google Ads accounts managed through a manager account: Smileline sets up conversions only in the advertiser account itself. If a manager account tracks conversions for the account (cross-account conversion tracking), its goals are shared with every other business it manages, so Smileline neither lists nor changes them. Setup stops with a message explaining this; let the account track its own conversions in Google Ads, then choose Try setup again. Enquiries from your ads keep arriving meanwhile.

You can open Choose conversion resources at any time, including while lead forms are syncing, to choose or change destinations or create a new resource for Smileline. A new Meta dataset is named [Smileline] CRM followed by the ad account ID. If a usable resource Smileline created under that name is already there, Smileline reuses it instead of making a duplicate. Smileline checks the live inventory again before saving; a failed inventory is never treated as an empty account. It remembers confirmed choices across retries and reconnections. Missing selected resources require repair or a new explicit choice, rather than switching to another account's resource. Apply setup only after reviewing the platform terms linked in the dialog.

Try setup again replaces Refresh status while setup has failed. It only restarts setup: it never changes tracking, value sharing or your resource choices, so it cannot undo a change a colleague made in the meantime. If setup changed since the page loaded, Smileline asks you to refresh first.

Creation requests retain a durable identity. If Meta or TikTok creates a resource but its response is lost, Smileline reconciles the inventory instead of creating duplicates. Unfinished setup with a saved choice — yours or the automatic one — stays visible and gets another automatic recovery window after the initial retries. Recovery keeps the chosen resource; it never silently chooses a different existing resource. This stops when tracking is disabled or setup succeeds.

Google is preparing your conversion actions is a temporary setup state: new actions can take up to six hours to become ready. Smileline saves eligible events and sends them automatically afterwards. This waiting state disappears when the preparation window ends; it is not a delivery error.

If the account is disabled, enable and save it first. Reconnecting Google is only needed when the connection or permissions checklist asks for it.

Smileline provisions the supported resources through each platform's API. The connected user and developer app must still have the provider permissions described below:

• On Google Ads it detects the conversion customer from the selected serving account, shows that customer in the checklist and lists conversion actions there. In Choose conversion resources you can pick a different goal for Lead, Booked and Going ahead, or create new ones. Goals you select there are enabled and assigned the matching funnel category, counting every conversion and accepting uploaded values. These edits also affect other integrations using those goals; bidding and attribution settings are preserved. Website and GA4 goals cannot be changed into upload goals. Event delivery uses Google's asynchronous Data Manager API and remains held until Google reports a successful request status.
• On Meta, setup uses the ad account's one linked CRM dataset. In Choose conversion resources you can pick another available, business-owned CRM dataset, or create a new CRM-enabled dataset in that ad account’s owning business and link it to the account. Website Pixels and unavailable datasets are shown as incompatible; setup cannot convert them. Native lead outcomes include Meta's original lead ID and CRM source markers.
• Smileline creates the dataset without a dataset category. Missing business access or a required provider review appears in the checklist. An uncertain creation is reconciled from Meta’s inventory on retry instead of creating another dataset; after the fast retries, Smileline checks again in a new 24-hour recovery window while tracking remains enabled. You can also review it in Events Manager and select the correct dataset.
• When the ad account has no usable CRM dataset, or Meta refuses dataset creation, the checklist says so and Technical details shows the setup error code. Ad permissions alone do not prove access to create datasets in the owning business. A Business admin opens Events Manager → Connect data sources → CRM, creates a CRM dataset and shares it with the ad account and connected user. Then select that dataset under Choose conversion resources and choose Apply setup. Try setup again preserves your saved choice: after a failed Create a new resource for Smileline request, it retries creation rather than selecting the admin's dataset. Reconnecting Meta with the ad permissions also restarts setup that was waiting on them.
• On TikTok, setup reuses or creates the website Pixel and the CRM Event Set for the advertiser. In Choose conversion resources you can choose the advertiser and pick either one yourself. Each path appears only when its permissions are available. TikTok permits up to 50 CRM Event Sets per advertiser.
• On ChatGPT it creates a conversion source named Smileline, uses that source's public pixel for browser and server events, creates the three event settings named above with a 30-day click window, and stores a separate Conversions API key encrypted. A rejected server key rotates automatically; the management connection does not need reconnecting. See ChatGPT Ads.
• Google remains Delivery not verified yet until Data Manager reports a successful asynchronous request status. This can remain pending after the first event is submitted, while Google processes it. Meta and ChatGPT require the first accepted real event. TikTok can also use an optional Test event code under Advanced for its website Pixel; native CRM verification still depends on a real attributed lead.
• Disconnecting ChatGPT keeps its Conversions API key stored encrypted, so reconnecting the same ad account needs no re-provisioning. Connecting a different ad account discards the previous account's pixel, event settings and key.

TikTok accepting a CRM Events API request proves delivery to the Event Set, but it does not complete lead-quality optimisation. In TikTok Events Manager:

1. Open the selected CRM Event Set.
2. Map SmilelineLead, SmilelineBooked and SmilelineWon to TikTok's four CRM funnel stages.
3. Wait up to 10 minutes, then confirm Attributed events shows more than zero matched events.

Smileline keeps CRM verification awaiting until this provider-side mapping and attribution check is complete. The website Pixel and native CRM paths use separate permissions, so a provider-action warning on one path does not stop the other.

Website leads deduplicate with your pixels: when an enquiry arrives through the tracking script, its browser event ID is reused for the Lead event, so a platform that also saw a pixel fire counts one conversion, not two.

Meta match quality

Meta scores how well it can match your events to people on Facebook and Instagram (Event match quality in Events Manager). Besides the hashed email, phone, name and click ID, Smileline sends Meta:

• External ID — a hashed ID of the enquiry, the same on its Lead, Schedule and Purchase events.
• Date of birth, gender and county — hashed. A Lead from a website enquiry form sends them only when the form collects them; Booked and Going ahead events, and Meta instant-form leads, use the patient record.
• Browser ID (fbp) — the Meta Pixel's _fbp cookie when the enquiry carried it, otherwise one derived from Smileline's own visitor ID.

To raise the score further:

• Install the Meta Pixel on your website. The pixel's real browser ID matches far better than a derived one. The tracking script picks the _fbp cookie up by itself; a website that posts its forms through its own server should forward the _fbp and _fbc cookie values as the fbp and fbc parameters.
• Ask for a postcode, and optionally a date of birth, on your enquiry form.

What is never sent

Smileline checks every event at the moment of sending and skips it when one of these applies:

• Junk — journeys marked as junk, and archived journeys. See Junk marking.
• Declined — the lead said no. Submitting your form counts as permission to share the conversion with the platform the lead came from, so an event is sent unless the enquiry itself refuses: a visitor who clicked Reject on your cookie banner, a browser sending Global Privacy Control, or a form or integration whose _sl.consent sends false for ad_storage, ad_user_data or ad_personalization — or advertising: false, which covers all three. A cookie banner the visitor never touched is not a refusal.
• No identifiers — the lead didn't come from this platform (see Which platform hears about a lead). Contact identifiers and personal details are irreversibly hashed before transmission; raw contact details are never sent.
• History — only journeys created after conversion tracking is first switched on (automatically or by you) ever send a Lead event. Smileline never uploads your historical pipeline.
• US practices — nothing is sent for a practice in the United States, whatever the switch says (see the note above). Google still counts calls from ads itself.

Junk marking

A junk enquiry — spam, a competitor, a wrong number — is exactly what you don't want a platform optimising towards. Two things mark it:

• Mark as junk… in a journey's actions menu — on a journeys-board card, in the journey dialog, and in a patient's journey list. You can add an optional reason (up to 500 characters); it shows under the journey in the patient's journey list. The same menu offers Unmark junk, and junk journeys carry a subtle Junk badge.
• A not-proceeding reason can be flagged Marks as junk under Settings → Not-proceeding reasons, so closing a journey with that reason marks junk automatically.

If your practice works with a Smileline partner, the partner sees each junk lead that arrived after you joined them — with the lead's name and your reason, or the not-proceeding reason you closed it with — in their lead reports. Unmarking a journey withdraws it.

Marking a journey as junk immediately stops any of its unreported events. Lead events deliberately wait 15 minutes before sending, so front-desk triage beats the upload — mark junk within that window and the platform never hears about the lead at all. Unmarking doesn't resurrect events that were suppressed, but the journey's later moments report normally.

When you merge two records of the same person, the journey closed as a duplicate stops its unreported events too. The log shows them as Duplicate record merged — not sent, never as junk.

Timing and guarantees

• Lead waits 15 minutes (the junk-triage window). Booked sends immediately. Going ahead waits about a minute, so an undo on Today can still cancel it, or an hour when value sharing is on, giving staff time to enter the agreed treatment value. Values resolve when the event is sent, not when the moment happens.
• If going ahead is undone, or the journey reopened, before its event was sent, the event is withdrawn.
• Delayed queue messages cannot block newer events. A stalled delivery handoff is counted under Held · 30 days and retries automatically when its 24-hour handoff window resets, within the provider’s acceptance window. Retries retain the original event identity so the platform can deduplicate them.
• Temporary connection failures are rechecked automatically. Missing or revoked permissions still require the account owner to reconnect; the checklist explains that action. Repair and recovery states explain what Smileline is doing, and provider error codes are available under Technical details.
• Events waiting for the provider connection or conversion setup appear as Held, with the reason beside the event, and count towards Held · 30 days. Complete the action shown above the log; eligible events resume automatically. Queued means the event is waiting for its scheduled send, including the Lead triage window.
• Delivery runs in durable seven-day slices. One that cannot be delivered in its current slice is set aside and counted — never silently dropped. Google automatically reopens recoverable work while its provider identifiers remain acceptable (up to 90 days for click identifiers or 63 days for enhanced-conversion user data). TikTok also reopens its bounded slices because TikTok's CRM postback documentation does not specify a hard event-age cutoff. Meta and OpenAI reject events older than seven days, so their hard window runs from the conversion moment; an event that can no longer be accepted is marked skipped as stale instead of being retried forever.
• If a platform restricts its dataset (Meta does this while it reviews an advertiser), events are held, not lost — the checklist warns "Meta has limited this dataset — events are held, nothing is lost". Smileline re-tests hourly and delivers the held events as soon as the restriction lifts.
• TikTok Instant Form outcomes that still need the provider's CRM Event Set route are also held individually; they do not block website events in the same batch.
• Google submissions stay pending after the initial API acknowledgement until Data Manager diagnostics report success. Processing, partial-success and resource errors remain durable: recoverable credentials and resources are revalidated or reprovisioned, while unresolved rows stay visible for replay.
• OpenAI server-key authentication failures trigger a fenced key rotation and re-arm the affected rows with their original event IDs and deadlines.
• Held · 30 days counts events Smileline will send again by itself. Failed · 30 days counts events that won't be re-sent automatically; the checklist then says so, and the conversion log shows why.

Automatic recovery

Held events are sent again on their own as soon as the platform can accept them — after setup succeeds, after you reconnect with the missing permissions, or when a platform that was refusing events accepts one again. Smileline works through every held event for that platform, page by page, until none are left; it never stops at a fixed number.

Each event keeps its original event ID and time, so the platform counts it once. Recovery only happens inside each platform's window: for Google, up to 90 days after the enquiry was captured for click identifiers (63 days for enhanced-conversion user data), seven days after the conversion moment for Meta and ChatGPT, and without a fixed cutoff for TikTok. An event whose window has closed is marked as such instead of being retried. If the practice has switched to a different ad account since the event happened, the event is not sent to the new account; it appears as failed in the conversion log. Recovery means Smileline sends the event again — the platform still decides whether it matches.

When Google rejects an ad click ID

Google sometimes reports that an event's click ID (gclid) is invalid. Smileline then keeps the rejected ID on record but never sends it again, and re-sends the event with what remains: another Google click identifier, or the hashed email and phone number unless the visitor declined, while the event is still within Google's 63-day window for that data. The event keeps its original ID and time. When nothing usable is left, the event is marked as an unmatched click.

Conversion log

The Conversion log sits below the card on each platform's Conversion tracking tab once tracking has been switched on at least once. It lists the Lead, Booked and Going ahead events of the leads that came from that platform, newest first. Select Filter to narrow it by Status, Stage, Patient name or Date; each filter shows as a chip you can click to change or remove, and Clear removes them all. A patient name never matches a row whose personal details have been removed.

Each row shows:

• the outcome: Queued, Sent (Google has received it and is still processing), Accepted, Skipped, Held (Smileline will send it again automatically) or Failed;
• the stage, the patient and the ad account it was sent to;
• the campaign the lead came from, when the lead's first visit or form names one. It's the same campaign the Patients list shows, and it stays visible after the patient's personal details are removed.

Expand a row to see the platform's answer: its outcome, error or diagnostic codes, counts such as events received, and the request ID to quote to the platform's support. Smileline stores only these codes, counts and IDs — never the platform's raw message text, which can repeat the contact details it was sent. Skipped rows explain why in plain words. A consent skip means the lead declined. Older events skipped under the earlier rule, when unknown consent still stopped an event, keep the explanation they were given then. When an older event's consent evidence has been removed, the log uses the unavailable explanation rather than claiming a refusal.

After 30 days a finished event's personal details are removed. The row keeps its outcome and the platform's answer but no longer shows the patient.

Conversion feedback also powers managed campaigns: campaigns Smileline creates optimise towards the Booked event rather than raw form fills. A Google Search campaign built from a template optimises on calls from ads, Lead and Booking together in the UK, and on calls alone in the US.

WhatsApp qualified leads

Click-to-WhatsApp ads open a WhatsApp chat instead of a form. When your team decides a chat from one of those ads is a real enquiry, they can tell Meta, so Meta shows your ads to more people like that person. Available to practices in the UK and the EU; not in the US, for the same health-data reasons as above.

1. An owner or manager turns on Report qualified leads to Meta for the WhatsApp number under Settings → Channels. Turning it on confirms your practice has a lawful basis (legitimate interest) to share this with Meta. If the WhatsApp connection doesn't yet allow it, reconnect WhatsApp and allow lead reporting when Meta asks.
2. In the inbox, a chat that began from a WhatsApp ad shows WhatsApp ad lead in the contact panel. Once the conversation shows a genuine enquiry, select Mark qualified lead.

Smileline sends Meta one QualifiedLead event for that ad click — only Meta's own click ID and your WhatsApp account, never the person's name, number or messages. Marking the chat again doesn't send a second event. Nothing is sent if the person has opted out of WhatsApp messages, if reporting has been turned off, or if the WhatsApp number was moved to another WhatsApp account; the panel says why.

The panel shows the report's outcome: Reported to Meta, Sending to Meta…, Couldn't report to Meta with Retry, or Meta didn't confirm this report. Meta doesn't remove duplicate WhatsApp reports, so when Smileline can't tell whether Meta received one, it never resends it on its own — Send again is your decision, and it may count the lead twice. Meta only accepts a report for seven days; after that the panel shows Too old to report to Meta. If Meta restricts lead reporting for your account (it limits some health businesses), nothing is sent and the settings card says so.