@mindful-web/marko-web-identity-x 1.83.0 → 1.85.0

package/CLAUDE.md

@@ -99,16 +99,29 @@ path of authentication. To compare upstreams:
 **`MindfulApiCall` is sampled.** Unsampled it ran ~55k events/hour / ~40M per month on the Fusable
 fleet, 88.9% of it `GetActiveAppContext` + `CheckContentAccess` — per-page-load context calls that
 are uniformly fast and analytically useless. Kept: **every non-`ok` outcome**, **every `ok` call
->= `MINDFUL_API_CALL_SLOW_MS`** (default 250ms — deliberately under Omeda's observed p95 of 282ms, so
-ordinary Omeda latency stays visible while fast idx calls fall away), and **1 in
-`MINDFUL_API_CALL_SAMPLE_RATE`** (default 100) of the rest. Each event carries `sampleRate` = the
-number of real calls it represents, so `sum(sampleRate)` recovers true volume; `sampleRate = 1` means
-the call was kept because it failed or was slow.
+>= `MINDFUL_API_CALL_SLOW_MS`** (default 250ms) *whose operation is not in*
+**`MINDFUL_API_CALL_NO_SLOW_CAPTURE`** (default `GetActiveAppContext,CheckContentAccess`), and **1 in
+`MINDFUL_API_CALL_SAMPLE_RATE`** (default 100) of everything else. Each event carries `sampleRate` =
+the number of real calls it represents, so `sum(sampleRate)` recovers true volume; `sampleRate = 1`
+means the call was kept because it failed or was slow.
+
+**Why the exclusion list exists.** The 250ms threshold alone did not hold. It was tuned against a
+`GetActiveAppContext` p95 of 206ms measured over only **1.4 hours**; over 48h that operation cleared
+250ms constantly and produced **96.3% of all kept events** (259,448 of 269,322 — 5,625/hour), so the
+sampler barely applied to the one operation generating the volume. Excluding the two per-page-load
+context operations from *slow*-capture drops them through to the 1-in-N sampler instead. Raising the
+threshold to ~1s was the alternative and is worse: it costs fidelity on every *other* operation to
+fix two. Errors and timeouts are unaffected — `GetActiveAppContext` contributed 28 errors and the
+only observed timeout (15,009ms against the 15s budget), and all of it still flows.
 
 Consequences when querying: `average(ms)` over everything **skews high** (fast calls are
 under-represented by design) — filter `WHERE sampleRate = 1` for the error/slow tail, or
-`WHERE sampleRate > 1` for a fast-call view. Set `MINDFUL_API_CALL_SAMPLE_RATE=1` to record
-everything again during an investigation, no deploy required.
+`WHERE sampleRate > 1` for a fast-call view. For the excluded operations the skew runs the *other*
+way: every success is sampled regardless of duration, so their `sampleRate = 1` rows are errors and
+timeouts **only**, never a slow tail — use `sampleRate > 1` with `percentile(ms, 95)` for their
+latency. Set `MINDFUL_API_CALL_SAMPLE_RATE=1` to record everything again during an investigation, or
+`MINDFUL_API_CALL_NO_SLOW_CAPTURE=` (explicitly empty) to restore slow-capture for every operation —
+neither needs a deploy. An *unset* `NO_SLOW_CAPTURE` means the default list, not "exclude nothing".
 
 It wraps `client.query`/`client.mutate`, **not** `fetch` — `@parameter1/omeda-graphql-client` sets
 `fetch` *after* spreading the caller's `linkConfig`, so a wrapped transport cannot be injected from
@@ -310,6 +323,287 @@ after `setIdentity`. `google-auth-library` is now a base-idx dependency (every s
 server-only) — accepted because the feature is gated on the client id. The Google OAuth app must
 list each site origin as an authorized JavaScript origin or the surfaces silently no-show.
 
