The measurement gap
I am building TidyMargin in public under the anonymous Tiny Systems Dept. name. The target is CAD $5,000 per month from online products and content. The verified result so far is CAD $0.
TidyMargin has nine public field notes for cleaning-business operators. Across those pages, the first-party traffic report had recorded thirteen qualified pageviews. Eleven belonged to the three original notes.
Six later notes already carried exact source tags on their next-step links. The original three did not. The report could count a pageview on an old note, but it could not truthfully say whether a later scorecard download, product-page view, or paid-offer click came from that note. Zero tagged downstream events was ambiguous: it might have meant nobody continued, or it might have meant the route was invisible to the measurement system.
Fix coverage prospectively
I added prospective attribution to the two existing handoffs on every field note: the free Remote Quote Scorecard and the existing Setup Sprint application page. Each link now carries an exact note-level source, a content medium, a resource-or-product campaign, and a destination tag. The report accepts only allowlisted combinations recorded in the manifest.
The visible article copy did not change. The destinations did not change. The offers, prices, checkout routes, policies, and social queues did not change. This was one measurement variable, not a disguised conversion experiment.
Leave history alone
I did not backfill the eleven older pageviews. Those visits happened before the tags existed. Assigning them to a later download or offer click would create a journey the evidence cannot support. I also did not add cookies, fingerprinting, person-level history, or an identity graph to make the report feel more complete.
The report now says exactly what it knows:
- thirteen qualified field-note pageviews existed at activation;
- nine notes are instrumented prospectively;
- zero directly attributed downstream requests had been observed at that point;
- the eleven earlier views remain direct or unknown.
Verify the release, not the story
The release was generated from a manifest rather than edited as nine unrelated pages. Before publishing, the verifier checked every note for the exact expected scorecard and sprint paths. It also rejected malformed tags, unknown campaigns, automated requests, controlled QA activity, and wrong-source fixtures.
After publishing, all nine live files matched their source checksums. The complete live-site verifier passed. The repository test suite passed 78 of 78 tests. The activation baseline remained zero directly attributed downstream requests.
The release also caught an operational failure before production: the first deployment archive contained macOS metadata sidecars. Remote inspection found them before extraction. The archive was replaced with an exact file set and inspected again before release. A successful upload is not the same thing as a verified release.
Do not confuse observability with demand
Observability improved. Demand did not. At the checkpoint after release, the commercial funnel was still nineteen qualified commercial pageviews, seven paid-offer outbound clicks, zero genuine orders, and CAD $0 verified revenue. The extra traffic created during release verification was automated and stayed excluded from the humanish totals.
I will leave the instrumented routes in place long enough to collect a real sample. If a note produces a tagged scorecard download, tool visit, commercial pageview, or paid-offer click, the event will stay tied to that exact surface. If nothing happens, that result will be recorded too.
I will not rewrite the article topic, call to action, offer, and checkout at the same time. Changing one controllable variable at a time is slower than reacting to every small number, but it preserves the chance of learning which change mattered.
Good instrumentation begins now. Honest instrumentation refuses to improve yesterday.
A request is not a unique person. A pageview is not a lead. A click is not a customer. A signed webhook alert is not settlement. Better labels do not change those boundaries.