Which visits became customers? One real week, and why the answer was missing

This week's answer, and the one field behind it

The honest answer for 19 to 25 October is that the counts cannot say which visits became freshlycited.com's 10 customers. Every one of the 10 won sign-ups reached Skald from the site's server without a visitor ID, and the visitor ID is what joins a lead to the visits before it.

That is a gap in what the site sends, so it is fixed on the site's server, once: put the visitor ID in the lead the server already sends, in the field named vid. From that week on, each won sign-up can open to the visits that came before it. The rest of this note shows the counts, why 68 of the joined events still say Direct or unknown, and the steps.

It is also the turn from reacting to planning ahead that runs through from reactive to proactive: the question "which visits became customers?" gets an answer only if the site sends the ID before anyone asks.

One week of lead events on freshlycited.com

freshlycited.com is one of the sites our own Skald server measures, and it reports leads to Skald two ways. The page's script tag sends what a visitor does on the page (a sign-up started, a form sent). The site's server sends each lead through the signed lead hook, a short message signed with a secret so nobody else can send fake leads.

First-hand: Skald's live lead database for freshlycited.com, 19 to 25 October 2026 (counts only, test events excluded). No visitor's address, email or name is used here. Every other example on this page is sample data and is marked as such.

Read down the table and the gap is plain. Joining works where the ID travels: every script-tag event carries it. It fails where the ID stops: 116 of the 131 server events, and all 10 customers, arrived without it.

What "tied" means here, in Skald's code

A lead reaches Skald as one small record: an id of the site's own and what was done (signup, contact, demo). Everything else is optional, and three optional parts decide what Skald can show for it.

• The visitor ID (vid). With visitor IDs on, Skald's script tag gives each browser an ID and records its page views under it. A lead that carries the ID opens to those visits in its timeline, each with its day and source, and lists the sources that assisted. In this note, tied means exactly this: the event carries a visitor ID.
• The touches (first_touch and last_touch). The referrer (the page a visitor came from) and the landing page of the first visit and of the visit that made the lead, as the site saw them. From these Skald works out the lead's source and first source, by the same rules it uses for a visit in the log.
• A source of the site's own (source, plus landing and campaign). A site that works out the source itself can send it as source, written as one of Skald's source names such as Search engine; Skald then uses it as given, ahead of the touches.

A lead with none of these has no visit to join and no source of its own. Its source shows as Unknown, a figure not recorded, and Skald leaves it at that. The touches and the source fill the Sources tables; only the ID fills the timeline. So the 10 customers kept the source the server sent with them, 9 Direct or unknown and 1 Search engine, while having no visits to show.

Why 68 tied events still say Direct or unknown

A script-tag event takes the source of the visit it was sent in, by the visit's referring site and its utm_source tag. A visit with neither is Direct or unknown: an address typed or pasted, a bookmark, or a link in an app or a mail program that sends no referrer.

That source belongs to the one visit. A person who first found the site through a search and came back two days later by typing the address makes a sign-up whose own visit says Direct or unknown. The earlier search visit is still there, in the same browser's timeline, because the event carries the ID. This is where the ID earns its keep: the source column shows the last door, and the timeline shows the way in.

Build a lead and see what Skald can show

Pick what the site's server sends with one sample sign-up, and whether visitor IDs are on. It starts as this week's customers arrived: touches sent, no ID.

switch the parts

{
  "external_ref": "u-48213",
  "action": "signup",
  "first_touch": {"referrer": "https://chatgpt.com/", "landing": "/guides/start/"},
  "last_touch": {"landing": "/pricing/"}
}

Switch the visitor ID to Sent and the timeline appears, while the source stays the one the touches gave. Both are kept side by side.

Ten customers, and why their visits stayed hidden

Won is a stage the site's server sends later with the same lead id, "stage": "won" (or lost). The site decides what won means for its business, and Skald counts it as given. A won is an outcome of a lead, so it adds no second lead, and it has its own time: the time the server sends with it, or the moment it arrives.

A won row carries only what the server puts in it. A lead's timeline in Skald lists the visits that share its visitor ID, so the ID has to travel with the sign-up and again with each later stage. This week, none of the 10, at sign-up or at won, carried the visitor ID.

The counts do not say why the server's events lacked the ID, so here are the ways the code allows it, none of them a measured share: the server never received it from the page (no hidden field, no cookie read); the sign-up happened in an app or a second address where the ID was not shared; or the won was sent from a back office that keeps only the lead id.

Send the visitor ID with the sign-up

These steps change what the site sends, once, on its server.

1. Keep visitor IDs on for the site in Skald. They are off by default; the 72 script-tag events show they were on that week for freshlycited.com.
2. Bring the ID from the page to the server. Add a hidden field to the sign-up form and fill it before the form is sent: form.skald_vid.value = skald('id') || ''. Or, with "Share across subdomains" on, read the first-party cookie skald_vid (a cookie set by your own site's address, which also reaches its subdomains).
3. Send it as vid with the lead. The PHP lead file reads the field or the cookie by itself; in Node and Python, pass it, for example vid=request.form.get("skald_vid"). The files are on lead file from your backend.
4. Store it with the lead, and send it with every later stage. When the server later sends the won, the same vid keeps the customer's timeline whole.
5. Sign-ups on another address, such as an app subdomain, need the ID shared across both; cross-domain tracking covers that.

Then read the same table a week later. The server's share with a visitor ID should rise toward the script tag's, and the won sign-ups should start to open onto real visits.

Four events with an AI assistant as source, read carefully

Four of the 203 events had an AI assistant as their source, two with a visitor ID and two without. In Skald that source has a narrow meaning: the visit's referrer is an assistant's own site (such as chatgpt.com or perplexity.ai), or its address carries a tag an assistant adds, such as utm_source=chatgpt.com. It is a click from an answer, named by the visit itself.

The 4 are a floor. A person who read an answer and then typed the address arrives with no referrer, as Direct or unknown. Skald estimates such visits on its own: "likely from an AI assistant" counts a visit only when an assistant fetched the same page in the minutes before and chance cannot explain it, and that estimate stays a separate figure. How it works is on AI referrals.

What was left out before counting

The 203 is already a clean figure, and three rules made it so.

• Test events. An event sent with "test": true, or marked as test in Skald afterwards, is listed and marked, and left out of every count.
• Repeats. A server lead is kept once per site, tool, id and stage. The script tag keeps at most one event per visitor ID, action and stage in a short window, so a reload adds nothing.
• Spam and duplicates in a site's own lead database make no row at all.

Each rule, and the "Show left out" switch that lists what they removed, is on lead hygiene.

Check the week's figures yourself

Skald counts every lead figure twice, by separate code that shares only the name lists, and withholds a day the two counts disagree on. The site's server can also ask Skald which leads it holds, with a signed request to /traffic-hooks/<site>/leads, and send again any that are missing. That check is how a site can confirm that every lead it sent was kept.

In Skald, the Leads list opens each lead with what it carries: its source, first source, landing page and, with an ID, the visits before it. Opening a few of the server's leads shows at once whether the ID is there.

What these counts leave open

They are counts of events, so some questions stay open on purpose.

• No conversion rate. There is no visit total in them to divide by. Where Skald shows a rate on its own pages, it does so only over at least 10 starts.
• A browser, not a person. One person on a laptop and a phone has two visitor IDs, and two timelines.
• As known now. A lead the site marks won, lost or spam later changes the figures, so the same week read next month may differ a little.

To see every way leads reach Skald, from booking tools, payment tools and forms, start at lead attribution. To run the same counts on your own site, see the plans and the 30-day trial.