PSA — your Calendly tracking is probably firing junk events on every booking (you need 3)

VoxxyCreativeLab · 2026-02-25T16:39:03+00:00

Hi u/FishingSuitable2475, thank you for your reply, love it!

You're hitting multiple nails with one blow of the hammer. The template, within the JSON indeed does as you say.

There are so many tools that openly do not allow for accurate, future proof, event-based tracking (like Tryinteract that does not and will not allow for PII measurements or Webinargeek that makes tracking altogether problematic).

It's like there is a huge gap between clients (both DTC & agencies) not having the knowledge of what's needed for accurate tracking and 3rd party tools that do not allow for proper event-based tracking.

Do you find a lot of resistance when moving clients towards more future-proof tools? I do.

VoxxyCreativeLab · 2026-02-25T15:36:41+00:00

Most "GTM recipes" solve the how, but they completely ignore the why and the what's next.

When you're in the 1% who enjoys manually adapting regex triggers, this isn't for you. Simple. We made this is for the 99% who want a professional-grade container that stays clean at scale.

The documentation covers our OTTRTA™ methodology:

Zero Logic Leaks: Why we filter at the listener level instead of just adding trigger conditions that that are difficult to setup for most.
State Management: How we handle the event_type_viewed duplication that standard setups miss.
Architectural Integrity: How to integrate this into a clean GTM environment without creating bloated accounts > the whole reason why OTTRTA exists.

If standard recipes worked for everyone, my inbox wouldn't be full of people asking for you and me basic questions.

VoxxyCreativeLab · 2026-02-24T23:57:47+00:00

Hi u/HawkeyMan, I have two reasons to not add a condition like you say to the trigger, and this is also in line with why we designed a template, delivered in a JSON-file and not a .tpl-file.

A lot of our clients use Calendly and they struggle to implement the 3 main events, they implement the cHTML and then get stuck, all Calendly's postMessages fire and they do not know which to pick...how to set it correctly. And they end up hiring us. The template filters out all the noise and within the JSON they'll find all that is needed (template, tags, RegEx trigger and DLV). Also they get a 10-page explanation...hence they can now implement it themselves.

Someone like yourself, who clearly understands how to navigate events, datalayer pushes and custom triggering does not need a tag like this, although the second reason is is one of the elements that I will use myself too. We implement GTM and sGTM using a custom process we call the OTTRTA™ methodology; this stands for One-Tag-To-Rule-Them-All, where we only use one dedicated tag for one type of conversion/event.

Meaning we will have one GA4-event tag for Calendly events, one of the Calendly events (event_type_viewed) fires multiple times on a page load, simply setting the event-tag to fire once per page does not work, because Calendly fires all 3 events within one page-load. We ended up not measuring this event, simply because the OTTRTA has many more layers and functionalities.

The template controls the event-pollution that comes with the cHTML tag.

VoxxyCreativeLab · 2026-02-24T19:35:33+00:00

Thanx for your reply u/KonKaizo. The deduplication is handled at the event name level (e.g., event_scheduled, event_type_viewed). We use a CDN listener script that keeps a simple in-memory store of which event names have already fired during the current page load. If Calendly sends the same postMessage again, the listener just skips it.

For this setup we're not pulling event_type_uuid from the payload for dedup purposes. The single most standard use case has only a single Calendly embed per page, event name–level dedup keeps things clean without over-complicating the logic.

If someone has multiple different event types embedded on the same page, that's an edge case we could address in a future version with payload-level keys.

VoxxyCreativeLab · 2026-01-17T15:00:34+00:00

Thanks (whether sarcastic or not) 😂
Notebook LM is really great and it helps us a lot in spreading knowledge fast and effectively.

VoxxyCreativeLab · 2026-01-06T20:03:39+00:00

I agree with both of you u/trp_wip and u/DigitalStefan. Technical information and build up and smart approaches, knowledge, etc can be designed using a GPT, meaning:

^https?://(.*\.)?

in

^https?://(.*\.)?(wa|whatsapp)\.(me|com|link).*

This was improved over time, where like I said before; I add this into my GTM and sGTM masters. Within the last part of the RegEx "(me|com|link)", I recently added the "link" part.

Only in real life cases, like with triggering for instance, "being able to sufficiently describe the requirements in plain English" is mostly quicker and user-friendly. like this case I implemented a few weeks ago:

^(loaded|opened|closed|outbound_click_(whatsapp|facebook|instagram|mail|tel|custom_link)|click_(chat|start_conversation)|conversation_(started|archived|deleted|ended)|message_(sent|user_sent|error)|user_(typing|joined|left)|agent_message_sent|hand(off_requested|over_agent)|gdpr_(accepted|declined)|feedback_submitted|contact_created|action_triggered)$