+## Progressive Profiling — added 2026-08
+
+Detects an **identified or authenticated** visitor with unanswered demographic attributes, gates
+the article, and asks only the missing questions. The audience that matters is
+*identified-but-not-authenticated* — the `__idx_idt` holder arriving from an email link, the
+majority of who we know. Today those users' form answers go only to an anonymous content-access
+submission and never touch their AppUser record (`form-access.marko:100-105` sets
+`updateProfileOnSubmit = false`); this makes that write real.
+
+**Dormant fleet-wide.** `progressiveProfileFieldRows` defaults to `[]`; nothing renders and no
+shared behavior changes until a site declares fields *and* enables the theme's `progressiveProfile`
+site config (Part 2/3, `marko-web-theme-monorail` + the website repos).
+
+### The one hard constraint: attributes only
+
+The backing mutation is `progressiveProfileUpdate` on **idx-compat**
+(`mindful-reporting#263`, shipped 2026-08-05). It writes member **attributes** — select, boolean,
+text — and nothing else; built-in/core member fields were cut on review. A built-in column would
+render, accept a value, and then be silently unwritable: the user submits, gets `changed: false`,
+and is re-gated forever. `config.js` therefore **throws at boot** on one, and on three other
+configurations that are each a user-facing trap:
+
+| Boot check | Why the runtime failure is worse than a failed deploy |
+| --- | --- |
+| `type: 'built-in'` | Unwritable ⇒ permanent gate loop. **Silent** — the only one of these with no visible symptom until a user is stuck. |
+| `type: 'custom-boolean'` | `custom-column.vue` binds the checkbox to `customField.answer` but its handler writes `customField.value`, so a *required* checkbox can never be checked. The diff util, payload builder and mutation all handle booleans correctly — only the shared renderer does not. Re-allow once that is fixed. |
+| any other type | Falls through to `custom-column.vue`'s `<pre v-else>` debug block, printing raw field metadata to a real visitor. |
+| id missing from a non-empty `activeCustomFieldIds` | `routes/profile.js:88-104` silently discards the answer ⇒ gate loop. |
+| rows configured with no `apiToken` | Every write uses `getOrgUserApiToken()` and the form token is signed from it. |
+
+No coverage is lost: every field the fleet-wide impact analysis measured is a select attribute.
+
+### Files
+
+- `utils/get-missing-progressive-fields.js` — the diff. Matches on **`answer.field.id`**, never
+  `answer.id`. That distinction is the whole reason this feature does not reuse
+  `get-form-custom-fields.js` (or `config.getGTMUserData`): an idx answer's `id` is the *answer's*
+  id, so comparing it to a configured field id never matches, and the truthy-empty-array bug that
+  follows returns an answer object with no `field`. Returns `missingRows` with every column forced
+  `required: true`, so `custom-column.vue` needs no changes.
+- `utils/get-progressive-form-fields.js` — correct, feature-scoped replacement for
+  `get-form-custom-fields.js`. Stamps `id` with the **field** id, which is the contract
+  `custom-column.vue` reads and what `get-create-user-custom-fields.js` already emits.
+- `utils/build-progressive-profile-payload.js` — marshals the body into mutation variables, plus
+  `buildContentSource()`. **Definitions come from server config, never the body**, so a client
+  cannot widen what gets written by posting extra rows. Drops an empty select rather than sending
+  `optionIds: []`, which the writer reads as *unset* — the one way this feature could destroy data
+  despite the fill-blanks-only rule.
+- `routes/progressive-profile.js` — `POST /__idx/progressive-profile` (+ `/dismiss`). A thin proxy;
+  it owns *trust*, not writes.
+- `components/progressive-profile-form.marko` (`<marko-web-identity-x-progressive-profile-form>`)
+  + `browser/progressive-profile.vue` (`IdentityXProgressiveProfile`, overridable via
+  `CustomProgressiveProfileComponent`).
+- `utils/progressive-profile-telemetry.js` — resolves the New Relic agent (injected first, lazy
+  fallback) and exposes `createRecorder`, which emits one typed event per submit. See *Telemetry*.
+- `utils/progressive-profile-cookies.js` — the attempts escape valve, the optional dismissal
+  suppression, and the 3-day suppression that follows an unverified submit. **Not** bot safeguards;
+  that is reCAPTCHA's job, below.
+
+### What happens server-side of the route
+
+Everything, in one Mongo transaction: the re-diff that drops already-filled fields, the attribute
+writes, the `action-history` entries attributed via `context.source = 'PROGRESSIVE_PROFILE'`, and
+one `member-events` document of kind `PROGRESSIVE_PROFILE_SUBMIT`. The route does no
+fetch-then-write of its own, and **no session is ever minted** — a visitor stays merely identified,
+so a bot cannot come away holding one. There is no `actionId` client-side; attribution lives in
+`action-history`.
+
+Auth picks the target and the client never does: an authenticated visitor writes as themselves
+(`AppUser` token, `userId` ignored by the resolver), an identified one is written by the org token
+with the **resolved** `targetId` — `body.userId` is never trusted and a mismatch is a 403.
+
+Fires `onUserProfileUpdate` only when `changed`, guarded, reported through `onHookError`. That hook
+is **provider-agnostic** — Omeda rapid-identify is the most visible consumer but one of five
+(`marko-web-identity-x-mailchimp`, `marko-web-postup`, plus site-level Braze and ActiveCampaign
+packages). The `profileUpdateHooks` field records `dispatched | skipped | error`, and `dispatched`
+deliberately does **not** mean any hook succeeded: every registrant uses `shouldAwait: false`, and
+`utils/call-hooks-for.js` wraps each promise in `.catch(onHookError)`, so `callHooksFor` returns
+before the hooks run and essentially never rejects. An async failure is reported there and can never
+reach this field; `error` is a *synchronous* dispatch throw only. Deliberately **not** `onLoginLinkSent` / `onAuthenticationSuccess`: those drive
+auto-signup and the GA4 `subscribe` conversion, and this is not a registration.
+
+### Bot protection — verify, then discard the write rather than the visitor
+
+The threat is concrete: `marko-web-omeda-identity-x/middleware/set-identity-cookie.js` mints
+`__idx_idt` for a **real person's** AppUser id on any request carrying `oly_enc_id`, so a newsletter
+security scanner following an emailed link browses *as* an identified human and could write to a
+real record. Cloudflare on these sites segregates rather than drops and scores 30–99 reach the
+origin, so there is no upstream to lean on.
+
+Verification is the fleet standard — **reCAPTCHA v3 via `@mindful-web/marko-web-recaptcha`**, the
+same package, 0.5 floor and client shape as newsletter signup, contact-us, inquiries and the RigDig
+checkout. Action `progressiveProfileSubmit`, declared client-side and checked server-side so a token
+minted for another form cannot be replayed here.
+
+**What differs is the response to a failure: the write is dropped, never the visitor.** The
+submission "succeeds", the content unlocks, and the answers go nowhere. Every other form on the
+fleet returns a hard 400 the visitor can do nothing about, which is right when the worst case is a
+retried newsletter signup. Here the form is the only way past a gate on the article, so rejecting a
+false positive locks a real reader out of content they can otherwise reach — a bigger loss than the
+bot write it prevented. A bot gains an article it could largely have read anonymously, and gains no
+write, which is the only thing actually at stake.
+
+An earlier revision escalated to a reCAPTCHA v2 checkbox instead. Removed: it cost a second key pair
+maintained fleet-wide plus a chunk of client code, to solve a problem **nobody has evidence exists**
+— it is unknown whether newsletter scanners submit forms at all, or only load pages. Measure first
+(below); the code is recoverable from `0f35bb1` if the data ever justifies it.
+
+**Every failure mode passively accepts** — `low-score`, `no-token`, `bad-token`, `stale-token`,
+`wrong-action` — each recorded separately. `no-token` matters as much as the rest: it is what an ad
+blocker eating `api.js` produces, and the client deliberately **does not disable submit** when the
+script fails to load (as the other forms do) because that would strand a reader behind a gate with
+nothing to click.
+
+**One rule for every visitor.** A failed check drops the write whether or not a session is present.
+An earlier revision exempted session holders — `/user/profile` has no captcha either, so a session
+is already sufficient authorization for a profile write elsewhere in this package — but that is a
+user-initiated edit on a page someone navigated to, while this is an interstitial pushed at a
+link-follower, which is exactly what an email scanner hits. Scanners follow magic links, so a
+session is not proof of a human. The exemption also bought nothing: the score is recorded either
+way, so authenticated submits still serve as the known-human control group.
+
+**The suppression cookie is mandatory, not a nicety.** A discarded submit leaves the member's record
+unchanged, so the diff would gate them again on the very next article — forever. `__idx_pp_sup`
+(3 days, `progressiveProfile.unverifiedSuppressDays`) stops that and hands the visitor back to the
+content meter, exactly as dismissal does. It is deliberately a **different cookie** from
+`__idx_pp_dis`: "user skipped" and "we threw their answers away" need to be distinguishable in
+Part 2's debug output and in support.
+
+**The honest cost, and why the telemetry ships with this and not after.** A false-positive human
+fills the form in good faith, nothing is saved, and three days later they are asked again —
+permanently, invisibly to them *and to us*. The v2 challenge let them rescue themselves; this does
+not. So the score is recorded on **every** submit, passing or not:
+**one custom event per submit, typed by what happened** — `ProgressiveProfileSubmit` (the mutation
+ran), `ProgressiveProfileDiscarded` (passive accept), `ProgressiveProfileRejected` (401/403/400,
+carries `reason`) or `ProgressiveProfileError` (threw, or fell through unrecorded). Shared
+attributes: `contentId`, `ms`, then `recaptcha`/`recaptchaScore` from the verify step and
+`userId`/`auth` once the identity resolves; `Submit` adds `fieldCount`, `changed`,
+`profileUpdateHooks`. Never the submitted answers.
+
+Split by type rather than an `outcome` field so each outcome is independently countable and
+alertable — "how many passive submits" is a bare `count(*)`, not a filter. There is deliberately no
+`outcome`/`accepted` attribute; the type carries it, and two encodings drift. (The HTTP response
+still returns `accepted` — that is the dataLayer's contract, unrelated.)
+
+**The arithmetic is enforced, not left to discipline.** Each terminal branch records its own type,
+`createRecorder` makes `record` a no-op once anything has fired, and a `finally` backstop catches a
+path that recorded nothing — as `ProgressiveProfileError` with `reason: 'unrecorded'`, so a branch
+added without a call site surfaces in New Relic instead of quietly skewing the mix.
+
+**Why a custom event and not transaction attributes — and specifically not because of sampling.**
+Measured before switching: these apps run 165–588 transactions/minute against a ~10k reservoir,
+`Transaction` data is queryable 35 days back, and `idxGoogleStep` attributes land and query fine
+today. Every New Relic destination is reservoir-backed anyway (`transaction_events`,
+`custom_insights_events`, `application_logging.forwarding`), so there is no unsampled path to move
+to; `recordLogEvent` would have been worst of all here, since every Log record on this account
+arrives via the HTTP Log API with no `entity.guid` — no APM agent forwards application logs, so it
+would likely have no-opped. The real reasons: the decision rule needs `histogram(recaptchaScore)`
+and a dedicated event type is the right shape for it, `FROM Transaction WHERE name LIKE '%…%'` is a
+string match a route rename silently breaks, and the measurement stops depending on `Transaction`
+retention staying where someone set it. **Do not "fix" this back to `addCustomAttributes` on the
+grounds that sampling was never a problem — it wasn't.**
+
+**Deliberately unsampled**, unlike `MindfulApiCall`, which needed a hand-written sampler at ~40M
+events/month. This is one row per gate submission: `count(*)` is the true count and there is no
+`sampleRate` attribute.
+
+The agent comes from `req.app.locals.newrelic` when a site passed one to `startServer`
+(mindful-web#314), falling back to the shared lazy resolver in `@mindful-web/utils` — the option is
+new and **no site passes it yet**, so without the fallback this would go dark fleet-wide. That
+fallback is also why `utils/add-custom-attributes.js` is now a one-line delegation to
+`newrelicAgent.addCustomAttributes`: it used to carry its own line-for-line copy of the same agent
+resolution. `routes/google.js` is unchanged and keeps its step attributes on the transaction, where
+`idxGoogleStep` riding on `TransactionError` is what makes a 500 self-describing.
+
+Capturing the score required a small addition to the shared package: `verifyToken()` returns
+`{ success, score, action, hostname, errorCodes }` instead of throwing, and `validateToken` is now a
+thin policy layer over it with an unchanged contract. Reach for `verifyToken` when a caller needs to
+*decide*; `validateToken` remains right for a form that should just refuse. **Two traps if you touch
+it:** `science-medicine-group-websites`'s preference center echoes `e.message` verbatim to the
+browser, so those three strings are user-facing copy; and `fusable-websites/packages/payfabric`
+catches on `error.code`, which `http-errors` does not set, so a rejection there surfaces as a 500 —
+adding a `.code` would silently flip it to 400. There is also a live regression trap inside
+`validateToken` itself, commented at the call site: the original compared `undefined < minimumScore`
+against the raw body, so a success carrying no score *passed*; `verifyToken` normalizes that to
+`null`, and `null < 0.5` is true.
+
+**The decision rule.** Run these after launch (`~/.newrelic/nrql`, account 2723345) and act on them;
+a rejection rate is unactionable without the distribution behind it.
+
+```sql
+-- The mix. Rates span types with a comma-union, which NRQL supports natively.
+SELECT count(*) FROM ProgressiveProfileSubmit, ProgressiveProfileDiscarded,
+  ProgressiveProfileRejected, ProgressiveProfileError FACET eventType() SINCE 1 day ago
+
+-- Passive submits, and why.
+SELECT count(*) FROM ProgressiveProfileDiscarded FACET recaptcha SINCE 1 day ago
+
+-- The discard rate the rollout table keys on.
+SELECT percentage(count(*), WHERE eventType() = 'ProgressiveProfileDiscarded')
+FROM ProgressiveProfileSubmit, ProgressiveProfileDiscarded SINCE 1 week ago
+
+SELECT histogram(recaptchaScore, 1.0, 10)
+FROM ProgressiveProfileSubmit, ProgressiveProfileDiscarded SINCE 1 week ago
+
+-- Authenticated submits are the known-human control group: if their p5 sits below the
+-- threshold, the threshold is wrong, not the traffic.
+SELECT percentile(recaptchaScore, 5, 25, 50)
+FROM ProgressiveProfileSubmit, ProgressiveProfileDiscarded FACET auth SINCE 1 week ago
+```
+
+| Discard rate | Score shape | Action |
+| --- | --- | --- |
+| < 2% | any | Done. Passive accept is permanent. |
+| 2–10% | clustered below ~0.2 | Bots. Keep passive accept. |
+| 2–10% | clustered 0.3–0.5 | Lower `recaptchaMinimumScore`, re-measure. Far cheaper than a challenge. |
+| > 10% | any | Build the v2 escalation — `0f35bb1`. |
+
+**What actually bounds the damage** is not on this route and never was: the mutation re-diffs inside
+its own transaction and can only ever fill a field that was already empty, so nothing that gets past
+reCAPTCHA can destroy data. Every write also lands in `action-history` with its `input`/`result`, so
+a bad one is findable and reversible from one collection.
+
+**Escape valve.** `progressive-profile-cookies.js` tracks gate renders; the theme middleware
+increments and releases the content past `maxAttemptsPerUser`, and this route clears the counter on
+any success. The known cause of an unclearable gate is gone structurally, but a gate that can trap a
+real person is worse than no gate.
+
+### Telemetry & analytics
+
+One custom event per submit, typed by outcome — `ProgressiveProfileSubmit` / `Discarded` /
+`Rejected` / `Error`. Shared attributes `recaptcha`, `recaptchaScore`, `auth` (`org|user`; `FACET`
+it to see how much traffic is identified-but-not-authenticated, the population the feature exists
+for), `userId`, `contentId`, `ms`; `Submit` adds `changed`, `fieldCount`, `profileUpdateHooks`. See *Bot protection* above for why this is an event rather than transaction
+attributes, and for the decision rule it feeds. Operational only — **submission counts come from
+`member-events`.**
+
+The one thing still on the transaction is `onHookError`'s payload
+(`idxProgressiveProfileStep`, `idxUserId`), which rides on `noticeError` — a separate seam, and the
+right place for it: a non-fatal hook failure belongs next to the error it describes.
+
+The dataLayer bridge and the p1events bridge are independent subscribers to the same EventBus, so
+what reaches each is decided separately:
+
+- **p1events: form views only.** A dedicated branch in `marko-web-p1-events/browser/index.js`
+  (`Identity / View / Progressive Profile`, top-level content `entity`, `props` carrying
+  `audience`, `fieldCount`, `fieldKeys`). No submit event: `member-events` is written by the
+  mutation that did the work, inside its transaction, so no event means no write. Nothing is added
+  to `identifyOnSubmit` — the session is already identified before the form renders.
+
+  **Consequence of passive accept:** a discarded submit writes no `member-events` row, so the
+  abandonment funnel (view identities minus `PROGRESSIVE_PROFILE_SUBMIT`) counts it as abandonment.
+  Arguably correct — no data was collected — but "never submitted" and "submitted and we threw it
+  away" are different populations, and only the New Relic `unverified` count separates them.
+- **GA4/dataLayer keeps a submit event**, carrying server-truth `changed` so the conversion trigger
+  can filter on `changed === true`. A discarded (unverified) submit reports `changed: false`, so it
+  is excluded from completions with **no GTM change**; the accompanying `accepted` value
+  (`written|unverified`) just makes discards separately countable. GA4 will read **lower** than
+  `member-events` (blockers, bot filters, unload races); the direction is always undercount.
+  Reconciling them is a watchlist item, not a bug.
+
+**Trap:** `global-event-emitter.js` assigns `additionalEventData` *after* spreading `data`,
+clobbering anything the caller passed under that key — which is why `access.vue`'s `ent:` never
+reaches the bridge. The content entity is passed as `emit`'s third argument instead.
+
+Submitted **answer values are never tracked** anywhere — `fieldKeys` and the member-event's
+`fieldIds` record which questions were asked, nothing more.
+
+### Two live follow-ups, neither in this package
+
+1. 🔴 **Index drop/recreate, production.** `completed_auth_date_website_channel` and
+   `completed_auth_email_website_channel` had their `partialFilterExpression` widened; a changed
+   partial filter does not alter an index in place, so both must be dropped and recreated. Until
+   then progressive-profiling `member-events` queries collection-scan. Owner: audience/infra.
+2. **The shared-code PR.** `get-form-custom-fields.js`, the commented-out `custom-boolean` branches
+   in `generate-required-field-payload.js`, the `routes/profile.js` allowlist, `custom-column.vue`'s
+   boolean binding, and the p1events bridge's `contentGatingType`/`contentGateType` mismatch (every
+   producer in the fleet sets the latter, so gate type has **never** reached p1events for any
+   gate). All shared with live flows across 18 repos — deliberately not fixed alongside a new
+   feature.
+
 ## Fleet / rollout
 
 Not tracked in-repo. The Google-auth architecture change + fleet rollout plan lives outside the repo

package/api/mutations/progressive-profile-update.js

@@ -0,0 +1,29 @@
+const gql = require('graphql-tag');
+const userFragment = require('../fragments/active-user');
+
+/**
+ * The single consolidated write behind the progressive-profile gate.
+ *
+ * Everything happens server-side of this boundary, in one Mongo transaction: the re-diff that
+ * drops already-answered fields, the attribute writes, the `action-history` entries attributed to
+ * `PROGRESSIVE_PROFILE`, and the `PROGRESSIVE_PROFILE_SUBMIT` member-event that is the
+ * authoritative submission record. The route does no fetch-then-write of its own.
+ *
+ * Accepts either auth mode: an `AppUser` token writes to its own member and `userId` is ignored;
+ * an `OrgUserApiToken` writes to `input.userId`, which is the common case here — the gate's
+ * primary audience is identified-but-not-authenticated. **No session is ever minted**, so a
+ * visitor stays merely identified and a bot cannot come away holding one.
+ */
+module.exports = gql`
+  mutation ProgressiveProfileUpdate($input: ProgressiveProfileUpdateMutationInput!) {
+    progressiveProfileUpdate(input: $input) {
+      ok
+      changed
+      appUser {
+        ...ActiveUserFragment
+      }
+    }
+  }
+
+  ${userFragment}
+`;

package/browser/index.js

@@ -9,6 +9,7 @@ const Download = () => import(/* webpackChunkName: "identity-x-download" */ './d
 const Logout = () => import(/* webpackChunkName: "identity-x-logout" */ './logout.vue');
 const Login = () => import(/* webpackChunkName: "identity-x-login" */ './login.vue');
 const Profile = () => import(/* webpackChunkName: "identity-x-profile" */ './profile.vue');
+const ProgressiveProfile = () => import(/* webpackChunkName: "identity-x-progressive-profile" */ './progressive-profile.vue');
 const CommentStream = () => import(/* webpackChunkName: "identity-x-comment-stream" */ './comments/stream.vue');
 
 const $graphql = createGraphqlClient({ uri: '/__graphql' });
@@ -25,6 +26,7 @@ export default (Browser, {
   CustomLoginComponent,
   CustomLogoutComponent,
   CustomProfileComponent,
+  CustomProgressiveProfileComponent,
 } = {}) => {
   const AccessComponent = CustomAccessComponent || Access;
   const AuthenticateComponent = CustomAuthenticateComponent || Authenticate;
@@ -35,6 +37,7 @@ export default (Browser, {
   const LoginComponent = CustomLoginComponent || Login;
   const LogoutComponent = CustomLogoutComponent || Logout;
   const ProfileComponent = CustomProfileComponent || Profile;
+  const ProgressiveProfileComponent = CustomProgressiveProfileComponent || ProgressiveProfile;
 
   window.IdentityX = new IdentityX();
 
@@ -48,6 +51,7 @@ export default (Browser, {
   Browser.register('IdentityXLogin', LoginComponent, { provide: { EventBus } });
   Browser.register('IdentityXLogout', LogoutComponent, { provide: { EventBus } });
   Browser.register('IdentityXProfile', ProfileComponent, { provide: { EventBus } });
+  Browser.register('IdentityXProgressiveProfile', ProgressiveProfileComponent, { provide: { EventBus } });
 
   // Ensure the client-side IdX context is refreshed when the authentication event occurs
   EventBus.$on('identity-x-authenticated', () => window.IdentityX.refreshContext());
@@ -66,6 +70,7 @@ export default (Browser, {
     'identity-x-login-mounted',
     'identity-x-logout-mounted',
     'identity-x-profile-mounted',
+    'identity-x-progressive-profile-mounted',
     // Actions/submissions
     'identity-x-access-submitted',
     'identity-x-authenticated',
@@ -79,6 +84,12 @@ export default (Browser, {
     'identity-x-login-link-sent',
     'identity-x-logout',
     'identity-x-profile-updated',
+    // GA4 keeps a submit conversion for progressive profiling even though p1events does not:
+    // campaign/source attribution is impossible from the server-side `member-events` record.
+    // The conversion trigger must filter on `changed === true` so a no-op submit is not counted
+    // as a profile completion. Expect GA4 to read LOWER than `member-events` -- blockers, bot
+    // filters and unload races drop dataLayer pushes but not server writes.
+    'identity-x-progressive-profile-submitted',
     // Errors
     'identity-x-access-errored',
     'identity-x-authenticate-errored',
@@ -90,6 +101,8 @@ export default (Browser, {
     'identity-x-login-errored',
     'identity-x-logout-errored',
     'identity-x-profile-errored',
+    'identity-x-progressive-profile-errored',
+    'identity-x-progressive-profile-dismissed',
   ].forEach((event) => {
     EventBus.$on(event, (args) => {
       if (!window.IdentityX) return;