{
  "slug": "bw-lead-ai",
  "name": "BW Lead Attribution Intelligence",
  "version": "1.8.4",
  "download_url": "https://plugins.bowden.works/wp-content/uploads/plugin-updates/bw-lead-ai-1.8.4.zip",
  "download_hash": "sha256:47294bcd0a4de9da814fd5428d741f3c3f21986fa264f8259d6af19563077356",
  "download_size": 509697,
  "requires": "6.0",
  "tested": "",
  "requires_php": "7.4",
  "last_updated": "2026-08-11",
  "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.8.4] - 2026-08-11\n\n### Changed\n- **A journey now hears about the pages a visitor reads after the first one.** The\n  update beacon was throttled to one report per browsing session, so in \"Every time\n  they come back\" mode a returning visitor reported their opening pageview and nothing\n  else — everything they read afterwards waited for a next visit, and on the last\n  visit before they went quiet that tail was never recorded at all. The browser now\n  also reports as it leaves each page, using `navigator.sendBeacon`, which is the API\n  built for it: the browser owns the request from that point, so it survives the page\n  being torn down where an ordinary request would be cancelled with it.\n\n  **Two brakes keep that from becoming a request per page.** A report whose payload is\n  identical to the last one sent is dropped without a request at all — a reload, a back\n  button and a tab switched away and back all produce one — and otherwise there is at\n  most one report a minute. The single exception is the first teardown of a given page,\n  which is allowed inside that window because it is the last chance to say what\n  happened on it. Five pages read over a few minutes is about five small reports.\n\n  Both teardown signals are listened for. `pagehide` is the correct one, but iOS\n  Safari routinely tears a page down without firing it, and `visibilitychange` to\n  hidden is what does fire there; on desktop they overlap harmlessly, since whichever\n  arrives second finds an unchanged payload and is dropped.\n\n  **The post-submission path is untouched.** After a form submission on a site that\n  saves on submission, every pageview still reports however little has changed — that\n  is what captures the thank-you page and the thank-you after it, and it is exempt from\n  both brakes deliberately. Nothing changed server-side: which reports are accepted is\n  still the update mode's decision, enforced on the server.\n\n- **\"When is a journey saved?\" is one checkbox instead of two options.** They were\n  never alternatives. A destination's confirmation saves a journey whichever way the\n  setting was pointed, so the only real question — and now the only thing on screen —\n  is whether a form submitted on this site saves one too. Nothing stored changed and\n  nothing migrates; the automatic default still follows whether a cross-domain\n  destination is configured, and an explicit choice still sticks.\n\n- **The Journey Storage tab now says what actually happens, in order.** In place of the\n  old options' prose: a journey is held for the real hold time (read from the\n  cross-domain setting, not a number written into the sentence), it is saved when the\n  form is submitted, and held journeys nobody submits expire on their own. A site with\n  no cross-domain destination is no longer told about destinations. The one combination\n  that stores nothing — no on-site saving and no destination — now says so on the page\n  instead of being discovered by an empty journeys list a month later.\n\n- **The three update options now say how often each one writes**, which is the question\n  they were being read for. Never: nothing after the save, and the browser is not asked\n  to report at all. Until their visit ends: every page after the submission, then\n  nothing more, ever. Every time they come back: every visit, at the cadence above.\n\n### Fixed\n- **\"Never — keep it exactly as it was saved\" implied a resubmit might update the\n  journey.** It cannot. Every submission carries its own token and saves its own\n  record, so a second enquiry from the same person is a second, separate journey — in\n  every mode. The description says that plainly now.\n\n- **The cross-domain wizard forgot which of its two options you had chosen.** The\n  answer to \"what should happen when they get there\" was reconstructed from whether any\n  fields were mapped rather than from the answer itself, so a datapoint that stopped\n  being shared silently reset the choice and the wizard asked again as though it had\n  never been answered. The choice is now recorded when it is made — including when it\n  is \"just the journey link\" — and read back as given."
}