8. Following One Lead From Link to Inbox

Following one test lead through the Ledgerlane path

The Ledgerlane offer page is written. Its "Book a diagnostic call" button leads to the six-field Tally form. The form has a confirmation and a first follow-up email drafted beside it. All of that works. What you can't do yet is tell anyone what happened after a post went out. Did anyone see it? Did they click? Did the people who filled in the form fit the service, or were they a four-van firm looking for a penalty appeal?

This chapter adds that ability, and then tests it. It finishes the stage of the course where you build a complete customer path. The first half sets up measurement: what you want to happen, what you will count, and how a campaign link carries its origin into the form. The second half runs one test lead through every step and checks each place it should leave a mark. By the end you can follow a single lead from the link it clicked to the record it created.

The habit behind this chapter is one the course already uses for copy. A claim only counts when you can name its source. A number works the same way. "Four leads this week" means nothing until you can say what was counted, where, and what was left out.

Start with the outcome you want

Before you track anything, decide what success is. For Ledgerlane, the answer comes straight from the brief. The service is for one- and two-van trade contractors. They usually arrive because of a penalty letter or a big year-end bill. So the outcome you want is a booked diagnostic call from a qualified lead. A qualified lead here means a contractor with one or two vans and a penalty or bill trigger.

That definition is narrow on purpose. A visitor is not a lead. A form submission is not always a qualified lead. A three-van firm, or someone who only wants an appeal, can fill in the form and still be a poor fit. If you count every submission as success, you will praise a post that brought in the wrong people.

The diagnostic call can't be booked automatically yet. The call length is still an open owner question, so the Calendly step after the form is waiting. For now, "call booked" means the founder replied and agreed a time. You record it by hand. That is fine. The outcome is defined before the tooling exists.

Five things you can observe, and why they differ

Marketing reports mix together five quite different observations. Keep them apart.

Reach is how many people had the chance to see something. If you post in a local trades group on Facebook, reach is roughly how many members saw the post in their feed. The platform reports it, using its own method. You can't check it yourself.

Engagement is what people did with the post itself: reactions, comments, shares, clicks on the link. A post can get forty comments from other bookkeepers and no interest from a single plumber. Engagement tells you the post was noticed. It doesn't tell you who noticed.

Qualified leads are people who reached the form and fit the service. You learn this from the form's own answers, the van count and the trigger, so this number comes from your records, not the platform's.

Conversion is a step from one stage to the next. The one that matters most here is from qualified lead to booked call, and then from call to signed customer. Conversion is always a rate between two counts, so you need to say which two.

Revenue is money. For Ledgerlane that is £180 a month for a one-van customer and £260 for two vans.

Here is an illustrative example to show how these separate. The numbers are made up. Say your post in a trades group reaches about two thousand people. Sixty of them click through to the offer page. Five submit the form. Three are qualified: one van or two, with a penalty letter or a big bill. Two of those book a call. One signs up for one van. That is £180 a month in revenue.

Look at the gaps between those numbers. Two thousand people saw the post and one became a customer. If you judged the post by its reach, you would think it was huge. If you judged it by its comments, you might think it failed. Neither tells you what you care about. Only the last three numbers come from records you control. That is why the lead record matters more than any dashboard.

The events worth tracking

An event is one thing a visitor does that a tool writes down. For this path you need four.

A page view means someone loaded the offer page. A button click means they pressed "Book a diagnostic call." A form submit means they sent the Tally form. A call booked means the founder confirmed a time with them.

The first three can be recorded by software. The fourth happens in a conversation, so for now it goes in your lead sheet by hand.

Each event answers a question. Page views with no clicks suggest the page isn't convincing people. Clicks with no submits suggest the form is putting people off. Submits that aren't qualified suggest the post or the page attracted the wrong reader. You need all four to know where people drop away.

Campaign links that carry their origin

When someone arrives at your page, your analytics tool tries to work out where they came from. Often it guesses badly. A visit from a Facebook group, a WhatsApp message and a typed address can all look alike. Campaign links fix that by writing the origin into the link itself.

The standard way to do this uses UTM parameters. UTM stands for Urchin Tracking Module, an old name from the tool Google bought to make Google Analytics. A UTM parameter is a small label added to the end of a web address after a question mark. Your analytics tool and your form can both read it.

Three labels do most of the work. Source names where the visitor came from, such as facebook or a newsletter's name. Medium names the type of channel, such as social, email or paid. Campaign names the push this link belongs to. Two more exist, term and content, for keywords and for telling apart two versions of the same post. You can skip them for now.

