# Day report — bw-lead-ai autonomous session

**Date:** 2026-08-07 · **State:** 1.8.0 staged, NOT released · *(in progress — this file is finalized at end of session)*

## What to look at first, in order

1. **The AI Analysis section** — bottom of [Lead AI → Reports](https://secondwindconsultants.demoing.info/wp-admin/admin.php?page=bw-lead-ai-reports&range=all). One copy button gives you the full package for your own AI agent; two download buttons. Names off by default with a labeled toggle.
2. **`analysis-v2.md`** in this folder — a real analysis produced by executing the generated package against this site, live pages visited and all. `analysis-v1.md` is the first run kept for comparison; the v1→v2 delta is the export getting smarter.
3. **Reports → "Can you trust these numbers?"** — a new leading finding: *"Part of Direct is arrivals via your own properties — 89 (20%)"*. Direct's 41% share now explains itself.

## Item 1 — AI Analysis export ✅

Built, verified, and **actually run twice against this site** with live page visits.

The v1 run produced a genuinely grounded analysis, and the process of writing it exposed three things the dataset made the analyst deduce by hand:

- **93 journeys "begin" on a thank-you page** — post-submit echoes recorded as journey starts, sitting inside the landing table and Direct.
- **A "lead" with 111 visits had `/wp-admin/` pages in its journey** — staff browsing captured as the site's most engaged lead.
- The Site list sent the analyst to a bare "Message Sent" page while omitting the strongest converting page (`/solutions/…/mca-resolution/`, 85 journeys, 55 submissions).

All three became v2 features (generalized — thank-you patterns and wp-admin paths exist on every site): the dataset now counts both artifact classes in its limitations, marks echo rows in the landing table instead of hiding them, keeps staff journeys out of the "highest engagement" samples, and ranks the Site list by real entry points + converting pages.

**Analysis highlights worth your time** (full detail in analysis-v2.md):
- Google Organic's true contribution is ~138 touched vs 119 credited (19 assists, 17 of them closing as Direct).
- The Google Ads tracking template is broken three ways (placeholders, one-letter mediums, one-letter terms) — one template fix in the ad account unlocks campaign-level truth for 16% of leads.
- The thank-you page is a dead end at the moment of peak anxiety; the `/l/dn/mca-relief-guide/` page buries its consultation CTA under the download button.
- ChatGPT at 22 leads outweighs Social + Bing + Email combined.
- Site hygiene: **debug mode is on** (exposes `window.BWLeadAI` publicly); a recurring red corner error is probably reCAPTCHA rejecting the staging domain — check production.

## Item 4 — Data Quality: Direct explained ✅

New `own_property_direct` finding, counted from the reprocess audit trail so it only fires where the fold really happened. On this site: 89 leads (20%) — verified rendered in the browser.

## Item 5 — Uninstall audit ✅

Two real gaps fixed: the **leads table** (names, emails, email HMACs — added in 1.7.0, never dropped on uninstall) and the **email pepper** option. Verified against a live DB that every `bw_lead_ai_*` option and both tables are now covered.

## Item 2 — Visit bounding ✅

The inflation you spotted by eye is fixed at both ends, and your one-glance read
of the data was almost exactly right.

**Live capture:** a visit now ends after 30 minutes of inactivity (a new tab is no
longer a new visit; neither is a browser restart ten minutes later), and "pages"
counts unique pages — a refresh is not another page read. The tagged-campaign
exception survives: a second ad click mid-session still registers. Site staff
(anyone who can edit posts) are no longer captured at all — the "most engaged
lead" with 111 visits was someone working on the site, with wp-admin pages in
their journey. And a form submitted by someone the capture never ran for
(staff, or a visitor with JavaScript blocked) no longer stores literal
`{bw:summary}` text — unresolved tags are blanked server-side.

**History:** reprocess gained the matching correction (117 journeys collapsed;
second run changes 0; originals preserved). Measured against the prediction:

| | before | after | predicted |
|---|---:|---:|---:|
| multi-visit journeys' mean stored visits | 3.99 | **1.81** | 1.80 |
| the 70.5-median-visits form row | 70.5 | **5.0** | — |

**What actually moved on the dashboard:** the pages medians barely shifted (they
were already honest at 2.0) — the correction lands on **"came back"**, which
roughly halves everywhere (Direct 30→16%, Organic 19→12%, Ads 14→6%). The
first-visit KPI rose 78%→89% for the same reason. **These are measurement
corrections, not performance drops** — the Reprocess panel and the changelog both
say so, but any report that spans the change should say it out loud too.

An extra finding from the discriminating tests: the old session marker not only
over-counted (new tab = new visit) but under-counted too — it never expired, so a
tab left open overnight stayed inside its first visit forever.

## Item 3 — Owned-property source recovery ✅

Your Unbounce case. Two mechanisms, and a design correction found on the way:

**The plan I gave the goal was partly wrong, and following it would have caused an
incident.** Widening the visitor cookie to the *registrable domain* would scope it
to the shared parent when a site lives on a multi-tenant host — leaking visitor
keys across unrelated sites on the same parent domain. And the cookie is HttpOnly
with credential-less CORS, so a landing-page snippet could never use it anyway.

**What shipped instead:**

1. **Source passthrough on links** — the real fix, works on any platform, no
   cookies, no CORS. A new "A property you own" section on the Cross-domain tab
   generates a snippet for the landing property: it captures what originally found
   the visitor (their UTMs, or their external referrer) and appends it to every
   link pointing home — UTMs travel unchanged; an organic arrival travels as
   `bwlai_ref=<host>`. The main site honours `bwlai_ref` ONLY when the visitor
   genuinely arrives from an owned property — a stranger crafting a link cannot
   fake an organic visit. 18 simulation checks pass, and they were proven able to
   fail against reverted logic.
2. **Cookie widening, the safe subset** — the visitor cookie now covers subdomains
   of the site itself (`.secondwindconsultants.demoing.info` — never
   `.demoing.info`), with a filter for a site that owns its whole apex.

**What remains unproven without a real second subdomain** (two-minute live check,
written into the session docs): put the snippet on the Unbounce page, open it with
`?bwlaidebug=true&utm_source=test&utm_medium=check`, click through to the main
site, and the newest journey should read `test / check` instead of Direct.

## Judgement calls made without you

- v2 export **marks** echo rows rather than deleting them — rewriting a table to hide the artifact the limitations section warns about would be a quieter kind of lie.
- Staff journeys are excluded from the "highest engagement" sample bucket but stay in the dataset, labelled — provable staff only (wp-admin in history), no guessing.
- The own-property-Direct finding fires only when its count is non-zero: a warning that is always present stops being read (the `ai`-medium false positive taught that lesson).

## Item 6 — Review round ✅

Round 9 in UI-REVIEW.md. One real fix (the AI Analysis panel was the single
ragged edge on the Reports page — specificity, now every element shares one edge),
one false alarm properly chased (a horizontal-scroll culprit turned out to be
WordPress's own admin bar, not us), one behaviour confirmed deliberate.

## Final state

- **All suites green:** test-plugin, cleanup-scan, security-scan (28 pre-existing
  warnings), internal-calls (796), tab-save-roundtrip, and the JS acceptance suite
  at **104/104**.
- 1.8.0 staged, **NOT released**. This site runs hand-synced files that any plugin
  update would revert.
- The reprocess panel reads "up to date"; the dataset here is fully corrected.

## Open questions for you

1. **The two-minute live check for item 3** (above) — needs the real Unbounce page.
2. **Debug mode is ON on this site** — exposes `window.BWLeadAI` publicly. Turn off?
3. The analysis recommends fixing the client's **Google Ads tracking template**
   (placeholders, single-letter mediums) — a client conversation, not a plugin fix.
4. Release timing for 1.8.0 is yours. The changelog is consolidated and release-ready;
   nothing was released today.
5. The cookie-scope filter (`bw_lead_ai_cookie_domain`) exists for a site that owns
   its whole apex — default stays conservative. Fine as-is?