A small service is best evaluated by the record it leaves behind. Every change to the service, every internal review, every incident lands here in the order it happened. Nothing is rewritten after the fact.
A separate public surface now hosts per-domain evaluation reports. Each report sits behind a per-domain access code; the merchant gets a single-page summary scoring their tracking, consent, and conversion setup, with the specific fixes called out alongside each finding. Linked from the marketing footer and reachable from the site's command palette.
A new public page sets out exactly how an evaluation score is produced — the weights given to each finding, the honesty band on the revenue-lift estimate, and the categories we deliberately don't score. Linked from the footer of every evaluation report. A reviewer who wants to audit our numbers has the source of truth in one place.
A short-lived per-prospect deliverable that shipped earlier in the month was retired today. The substance moves to the new evaluation tool — one URL per merchant, one access code per merchant, no app to log into. The legacy route now returns a not-found response and is removed from indexes.
The monitoring offer now has a one-page intake: enter a domain, accept terms, copy a single line of script. The intake validates against the same schema the monitoring service itself enforces, so an invalid signup cannot reach the service in the first place. The script is generated per merchant and is the only thing that needs to land in the storefront for monitoring to begin.
The service that watches a storefront's tracking and pixel layer in production cut its first end-to-end staging build today. Fifteen tightly scoped waves: storage layer, registration, signed per-merchant script, beacon ingest, detection engine, deduplication, alert dispatch, retention sweep, secret-rotation drill, and a step-by-step deploy runbook. Production rollout is gated on the first cohort of monitored merchants.
A passive layer now forwards security-policy violations and integrity failures from the public surface to an independent third-party reporting endpoint in report-only mode. Runtime errors on the same surface are tunnelled to a separate product-error monitor that pages the operator within minutes. The visitor sees no change; the operator sees problems within minutes of them happening.
Every public mention of our revenue-lift estimate now reads "15–25% of paid-ads revenue." Earlier wording left the denominator implicit, which could be misread as a percentage of total revenue — an order of magnitude apart. The explicit denominator is enforced by a build-time check so the language can't quietly regress in a future edit.
Two changes that protect the path between writing code and shipping it. Pushes to anything other than the two canonical branches now refuse at the local pre-push step, and the preview-deploy hook is disabled on the working branch so an intermediate commit never accidentally surfaces as a public preview URL. Neither change is visible to merchants; both close common ways an in-progress change can become publicly visible before it's ready.
A small set of words that had drifted into our own copy were removed and added to a build-time blocklist. The biggest cut was the metaphor we'd been using for missing recovery — the word is in the air, but it's vague and not what we actually do. Replacement language is direct: drift, missing fires, recovery shortfall.
How this page works
Technical detail is kept off this page on purpose — a public log shouldn't double as a map for attackers. For full depth or our sub-processor list, email vadim@loomaru.com.