Let's build one. Say you are posting in a local trades group in October, aimed at contractors who just got a penalty letter. Your link is the offer page address, then a question mark, then "utm underscore source equals facebook", then an ampersand, then "utm underscore medium equals social", another ampersand, and "utm underscore campaign equals penalty underscore letter underscore october". Spoken aloud it is long. On screen it is one line.

Keep your labels in lower case and spell them the same way every time. "Facebook" and "facebook" will show up as two different sources. Write the agreed spellings in a short note in the project workspace, so every later link follows them.

Some people shorten long links with a link shortener. That is fine, as long as the shortener forwards the full address with its labels. That is one of the things the test later checks.

Catching the labels in the Tally form

A campaign link tells your analytics tool where a visitor came from. But your analytics tool is not your lead record. You also want the origin stored next to each person's form answers. That way, when the founder looks at a submission, it already says "facebook, social, penalty letter October."

Tally does this with hidden fields. A hidden field is a form field the visitor never sees. It fills itself from the web address. In the Tally form builder, you type a forward slash and the word "hidden" on a new line, then press Enter. You then name the fields to match the labels in your link exactly: utm underscore source, utm underscore medium and utm underscore campaign. The names are case-sensitive, so a capital letter breaks the match. Then press Publish, or the fields won't be live.

When a visitor opens the form at an address that carries those labels, Tally fills the matching hidden fields. The values are saved with the submission. In the form's Submissions tab, they appear as columns beside the name, van count and trigger.

There is a catch, and it matters for Ledgerlane. The labels arrive on the offer page, because that is the address in your post. The form lives at a separate Tally address. When the visitor presses the button, does the form get the labels too? That depends on how the form is connected to the page. Hold that question. The test will answer it.

Recording the click and the submit

For page views, button clicks and submits, you need an analytics tool on the offer page. Two are worth comparing here.

Google Analytics 4, usually called GA4, is free and widely used. Plausible Analytics is a smaller, paid, privacy-focused tool. Both can record a page view as soon as their script is on the page. Both need a small extra instruction for the button click and for the submit.

For the button click, a short script watches the "Book a diagnostic call" button. When it is pressed, the script sends an event. In GA4 you might name it button click. In Plausible you might name it CTA Click. CTA stands for call to action. If you use a website builder, it may offer a box for adding scripts. If it doesn't, this is a small job for whoever manages the site.

The submit is trickier. The Tally form usually sits inside the page as an embedded frame, a window onto another site. The page can't see what happens inside that window. Tally solves this by sending a message out of the frame when someone submits. The message is called Tally dot FormSubmitted. A short listener on the page waits for it and passes it on to your analytics tool. GA4 has a standard event name for this, generate lead. In Plausible you create a goal called Form Submission. Plausible needs both goal names registered in its dashboard, or it won't count them.

Notice what this depends on. The submit message reaches your page only if the form is embedded on your page. If the button just sends people to Tally's own address, your page is gone by the time they submit. Nothing on it is listening.

Both tools have a live view for checking events as they happen. In GA4 it is the Realtime report, under Reports. There is also DebugView, under Admin, for a closer look at single events. In Plausible, the dashboard shows current visitors at the top and a Goal Conversions panel at the bottom.

What UK consent rules mean for these counts

Ledgerlane serves UK contractors, so UK rules apply to how its page uses cookies and similar storage. For years, the Privacy and Electronic Communications Regulations, known as PECR, meant most sites needed opt-in consent before analytics cookies could run. That is why so many sites have banners.

That changed for one kind of analytics. The Data (Use and Access) Act 2025 amended PECR. The change has been in force since the fifth of February 2026. The Information Commissioner's Office, the UK's data regulator, finalised its guidance on storage and access technologies on the twenty-ninth of April 2026. Under the new exception, you no longer need opt-in consent when the only purpose is collecting combined statistics about how your site is used, so you can improve it.

The exception has conditions. You must tell visitors clearly what you use and why. You must give them a simple, free way to object, such as a setting that turns analytics off. The data must be combined into totals, and individual-level data kept only as long as it takes to make those totals. It can't be used to make decisions about one person. If an outside company provides the analytics, it must act only for you. It can't reuse, combine or share the data for its own purposes.

The exception does not cover advertising. Cross-site tracking, ad measurement, remarketing and profiling still need prior opt-in consent. That matters for GA4. A standard GA4 setup with Google Signals or ad-personalisation sharing switched on links your analytics to advertising. It doesn't fit the exception, so it still needs consent. Penalties under PECR now match UK data protection law, up to £17.5 million or four percent of global annual turnover. Small sites rarely face that, but the gap between fines tells you the rules are taken seriously.

