{
  "slug": "bw-lead-ai",
  "name": "BW Lead Attribution Intelligence",
  "version": "1.6.0",
  "download_url": "https://plugins.bowden.works/wp-content/uploads/plugin-updates/bw-lead-ai-1.6.0.zip",
  "download_hash": "sha256:ceb88dd38d95baf59dcdcc0d6c10562bc2886050f6c21f8829cb12565377e883",
  "download_size": 288521,
  "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.6.0] - 2026-08-06\n\n### Added\n- **Who the visitor was.** Two new options under Settings → Handoff, **both off by\n  default**: record the name and email of whoever submitted, and optionally keep a\n  copy of the whole submitted form. The journey report then opens with the person\n  rather than a channel, and the browse list gains a \"Who\" column.\n\n- **Captured server-side, never in the browser.** The obvious implementation — read\n  the name and email in JavaScript and keep them beside the journey in\n  `localStorage` — was rejected. This plugin otherwise stores no personal data at\n  all, which is what lets it say nothing identifying is retained, and why a\n  cross-site-scripting flaw on the host site cannot leak anything about a person.\n  Identity is instead read from the submission the server already receives\n  (`gform_after_submission`), and the only thing the browser contributes is the\n  handoff token it already holds.\n\n- **A destination can also supply it.** When the form lives on the third party's own\n  domain we never see it, so the confirm endpoint now accepts optional identity\n  fields. Keys are a fixed allow-list, the email must actually be one, and everything\n  is length-capped.\n\n- Two filters: `bw_lead_ai_extract_identity` and `bw_lead_ai_capture_submission` —\n  the latter for dropping a sensitive question before it is stored.\n\n### Security\n- **Identity and submissions live in dedicated columns, outside the datapoint\n  system.** The claim endpoint only ever reads the datapoint payload, so there is no\n  code path by which a name, an email or a form answer can reach a third-party\n  origin. That is a structural guarantee rather than a setting anyone could mis-tick,\n  and it is covered by a test asserting no trace of either appears in a claim.\n- Both options are gated on handoff being enabled, and both default off. The settings\n  copy states plainly that these are the only options in the plugin that cause\n  personal data to be retained, and points at the retention setting.\n\n### Notes\n- Schema version 2 adds two columns; `dbDelta` applies it in place on an existing\n  install without touching stored rows.\n- Identity is not currently captured for a visitor who never clicks through to a\n  destination — there is no journey record to attach it to. That is a natural\n  consequence of records being minted by the handoff flow, and is the same limitation\n  as journeys generally."
}