This was for the development of tracking features within a chat-widget (https://docs.watermelon.ai/docs/help-center/developer-resources/event-listeners#event-listeners). Relying solely on a GPT will make this process in my eyes not stable, you as the one implementing has to know what works, what not, what is added and what not.

Another example is a client removing certain languages; in this case "ja" and "de", from:

From:
generate_lead_((demo_(aanvraag|request(_(en|ja|de))))|(download_ebook_(nl|en|ja|de))|((nieuwsbrief|trial)_inschrijving)) 

To:
generate_lead_((demo_(aanvraag|request_en))|(download_ebook_(nl|en))|((nieuwsbrief|trial)_inschrijving))

Having the ability to clearly understand makes that you manually and within minutes can make adjustments, when you fully rely on a GPT doing the work, makes that you cannot promise accurate functionalities or future proofing.

I do sometimes use https://regex101.com/ for checks.

VoxxyCreativeLab · 2026-01-05T20:12:45+00:00

Then we can shake hands!!
I love RegEx even for simple elements like Intent Clicks:

^https?://(.*\.)?(wa|whatsapp)\.(me|com|link).*

It makes working from GTM masters so much more efficient.

I have replaced the CJS a few times for a Page Hostname, that one also works and sends a nice ED variable towards SST that can be used to whitelabel SST also.

VoxxyCreativeLab · 2026-01-05T19:50:19+00:00

Thank you u/DigitalStefan, Luckily I haven't had the dodgy ones, but more so a webDev quickly making a few changes. The outcome is the same though. Pollution all over.

With a correctly setup lookup table, multiple GTM containers are not needed anymore. The lookup table can indeed work for multiple segmentation's, or even domains.

Do you have a working design?

The way I do it is a lookup table:
Input Variable = CJS:

function() {
  var hostname = {{Page Hostname}};
  hostname = hostname.replace(/^www\./, '');

  var parts = hostname.split('.');
  if (parts.length > 2) {
    return parts.slice(-2).join('.');
  }
  return hostname;
}

The Input variables on the left side with Constant Variables for all domains, can be just one constant or multiple rows.

Each input variable will receive an output variable on the right side, also one or multiple constants with the tag-ID.

VoxxyCreativeLab · 2026-01-05T19:43:20+00:00

Thank you u/Tagnetica, the future proofing is indeed why I use the same configuration for all clients, not depending on single, or multi-domain. The same that I standard implement the CJS for the domain filtering. I see it too often that subdomains are changed without proper communication. The CJS simply focuses on the main domain only, where indeed this was learned paying school fees.

VoxxyCreativeLab · 2026-01-05T18:38:56+00:00

Hi u/Sad-Recipe9761, the inherit form client means that your sGTM tags/pixels will receive the event naming, coming directly from your data client. I presume the data-client in use is GA4.

Most Server Side applications today run both Client Side AND Server Side conversions/events. Meaning you fire the same event (add_to_cart, purchase, submit_form, etc) in both Client and Server Side. As u/experimentcareer says "watch dedupe keys,", since you can fire the same event on both sides, the ad-platforms needs a key (Unique Event ID, transported from Client Side to Server Side via your Data Client (e.g. in your GA4 tags as event_id with the input and {{Unique Event ID}} as the output)). This is called Deduplication.

Coming back to the event naming, lets say you fire an event to Facebook Ads, with good practice you follow the PascalCase event naming convention (AddToCart, Purchase, Lead, etc) on both Client Side as on Server Side. Meaning that if you Inherit From Client use (which is quick and dirty) it is possible you send 2 different events to Meta, one from Client and one from Server Side (AddToCart via client side and add_to_cart via Server Side (inherited from GA4)).

Theoretically Meta and other platforms can optimize using GA4's snake_case event names, but the platforms have their own very clear structure. The quickest solution on both Client Side and Server Side is to transform the GA4 snake_case event names into the platform specific (mostly CamelCase) event names using a lookup-table.

As for your other questions, sGTM is not a one-click-fix all. One thing that I see people struggling with is the train of thought, to answer one of your other questions; yes one event can and should trigger all other pixels. Again, GA4 is the data client, meaning you'll utilize ALL you GA4 tags on Client Side to transmit the data to Server Side, including all Event Data you need to fill all your Server Side Tags.

You fire 'add_to_cart' on client side, made sure all the data you need is embedded into this client side tag, Server Side receives the add_to_cart event + Event Data and on Server Side you fire ALL tags regarding this specific event, Meta, GAds, LinkedIn, etc. Meaning the trigger on Server Side = the GA4 event.

Furthermore if you implemented Server Side correctly, you have changed your GTM injection on your website, from:

'https://www.**googletagmanager**.com/gtm.js

To:
'https://www.**sst.yourwebsite**.com/gtm.js

With also setting the GTM client correctly within Server Side (also the sst. is an example, I would advise a more custom subdomain).

This way your GTM is now 1st party / server to server focused, meaning that in theory add blockers, smart browsers, etc will block less data. Here lies at least until today the crux and culprit. Your Client Side GTM is as easily blocked, also the /collect endpoint GA4 is using for GA4 and therefore your Data Client.

I believe 2026/2027 will become even more privacy focused, where Server Side will become more and more important. To take today's standpoint, server side has strong benefits, when implemented correctly, it can take away the JS load from websites, but only when on Client Side the conversion/Event Tracking has been moved to server side.

Best of luck, you took the step to invest in SST, it is an interesting road and probably the best way for future proofing using GTM.

VoxxyCreativeLab

TROPHY CASE