Here is what this means for Ledgerlane. Plausible says it uses a cookieless method. It stores nothing on the visitor's device, and the hash it uses to count visitors changes every day. Tools that store and access nothing on the device sit outside PECR's consent rule altogether. Your handling of personal data must still follow UK data protection principles, and you should still explain your analytics on the page. GA4 can work, but you would need to set it up carefully and probably show a consent banner.

A banner changes your counts. When someone refuses or objects, the page must stop storing or reading identifiers on their device. Their visit goes unseen. Their multi-page session may break into pieces. Their submit may never be linked to the post that brought them. A site with a banner always under-counts, by an amount you can't measure. The usual pattern is that a meaningful share of visitors decline. So for this example, Plausible is the simpler choice. It has no banner gap, and the counts are closer to what really happened. Your Tally records don't depend on any of this, because they are written when someone submits.

What the numbers will never show

Even with a clean setup, some leads won't come with a label. Know where the gaps are before you read a report.

Dark social is sharing in private spaces, such as WhatsApp, text messages and email. If a plumber copies your page address without the labels and sends it to a friend, the friend arrives with no source. Your analytics tool may file the visit as "direct," as if they typed the address.

Cross-device visits split one person in two. Someone sees the post on their phone at lunch, then fills in the form on a laptop that evening. Cookieless tools can't link those visits, and most cookie-based tools can't either. The submit may show no campaign.

Refused cookies, as above, make visits vanish from tools that need consent.

And some people skip the form. A contractor sees the post, finds the phone number and rings. That lead never touches Tally, so no hidden field ever fills. The founder has to ask, "How did you hear about us?" and write the answer down. The form leaves that question out on purpose, to keep it short. On a call, it costs nothing to ask.

So read every campaign count as a floor, not a total. Some of what you are owed sits in the "direct" pile or in the founder's call notes.

A lead sheet that follows one person

The analytics tool counts visits in totals. The Tally dashboard stores submissions. Neither one follows a lead past the form. Until a CRM arrives, a simple spreadsheet does that job. Make it a Google Sheet, kept alongside the project files.

Each row is one lead. The columns follow the path in order. Date first. Then source, medium and campaign, copied from the hidden fields, or "phone" or "unknown" for leads that didn't come through the form. Then van count and trigger, from the form. Then a qualified column, yes or no, with a short reason when it is no. Then call booked, with a date. Then became customer, yes or no, and the monthly fee from the price rows, £180 or £260. Then a test column, which you will need in a moment. Then a notes column.

Reading across a row tells one lead's story. Reading down a column tells you how a campaign did. Count the qualified "yes" answers for the October penalty-letter campaign, and you have a number you can stand behind.

Now the setup is ready. The only way to know it works is to use it.

Running the test on a phone

Use your phone, because that is where contractors will read this. Open a private browsing tab, so no earlier visit gets in the way. For the test link, use the October link from earlier, with one change. Set the source to test, the medium to test and the campaign to test. A test lead should never be mistaken for a real one, even if someone forgets the test column.

Open the link. Look at the offer page as a contractor would. Check that the hero line about the penalty-or-bill moment comes first, that the prices read £180 for one van and £260 for two, and that the exclusions sit next to the prices. Then press "Book a diagnostic call."

Fill in the form as a one-van contractor with a penalty letter. In the name field, write "TEST" plus the date, so the record explains itself. Use an email inbox you can check. Pick one van. Pick penalty letter as the trigger. Leave the optional box empty. Submit.

The confirmation appears. Read it closely. The owner placeholder for reply time is still there, as it should be, because the founder hasn't answered yet. That placeholder blocks going live. The test proves the confirmation shows. It doesn't make the confirmation ready. Write it down.

Checking every place the lead should appear

Now go through each place the lead should have reached. Use the same order every time you test.

First, open the Tally dashboard on a computer and go to the form's Submissions tab. The test entry should be there. The name, email, phone, one van and penalty letter should all be in the right columns. Then look at the three hidden-field columns for source, medium and campaign.

In this illustrative run, they are empty.

That is the catch from earlier. The labels reached the offer page, because the link pointed there. But the button sends the visitor to the Tally form's share link, a separate address. That jump drops everything after the question mark. The form opened clean, so its hidden fields had nothing to fill. A redirect or a link shortener that strips labels would fail the same way.

Second, check the inbox for the Tally account owner. The notification email for the test submission should be there. In this run it is.

Third, check analytics. Open the Plausible dashboard while you repeat the test. If you use GA4, open the Realtime report. The page view shows up. The button click shows up as a CTA Click goal. The form submit does not. That is the same fault showing up in a second place. The form was on Tally's own site, not inside your page, so the Tally dot FormSubmitted message went to a page with no listener.

