Ecommerce Process Mining

E-commerce process mining

Capture what back-office staff actually do, as structured events read from the page's DOM rather than as video, and turn it into SOPs and an automation shortlist. The insight the whole design turns on: in e-commerce the screens are full of other people's data. The employee consents; the customer whose order is on screen never did. Every choice below follows from treating capture as a privacy system first and a data pipeline second.

Written by the engineer who has shipped this module. Every section in every reference carries a maturity tag: [P] ran in the earlier implementation, [D] was specified in its design notes and never built there, [A] was designed here and is held by the 76 unit tests and 24 SQL checks shipped with this skill and by nothing else. No part of the capture path has met a production browser, so plan the spike in extension.md. The tags and the audit record are in provenance.md; keep the tags in anything written from this skill.

When to use

• Mapping real order, return, listing, purchasing or support workflows across several web tools
• Building the capture extension, its consent, exclusion and pause controls, or the ingest API
• Generating per-role SOPs, or ranking manual work by cost so automation can be scoped

When NOT to use

Architecture

 EXTENSION (MV3)                   SERVER                        AI (batch)
 content script                    POST /ingest                  1 narrate each event
   label + confidence               bearer key, emit scope          cheap text model;
   value gate                       consent re-read per batch       low confidence goes
 service worker         batch       exclusions (again)              to vision on the crop
   pause, budget        ----->      scrub (authoritative)         2 mine branches across
   exclusions (first)               idempotent insert               sessions
   screenshot gate                       |                        3 write the SOP
   offline queue                         v
                                   events <-- gap-capture form (phone, floor, paper)

 connect: PKCE --> consent page --> one-time code --> exchange --> scoped API key

Critical facts

1. Two consents, not one. Connecting the extension authorises it to talk; the consent toggle authorises the server to accept. Ingest re-reads consent on every batch, so never cache it.
2. Exclusions beat the allowlist, and run twice. The extension first, so no local state is ever created, and the server again, so a stale client still leaks nothing. Both import one matcher.
3. Consent is per person per tenant. Staff shared across two legal entities consent to each separately; one row per user silently moves consent between them.
4. Managers never see who opted in. Aggregate only, suppressed below a group of five, because with three employees the count is the names.
5. A card number and a barcode look alike. About one EAN, GTIN or tracking number in ten passes Luhn. Match on length and issuer prefix, or the scrubber eats your product data.
6. code= is a discount code far more often than an OAuth code. Drop credential URLs by shape, meaning state= alongside or an auth path, never by parameter name.
7. A whole-viewport perceptual hash cannot see one field change. Dedup on it alone and low-confidence events reuse a screenshot taken before the value existed. Hash the element crop too, and never dedup a low-confidence event.
8. Service workers die mid-handshake. The PKCE verifier lives in chrome.storage.session, and timed pauses end by the clock, not by an alarm that may never fire.
9. Screenshots bypass the scrubber. It reads JSON, not pixels. Default to metadata_only wherever buyer data is on screen.
10. The consent toggle is necessary, not sufficient. EU deployments need a legal basis and usually a works-council consultation before go-live.

Hard rules

Never fail open on a privacy switch. Unreadable pause state means paused, an unparseable host means excluded, and a failed consent save leaves the toggle showing what the server believes.

Never read a value you would have to scrub. Password, card, one-time-code and hidden fields are skipped at the point of capture. The scrubber is a net, not a licence.

Never let the redeem be two statements. One-time codes are claimed with a single DELETE ... RETURNING.

Never accept an authorization request from an unknown extension id. A well-formed id proves nothing, so keep an allowlist.

Never report success to the extension for an event you did not store. It will delete its only copy.

Never present designed or added material as proven. Carry the [P], [D] and [A] tags into whatever you build from this.

Quick start

1. Fill the seam table against the host app: adaptation.md.
2. Settle the legal posture and the screenshot mode: consent-and-privacy.md.
3. Land the schema: data-model.md.
4. Build the employee and manager pages: console-surfaces.md. This slice ships on its own, with no extension, and is the only [P] one.
5. Add ingest and the scrubber: ingest.md, pii-scrubber.md.
6. Add the connect flow: extension-auth.md.
7. Build the extension: extension.md, screenshots.md, with the suites from testing.md.
8. Choose the target apps and categories: ecommerce-playbook.md, then the pipeline: ai-pipeline.md. The ledger behind every odd-looking template is provenance.md.

Reference directory

Part of the Timerise Skills index, which lists the sibling skills.