{
  "slug": "bw-lead-ai",
  "name": "BW Lead Attribution Intelligence",
  "version": "1.5.0",
  "download_url": "https://plugins.bowden.works/wp-content/uploads/plugin-updates/bw-lead-ai-1.5.0.zip",
  "download_hash": "sha256:fb263a49a3c09a23433b650ff8bae19d446efb00cf14520ae52ce39803e5c93e",
  "download_size": 282000,
  "requires": "6.0",
  "tested": "",
  "requires_php": "7.4",
  "last_updated": "2026-08-06",
  "homepage": "https://plugins.bowden.works/bw-lead-ai/",
  "author": "Bowden Works",
  "description": "Capture traffic source, attribute it to every lead, and understand where your leads are coming from.",
  "changelog": "## [1.5.0] - 2026-08-06\n\n### Added\n- **Visitor Journeys browse page** (Settings → Visitor Journeys) — every captured\n  journey in one list, so you no longer need a link from the destination to find one.\n  Filter by confirmed enquiries vs awaiting confirmation, search by channel, campaign\n  or page, and click through to the full report. Appears only when handoff is on.\n\n- **The journey report is now a proper report.** Previously it listed raw datapoint\n  names and values; the browsing history — the actual reason for the feature — wasn't\n  shown at all. It now leads with what matters:\n  - **Hero**: the channel they enquired through, when, and how long from first visit\n    to enquiry.\n  - **How they found us**: first touch and last touch side by side — shown as two\n    cards only when they differ, with a note explaining why both deserve credit.\n  - **At a glance**: visits, pages viewed, interactions, days to enquiry.\n  - **What they did**: a chronological timeline grouped by visit, with pages,\n    interactions and form submissions interleaved. \"Watched Campus tour (50%)\",\n    \"Downloaded viewbook.pdf\", \"Submitted a form\" — not merge-tag names.\n  - Everything else — all captured values, the written summaries, and record\n    plumbing — folded into collapsed sections so nothing is hidden but nothing\n    clutters.\n\n- **Structured browsing history.** A new **Full browsing history** datapoint captures\n  the journey as structured data rather than only as pre-formatted text, which is what\n  lets the report render a real timeline instead of parsing a blob back apart. Oversized\n  journeys are dropped rather than truncated — half a JSON document is unparseable.\n\n### Changed\n- **Stored and shared datapoints are now two separate lists**, and this is the\n  important one.\n\n  Previously a single list governed both what a record held *and* what the third-party\n  destination could claim. That meant the only way to see a visitor's browsing history\n  in the report was to also hand it to the destination — the exact opposite of the\n  Journey-link mode's purpose, and directly at odds with the recommended setup\n  (minimal fields to the CRM, full history kept behind login).\n\n  The Handoff tab now has a **Store** column and a **Send** column. Store feeds the\n  report and never leaves the server; Send is the subset the destination may claim.\n  A datapoint can only be sent if it is also stored, enforced on save and again when\n  a claim is served. Existing installs keep their current list as the stored set, with\n  the same values carried over as the shared set — no change in what any destination\n  currently receives.\n\n- Datapoints are labelled in plain language throughout the admin (\"Search term\",\n  \"First page visited\", \"Full browsing history\") rather than by merge-tag name."
}