Fourth, check the follow-up email. Nothing arrives, and nothing should. The follow-up email drafted with its sentence tags isn't sent automatically. Right now the founder copies it and sends it by hand. That is a gap, not a fault. It works only if someone remembers. Record it as a gap, with the time it would take a lead to hear back on a busy day.

Fixing the fault and testing again

One change fixes both failures: embed the form on the offer page instead of linking away from it. Tally's embed widget reads the labels in the parent page's address and passes the matching ones into the form's hidden fields. It does this for standard, pop-up and full-page embeds. Point the "Book a diagnostic call" button at the embedded form, either as a pop-up or as a section further down the page. Add the short listener that turns the submit message into your Form Submission goal.

If the page builder only accepts a plain embedded frame, without Tally's script, the labels won't pass on their own. A small script has to add the page's address labels to the form's address. That is a job for whoever manages the site, and a reason to prefer the official widget.

Then run the test again, exactly as before, with a new TEST name and time. This time the Submissions tab shows test in all three hidden-field columns. Plausible shows the page view, the click and the form submission. The notification email arrives. The confirmation still shows the owner placeholder. The follow-up still waits for the founder.

Also check the page on a phone again. An embedded form changes the page layout, so redo the quick checks from the form chapter. Make sure the sticky button doesn't cover the form fields when they are in focus, and that the choices still meet the tap-size check at narrow widths.

The fault note and the test record

Save a fault note in the project workspace beside the other form notes. Write it so someone else could reuse it. What broke: the hidden UTM fields stayed empty, and the submit event never fired. Why: the button sent visitors to the Tally share address, which dropped the labels and left the page before submitting. What changed: the form is now embedded with Tally's widget, and a listener is on the page. How it was checked: a second test, with all three fields filled and the submit goal counted. Also list what is still open: the owner placeholder blocking going live, and the follow-up email being sent by hand.

Then keep the test out of your real numbers. In the lead sheet, add the test rows with the test column marked yes. Every count you make filters those rows out. In Tally, the TEST name and test labels make the entries easy to spot and remove later. Leave them for now as proof the path worked on this date. In Plausible, the test source shows up as its own line, so it won't mix with real campaigns. Keep a note of the test dates, so you can ignore those visits when you set a baseline.

Here is where the path stands. A tagged link reaches the page. The click and the submit are counted in a tool that fits UK consent rules. The form stores the lead's answers with their origin. The account owner is notified. The lead sheet carries the lead on to qualified, booked and signed. You can check each step and say what each number counts. Two things are still open, and both are written down: the owner placeholder that must go before launch, and the follow-up that depends on someone remembering.

With the path working end to end, the next question is what to send down it. That is channel craft: articles, emails, posts and ads that each carry the same defended claims to this page.

Getting Tally records into a CRM

The fault notes already say the Tally records will need a duplicate-checking connection once a CRM exists. There are three ways to do it. They differ in two things that matter for Ledgerlane: whether the UTM labels arrive with the contact, and whether a second submission from the same person creates a duplicate.

Tally's own integrations come first. They are built in and need no upkeep. But they connect to Notion, Airtable, Google Sheets and Slack, not to sales CRMs. Hidden fields do arrive, as columns or properties in those tools. Duplicate handling stops at the form. Tally can block repeat submissions, but it can't check whether a contact already exists anywhere else. A Google Sheets integration is still useful now. It could fill your lead sheet automatically, labels included.

A connector such as Zapier or Make sits between Tally and the CRM. Tally has official triggers there that connect to HubSpot, Pipedrive and Salesforce. Your hidden fields show up as named values you can match one to one with contact fields. For duplicates, HubSpot offers a "Create or Update Contact" action that uses email as the identifier. A contractor who submits twice updates one record instead of creating two. With a lookup step, you can also keep the first campaign that brought them. The trade-off is cost. Connector plans charge by usage, so the bill rises as submissions rise.

A Tally webhook is the third way. When someone submits, Tally sends the record to a web address you control. This works on free and paid plans. The hidden fields arrive inside the list of fields, marked as hidden fields. Duplicate checking becomes your job, written into whatever receives the data. That receiver must be hosted, maintained, and must reply within Tally's ten-second window. It is the most flexible option and the most to look after, so it fits later in the course.

You don't need to pick a CRM yet. One small step now: add one line to the form fault note. Whichever route you use, email is the identifier for each contact, and the three UTM fields must carry over unchanged. That way, when the CRM arrives, the test you just ran becomes the test you run again.