Site and event tracking

Connect a website

Open Surfaces → Site & event tracking → Add website. Enter a name and each allowed website. HTTPS is added when you enter a bare domain. For Jessica's website, use https://jessicaberchtold.com and https://www.jessicaberchtold.com. Domains are exact: add each subdomain separately, without a path. Wildcards are not supported. After saving, use Add website URL or the remove icon to update the allowed list; keep at least one domain.

Copy the Website tag to the site's shared template or script manager. This tag runs apart from chat and Google Analytics. Add the app's origin to the site's script-src and connect-src rules.

The tag waits for consent before storing a visitor ID or sending any events. Connect your existing consent manager to the following calls, after the tag loads:

// Inside your consent manager's analytics-consent callback:
window.BerchtoldTracking?.consent(analyticsConsentGranted === true)

If your consent manager initializes first, listen for berchtold:tracking-ready and apply the current consent choice there as well. Reapply the current choice on each page load. Never grant consent unconditionally. A Global Privacy Control or Do Not Track signal keeps collection off.

Control collection and check status

Site tracking records page views and clicks on links or marked buttons. Event tracking records custom events by name. You can pause each on its own. Paused channels reject new events, even from tags already on the site. Past events stay on Contacts.

Check each channel for its state: Paused, Awaiting first event, Receiving activity, or No activity in 24 hours. The state reflects that channel's last event. Linking a visitor to a Contact does not count as an event. Use the refresh icon to check again, or return to this tab.

Identify a contact

The tag cannot tell who a visitor is. Your server must link them to a Contact. An IP address, URL or form field alone is not proof of who they are.

1. Expand Consent & contact identification in the tag panel. Copy the server key to a secret store on your website's server. You can view it only once. A new key stops the old key and unused tokens from working.
2. After a trusted inquiry submission or authenticated sign-in, read BerchtoldTracking.getVisitorId() in that visitor's browser. It returns null without consent.
3. Your website server uses the Contact ID or email it has validated to request a token. The Contact must already exist in this workspace; tracking does not create Contacts.

// Website SERVER code. APP_ORIGIN, SITE_ID and SERVER_KEY are server settings.
const response = await fetch(`${APP_ORIGIN}/api/tracking/${SITE_ID}/identify`, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${SERVER_KEY}`,
  },
  body: JSON.stringify({
    visitor_id: visitorId,
    contact_id: validatedContactId,
    // Alternatively send email, but never both contact_id and email.
  }),
})
if (!response.ok) throw new Error("Contact identification failed")
const { identity_token } = await response.json()
// Return only identity_token to that visitor's browser.

4. In the browser, call await BerchtoldTracking.identify(identity_token). Tokens last 30 minutes and are bound to that site and visitor. The server remembers the identified visitor for up to 30 days of inactivity. Recent anonymous events then appear in the Contact record, along with future events.

Your server must verify who the visitor is. Do not let anyone submit an email or Contact ID and get a token for that person. Keep the server key out of browser code, page markup, tag managers and URLs.

Call BerchtoldTracking.reset() on logout or before someone else uses the browser. When a visitor withdraws consent, call BerchtoldTracking.consent(false). This stops new events and clears the local visitor ID. Past events stay on the Contact.

Capture pages, clicks and events

Page views include ordinary navigation and path changes in single-page applications. Link clicks record the page and destination. Give a button a stable event name to capture its click:

<button data-crm-event="request_tour">Request a tour</button>

After your website confirms a meaningful action, record a named event:

BerchtoldTracking.track("tour_requested", { listing_id: "123" })

Use data-crm-ignore on an element or container to omit its clicks. Do not load the tag on sensitive pages. Form values, page text, passwords, URL query strings and fragments are not collected automatically. URL paths are recorded; avoid putting personal data in paths. Keep custom names and properties free of personal or secret information.

Review activity

Open the Contact's Recent activity panel. Under Activity type, check Pages viewed, Clicks, or Custom events. You can also check Notes, Tasks, Automations and Record changes. All activity selects every type. Uncheck it to clear all types. Each entry shows the time, site and page. Clicks also show the target link when present. Event details shows the cleaned referrer and fields sent with the event. Use Refresh activity to see new events. Use Load older activity to see past pages.

Notes, tasks and record changes also appear here. New events from our built-in automations appear here too. This release does not show email, SMS or past ActiveCampaign activity. Site events do not start automations yet.

Verify and troubleshoot

• Open the live site and grant consent for analytics. Visit a page and click a link. Surfaces should show Receiving activity and the time of the last event. Events will not appear on a Contact until the site links the visitor to one.
• Complete the site's identity flow and open the resulting Contact. Verify the previous page view and a new click. Repeat on mobile.
• If no events arrive, check consent and privacy signals first. Check the allowed origins, tag URL and site security rules. Make sure tracking is not paused. Listen for berchtold:tracking-error to learn why an event failed.
• If events arrive but the Contact has no activity, check the server's visitor link. Make sure the Contact exists and is not archived.
• Keep the same visitor ID through identification. Reset before switching people; known visitors cannot be silently reassigned.

The pilot keeps up to 50 events per unknown visitor for 30 days. Site events expire after 365 days. Firestore TTL rules must be deployed to delete them, and deletion is not instant. Notes and other CRM events do not expire this way. Send at most 20 events per request. Daily limits are 2,000 events per visitor and 50,000 per site.