Skip to main content

Meaningful ads tracking and Dentally Portal update - major issues for digital advertising with google / meta

  • Aug 24, 2026 12:01 PM UTC
  • 3 replies
  • 95 views

Forum|alt.badge.img+2

I wanted to raise this as a feature request because the lack of meaningful tracking within Dentally Portal has become a major issue and restriction for practices using digital advertising.

When patients move from our website into the hosted Portal, we lose visibility of what happens next. We cannot reliably track whether someone starts the booking process, selects an appointment, completes payment or confirms their booking.

There is no practical way to add or meaningfully integrate GA4, Google Ads tracking, Google Tag Manager or Meta Pixel. The Portal also does not retain and pass through identifiers such as GCLID, GBRAID or WBRAID, which makes accurate attribution extremely difficult (and expensive)

We have explored webhooks, Zapier and offline conversions, but there does not appear to be a reliable workaround. Without the original advertising identifier, bookings cannot be confidently connected to the advert or campaign that generated them. Matching using email addresses or telephone numbers alone is not a dependable substitute.

This means practices can (and are) spending thousands of pounds each month on Google and Meta advertising without being able to tell the platforms which patients actually completed a paid or confirmed booking. Google and Meta are then left optimising towards clicks and basic leads rather than genuine bookings, creating a significant amount of wasted ad spend.

We have experienced this restriction for approximately three years. Given how important online advertising and accurate attribution have become, I think it is reasonable to have expected this to have been resolved by now.

I appreciate that previous replies have said the integration is on the roadmap, but at this stage we do not really need another confirmation that it is being considered. We need clarity on when it will actually be delivered and confirmation that a working solution has now been prioritised.

Dentally Portal is otherwise a useful part of the system, but this limitation significantly restricts its value for any practice trying to measure and scale its marketing properly

3 replies

Ysy Lees
Community Manager
Forum|alt.badge.img+4
  • Community Manager
  • Sep 10, 2026 3:49 PM UTC

Hi Fahad, I understand your feedback and appreciate you passing this on. Google Analytics is being actively worked on as part of the roadmap to support practices being able to track analytics and it will be released as part of wider Online Booking improvements this year. As soon as we approach release, I will aim to provide an exact date as this is being worked on currently.


Forum|alt.badge.img+2

Hi Fahad, I understand your feedback and appreciate you passing this on. Google Analytics is being actively worked on as part of the roadmap to support practices being able to track analytics and it will be released as part of wider Online Booking improvements this year. As soon as we approach release, I will aim to provide an exact date as this is being worked on currently.

Hello

Can you give us an indication as to when. This is the sort of thing we need to get on top of asap. If it's not close enough we will probably leave dentally. As its essential for what we have planned 


Forum|alt.badge.img
  • Newcomer
  • Oct 22, 2026 9:06 PM UTC

​@Fahad-TheSmileDesigners, you're right that email and phone aren't a dependable substitute for the click ID. Sent to Google as the identifier, they get matched against the same details your own tag saw submitted on your own site, and on the Portal flow your tag never sees them. Your side of that match is empty, so Google falls back to signed-in account data for whoever it can recognise that way. That's the route you tried, and it behaves exactly as you found.
The second use for them doesn't involve Google at all. You keep them on your side only, as the thing that pairs a booking back to a click ID you stored yourself. Capture the click ID when someone lands from an ad, take name, email and phone on your side before they go through to Portal, and hold the two together. When the appointment webhook comes back carrying that email and phone, you look up which click it belongs to and send Google the click ID. Their own guidance says the click ID is "required if you are not implementing a tag to collect user-provided data", which is your situation exactly. The identifier never has to survive the Portal, because it never goes in.
It costs you a step between the ad and the booking, which is real friction and will lose you some. And it only gets you the completed booking, not the steps inside Portal, so starts, slot selection and payment stay dark until dentally opens that up. What it does give back is contact details for everyone who reached that point, including the ones who never finish, and those are invisible to you now.
One thing moving underneath this. From 15 June 2026 Google is shifting offline conversion imports and enhanced conversions for leads uploads onto its Data Manager API and blocking them in the Google Ads API. If you're going through Zapier, their team have said the full switch-over is March 2027 and there's nothing to change today. It does mean anything built from here wants building against the new API and not the old one.
If you want to confirm the current setup is failing the way I've described rather than for another reason, the enhanced conversions diagnostics report in Google Ads names it: "No user-provided data matches" and "Tag not firing on forms". Check the customer data terms are accepted on the account too, since that's a prerequisite.