Docs

Domains and identity

List every hostname your product runs on. ClickClacks only accepts events from those, and follows one person across them when they click from one to another.

Allowed domains

Each source has a primary domain, and you can add more under Anywhere else your product runs when you create it. Later, add domains on the Identity page in Sources. The data-domains attribute in your snippet is built from the domains of every website and web app source in the project, plus any extra domains you added, so the tracker knows which hostnames belong together. (If you switch off Carry identity between these domains on the Identity page, each source’s list is just its own domain.)

html
<script async src="https://app.clickclacks.io/c.js" data-key="ck_live_8f3a2c" data-domains="acme.com,www.acme.com,app.acme.com"></script>
  • Entries are exact hostnames. There are no wildcards, and acme.com, www.acme.com and app.acme.com are three separate entries. List each one visitors actually see in the address bar.
  • Unlisted hostnames are rejected. On a hostname that isn’t in data-domains, the tracker doesn’t start. On the server, events whose origin isn’t in the source’s saved list are refused, so a copied snippet can’t pollute your data.
  • Both lists need the domain. The browser checks the attribute; the server checks the saved list. After adding a domain in the app, copy the updated snippet from the source, or add the hostname to data-domains yourself.

One person across domains

A project is one product, and its sources share one pool of people. That’s what lets a funnel start on your marketing site and finish in your app. The tracker keeps its anonymous ID in the browser’s local storage, which browsers keep separate for every hostname, so acme.com and app.acme.com can’t read each other’s. ClickClacks bridges the gap through links instead:

  1. 01Click

    A visitor on acme.com clicks a link to app.acme.com. Both hostnames are listed.

  2. 02Tag

    The tracker adds a _ccid parameter to that link, carrying the visitor’s anonymous ID and session.

  3. 03Adopt

    On app.acme.com the tracker checks the visit came from a listed domain, adopts the IDs, and removes _ccid from the address bar.

No markup changes are needed, on your side or in any site builder. The rest of the link’s query string is left as it was. The first pageview after the hop records the domain the visitor came from.

This works the same between subdomains of one domain (acme.com to app.acme.com) and between entirely different domains (acme.com to getacme.io), as long as both hostnames are listed.

Where carry-over stops

Identity only travels on a link click between two listed hostnames. It doesn’t carry when:

  • The visitor doesn’t click a link. Typing the address, opening a bookmark or following a link in an email starts a new anonymous visitor. So does navigation done in script (for example setting location.href) or a form submission, because only <a> links are tagged.
  • A hostname isn’t listed. Links to it aren’t tagged, and the tracker doesn’t run there.
  • The referrer is removed. The destination only accepts the ID when the browser reports a listed domain as the referrer. A link with rel="noreferrer", or a Referrer-Policy of no-referrer, stops the hand-off.
  • The hop is into a native app. ClickClacks follows people from web to web. Mobile app sources are marked coming soon in the app.

The ID you set with identify is stored per hostname too, and isn’t part of the hand-off. Call identify on each domain where the person is signed in.

The carry-over rate

Rather than asking whether your domains are set up correctly, ClickClacks measures it. The carry-over rate is, of the people who followed a link from one listed domain to another and arrived within 30 minutes, the share whose first event already carried an ID ClickClacks knew. It’s shown as Is it working on the Identity page, and below 80% it is flagged. The rate appears once enough real linked arrivals have been seen.

Serve from your own domain

You can serve the tracker from a subdomain of your own, such as cc.acme.com, instead of app.clickclacks.io. A project has one custom domain, shared by all of its sources. Set it up in Settings → Custom domain:

  1. Enter a subdomain. A bare apex domain such as acme.com isn’t accepted.
  2. At your DNS provider, create the one CNAME record the app shows you. ClickClacks checks your DNS and tells you what it found if something is off.
  3. ClickClacks then issues an HTTPS certificate from Let’s Encrypt. If your domain has CAA records that don’t allow Let’s Encrypt, the app shows the record you need to add.
  4. When the domain is live, only the script’s src changes. data-key and data-domains stay the same:
html
<script async src="https://cc.acme.com/c.js" data-key="ck_live_8f3a2c" data-domains="acme.com,www.acme.com,app.acme.com"></script>

Loaded from cc.acme.com, the tracker also sends its events to cc.acme.com. Heatmap page captures still go to app.clickclacks.io. Your custom domain answers only the tracker script and the event endpoint; every other path returns a 404.

Moving your sources over

Update the snippet on each site to the new src. The app shows which sources are still sending to app.clickclacks.io. Events sent the old way keep being accepted for 30 days after your domain is verified; after that they are refused while the custom domain is live. If your custom domain stops being live, for example because the DNS record is removed, app.clickclacks.io keeps accepting events and the snippet shown in the app goes back to loading from it.