See where your bookings come from. Tymeslot tracks visits and conversions on your booking pages with UTM parameters. It sets no cookies, stores no IP addresses and loads no third-party scripts.
Tymeslot's built-in analytics show which campaigns, channels and partners lead to bookings, not only to clicks.
Visits, unique visitors, bookings and a per-source conversion table are recorded on every booking page you publish, and shown under Dashboard → Analytics.
No cookies on the visitor's device, so no consent banner is needed.
No IP addresses stored: unique visitors are counted with a hash that changes every day.
No third-party scripts; the data stays in Tymeslot.
🏷️
1
Tag your booking links
Append
utm_*
parameters to any booking link you share: in newsletters, ads, social posts, partner pages or email signatures. Tymeslot carries UTM and referrer information through the booking flow as long as the visitor follows links from the tagged URL.
The five standard UTM parameters are supported:
utm_source:
where the traffic came from (e.g. newsletter, linkedin, partner-acme).
utm_medium:
the channel type (e.g. email, social, cpc).
utm_campaign:
the campaign name (e.g. spring-launch).
utm_content:
used to differentiate creatives or placements within a campaign.
You don't need to pre-register custom URL parameters. Anything beyond the five standard UTM keys is stored in a separate set of tracking parameters on the visit and on the resulting booking. Use them for affiliate IDs, A/B test variants or your own ad-platform click IDs.
📊
2
What gets tracked on each visit
When a visitor lands on one of your booking pages, Tymeslot records one page view with just enough context to attribute the visit, and nothing more.
UTM parameters:
the five standard UTM fields from the URL, if present.
Custom tracking parameters:
any non-UTM query parameters, kept as-is in a small JSON bag.
Referrer host:
just the hostname (e.g. google.com), never the full URL.
Browser family and device type:
a coarse bucket like chrome, safari, or firefox, plus whether the device is a desktop, mobile or tablet. No browser version, operating system or device fingerprint.
Visitor session hash:
a one-way hash of the IP address, the user agent and a random salt for the day. It is used only to count unique visitors within a day. Each day's salt is deleted once the day is over, so the hash cannot be traced back to the IP address.
Timestamp: when the visit happened.
🛡️
3
What is deliberately not tracked
This list matters as much as the one above. Tymeslot's analytics are built to collect as little as possible, so there is little for a privacy review to find.
No IP addresses:
the IP address is used for a moment to compute the visitor hash, then discarded. It is never written to the database.
No cookies:
Tymeslot sets no analytics cookies in the visitor's browser, and uses neither localStorage nor fingerprinting scripts.
No cross-site tracking:
visits are recorded only on your own booking pages, and the data stays in your Tymeslot instance.
No bot traffic:
common crawler user-agents are filtered out before a row is written, so your conversion numbers reflect real humans.
No consent banner needed
Because there are no cookies and no persistent identifiers, this kind of tracking falls outside the scope of the EU ePrivacy Directive's consent requirement. You don't need a cookie banner to run it. (Your local rules are still your call, but there is nothing here to consent to.)
📈
4
View the dashboard
Sign in to Tymeslot and open Dashboard → Analytics
from the left sidebar. The page covers all your booking pages over the last 7, 30 or 90 days.
Summary cards and the visits-over-time chart for the selected window.
Summary cards:
visits, unique visitors, bookings and the estimated conversion rate for the selected period.
Visits over time:
a day-by-day chart that shows the effect of a campaign launch or a quiet weekend at a glance.
Traffic sources:
every
utm_source
that sent traffic in the period, with visits, bookings and conversion side by side. Untagged traffic appears as its own row, (direct / unknown). A separate
Devices
breakdown splits visits into desktop, mobile and tablet.
The sources table attributes visits and conversions to each utm_source.
UTM parameters travel with the booking flow
Tymeslot carries UTM and referrer information through the booking flow as long as the visitor follows links from the tagged URL. When the booking is completed, the parameters present at that point are saved on the booking.
❓
Frequently Asked Questions
Do I need to enable anything to start collecting analytics?
Not on tymeslot.app: tracking is on for every booking page, and the dashboard fills in as soon as you share tagged links. The Analytics page is part of the Pro plan. Self-hosted instances start with analytics off; see the self-hosting question below.
Will this slow my booking pages down?
No. The page view is written in the background after the page has loaded, so it never delays the booking flow, and there are no third-party scripts to load.
Can I see analytics for a specific meeting type only?
Not yet. The dashboard combines all your booking pages. Each visit is already recorded with its meeting type, so a per-meeting-type breakdown can be added later.
What does the conversion rate represent?
It's visitors who booked ÷ unique visitors
within the selected period: the share of distinct visitors who completed a booking. The dashboard labels it an estimate because the two counts come from separate records; it never shows more than 100%.
Can I export the data?
Not from the UI today. If you self-host, the underlying
analytics_events
table and the
utm_*
columns on
meetings
are queryable directly from your own Postgres.
I self-host. How do I turn booking analytics on?
Booking analytics ships disabled
on self-hosted instances. An admin turns it on under /admin/settings → Analytics → Booking analytics; the change applies immediately, without a restart. If you build from source,
config :tymeslot, :booking_analytics_enabled, true
sets the same default. Review your privacy policy before you enable it. No secret is needed: each day's visitor-hash salt is generated
at random and deleted once the day is over. Earlier versions required ANALYTICS_SALT_SECRET; it is no longer read and can be removed.
Does this work with the embedded booking widget?
Visits and bookings through the widget are recorded, but not attributed to your campaigns. The widget loads your booking page in an iframe and does not pass on the UTM parameters of the page that hosts it. To measure a campaign, share a tagged link to your booking page itself. See the
Widget Embedding
guide for details.
